diff --git a/detection_rules/rule_formatter.py b/detection_rules/rule_formatter.py index e4b4d704b60..f080ed0bf55 100644 --- a/detection_rules/rule_formatter.py +++ b/detection_rules/rule_formatter.py @@ -249,6 +249,14 @@ def _do_write(_data, _contents): # This will ensure that the output file has the correct number of backslashes. v = v.replace("\\", "\\\\") + if k == 'osquery' and isinstance(v, list): + # Specifically handle transform.osquery queries + for osquery_item in v: + if 'query' in osquery_item and isinstance(osquery_item['query'], str): + # Transform instances of \ to \\ as calling write will convert \\ to \. + # This will ensure that the output file has the correct number of backslashes. + osquery_item['query'] = osquery_item['query'].replace("\\", "\\\\") + if isinstance(v, dict): bottom[k] = OrderedDict(sorted(v.items())) elif isinstance(v, list): diff --git a/rules/apm/apm_403_response_to_a_post.toml b/rules/apm/apm_403_response_to_a_post.toml index d8010b71afc..72a90b2e67b 100644 --- a/rules/apm/apm_403_response_to_a_post.toml +++ b/rules/apm/apm_403_response_to_a_post.toml @@ -2,7 +2,7 @@ creation_date = "2020/02/18" integration = ["apm"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -32,4 +32,38 @@ type = "query" query = ''' http.response.status_code:403 and http.request.method:post ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Web Application Suspicious Activity: POST Request Declined + +Web applications often use POST requests to handle data submissions securely. However, adversaries may exploit this by attempting unauthorized actions, triggering a 403 error when access is denied. The detection rule identifies such anomalies by flagging POST requests that receive a 403 response, indicating potential misuse or probing attempts, thus aiding in early threat detection. + +### Possible investigation steps + +- Review the source IP address and user agent associated with the POST request to identify any patterns or known malicious actors. +- Examine the URL or endpoint targeted by the POST request to determine if it is a sensitive or restricted resource. +- Check the timestamp of the request to see if it coincides with other suspicious activities or known attack patterns. +- Analyze the frequency and volume of similar 403 POST requests from the same source to assess if this is part of a larger probing or attack attempt. +- Investigate any recent changes or updates to the web application that might have inadvertently triggered legitimate requests to be denied. + +### False positive analysis + +- Legitimate API interactions may trigger 403 responses if the API endpoint is accessed without proper authentication or authorization. Review API access logs to identify and whitelist known applications or users that frequently interact with the API. +- Web application firewalls (WAFs) might block certain POST requests due to predefined security rules, resulting in 403 errors. Analyze WAF logs to determine if specific rules are causing false positives and adjust the ruleset accordingly. +- Automated scripts or bots performing routine tasks might inadvertently trigger 403 responses. Identify these scripts and ensure they are configured with the necessary permissions or exclude their IP addresses from the detection rule. +- User error, such as incorrect form submissions or missing required fields, can lead to 403 responses. Educate users on proper form usage and consider implementing client-side validation to reduce these occurrences. +- Maintenance or configuration changes in the web application might temporarily cause 403 errors. Coordinate with the development or operations team to understand scheduled changes and adjust monitoring rules during these periods. + +### Response and remediation + +- Immediately review the logs associated with the 403 POST requests to identify the source IP addresses and user agents involved. Block any suspicious IP addresses at the firewall or web application firewall (WAF) to prevent further unauthorized attempts. +- Conduct a thorough review of the web application's access control policies and permissions to ensure that they are correctly configured to prevent unauthorized actions. +- Check for any recent changes or updates to the web application that might have inadvertently altered access controls or introduced vulnerabilities, and roll back or patch as necessary. +- Notify the security operations team to monitor for any additional suspicious activity from the identified IP addresses or similar patterns, and escalate to incident response if further malicious activity is detected. +- Implement additional logging and monitoring for POST requests that result in 403 responses to enhance detection capabilities and gather more context for future incidents. +- Review and update the web application firewall (WAF) rules to better detect and block unauthorized POST requests, ensuring that legitimate traffic is not affected. +- If applicable, engage with the development team to conduct a security review of the application code to identify and fix any potential vulnerabilities that could be exploited by attackers.""" diff --git a/rules/apm/apm_405_response_method_not_allowed.toml b/rules/apm/apm_405_response_method_not_allowed.toml index bedc96ade16..2a9367dd263 100644 --- a/rules/apm/apm_405_response_method_not_allowed.toml +++ b/rules/apm/apm_405_response_method_not_allowed.toml @@ -2,7 +2,7 @@ creation_date = "2020/02/18" integration = ["apm"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -32,4 +32,38 @@ type = "query" query = ''' http.response.status_code:405 ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Web Application Suspicious Activity: Unauthorized Method + +Web applications often restrict HTTP methods to protect resources, allowing only specific actions like GET or POST. Adversaries may exploit misconfigurations by attempting unauthorized methods, potentially revealing vulnerabilities or sensitive data. The detection rule identifies such attempts by flagging HTTP 405 responses, indicating a method is not permitted, thus highlighting potential misuse or probing activities. + +### Possible investigation steps + +- Review the web server logs to identify the source IP address associated with the HTTP 405 response to determine if the request originated from a known or suspicious source. +- Analyze the request headers and payload associated with the 405 response to understand what unauthorized method was attempted and if there are any patterns or anomalies. +- Check the application configuration to verify which HTTP methods are allowed for the resource in question and assess if there are any misconfigurations that could be exploited. +- Investigate if there are multiple 405 responses from the same source IP or user agent, which could indicate probing or automated scanning activity. +- Correlate the 405 response events with other security alerts or logs to identify any related suspicious activities or potential attack vectors. + +### False positive analysis + +- Routine API calls using unsupported methods may trigger 405 responses. Review API documentation to ensure correct methods are used and adjust monitoring to exclude these known patterns. +- Automated tools or scripts might inadvertently use incorrect HTTP methods, leading to false positives. Identify and update these tools to use appropriate methods, or whitelist their IP addresses if they are known and trusted. +- Web crawlers or bots might attempt unsupported methods as part of their scanning process. Configure your monitoring system to recognize and exclude these benign activities based on user-agent strings or IP ranges. +- Development and testing environments often experiment with various HTTP methods, resulting in 405 responses. Implement rules to exclude these environments from production monitoring to reduce noise. +- Legacy systems or applications might not support certain HTTP methods, causing frequent 405 errors. Document these systems and create exceptions in your monitoring to prevent unnecessary alerts. + +### Response and remediation + +- Immediately review the web server and application logs to identify the source IP address and user agent associated with the 405 response. Block the IP address if it is determined to be malicious or part of a known attack pattern. +- Conduct a security assessment of the web application's configuration to ensure that only necessary HTTP methods are enabled for each resource. Disable any methods that are not required for the application's functionality. +- Implement or update web application firewall (WAF) rules to block unauthorized HTTP methods and monitor for repeated attempts from the same source. +- Notify the security operations team to monitor for any additional suspicious activity from the identified source or similar patterns, and escalate to incident response if further malicious activity is detected. +- Review and update the application's security policies and access controls to ensure they align with best practices and prevent unauthorized method usage. +- Conduct a vulnerability assessment of the web application to identify and remediate any potential security weaknesses that could be exploited by unauthorized HTTP methods. +- Document the incident, including the response actions taken, and update the incident response plan to improve future detection and response capabilities for similar threats.""" diff --git a/rules/apm/apm_sqlmap_user_agent.toml b/rules/apm/apm_sqlmap_user_agent.toml index c8ba5b28669..570ea7d28b5 100644 --- a/rules/apm/apm_sqlmap_user_agent.toml +++ b/rules/apm/apm_sqlmap_user_agent.toml @@ -2,7 +2,7 @@ creation_date = "2020/02/18" integration = ["apm"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -32,4 +32,39 @@ type = "query" query = ''' user_agent.original:"sqlmap/1.3.11#stable (http://sqlmap.org)" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Web Application Suspicious Activity: sqlmap User Agent + +Sqlmap is a widely-used open-source tool designed to automate the detection and exploitation of SQL injection vulnerabilities in web applications. Adversaries may exploit sqlmap to extract sensitive data or manipulate databases. The detection rule identifies suspicious activity by monitoring for specific user agent strings associated with sqlmap, flagging potential unauthorized testing or attacks on web applications. + +### Possible investigation steps + +- Review the logs to identify the source IP address associated with the user agent string "sqlmap/1.3.11#stable (http://sqlmap.org)" to determine the origin of the suspicious activity. +- Check for any other user agent strings or unusual activity from the same IP address to assess if there are additional signs of probing or attacks. +- Investigate the targeted web application endpoints to understand which parts of the application were accessed and if any SQL injection attempts were successful. +- Correlate the timestamp of the detected activity with other security logs or alerts to identify any concurrent suspicious activities or anomalies. +- Assess the potential impact by reviewing database logs or application logs for any unauthorized data access or modifications during the time of the detected activity. +- Consider blocking or monitoring the identified IP address to prevent further unauthorized access attempts, if deemed malicious. + +### False positive analysis + +- Development and testing environments may use sqlmap for legitimate security testing. To handle this, create exceptions for known IP addresses or user agents associated with internal security teams. +- Automated security scanners or vulnerability assessment tools might mimic sqlmap's user agent for testing purposes. Identify and whitelist these tools to prevent unnecessary alerts. +- Some web application firewalls or intrusion detection systems may simulate sqlmap activity to test their own detection capabilities. Coordinate with your security infrastructure team to recognize and exclude these activities. +- Educational institutions or training environments might use sqlmap for teaching purposes. Establish a list of authorized users or networks to exclude from alerts. +- Ensure that any third-party security service providers are recognized and their activities are documented to avoid misidentification as threats. + +### Response and remediation + +- Immediately block the IP address associated with the sqlmap user agent activity to prevent further unauthorized access attempts. +- Review and analyze web server logs to identify any additional suspicious activity or patterns that may indicate further exploitation attempts. +- Conduct a thorough assessment of the affected web application to identify and patch any SQL injection vulnerabilities that may have been exploited. +- Reset credentials and enforce strong password policies for any database accounts that may have been compromised. +- Implement web application firewall (WAF) rules to detect and block SQL injection attempts, including those using sqlmap. +- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation. +- Document the incident details and response actions taken for future reference and to enhance incident response procedures.""" diff --git a/rules/cross-platform/command_and_control_google_drive_malicious_file_download.toml b/rules/cross-platform/command_and_control_google_drive_malicious_file_download.toml index cde6a30ffa4..e00be1244c6 100644 --- a/rules/cross-platform/command_and_control_google_drive_malicious_file_download.toml +++ b/rules/cross-platform/command_and_control_google_drive_malicious_file_download.toml @@ -2,7 +2,7 @@ creation_date = "2023/06/19" integration = ["endpoint", "system"] maturity = "production" -updated_date = "2024/08/09" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -49,6 +49,41 @@ process where /* Look for Google Drive download URL with AV flag skipping */ (process.command_line : "*drive.google.com*" and process.command_line : "*export=download*" and process.command_line : "*confirm=no_antivirus*") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious File Downloaded from Google Drive + +Google Drive is a widely-used cloud storage service that allows users to store and share files. Adversaries may exploit its trusted nature to distribute malicious files, bypassing security measures by using download links with antivirus checks disabled. The detection rule identifies such activities by monitoring browser processes for specific Google Drive download patterns, flagging potential threats for further investigation. + +### Possible investigation steps + +- Review the process command line details to confirm the presence of the Google Drive download URL with the "export=download" and "confirm=no_antivirus" parameters, which indicate an attempt to bypass antivirus checks. +- Identify the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Check the file downloaded from the Google Drive URL for any known malicious signatures or behaviors using a reputable antivirus or malware analysis tool. +- Investigate the source of the download link to determine if it was shared via email, messaging, or another communication channel, and assess the legitimacy of the source. +- Analyze network logs to identify any additional suspicious activity or connections related to the IP address or domain associated with the download. +- Review historical data for any previous similar alerts or activities involving the same user or device to identify potential patterns or repeated attempts. + +### False positive analysis + +- Legitimate file sharing activities from Google Drive may trigger alerts if users frequently download files for business purposes. To manage this, create exceptions for specific users or departments known to use Google Drive extensively for legitimate work. +- Automated scripts or tools that download files from Google Drive for regular data processing tasks might be flagged. Identify these scripts and whitelist their associated processes or command lines to prevent unnecessary alerts. +- Educational institutions or research organizations often share large datasets via Google Drive, which could be mistakenly flagged. Implement exceptions for known educational or research-related Google Drive URLs to reduce false positives. +- Internal IT or security teams may use Google Drive to distribute software updates or patches. Recognize these activities and exclude them by specifying trusted internal Google Drive links or user accounts. +- Collaboration with external partners who use Google Drive for file sharing can lead to false positives. Establish a list of trusted partners and their associated Google Drive URLs to minimize unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further spread of potential malware or unauthorized access. +- Quarantine the downloaded file and perform a detailed malware analysis using a sandbox environment to determine its behavior and potential impact. +- If malware is confirmed, initiate a full system scan using updated antivirus and anti-malware tools to identify and remove any additional threats. +- Review and analyze the process command line logs to identify any other suspicious activities or downloads that may have occurred concurrently. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Implement network-level blocking of the specific Google Drive URL or domain if it is confirmed to be malicious, to prevent future access. +- Update endpoint detection and response (EDR) systems with indicators of compromise (IOCs) identified during the analysis to enhance detection of similar threats in the future.""" [[rule.threat]] diff --git a/rules/cross-platform/command_and_control_non_standard_ssh_port.toml b/rules/cross-platform/command_and_control_non_standard_ssh_port.toml index 7e90f0a3dc5..639840ec937 100644 --- a/rules/cross-platform/command_and_control_non_standard_ssh_port.toml +++ b/rules/cross-platform/command_and_control_non_standard_ssh_port.toml @@ -2,7 +2,7 @@ creation_date = "2022/10/18" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/18" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -56,6 +56,40 @@ sequence by process.entity_id with maxspan=1m ) ] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Non-Standard Port SSH connection + +SSH is a protocol used for secure remote access and management of systems. Typically, it operates over port 22. However, adversaries may exploit non-standard ports to evade detection and bypass network filters. The detection rule identifies unusual SSH activity by monitoring processes and network connections on ports other than 22, excluding common benign use cases, to flag potential threats. + +### Possible investigation steps + +- Review the process details, including process.entity_id and process.name, to confirm the execution of SSH or SSHD processes and identify any unusual parent processes not listed in the exclusion list. +- Examine the network connection details, focusing on destination.port to verify the use of non-standard ports for SSH connections and assess if these ports are commonly used within the organization. +- Analyze the destination.ip to determine if the connection is being made to an external or potentially malicious IP address, especially if it falls outside the specified CIDR ranges. +- Investigate the context of the SSH connection attempt by checking for any recent changes in network configurations or firewall rules that might explain the use of non-standard ports. +- Correlate the alert with other security events or logs to identify any patterns or additional indicators of compromise related to the same process or network activity. + +### False positive analysis + +- Legitimate administrative tools like rsync, git, and ansible-playbook may use SSH over non-standard ports for valid operations. Ensure these tools are included in the process.parent.name exclusion list to prevent false positives. +- Backup and synchronization applications such as pyznap and pgbackrest might use SSH on non-standard ports. Add these applications to the exclusion list to avoid unnecessary alerts. +- Development and deployment tools like Sourcetree and git-lfs may establish SSH connections on non-standard ports during routine operations. Verify these tools are part of the exclusion criteria to minimize false positives. +- Custom scripts or automation tasks that use SSH on non-standard ports for internal processes should be reviewed and, if deemed safe, added to the exclusion list to reduce noise. +- Internal network traffic to non-public IP ranges might be flagged if not properly excluded. Ensure that internal IP ranges are correctly specified in the cidrmatch exclusion to prevent false positives. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious SSH processes identified on non-standard ports to halt potential malicious activity. +- Conduct a thorough review of the system's SSH configuration files to identify unauthorized changes, such as modifications to the SSH port settings, and revert them to the standard configuration. +- Reset credentials for any accounts accessed via the non-standard port to prevent further unauthorized access. +- Implement network-level controls to block SSH traffic on non-standard ports unless explicitly required and documented for legitimate use cases. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Enhance monitoring and alerting for SSH connections on non-standard ports across the network to improve early detection of similar threats in the future.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/cross-platform/credential_access_cookies_chromium_browsers_debugging.toml b/rules/cross-platform/credential_access_cookies_chromium_browsers_debugging.toml index 3a940510079..3e89eb92165 100644 --- a/rules/cross-platform/credential_access_cookies_chromium_browsers_debugging.toml +++ b/rules/cross-platform/credential_access_cookies_chromium_browsers_debugging.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "windows"] min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." min_stack_version = "8.14.0" maturity = "production" -updated_date = "2024/05/28" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -64,6 +64,41 @@ process where event.type in ("start", "process_started", "info") and "--remote-debugging-pipe=*") and process.args : "--user-data-dir=*" and not process.args:"--remote-debugging-port=0" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Cookies Theft via Browser Debugging + +Chromium-based browsers support debugging features that allow developers to inspect and modify web applications. Adversaries can exploit these features to access session cookies, enabling unauthorized access to web services. The detection rule identifies suspicious browser processes using debugging arguments, which may indicate cookie theft attempts, by monitoring specific process names and arguments across different operating systems. + +### Possible investigation steps + +- Review the process details to confirm the presence of suspicious debugging arguments such as "--remote-debugging-port=*", "--remote-debugging-targets=*", or "--remote-debugging-pipe=*". Check if these arguments were used in conjunction with "--user-data-dir=*" and ensure "--remote-debugging-port=0" is not present. +- Identify the user account associated with the suspicious browser process to determine if it aligns with expected behavior or if it might be compromised. +- Investigate the source IP address and network activity associated with the process to identify any unusual or unauthorized access patterns. +- Check for any recent changes or anomalies in the user's account activity, such as unexpected logins or access to sensitive applications. +- Correlate the event with other security alerts or logs to identify if this activity is part of a broader attack pattern or campaign. +- If possible, capture and analyze the network traffic associated with the process to detect any data exfiltration attempts or communication with known malicious IP addresses. + +### False positive analysis + +- Development and testing activities may trigger the rule when developers use debugging features for legitimate purposes. To manage this, create exceptions for known developer machines or user accounts frequently involved in web application development. +- Automated testing frameworks that utilize browser debugging for testing web applications can also cause false positives. Identify and exclude processes initiated by these frameworks by specifying their unique process names or user accounts. +- Browser extensions or tools that rely on debugging ports for functionality might be flagged. Review and whitelist these extensions or tools if they are verified as safe and necessary for business operations. +- Remote support or troubleshooting sessions using debugging features can be mistaken for suspicious activity. Implement a policy to log and review such sessions, allowing exceptions for recognized support tools or personnel. +- Continuous integration/continuous deployment (CI/CD) pipelines that involve browser automation may inadvertently match the rule criteria. Exclude these processes by identifying and filtering based on the CI/CD system's user accounts or process identifiers. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious browser processes identified with debugging arguments to stop potential cookie theft in progress. +- Conduct a thorough review of access logs for the affected web applications or services to identify any unauthorized access attempts using stolen cookies. +- Invalidate all active sessions for the affected user accounts and force a re-authentication to ensure that any stolen session cookies are rendered useless. +- Implement stricter browser security policies, such as disabling remote debugging features in production environments, to prevent similar exploitation in the future. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been compromised. +- Enhance monitoring and alerting for similar suspicious browser activities by refining detection rules and incorporating additional threat intelligence.""" [[rule.threat]] diff --git a/rules/cross-platform/credential_access_forced_authentication_pipes.toml b/rules/cross-platform/credential_access_forced_authentication_pipes.toml index db0ec420cba..261a87ce870 100644 --- a/rules/cross-platform/credential_access_forced_authentication_pipes.toml +++ b/rules/cross-platform/credential_access_forced_authentication_pipes.toml @@ -2,7 +2,7 @@ creation_date = "2024/07/23" integration = ["endpoint", "system"] maturity = "production" -updated_date = "2024/10/01" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -60,6 +60,40 @@ sequence with maxspan=15s [network where host.os.type == "linux" and event.action == "connection_attempted" and destination.port == 445 and not startswith~(string(destination.ip), string(host.ip))] by host.ip, data_stream.namespace [file where host.os.type == "windows" and event.code == "5145" and file.name : ("Spoolss", "netdfs", "lsarpc", "lsass", "netlogon", "samr", "efsrpc", "FssagentRpc")] by source.ip, data_stream.namespace ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Active Directory Forced Authentication from Linux Host - SMB Named Pipes + +Active Directory (AD) and SMB named pipes facilitate network resource access and inter-process communication. Adversaries exploit these by forcing authentication from a Linux host to capture credentials or perform relay attacks. The detection rule identifies suspicious SMB connection attempts from Linux to Windows hosts, focusing on specific named pipes indicative of forced authentication attempts, thus highlighting potential credential access threats. + +### Possible investigation steps + +- Review the network logs to identify the Linux host IP address that attempted the SMB connection on port 445 and verify if this activity is expected or authorized. +- Check the Windows host logs for event code 5145 to determine which named pipes were accessed and assess if these accesses align with normal operations or indicate suspicious activity. +- Investigate the source IP address from the Windows logs to determine if it matches the Linux host IP and evaluate if this connection is part of a known and legitimate process. +- Analyze historical data for any previous similar connection attempts from the same Linux host to identify patterns or repeated unauthorized access attempts. +- Consult with system administrators to confirm if there have been any recent changes or updates in the network configuration that could explain the connection attempts. + +### False positive analysis + +- Routine administrative tasks from Linux hosts may trigger alerts. Identify and document these tasks to create exceptions for known IP addresses or hostnames involved in regular operations. +- Automated backup or monitoring systems that connect to Windows hosts using SMB may cause false positives. Review and whitelist these systems by their IP addresses or specific named pipes they access. +- Development or testing environments where Linux hosts frequently interact with Windows systems can generate alerts. Establish a separate monitoring policy or exclude these environments from the rule to reduce noise. +- Security tools or scripts that perform network scans or audits might mimic suspicious behavior. Verify these tools and exclude their activities by specifying their source IPs or associated user accounts. +- Cross-platform file sharing services that use SMB for legitimate purposes may be flagged. Identify these services and adjust the rule to ignore their specific connection patterns or named pipes. + +### Response and remediation + +- Isolate the affected Linux host from the network to prevent further unauthorized SMB connection attempts and potential credential capture. +- Conduct a thorough review of the Linux host's network activity logs to identify any unauthorized access or data exfiltration attempts. +- Reset passwords for any accounts that may have been exposed or compromised during the forced authentication attempt to mitigate the risk of credential misuse. +- Implement network segmentation to limit SMB traffic between Linux and Windows hosts, reducing the attack surface for similar threats. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional hosts or systems are affected. +- Deploy enhanced monitoring on the identified named pipes and associated network traffic to detect and respond to future forced authentication attempts promptly. +- Review and update firewall rules to restrict unnecessary SMB traffic and ensure only authorized systems can communicate over port 445.""" [[rule.threat]] diff --git a/rules/cross-platform/defense_evasion_agent_spoofing_mismatched_id.toml b/rules/cross-platform/defense_evasion_agent_spoofing_mismatched_id.toml index 0387b769dc3..c7671e0e134 100644 --- a/rules/cross-platform/defense_evasion_agent_spoofing_mismatched_id.toml +++ b/rules/cross-platform/defense_evasion_agent_spoofing_mismatched_id.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2021/07/14" maturity = "production" -updated_date = "2024/05/31" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -31,6 +31,41 @@ type = "query" query = ''' event.agent_id_status:(agent_id_mismatch or mismatch) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Agent Spoofing - Mismatched Agent ID + +In security environments, agent IDs uniquely identify software agents that report events. Adversaries may spoof these IDs to disguise unauthorized activities, evading detection systems. The detection rule identifies discrepancies between expected and actual agent IDs, flagging potential spoofing attempts. By monitoring for mismatches, it helps uncover efforts to masquerade malicious actions as legitimate. + +### Possible investigation steps + +- Review the event logs to identify the specific events where the agent_id_status is marked as "agent_id_mismatch" or "mismatch" to understand the scope and frequency of the issue. +- Correlate the mismatched agent IDs with the associated API keys to determine if there are any patterns or commonalities that could indicate a targeted spoofing attempt. +- Investigate the source IP addresses and user accounts associated with the mismatched events to identify any unauthorized access or suspicious activity. +- Check for any recent changes or anomalies in the configuration or deployment of agents that could explain the mismatches, such as updates or reassignments. +- Analyze historical data to determine if similar mismatches have occurred in the past and whether they were resolved or linked to known issues or threats. +- Consult with the IT or security team to verify if there are any legitimate reasons for the agent ID discrepancies, such as testing or maintenance activities. + +### False positive analysis + +- Legitimate software updates or patches may temporarily cause agent ID mismatches. Users should verify if the mismatches coincide with scheduled updates and consider excluding these events if confirmed. +- Network configuration changes, such as IP address reassignments, can lead to mismatches. Ensure that network changes are documented and correlate with the mismatched events before excluding them. +- Virtual machine snapshots or clones might result in duplicate agent IDs. Users should track virtual machine activities and exclude events from known snapshot or cloning operations. +- Load balancing or failover processes in high-availability environments can cause agent ID discrepancies. Review the infrastructure setup and exclude events that align with these processes. +- Testing environments often simulate various agent activities, leading to mismatches. Clearly separate test environments from production in monitoring systems and exclude test-related events. + +### Response and remediation + +- Immediately isolate the affected systems to prevent further unauthorized access or data exfiltration. This can be done by disconnecting the system from the network or using network segmentation techniques. +- Conduct a thorough review of the logs and events associated with the mismatched agent ID to identify any unauthorized changes or activities. Focus on the specific events flagged by the detection rule. +- Revoke and reissue API keys associated with the compromised agent ID to prevent further misuse. Ensure that new keys are distributed securely and only to authorized personnel. +- Implement additional monitoring on the affected systems and related network segments to detect any further attempts at agent ID spoofing or other suspicious activities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat actor has compromised other parts of the network. +- Review and update access controls and authentication mechanisms to ensure that only legitimate agents can report events. Consider implementing multi-factor authentication for added security. +- Document the incident, including all actions taken, and conduct a post-incident review to identify any gaps in detection or response. Use this information to enhance future threat detection and response capabilities.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/cross-platform/defense_evasion_agent_spoofing_multiple_hosts.toml b/rules/cross-platform/defense_evasion_agent_spoofing_multiple_hosts.toml index 0a5ee5c15a7..309dd1326ac 100644 --- a/rules/cross-platform/defense_evasion_agent_spoofing_multiple_hosts.toml +++ b/rules/cross-platform/defense_evasion_agent_spoofing_multiple_hosts.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2021/07/14" maturity = "production" -updated_date = "2024/06/14" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -31,6 +31,40 @@ type = "threshold" query = ''' event.agent_id_status:* and not tags:forwarded ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Agent Spoofing - Multiple Hosts Using Same Agent + +In network environments, agents are deployed on hosts to monitor and report activities. Adversaries may exploit these agents by hijacking their IDs to inject false data, masking malicious actions. The detection rule identifies anomalies where multiple hosts report using the same agent ID, signaling potential spoofing attempts. By focusing on unique agent ID usage, it helps uncover evasion tactics aimed at concealing unauthorized activities. + +### Possible investigation steps + +- Review the alert details to identify the specific agent ID that is being reported by multiple hosts. +- Cross-reference the agent ID with the list of known and authorized agents to determine if it has been compromised or misconfigured. +- Examine the network logs and host activity for each host reporting the same agent ID to identify any unusual or unauthorized activities. +- Check for any recent changes or updates to the agent software on the affected hosts that could explain the anomaly. +- Investigate the timeline of events to determine when the agent ID started being used by multiple hosts and correlate this with any known incidents or changes in the network environment. +- Assess the potential impact of the spoofing attempt on the network's security posture and consider isolating affected hosts if necessary to prevent further malicious activity. + +### False positive analysis + +- Legitimate load balancing or failover scenarios where multiple hosts are configured to use the same agent ID for redundancy can trigger false positives. Users should identify and document these configurations, then create exceptions in the detection rule to exclude these known non-threatening behaviors. +- Virtualized environments where snapshots or clones of a host are created might result in multiple instances reporting the same agent ID. Users should ensure that each virtual instance is assigned a unique agent ID or adjust the rule to account for these scenarios. +- Testing or development environments where agents are intentionally duplicated for testing purposes can also lead to false positives. Users should tag these environments appropriately and modify the rule to exclude events from these tags. +- In cases where agents are temporarily reassigned to different hosts for maintenance or troubleshooting, users should maintain a log of these activities and adjust the detection rule to ignore these temporary changes. + +### Response and remediation + +- Isolate affected hosts immediately to prevent further spread of potentially malicious activities across the network. +- Revoke and reissue new agent IDs for the affected hosts to ensure that compromised IDs are no longer in use. +- Conduct a thorough forensic analysis on the isolated hosts to identify any unauthorized changes or malicious software that may have been introduced. +- Review and update access controls and authentication mechanisms for agent deployment to prevent unauthorized access and hijacking of agent IDs. +- Monitor network traffic and logs closely for any signs of continued spoofing attempts or related suspicious activities. +- Escalate the incident to the security operations center (SOC) and relevant stakeholders to ensure awareness and coordinated response efforts. +- Implement enhanced logging and alerting for agent ID anomalies to improve detection of similar threats in the future.""" [[rule.threat]] diff --git a/rules/cross-platform/defense_evasion_deleting_websvr_access_logs.toml b/rules/cross-platform/defense_evasion_deleting_websvr_access_logs.toml index 27c9ce51e5b..2c42306a998 100644 --- a/rules/cross-platform/defense_evasion_deleting_websvr_access_logs.toml +++ b/rules/cross-platform/defense_evasion_deleting_websvr_access_logs.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/03" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -49,6 +49,40 @@ file where event.type == "deletion" and "/var/log/httpd/access_log", "/var/www/*/logs/access.log") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 WebServer Access Logs Deleted + +Web server access logs are crucial for monitoring and analyzing web traffic, providing insights into user activity and potential security incidents. Adversaries may delete these logs to cover their tracks, hindering forensic investigations. The detection rule identifies log deletions across various operating systems by monitoring specific file paths, signaling potential attempts at evasion or evidence destruction. + +### Possible investigation steps + +- Review the specific file path where the deletion event was detected to determine which web server's logs were affected, using the file.path field from the alert. +- Check for any recent access or modification events on the affected web server to identify potential unauthorized access or suspicious activity prior to the log deletion. +- Investigate user accounts and processes that had access to the deleted log files around the time of the deletion event to identify potential malicious actors or compromised accounts. +- Correlate the log deletion event with other security alerts or anomalies in the same timeframe to identify patterns or related incidents. +- Examine backup logs or alternative logging mechanisms, if available, to recover deleted information and assess the impact of the log deletion on forensic capabilities. + +### False positive analysis + +- Routine log rotation or maintenance scripts may delete old web server logs. To handle this, identify and exclude these scheduled tasks from triggering alerts by specifying their execution times or associated process names. +- Automated backup processes that move or delete logs after archiving can trigger false positives. Exclude these processes by adding exceptions for the backup software or scripts used. +- Development or testing environments where logs are frequently cleared to reset the environment can cause alerts. Consider excluding these environments by specifying their IP addresses or hostnames. +- System administrators manually deleting logs as part of regular maintenance can be mistaken for malicious activity. Implement a policy to log and approve such actions, and exclude these approved activities from detection. +- Temporary log deletions during server migrations or upgrades might trigger alerts. Document these events and create temporary exceptions during the migration period. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Conduct a thorough review of recent user activity and system changes to identify any unauthorized access or modifications that may have led to the log deletion. +- Restore the deleted web server access logs from backups, if available, to aid in further forensic analysis and investigation. +- Implement enhanced monitoring on the affected system to detect any further attempts at log deletion or other suspicious activities. +- Review and tighten access controls and permissions on log files to ensure only authorized personnel can modify or delete them. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Document the incident, including all actions taken, and update incident response plans to improve future detection and response capabilities.""" [[rule.threat]] diff --git a/rules/cross-platform/defense_evasion_deletion_of_bash_command_line_history.toml b/rules/cross-platform/defense_evasion_deletion_of_bash_command_line_history.toml index d741251924d..4f7ff590fac 100644 --- a/rules/cross-platform/defense_evasion_deletion_of_bash_command_line_history.toml +++ b/rules/cross-platform/defense_evasion_deletion_of_bash_command_line_history.toml @@ -2,7 +2,7 @@ creation_date = "2020/05/04" integration = ["endpoint", "auditd_manager"] maturity = "production" -updated_date = "2024/09/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -54,6 +54,40 @@ process where event.action in ("exec", "exec_event", "executed", "process_starte (process.args : "set" and process.args : "history" and process.args : "+o") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Tampering of Shell Command-Line History + +Shell command-line history is a crucial feature in Unix-like systems, recording user commands for convenience and auditing. Adversaries may manipulate this history to hide their tracks, using commands to delete or redirect history files, clear history buffers, or disable history logging. The detection rule identifies such tampering by monitoring for suspicious command patterns and arguments indicative of history manipulation attempts. + +### Possible investigation steps + +- Review the process execution details to identify the user account associated with the suspicious command, focusing on the process.args field to determine the specific command and arguments used. +- Check the process execution timeline to correlate the suspicious activity with other events on the system, such as logins or file modifications, to understand the context of the tampering attempt. +- Investigate the command history files (.bash_history, .zsh_history) for the affected user accounts to assess the extent of tampering and identify any commands that may have been executed prior to the history manipulation. +- Examine system logs and audit records for any additional indicators of compromise or related suspicious activities, such as unauthorized access attempts or privilege escalation events. +- Verify the current configuration of the HISTFILE and HISTFILESIZE environment variables for the affected user accounts to ensure they have not been altered to disable history logging. + +### False positive analysis + +- System administrators or automated scripts may clear command-line history as part of routine maintenance or privacy measures. To handle this, identify and whitelist known scripts or user accounts that perform these actions regularly. +- Developers or power users might redirect or unset history files to manage disk space or for personal preference. Consider excluding specific user accounts or directories from monitoring if these actions are verified as non-malicious. +- Security tools or compliance scripts may execute commands that resemble history tampering to ensure systems are in a desired state. Review and exclude these tools from triggering alerts by adding them to an exception list. +- Temporary testing environments or sandboxed systems might frequently clear history as part of their reset processes. Exclude these environments from the rule to prevent unnecessary alerts. +- Users with privacy concerns might intentionally disable history logging. Engage with these users to understand their needs and adjust monitoring policies accordingly, possibly by excluding their sessions from the rule. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further tampering or data exfiltration. +- Conduct a thorough review of the affected user's recent command history and system logs to identify any unauthorized or suspicious activities that may have occurred prior to the tampering. +- Restore the tampered history files from a secure backup, if available, to aid in further forensic analysis and ensure continuity of auditing. +- Re-enable and secure shell history logging by resetting the HISTFILE and HISTFILESIZE environment variables to their default values and ensuring they are not set to null or zero. +- Implement stricter access controls and monitoring on the affected system to prevent unauthorized users from modifying shell history files in the future. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may have been compromised. +- Review and update endpoint detection and response (EDR) configurations to enhance monitoring for similar tampering attempts, ensuring alerts are generated for any future suspicious command patterns.""" [[rule.threat]] diff --git a/rules/cross-platform/defense_evasion_elastic_agent_service_terminated.toml b/rules/cross-platform/defense_evasion_elastic_agent_service_terminated.toml index 655695f3cae..9bd55b5a8e5 100644 --- a/rules/cross-platform/defense_evasion_elastic_agent_service_terminated.toml +++ b/rules/cross-platform/defense_evasion_elastic_agent_service_terminated.toml @@ -2,7 +2,7 @@ creation_date = "2022/05/23" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/18" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -61,6 +61,41 @@ or process.args : "com.apple.iokit.EndpointSecurity" and event.action : "end")) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Elastic Agent Service Terminated + +The Elastic Agent is a crucial component for monitoring and securing endpoints across various operating systems. It ensures continuous security oversight by collecting and analyzing data. Adversaries may attempt to disable this agent to evade detection, compromising system defenses. The detection rule identifies suspicious termination activities by monitoring specific processes and commands across Windows, Linux, and macOS, flagging potential defense evasion attempts. + +### Possible investigation steps + +- Review the event logs to identify the exact process and command used to terminate the Elastic Agent, focusing on the process names and arguments such as "net.exe", "sc.exe", "systemctl", and "pkill" with arguments like "stop", "uninstall", or "disable". +- Check the timeline of events around the termination to identify any preceding suspicious activities or anomalies that might indicate an adversary's presence or actions. +- Investigate the user account associated with the process termination to determine if it was authorized or if there are signs of account compromise. +- Examine the host for any other signs of tampering or compromise, such as unauthorized changes to system configurations or the presence of other malicious processes. +- Verify the current status of the Elastic Agent on the affected host and attempt to restart it if it is not running, ensuring that security monitoring is restored. +- Correlate this event with other alerts or logs from the same host or network to identify potential patterns or coordinated attack activities. + +### False positive analysis + +- Routine maintenance activities may trigger the rule if administrators use commands like systemctl or service to stop the Elastic Agent for updates or configuration changes. To manage this, create exceptions for known maintenance windows or authorized personnel. +- Automated scripts or deployment tools that temporarily disable the Elastic Agent during software installations or updates can cause false positives. Identify these scripts and whitelist their execution paths or specific arguments. +- Testing environments where Elastic Agent is frequently started and stopped for development purposes might generate alerts. Exclude these environments by specifying their hostnames or IP addresses in the rule exceptions. +- Security tools or processes that interact with the Elastic Agent, such as backup solutions or system monitoring tools, might inadvertently stop the service. Review these interactions and adjust the rule to ignore specific process names or arguments associated with these tools. +- User-initiated actions, such as troubleshooting or system performance optimization, may involve stopping the Elastic Agent. Educate users on the impact of these actions and establish a protocol for notifying the security team when such actions are necessary. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or potential lateral movement by adversaries. +- Verify the status of the Elastic Agent on the affected host and attempt to restart the service. If the service fails to restart, investigate potential causes such as corrupted files or missing dependencies. +- Conduct a thorough review of recent process execution logs on the affected host to identify any unauthorized or suspicious activities that may have led to the termination of the Elastic Agent. +- If malicious activity is confirmed, perform a comprehensive malware scan and remove any identified threats. Ensure that the host is clean before reconnecting it to the network. +- Review and update endpoint security configurations to prevent unauthorized termination of security services. This may include implementing stricter access controls or using application whitelisting. +- Escalate the incident to the security operations team for further analysis and to determine if additional hosts are affected or if there is a broader security incident underway. +- Document the incident, including all actions taken and findings, to enhance future response efforts and update incident response plans as necessary.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/cross-platform/defense_evasion_encoding_rot13_python_script.toml b/rules/cross-platform/defense_evasion_encoding_rot13_python_script.toml index 81c67c2d202..12f23a5ee47 100644 --- a/rules/cross-platform/defense_evasion_encoding_rot13_python_script.toml +++ b/rules/cross-platform/defense_evasion_encoding_rot13_python_script.toml @@ -2,7 +2,7 @@ creation_date = "2024/09/17" integration = ["endpoint"] maturity = "production" -updated_date = "2024/09/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -38,6 +38,40 @@ sequence by process.entity_id with maxspan=1m [file where host.os.type in ("windows", "macos") and event.action != "deletion" and process.name : "python*" and file.name : "rot_??.cpython-*.pyc*"] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 ROT Encoded Python Script Execution + +ROT encoding, a simple letter substitution cipher, is often used to obfuscate Python scripts, making them harder to analyze. Adversaries exploit this by embedding ROT-encoded scripts within legitimate packages to evade detection. The detection rule identifies such activities by monitoring Python script executions and the presence of ROT-encoded compiled files, flagging potential misuse on Windows and macOS systems. + +### Possible investigation steps + +- Review the process entity ID to identify the specific Python process that triggered the alert and gather details such as the process start time and command line arguments. +- Examine the file path and name of the ROT-encoded compiled file (e.g., "rot_??.cpython-*.pyc") to determine its origin and whether it is part of a legitimate package or potentially malicious. +- Check the parent process of the Python script to understand how it was initiated and whether it was executed by a legitimate application or user. +- Investigate the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Analyze any network connections or file modifications made by the Python process to identify potential data exfiltration or further malicious activity. +- Correlate this alert with other security events or logs from the same host to identify patterns or additional indicators of compromise. + +### False positive analysis + +- Legitimate development activities may trigger the rule if developers use ROT encoding for testing or educational purposes. To manage this, create exceptions for known development environments or specific user accounts involved in such activities. +- Automated scripts or tools that use ROT encoding for legitimate data processing tasks can be flagged. Identify these scripts and whitelist their execution paths or associated process names to prevent false alerts. +- Some security tools or software may use ROT encoding as part of their normal operations. Review and document these tools, then configure the detection system to exclude their known file paths or process identifiers. +- Regularly scheduled tasks or cron jobs that involve ROT-encoded files for non-malicious purposes can cause false positives. Exclude these tasks by specifying their unique identifiers or execution schedules in the detection rule settings. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of potentially malicious activity. +- Terminate any running Python processes that are identified as executing ROT-encoded scripts to halt the execution of obfuscated code. +- Conduct a thorough review of the affected system to identify and remove any ROT-encoded Python files, specifically targeting files matching the pattern "rot_??.cpython-*.pyc*". +- Restore any affected systems from a known good backup to ensure the removal of any persistent threats. +- Implement application whitelisting to prevent unauthorized Python scripts from executing, focusing on blocking scripts with ROT encoding patterns. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected. +- Update detection mechanisms to monitor for similar ROT-encoded script activities, enhancing the ability to detect and respond to future threats.""" [[rule.threat]] diff --git a/rules/cross-platform/defense_evasion_masquerading_space_after_filename.toml b/rules/cross-platform/defense_evasion_masquerading_space_after_filename.toml index 4b46332364f..ba427f0d623 100644 --- a/rules/cross-platform/defense_evasion_masquerading_space_after_filename.toml +++ b/rules/cross-platform/defense_evasion_masquerading_space_after_filename.toml @@ -2,7 +2,7 @@ creation_date = "2022/10/18" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/18" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -52,6 +52,40 @@ process.executable regex~ """/[a-z0-9\s_\-\\./]+\s""" and not ( ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Masquerading Space After Filename + +In Linux and macOS environments, file execution is determined by the file's true type rather than its extension. Adversaries exploit this by appending a space to filenames, misleading users into executing malicious files disguised as benign. The detection rule identifies such anomalies by monitoring process creation events with filenames ending in a space, excluding known safe processes and paths, thus highlighting potential masquerading attempts. + +### Possible investigation steps + +- Review the process creation event details to identify the full path and name of the executable with a space appended. This can help determine if the file is located in a suspicious or unusual directory. +- Check the process.parent.args field to understand the parent process that initiated the execution. This can provide context on whether the execution was part of a legitimate process chain or potentially malicious activity. +- Investigate the user account associated with the process creation event to determine if the account has a history of executing similar files or if it has been compromised. +- Examine the file's true type and hash to verify its legitimacy and check against known malicious file databases or threat intelligence sources. +- Look for any additional process events or network activity associated with the suspicious executable to identify potential lateral movement or data exfiltration attempts. +- Cross-reference the event with any recent alerts or incidents involving the same host or user to identify patterns or ongoing threats. + +### False positive analysis + +- Processes like "ls", "find", "grep", and "xkbcomp" are known to be safe and can be excluded from triggering the rule by adding them to the exception list. +- Executables located in directories such as "/opt/nessus_agent/*", "/opt/gitlab/sv/gitlab-exporter/*", and "/tmp/ansible-admin/*" are typically non-threatening and should be excluded to prevent false positives. +- Parent processes with arguments like "./check_rubrik", "/usr/bin/check_mk_agent", "/etc/rubrik/start_stop_bootstrap.sh", and "/etc/rubrik/start_stop_agent.sh" are generally safe and can be added to the exclusion list to avoid unnecessary alerts. +- Regularly review and update the exception list to ensure that only verified safe processes and paths are excluded, maintaining the effectiveness of the detection rule. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further execution or spread of the potentially malicious file. +- Terminate any suspicious processes identified by the detection rule to halt any ongoing malicious activity. +- Conduct a forensic analysis of the file with the appended space to determine its true file type and origin, using tools like file command or hex editors. +- Remove the malicious file from the system and any other locations it may have been copied to, ensuring complete eradication. +- Review and update endpoint protection settings to block execution of files with suspicious naming conventions, such as those ending with a space. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess potential impacts on other systems. +- Implement additional monitoring for similar masquerading attempts by enhancing logging and alerting mechanisms to detect files with unusual naming patterns.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/cross-platform/defense_evasion_timestomp_touch.toml b/rules/cross-platform/defense_evasion_timestomp_touch.toml index 36d4a8ca911..c38092ddf24 100644 --- a/rules/cross-platform/defense_evasion_timestomp_touch.toml +++ b/rules/cross-platform/defense_evasion_timestomp_touch.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/03" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -46,6 +46,39 @@ process where event.type == "start" and "/usr/lib/go-*/bin/go", "/usr/lib/dracut/dracut-functions.sh", "/tmp/KSInstallAction.*/m/.patch/*" ) and not process.parent.name in ("pmlogger_daily", "pmlogger_janitor", "systemd") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Timestomping using Touch Command + +Timestomping is a technique used by adversaries to alter file timestamps, making malicious files blend with legitimate ones. The 'touch' command, prevalent in Linux and macOS, can modify access and modification times. Attackers exploit this to evade detection. The detection rule identifies suspicious 'touch' usage by non-root users, focusing on specific arguments and excluding benign processes, thus highlighting potential timestomping activities. + +### Possible investigation steps + +- Review the process details to identify the user who executed the 'touch' command, focusing on the user.id field to determine if the user is legitimate and authorized to perform such actions. +- Examine the process.args field to understand the specific arguments used with the 'touch' command, particularly looking for the use of "-r", "-t", "-a*", or "-m*" which indicate potential timestomping activity. +- Investigate the parent process of the 'touch' command by checking the process.parent.name field to determine if it was initiated by a suspicious or unexpected process, excluding known benign processes like "pmlogger_daily", "pmlogger_janitor", and "systemd". +- Cross-reference the file paths and names involved in the 'touch' command with known system files and directories to assess if the files are legitimate or potentially malicious. +- Check for any recent alerts or logs related to the same user or process to identify patterns or repeated attempts at timestomping or other suspicious activities. + +### False positive analysis + +- Non-root users running legitimate scripts or applications that use the touch command with similar arguments may trigger false positives. To mitigate this, identify and whitelist these specific scripts or applications by adding their paths to the exclusion list. +- Automated system maintenance tasks that involve file timestamp modifications can be mistaken for malicious activity. Review and exclude known maintenance processes by adding them to the exclusion criteria, ensuring they do not match the suspicious argument patterns. +- Development tools or environments that utilize the touch command for file management during build processes might be flagged. Analyze these tools and exclude their typical usage patterns by specifying their paths or parent processes in the exclusion list. +- User-initiated file management activities, such as organizing or backing up files, can inadvertently match the rule's criteria. Educate users on the implications of using touch with specific arguments and consider excluding common user directories from the rule if they are frequently involved in such activities. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity and potential lateral movement by the attacker. +- Conduct a thorough review of the affected system's file system to identify and document any files with suspicious timestamp modifications, focusing on those altered by non-root users. +- Restore any critical files with altered timestamps from known good backups to ensure data integrity and system reliability. +- Revoke or reset credentials for any non-root users involved in the suspicious 'touch' command activity to prevent unauthorized access. +- 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 enhanced monitoring on the affected system and similar environments to detect any further attempts at timestomping or related suspicious activities. +- Review and update access controls and permissions to ensure that only authorized users have the ability to modify file timestamps, reducing the risk of future timestomping attempts.""" [[rule.threat]] diff --git a/rules/cross-platform/discovery_virtual_machine_fingerprinting_grep.toml b/rules/cross-platform/discovery_virtual_machine_fingerprinting_grep.toml index 2ef727a4d0a..1cc57c63f10 100644 --- a/rules/cross-platform/discovery_virtual_machine_fingerprinting_grep.toml +++ b/rules/cross-platform/discovery_virtual_machine_fingerprinting_grep.toml @@ -2,7 +2,7 @@ creation_date = "2021/09/29" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -51,6 +51,39 @@ process where event.type == "start" and process.args : ("parallels*", "vmware*", "virtualbox*") and process.args : "Manufacturer*" and not process.parent.executable in ("/Applications/Docker.app/Contents/MacOS/Docker", "/usr/libexec/kcare/virt-what") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Virtual Machine Fingerprinting via Grep + +Virtual machine fingerprinting involves identifying virtualized environments by querying system details. Adversaries exploit tools like `grep` to extract information about virtual machine hardware, aiding in evasion or targeting. The detection rule identifies non-root users executing `grep` with arguments linked to virtual machine identifiers, flagging potential reconnaissance activities while excluding benign processes. + +### Possible investigation steps + +- Review the process execution details to confirm the non-root user who initiated the `grep` or `egrep` command and assess their typical behavior and access rights. +- Examine the command-line arguments used with `grep` to identify specific virtual machine identifiers such as "parallels", "vmware", or "virtualbox" and determine if these align with known reconnaissance patterns. +- Investigate the parent process of the `grep` command to understand the context in which it was executed, ensuring it is not a benign process like Docker or kcare. +- Check for any additional suspicious activities or commands executed by the same user around the same time to identify potential lateral movement or further reconnaissance. +- Correlate this event with other security alerts or logs to determine if it is part of a broader attack pattern or campaign, particularly looking for connections to known malware like Pupy RAT. + +### False positive analysis + +- Non-root users running legitimate scripts or applications that query virtual machine identifiers for system management or inventory purposes may trigger the rule. To handle this, identify and whitelist these specific scripts or applications by excluding their parent executable paths. +- Developers or IT personnel using grep to troubleshoot or gather system information on virtual machines might be flagged. Create exceptions for known user accounts or specific directories where these activities are expected. +- Automated monitoring tools that check virtual machine environments for compliance or performance metrics could cause false positives. Exclude these tools by adding their process names or parent executables to the exception list. +- Some virtualization management software might use grep internally to gather system information. Identify these applications and exclude their processes to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further reconnaissance or data exfiltration by the adversary. +- Terminate any suspicious processes identified by the alert, specifically those involving `grep` or `egrep` with arguments related to virtual machine identifiers. +- Conduct a thorough review of the affected system's user accounts and permissions, focusing on non-root users, to identify any unauthorized access or privilege escalation. +- Analyze system logs and network traffic for any signs of lateral movement or additional compromise, paying close attention to connections initiated by the affected system. +- Restore the system from a known good backup if any unauthorized changes or malware are detected, ensuring that the backup is free from compromise. +- Implement stricter access controls and monitoring for systems running virtual machines, including enhanced logging and alerting for similar reconnaissance activities. +- Escalate the incident to the security operations team for further investigation and to determine if the activity is part of a larger attack campaign.""" [[rule.threat]] diff --git a/rules/cross-platform/execution_aws_ssm_sendcommand_with_command_parameters.toml b/rules/cross-platform/execution_aws_ssm_sendcommand_with_command_parameters.toml index ee87869d33c..21b713c7133 100644 --- a/rules/cross-platform/execution_aws_ssm_sendcommand_with_command_parameters.toml +++ b/rules/cross-platform/execution_aws_ssm_sendcommand_with_command_parameters.toml @@ -2,7 +2,7 @@ creation_date = "2022/09/03" integration = ["endpoint", "auditd_manager"] maturity = "production" -updated_date = "2024/11/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -86,6 +86,41 @@ and process.args: ( and ("AWS-RunShellScript" or "AWS-RunPowerShellScript") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS SSM `SendCommand` with Run Shell Command Parameters + +AWS Systems Manager (SSM) allows remote command execution on EC2 instances via the `SendCommand` API, using scripts like `AWS-RunShellScript` or `AWS-RunPowerShellScript`. Adversaries may exploit this to execute unauthorized commands without direct access. The detection rule identifies unusual command executions by monitoring process activities, flagging first-time occurrences within a week to spot potential threats. + +### Possible investigation steps + +- Review the alert details to identify the specific EC2 instance and the user account associated with the `SendCommand` API call. +- Check the AWS CloudTrail logs for the `SendCommand` event to gather additional context, such as the source IP address, user agent, and any associated IAM roles or policies. +- Investigate the command parameters used in the `SendCommand` API call, focusing on the `commands` field to determine the nature and intent of the executed script. +- Examine the process execution history on the affected host to identify any unusual or unauthorized processes that may have been initiated as a result of the command. +- Assess the recent activity of the user account involved in the alert to identify any other suspicious actions or deviations from normal behavior. +- Verify the integrity and security posture of the affected EC2 instance, checking for any signs of compromise or unauthorized changes. + +### False positive analysis + +- Routine administrative tasks using AWS SSM SendCommand may trigger alerts. Identify and document regular maintenance scripts and exclude them from detection to reduce noise. +- Automated deployment processes often use AWS-RunShellScript or AWS-RunPowerShellScript. Review deployment logs and whitelist these processes if they are verified as non-threatening. +- Monitoring or compliance checks that utilize SSM for gathering system information can be mistaken for malicious activity. Confirm these activities with the relevant teams and create exceptions for known benign operations. +- Scheduled tasks or cron jobs that execute commands via SSM should be reviewed. If they are part of standard operations, consider excluding them from the rule to prevent false positives. +- Development and testing environments frequently use SSM for testing scripts. Ensure these environments are well-documented and apply exceptions to avoid unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected EC2 instance from the network to prevent further unauthorized command execution and potential lateral movement. +- Review the AWS CloudTrail logs to identify the source of the `SendCommand` API call, including the IAM user or role that initiated the command, and assess whether the access was legitimate or compromised. +- Revoke or rotate the credentials of the IAM user or role involved in the suspicious activity to prevent further unauthorized access. +- Conduct a thorough examination of the affected EC2 instance to identify any unauthorized changes or installed malware, and restore the instance from a known good backup if necessary. +- Implement stricter IAM policies and permissions to limit the use of the `SendCommand` API to only trusted users and roles, ensuring the principle of least privilege is enforced. +- Enable multi-factor authentication (MFA) for all IAM users with permissions to execute commands on EC2 instances to add an additional layer of security. +- Escalate the incident to the security operations team for further investigation and to determine if additional instances or resources have been compromised.""" [rule.investigation_fields] field_names = [ diff --git a/rules/cross-platform/execution_pentest_eggshell_remote_admin_tool.toml b/rules/cross-platform/execution_pentest_eggshell_remote_admin_tool.toml index f97739824da..984a176abde 100644 --- a/rules/cross-platform/execution_pentest_eggshell_remote_admin_tool.toml +++ b/rules/cross-platform/execution_pentest_eggshell_remote_admin_tool.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/12" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -30,6 +30,40 @@ type = "query" query = ''' event.category:process and event.type:(process_started or start) and process.name:espl and process.args:eyJkZWJ1ZyI6* ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 EggShell Backdoor Execution + +EggShell is a post-exploitation tool used on macOS and Linux systems, allowing adversaries to execute commands and scripts remotely. It leverages command and scripting interpreters to gain control over compromised systems. Attackers exploit this by executing malicious payloads, maintaining persistence, and exfiltrating data. The detection rule identifies suspicious process activities, specifically targeting the execution patterns and arguments associated with EggShell, to alert analysts of potential backdoor usage. + +### Possible investigation steps + +- Review the alert details to confirm the presence of the process name 'espl' and check if the process arguments start with 'eyJkZWJ1ZyI6', which indicates potential EggShell activity. +- Investigate the parent process of 'espl' to understand how it was initiated and identify any associated suspicious activities or processes. +- Examine the user account under which the 'espl' process was executed to determine if it aligns with expected behavior or if it indicates a compromised account. +- Check for any network connections or data exfiltration attempts associated with the 'espl' process to assess if data has been sent to an external source. +- Review system logs and other security alerts around the time of the 'espl' process execution to identify any correlated events or anomalies. +- Assess the persistence mechanisms on the affected system to determine if the EggShell backdoor has established any means to survive reboots or user logouts. + +### False positive analysis + +- Legitimate administrative scripts or tools that use similar command patterns to EggShell may trigger false positives. Review the process arguments and context to determine if the activity is expected and authorized. +- Development or testing environments where EggShell or similar tools are used for legitimate purposes can cause alerts. Implement exceptions for these environments by excluding specific user accounts or process paths. +- Automated scripts or monitoring tools that mimic EggShell's execution patterns might be flagged. Identify these scripts and create exceptions based on their unique identifiers or execution context. +- Regularly update the detection rule to refine the criteria based on observed false positives, ensuring that legitimate activities are not continuously flagged. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further command execution and data exfiltration. +- Terminate any suspicious processes associated with the EggShell backdoor, specifically those matching the process name 'espl' and arguments starting with 'eyJkZWJ1ZyI6'. +- Conduct a thorough examination of the system to identify any additional malicious payloads or persistence mechanisms that may have been deployed by the attacker. +- Remove any unauthorized user accounts or access credentials that may have been created or compromised during the exploitation. +- Restore the system from a known good backup to ensure all traces of the backdoor and any associated malware are eradicated. +- Update and patch all software and systems to close any vulnerabilities that may have been exploited by the attacker. +- Enhance monitoring and detection capabilities to identify similar threats in the future, focusing on command and scripting interpreter activities as outlined in MITRE ATT&CK technique T1059.""" [[rule.threat]] diff --git a/rules/cross-platform/execution_potential_widespread_malware_infection.toml b/rules/cross-platform/execution_potential_widespread_malware_infection.toml index 99d34658172..0654843e9bf 100644 --- a/rules/cross-platform/execution_potential_widespread_malware_infection.toml +++ b/rules/cross-platform/execution_potential_widespread_malware_infection.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2024/05/08" maturity = "production" -updated_date = "2024/10/09" +updated_date = "2025/01/10" min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully" min_stack_version = "8.13.0" @@ -38,6 +38,41 @@ from logs-endpoint.alerts-* | stats hosts = count_distinct(host.id) by rule.name, event.code | where hosts >= 3 ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Widespread Malware Infection Across Multiple Hosts + +Endpoint security technologies monitor and analyze activities on devices to detect malicious behavior. Adversaries exploit these systems by deploying malware that triggers specific signatures across multiple hosts, indicating a coordinated attack. The detection rule identifies such threats by analyzing alert data for specific malware signatures across several hosts, flagging potential widespread infections for prioritized investigation. + +### Possible investigation steps + +- Review the alert details to identify the specific rule.name and event.code that triggered the alert, focusing on those with a high count of distinct host.id values. +- Correlate the identified rule.name with known malware signatures or recent threat intelligence reports to understand the potential impact and behavior of the malware. +- Examine the affected host.id entries to determine if there are any commonalities, such as shared network segments, user accounts, or software versions, that could indicate the initial infection vector. +- Investigate the timeline of events for each affected host to identify any suspicious activities or anomalies preceding the alert, such as unusual file downloads or execution of unknown processes. +- Check for any additional alerts or logs related to the same host.id entries to assess if there are other indicators of compromise or related malicious activities. +- Coordinate with IT and security teams to isolate affected hosts if necessary, and initiate containment and remediation procedures based on the findings. + +### False positive analysis + +- Legitimate software updates or installations may trigger malware signatures, especially if they involve new or uncommon software. Users can create exceptions for known software update processes to prevent these alerts from being flagged as potential threats. +- Security testing tools or penetration testing activities might mimic malware behavior, leading to false positives. Analysts should coordinate with IT and security teams to whitelist these activities during scheduled tests. +- Custom scripts or administrative tools that perform automated tasks across multiple hosts can be mistaken for malicious activity. Identifying and excluding these scripts from the rule can reduce unnecessary alerts. +- Frequent use of remote management tools that execute scripts or commands on multiple hosts may trigger alerts. Users should ensure these tools are recognized and excluded from the rule to avoid false positives. +- Known benign applications that use shellcode or memory manipulation techniques for legitimate purposes should be reviewed and added to an exception list to prevent them from being flagged. + +### Response and remediation + +- Isolate affected hosts immediately to prevent further spread of the malware across the network. This can be done by disconnecting them from the network or using network segmentation techniques. +- Conduct a thorough scan of the isolated hosts using updated antivirus or endpoint detection and response (EDR) tools to identify and remove the malicious files or processes associated with the detected signatures. +- Analyze the identified malware to understand its behavior and entry points. This will help in determining if additional hosts may be compromised and require similar remediation actions. +- Apply security patches and updates to all affected systems to close any vulnerabilities that the malware may have exploited. +- Restore affected systems from clean backups if the malware has caused significant damage or if the integrity of the system cannot be assured after cleaning. +- Monitor network traffic and endpoint activities closely for any signs of persistence or re-infection, using enhanced detection rules and updated threat intelligence feeds. +- Escalate the incident to the appropriate internal or external cybersecurity teams if the infection appears to be part of a larger coordinated attack, ensuring that all relevant data and findings are shared for further investigation and response.""" [[rule.threat]] diff --git a/rules/cross-platform/execution_suspicious_java_netcon_childproc.toml b/rules/cross-platform/execution_suspicious_java_netcon_childproc.toml index 877e4ced8fd..95e7b4b9534 100644 --- a/rules/cross-platform/execution_suspicious_java_netcon_childproc.toml +++ b/rules/cross-platform/execution_suspicious_java_netcon_childproc.toml @@ -2,7 +2,7 @@ creation_date = "2021/12/10" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -64,6 +64,39 @@ sequence by host.id with maxspan=1m "php*", "wget")] by process.parent.pid ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 JAVA/JNDI Exploitation Attempt + +Java Naming and Directory Interface (JNDI) is a Java API that provides naming and directory functionality, allowing Java applications to discover and look up data and resources via a directory service. Adversaries exploit JNDI by injecting malicious payloads that trigger outbound connections to LDAP, RMI, or DNS services, potentially leading to remote code execution. The detection rule identifies such exploitation attempts by monitoring Java processes making suspicious outbound connections followed by the execution of potentially harmful child processes, such as shell scripts or scripting languages, indicating a possible compromise. + +### Possible investigation steps + +- Review the network logs to confirm the outbound connection attempt by the Java process to the specified ports (1389, 389, 1099, 53, 5353) and identify the destination IP addresses to determine if they are known malicious or suspicious entities. +- Examine the process tree to verify the parent-child relationship between the Java process and any suspicious child processes such as shell scripts or scripting languages (e.g., sh, bash, curl, python). +- Check the command line arguments and environment variables of the suspicious child processes to identify any potentially malicious payloads or commands being executed. +- Investigate the host's recent activity and logs for any other indicators of compromise or unusual behavior that might correlate with the suspected exploitation attempt. +- Assess the system for any unauthorized changes or new files that may have been introduced as a result of the exploitation attempt, focusing on directories commonly used by Java applications. + +### False positive analysis + +- Development and testing environments may trigger false positives when developers use Java applications to test connections to LDAP, RMI, or DNS services. To mitigate this, exclude known development servers or IP ranges from the detection rule. +- Automated scripts or maintenance tasks that involve Java applications making legitimate outbound connections to the specified ports can be mistaken for exploitation attempts. Identify and whitelist these scripts or tasks by their process names or hashes. +- Legitimate Java-based applications that require frequent updates or data retrieval from external services might generate similar network patterns. Monitor and document these applications, then create exceptions for their specific network behaviors. +- Security tools or monitoring solutions that use Java for network scanning or analysis might inadvertently match the rule's criteria. Ensure these tools are recognized and excluded by their process identifiers or network activity profiles. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further outbound connections and potential lateral movement. +- Terminate any suspicious Java processes identified in the alert, especially those making outbound connections to LDAP, RMI, or DNS ports. +- Conduct a thorough review of the affected system for any unauthorized changes or additional malicious processes, focusing on child processes like shell scripts or scripting languages. +- Restore the affected system from a known good backup if unauthorized changes or malware are detected. +- Update and patch Java and any related applications to the latest versions to mitigate known vulnerabilities. +- Implement network-level controls to block outbound connections to suspicious or unauthorized LDAP, RMI, or DNS services from Java processes. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] diff --git a/rules/cross-platform/guided_onboarding_sample_rule.toml b/rules/cross-platform/guided_onboarding_sample_rule.toml index 90163be7f7e..2006b978127 100644 --- a/rules/cross-platform/guided_onboarding_sample_rule.toml +++ b/rules/cross-platform/guided_onboarding_sample_rule.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2022/09/22" maturity = "production" -updated_date = "2024/12/19" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -20,7 +20,39 @@ language = "kuery" license = "Elastic License v2" max_signals = 1 name = "My First Rule" -note = """This is a test alert. +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 My First Rule +Elastic Security leverages event data to monitor and alert on potential security incidents. The "My First Rule" is a foundational rule designed for onboarding, focusing on event data without indicating a specific threat. Adversaries might exploit event logging to obscure their tracks or trigger false alerts. This rule helps analysts familiarize themselves with event-based alerts, ensuring they can identify and respond to genuine threats effectively. + +### Possible investigation steps + +- Review the event data associated with the alert to understand the context and source of the event.kind:event. +- Check the timestamp of the event to determine when the activity occurred and correlate it with other events around the same time. +- Identify the host or user associated with the event to assess if there is any unusual or unauthorized activity. +- Examine related logs or events from the same source to identify any patterns or anomalies that could indicate suspicious behavior. +- Consult with team members or use internal resources to determine if the event is part of normal operations or if it requires further investigation. + +### False positive analysis + +- Routine system events can trigger alerts, as the rule monitors all event data without filtering for specific threats. +- Identify and document common non-threatening events that frequently trigger alerts, such as regular system updates or scheduled tasks. +- Use exceptions to exclude these documented non-threatening events from triggering alerts, reducing noise and focusing on genuine threats. +- Regularly review and update the list of exceptions to ensure it remains relevant and does not inadvertently exclude new potential threats. +- Collaborate with IT and operations teams to understand normal event patterns and adjust the rule's exceptions accordingly. + +### Response and remediation + +- Verify the legitimacy of the event by cross-referencing with known benign activities or scheduled tasks to rule out false positives. +- Contain any potential threat by isolating affected systems or accounts if suspicious activity is confirmed, preventing further unauthorized access or damage. +- Remediate by reviewing and adjusting logging configurations to ensure accurate event capture and reduce the risk of adversaries exploiting logging mechanisms. +- Escalate the incident to the appropriate security team or management if the event correlates with other suspicious activities or if it indicates a potential breach. +- Enhance detection capabilities by updating alerting rules to include additional context or indicators observed during the investigation, ensuring better identification of similar threats in the future. + +This is a test alert. This alert does not show threat activity. Elastic created this alert to help you understand how alerts work. diff --git a/rules/cross-platform/initial_access_zoom_meeting_with_no_passcode.toml b/rules/cross-platform/initial_access_zoom_meeting_with_no_passcode.toml index c335de8be23..19ec10d0a00 100644 --- a/rules/cross-platform/initial_access_zoom_meeting_with_no_passcode.toml +++ b/rules/cross-platform/initial_access_zoom_meeting_with_no_passcode.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2020/09/14" maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -34,6 +34,40 @@ query = ''' event.type:creation and event.module:zoom and event.dataset:zoom.webhook and event.action:meeting.created and not zoom.meeting.password:* ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Zoom Meeting with no Passcode + +Zoom meetings without passcodes are vulnerable to unauthorized access, known as Zoombombing, where intruders disrupt sessions with inappropriate content. Adversaries exploit this by joining unsecured meetings to cause chaos or gather sensitive information. The detection rule identifies such meetings by monitoring Zoom event logs for sessions created without a passcode, helping to mitigate potential security breaches. + +### Possible investigation steps + +- Review the Zoom event logs to identify the specific meeting details, including the meeting ID and the organizer's information, using the fields event.type, event.module, event.dataset, and event.action. +- Contact the meeting organizer to verify if the meeting was intentionally created without a passcode and understand the context or purpose of the meeting. +- Check for any unusual or unauthorized participants who joined the meeting by examining the participant logs associated with the meeting ID. +- Assess if any sensitive information was discussed or shared during the meeting that could have been exposed to unauthorized participants. +- Evaluate the need to implement additional security measures, such as enabling passcodes for all future meetings or using waiting rooms to control participant access. + +### False positive analysis + +- Internal team meetings may be scheduled without a passcode for convenience, especially if all participants are within a secure network. To handle this, create exceptions for meetings initiated by trusted internal users or within specific IP ranges. +- Recurring meetings with a consistent group of participants might not use passcodes to simplify access. Consider excluding these meetings by identifying and whitelisting their unique meeting IDs. +- Training sessions or webinars intended for a broad audience might be set up without passcodes to ease access. Implement a policy to review and approve such meetings in advance, ensuring they are legitimate and necessary. +- Meetings created by automated systems or bots for integration purposes may not require passcodes. Identify these systems and exclude their meeting creation events from triggering alerts. +- In some cases, meetings may be intentionally left without passcodes for public access, such as community events. Establish a process to verify and document these events, allowing them to be excluded from the rule. + +### Response and remediation + +- Immediately terminate any ongoing Zoom meetings identified without a passcode to prevent further unauthorized access or disruption. +- Notify the meeting host and relevant stakeholders about the security incident, advising them to reschedule the meeting with appropriate security measures, such as enabling a passcode or waiting room. +- Review and update Zoom account settings to enforce mandatory passcodes for all future meetings, ensuring compliance with security policies. +- Conduct a security audit of recent Zoom meetings to identify any other sessions that may have been created without a passcode and take corrective actions as necessary. +- Escalate the incident to the IT security team for further investigation and to assess any potential data breaches or information leaks resulting from the unauthorized access. +- Implement enhanced monitoring and alerting for Zoom meeting creation events to quickly detect and respond to any future instances of meetings being set up without passcodes. +- Coordinate with the communications team to prepare a response plan for any potential public relations issues arising from the incident, ensuring clear and consistent messaging.""" [[rule.threat]] diff --git a/rules/cross-platform/multiple_alerts_different_tactics_host.toml b/rules/cross-platform/multiple_alerts_different_tactics_host.toml index 676a9a892e7..d21057298e0 100644 --- a/rules/cross-platform/multiple_alerts_different_tactics_host.toml +++ b/rules/cross-platform/multiple_alerts_different_tactics_host.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2022/11/16" maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -31,6 +31,41 @@ type = "threshold" query = ''' signal.rule.name:* and kibana.alert.rule.threat.tactic.id:* ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Multiple Alerts in Different ATT&CK Tactics on a Single Host + +The detection rule identifies hosts with alerts across various attack phases, indicating potential compromise. Adversaries exploit system vulnerabilities, moving through different tactics like execution, persistence, and exfiltration. This rule prioritizes hosts with diverse tactic alerts, aiding analysts in focusing on high-risk threats by correlating alert data to detect complex attack patterns. + +### Possible investigation steps + +- Review the alert details to identify the specific host involved and the different ATT&CK tactics that triggered the alerts. +- Examine the timeline of the alerts to understand the sequence of events and determine if there is a pattern or progression in the tactics used. +- Correlate the alert data with other logs and telemetry from the host, such as process creation, network connections, and file modifications, to gather additional context. +- Investigate any known vulnerabilities or misconfigurations on the host that could have been exploited by the adversary. +- Check for any indicators of compromise (IOCs) associated with the alerts, such as suspicious IP addresses, domains, or file hashes, and search for these across the network. +- Assess the impact and scope of the potential compromise by determining if other hosts or systems have similar alerts or related activity. + +### False positive analysis + +- Alerts from routine administrative tasks may trigger multiple tactics. Review and exclude known benign activities such as scheduled software updates or system maintenance. +- Security tools running on the host might generate alerts across different tactics. Identify and exclude alerts from trusted security applications to reduce noise. +- Automated scripts or batch processes can mimic adversarial behavior. Analyze and whitelist these processes if they are verified as non-threatening. +- Frequent alerts from development or testing environments can be misleading. Consider excluding these environments from the rule or applying a different risk score. +- User behavior anomalies, such as accessing multiple systems or applications, might trigger alerts. Implement user behavior baselines to differentiate between normal and suspicious activities. + +### Response and remediation + +- Isolate the affected host from the network immediately to prevent further lateral movement by the adversary. +- Conduct a thorough forensic analysis of the host to identify the specific vulnerabilities exploited and gather evidence of the attack phases involved. +- Remove any identified malicious software or unauthorized access tools from the host, ensuring all persistence mechanisms are eradicated. +- Apply security patches and updates to the host to address any exploited vulnerabilities and prevent similar attacks. +- Restore the host from a known good backup if necessary, ensuring that the backup is free from compromise. +- Monitor the host and network for any signs of re-infection or further suspicious activity, using enhanced logging and alerting based on the identified attack patterns. +- Escalate the incident to the appropriate internal or external cybersecurity teams for further investigation and potential legal action if the attack is part of a larger campaign.""" diff --git a/rules/cross-platform/multiple_alerts_involving_user.toml b/rules/cross-platform/multiple_alerts_involving_user.toml index 076a1096ea5..ae53897aa33 100644 --- a/rules/cross-platform/multiple_alerts_involving_user.toml +++ b/rules/cross-platform/multiple_alerts_involving_user.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2022/11/16" maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -33,6 +33,42 @@ type = "threshold" query = ''' signal.rule.name:* and user.name:* and not user.id:("S-1-5-18" or "S-1-5-19" or "S-1-5-20") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Multiple Alerts Involving a User + +In security environments, monitoring user activity is crucial as adversaries often exploit user accounts to gain unauthorized access. Attackers may trigger multiple alerts by performing suspicious actions under a compromised user account. The detection rule identifies such patterns by correlating diverse alerts linked to the same user, excluding known system accounts, thus prioritizing potential threats for analysts. + +### Possible investigation steps + +- Review the alert details to identify the specific user account involved, focusing on the user.name field to gather initial context about the user. +- Examine the timeline and sequence of the triggered alerts to understand the pattern of activity associated with the user, noting any unusual or unexpected actions. +- Cross-reference the user activity with known legitimate activities or scheduled tasks to rule out false positives, ensuring that the actions are not part of normal operations. +- Investigate the source and destination IP addresses associated with the alerts to identify any suspicious or unauthorized access points. +- Check for any recent changes in user permissions or group memberships that could indicate privilege escalation attempts. +- Look into any recent login attempts or authentication failures for the user account to detect potential brute force or credential stuffing attacks. +- Collaborate with the user or their manager to verify if the activities were authorized or if the account might be compromised. + +### False positive analysis + +- Alerts triggered by automated system processes or scripts that mimic user behavior can be false positives. To manage these, identify and exclude known benign scripts or processes from the rule. +- Frequent alerts from users in roles that inherently require access to multiple systems or sensitive data, such as IT administrators, may not indicate compromise. Implement role-based exceptions to reduce noise. +- Alerts generated by legitimate software updates or maintenance activities can be mistaken for suspicious behavior. Schedule these activities during known maintenance windows and exclude them from the rule during these times. +- Users involved in testing or development environments may trigger multiple alerts due to their work nature. Create exceptions for these environments to prevent unnecessary alerts. +- High-volume users, such as those in customer support or sales, may naturally generate more alerts. Monitor these users separately and adjust the rule to focus on unusual patterns rather than volume alone. + +### Response and remediation + +- Isolate the affected user account immediately to prevent further unauthorized access. Disable the account or change the password to stop any ongoing malicious activity. +- Conduct a thorough review of the affected user's recent activities and access logs to identify any unauthorized actions or data access. This will help in understanding the scope of the compromise. +- Remove any malicious software or unauthorized tools that may have been installed on the user's system. Use endpoint detection and response (EDR) tools to scan and clean the system. +- Restore any altered or deleted data from backups, ensuring that the restored data is free from any malicious modifications. +- Notify relevant stakeholders, including IT security teams and management, about the incident and the steps being taken to address it. This ensures that everyone is aware and can provide support if needed. +- Implement additional monitoring on the affected user account and related systems to detect any further suspicious activities. This includes setting up alerts for unusual login attempts or data access patterns. +- Review and update access controls and permissions for the affected user and similar accounts to prevent future incidents. Ensure that least privilege principles are applied.""" diff --git a/rules/cross-platform/persistence_credential_access_modify_auth_module_or_config.toml b/rules/cross-platform/persistence_credential_access_modify_auth_module_or_config.toml index 85d4432c091..ffb6a09f9be 100644 --- a/rules/cross-platform/persistence_credential_access_modify_auth_module_or_config.toml +++ b/rules/cross-platform/persistence_credential_access_modify_auth_module_or_config.toml @@ -2,7 +2,7 @@ creation_date = "2020/12/21" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -68,6 +68,41 @@ event.category:file and event.type:change and systemd or containerd or pacman ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Modification of Standard Authentication Module or Configuration + +Authentication modules, such as PAM (Pluggable Authentication Modules), are crucial for managing user authentication in Linux and macOS environments. Adversaries may exploit these by altering module files or configurations to gain unauthorized access or escalate privileges. The detection rule identifies suspicious changes to these modules, excluding legitimate processes and paths, to flag potential unauthorized modifications. + +### Possible investigation steps + +- Review the specific file that triggered the alert by examining the file.name and file.path fields to determine if it is a known authentication module or configuration file. +- Investigate the process that made the change by analyzing the process.executable field to identify if it is a legitimate process or potentially malicious. +- Check the process.name field to see if the process is one of the excluded legitimate processes, which might indicate a false positive. +- Look into recent system changes or updates that might have affected authentication modules, focusing on the time frame around the alert. +- Correlate the alert with other security events or logs to identify any related suspicious activities or patterns, such as unauthorized access attempts or privilege escalation. +- Verify the integrity of the affected authentication module or configuration file by comparing it with a known good version or using file integrity monitoring tools. + +### False positive analysis + +- Package management operations such as updates or installations can trigger false positives. Exclude processes like yum, dnf, rpm, and dpkg from the detection rule to prevent these benign activities from being flagged. +- System maintenance tasks often involve legitimate changes to authentication modules. Exclude processes like authconfig, pam-auth-update, and pam-config to avoid false alerts during routine maintenance. +- Development and testing environments may frequently modify authentication modules for testing purposes. Consider excluding paths like /tmp/snap.rootfs_*/pam_*.so and /tmp/newroot/lib/*/pam_*.so to reduce noise from these environments. +- Backup and synchronization tools such as rsync can cause false positives when they interact with authentication module files. Exclude rsync from the detection rule to prevent these non-threatening activities from being flagged. +- Containerized environments may have different paths and processes that interact with authentication modules. Exclude processes like containerd and paths like /tmp/newroot/usr/lib64/security/pam_*.so to account for these variations. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Conduct a thorough review of the modified authentication module or configuration file to identify unauthorized changes and revert them to their original state using a known good backup. +- Reset passwords for all user accounts on the affected system, prioritizing accounts with elevated privileges, to mitigate potential credential compromise. +- Perform a comprehensive scan of the system for additional indicators of compromise, such as unauthorized user accounts or scheduled tasks, and remove any malicious artifacts found. +- 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 enhanced monitoring on the affected system and similar environments to detect any future unauthorized modifications to authentication modules or configurations. +- Review and update access controls and authentication policies to strengthen security measures and reduce the risk of similar attacks in the future.""" [[rule.threat]] diff --git a/rules/cross-platform/persistence_shell_profile_modification.toml b/rules/cross-platform/persistence_shell_profile_modification.toml index 60a1afc60aa..00a694158ac 100644 --- a/rules/cross-platform/persistence_shell_profile_modification.toml +++ b/rules/cross-platform/persistence_shell_profile_modification.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/19" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -49,6 +49,41 @@ event.category:file and event.type:change and /Users/*/.bash_profile or /Users/*/.zshenv) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Bash Shell Profile Modification + +Bash shell profiles, such as `.bash_profile` and `.bashrc`, are scripts that configure user environments upon login. Adversaries exploit these by inserting malicious commands to ensure persistence, executing harmful scripts whenever a user initiates a shell session. The detection rule identifies unauthorized modifications by monitoring file changes and filtering out benign processes, focusing on unusual executables and paths to flag potential threats. + +### Possible investigation steps + +- Review the alert details to identify the specific file path that was modified, focusing on paths like /home/*/.bash_profile or /home/*/.bashrc. +- Examine the process name and executable that triggered the alert to determine if it is an unusual or unauthorized process, as specified in the query. +- Check the modification timestamp of the affected file to correlate with any known user activity or scheduled tasks. +- Investigate the contents of the modified Bash shell profile file to identify any suspicious or unexpected commands or scripts. +- Cross-reference the user account associated with the modified file to determine if the activity aligns with their typical behavior or if the account may be compromised. +- Look for any related alerts or logs around the same timeframe that might indicate a broader attack or persistence mechanism. + +### False positive analysis + +- Frequent use of text editors like vim or nano may trigger alerts when users legitimately modify their shell profiles. To mitigate this, consider excluding these processes from the detection rule if they are commonly used in your environment. +- Automated system updates or configuration management tools like dnf or yum might modify shell profiles as part of their operations. Exclude these processes if they are verified as part of routine maintenance. +- Development tools such as git or platform-python may alter shell profiles during setup or updates. If these tools are regularly used, add them to the exclusion list to prevent false positives. +- User-specific applications located in directories like /Applications or /usr/local may be flagged if they modify shell profiles. Verify these applications and exclude their paths if they are trusted and frequently used. +- Consider excluding specific user directories from monitoring if they are known to contain benign scripts that modify shell profiles, ensuring these exclusions are well-documented and reviewed regularly. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified in the alert that are not part of the allowed list, such as unauthorized executables modifying shell profiles. +- Restore the modified shell profile files (.bash_profile, .bashrc) from a known good backup to remove any malicious entries. +- Conduct a thorough review of user accounts and permissions on the affected system to ensure no unauthorized access or privilege escalation has occurred. +- Implement file integrity monitoring on critical shell profile files to detect and alert on future unauthorized changes. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Review and update endpoint protection policies to enhance detection capabilities for similar persistence techniques, leveraging MITRE ATT&CK framework references for T1546.""" [[rule.threat]] diff --git a/rules/cross-platform/persistence_ssh_authorized_keys_modification.toml b/rules/cross-platform/persistence_ssh_authorized_keys_modification.toml index 71edbff424d..2846a2cfd73 100644 --- a/rules/cross-platform/persistence_ssh_authorized_keys_modification.toml +++ b/rules/cross-platform/persistence_ssh_authorized_keys_modification.toml @@ -2,7 +2,7 @@ creation_date = "2020/12/22" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -50,6 +50,42 @@ event.category:file and event.type:(change or creation) and /usr/bin/chef-client ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Modification + +SSH authorized_keys files are crucial for secure, password-less authentication, allowing users to log into servers using public keys. Adversaries exploit this by adding their keys, ensuring persistent access. The detection rule identifies unauthorized changes to these files, excluding benign processes, to flag potential threats, focusing on persistence and lateral movement tactics. + +### Possible investigation steps + +- Review the alert details to identify the specific file that was modified, focusing on "authorized_keys", "authorized_keys2", "/etc/ssh/sshd_config", or "/root/.ssh". +- Examine the process that triggered the alert by checking the process executable path to ensure it is not one of the benign processes listed in the exclusion criteria. +- Investigate the user account associated with the modification to determine if it is a legitimate user or potentially compromised. +- Check the timestamp of the file modification to correlate with any known user activity or scheduled tasks that might explain the change. +- Analyze recent login attempts and SSH connections to the server to identify any suspicious activity or unauthorized access. +- Review the contents of the modified authorized_keys file to identify any unfamiliar or unauthorized public keys that have been added. +- If unauthorized keys are found, remove them and consider resetting credentials or keys for affected accounts to prevent further unauthorized access. + +### False positive analysis + +- Development tools like git and maven may modify SSH authorized_keys files during legitimate operations. To prevent these from triggering alerts, add their paths to the exclusion list in the detection rule. +- System utilities such as vim and touch are often used by administrators to manually update authorized_keys files. Consider excluding these processes if they are part of regular maintenance activities. +- Automation tools like puppet and chef-client might update SSH configurations as part of their deployment scripts. Verify these changes are expected and exclude these processes if they are part of routine operations. +- Docker-related processes may alter SSH configurations when containers are being managed. If these changes are part of standard container operations, include the relevant paths in the exclusion list. +- Google Guest Agent and JumpCloud Agent might modify SSH settings as part of their management tasks. Confirm these actions are legitimate and exclude these processes if they align with normal system management activities. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement. +- Review the SSH authorized_keys file and remove any unauthorized or suspicious public keys that have been added. +- Change the passwords for all user accounts on the affected host to prevent adversaries from regaining access using compromised credentials. +- Conduct a thorough review of user accounts and permissions on the affected host to identify and disable any unauthorized accounts or privilege escalations. +- Restore the affected system from a known good backup if unauthorized changes are extensive or if the integrity of the system is in question. +- Implement additional monitoring on the affected host and network to detect any further unauthorized access attempts or suspicious activities. +- Escalate the incident to the security operations team for further investigation and to determine if other systems may be affected.""" [[rule.threat]] diff --git a/rules/cross-platform/privilege_escalation_echo_nopasswd_sudoers.toml b/rules/cross-platform/privilege_escalation_echo_nopasswd_sudoers.toml index d6509cbfe32..0645d57187d 100644 --- a/rules/cross-platform/privilege_escalation_echo_nopasswd_sudoers.toml +++ b/rules/cross-platform/privilege_escalation_echo_nopasswd_sudoers.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/26" integration = ["endpoint"] maturity = "production" -updated_date = "2024/09/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -33,6 +33,40 @@ type = "query" query = ''' event.category:process and event.type:start and process.args:(echo and *NOPASSWD*ALL*) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Privilege Escalation via Sudoers File Modification + +The sudoers file is crucial in Unix-like systems, defining user permissions for executing commands with elevated privileges. Adversaries may exploit this by modifying the file to allow unauthorized privilege escalation, often using the NOPASSWD directive to bypass password prompts. The detection rule identifies suspicious process activities, such as attempts to alter sudoers configurations, by monitoring specific command patterns indicative of such exploits. + +### Possible investigation steps + +- Review the alert details to identify the specific process that triggered the alert, focusing on the process.args field to confirm the presence of the *NOPASSWD*ALL* pattern. +- Examine the process execution context, including the user account under which the process was initiated, to determine if it aligns with expected behavior or if it indicates potential misuse. +- Check the system's sudoers file for recent modifications, especially looking for unauthorized entries or changes that include the NOPASSWD directive. +- Investigate the command history of the user associated with the alert to identify any suspicious activities or commands executed around the time of the alert. +- Correlate the event with other logs or alerts from the same host or user to identify any patterns or additional indicators of compromise that might suggest a broader attack. + +### False positive analysis + +- Routine administrative tasks may trigger the rule if administrators frequently update the sudoers file to add legitimate NOPASSWD entries for automation purposes. To manage this, create exceptions for known administrative scripts or processes that are regularly reviewed and approved. +- Configuration management tools like Ansible or Puppet might modify the sudoers file as part of their normal operation. Exclude these tools from triggering alerts by identifying their specific process names or paths and adding them to an exception list. +- Development environments where developers are granted temporary elevated privileges for testing purposes can cause false positives. Implement a policy to log and review these changes separately, ensuring they are reverted after use. +- Automated scripts that require passwordless sudo access for operational efficiency might be flagged. Document these scripts and their usage, and configure the detection system to ignore these specific, well-documented cases. +- System updates or patches that modify sudoers configurations as part of their installation process can be mistaken for malicious activity. Monitor update schedules and correlate them with alerts to identify and exclude these benign changes. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation. +- Review and revert any unauthorized changes to the sudoers file by restoring it from a known good backup or manually correcting the entries to remove any NOPASSWD directives added by the adversary. +- Conduct a thorough audit of user accounts and permissions on the affected system to identify and remove any unauthorized accounts or privilege assignments. +- Reset passwords for all accounts with elevated privileges on the affected system to ensure that compromised credentials cannot be reused. +- Deploy endpoint detection and response (EDR) tools to monitor for any further suspicious activities or attempts to modify the sudoers file across the network. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems. +- Implement additional logging and alerting for changes to the sudoers file and other critical configuration files to enhance detection of similar threats in the future.""" [[rule.threat]] diff --git a/rules/cross-platform/privilege_escalation_setuid_setgid_bit_set_via_chmod.toml b/rules/cross-platform/privilege_escalation_setuid_setgid_bit_set_via_chmod.toml index d23c490865c..78471f68c8f 100644 --- a/rules/cross-platform/privilege_escalation_setuid_setgid_bit_set_via_chmod.toml +++ b/rules/cross-platform/privilege_escalation_setuid_setgid_bit_set_via_chmod.toml @@ -2,7 +2,7 @@ creation_date = "2020/04/23" integration = ["endpoint"] maturity = "production" -updated_date = "2024/09/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -49,6 +49,40 @@ process where host.os.type == "linux" and event.type == "start" and event.action ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 SUID/SGID Bit Set + +The SUID/SGID bits in Unix-like systems allow files to execute with the privileges of the file owner or group, enabling necessary elevated permissions for certain applications. However, adversaries can exploit these bits to escalate privileges by modifying files to run with higher access rights. The detection rule identifies suspicious use of commands like `chmod` or `install` to set these bits, excluding known safe paths, to flag potential privilege escalation attempts. + +### Possible investigation steps + +- Review the process details to identify the user who executed the command, focusing on the process.name and process.args fields to understand the specific command and arguments used. +- Check the process.parent.executable field to determine the parent process and assess whether it is a known legitimate process or potentially malicious. +- Investigate the file or directory targeted by the SUID/SGID bit modification by examining the process.args field for any unusual or sensitive paths that could indicate privilege escalation attempts. +- Correlate the event with other recent activities from the same user or system to identify any patterns or anomalies that could suggest malicious behavior. +- Verify if the file or directory with modified SUID/SGID bits is part of a known safe path as listed in the exclusion criteria, and assess whether the modification is expected or authorized. + +### False positive analysis + +- System package installations or updates may trigger the rule when legitimate processes like package managers set SUID/SGID bits. To handle this, exclude paths related to package management, such as "/var/lib/dpkg/info*". +- Docker or container-related operations might set these bits during normal operations. Exclude paths like "/var/lib/docker/*" to prevent false positives from container management activities. +- Temporary directories used during system operations, such as "/tmp/newroot/*", can cause false alerts. Exclude these paths to avoid unnecessary alerts from temporary system processes. +- Specific system services or applications, like "/usr/bin/ssh-agent", may require SUID/SGID bits for legitimate functionality. Exclude these known safe executables to reduce false positives. +- Custom scripts or applications that are known to require elevated permissions should be reviewed and, if deemed safe, added to the exclusion list to prevent repeated false alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation. +- Identify and terminate any suspicious processes associated with the use of `chmod` or `install` commands that have set the SUID/SGID bits, especially those not in the excluded safe paths. +- Review and revert any unauthorized changes to file permissions, specifically those with SUID/SGID bits set, to their original state. +- Conduct a thorough audit of user accounts and privileges on the affected system to ensure no unauthorized accounts or privilege escalations have occurred. +- Implement additional monitoring on the affected system to detect any further attempts to exploit SUID/SGID bits, focusing on the specific commands and arguments identified in the detection query. +- Escalate the incident to the security operations team for a deeper investigation into potential lateral movement or persistence mechanisms that may have been established by the adversary. +- Apply patches and updates to the affected system and any vulnerable applications to mitigate known vulnerabilities that could be exploited in conjunction with SUID/SGID bit abuse.""" [[rule.threat]] diff --git a/rules/cross-platform/privilege_escalation_sudo_buffer_overflow.toml b/rules/cross-platform/privilege_escalation_sudo_buffer_overflow.toml index 0fa03093486..8d0b1cbdadd 100644 --- a/rules/cross-platform/privilege_escalation_sudo_buffer_overflow.toml +++ b/rules/cross-platform/privilege_escalation_sudo_buffer_overflow.toml @@ -2,7 +2,7 @@ creation_date = "2021/02/03" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -48,6 +48,41 @@ event.category:process and event.type:start and process.name:(sudo or sudoedit) and process.args:(*\\ and ("-i" or "-s")) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Sudo Heap-Based Buffer Overflow Attempt + +Sudo is a critical utility in Unix-like systems, allowing users to execute commands with elevated privileges. A heap-based buffer overflow in Sudo (CVE-2021-3156) can be exploited by attackers to gain root access. Adversaries may craft specific command-line arguments to trigger this vulnerability. The detection rule identifies suspicious Sudo or Sudoedit invocations with particular argument patterns, signaling potential exploitation attempts. + +### Possible investigation steps + +- Review the alert details to confirm the presence of suspicious Sudo or Sudoedit invocations with the specific argument patterns: process.args containing a backslash followed by either "-i" or "-s". +- Examine the process execution context by gathering additional details such as the user account associated with the process, the parent process, and the command line used. +- Check the system logs for any other unusual or unauthorized activities around the time of the alert to identify potential lateral movement or further exploitation attempts. +- Investigate the history of the user account involved to determine if there have been any previous suspicious activities or privilege escalation attempts. +- Assess the system for any signs of compromise or unauthorized changes, such as new user accounts, modified files, or unexpected network connections. +- Verify the current version of Sudo installed on the system to determine if it is vulnerable to CVE-2021-3156 and consider applying patches or updates if necessary. + +### False positive analysis + +- Routine administrative tasks using sudo or sudoedit with interactive or shell options may trigger the rule. Review the context of these commands and consider excluding specific user accounts or scripts that are known to perform legitimate administrative functions. +- Automated scripts or cron jobs that use sudo with the -i or -s options for legitimate purposes can be flagged. Identify these scripts and add them to an exception list to prevent unnecessary alerts. +- Development or testing environments where users frequently test commands with elevated privileges might generate false positives. Implement a separate monitoring policy for these environments or exclude known test accounts. +- Security tools or monitoring solutions that simulate attacks for testing purposes may inadvertently trigger the rule. Ensure these tools are recognized and excluded from triggering alerts by adding them to an exception list. +- Users with legitimate reasons to frequently switch to root using sudo -i or sudo -s should be identified, and their activities should be monitored separately to avoid false positives. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the attacker. +- Terminate any suspicious sudo or sudoedit processes identified by the detection rule to halt ongoing exploitation attempts. +- Apply the latest security patches and updates to the Sudo utility on all affected systems to remediate the vulnerability (CVE-2021-3156). +- Conduct a thorough review of system logs and process execution history to identify any unauthorized access or privilege escalation activities. +- Reset passwords for all user accounts on the affected system, especially those with elevated privileges, to mitigate potential credential compromise. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the scope of the breach. +- Implement enhanced monitoring and alerting for sudo and sudoedit command executions across the network to detect similar exploitation attempts in the future.""" [[rule.threat]] diff --git a/rules/cross-platform/privilege_escalation_sudoers_file_mod.toml b/rules/cross-platform/privilege_escalation_sudoers_file_mod.toml index b0d2ae7d57e..dabefa210d6 100644 --- a/rules/cross-platform/privilege_escalation_sudoers_file_mod.toml +++ b/rules/cross-platform/privilege_escalation_sudoers_file_mod.toml @@ -2,7 +2,7 @@ creation_date = "2020/04/13" integration = ["endpoint"] maturity = "production" -updated_date = "2024/09/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -35,6 +35,40 @@ event.category:file and event.type:change and file.path:(/etc/sudoers* or /priva not process.name:(dpkg or platform-python or puppet or yum or dnf) and not process.executable:(/opt/chef/embedded/bin/ruby or /opt/puppetlabs/puppet/bin/ruby or /usr/bin/dockerd) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Sudoers File Modification + +The sudoers file is crucial in Unix-like systems, defining user permissions for executing commands with elevated privileges. Adversaries may exploit this by altering the file to gain unauthorized access or escalate privileges. The detection rule identifies suspicious changes to the sudoers file, excluding legitimate processes, to flag potential privilege escalation attempts. + +### Possible investigation steps + +- Review the alert details to identify the specific file path that triggered the alert, focusing on /etc/sudoers* or /private/etc/sudoers*. +- Examine the process information associated with the change event, particularly the process.name and process.executable fields, to determine if the modification was made by a suspicious or unauthorized process. +- Check the user account associated with the process that made the change to the sudoers file to assess if the account has a legitimate reason to modify the file. +- Investigate recent login activity and user behavior for the account involved in the modification to identify any anomalies or signs of compromise. +- Review system logs around the time of the alert to gather additional context on what other activities occurred on the system, which might indicate a broader attack or compromise. +- Assess the current state of the sudoers file to identify any unauthorized or suspicious entries that could indicate privilege escalation attempts. + +### False positive analysis + +- System updates and package installations can trigger changes to the sudoers file. Exclude processes like dpkg, yum, dnf, and platform-python from triggering alerts as they are commonly involved in legitimate updates. +- Configuration management tools such as Puppet and Chef may modify the sudoers file as part of their normal operations. Exclude process executables like /opt/chef/embedded/bin/ruby and /opt/puppetlabs/puppet/bin/ruby to prevent false positives. +- Docker daemon processes might interact with the sudoers file during container operations. Exclude /usr/bin/dockerd to avoid unnecessary alerts related to Docker activities. +- Regularly review and update the exclusion list to ensure it reflects the current environment and operational tools, minimizing false positives while maintaining security vigilance. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation. +- Review the recent changes to the sudoers file to identify unauthorized modifications and revert them to the last known good configuration. +- Conduct a thorough examination of system logs to identify any unauthorized access or actions performed using elevated privileges, focusing on the time frame of the detected change. +- Reset passwords and review access permissions for all users with sudo privileges to ensure no unauthorized accounts have been added or existing accounts have been compromised. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been affected. +- Implement additional monitoring on the affected system and similar systems to detect any further attempts to modify the sudoers file or other privilege escalation activities. +- Review and update security policies and configurations to prevent similar incidents, ensuring that only authorized processes can modify the sudoers file.""" [[rule.threat]] diff --git a/rules/integrations/aws/collection_cloudtrail_logging_created.toml b/rules/integrations/aws/collection_cloudtrail_logging_created.toml index f4c31b3d257..694363bb9e4 100644 --- a/rules/integrations/aws/collection_cloudtrail_logging_created.toml +++ b/rules/integrations/aws/collection_cloudtrail_logging_created.toml @@ -2,7 +2,7 @@ creation_date = "2020/06/10" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -20,7 +20,42 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS CloudTrail Log Created" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS CloudTrail Log Created + +AWS CloudTrail is a service that enables governance, compliance, and operational and risk auditing of your AWS account. It logs API calls and related events, providing visibility into user activity. Adversaries may create new trails to capture sensitive data or cover their tracks. The detection rule identifies successful trail creation, signaling potential unauthorized activity, aiding in early threat detection. + +### Possible investigation steps + +- Review the AWS CloudTrail logs to identify the user or role associated with the CreateTrail event by examining the user identity information in the event logs. +- Check the time and date of the CreateTrail event to determine if it aligns with any known maintenance or administrative activities. +- Investigate the configuration of the newly created trail to understand what specific log data it is set to capture and where it is being delivered. +- Assess whether the trail creation was authorized by cross-referencing with change management records or by contacting relevant personnel. +- Analyze other recent AWS CloudTrail events associated with the same user or role to identify any suspicious or unusual activities that may indicate malicious intent. +- Evaluate the permissions and access policies of the user or role involved in the event to ensure they align with the principle of least privilege. + +### False positive analysis + +- Routine administrative actions by authorized personnel can trigger this rule. Regularly review and document legitimate trail creation activities to differentiate them from unauthorized actions. +- Automated processes or scripts that create trails for compliance or monitoring purposes may cause false positives. Identify and whitelist these processes to prevent unnecessary alerts. +- Third-party security tools or services that integrate with AWS and create trails for enhanced logging might be mistaken for suspicious activity. Verify these integrations and exclude them from the rule if they are part of your security strategy. +- Changes in organizational policy or structure that require new trail creation can lead to false positives. Ensure that such changes are communicated to the security team to adjust the rule settings accordingly. + +### Response and remediation + +- Immediately review the newly created CloudTrail log to verify its legitimacy. Check the user or service account that initiated the trail creation and confirm if it aligns with expected administrative activities. +- If the trail creation is unauthorized, disable or delete the trail to prevent further data capture by potential adversaries. +- Conduct a thorough audit of recent API calls and user activities associated with the account that created the trail to identify any other suspicious actions or configurations. +- Escalate the incident to the security operations team for further investigation and to determine if additional AWS resources have been compromised. +- Implement additional monitoring and alerting for any future unauthorized CloudTrail modifications or creations to enhance early detection capabilities. +- Review and tighten IAM policies and permissions to ensure that only authorized personnel have the ability to create or modify CloudTrail configurations. +- Consider enabling AWS CloudTrail log file integrity validation to ensure that log files have not been altered or deleted, providing an additional layer of security. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/aws/credential_access_aws_getpassword_for_ec2_instance.toml b/rules/integrations/aws/credential_access_aws_getpassword_for_ec2_instance.toml index cbb1e5613fc..d27a455dd09 100644 --- a/rules/integrations/aws/credential_access_aws_getpassword_for_ec2_instance.toml +++ b/rules/integrations/aws/credential_access_aws_getpassword_for_ec2_instance.toml @@ -2,7 +2,7 @@ creation_date = "2024/04/10" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -17,7 +17,7 @@ language = "kuery" license = "Elastic License v2" name = "AWS EC2 Admin Credential Fetch via Assumed Role" note = """ -## Triage and Analysis +## Triage and analysis ### Investigating AWS EC2 Admin Credential Fetch via Assumed Role diff --git a/rules/integrations/aws/credential_access_iam_compromisedkeyquarantine_policy_attached_to_user.toml b/rules/integrations/aws/credential_access_iam_compromisedkeyquarantine_policy_attached_to_user.toml index e8549d773a8..a15d92086ad 100644 --- a/rules/integrations/aws/credential_access_iam_compromisedkeyquarantine_policy_attached_to_user.toml +++ b/rules/integrations/aws/credential_access_iam_compromisedkeyquarantine_policy_attached_to_user.toml @@ -2,7 +2,7 @@ creation_date = "2024/07/20" integration = ["aws"] maturity = "production" -updated_date = "2024/07/20" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -21,12 +21,12 @@ language = "eql" license = "Elastic License v2" name = "AWS IAM CompromisedKeyQuarantine Policy Attached to User" note = """ -## Triage and Analysis +## Triage and analysis ### Investigating AWS IAM CompromisedKeyQuarantine Policy Attached to User -The AWS IAM `CompromisedKeyQuarantine` and `CompromisedKeyQuarantineV2` managed policies deny certain action and is applied by the AWS team to a user with exposed credentials. -This action is accompanied by a support case which specifies instructions to follow before detaching the policy. +The AWS IAM `CompromisedKeyQuarantine` and `CompromisedKeyQuarantineV2` managed policies deny certain action and is applied by the AWS team to a user with exposed credentials. +This action is accompanied by a support case which specifies instructions to follow before detaching the policy. #### Possible Investigation Steps @@ -70,9 +70,9 @@ timestamp_override = "event.ingested" type = "eql" query = ''' -any where event.dataset == "aws.cloudtrail" +any where event.dataset == "aws.cloudtrail" and event.action == "AttachUserPolicy" - and event.outcome == "success" + and event.outcome == "success" and stringContains(aws.cloudtrail.request_parameters, "AWSCompromisedKeyQuarantine") ''' diff --git a/rules/integrations/aws/credential_access_retrieve_secure_string_parameters_via_ssm.toml b/rules/integrations/aws/credential_access_retrieve_secure_string_parameters_via_ssm.toml index b77b7bdd90c..ef65515d597 100644 --- a/rules/integrations/aws/credential_access_retrieve_secure_string_parameters_via_ssm.toml +++ b/rules/integrations/aws/credential_access_retrieve_secure_string_parameters_via_ssm.toml @@ -2,7 +2,7 @@ creation_date = "2024/04/12" integration = ["aws"] maturity = "production" -updated_date = "2024/07/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -28,7 +28,7 @@ language = "kuery" license = "Elastic License v2" name = "AWS Systems Manager SecureString Parameter Request with Decryption Flag" note = """ -## Triage and Analysis +## Triage and analysis ### Investigating AWS Systems Manager SecureString Parameter Request with Decryption Flag diff --git a/rules/integrations/aws/credential_access_root_console_failure_brute_force.toml b/rules/integrations/aws/credential_access_root_console_failure_brute_force.toml index e8cfdda99fe..6f841ec6401 100644 --- a/rules/integrations/aws/credential_access_root_console_failure_brute_force.toml +++ b/rules/integrations/aws/credential_access_root_console_failure_brute_force.toml @@ -2,7 +2,7 @@ creation_date = "2020/07/21" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,42 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"] language = "kuery" license = "Elastic License v2" name = "AWS Management Console Brute Force of Root User Identity" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS Management Console Brute Force of Root User Identity + +The AWS Management Console is a web-based interface for accessing and managing AWS services. The root user identity has unrestricted access, making it a prime target for adversaries seeking unauthorized control. Attackers may attempt brute force attacks to guess the root password. The detection rule identifies such attempts by monitoring failed login events specifically for the root user, flagging potential credential access threats. + +### Possible investigation steps + +- Review the CloudTrail logs for the specific time frame of the failed login attempts to identify patterns or anomalies in the source IP addresses or user agents. +- Check the geographical location of the IP addresses involved in the failed login attempts to determine if they are consistent with known or expected locations for legitimate access. +- Investigate any successful login attempts from the same IP addresses or user agents to assess if the brute force attempt was successful at any point. +- Analyze the frequency and timing of the failed login attempts to determine if they align with typical brute force attack patterns, such as rapid or sequential attempts. +- Correlate the failed login events with other security events or alerts in the AWS environment to identify any concurrent suspicious activities that may indicate a broader attack campaign. +- Review AWS CloudTrail logs for any changes in IAM policies or unusual activity following the failed login attempts to ensure no unauthorized access was gained. + +### False positive analysis + +- Legitimate users may forget their password and repeatedly attempt to log in, triggering the rule. To manage this, monitor for patterns of failed logins followed by successful ones and consider excluding these from alerts if they originate from known IP addresses. +- Automated scripts or applications using outdated credentials can cause repeated failed login attempts. Identify and update these credentials or exclude the associated IP addresses from the rule. +- Security testing or penetration testing activities might simulate brute force attacks. Coordinate with your security team to whitelist IP addresses or timeframes associated with these activities to prevent false positives. +- Shared accounts or environments where multiple users attempt to access the root account can lead to multiple failed attempts. Implement stricter access controls and consider excluding known internal IP ranges from the rule. + +### Response and remediation + +- Immediately disable the root user account to prevent further unauthorized access attempts. This can be done through the AWS Management Console by navigating to the IAM section and selecting the root user account. +- Review the CloudTrail logs to identify the source IP addresses of the failed login attempts. Block these IP addresses using AWS security groups or network ACLs to prevent further access attempts from these locations. +- Reset the root user password and ensure it is strong and unique. Use a password manager to generate and store the new password securely. +- Enable multi-factor authentication (MFA) for the root user account to add an additional layer of security. This can be configured in the AWS Management Console under the IAM section. +- Conduct a thorough audit of recent account activity to ensure no unauthorized changes have been made. Pay special attention to IAM roles, policies, and permissions. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. Provide them with details of the attempted breach and actions taken. +- Implement additional monitoring and alerting for unusual login patterns or failed login attempts to the root account to enhance early detection of similar threats in the future. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html"] diff --git a/rules/integrations/aws/defense_evasion_configuration_recorder_stopped.toml b/rules/integrations/aws/defense_evasion_configuration_recorder_stopped.toml index c0cd38ab247..3d79fb84154 100644 --- a/rules/integrations/aws/defense_evasion_configuration_recorder_stopped.toml +++ b/rules/integrations/aws/defense_evasion_configuration_recorder_stopped.toml @@ -2,7 +2,7 @@ creation_date = "2020/06/16" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -20,7 +20,42 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS Configuration Recorder Stopped" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS Configuration Recorder Stopped + +AWS Config records and evaluates configurations of AWS resources, ensuring compliance and security. Stopping the configuration recorder can hinder visibility into resource changes, aiding adversaries in evading detection. The detection rule identifies successful attempts to stop the recorder, signaling potential defense evasion by monitoring specific AWS CloudTrail events related to configuration changes. + +### Possible investigation steps + +- Review the AWS CloudTrail logs for the specific event.action:StopConfigurationRecorder to identify the user or role that initiated the action. +- Check the event.outcome:success field to confirm the action was successfully executed and correlate it with any other suspicious activities around the same timeframe. +- Investigate the IAM permissions and roles associated with the user or entity that stopped the configuration recorder to determine if they have the necessary permissions and if those permissions are appropriate. +- Analyze the context of the event by examining other recent AWS CloudTrail events from the same event.provider:config.amazonaws.com to identify any related configuration changes or anomalies. +- Assess the potential impact on compliance and security by identifying which resources were affected by the stopped configuration recorder and evaluating the risk of undetected changes during the period it was inactive. +- Review any recent changes in AWS Config settings or policies that might explain the legitimate need to stop the configuration recorder, ensuring there is a valid business justification. + +### False positive analysis + +- Routine maintenance activities by authorized personnel can trigger the rule. To manage this, create exceptions for specific IAM roles or users known to perform these tasks regularly. +- Automated scripts or tools used for configuration management might stop the recorder as part of their operation. Identify these scripts and exclude their actions from triggering alerts by using their unique identifiers or tags. +- Scheduled configuration changes during non-peak hours may involve stopping the recorder temporarily. Document these schedules and adjust the rule to ignore events during these periods. +- Testing environments often mimic production changes, including stopping the recorder. Exclude events from known testing accounts or environments to prevent unnecessary alerts. + +### Response and remediation + +- Immediately re-enable the AWS Config recorder to restore visibility into resource changes and ensure compliance monitoring is active. +- Conduct a thorough review of AWS CloudTrail logs to identify any unauthorized or suspicious activities that occurred during the period when the configuration recorder was stopped. +- Verify the IAM roles and permissions associated with the AWS account to ensure that only authorized personnel have the ability to stop the configuration recorder. Adjust permissions as necessary to follow the principle of least privilege. +- Implement additional monitoring and alerting for any future attempts to stop the AWS Config recorder, ensuring that such actions trigger immediate notifications to the security team. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if the action was part of a broader attack or misconfiguration. +- Review and update incident response plans to include specific procedures for handling AWS Config recorder stoppage events, ensuring rapid response and containment in future occurrences. +- Consider enabling AWS Config rules to automatically remediate unauthorized changes, such as stopping the configuration recorder, to enhance the security posture and prevent recurrence. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/aws/defense_evasion_ec2_network_acl_deletion.toml b/rules/integrations/aws/defense_evasion_ec2_network_acl_deletion.toml index fb2e47ad909..673aa1fe03f 100644 --- a/rules/integrations/aws/defense_evasion_ec2_network_acl_deletion.toml +++ b/rules/integrations/aws/defense_evasion_ec2_network_acl_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/05/26" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -23,7 +23,43 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS EC2 Network Access Control List Deletion" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS EC2 Network Access Control List Deletion + +AWS EC2 Network ACLs are essential for controlling inbound and outbound traffic to subnets, acting as a firewall layer. Adversaries may delete these ACLs to disable security controls, facilitating unauthorized access or data exfiltration. The detection rule monitors AWS CloudTrail logs for successful deletion events of ACLs or their entries, signaling potential defense evasion attempts. + +### Possible investigation steps + +- Review the AWS CloudTrail logs to identify the specific user or role associated with the deletion event by examining the user identity information in the logs. +- Check the time and date of the deletion event to determine if it coincides with any other suspicious activities or known maintenance windows. +- Investigate the source IP address and location from which the deletion request was made to assess if it aligns with expected access patterns or if it appears anomalous. +- Examine the AWS account activity around the time of the event to identify any other unusual actions or changes, such as the creation of new resources or modifications to existing ones. +- Assess the impact of the deleted Network ACL or entries by identifying the affected subnets and evaluating the potential exposure or risk to the network. +- Review any recent changes to IAM policies or roles that might have inadvertently granted excessive permissions to users or services, allowing them to delete Network ACLs. + +### False positive analysis + +- Routine maintenance or updates by authorized personnel may trigger deletion events. Verify if the deletion aligns with scheduled maintenance activities and consider excluding these events from alerts. +- Automated scripts or infrastructure-as-code tools like Terraform or CloudFormation might delete and recreate ACLs as part of normal operations. Identify these tools and exclude their actions from triggering alerts. +- Changes in network architecture or security policy updates can lead to legitimate ACL deletions. Document these changes and adjust the detection rule to ignore such planned modifications. +- Ensure that the AWS accounts involved in the deletion events are recognized and trusted. Exclude actions from these accounts if they are part of regular administrative tasks. +- Collaborate with the security team to establish a baseline of normal ACL deletion activities and refine the detection rule to minimize false positives based on this baseline. + +### Response and remediation + +- Immediately isolate the affected subnet to prevent further unauthorized access or data exfiltration. This can be done by applying a restrictive security group or temporarily removing the subnet from the VPC. +- Review AWS CloudTrail logs to identify the source of the deletion event, including the IAM user or role responsible, and assess whether the action was authorized or part of a larger compromise. +- Recreate the deleted Network ACL or its entries using the most recent backup or configuration documentation to restore intended security controls. +- Implement a temporary monitoring solution to track any further unauthorized changes to network ACLs or related security configurations. +- Escalate the incident to the security operations team for a comprehensive investigation to determine the root cause and scope of the breach, including potential lateral movement or data exfiltration. +- Revoke or rotate credentials for any compromised IAM users or roles involved in the deletion event to prevent further unauthorized actions. +- Enhance detection capabilities by configuring alerts for any future unauthorized changes to network ACLs, ensuring rapid response to similar threats. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/aws/defense_evasion_elasticache_security_group_creation.toml b/rules/integrations/aws/defense_evasion_elasticache_security_group_creation.toml index d39dcc0b035..26b2b6f5578 100644 --- a/rules/integrations/aws/defense_evasion_elasticache_security_group_creation.toml +++ b/rules/integrations/aws/defense_evasion_elasticache_security_group_creation.toml @@ -2,7 +2,7 @@ creation_date = "2021/07/19" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Austin Songer"] @@ -21,7 +21,43 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS ElastiCache Security Group Created" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS ElastiCache Security Group Created + +AWS ElastiCache security groups control access to cache clusters, ensuring only authorized traffic can interact with them. Adversaries might create new security groups to bypass existing restrictions, facilitating unauthorized access or data exfiltration. The detection rule monitors for successful creation events of these groups, signaling potential defense evasion tactics by identifying unusual or unauthorized configurations. + +### Possible investigation steps + +- Review the CloudTrail logs for the specific event.action "Create Cache Security Group" to identify the user or role that initiated the creation of the ElastiCache security group. +- Examine the event.provider field to confirm that the event is associated with elasticache.amazonaws.com, ensuring the alert is relevant to ElastiCache services. +- Check the event.outcome field to verify that the security group creation was successful, confirming the alert's validity. +- Investigate the IAM permissions and roles associated with the user or entity that created the security group to determine if they have legitimate access and reasons for this action. +- Analyze the configuration of the newly created ElastiCache security group to identify any overly permissive rules or unusual configurations that could indicate malicious intent. +- Correlate this event with other recent activities in the AWS account, such as changes to IAM policies or unusual login attempts, to assess if this is part of a broader attack pattern. + +### False positive analysis + +- Routine administrative actions by authorized personnel can trigger this rule. Regularly review and document legitimate security group creation activities to differentiate them from suspicious actions. +- Automated processes or scripts that create security groups as part of normal operations may cause false positives. Identify and whitelist these processes to prevent unnecessary alerts. +- Infrastructure as Code (IaC) tools like Terraform or CloudFormation might create security groups during deployments. Ensure these tools and their actions are well-documented and consider excluding their known patterns from triggering alerts. +- Development and testing environments often involve frequent creation and deletion of resources, including security groups. Establish separate monitoring rules or exceptions for these environments to reduce noise. +- Scheduled maintenance or updates that involve security group modifications should be communicated to the security team in advance, allowing them to temporarily adjust monitoring rules or expectations. + +### Response and remediation + +- Immediately review the newly created ElastiCache security group to verify its necessity and ensure it aligns with organizational security policies. If unauthorized, proceed to delete the security group to prevent potential misuse. +- Conduct a thorough audit of recent IAM activity to identify any unauthorized access or privilege escalation that may have led to the creation of the security group. Pay special attention to any anomalies in user behavior or access patterns. +- Isolate any affected ElastiCache instances by temporarily restricting access to them until a full assessment is completed. This helps prevent any potential data exfiltration or unauthorized access. +- Notify the security operations team and relevant stakeholders about the incident for further investigation and to ensure awareness across the organization. +- Implement additional monitoring on the AWS account to detect any further unauthorized changes to security groups or other critical configurations, enhancing the detection capabilities for similar threats. +- Review and update IAM policies and permissions to ensure the principle of least privilege is enforced, reducing the risk of unauthorized security group creation in the future. +- If the incident is confirmed as malicious, escalate to the incident response team for a comprehensive investigation and to determine if further actions, such as legal or regulatory reporting, are necessary. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/aws/defense_evasion_elasticache_security_group_modified_or_deleted.toml b/rules/integrations/aws/defense_evasion_elasticache_security_group_modified_or_deleted.toml index a496a341a8c..dcf14818d03 100644 --- a/rules/integrations/aws/defense_evasion_elasticache_security_group_modified_or_deleted.toml +++ b/rules/integrations/aws/defense_evasion_elasticache_security_group_modified_or_deleted.toml @@ -2,7 +2,7 @@ creation_date = "2021/07/19" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Austin Songer"] @@ -21,7 +21,43 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS ElastiCache Security Group Modified or Deleted" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS ElastiCache Security Group Modified or Deleted + +AWS ElastiCache security groups control inbound and outbound traffic to cache clusters, ensuring only authorized access. Adversaries may modify or delete these groups to bypass security controls, facilitating unauthorized data access or exfiltration. The detection rule monitors specific API actions related to security group changes, flagging successful modifications or deletions as potential defense evasion attempts. + +### Possible investigation steps + +- Review the CloudTrail logs for the specific event.provider: elasticache.amazonaws.com to identify the user or role that initiated the security group modification or deletion. +- Examine the event.action field to determine the exact action taken, such as "Delete Cache Security Group" or "Authorize Cache Security Group Ingress", and assess the potential impact on security posture. +- Check the event.outcome field to confirm the success of the action and correlate it with any other suspicious activities in the same timeframe. +- Investigate the source IP address and location associated with the event to determine if it aligns with expected administrative activity. +- Review the AWS IAM policies and permissions associated with the user or role to ensure they are appropriate and have not been overly permissive. +- Assess the affected ElastiCache clusters to determine if any unauthorized access or data exfiltration attempts have occurred following the security group change. + +### False positive analysis + +- Routine maintenance activities by authorized personnel can trigger alerts when they modify security groups for legitimate reasons. To manage this, create exceptions for known maintenance windows or specific user actions. +- Automated scripts or tools used for infrastructure management might modify security groups as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific user or role identifiers. +- Changes made by cloud management platforms or third-party services that integrate with AWS may also result in false positives. Review and whitelist these services if they are verified as non-threatening. +- Regular updates or deployments that require temporary security group modifications can be mistaken for suspicious activity. Document these processes and adjust the detection rule to account for these expected changes. +- Ensure that any changes made by trusted IP addresses or within a specific network range are reviewed and potentially excluded from alerting, as they may represent internal, authorized activities. + +### Response and remediation + +- Immediately isolate the affected ElastiCache instance by applying restrictive security group rules to prevent further unauthorized access. +- Review CloudTrail logs to identify any unauthorized API calls related to the security group modifications and determine the source of the changes. +- Revert any unauthorized changes to the ElastiCache security groups by restoring them to their previous state using backups or documented configurations. +- Conduct a thorough investigation to identify any data exfiltration or unauthorized access that may have occurred due to the security group changes. +- Escalate the incident to the security operations team for further analysis and to determine if additional security measures are required. +- Implement additional monitoring and alerting for changes to ElastiCache security groups to ensure rapid detection of similar threats in the future. +- Review and update IAM policies to ensure that only authorized personnel have permissions to modify ElastiCache security groups, reducing the risk of future unauthorized changes. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://docs.aws.amazon.com/AmazonElastiCache/latest/APIReference/Welcome.html"] diff --git a/rules/integrations/aws/defense_evasion_guardduty_detector_deletion.toml b/rules/integrations/aws/defense_evasion_guardduty_detector_deletion.toml index d0f4ad05d7d..ec4f02bff24 100644 --- a/rules/integrations/aws/defense_evasion_guardduty_detector_deletion.toml +++ b/rules/integrations/aws/defense_evasion_guardduty_detector_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/05/28" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -23,7 +23,43 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS GuardDuty Detector Deletion" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS GuardDuty Detector Deletion + +AWS GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior in AWS environments. Deleting a GuardDuty detector halts this monitoring, potentially concealing malicious actions. Adversaries may exploit this by deleting detectors to evade detection. The detection rule identifies successful deletion events, signaling potential defense evasion attempts, and is crucial for maintaining security visibility. + +### Possible investigation steps + +- Review the CloudTrail logs for the specific event.provider:guardduty.amazonaws.com and event.action:DeleteDetector to identify the user or role responsible for the deletion. +- Check the event.outcome:success to confirm the deletion was successful and not an attempted action. +- Investigate the IAM permissions and recent activity of the user or role identified to determine if the deletion was authorized or potentially malicious. +- Examine any recent GuardDuty findings prior to the deletion to assess if there were any critical alerts that might have prompted the deletion. +- Correlate the timing of the detector deletion with other security events or anomalies in the AWS environment to identify potential patterns or coordinated actions. +- Review AWS CloudTrail logs for any other suspicious activities or changes in the environment around the time of the detector deletion. + +### False positive analysis + +- Routine maintenance or administrative actions may lead to the deletion of a GuardDuty detector. Verify if the deletion aligns with scheduled maintenance or administrative tasks. +- Automated scripts or tools used for environment cleanup might inadvertently delete detectors. Review and adjust automation scripts to prevent unintended deletions. +- Organizational policy changes or restructuring could result in detector deletions. Ensure that policy changes are communicated and understood by all relevant teams to avoid unnecessary deletions. +- Exclude known and authorized users or roles from triggering alerts by creating exceptions for specific IAM roles or user accounts that are responsible for legitimate detector deletions. +- Implement logging and alerting for detector deletions to quickly identify and verify the legitimacy of the action, allowing for rapid response to potential false positives. + +### Response and remediation + +- Immediately re-enable GuardDuty in the affected AWS account to restore monitoring capabilities and ensure continuous threat detection. +- Conduct a thorough review of CloudTrail logs to identify any unauthorized access or suspicious activities that occurred during the period when GuardDuty was disabled. +- Isolate any compromised resources identified during the log review to prevent further unauthorized access or damage. +- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional access controls and monitoring on the AWS account to prevent unauthorized deletion of GuardDuty detectors in the future. +- Review and update IAM policies to ensure that only authorized personnel have permissions to delete GuardDuty detectors. +- Consider enabling AWS Config rules to monitor and alert on changes to GuardDuty configurations for proactive detection of similar incidents. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/aws/defense_evasion_rds_instance_restored.toml b/rules/integrations/aws/defense_evasion_rds_instance_restored.toml index 4a584d3a37c..9f5408d461d 100644 --- a/rules/integrations/aws/defense_evasion_rds_instance_restored.toml +++ b/rules/integrations/aws/defense_evasion_rds_instance_restored.toml @@ -2,7 +2,7 @@ creation_date = "2021/06/29" integration = ["aws"] maturity = "production" -updated_date = "2024/06/20" +updated_date = "2025/01/10" [rule] author = ["Austin Songer", "Elastic"] @@ -46,6 +46,41 @@ any where event.dataset == "aws.cloudtrail" and event.action in ("RestoreDBInstanceFromDBSnapshot", "RestoreDBInstanceFromS3") and event.outcome == "success" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS RDS DB Instance Restored + +Amazon RDS (Relational Database Service) allows users to set up, operate, and scale databases in the cloud. Adversaries may exploit RDS by restoring DB instances from snapshots or S3 to access sensitive data or bypass security controls. The detection rule identifies successful restoration attempts, signaling potential unauthorized access or data exfiltration activities, by monitoring specific API operations and outcomes. + +### Possible investigation steps + +- Review the CloudTrail logs to identify the user or role associated with the successful `RestoreDBInstanceFromDBSnapshot` or `RestoreDBInstanceFromS3` API call by examining the `user.identity` field. +- Check the source IP address and location from which the API call was made using the `sourceIPAddress` field to determine if it aligns with expected or known locations. +- Investigate the timing of the restoration event by looking at the `@timestamp` field to see if it coincides with any other suspicious activities or anomalies in the environment. +- Examine the specific DB instance details restored, such as the DB instance identifier, to assess the sensitivity of the data involved and potential impact. +- Verify if there are any associated alerts or logs indicating unauthorized access or data exfiltration attempts around the same time frame. +- Contact the user or team responsible for the credentials used, if legitimate, to confirm whether the restoration was authorized and intended. + +### False positive analysis + +- Routine database maintenance or testing activities may trigger the rule. Organizations should identify and document regular restoration activities performed by authorized personnel and exclude these from alerts. +- Automated backup and restore processes used for disaster recovery or data migration can result in false positives. Users should configure exceptions for known automated processes by filtering based on specific user accounts or roles. +- Development and staging environments often involve frequent restoration of databases for testing purposes. Exclude these environments by identifying and filtering out specific instance identifiers or tags associated with non-production environments. +- Scheduled tasks or scripts that restore databases as part of regular operations can be mistaken for unauthorized activity. Ensure these tasks are well-documented and create exceptions based on the source IP or IAM role used for these operations. +- Third-party services or integrations that require database restoration for functionality may trigger alerts. Verify these services and exclude their associated actions by identifying their unique user agents or API keys. + +### Response and remediation + +- Immediately isolate the restored RDS instance to prevent unauthorized access. This can be done by modifying the security group rules to restrict inbound and outbound traffic. +- Conduct a thorough review of CloudTrail logs to identify the source of the compromised credentials and any other suspicious activities associated with the same user or account. +- Revoke the compromised credentials and issue new credentials for the affected user or service account. Ensure that multi-factor authentication (MFA) is enabled for all accounts. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized restoration and any potential data exposure. +- Perform a security assessment of the restored RDS instance to identify any unauthorized changes or data exfiltration. This includes checking for unusual queries or data exports. +- Implement additional monitoring and alerting for similar API operations to detect future unauthorized restoration attempts promptly. +- Review and update IAM policies to ensure that only authorized users have the necessary permissions to restore RDS instances, reducing the risk of future incidents.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/integrations/aws/defense_evasion_route53_dns_query_resolver_config_deletion.toml b/rules/integrations/aws/defense_evasion_route53_dns_query_resolver_config_deletion.toml index 0df31df63c9..942e042e88b 100644 --- a/rules/integrations/aws/defense_evasion_route53_dns_query_resolver_config_deletion.toml +++ b/rules/integrations/aws/defense_evasion_route53_dns_query_resolver_config_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2024/04/12" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -19,7 +19,7 @@ language = "kuery" license = "Elastic License v2" name = "Route53 Resolver Query Log Configuration Deleted" note = """ -## Triage and Analysis +## Triage and analysis ### Investigating Route53 Resolver Query Log Configuration Deleted diff --git a/rules/integrations/aws/defense_evasion_s3_bucket_configuration_deletion.toml b/rules/integrations/aws/defense_evasion_s3_bucket_configuration_deletion.toml index ceb62849c0d..d26d92a11af 100644 --- a/rules/integrations/aws/defense_evasion_s3_bucket_configuration_deletion.toml +++ b/rules/integrations/aws/defense_evasion_s3_bucket_configuration_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/05/27" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -20,7 +20,42 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS S3 Bucket Configuration Deletion" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS S3 Bucket Configuration Deletion + +Amazon S3 is a scalable storage service where configurations like policies, replication, and encryption ensure data security and compliance. Adversaries may delete these configurations to evade defenses, disrupt data protection, or conceal malicious activities. The detection rule monitors successful deletions of these configurations, signaling potential defense evasion attempts by correlating specific CloudTrail events. + +### Possible investigation steps + +- Review the CloudTrail logs for the specific event.provider:s3.amazonaws.com and event.action values to identify the user or role responsible for the deletion actions. +- Examine the event.outcome:success field to confirm that the deletion actions were completed successfully and not attempted or failed. +- Investigate the IAM policies and permissions associated with the user or role identified to determine if they have legitimate access to perform such deletions. +- Check for any recent changes in IAM roles or policies that might have inadvertently granted excessive permissions. +- Correlate the timing of the deletion events with other suspicious activities or alerts in the AWS environment to identify potential patterns or coordinated actions. +- Assess the impact of the deleted configurations on data security and compliance, and determine if any critical data protection mechanisms were affected. + +### False positive analysis + +- Routine administrative actions by authorized personnel may trigger alerts when they update or remove bucket configurations as part of regular maintenance. To manage this, create exceptions for specific user roles or IAM users known to perform these tasks regularly. +- Automated scripts or tools used for infrastructure management might delete and recreate bucket configurations as part of their operation. Identify these scripts and exclude their associated actions from triggering alerts by using specific identifiers or tags. +- Scheduled policy updates or compliance checks that involve temporary removal of configurations can also result in false positives. Implement time-based exceptions for these known activities to prevent unnecessary alerts. +- Development and testing environments often undergo frequent configuration changes, which can mimic suspicious behavior. Exclude these environments from the rule by using environment-specific tags or identifiers. + +### Response and remediation + +- Immediately revoke any unauthorized access to the affected S3 bucket by reviewing and updating the bucket's access policies and permissions. +- Restore the deleted configurations by applying the latest known good configuration settings for policies, replication, encryption, and other affected components. +- Conduct a thorough audit of recent IAM activity to identify any unauthorized or suspicious actions related to the S3 bucket configurations. +- Escalate the incident to the security operations team for further investigation and to determine if additional AWS resources or accounts have been compromised. +- Implement additional monitoring and alerting for any future unauthorized configuration changes to S3 buckets, focusing on the specific actions identified in the detection rule. +- Review and enhance IAM policies to enforce the principle of least privilege, ensuring only authorized users have the necessary permissions to modify S3 bucket configurations. +- Coordinate with the incident response team to assess the impact of the configuration deletions on data security and compliance, and take necessary steps to mitigate any identified risks. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/aws/defense_evasion_s3_bucket_lifecycle_expiration_added.toml b/rules/integrations/aws/defense_evasion_s3_bucket_lifecycle_expiration_added.toml index 00d6eb47dfd..97a1cb932da 100644 --- a/rules/integrations/aws/defense_evasion_s3_bucket_lifecycle_expiration_added.toml +++ b/rules/integrations/aws/defense_evasion_s3_bucket_lifecycle_expiration_added.toml @@ -2,7 +2,7 @@ creation_date = "2024/04/12" integration = ["aws"] maturity = "production" -updated_date = "2024/07/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -27,7 +27,7 @@ language = "kuery" license = "Elastic License v2" name = "AWS S3 Bucket Expiration Lifecycle Configuration Added" note = """ -## Triage and Analysis +## Triage and analysis ### Investigating AWS S3 Bucket Expiration Lifecycle Configuration Added diff --git a/rules/integrations/aws/defense_evasion_s3_bucket_server_access_logging_disabled.toml b/rules/integrations/aws/defense_evasion_s3_bucket_server_access_logging_disabled.toml index 6815557fb75..7918b0463a1 100644 --- a/rules/integrations/aws/defense_evasion_s3_bucket_server_access_logging_disabled.toml +++ b/rules/integrations/aws/defense_evasion_s3_bucket_server_access_logging_disabled.toml @@ -2,7 +2,7 @@ creation_date = "2024/07/12" integration = ["aws"] maturity = "production" -updated_date = "2024/07/12" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -25,7 +25,7 @@ license = "Elastic License v2" name = "AWS S3 Bucket Server Access Logging Disabled" note = """ -## Triage and Analysis +## Triage and analysis ### Investigating AWS S3 Bucket Server Access Logging Disabled @@ -80,9 +80,9 @@ timestamp_override = "event.ingested" type = "eql" query = ''' -any where event.dataset == "aws.cloudtrail" - and event.action == "PutBucketLogging" - and event.outcome == "success" +any where event.dataset == "aws.cloudtrail" + and event.action == "PutBucketLogging" + and event.outcome == "success" and not stringContains(aws.cloudtrail.request_parameters, "LoggingEnabled") ''' diff --git a/rules/integrations/aws/defense_evasion_sts_get_federation_token.toml b/rules/integrations/aws/defense_evasion_sts_get_federation_token.toml index 5d042038e21..bf54ed3f4bd 100644 --- a/rules/integrations/aws/defense_evasion_sts_get_federation_token.toml +++ b/rules/integrations/aws/defense_evasion_sts_get_federation_token.toml @@ -2,7 +2,7 @@ creation_date = "2024/08/19" integration = ["aws"] maturity = "production" -updated_date = "2024/08/19" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -39,6 +39,39 @@ event.dataset: "aws.cloudtrail" and event.provider: sts.amazonaws.com and event.action: GetFederationToken ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 First Occurrence of STS GetFederationToken Request by User + +AWS Security Token Service (STS) enables users to request temporary credentials for accessing AWS resources. While beneficial for legitimate use, adversaries may exploit this to gain unauthorized access. The detection rule identifies unusual activity by flagging the first instance of a `GetFederationToken` request by a user within a 10-day window, helping to uncover potential misuse aimed at evading defenses. + +### Possible investigation steps + +- Review the specific user account associated with the GetFederationToken request to determine if the activity aligns with their typical behavior and role within the organization. +- Examine the AWS CloudTrail logs for additional context around the time of the GetFederationToken request, looking for any other unusual or suspicious activities by the same user or related accounts. +- Check the source IP address and geolocation of the GetFederationToken request to identify if it originates from an expected or unexpected location. +- Investigate the resources accessed using the temporary credentials obtained from the GetFederationToken request to assess if there was any unauthorized or suspicious access. +- Consult with the user or their manager to verify if the GetFederationToken request was legitimate and necessary for their work tasks. + +### False positive analysis + +- Routine administrative tasks by cloud administrators may trigger the rule if they are using `GetFederationToken` for legitimate purposes. To manage this, create exceptions for known administrative accounts that regularly perform these actions. +- Automated scripts or applications that use `GetFederationToken` for legitimate operations might be flagged. Identify these scripts and exclude their associated user accounts from the rule to prevent unnecessary alerts. +- Third-party services integrated with AWS that require temporary credentials might cause false positives. Review and whitelist these services if they are verified and trusted to avoid repeated alerts. +- New employees or contractors accessing AWS resources for the first time may trigger the rule. Implement a process to verify their access requirements and exclude their accounts if their actions are deemed non-threatening. + +### Response and remediation + +- Immediately revoke the temporary credentials associated with the `GetFederationToken` request to prevent unauthorized access to AWS resources. +- Review CloudTrail logs to identify any suspicious activities performed using the temporary credentials and assess the potential impact on AWS resources. +- Isolate the affected user account by disabling it temporarily to prevent further unauthorized actions until a thorough investigation is completed. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Conduct a root cause analysis to determine how the `GetFederationToken` request was initiated and identify any potential security gaps or misconfigurations. +- Implement additional monitoring and alerting for `GetFederationToken` requests to detect and respond to similar activities promptly in the future. +- Review and update IAM policies and permissions to ensure that only authorized users have the ability to request temporary credentials, reducing the risk of misuse.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/integrations/aws/defense_evasion_vpc_security_group_ingress_rule_added_for_remote_connections.toml b/rules/integrations/aws/defense_evasion_vpc_security_group_ingress_rule_added_for_remote_connections.toml index 305ae622ff5..026f16032f2 100644 --- a/rules/integrations/aws/defense_evasion_vpc_security_group_ingress_rule_added_for_remote_connections.toml +++ b/rules/integrations/aws/defense_evasion_vpc_security_group_ingress_rule_added_for_remote_connections.toml @@ -2,7 +2,7 @@ creation_date = "2024/04/16" integration = ["aws"] maturity = "production" -updated_date = "2024/07/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -25,7 +25,7 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "Insecure AWS EC2 VPC Security Group Ingress Rule Added" -note = """## Triage and Analysis +note = """## Triage and analysis ### Investigating Insecure AWS EC2 VPC Security Group Ingress Rule Added diff --git a/rules/integrations/aws/defense_evasion_waf_acl_deletion.toml b/rules/integrations/aws/defense_evasion_waf_acl_deletion.toml index 33ddcf3751a..33c6d1d5575 100644 --- a/rules/integrations/aws/defense_evasion_waf_acl_deletion.toml +++ b/rules/integrations/aws/defense_evasion_waf_acl_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/05/21" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -20,7 +20,42 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS WAF Access Control List Deletion" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS WAF Access Control List Deletion + +AWS Web Application Firewall (WAF) protects web applications by controlling access based on defined rules. Deleting an Access Control List (ACL) can expose applications to threats by removing these protective rules. Adversaries may exploit this to bypass defenses, facilitating unauthorized access or data exfiltration. The detection rule monitors for successful ACL deletions, signaling potential defense evasion attempts. + +### Possible investigation steps + +- Review the CloudTrail logs for the specific event.action:DeleteWebACL to identify the user or role that initiated the deletion. Check the event.userIdentity field for details. +- Examine the event.time field to determine when the deletion occurred and correlate it with any other suspicious activities or alerts around the same timeframe. +- Investigate the event.sourceIPAddress to identify the origin of the request and assess if it aligns with known IP addresses or locations associated with your organization. +- Check the AWS WAF configuration history to understand the context of the deleted ACL, including its rules and the applications it was protecting. +- Assess the impact of the ACL deletion by reviewing access logs for the affected applications to identify any unusual or unauthorized access attempts following the deletion. +- Verify if there are any recent changes in IAM policies or permissions that could have allowed unauthorized users to delete the ACL. + +### False positive analysis + +- Routine maintenance or updates by authorized personnel may trigger ACL deletions. Verify if the deletion aligns with scheduled maintenance activities and consider excluding these events from alerts. +- Automated scripts or tools used for infrastructure management might delete and recreate ACLs as part of their normal operation. Identify these scripts and whitelist their actions to prevent unnecessary alerts. +- Changes in security policies or architecture might necessitate the removal of certain ACLs. Ensure that such changes are documented and approved, and exclude these events from monitoring if they are part of a planned update. +- Test environments often undergo frequent configuration changes, including ACL deletions. Differentiate between production and test environments and adjust monitoring rules to reduce false positives in non-production settings. + +### Response and remediation + +- Immediately revoke any access keys or credentials associated with the user or role that performed the ACL deletion to prevent further unauthorized actions. +- Restore the deleted AWS WAF Access Control List from a backup or recreate it using documented configurations to re-establish protective rules. +- Conduct a thorough review of recent access logs and CloudTrail events to identify any unauthorized access or data exfiltration attempts that may have occurred following the ACL deletion. +- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring and alerting for any future attempts to delete or modify AWS WAF ACLs, ensuring rapid detection and response. +- Review and tighten IAM policies to ensure that only authorized personnel have permissions to delete or modify AWS WAF configurations. +- Consider enabling AWS Config rules to continuously monitor and alert on changes to critical AWS resources, including WAF ACLs, to prevent similar incidents. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/aws/defense_evasion_waf_rule_or_rule_group_deletion.toml b/rules/integrations/aws/defense_evasion_waf_rule_or_rule_group_deletion.toml index 1206af84945..5583b5235ed 100644 --- a/rules/integrations/aws/defense_evasion_waf_rule_or_rule_group_deletion.toml +++ b/rules/integrations/aws/defense_evasion_waf_rule_or_rule_group_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/06/09" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -20,7 +20,43 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS WAF Rule or Rule Group Deletion" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS WAF Rule or Rule Group Deletion + +AWS Web Application Firewall (WAF) protects web applications by filtering and monitoring HTTP requests. Adversaries may delete WAF rules or groups to disable security measures, facilitating attacks like SQL injection or cross-site scripting. The detection rule monitors AWS CloudTrail logs for successful deletion actions, signaling potential defense evasion attempts by identifying unauthorized or suspicious deletions. + +### Possible investigation steps + +- Review the AWS CloudTrail logs to identify the user or role associated with the deletion action by examining the userIdentity field. +- Check the event.time field in the CloudTrail logs to determine when the deletion occurred and correlate it with any other suspicious activities around the same time. +- Investigate the source IP address and user agent from the CloudTrail logs to assess if the request originated from a known or expected location and device. +- Verify if the deleted WAF rule or rule group was part of a critical security configuration by reviewing the AWS WAF setup and any associated documentation. +- Contact the user or team responsible for AWS WAF management to confirm if the deletion was authorized and understand the rationale behind it. +- Examine any recent changes in IAM policies or permissions that might have allowed unauthorized users to perform the deletion action. + +### False positive analysis + +- Routine maintenance or updates by authorized personnel can trigger rule deletions. Verify if the deletion aligns with scheduled maintenance activities and consider excluding these events from alerts. +- Automated scripts or tools used for infrastructure management might delete and recreate WAF rules as part of their normal operation. Identify these scripts and whitelist their actions to prevent unnecessary alerts. +- Changes in security policies or architecture might necessitate the removal of certain WAF rules. Ensure that such changes are documented and approved, and exclude these documented actions from triggering alerts. +- Temporary rule deletions for testing purposes by security teams can be mistaken for malicious activity. Coordinate with the security team to log these activities and exclude them from detection rules. +- Ensure that IAM roles or users with permissions to delete WAF rules are reviewed regularly. Exclude actions performed by trusted roles or users after confirming their legitimacy. + +### Response and remediation + +- Immediately review AWS CloudTrail logs to confirm the unauthorized deletion of WAF rules or rule groups and identify the source of the action, including the IAM user or role involved. +- Reapply the deleted WAF rules or rule groups to restore the intended security posture and prevent potential attacks such as SQL injection or cross-site scripting. +- Temporarily restrict or revoke permissions for the identified IAM user or role to prevent further unauthorized actions until a thorough investigation is completed. +- Conduct a security review of the affected AWS environment to identify any other potential security gaps or unauthorized changes that may have occurred. +- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring and alerting for AWS WAF configuration changes to detect and respond to similar unauthorized actions promptly in the future. +- Consider enabling AWS Config rules to continuously monitor and enforce compliance with WAF configurations, ensuring any unauthorized changes are automatically flagged. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/aws/discovery_ec2_multi_region_describe_instances.toml b/rules/integrations/aws/discovery_ec2_multi_region_describe_instances.toml index ac33fffcfe4..b44db7e2dc0 100644 --- a/rules/integrations/aws/discovery_ec2_multi_region_describe_instances.toml +++ b/rules/integrations/aws/discovery_ec2_multi_region_describe_instances.toml @@ -2,7 +2,7 @@ creation_date = "2024/08/26" integration = ["aws"] maturity = "production" -updated_date = "2024/11/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -23,7 +23,7 @@ from = "now-9m" language = "esql" license = "Elastic License v2" name = "AWS EC2 Multi-Region DescribeInstances API Calls" -note = """## Triage and Analysis +note = """## Triage and analysis ### Investigating AWS EC2 Multi-Region DescribeInstances API Calls diff --git a/rules/integrations/aws/discovery_ec2_multiple_discovery_api_calls_via_cli.toml b/rules/integrations/aws/discovery_ec2_multiple_discovery_api_calls_via_cli.toml index a3e05953da5..8b82b3bac15 100644 --- a/rules/integrations/aws/discovery_ec2_multiple_discovery_api_calls_via_cli.toml +++ b/rules/integrations/aws/discovery_ec2_multiple_discovery_api_calls_via_cli.toml @@ -4,7 +4,7 @@ integration = ["aws"] maturity = "production" min_stack_comments = "ES|QL rule type is still in technical preview as of 8.13, however this rule was tested successfully" min_stack_version = "8.13.0" -updated_date = "2024/11/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -24,7 +24,7 @@ from = "now-9m" language = "esql" license = "Elastic License v2" name = "AWS Discovery API Calls via CLI from a Single Resource" -note = """## Triage and Analysis +note = """## Triage and analysis ### Investigating AWS Discovery API Calls via CLI from a Single Resource diff --git a/rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml b/rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml index e0fa48aacb1..a64df95e82b 100644 --- a/rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml +++ b/rules/integrations/aws/discovery_servicequotas_multi_region_service_quota_requests.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2024/08/26" maturity = "production" -updated_date = "2024/10/09" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -60,6 +60,40 @@ from logs-aws.cloudtrail-* // sort the results by time windows in descending order | sort target_time_window desc ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS Service Quotas Multi-Region `GetServiceQuota` Requests + +AWS Service Quotas manage resource limits across AWS services, crucial for maintaining operational boundaries. Adversaries may exploit `GetServiceQuota` API calls to probe AWS infrastructure, seeking vulnerabilities for deploying threats like cryptocurrency miners. The detection rule identifies unusual multi-region queries for EC2 quotas, signaling potential credential compromise or unauthorized access attempts. + +### Possible investigation steps + +- Review the AWS CloudTrail logs to identify the specific user or role associated with the `aws.cloudtrail.user_identity.arn` field that triggered the alert. Determine if this user or role should have access to multiple regions. +- Examine the `cloud.region` field to identify which regions were accessed and verify if these regions are typically used by your organization. Investigate any unfamiliar regions for unauthorized activity. +- Check the AWS IAM policies and permissions associated with the identified user or role to ensure they align with the principle of least privilege. Look for any recent changes or anomalies in permissions. +- Investigate the source IP addresses and locations from which the `GetServiceQuota` API calls were made to determine if they match expected patterns for your organization. Look for any unusual or suspicious IP addresses. +- Review recent activity logs for the identified user or role to detect any other unusual or unauthorized actions, such as attempts to launch EC2 instances or access other AWS services. +- If a compromise is suspected, consider rotating the credentials for the affected user or role and implementing additional security measures, such as multi-factor authentication (MFA) and enhanced monitoring. + +### False positive analysis + +- Legitimate multi-region operations: Organizations with a global presence may have legitimate reasons for querying EC2 service quotas across multiple regions. To handle this, users can create exceptions for known accounts or roles that regularly perform such operations. +- Automated infrastructure management tools: Some tools or scripts designed for infrastructure management might perform multi-region `GetServiceQuota` requests as part of their normal operation. Users should identify these tools and exclude their activity from triggering alerts by whitelisting their associated user identities or ARNs. +- Testing and development activities: Developers or testers might intentionally perform multi-region queries during testing phases. Users can mitigate false positives by setting up temporary exceptions for specific time frames or user identities involved in testing. +- Cloud service providers or partners: Third-party services or partners managing AWS resources on behalf of an organization might generate similar patterns. Users should establish trust relationships and exclude these entities from detection by verifying their activities and adding them to an exception list. + +### Response and remediation + +- Immediately isolate the AWS account or IAM user identified in the alert to prevent further unauthorized access. This can be done by disabling the access keys or suspending the account temporarily. +- Conduct a thorough review of the AWS CloudTrail logs for the identified user or resource to determine the extent of the unauthorized activity and identify any other potentially compromised resources. +- Rotate all access keys and passwords associated with the compromised account or IAM user to prevent further unauthorized access. +- Implement additional security measures such as enabling multi-factor authentication (MFA) for all IAM users and roles to enhance account security. +- Notify the security operations team and relevant stakeholders about the potential compromise and the steps being taken to remediate the issue. +- If evidence of compromise is confirmed, consider engaging AWS Support or a third-party incident response team for further investigation and assistance. +- Review and update IAM policies and permissions to ensure the principle of least privilege is enforced, reducing the risk of future unauthorized access attempts.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/integrations/aws/execution_lambda_external_layer_added_to_function.toml b/rules/integrations/aws/execution_lambda_external_layer_added_to_function.toml index edd6adb3742..e41ca5a755c 100644 --- a/rules/integrations/aws/execution_lambda_external_layer_added_to_function.toml +++ b/rules/integrations/aws/execution_lambda_external_layer_added_to_function.toml @@ -2,7 +2,7 @@ creation_date = "2024/04/30" integration = ["aws"] maturity = "production" -updated_date = "2024/07/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -19,7 +19,7 @@ language = "kuery" license = "Elastic License v2" name = "AWS Lambda Layer Added to Existing Function" note = """ -## Triage and Analysis +## Triage and analysis ### Investigating AWS Lambda Layer Added to Existing Function diff --git a/rules/integrations/aws/execution_new_terms_cloudformation_createstack.toml b/rules/integrations/aws/execution_new_terms_cloudformation_createstack.toml index 6dcc33f9728..11ebc853d10 100644 --- a/rules/integrations/aws/execution_new_terms_cloudformation_createstack.toml +++ b/rules/integrations/aws/execution_new_terms_cloudformation_createstack.toml @@ -2,7 +2,7 @@ creation_date = "2020/07/25" integration = ["aws"] maturity = "production" -updated_date = "2024/11/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -49,6 +49,41 @@ query = ''' event.dataset:aws.cloudtrail and event.provider:cloudformation.amazonaws.com and event.action: (CreateStack or CreateStackSet) and event.outcome:success ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 First Time AWS Cloudformation Stack Creation by User + +AWS CloudFormation automates the setup of cloud resources using templates, streamlining infrastructure management. Adversaries with access can exploit this to deploy malicious resources, escalating their control. The detection rule identifies unusual activity by flagging the initial use of stack creation APIs by a user, helping to spot potential unauthorized actions early. + +### Possible investigation steps + +- Review the CloudTrail logs for the specific event.dataset:aws.cloudtrail and event.provider:cloudformation.amazonaws.com to identify the user or role that initiated the CreateStack or CreateStackSet action. +- Verify the IAM permissions of the user or role involved in the event to ensure they have the appropriate level of access and determine if the action aligns with their typical responsibilities. +- Examine the stack template used in the CreateStack or CreateStackSet action to identify any unusual or unauthorized resources being provisioned. +- Check the event.outcome:success field to confirm the stack creation was successful and investigate any related resources that were deployed as part of the stack. +- Correlate the timing of the stack creation with other logs or alerts to identify any suspicious activity or patterns that might indicate malicious intent. +- Investigate the account's recent activity history to determine if there have been any other first-time or unusual actions by the same user or role. + +### False positive analysis + +- Routine infrastructure updates by authorized users may trigger the rule. To manage this, maintain a list of users or roles that regularly perform these updates and create exceptions for them. +- Automated deployment tools or scripts that use CloudFormation for legitimate purposes can cause false positives. Identify these tools and exclude their associated IAM roles or users from the rule. +- New team members or roles onboarding into cloud management tasks might be flagged. Implement a process to review and whitelist these users after verifying their activities. +- Scheduled or periodic stack creations for testing or development environments can be mistaken for suspicious activity. Document these schedules and exclude the relevant users or roles from the rule. +- Third-party services or integrations that require stack creation permissions could be misidentified. Ensure these services are documented and their actions are excluded from triggering the rule. + +### Response and remediation + +- Immediately isolate the IAM user or role that initiated the stack creation to prevent further unauthorized actions. This can be done by revoking permissions or disabling the account temporarily. +- Review the created stack and stack set for any unauthorized or suspicious resources. Identify and terminate any resources that are not part of the expected infrastructure. +- Conduct a thorough audit of recent IAM activity to identify any other unusual or unauthorized actions that may indicate further compromise. +- If malicious activity is confirmed, escalate the incident to the security operations team for a full investigation and potential involvement of incident response teams. +- Implement additional monitoring and alerting for the affected account to detect any further unauthorized attempts to use CloudFormation or other critical AWS services. +- Review and tighten IAM policies and permissions to ensure that only necessary privileges are granted, reducing the risk of exploitation by adversaries. +- Consider enabling AWS CloudTrail logging and AWS Config rules to maintain a detailed record of all API activity and configuration changes for ongoing monitoring and compliance.""" [[rule.threat]] diff --git a/rules/integrations/aws/execution_ssm_command_document_created_by_rare_user.toml b/rules/integrations/aws/execution_ssm_command_document_created_by_rare_user.toml index 6062fe1ad86..d3dc371b5c1 100644 --- a/rules/integrations/aws/execution_ssm_command_document_created_by_rare_user.toml +++ b/rules/integrations/aws/execution_ssm_command_document_created_by_rare_user.toml @@ -2,7 +2,7 @@ creation_date = "2024/11/01" integration = ["aws"] maturity = "production" -updated_date = "2024/11/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"] language = "kuery" license = "Elastic License v2" name = "AWS SSM Command Document Created by Rare User" -note = """## Triage and Analysis +note = """## Triage and analysis ### Investigating AWS SSM Command Document Created by Rare User diff --git a/rules/integrations/aws/execution_ssm_sendcommand_by_rare_user.toml b/rules/integrations/aws/execution_ssm_sendcommand_by_rare_user.toml index 4f860173b1c..e1b47b34a84 100644 --- a/rules/integrations/aws/execution_ssm_sendcommand_by_rare_user.toml +++ b/rules/integrations/aws/execution_ssm_sendcommand_by_rare_user.toml @@ -2,7 +2,7 @@ creation_date = "2020/07/06" integration = ["aws"] maturity = "production" -updated_date = "2024/11/05" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -26,7 +26,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"] language = "kuery" license = "Elastic License v2" name = "AWS SSM `SendCommand` Execution by Rare User" -note = """## Triage and Analysis +note = """## Triage and analysis ### Investigating AWS SSM `SendCommand` Execution by Rare User diff --git a/rules/integrations/aws/exfiltration_ec2_ami_shared_with_separate_account.toml b/rules/integrations/aws/exfiltration_ec2_ami_shared_with_separate_account.toml index bc1ecf1dadb..83092ce7ae9 100644 --- a/rules/integrations/aws/exfiltration_ec2_ami_shared_with_separate_account.toml +++ b/rules/integrations/aws/exfiltration_ec2_ami_shared_with_separate_account.toml @@ -2,7 +2,7 @@ creation_date = "2024/04/16" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -24,7 +24,7 @@ language = "kuery" license = "Elastic License v2" name = "EC2 AMI Shared with Another Account" note = """ -## Triage and Analysis +## Triage and analysis ### Investigating EC2 AMI Shared with Another Account diff --git a/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml b/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml index 926072b8026..dc5a7b6745e 100644 --- a/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml +++ b/rules/integrations/aws/exfiltration_ec2_ebs_snapshot_shared_with_another_account.toml @@ -4,7 +4,7 @@ integration = ["aws"] maturity = "production" min_stack_comments = "AWS integration breaking changes, bumping version to ^2.0.0" min_stack_version = "8.13.0" -updated_date = "2024/10/02" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -24,7 +24,7 @@ license = "Elastic License v2" name = "AWS EC2 EBS Snapshot Shared with Another Account" note = """ -## Triage and Analysis +## Triage and analysis ### Investigating AWS EC2 EBS Snapshot Shared with Another Account diff --git a/rules/integrations/aws/exfiltration_ec2_full_network_packet_capture_detected.toml b/rules/integrations/aws/exfiltration_ec2_full_network_packet_capture_detected.toml index e809fcaf22f..0d076751b11 100644 --- a/rules/integrations/aws/exfiltration_ec2_full_network_packet_capture_detected.toml +++ b/rules/integrations/aws/exfiltration_ec2_full_network_packet_capture_detected.toml @@ -2,7 +2,7 @@ creation_date = "2021/05/05" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic", "Austin Songer"] @@ -24,7 +24,43 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS EC2 Full Network Packet Capture Detected" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS EC2 Full Network Packet Capture Detected + +Traffic Mirroring in AWS EC2 allows copying of network traffic for monitoring and analysis, crucial for security and performance insights. However, adversaries can exploit this by capturing unencrypted data, leading to potential data exfiltration. The detection rule identifies successful creation of traffic mirroring components, signaling possible misuse for unauthorized data collection. + +### Possible investigation steps + +- Review the CloudTrail logs for the specific event actions: CreateTrafficMirrorFilter, CreateTrafficMirrorFilterRule, CreateTrafficMirrorSession, and CreateTrafficMirrorTarget to identify the user or role that initiated these actions. +- Check the event.outcome field to confirm the success of the traffic mirroring setup and gather details about the time and source IP address of the request. +- Investigate the associated Elastic Network Interface (ENI) to determine which EC2 instance is involved and assess its role and importance within the network. +- Analyze the network traffic patterns and data flow from the mirrored traffic to identify any signs of data exfiltration or unusual data transfer activities. +- Verify the encryption status of the network traffic being mirrored to assess the risk of sensitive data exposure. +- Cross-reference the involved AWS account and IAM roles with known threat actor profiles or previous security incidents to identify potential insider threats or compromised accounts. + +### False positive analysis + +- Routine network monitoring activities may trigger the rule if legitimate traffic mirroring is set up for performance analysis. To manage this, identify and document authorized traffic mirroring configurations and exclude them from alerts. +- Security audits or compliance checks might involve creating traffic mirroring sessions. Coordinate with audit teams to schedule these activities and temporarily suppress alerts during these periods. +- Development and testing environments often use traffic mirroring for debugging purposes. Maintain a list of such environments and apply exceptions to avoid unnecessary alerts. +- Automated infrastructure management tools might create traffic mirroring components as part of their operations. Review and whitelist these tools to prevent false positives. +- Ensure that any third-party services with access to your AWS environment are vetted and their activities are monitored to distinguish between legitimate and suspicious traffic mirroring actions. + +### Response and remediation + +- Immediately isolate the affected EC2 instance to prevent further data exfiltration. This can be done by removing the instance from any network access or security groups that allow outbound traffic. +- Review and terminate any unauthorized Traffic Mirroring sessions, filters, or targets that were created. Ensure that only legitimate and necessary mirroring configurations are active. +- Conduct a thorough audit of the AWS CloudTrail logs to identify any other suspicious activities or unauthorized access attempts related to Traffic Mirroring or other sensitive operations. +- Rotate and update any credentials or access keys that may have been exposed or compromised during the incident to prevent further unauthorized access. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. Escalate to higher management if the data exfiltration involves sensitive or critical data. +- Implement additional network monitoring and intrusion detection measures to enhance visibility and detect similar threats in the future. Consider using AWS GuardDuty or similar services for continuous threat detection. +- Review and update security policies and access controls to ensure that Traffic Mirroring and other sensitive features are only accessible to authorized personnel with a legitimate need. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/aws/exfiltration_ec2_vm_export_failure.toml b/rules/integrations/aws/exfiltration_ec2_vm_export_failure.toml index 6b99a4eed46..deef65a43ee 100644 --- a/rules/integrations/aws/exfiltration_ec2_vm_export_failure.toml +++ b/rules/integrations/aws/exfiltration_ec2_vm_export_failure.toml @@ -2,7 +2,7 @@ creation_date = "2021/04/22" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic", "Austin Songer"] @@ -23,7 +23,41 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS EC2 VM Export Failure" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS EC2 VM Export Failure + +AWS EC2 allows users to export virtual machines for backup or migration. However, adversaries might exploit this feature to exfiltrate sensitive data by exporting VMs to unauthorized locations. The detection rule monitors failed export attempts, focusing on specific AWS CloudTrail events, to identify potential exfiltration activities, thereby alerting security teams to investigate further. + +### Possible investigation steps + +- Review the AWS CloudTrail logs for the specific event.action: CreateInstanceExportTask with event.outcome: failure to gather details about the failed export attempt, including timestamps, source IP addresses, and user identities involved. +- Investigate the IAM user or role associated with the failed export attempt to determine if the action was authorized or if there are any signs of compromised credentials. +- Check the AWS account's export policies and permissions to ensure they are configured correctly and restrict unauthorized export attempts. +- Analyze any recent changes in the AWS environment, such as new IAM roles or policy modifications, that could be related to the failed export attempt. +- Correlate the failed export attempt with other security events or alerts in the environment to identify any patterns or potential coordinated activities indicating a broader threat. + +### False positive analysis + +- Routine backup operations may trigger the rule if they involve failed export attempts. To manage this, identify and whitelist specific IAM roles or users that regularly perform legitimate backup tasks. +- Development and testing environments often involve frequent export attempts for non-production instances. Exclude these environments by tagging instances appropriately and adjusting the detection rule to ignore these tags. +- Misconfigured export tasks due to incorrect permissions or settings can lead to false positives. Regularly review and update IAM policies and export configurations to ensure they align with intended operations. +- Automated scripts or tools that manage EC2 instances might occasionally fail due to transient issues, causing false alerts. Monitor and log these scripts' activities to distinguish between expected failures and potential threats. + +### Response and remediation + +- Immediately isolate the affected AWS account to prevent further unauthorized export attempts. This can be done by restricting permissions or temporarily suspending the account. +- Review and revoke any suspicious or unauthorized IAM roles or policies that may have been used to initiate the failed export attempt. +- Conduct a thorough audit of recent AWS CloudTrail logs to identify any other unusual activities or patterns that may indicate a broader compromise. +- Notify the security operations team and relevant stakeholders about the incident for further investigation and potential escalation. +- Implement additional monitoring and alerting for successful and failed VM export attempts to ensure rapid detection of similar activities in the future. +- Enhance IAM policies to enforce the principle of least privilege, ensuring only authorized users have the necessary permissions to export EC2 instances. +- Consider enabling AWS Config rules to continuously monitor and enforce compliance with security best practices related to EC2 instance exports. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://docs.aws.amazon.com/vm-import/latest/userguide/vmexport.html#export-instance"] diff --git a/rules/integrations/aws/exfiltration_rds_snapshot_export.toml b/rules/integrations/aws/exfiltration_rds_snapshot_export.toml index 3acc55c151f..29f9a59228b 100644 --- a/rules/integrations/aws/exfiltration_rds_snapshot_export.toml +++ b/rules/integrations/aws/exfiltration_rds_snapshot_export.toml @@ -2,7 +2,7 @@ creation_date = "2021/06/06" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic", "Austin Songer"] @@ -20,7 +20,42 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS RDS Snapshot Export" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS RDS Snapshot Export + +Amazon RDS Snapshot Export allows users to export Aurora database snapshots to Amazon S3, facilitating data analysis and backup. However, adversaries may exploit this feature to exfiltrate sensitive data by exporting snapshots without authorization. The detection rule monitors successful export tasks in AWS CloudTrail logs, flagging potential misuse by identifying unexpected or unauthorized snapshot exports. + +### Possible investigation steps + +- Review the AWS CloudTrail logs for the specific event.action:StartExportTask to identify the user or role that initiated the export task. +- Check the event.provider:rds.amazonaws.com logs to verify the source IP address and location from which the export task was initiated, looking for any anomalies or unexpected locations. +- Investigate the event.dataset:aws.cloudtrail logs to determine the specific database snapshot that was exported and assess its sensitivity or criticality. +- Cross-reference the event.outcome:success with IAM policies and permissions to ensure the user or role had legitimate access to perform the export task. +- Analyze any recent changes in IAM roles or policies that might have inadvertently granted export permissions to unauthorized users. +- Contact the data owner or relevant stakeholders to confirm whether the export task was authorized and aligns with business needs. + +### False positive analysis + +- Routine data exports for legitimate business purposes may trigger alerts. Users should review export tasks to confirm they align with expected business operations and consider whitelisting known, authorized export activities. +- Automated backup processes that regularly export snapshots to S3 can be mistaken for unauthorized actions. Identify and document these processes, then create exceptions in the monitoring system to prevent false alerts. +- Development and testing environments often involve frequent snapshot exports for testing purposes. Ensure these environments are clearly identified and excluded from alerts by setting up specific rules or tags that differentiate them from production environments. +- Exports initiated by third-party services or integrations that have been granted access to RDS snapshots might be flagged. Verify these integrations and adjust the detection rule to recognize and exclude these trusted services. + +### Response and remediation + +- Immediately revoke access to the AWS account or IAM role that initiated the unauthorized snapshot export to prevent further data exfiltration. +- Conduct a thorough review of AWS CloudTrail logs to identify any other unauthorized activities associated with the same account or IAM role, and assess the scope of the potential data breach. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized export and any other suspicious activities discovered. +- Restore the affected database from a known good backup if data integrity is suspected to be compromised, ensuring that the restored data is free from unauthorized changes. +- Implement stricter IAM policies and permissions to limit who can perform snapshot exports, ensuring that only authorized personnel have the necessary permissions. +- Enhance monitoring and alerting mechanisms to detect any future unauthorized snapshot export attempts, ensuring timely response to similar threats. +- Conduct a post-incident review to identify gaps in security controls and update incident response plans to improve readiness for future incidents. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_StartExportTask.html"] diff --git a/rules/integrations/aws/exfiltration_rds_snapshot_shared_with_another_account.toml b/rules/integrations/aws/exfiltration_rds_snapshot_shared_with_another_account.toml index 20d686e65be..5851cc6b77b 100644 --- a/rules/integrations/aws/exfiltration_rds_snapshot_shared_with_another_account.toml +++ b/rules/integrations/aws/exfiltration_rds_snapshot_shared_with_another_account.toml @@ -2,7 +2,7 @@ creation_date = "2024/06/25" integration = ["aws"] maturity = "production" -updated_date = "2024/07/06" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -20,7 +20,7 @@ language = "eql" license = "Elastic License v2" name = "AWS RDS DB Snapshot Shared with Another Account" note = """ -## Triage and Analysis +## Triage and analysis ### Investigating AWS RDS DB Snapshot Shared with Another Account @@ -81,7 +81,7 @@ query = ''' any where event.dataset == "aws.cloudtrail" and event.provider == "rds.amazonaws.com" and event.outcome == "success" - and event.action in ("ModifyDBSnapshotAttribute", "ModifyDBClusterSnapshotAttribute") + and event.action in ("ModifyDBSnapshotAttribute", "ModifyDBClusterSnapshotAttribute") and stringContains(aws.cloudtrail.request_parameters, "attributeName=restore") and stringContains(aws.cloudtrail.request_parameters, "valuesToAdd=[*]") ''' diff --git a/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml b/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml index 814222060d1..c70cf9217fa 100644 --- a/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml +++ b/rules/integrations/aws/exfiltration_s3_bucket_policy_added_for_external_account_access.toml @@ -2,7 +2,7 @@ creation_date = "2024/04/17" integration = ["aws"] maturity = "production" -updated_date = "2024/07/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -23,7 +23,7 @@ language = "eql" license = "Elastic License v2" name = "AWS S3 Bucket Policy Added to Share with External Account" note = """ -## Triage and Analysis +## Triage and analysis ### Investigating AWS S3 Bucket Policy Change to Share with External Account diff --git a/rules/integrations/aws/exfiltration_s3_bucket_replicated_to_external_account.toml b/rules/integrations/aws/exfiltration_s3_bucket_replicated_to_external_account.toml index 1939fa0d9ec..27d30ee7048 100644 --- a/rules/integrations/aws/exfiltration_s3_bucket_replicated_to_external_account.toml +++ b/rules/integrations/aws/exfiltration_s3_bucket_replicated_to_external_account.toml @@ -2,7 +2,7 @@ creation_date = "2024/07/12" integration = ["aws"] maturity = "production" -updated_date = "2024/07/12" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -20,7 +20,7 @@ language = "eql" license = "Elastic License v2" name = "AWS S3 Bucket Replicated to Another Account" note = """ -## Triage and Analysis +## Triage and analysis ### Investigating AWS S3 Bucket Replicated to Another Account @@ -73,9 +73,9 @@ timestamp_override = "event.ingested" type = "eql" query = ''' -any where event.dataset == "aws.cloudtrail" +any where event.dataset == "aws.cloudtrail" and event.action == "PutBucketReplication" - and event.outcome == "success" + and event.outcome == "success" and stringContains(aws.cloudtrail.request_parameters, "Account") ''' diff --git a/rules/integrations/aws/exfiltration_sns_email_subscription_by_rare_user.toml b/rules/integrations/aws/exfiltration_sns_email_subscription_by_rare_user.toml index 256caac2f0b..ec60aad4466 100644 --- a/rules/integrations/aws/exfiltration_sns_email_subscription_by_rare_user.toml +++ b/rules/integrations/aws/exfiltration_sns_email_subscription_by_rare_user.toml @@ -2,7 +2,7 @@ creation_date = "2024/11/01" integration = ["aws"] maturity = "production" -updated_date = "2024/11/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"] language = "kuery" license = "Elastic License v2" name = "AWS SNS Email Subscription by Rare User" -note = """## Triage and Analysis +note = """## Triage and analysis ### Investigating AWS SNS Email Subscription by Rare User diff --git a/rules/integrations/aws/impact_aws_eventbridge_rule_disabled_or_deleted.toml b/rules/integrations/aws/impact_aws_eventbridge_rule_disabled_or_deleted.toml index 4dced14d748..8b067da8dd0 100644 --- a/rules/integrations/aws/impact_aws_eventbridge_rule_disabled_or_deleted.toml +++ b/rules/integrations/aws/impact_aws_eventbridge_rule_disabled_or_deleted.toml @@ -2,7 +2,7 @@ creation_date = "2021/10/17" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Austin Songer"] @@ -23,7 +23,43 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"] language = "kuery" license = "Elastic License v2" name = "AWS EventBridge Rule Disabled or Deleted" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS EventBridge Rule Disabled or Deleted + +AWS EventBridge is a serverless event bus service that enables applications to respond to changes in data. Disabling or deleting rules can disrupt event-driven workflows, potentially masking malicious activities. Adversaries might exploit this by halting security alerts or data flows. The detection rule monitors successful disable or delete actions on EventBridge rules, flagging potential misuse that could impact system visibility and integrity. + +### Possible investigation steps + +- Review the CloudTrail logs to identify the user or role associated with the DeleteRule or DisableRule action by examining the user identity information in the event logs. +- Check the event time and correlate it with other activities in the AWS account to determine if there are any related suspicious actions or patterns. +- Investigate the specific EventBridge rule that was disabled or deleted to understand its purpose and the potential impact on workflows or security monitoring. +- Assess the permissions and roles of the user who performed the action to determine if they had legitimate access and reasons for modifying the EventBridge rule. +- Look for any recent changes in IAM policies or roles that might have granted new permissions to the user or role involved in the action. +- Contact the user or team responsible for the action to verify if the change was intentional and authorized, and document their response for future reference. + +### False positive analysis + +- Routine maintenance or updates by administrators can lead to the disabling or deletion of EventBridge rules. To manage this, create exceptions for known maintenance windows or specific user actions that are documented and approved. +- Automated scripts or tools used for infrastructure management might disable or delete rules as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific user or role identifiers. +- Testing environments often involve frequent changes to EventBridge rules, including disabling or deleting them. Exclude actions within these environments by filtering based on environment tags or specific resource identifiers. +- Scheduled tasks that involve disabling rules temporarily for performance reasons can be a source of false positives. Document these schedules and configure the detection rule to ignore actions during these periods. +- Changes made by trusted third-party services or integrations that manage EventBridge rules should be reviewed and, if deemed non-threatening, excluded by identifying the service accounts or API keys used. + +### Response and remediation + +- Immediately re-enable or recreate the disabled or deleted EventBridge rule to restore the intended event-driven workflows and ensure continuity of operations. +- Conduct a review of CloudTrail logs to identify the user or service account responsible for the action, and verify if the action was authorized and legitimate. +- If unauthorized activity is detected, revoke access for the compromised account and initiate a password reset or key rotation for the affected credentials. +- Notify the security operations team to assess the potential impact on system visibility and integrity, and to determine if further investigation is required. +- Implement additional monitoring and alerting for changes to EventBridge rules to detect similar activities in the future. +- Escalate the incident to the incident response team if there is evidence of malicious intent or if the activity aligns with known threat patterns, such as those described in MITRE ATT&CK technique T1489 (Service Stop). +- Review and update IAM policies to ensure that only authorized users have the necessary permissions to modify EventBridge rules, reducing the risk of unauthorized changes. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml b/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml index 06305eb8968..3c67566be9f 100644 --- a/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml +++ b/rules/integrations/aws/impact_ec2_disable_ebs_encryption.toml @@ -2,7 +2,7 @@ creation_date = "2020/06/05" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -23,7 +23,42 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS EC2 Encryption Disabled" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS EC2 Encryption Disabled + +Amazon EC2's EBS encryption ensures data at rest is secure by default. Disabling this feature can expose sensitive data, making it vulnerable to unauthorized access. Adversaries might exploit this by disabling encryption to access or manipulate data without detection. The detection rule monitors CloudTrail logs for successful attempts to disable EBS encryption, alerting security teams to potential misuse. + +### Possible investigation steps + +- Review the CloudTrail logs for the specific event.action: DisableEbsEncryptionByDefault to identify the user or role that initiated the action. +- Check the event.provider: ec2.amazonaws.com logs to gather additional context about the environment and any related activities around the time of the event. +- Investigate the IAM policies and permissions associated with the user or role to determine if they have the necessary permissions to disable EBS encryption and if those permissions are appropriate. +- Assess the event.outcome: success to confirm that the action was completed successfully and identify any subsequent actions taken by the same user or role. +- Examine the AWS account's security settings and configurations to ensure that no other security features have been altered or disabled. +- Contact the user or team responsible for the action to understand the rationale behind disabling EBS encryption and verify if it aligns with organizational policies. + +### False positive analysis + +- Routine administrative actions may trigger alerts if encryption is disabled for testing or configuration purposes. To manage this, create exceptions for specific IAM roles or users known to perform these tasks regularly. +- Automated scripts or tools that disable encryption for specific workflows might cause false positives. Identify these scripts and exclude their associated actions from triggering alerts by using specific tags or identifiers. +- Changes in regional settings or policies that temporarily disable encryption could be misinterpreted as threats. Monitor these changes and adjust the detection rule to account for legitimate policy updates. +- Scheduled maintenance or updates that require temporary encryption disabling should be documented and excluded from alerts by setting time-based exceptions during known maintenance windows. + +### Response and remediation + +- Immediately isolate the affected EC2 instances to prevent further unauthorized access or data manipulation. This can be done by modifying security group rules or network ACLs to restrict access. +- Re-enable EBS encryption by default in the affected region to ensure that all new volumes are encrypted. This can be done through the AWS Management Console or AWS CLI. +- Conduct a thorough review of recent changes in the AWS environment to identify any unauthorized modifications or access patterns. Focus on CloudTrail logs for any suspicious activity related to EBS encryption settings. +- Notify the security operations team and relevant stakeholders about the incident, providing them with details of the alert and any initial findings. +- Implement additional monitoring and alerting for any future attempts to disable EBS encryption by default, ensuring that security teams are promptly notified of similar activities. +- Review and update IAM policies to ensure that only authorized personnel have the necessary permissions to modify EBS encryption settings, reducing the risk of accidental or malicious changes. +- If any data manipulation is detected, initiate data recovery procedures to restore affected data from backups, ensuring data integrity and availability. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/aws/impact_efs_filesystem_or_mount_deleted.toml b/rules/integrations/aws/impact_efs_filesystem_or_mount_deleted.toml index 289a125097f..255a0ae64a7 100644 --- a/rules/integrations/aws/impact_efs_filesystem_or_mount_deleted.toml +++ b/rules/integrations/aws/impact_efs_filesystem_or_mount_deleted.toml @@ -2,7 +2,7 @@ creation_date = "2021/08/27" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Austin Songer"] @@ -24,7 +24,43 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS EFS File System or Mount Deleted" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS EFS File System or Mount Deleted + +Amazon Elastic File System (EFS) provides scalable file storage for use with AWS cloud services and on-premises resources. Adversaries may target EFS by deleting file systems or mount targets, disrupting applications reliant on these resources. The detection rule monitors AWS CloudTrail logs for successful deletion events, signaling potential malicious activity aimed at data destruction or service disruption. + +### Possible investigation steps + +- Review the AWS CloudTrail logs to identify the user or role associated with the deletion event by examining the user identity information in the logs. +- Check the event time and correlate it with other activities in the AWS environment to determine if there are any related suspicious actions or patterns. +- Investigate the source IP address and location from which the deletion request was made to assess if it aligns with expected access patterns or if it appears anomalous. +- Verify if there were any recent changes to IAM policies or roles that might have inadvertently granted permissions to delete EFS resources. +- Assess the impact of the deletion by identifying which applications or services were using the deleted EFS file system or mount target and determine if there are any disruptions. +- Contact the user or team responsible for the AWS account to confirm if the deletion was intentional and authorized, or if it was potentially malicious. + +### False positive analysis + +- Routine maintenance activities by system administrators may trigger deletion events. To manage this, create exceptions for known maintenance windows or specific administrator accounts. +- Automated scripts or cloud management tools that manage EFS resources might delete mounts or file systems as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts. +- Development or testing environments often involve frequent creation and deletion of resources. Exclude these environments from the rule to prevent unnecessary alerts. +- Scheduled cleanup jobs that remove unused or temporary file systems can cause false positives. Document these jobs and configure exceptions based on their execution schedule. +- Ensure that any third-party services or integrations with AWS that manage EFS resources are accounted for, and their actions are excluded if they are part of expected behavior. + +### Response and remediation + +- Immediately isolate the affected EFS file system to prevent further unauthorized deletions or access. This can be done by modifying the security group rules to deny all traffic temporarily. +- Review AWS CloudTrail logs to identify the source of the deletion request, including the IAM user or role involved, and assess whether the action was authorized. +- Revoke or adjust permissions for the identified IAM user or role to prevent further unauthorized actions. Ensure that least privilege principles are applied. +- Restore the deleted EFS file system or mount from the most recent backup, if available, to minimize data loss and service disruption. +- Notify the incident response team and relevant stakeholders about the incident for further investigation and to ensure awareness across the organization. +- Conduct a post-incident review to identify any gaps in security controls or processes that allowed the unauthorized deletion, and implement necessary improvements. +- Enhance monitoring and alerting for similar events by ensuring that all critical AWS resources have appropriate logging and alerting configured, focusing on deletion and modification actions. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/aws/impact_iam_group_deletion.toml b/rules/integrations/aws/impact_iam_group_deletion.toml index 97463e97775..06e9523fd17 100644 --- a/rules/integrations/aws/impact_iam_group_deletion.toml +++ b/rules/integrations/aws/impact_iam_group_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/05/21" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -23,7 +23,42 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS IAM Group Deletion" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS IAM Group Deletion + +AWS IAM groups facilitate user management by organizing users with similar permissions. Adversaries might exploit group deletion to disrupt access controls, potentially leading to unauthorized access or service disruption. The detection rule monitors successful group deletions via AWS CloudTrail, flagging potential misuse by correlating specific IAM actions and outcomes, thus aiding in timely threat identification. + +### Possible investigation steps + +- Review the AWS CloudTrail logs to identify the user or role that performed the DeleteGroup action by examining the userIdentity field. +- Check the event time to determine when the group deletion occurred and correlate it with any other suspicious activities around the same timeframe. +- Investigate the specific IAM group that was deleted to understand its purpose and the permissions it granted by reviewing historical IAM policies and group membership. +- Assess the impact of the group deletion by identifying any users or services that might have been affected due to the loss of group-based permissions. +- Verify if the group deletion was authorized by cross-referencing with change management records or contacting the responsible team or individual. +- Look for any patterns or repeated occurrences of similar actions in the logs to identify potential malicious behavior or misconfigurations. + +### False positive analysis + +- Routine administrative tasks may trigger alerts when IAM groups are deleted as part of regular maintenance or restructuring. To manage this, create exceptions for known maintenance periods or specific administrative accounts. +- Automated scripts or tools that manage IAM resources might delete groups as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific user or role identifiers. +- Temporary groups created for short-term projects or testing purposes might be deleted frequently. Document these groups and exclude their deletion from monitoring by using naming conventions or tags. +- Changes in organizational structure or policy might necessitate the deletion of certain groups. Coordinate with relevant teams to anticipate these changes and adjust monitoring rules accordingly. + +### Response and remediation + +- Immediately revoke any active sessions and access keys for users who were part of the deleted IAM group to prevent unauthorized access. +- Restore the deleted IAM group from a backup or recreate it with the same permissions to ensure continuity of access for legitimate users. +- Conduct a review of recent IAM activity logs to identify any unauthorized or suspicious actions that may have preceded the group deletion. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring on IAM activities, especially focusing on group management actions, to detect similar threats in the future. +- Review and tighten IAM policies and permissions to ensure that only authorized personnel can delete IAM groups. +- If malicious intent is suspected, escalate the incident to the incident response team for a comprehensive investigation and potential legal action. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/aws/impact_kms_cmk_disabled_or_scheduled_for_deletion.toml b/rules/integrations/aws/impact_kms_cmk_disabled_or_scheduled_for_deletion.toml index 11c2d13335e..1bfd869dcc6 100644 --- a/rules/integrations/aws/impact_kms_cmk_disabled_or_scheduled_for_deletion.toml +++ b/rules/integrations/aws/impact_kms_cmk_disabled_or_scheduled_for_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2022/09/21" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Xavier Pich"] @@ -25,7 +25,43 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS KMS Customer Managed Key Disabled or Scheduled for Deletion" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS KMS Customer Managed Key Disabled or Scheduled for Deletion + +AWS Key Management Service (KMS) allows users to create and manage cryptographic keys for data encryption. Customer Managed Keys (CMKs) are crucial for securing sensitive data. Adversaries may disable or schedule deletion of CMKs to render encrypted data inaccessible, causing data loss. The detection rule monitors successful disablement or deletion attempts, alerting analysts to potential data destruction activities. + +### Possible investigation steps + +- Review the CloudTrail logs for the specific event.dataset:aws.cloudtrail entries to identify the user or role that initiated the DisableKey or ScheduleKeyDeletion action. +- Check the event.provider:kms.amazonaws.com logs to gather additional context about the KMS key involved, including its key ID and any associated metadata. +- Investigate the event.action:("DisableKey" or "ScheduleKeyDeletion") to determine if the action was authorized and aligns with recent changes or requests within the organization. +- Analyze the event.outcome:success to confirm the success of the action and assess the potential impact on encrypted data. +- Cross-reference the timing of the event with any known incidents or maintenance activities to rule out false positives or expected behavior. +- Contact the user or team responsible for the action to verify the intent and ensure it was a legitimate operation. + +### False positive analysis + +- Routine key management activities by authorized personnel can trigger alerts. Regularly review and document key management procedures to differentiate between legitimate and suspicious activities. +- Automated scripts or tools used for key rotation or lifecycle management might disable or schedule deletion of keys as part of their process. Identify and whitelist these scripts or tools to prevent unnecessary alerts. +- Testing environments where keys are frequently created and deleted for development purposes can generate false positives. Exclude these environments from monitoring or adjust the rule to focus on production environments. +- Scheduled maintenance or compliance audits may involve disabling keys temporarily. Coordinate with relevant teams to schedule these activities and temporarily adjust monitoring rules to avoid false alerts. +- Misconfigured alerts due to incorrect tagging or categorization of keys can lead to false positives. Ensure that all keys are correctly tagged and categorized to align with monitoring rules. + +### Response and remediation + +- Immediately verify the legitimacy of the disablement or deletion action by contacting the key owner or relevant stakeholders to confirm if the action was intentional. +- If the action was unauthorized, revoke any access credentials or permissions associated with the user or service that performed the action to prevent further unauthorized activities. +- Restore access to encrypted data by identifying any backup keys or data recovery options available, and initiate data recovery procedures if possible. +- Escalate the incident to the security operations team and relevant management to assess the impact and coordinate a broader response if necessary. +- Implement additional monitoring and alerting for any further attempts to disable or delete KMS keys, ensuring that alerts are sent to the appropriate personnel for rapid response. +- Review and tighten IAM policies and permissions related to KMS key management to ensure that only authorized personnel have the ability to disable or delete keys. +- Conduct a post-incident review to identify any gaps in the current security posture and update incident response plans to address similar threats in the future. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/aws/impact_rds_group_deletion.toml b/rules/integrations/aws/impact_rds_group_deletion.toml index 989081659af..127e2b4031c 100644 --- a/rules/integrations/aws/impact_rds_group_deletion.toml +++ b/rules/integrations/aws/impact_rds_group_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2021/06/05" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic", "Austin Songer"] @@ -21,7 +21,41 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS RDS Security Group Deletion" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS RDS Security Group Deletion + +Amazon RDS Security Groups control access to RDS instances, acting as a virtual firewall. Adversaries may delete these groups to disrupt database access or cover their tracks. The detection rule monitors AWS CloudTrail logs for successful deletion events of RDS Security Groups, signaling potential unauthorized activity. This helps security analysts quickly identify and respond to suspicious deletions. + +### Possible investigation steps + +- Review the AWS CloudTrail logs to confirm the event details, focusing on the event.provider:rds.amazonaws.com and event.action:DeleteDBSecurityGroup fields to ensure the deletion event is accurately captured. +- Identify the user or role associated with the event by examining the user identity information in the CloudTrail logs to determine if the action was performed by an authorized entity. +- Check the event time and correlate it with other security events or alerts to identify any suspicious activity patterns or sequences that might indicate a broader attack. +- Investigate the context of the deletion by reviewing recent changes or activities in the AWS account, such as modifications to IAM policies or unusual login attempts, to assess if the deletion is part of a larger unauthorized access attempt. +- Contact the relevant database or cloud infrastructure team to verify if the deletion was intentional and authorized, ensuring that it aligns with any ongoing maintenance or decommissioning activities. + +### False positive analysis + +- Routine maintenance activities by authorized personnel may trigger the rule. To manage this, create exceptions for known maintenance windows or specific user accounts that regularly perform these tasks. +- Automated scripts or tools used for infrastructure management might delete security groups as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific identifiers or tags. +- Changes in security group configurations during scheduled updates or migrations can result in deletions. Document these events and adjust the detection rule to ignore deletions during these planned activities. +- Testing environments often involve frequent creation and deletion of resources, including security groups. Exclude these environments from monitoring by using environment-specific tags or identifiers. + +### Response and remediation + +- Immediately isolate the affected RDS instance by modifying its security group settings to restrict all inbound and outbound traffic, preventing further unauthorized access. +- Review AWS CloudTrail logs to identify the source of the deletion request, including the IAM user or role involved, and assess whether the credentials have been compromised. +- Recreate the deleted RDS Security Group with the appropriate rules and reassign it to the affected RDS instance to restore normal operations. +- Conduct a thorough audit of IAM permissions to ensure that only authorized personnel have the ability to delete RDS Security Groups, and revoke any unnecessary permissions. +- Implement multi-factor authentication (MFA) for all IAM users with permissions to modify RDS Security Groups to enhance security and prevent unauthorized changes. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected. +- Update incident response plans and security policies based on the findings to prevent similar incidents in the future and improve overall cloud security posture. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DeleteDBSecurityGroup.html"] diff --git a/rules/integrations/aws/impact_rds_instance_cluster_deletion.toml b/rules/integrations/aws/impact_rds_instance_cluster_deletion.toml index 8648fe43465..63645111abb 100644 --- a/rules/integrations/aws/impact_rds_instance_cluster_deletion.toml +++ b/rules/integrations/aws/impact_rds_instance_cluster_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/05/21" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -23,7 +23,42 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS Deletion of RDS Instance or Cluster" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS Deletion of RDS Instance or Cluster + +Amazon RDS simplifies database management by automating tasks like setup and scaling. However, adversaries can exploit this by deleting RDS instances or clusters, causing data loss and service disruption. The detection rule monitors AWS CloudTrail logs for successful deletion actions, alerting security teams to potential malicious activity aimed at data destruction. + +### Possible investigation steps + +- Review the AWS CloudTrail logs to confirm the event details, focusing on the event.provider as rds.amazonaws.com and event.action values such as DeleteDBCluster, DeleteGlobalCluster, or DeleteDBInstance. +- Identify the user or role responsible for the deletion by examining the user identity information in the CloudTrail logs, and verify if the action aligns with their typical behavior or responsibilities. +- Check the event time and correlate it with any other suspicious activities or alerts in the AWS environment to determine if the deletion is part of a broader attack pattern. +- Investigate the context of the deletion by reviewing recent changes or activities in the AWS account, such as IAM policy changes or unusual login attempts, to assess if the account may have been compromised. +- Assess the impact of the deletion by identifying the specific RDS instance or cluster affected and determining the potential data loss or service disruption caused by the action. +- Contact the responsible team or individual to verify if the deletion was intentional and authorized, and if not, initiate incident response procedures to mitigate further risk. + +### False positive analysis + +- Routine maintenance activities by database administrators can trigger alerts when they intentionally delete RDS instances or clusters. To manage this, create exceptions for known maintenance windows or specific administrator actions. +- Automated scripts or tools used for testing and development purposes might delete RDS resources as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific user or role identifiers. +- Scheduled decommissioning of outdated or unused RDS instances can also result in false positives. Maintain an updated list of decommissioning schedules and exclude these from the detection rule. +- CloudFormation stack deletions that include RDS resources can lead to alerts. Monitor CloudFormation activities and correlate them with RDS deletions to differentiate between legitimate and suspicious actions. + +### Response and remediation + +- Immediately isolate the affected AWS account to prevent further unauthorized actions. This can be done by revoking access keys and disabling any suspicious IAM user accounts or roles involved in the deletion. +- Initiate a recovery process for the deleted RDS instance or cluster using available backups or snapshots. Ensure that the restoration is performed in a secure environment to prevent further compromise. +- Conduct a thorough review of AWS CloudTrail logs to identify any unauthorized access patterns or anomalies leading up to the deletion event. This will help in understanding the scope of the breach and identifying potential entry points. +- Escalate the incident to the organization's security operations center (SOC) or incident response team for further investigation and to determine if additional systems or data were affected. +- Implement enhanced monitoring and alerting for AWS RDS and other critical resources to detect similar deletion attempts in the future. This includes setting up alerts for any unauthorized changes to IAM policies or roles. +- Review and strengthen IAM policies to ensure the principle of least privilege is enforced, reducing the risk of unauthorized deletions by limiting permissions to only those necessary for specific roles. +- Communicate with stakeholders and affected parties about the incident, outlining the steps taken for recovery and measures implemented to prevent future occurrences. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/aws/impact_rds_instance_cluster_deletion_protection_disabled.toml b/rules/integrations/aws/impact_rds_instance_cluster_deletion_protection_disabled.toml index 26419ea1c3a..99cd9388f84 100644 --- a/rules/integrations/aws/impact_rds_instance_cluster_deletion_protection_disabled.toml +++ b/rules/integrations/aws/impact_rds_instance_cluster_deletion_protection_disabled.toml @@ -2,12 +2,12 @@ creation_date = "2024/06/28" integration = ["aws"] maturity = "production" -updated_date = "2024/07/06" +updated_date = "2025/01/10" [rule] author = ["Elastic"] description = """ -Identifies the modification of an AWS RDS DB instance or cluster to remove the deletionProtection feature. Deletion protection is enabled automatically for instances set up through the console and can be used to protect them from unintentional deletion activity. If disabled an instance or cluster can be deleted, destroying sensitive or critical information. Adversaries with the proper permissions can take advantage of this to set up future deletion events against a compromised environment. +Identifies the modification of an AWS RDS DB instance or cluster to remove the deletionProtection feature. Deletion protection is enabled automatically for instances set up through the console and can be used to protect them from unintentional deletion activity. If disabled an instance or cluster can be deleted, destroying sensitive or critical information. Adversaries with the proper permissions can take advantage of this to set up future deletion events against a compromised environment. """ false_positives = [ """ @@ -20,7 +20,7 @@ language = "eql" license = "Elastic License v2" name = "AWS RDS DB Instance or Cluster Deletion Protection Disabled" note = """ -## Triage and Analysis +## Triage and analysis ### Investigating AWS RDS DB Instance or Cluster Deletion Protection Disabled diff --git a/rules/integrations/aws/impact_rds_instance_cluster_stoppage.toml b/rules/integrations/aws/impact_rds_instance_cluster_stoppage.toml index ecdf99bd422..6ff6240159b 100644 --- a/rules/integrations/aws/impact_rds_instance_cluster_stoppage.toml +++ b/rules/integrations/aws/impact_rds_instance_cluster_stoppage.toml @@ -2,7 +2,7 @@ creation_date = "2020/05/20" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -20,7 +20,43 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS RDS Instance/Cluster Stoppage" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS RDS Instance/Cluster Stoppage + +Amazon RDS is a managed database service that simplifies database setup, operation, and scaling. Adversaries may stop RDS instances or clusters to disrupt services, potentially causing data unavailability or loss. The detection rule monitors AWS CloudTrail logs for successful stop actions on RDS resources, alerting analysts to potential unauthorized disruptions aligned with impact tactics. + +### Possible investigation steps + +- Review the AWS CloudTrail logs to identify the user or role associated with the StopDBCluster or StopDBInstance action to determine if the action was authorized. +- Check the event time and correlate it with any scheduled maintenance or known operational activities to rule out legitimate stoppage. +- Investigate the source IP address and location from which the stop action was initiated to identify any anomalies or unauthorized access. +- Examine the AWS IAM policies and permissions associated with the user or role to ensure they align with the principle of least privilege. +- Look for any related alerts or logs around the same timeframe that might indicate a broader security incident or unauthorized access attempt. +- Contact the relevant database or application owner to confirm whether the stoppage was planned or expected. + +### False positive analysis + +- Routine maintenance activities may trigger stop actions on RDS instances or clusters. To manage this, create exceptions for scheduled maintenance windows by excluding events occurring during these times. +- Development and testing environments often involve frequent stopping and starting of RDS instances. Identify and exclude these environments from alerts by using tags or specific instance identifiers. +- Automated scripts or tools used for cost-saving measures might stop RDS instances during off-peak hours. Review and whitelist these scripts by verifying their source and purpose. +- User-initiated stop actions for legitimate reasons, such as troubleshooting or configuration changes, can be excluded by maintaining a list of authorized personnel and their activities. +- CloudFormation or other infrastructure-as-code tools may stop RDS instances as part of deployment processes. Exclude these actions by identifying and filtering events associated with these tools. + +### Response and remediation + +- Immediately verify the legitimacy of the stop action by reviewing the associated CloudTrail logs, focusing on the user identity, source IP, and time of the event to determine if the action was authorized. +- If unauthorized, isolate the affected RDS instance or cluster by disabling any associated IAM user or role that performed the stop action to prevent further unauthorized access. +- Restore the RDS instance or cluster from the latest backup or snapshot to minimize data unavailability and ensure service continuity. +- Conduct a root cause analysis to identify how the unauthorized stop action was executed, focusing on potential security gaps in IAM policies or network configurations. +- Implement additional security measures, such as enabling multi-factor authentication (MFA) for all IAM users and roles with permissions to stop RDS instances or clusters. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data were impacted. +- Update the incident response plan to include lessons learned from this event, ensuring quicker and more effective responses to similar threats in the future. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/aws/impact_rds_snapshot_deleted.toml b/rules/integrations/aws/impact_rds_snapshot_deleted.toml index ff2c665c4c9..bb09e40ec69 100644 --- a/rules/integrations/aws/impact_rds_snapshot_deleted.toml +++ b/rules/integrations/aws/impact_rds_snapshot_deleted.toml @@ -2,7 +2,7 @@ creation_date = "2024/06/29" integration = ["aws"] maturity = "production" -updated_date = "2024/07/06" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -46,6 +46,40 @@ any where event.dataset == "aws.cloudtrail" (event.action == "ModifyDBInstance" and stringContains(aws.cloudtrail.request_parameters, "backupRetentionPeriod=0")) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS RDS Snapshot Deleted + +AWS RDS snapshots are critical for data recovery, capturing full backups of database instances. Adversaries may delete these snapshots to prevent data restoration, effectively causing data loss. The detection rule monitors AWS CloudTrail logs for successful deletion actions or modifications that disable automated backups, signaling potential malicious activity aimed at data destruction. + +### Possible investigation steps + +- Review the AWS CloudTrail logs to identify the user or role associated with the event.action values "DeleteDBSnapshot" or "DeleteDBClusterSnapshot" to determine if the action was authorized or expected. +- Check the timestamp of the deletion event to correlate with any known maintenance activities or incidents that might explain the snapshot deletion. +- Investigate the source IP address and location from which the deletion request was made to identify any anomalies or unauthorized access patterns. +- Examine the AWS IAM policies and permissions associated with the user or role to ensure they have the appropriate level of access and to identify any potential over-permissioning. +- Look for any recent changes in the AWS environment, such as modifications to IAM roles or policies, that could have allowed unauthorized snapshot deletions. +- If the event.action is "ModifyDBInstance" with "backupRetentionPeriod=0", verify if there was a legitimate reason for disabling automated backups and assess the impact on data recovery capabilities. + +### False positive analysis + +- Routine maintenance activities by database administrators may involve deleting old or unnecessary snapshots. To manage this, create exceptions for specific user accounts or roles known to perform these tasks regularly. +- Automated scripts or tools used for database management might delete snapshots as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by whitelisting their associated IAM roles or user accounts. +- Testing environments often involve frequent creation and deletion of snapshots. Consider excluding specific RDS instances or environments used solely for testing purposes to reduce noise in alerts. +- Scheduled cleanup jobs that remove outdated snapshots to manage storage costs can trigger false positives. Document these jobs and adjust the detection rule to ignore actions performed by these jobs' IAM roles. + +### Response and remediation + +- Immediately revoke access to AWS accounts or roles suspected of unauthorized activity to prevent further malicious actions. +- Restore the deleted RDS snapshots from any available backups or replicas to ensure data recovery and continuity. +- Enable and configure automated backups for the affected RDS instances to prevent future data loss, ensuring the backupRetentionPeriod is set to a non-zero value. +- Conduct a thorough review of AWS CloudTrail logs to identify any unauthorized access patterns or anomalies leading up to the snapshot deletion. +- Escalate the incident to the security operations team for further investigation and to determine if additional AWS resources were compromised. +- Implement stricter IAM policies and multi-factor authentication for accessing AWS RDS resources to enhance security and prevent unauthorized deletions. +- Update and test the incident response plan to include specific procedures for handling AWS RDS snapshot deletions, ensuring rapid response in future incidents.""" [[rule.threat]] diff --git a/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml b/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml index b6452e68392..7ecd7e47d37 100644 --- a/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml +++ b/rules/integrations/aws/impact_s3_bucket_object_uploaded_with_ransom_extension.toml @@ -4,7 +4,7 @@ integration = ["aws"] maturity = "production" min_stack_comments = "AWS integration breaking changes, bumping version to ^2.0.0" min_stack_version = "8.13.0" -updated_date = "2024/10/09" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -25,7 +25,7 @@ license = "Elastic License v2" name = "Potential AWS S3 Bucket Ransomware Note Uploaded" note = """ -## Triage and Analysis +## Triage and analysis ### Investigating Potential AWS S3 Bucket Ransomware Note Uploaded diff --git a/rules/integrations/aws/impact_s3_object_encryption_with_external_key.toml b/rules/integrations/aws/impact_s3_object_encryption_with_external_key.toml index 7c80014e43c..297134d25bd 100644 --- a/rules/integrations/aws/impact_s3_object_encryption_with_external_key.toml +++ b/rules/integrations/aws/impact_s3_object_encryption_with_external_key.toml @@ -4,7 +4,7 @@ integration = ["aws"] maturity = "production" min_stack_comments = "ES|QL rule type in technical preview as of 8.13" min_stack_version = "8.13.0" -updated_date = "2024/10/09" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,7 @@ license = "Elastic License v2" name = "AWS S3 Object Encryption Using External KMS Key" note = """ -## Triage and Analysis +## Triage and analysis ### Investigating AWS S3 Object Encryption Using External KMS Key diff --git a/rules/integrations/aws/impact_s3_object_versioning_disabled.toml b/rules/integrations/aws/impact_s3_object_versioning_disabled.toml index 3e5550fa6ec..bcf3e6b7a20 100644 --- a/rules/integrations/aws/impact_s3_object_versioning_disabled.toml +++ b/rules/integrations/aws/impact_s3_object_versioning_disabled.toml @@ -2,12 +2,12 @@ creation_date = "2024/07/12" integration = ["aws"] maturity = "production" -updated_date = "2024/08/02" +updated_date = "2025/01/10" [rule] author = ["Elastic"] description = """ -Identifies when object versioning is suspended for an Amazon S3 bucket. Object versioning allows for multiple versions of an object to exist in the same bucket. This allows for easy recovery of deleted or overwritten objects. When object versioning is suspended for a bucket, it could indicate an adversary's attempt to inhibit system recovery following malicious activity. Additionally, when versioning is suspended, buckets can then be deleted. +Identifies when object versioning is suspended for an Amazon S3 bucket. Object versioning allows for multiple versions of an object to exist in the same bucket. This allows for easy recovery of deleted or overwritten objects. When object versioning is suspended for a bucket, it could indicate an adversary's attempt to inhibit system recovery following malicious activity. Additionally, when versioning is suspended, buckets can then be deleted. """ false_positives = [ """ @@ -21,7 +21,7 @@ license = "Elastic License v2" name = "AWS S3 Object Versioning Suspended" note = """ -## Triage and Analysis +## Triage and analysis ### Investigating AWS S3 Object Versioning Suspended @@ -76,9 +76,9 @@ timestamp_override = "event.ingested" type = "eql" query = ''' -any where event.dataset == "aws.cloudtrail" +any where event.dataset == "aws.cloudtrail" and event.action == "PutBucketVersioning" - and event.outcome == "success" + and event.outcome == "success" and stringContains(aws.cloudtrail.request_parameters, "Status=Suspended") ''' diff --git a/rules/integrations/aws/initial_access_password_recovery.toml b/rules/integrations/aws/initial_access_password_recovery.toml index 76273e283f6..da0af803ed0 100644 --- a/rules/integrations/aws/initial_access_password_recovery.toml +++ b/rules/integrations/aws/initial_access_password_recovery.toml @@ -2,7 +2,7 @@ creation_date = "2020/07/02" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -23,7 +23,42 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS IAM Password Recovery Requested" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS IAM Password Recovery Requested + +AWS Identity and Access Management (IAM) facilitates secure access control to AWS resources. Password recovery requests are legitimate processes for users to regain access. However, adversaries may exploit this by initiating unauthorized recovery attempts to gain access. The detection rule monitors successful password recovery requests within AWS CloudTrail logs, focusing on initial access tactics, to identify potential misuse and unauthorized access attempts. + +### Possible investigation steps + +- Review the AWS CloudTrail logs for the specific event.action:PasswordRecoveryRequested to identify the user account involved in the password recovery request. +- Check the event.provider:signin.amazonaws.com logs to determine the source IP address and geolocation associated with the password recovery request to assess if it aligns with known user activity. +- Investigate the event.outcome:success logs to confirm if the password recovery was completed and if there were any subsequent successful logins from the same or different IP addresses. +- Analyze the user account's recent activity and permissions to identify any unusual or unauthorized actions that may indicate compromise. +- Cross-reference the event with any other security alerts or incidents involving the same user account to identify potential patterns or coordinated attacks. +- Contact the user associated with the password recovery request to verify if they initiated the request and to ensure their account security. + +### False positive analysis + +- Routine password recovery by legitimate users can trigger this rule. To manage this, identify users who frequently request password recovery and consider adding them to an exception list if their behavior is verified as non-threatening. +- Automated password recovery processes used by internal IT support or helpdesk teams may also cause false positives. Coordinate with these teams to understand their workflows and exclude their activities from triggering alerts. +- Users with known issues accessing their accounts due to technical problems might repeatedly request password recovery. Monitor these cases and exclude them once confirmed as non-malicious. +- Scheduled security drills or training exercises that involve password recovery can generate alerts. Ensure these activities are documented and excluded from the rule to prevent unnecessary alerts. + +### Response and remediation + +- Immediately verify the legitimacy of the password recovery request by contacting the user associated with the request. Ensure they initiated the recovery process and are aware of the request. +- Temporarily disable the affected IAM user account to prevent any unauthorized access until the situation is fully assessed and resolved. +- Review AWS CloudTrail logs for any additional suspicious activities associated with the IAM user account, such as unusual login attempts or changes to permissions, to identify potential compromise. +- If unauthorized access is confirmed, reset the IAM user's password and any associated access keys. Ensure the new credentials are communicated securely to the legitimate user. +- Implement multi-factor authentication (MFA) for the affected IAM user account to enhance security and prevent future unauthorized access attempts. +- Escalate the incident to the security operations team for further investigation and to determine if additional accounts or resources have been compromised. +- Update and enhance monitoring rules to detect similar unauthorized password recovery attempts in the future, ensuring timely alerts and responses. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://www.cadosecurity.com/an-ongoing-aws-phishing-campaign/"] diff --git a/rules/integrations/aws/initial_access_signin_console_login_no_mfa.toml b/rules/integrations/aws/initial_access_signin_console_login_no_mfa.toml index 7b3b75e46ad..551b1603889 100644 --- a/rules/integrations/aws/initial_access_signin_console_login_no_mfa.toml +++ b/rules/integrations/aws/initial_access_signin_console_login_no_mfa.toml @@ -2,7 +2,7 @@ creation_date = "2024/08/19" integration = ['aws'] maturity = "production" -updated_date = "2024/10/09" +updated_date = "2025/01/10" min_stack_comments = "ES|QL rule type in technical preview as of 8.13" min_stack_version = "8.13.0" @@ -46,6 +46,41 @@ from logs-aws.cloudtrail-* metadata _id, _version, _index | where mfa_used == "No" | keep @timestamp, event.action, aws.cloudtrail.event_type, aws.cloudtrail.user_identity.type ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS Signin Single Factor Console Login with Federated User + +Federated users in AWS are granted temporary credentials to access resources, often without the need for a permanent account. This setup is convenient but can be risky if not properly secured with multi-factor authentication (MFA). Adversaries might exploit this by using stolen or misconfigured credentials to gain unauthorized access. The detection rule identifies instances where federated users log in without MFA, flagging potential security risks by analyzing specific AWS CloudTrail events and dissecting login data to check for the absence of MFA, thus helping to mitigate unauthorized access attempts. + +### Possible investigation steps + +- Review the AWS CloudTrail logs to confirm the event details, focusing on the event.provider, event.action, and aws.cloudtrail.user_identity.type fields to ensure the alert corresponds to a federated user login without MFA. +- Identify the federated user involved by examining the aws.cloudtrail.user_identity.arn field to determine which user or service is associated with the login attempt. +- Check the aws.cloudtrail.additional_eventdata field to verify the mfa_used value is "No" and assess if this is expected behavior for the identified user or service. +- Investigate the source IP address and location of the login attempt to determine if it aligns with typical access patterns for the federated user. +- Review recent activity associated with the federated user to identify any unusual or unauthorized actions that may have occurred following the login event. +- Assess the configuration and policies of the Identity Provider (IdP) used for federated access to ensure MFA is enforced and properly configured for all users. + +### False positive analysis + +- Federated users with specific roles or permissions may frequently log in without MFA due to operational requirements. Review these roles and consider adding them to an exception list if they are deemed non-threatening. +- Automated processes or scripts using federated credentials might trigger this rule if they are not configured to use MFA. Verify these processes and, if legitimate, exclude them from the rule to prevent unnecessary alerts. +- Temporary testing or development accounts might be set up without MFA for convenience. Ensure these accounts are monitored and, if necessary, excluded from the rule to avoid false positives. +- Third-party integrations or services that rely on federated access without MFA could be flagged. Assess these integrations and whitelist them if they are secure and necessary for business operations. +- Users accessing AWS from secure, controlled environments might not use MFA as part of a risk-based authentication strategy. Evaluate the security of these environments and consider excluding them if they meet your organization's security standards. + +### Response and remediation + +- Immediately revoke the temporary credentials associated with the federated user account to prevent further unauthorized access. +- Conduct a thorough review of AWS CloudTrail logs to identify any suspicious activities or unauthorized access attempts associated with the federated user account. +- Notify the security team and relevant stakeholders about the potential security breach to ensure coordinated response efforts. +- Implement or enforce multi-factor authentication (MFA) for all federated user accounts to enhance security and prevent similar incidents in the future. +- Review and update IAM policies and roles associated with federated users to ensure they follow the principle of least privilege. +- Escalate the incident to the incident response team if any malicious activities are detected, and initiate a full security investigation to assess the impact and scope of the breach. +- Monitor AWS CloudTrail and other relevant logs closely for any further unauthorized access attempts or anomalies related to federated user accounts.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/integrations/aws/lateral_movement_aws_ssm_start_session_to_ec2_instance.toml b/rules/integrations/aws/lateral_movement_aws_ssm_start_session_to_ec2_instance.toml index a32e91109c9..766039eb3d3 100644 --- a/rules/integrations/aws/lateral_movement_aws_ssm_start_session_to_ec2_instance.toml +++ b/rules/integrations/aws/lateral_movement_aws_ssm_start_session_to_ec2_instance.toml @@ -2,7 +2,7 @@ creation_date = "2024/04/16" integration = ["aws"] maturity = "production" -updated_date = "2024/07/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -19,7 +19,7 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "SSM Session Started to EC2 Instance" -note = """## Triage and Analysis +note = """## Triage and analysis ### Investigating SSM Session Started to EC2 Instance diff --git a/rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml b/rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml index 153db90dc33..2b289fdefa6 100644 --- a/rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml +++ b/rules/integrations/aws/lateral_movement_ec2_instance_console_login.toml @@ -2,7 +2,7 @@ creation_date = "2024/07/24" integration = ["aws"] maturity = "production" -updated_date = "2024/07/31" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -43,6 +43,42 @@ any where event.dataset == "aws.cloudtrail" and aws.cloudtrail.user_identity.type == "AssumedRole" and stringContains (user.id, ":i-") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS EC2 Instance Console Login via Assumed Role + +AWS EC2 instances can assume roles to access resources securely, using temporary credentials. This mechanism, while essential for legitimate operations, can be exploited by adversaries who gain access to EC2 credentials, allowing them to assume roles and perform unauthorized actions. The detection rule identifies unusual console login activities by EC2 instances, flagging potential misuse by checking for specific session patterns and successful login events, thus helping to uncover lateral movement or credential access attempts. + +### Possible investigation steps + +- Review the CloudTrail logs for the specific event where event.dataset is "aws.cloudtrail" and event.provider is "signin.amazonaws.com" to gather more details about the login event. +- Identify the EC2 instance associated with the session by examining the user.id field for the pattern ":i-" and correlate it with known EC2 instance IDs in your environment. +- Check the AWS CloudTrail logs for any other activities performed by the same assumed role session to identify any unauthorized actions or lateral movement attempts. +- Investigate the source IP address and geolocation of the login event to determine if it aligns with expected access patterns for your organization. +- Verify the IAM role policies and permissions associated with the assumed role to assess the potential impact of the unauthorized access. +- Review recent changes to the IAM roles and policies to identify any unauthorized modifications that could have facilitated the assumed role access. +- Contact the instance owner or relevant team to confirm if the login activity was expected or authorized, and take appropriate action if it was not. + +### False positive analysis + +- Routine administrative tasks: EC2 instances may assume roles for legitimate administrative purposes, such as automated deployments or maintenance tasks. To manage this, identify and whitelist known administrative session patterns or specific instance IDs that regularly perform these tasks. +- Monitoring and logging services: Some monitoring or logging services might use assumed roles to access AWS resources for data collection. Review and exclude these services by identifying their specific session patterns or instance IDs. +- Scheduled jobs or scripts: Automated scripts or scheduled jobs running on EC2 instances might assume roles for resource access. Document these jobs and create exceptions for their session patterns to prevent false alerts. +- Development and testing environments: Instances in development or testing environments might frequently assume roles for testing purposes. Consider excluding these environments from the rule or creating specific exceptions for known testing activities. +- Third-party integrations: Some third-party tools or integrations might require EC2 instances to assume roles for functionality. Verify these integrations and exclude their session patterns or instance IDs from triggering alerts. + +### Response and remediation + +- Immediately revoke the temporary credentials associated with the compromised EC2 instance to prevent further unauthorized access. +- Isolate the affected EC2 instance from the network to contain any potential lateral movement by the attacker. +- Conduct a thorough review of CloudTrail logs to identify any unauthorized actions performed using the assumed role and assess the extent of the compromise. +- Reset and rotate all credentials and access keys associated with the compromised EC2 instance and any other potentially affected resources. +- Implement stricter IAM policies and role permissions to limit the scope of access for EC2 instances, ensuring the principle of least privilege is enforced. +- Notify the security operations team and relevant stakeholders about the incident for further investigation and to initiate any necessary legal or compliance procedures. +- Enhance monitoring and alerting mechanisms to detect similar patterns of unusual console login activities in the future, ensuring rapid response to potential threats.""" [[rule.threat]] diff --git a/rules/integrations/aws/persistence_ec2_network_acl_creation.toml b/rules/integrations/aws/persistence_ec2_network_acl_creation.toml index 0ec4ba8c4a3..ebe7c1ed629 100644 --- a/rules/integrations/aws/persistence_ec2_network_acl_creation.toml +++ b/rules/integrations/aws/persistence_ec2_network_acl_creation.toml @@ -2,7 +2,7 @@ creation_date = "2020/06/04" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -23,7 +23,43 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS EC2 Network Access Control List Creation" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS EC2 Network Access Control List Creation + +AWS EC2 Network ACLs are stateless firewalls for controlling inbound and outbound traffic at the subnet level. Adversaries may exploit ACLs to establish persistence or exfiltrate data by creating permissive rules. The detection rule monitors successful creation events of ACLs or entries, flagging potential unauthorized modifications that align with persistence tactics, aiding in early threat identification. + +### Possible investigation steps + +- Review the CloudTrail logs for the specific event.dataset:aws.cloudtrail entries to identify the user or role (event.user) that initiated the CreateNetworkAcl or CreateNetworkAclEntry actions. +- Examine the event.provider:ec2.amazonaws.com logs to determine the IP addresses and locations associated with the request to assess if they are expected or suspicious. +- Check the event.action details to understand the specific rules created in the Network ACL, focusing on any overly permissive rules that could indicate a security risk. +- Investigate the event.outcome:success entries to confirm the successful creation of the ACL or ACL entry and correlate with any other suspicious activities in the AWS environment. +- Cross-reference the event with other security alerts or logs to identify any patterns or anomalies that could suggest malicious intent or unauthorized access. +- Assess the impact of the new ACL rules on the network security posture, ensuring they do not inadvertently allow unauthorized access or data exfiltration. + +### False positive analysis + +- Routine infrastructure updates or deployments may trigger the creation of new network ACLs or entries. To manage this, establish a baseline of expected changes during scheduled maintenance windows and exclude these from alerts. +- Automated scripts or infrastructure-as-code tools like Terraform or CloudFormation can create network ACLs as part of normal operations. Identify and whitelist these automated processes to prevent unnecessary alerts. +- Changes made by trusted administrators or security teams for legitimate purposes can be mistaken for suspicious activity. Implement a process to log and review approved changes, allowing you to exclude these from detection. +- Temporary ACLs created for troubleshooting or testing purposes can generate alerts. Document and track these activities, and use tags or naming conventions to easily identify and exclude them from monitoring. +- Third-party services or integrations that require specific network configurations might create ACLs. Review and validate these services, and if deemed safe, add them to an exception list to reduce false positives. + +### Response and remediation + +- Immediately review the AWS CloudTrail logs to confirm the creation of the Network ACL or entry and identify the IAM user or role responsible for the action. This helps determine if the action was authorized or potentially malicious. +- Revoke any suspicious or unauthorized IAM credentials associated with the creation of the Network ACL or entry to prevent further unauthorized access. +- Modify or delete the newly created Network ACL or entry if it is determined to be unauthorized or overly permissive, ensuring that it aligns with your organization's security policies. +- Conduct a security review of the affected AWS environment to identify any other unauthorized changes or indicators of compromise, focusing on persistence mechanisms. +- Implement additional monitoring and alerting for changes to Network ACLs and other critical AWS resources to enhance detection of similar threats in the future. +- Escalate the incident to the security operations team or incident response team for further investigation and to determine if additional containment or remediation actions are necessary. +- Review and update IAM policies and permissions to ensure the principle of least privilege is enforced, reducing the risk of unauthorized changes to network configurations. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/aws/persistence_ec2_security_group_configuration_change_detection.toml b/rules/integrations/aws/persistence_ec2_security_group_configuration_change_detection.toml index c01a4fe6b96..8041dde9f4c 100644 --- a/rules/integrations/aws/persistence_ec2_security_group_configuration_change_detection.toml +++ b/rules/integrations/aws/persistence_ec2_security_group_configuration_change_detection.toml @@ -2,7 +2,7 @@ creation_date = "2021/05/05" integration = ["aws"] maturity = "production" -updated_date = "2024/11/07" +updated_date = "2025/01/10" [rule] author = ["Elastic", "Austin Songer"] @@ -23,7 +23,42 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"] language = "kuery" license = "Elastic License v2" name = "AWS EC2 Security Group Configuration Change" -note = """ +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS EC2 Security Group Configuration Change + +AWS EC2 Security Groups act as virtual firewalls, controlling inbound and outbound traffic to instances. Adversaries may exploit changes in these configurations to gain unauthorized access, maintain persistence, or exfiltrate data. The detection rule monitors successful modifications to security group settings, such as rule changes or new group creation, to identify potential security breaches and unauthorized access attempts. + +### Possible investigation steps + +- Review the CloudTrail logs for the specific event.dataset "aws.cloudtrail" to identify the exact changes made to the security group configuration. +- Examine the event.provider "ec2.amazonaws.com" and event.action fields to determine the type of action performed, such as "AuthorizeSecurityGroupEgress" or "ModifySecurityGroupRules", to understand the nature of the change. +- Check the event.outcome field to confirm the success of the action and correlate it with any suspicious activity or unauthorized access attempts. +- Investigate the IAM user or role associated with the change to verify if the action aligns with their typical behavior and permissions. +- Analyze the timing and context of the change to see if it coincides with any other unusual activities or alerts in the AWS environment. +- Assess the impact of the security group change on the overall security posture, including potential exposure of sensitive resources or data. +- If necessary, consult with the responsible team or individual to validate the legitimacy of the change and ensure it was authorized. + +### False positive analysis + +- Routine administrative changes to security groups by authorized personnel can trigger alerts. To manage this, maintain a list of known IP addresses and users who regularly perform these tasks and create exceptions for their activities. +- Automated scripts or tools used for infrastructure management may frequently modify security group settings. Identify these tools and exclude their actions from triggering alerts by using their specific identifiers or tags. +- Scheduled updates or deployments that involve security group modifications can result in false positives. Document these schedules and adjust the monitoring rules to account for these expected changes during specific time windows. +- Changes made by cloud service providers as part of their maintenance or updates might be flagged. Verify these changes through official communication from the provider and consider excluding them if they are part of standard operations. + +### Response and remediation + +- Immediately isolate the affected EC2 instances by removing them from the compromised security group to prevent further unauthorized access. +- Revert any unauthorized changes to the security group configurations by restoring them to their last known good state using AWS CloudTrail logs for reference. +- Conduct a thorough review of IAM roles and permissions associated with the affected security groups to ensure that only authorized personnel have the ability to modify security group settings. +- Implement additional monitoring and alerting for any future changes to security group configurations, focusing on the specific actions identified in the detection rule. +- Escalate the incident to the security operations team for further investigation and to determine if there are any broader implications or related threats within the AWS environment. +- Review and update the AWS security group policies to enforce stricter rules and minimize the attack surface, ensuring that only necessary ports and protocols are allowed. +- Conduct a post-incident analysis to identify the root cause and implement measures to prevent similar incidents, such as enhancing logging and monitoring capabilities or applying stricter access controls. + ### Investigating AWS EC2 Security Group Configuration Change This rule identifies any changes to an AWS Security Group, which functions as a virtual firewall controlling inbound and outbound traffic for resources like EC2 instances. Modifications to a security group configuration could expose critical assets to unauthorized access. Threat actors may exploit such changes to establish persistence, exfiltrate data, or pivot within an AWS environment. diff --git a/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml b/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml index 447c69c9399..76e29a4de1b 100644 --- a/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml +++ b/rules/integrations/aws/persistence_iam_create_login_profile_for_root.toml @@ -4,7 +4,7 @@ integration = ["aws"] maturity = "production" min_stack_comments = "ES|QL available in technical preview." min_stack_version = "8.13.0" -updated_date = "2024/12/02" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -17,7 +17,41 @@ from = "now-9m" language = "esql" license = "Elastic License v2" name = "AWS IAM Login Profile Added for Root" -note = """ +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS IAM Login Profile Added for Root + +AWS IAM allows management of user access and permissions within AWS environments. A login profile enables console access using a password. Adversaries may exploit temporary root access to create a login profile, ensuring persistent access even if keys are rotated. The detection rule identifies such actions by monitoring specific API calls and conditions, flagging unauthorized profile additions to root accounts. + +### Possible investigation steps + +- Review the @timestamp field to determine when the CreateLoginProfile action occurred and correlate it with any other suspicious activities around the same time. +- Examine the aws.cloudtrail.user_identity.arn and aws.cloudtrail.user_identity.access_key_id fields to identify the specific root account and access key involved in the action. +- Investigate the source.address field to trace the IP address from which the CreateLoginProfile request originated, checking for any unusual or unauthorized locations. +- Analyze the aws.cloudtrail.request_parameters and aws.cloudtrail.response_elements fields to understand the specifics of the login profile creation and verify if any unexpected parameters were used. +- Check the cloud.account.id to confirm which AWS account was affected and assess if there are any other security incidents or alerts associated with this account. +- Review the event.action field to ensure that no other unauthorized actions were performed by the root account around the same time. + +### False positive analysis + +- Administrative actions by trusted personnel may trigger the rule if they are performing legitimate maintenance or security tasks. To manage this, create exceptions for known administrative accounts by filtering their access key IDs. +- Automated scripts or tools used for account management might inadvertently match the rule's conditions. Identify these scripts and exclude their specific access key IDs or user agents from the detection criteria. +- Testing environments where root access is used for simulation or development purposes can cause false positives. Implement a tagging system for test environments and exclude logs with these tags from triggering the rule. +- Third-party integrations that require root access for initial setup or configuration might be flagged. Document these integrations and adjust the rule to recognize and exclude their specific access patterns. + +### Response and remediation + +- Immediately revoke any active sessions and access keys associated with the root account to prevent further unauthorized access. +- Reset the root account password and ensure that multi-factor authentication (MFA) is enabled for the root user to enhance security. +- Review AWS CloudTrail logs to identify any other suspicious activities or changes made by the root account during the time of the incident. +- Conduct a thorough audit of IAM policies and permissions to ensure that no other unauthorized changes have been made and that least privilege principles are enforced. +- Notify the security operations team and relevant stakeholders about the incident for further investigation and to ensure awareness across the organization. +- Implement additional monitoring and alerting for root account activities to detect any future unauthorized access attempts promptly. +- Consider engaging AWS Support or a third-party security expert if the incident's scope is beyond internal capabilities or if further forensic analysis is required. + ## Investigating AWS IAM Login Profile Added for Root This rule detects when a login profile is added to the AWS root account. Adding a login profile to the root account, especially if self-assigned, is highly suspicious as it might indicate an adversary trying to establish persistence in the environment. diff --git a/rules/integrations/aws/persistence_iam_create_user_via_assumed_role_on_ec2_instance.toml b/rules/integrations/aws/persistence_iam_create_user_via_assumed_role_on_ec2_instance.toml index 787afc8f6ad..c5ae7aec9a1 100644 --- a/rules/integrations/aws/persistence_iam_create_user_via_assumed_role_on_ec2_instance.toml +++ b/rules/integrations/aws/persistence_iam_create_user_via_assumed_role_on_ec2_instance.toml @@ -2,7 +2,7 @@ creation_date = "2024/11/04" integration = ["aws"] maturity = "production" -updated_date = "2024/11/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -25,7 +25,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"] language = "kuery" license = "Elastic License v2" name = "AWS IAM Create User via Assumed Role on EC2 Instance" -note = """## Triage and Analysis +note = """## Triage and analysis ### Investigating AWS IAM User Creation via Assumed Role on an EC2 Instance diff --git a/rules/integrations/aws/persistence_iam_group_creation.toml b/rules/integrations/aws/persistence_iam_group_creation.toml index 5d678c72d7c..ca23bbb4585 100644 --- a/rules/integrations/aws/persistence_iam_group_creation.toml +++ b/rules/integrations/aws/persistence_iam_group_creation.toml @@ -2,7 +2,7 @@ creation_date = "2020/06/05" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -23,7 +23,43 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS IAM Group Creation" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS IAM Group Creation + +AWS IAM allows organizations to manage user access and permissions securely. Groups in IAM simplify permission management by allowing multiple users to inherit the same permissions. However, adversaries may exploit this by creating unauthorized groups to gain persistent access. The detection rule monitors successful group creation events, flagging potential misuse by correlating specific AWS CloudTrail logs, thus aiding in identifying unauthorized access attempts. + +### Possible investigation steps + +- Review the AWS CloudTrail logs for the specific event.provider: iam.amazonaws.com and event.action: CreateGroup to identify the user or service that initiated the group creation. +- Check the event.dataset: aws.cloudtrail logs for any associated event.outcome: success entries to confirm the successful creation of the group. +- Investigate the permissions assigned to the newly created group to assess if they include any sensitive or high-privilege permissions that could pose a security risk. +- Identify and review the IAM user or role that created the group to determine if they have a legitimate reason for this action and if their activity aligns with their typical behavior. +- Cross-reference the group creation event with other recent IAM activities, such as user additions to the group or changes to group policies, to detect any suspicious patterns or anomalies. +- Consult with relevant stakeholders or the user responsible for the group creation to verify the legitimacy of the action and gather additional context if necessary. + +### False positive analysis + +- Routine administrative actions by authorized personnel can trigger alerts. Regularly review and document legitimate group creation activities to differentiate them from unauthorized actions. +- Automated scripts or tools used for infrastructure management may create groups as part of their normal operation. Identify and whitelist these scripts to prevent unnecessary alerts. +- Temporary groups created for short-term projects or testing purposes might be flagged. Implement a naming convention for such groups and exclude them from alerts based on this pattern. +- Scheduled tasks or maintenance activities that involve group creation should be logged and approved in advance. Use these logs to create exceptions in the detection rule. +- Third-party integrations or services that require group creation for functionality can cause false positives. Verify these integrations and adjust the rule to exclude their known actions. + +### Response and remediation + +- Immediately review the AWS CloudTrail logs to confirm the unauthorized creation of the IAM group and identify the user or service responsible for the action. +- Revoke any permissions associated with the newly created IAM group to prevent further unauthorized access or actions. +- Temporarily disable or delete the unauthorized IAM group to contain the threat and prevent any potential misuse. +- Conduct a thorough audit of recent IAM changes to identify any other unauthorized activities or anomalies that may indicate further compromise. +- Escalate the incident to the security operations team for a detailed investigation and to assess the potential impact on the organization's security posture. +- Implement additional monitoring and alerting for IAM group creation events to enhance detection capabilities and prevent similar incidents in the future. +- Review and update IAM policies and permissions to ensure they follow the principle of least privilege, reducing the risk of unauthorized access. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/aws/persistence_iam_roles_anywhere_profile_created.toml b/rules/integrations/aws/persistence_iam_roles_anywhere_profile_created.toml index 1d800bd6854..9bcc42842a8 100644 --- a/rules/integrations/aws/persistence_iam_roles_anywhere_profile_created.toml +++ b/rules/integrations/aws/persistence_iam_roles_anywhere_profile_created.toml @@ -2,7 +2,7 @@ creation_date = "2024/04/20" integration = ["aws"] maturity = "production" -updated_date = "2024/07/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -26,7 +26,7 @@ language = "kuery" license = "Elastic License v2" name = "AWS IAM Roles Anywhere Profile Creation" note = """ -## Triage and Analysis +## Triage and analysis ### Investigating AWS IAM Roles Anywhere Profile Creation diff --git a/rules/integrations/aws/persistence_iam_roles_anywhere_trusted_anchor_created_with_external_ca.toml b/rules/integrations/aws/persistence_iam_roles_anywhere_trusted_anchor_created_with_external_ca.toml index d55e1007ae7..bdaf5811c53 100644 --- a/rules/integrations/aws/persistence_iam_roles_anywhere_trusted_anchor_created_with_external_ca.toml +++ b/rules/integrations/aws/persistence_iam_roles_anywhere_trusted_anchor_created_with_external_ca.toml @@ -2,7 +2,7 @@ creation_date = "2024/04/20" integration = ["aws"] maturity = "production" -updated_date = "2024/07/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -27,7 +27,7 @@ language = "kuery" license = "Elastic License v2" name = "AWS IAM Roles Anywhere Trust Anchor Created with External CA" note = """ -## Triage and Analysis +## Triage and analysis ### Investigating AWS IAM Roles Anywhere Trust Anchor Created with External CA diff --git a/rules/integrations/aws/persistence_lambda_backdoor_invoke_function_for_any_principal.toml b/rules/integrations/aws/persistence_lambda_backdoor_invoke_function_for_any_principal.toml index 7bc76bfde42..d81faf28ac5 100644 --- a/rules/integrations/aws/persistence_lambda_backdoor_invoke_function_for_any_principal.toml +++ b/rules/integrations/aws/persistence_lambda_backdoor_invoke_function_for_any_principal.toml @@ -2,7 +2,7 @@ creation_date = "2024/04/30" integration = ["aws"] maturity = "production" -updated_date = "2024/07/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -19,7 +19,7 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS Lambda Function Policy Updated to Allow Public Invocation" -note = """## Triage and Analysis +note = """## Triage and analysis ### Investigating AWS Lambda Function Policy Updated to Allow Public Invocation diff --git a/rules/integrations/aws/persistence_rds_cluster_creation.toml b/rules/integrations/aws/persistence_rds_cluster_creation.toml index 352fd7c484b..8bc74a442ed 100644 --- a/rules/integrations/aws/persistence_rds_cluster_creation.toml +++ b/rules/integrations/aws/persistence_rds_cluster_creation.toml @@ -2,7 +2,7 @@ creation_date = "2020/05/20" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -23,7 +23,43 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS RDS Cluster Creation" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS RDS Cluster Creation + +Amazon RDS facilitates database management by automating tasks like hardware provisioning and backups. Adversaries may exploit RDS by creating unauthorized clusters to exfiltrate data or establish persistence. The detection rule monitors successful creation events of RDS clusters, flagging potential misuse by correlating specific actions and outcomes, thus aiding in identifying unauthorized activities. + +### Possible investigation steps + +- Review the event details in AWS CloudTrail to confirm the event.dataset is 'aws.cloudtrail' and the event.provider is 'rds.amazonaws.com', ensuring the alert is based on the correct data source. +- Verify the identity of the user or service account that initiated the CreateDBCluster or CreateGlobalCluster action by examining the user identity information in the event logs. +- Check the event time and correlate it with any other suspicious activities or alerts in the same timeframe to identify potential patterns or coordinated actions. +- Investigate the source IP address and geolocation associated with the event to determine if it aligns with expected access patterns or if it indicates unauthorized access. +- Assess the configuration and settings of the newly created RDS cluster, including security groups, network settings, and any associated IAM roles, to identify potential security misconfigurations or vulnerabilities. +- Review the AWS account's recent activity for any other unusual or unauthorized actions that might indicate broader compromise or misuse. + +### False positive analysis + +- Routine maintenance or testing activities by authorized personnel can trigger alerts. To manage this, create exceptions for specific user accounts or roles known to perform these tasks regularly. +- Automated scripts or tools used for infrastructure management might create RDS clusters as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific tags or identifiers. +- Scheduled deployments or updates that involve creating new RDS clusters can be mistaken for unauthorized activity. Document these schedules and configure the detection rule to ignore events during these timeframes. +- Development or staging environments often involve frequent creation and deletion of RDS clusters. Exclude these environments from monitoring by filtering based on environment-specific tags or naming conventions. +- Partner or third-party integrations that require creating RDS clusters should be reviewed and whitelisted if deemed non-threatening, ensuring that their actions do not generate false positives. + +### Response and remediation + +- Immediately isolate the newly created RDS cluster to prevent any unauthorized access or data exfiltration. This can be done by modifying the security group rules to restrict inbound and outbound traffic. +- Review CloudTrail logs to identify the IAM user or role responsible for the creation of the RDS cluster. Verify if the action was authorized and if the credentials have been compromised. +- Revoke any suspicious or unauthorized IAM credentials and rotate keys for affected users or roles to prevent further unauthorized actions. +- Conduct a thorough audit of the RDS cluster configuration and data to assess any potential data exposure or integrity issues. If sensitive data is involved, consider notifying relevant stakeholders and following data breach protocols. +- Implement additional monitoring and alerting for RDS-related activities, focusing on unusual patterns or actions that align with persistence tactics, to enhance detection capabilities. +- Escalate the incident to the security operations team for further investigation and to determine if additional containment or remediation actions are necessary. +- Review and update IAM policies and permissions to ensure the principle of least privilege is enforced, reducing the risk of unauthorized RDS cluster creation in the future. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/aws/persistence_rds_db_instance_password_modified.toml b/rules/integrations/aws/persistence_rds_db_instance_password_modified.toml index ac4bbc343f9..203d1936cff 100644 --- a/rules/integrations/aws/persistence_rds_db_instance_password_modified.toml +++ b/rules/integrations/aws/persistence_rds_db_instance_password_modified.toml @@ -2,12 +2,12 @@ creation_date = "2024/06/27" integration = ["aws"] maturity = "production" -updated_date = "2024/07/06" +updated_date = "2025/01/10" [rule] author = ["Elastic"] description = """ -Identifies the modification of the master password for an AWS RDS DB instance or cluster. DB instances may contain sensitive data that can be abused if accessed by unauthorized actors. Amazon RDS API operations never return the password, so this operation provides a means to regain access if the password is lost. Adversaries with the proper permissions can take advantage of this to evade defenses and gain unauthorized access to a DB instance or cluster to support persistence mechanisms or privilege escalation. +Identifies the modification of the master password for an AWS RDS DB instance or cluster. DB instances may contain sensitive data that can be abused if accessed by unauthorized actors. Amazon RDS API operations never return the password, so this operation provides a means to regain access if the password is lost. Adversaries with the proper permissions can take advantage of this to evade defenses and gain unauthorized access to a DB instance or cluster to support persistence mechanisms or privilege escalation. """ false_positives = [ """ @@ -20,7 +20,7 @@ language = "eql" license = "Elastic License v2" name = "AWS RDS DB Instance or Cluster Password Modified" note = """ -## Triage and Analysis +## Triage and analysis ### Investigating AWS RDS DB Instance or Cluster Password Modified diff --git a/rules/integrations/aws/persistence_rds_group_creation.toml b/rules/integrations/aws/persistence_rds_group_creation.toml index 1140f4e4ef5..6e7b4f6e201 100644 --- a/rules/integrations/aws/persistence_rds_group_creation.toml +++ b/rules/integrations/aws/persistence_rds_group_creation.toml @@ -2,7 +2,7 @@ creation_date = "2021/06/05" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic", "Austin Songer"] @@ -20,7 +20,42 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS RDS Security Group Creation" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS RDS Security Group Creation + +Amazon RDS Security Groups control access to RDS instances, acting as virtual firewalls. Adversaries may exploit this by creating unauthorized security groups to maintain persistence or exfiltrate data. The detection rule monitors successful creation events of RDS security groups, flagging potential misuse by correlating specific AWS CloudTrail logs, thus aiding in identifying unauthorized access attempts. + +### Possible investigation steps + +- Review the AWS CloudTrail logs for the event.action:CreateDBSecurityGroup to identify the user or role responsible for the creation of the RDS security group. +- Check the event.provider:rds.amazonaws.com logs to gather additional context about the RDS instance associated with the newly created security group. +- Investigate the event.outcome:success logs to confirm the successful creation and assess if it aligns with expected administrative activities. +- Analyze the associated AWS account and user activity to determine if there are any anomalies or unauthorized access patterns. +- Cross-reference the security group details with existing security policies to ensure compliance and identify any deviations. +- Evaluate the permissions and rules associated with the new security group to assess potential risks or exposure to sensitive data. + +### False positive analysis + +- Routine administrative tasks may trigger the rule when authorized personnel create new RDS security groups for legitimate purposes. To manage this, establish a list of known IP addresses or user accounts that frequently perform these tasks and create exceptions for them. +- Automated deployment tools or scripts that create RDS security groups as part of infrastructure provisioning can lead to false positives. Identify these tools and their associated accounts, then configure the rule to exclude these specific actions. +- Scheduled maintenance or updates that involve creating new security groups might be flagged. Document these scheduled activities and adjust the rule to recognize and exclude them during the specified time frames. +- Testing environments where security groups are frequently created and deleted for development purposes can generate alerts. Implement tagging or naming conventions for test environments and exclude these from the rule's scope. + +### Response and remediation + +- Immediately review the AWS CloudTrail logs to confirm the unauthorized creation of the RDS security group and identify the source IP and user account involved in the action. +- Revoke any unauthorized security group rules associated with the newly created RDS security group to prevent further unauthorized access or data exfiltration. +- Temporarily disable or delete the unauthorized RDS security group to contain the threat and prevent persistence. +- Conduct a thorough audit of all AWS IAM roles and permissions to ensure that only authorized users have the ability to create or modify RDS security groups. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been compromised. +- Implement additional monitoring and alerting for any future RDS security group creation events to quickly detect and respond to similar threats. +- Review and update AWS security policies and access controls to prevent unauthorized security group creation, ensuring alignment with best practices for least privilege. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBSecurityGroup.html"] diff --git a/rules/integrations/aws/persistence_rds_instance_creation.toml b/rules/integrations/aws/persistence_rds_instance_creation.toml index ba167a1cb93..8cc4d38b7fc 100644 --- a/rules/integrations/aws/persistence_rds_instance_creation.toml +++ b/rules/integrations/aws/persistence_rds_instance_creation.toml @@ -2,7 +2,7 @@ creation_date = "2021/06/06" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic", "Austin Songer"] @@ -20,7 +20,43 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS RDS Instance Creation" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS RDS Instance Creation + +Amazon RDS simplifies database management by automating tasks like provisioning and scaling. However, adversaries may exploit this by creating unauthorized instances to exfiltrate data or establish persistence. The detection rule monitors successful RDS instance creations, focusing on specific AWS CloudTrail events, to identify potential misuse and ensure asset visibility. + +### Possible investigation steps + +- Review the CloudTrail logs for the specific event.action:CreateDBInstance to gather details about the RDS instance creation, including the timestamp, user identity, and source IP address. +- Verify the user identity associated with the event to determine if the action was performed by an authorized user or service account. Check for any anomalies in user behavior or access patterns. +- Investigate the source IP address to identify if it is associated with known internal or external entities, and assess if it aligns with expected network activity. +- Examine the AWS account and region where the RDS instance was created to ensure it aligns with organizational policies and expected usage patterns. +- Check for any related events or activities in CloudTrail logs around the same timeframe, such as modifications to security groups or IAM policies, which might indicate further unauthorized actions. +- Assess the configuration and settings of the newly created RDS instance, including database engine, instance class, and network settings, to ensure they comply with security and compliance standards. + +### False positive analysis + +- Routine maintenance or testing activities by authorized personnel may trigger alerts. To manage this, create exceptions for known maintenance windows or specific user accounts involved in these activities. +- Automated scripts or tools used for legitimate database provisioning can cause false positives. Identify these scripts and exclude their associated user accounts or roles from triggering alerts. +- Development or staging environments often have frequent instance creations that are non-threatening. Exclude these environments by filtering based on tags or specific resource identifiers. +- Third-party integrations or services that require RDS instance creation might be flagged. Review and whitelist these services by their IAM roles or API calls. +- Scheduled scaling operations that automatically create instances can be mistaken for unauthorized activity. Document and exclude these operations by their specific time frames or automation identifiers. + +### Response and remediation + +- Immediately isolate the newly created RDS instance to prevent any unauthorized access or data exfiltration. This can be done by modifying the security group rules to restrict inbound and outbound traffic. +- Review the CloudTrail logs to identify the IAM user or role responsible for the RDS instance creation. Verify if the action was authorized and if the credentials have been compromised. +- Revoke any suspicious or unauthorized IAM credentials and rotate keys for affected users or roles to prevent further unauthorized actions. +- Conduct a thorough audit of the RDS instance configuration, including database parameters and access controls, to ensure no sensitive data has been exposed or altered. +- Notify the security operations team and relevant stakeholders about the incident for further investigation and to determine if additional systems have been affected. +- Implement additional monitoring and alerting for unusual RDS activities, such as unexpected instance creations or modifications, to enhance detection capabilities. +- Review and update IAM policies to enforce the principle of least privilege, ensuring that only authorized users have the necessary permissions to create RDS instances. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html"] diff --git a/rules/integrations/aws/persistence_rds_instance_made_public.toml b/rules/integrations/aws/persistence_rds_instance_made_public.toml index 8c40eeebabd..9257864e236 100644 --- a/rules/integrations/aws/persistence_rds_instance_made_public.toml +++ b/rules/integrations/aws/persistence_rds_instance_made_public.toml @@ -2,7 +2,7 @@ creation_date = "2024/06/29" integration = ["aws"] maturity = "production" -updated_date = "2024/07/06" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -20,7 +20,7 @@ language = "eql" license = "Elastic License v2" name = "AWS RDS DB Instance Made Public" note = """ -## Triage and Analysis +## Triage and analysis ### Investigating AWS RDS DB Instance Made Public @@ -42,7 +42,7 @@ This rule identifies when an RDS DB instance is created or modified to enable pu ### Response and Remediation -- **Immediate Review and Reversal**: If the change was unauthorized, update the instance attributes to remove public access and restore it to its previous state. Determine whether attached security groups have been modified to allow additional access and revert any unauthorized changes. +- **Immediate Review and Reversal**: If the change was unauthorized, update the instance attributes to remove public access and restore it to its previous state. Determine whether attached security groups have been modified to allow additional access and revert any unauthorized changes. - **Enhance Monitoring and Alerts**: Adjust monitoring systems to alert on similar actions, especially those involving sensitive data or permissions. - **Audit Instances and Policies**: Conduct a comprehensive audit of all instances and associated policies to ensure they adhere to the principle of least privilege. - **Policy Update**: Review and possibly update your organization’s policies on DB instance access to tighten control and prevent unauthorized access. @@ -81,7 +81,7 @@ any where event.dataset == "aws.cloudtrail" and event.outcome == "success" and ( (event.action == "ModifyDBInstance" and stringContains(aws.cloudtrail.request_parameters, "publiclyAccessible=true")) - or + or (event.action in ("CreateDBInstance", "CreateDBCluster") and stringContains(aws.cloudtrail.request_parameters, "publiclyAccessible=true")) ) ''' diff --git a/rules/integrations/aws/persistence_redshift_instance_creation.toml b/rules/integrations/aws/persistence_redshift_instance_creation.toml index ee4a8e87d42..2164a87333c 100644 --- a/rules/integrations/aws/persistence_redshift_instance_creation.toml +++ b/rules/integrations/aws/persistence_redshift_instance_creation.toml @@ -2,7 +2,7 @@ creation_date = "2022/04/12" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -24,7 +24,42 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS Redshift Cluster Creation" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS Redshift Cluster Creation + +Amazon Redshift is a data warehousing service that allows for scalable data storage and analysis. In a secure environment, only authorized users should create Redshift clusters. Adversaries might exploit misconfigured permissions to create clusters, potentially leading to data exfiltration or unauthorized data processing. The detection rule monitors for successful cluster creation events, especially by non-admin users, to identify potential misuse or misconfigurations. + +### Possible investigation steps + +- Review the CloudTrail logs for the event.dataset:aws.cloudtrail and event.provider:redshift.amazonaws.com to confirm the details of the CreateCluster event, including the timestamp and the user who initiated the action. +- Identify the IAM role or user associated with the event.action:CreateCluster and verify if this user is expected to have permissions to create Redshift clusters. Check for any recent changes to their permissions or roles. +- Investigate the event.outcome:success to ensure that the cluster creation was indeed successful and determine the region and account where the cluster was created. +- Examine the configuration of the newly created Redshift cluster to ensure it adheres to security best practices, such as encryption settings, VPC configurations, and access controls. +- Cross-reference the user activity with other logs or alerts to identify any unusual patterns or behaviors that might indicate misuse or compromise, such as multiple cluster creation attempts or access from unfamiliar IP addresses. +- Contact the user or team responsible for the account to verify if the cluster creation was intentional and authorized, and document their response for future reference. + +### False positive analysis + +- Routine maintenance or testing activities by non-admin users can trigger alerts. To manage this, create exceptions for specific users or roles known to perform these tasks regularly. +- Automated scripts or third-party tools that create clusters as part of their normal operation may cause false positives. Identify these tools and exclude their associated user accounts or roles from the detection rule. +- Development or staging environments where non-admin users are permitted to create clusters for testing purposes can lead to alerts. Implement environment-specific exclusions to prevent unnecessary alerts. +- Temporary permissions granted to non-admin users for specific projects can result in cluster creation alerts. Monitor and document these permissions, and adjust the detection rule to account for these temporary changes. + +### Response and remediation + +- Immediately isolate the Redshift cluster to prevent any unauthorized access or data exfiltration. This can be done by modifying the security group rules to restrict inbound and outbound traffic. +- Review the IAM roles and permissions associated with the user who created the cluster. Revoke any unnecessary permissions and ensure that the principle of least privilege is enforced. +- Conduct a thorough audit of recent CloudTrail logs to identify any other unauthorized activities or anomalies associated with the same user or related accounts. +- If data exfiltration is suspected, initiate a data integrity check and consider restoring from a known good backup to ensure no data tampering has occurred. +- Notify the security team and relevant stakeholders about the incident for further investigation and to determine if additional security measures are needed. +- Implement additional monitoring and alerting for Redshift cluster creation events, especially focusing on non-administrative users, to quickly detect similar activities in the future. +- Consider enabling multi-factor authentication (MFA) for all users with permissions to create or modify Redshift clusters to add an extra layer of security. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://docs.aws.amazon.com/redshift/latest/APIReference/API_CreateCluster.html"] diff --git a/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml b/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml index 3adaff849fd..034fb0b3227 100644 --- a/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml +++ b/rules/integrations/aws/persistence_route_53_domain_transfer_lock_disabled.toml @@ -2,7 +2,7 @@ creation_date = "2021/05/10" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic", "Austin Songer"] @@ -23,7 +23,42 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS Route 53 Domain Transfer Lock Disabled" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS Route 53 Domain Transfer Lock Disabled + +AWS Route 53's domain transfer lock is a security feature that prevents unauthorized domain transfers. Disabling this lock can expose domains to hijacking risks. Adversaries might exploit this by transferring domains to gain control over web traffic or disrupt services. The detection rule monitors successful lock disablement events, alerting analysts to potential unauthorized actions, thereby aiding in maintaining domain integrity. + +### Possible investigation steps + +- Review the AWS CloudTrail logs for the specific event.action: DisableDomainTransferLock to identify the user or service account responsible for the action. +- Check the event.provider: route53.amazonaws.com logs to gather additional context about the domain affected and any related activities around the time of the lock disablement. +- Verify the event.outcome: success to confirm that the lock was indeed successfully disabled and not just attempted. +- Investigate the account activity of the user identified in the logs to determine if there are any other suspicious actions or patterns that could indicate unauthorized access. +- Assess whether there was a legitimate business need for the domain transfer lock to be disabled, such as a planned domain transfer, by consulting with relevant stakeholders or reviewing change management records. +- Evaluate the current security posture of the affected domain, ensuring that other security measures are in place to mitigate potential risks from the lock being disabled. + +### False positive analysis + +- Routine domain management activities by authorized personnel can trigger alerts when they intentionally disable the transfer lock for legitimate domain transfers. To manage this, maintain a list of authorized personnel and their expected activities, and cross-reference alerts with this list. +- Scheduled domain transfers as part of business operations may result in false positives. Implement a process to document and pre-approve such transfers, allowing security teams to quickly verify and dismiss these alerts. +- Automated scripts or tools used for domain management might inadvertently disable the transfer lock during updates or maintenance. Ensure these tools are configured correctly and include logging to track their actions, allowing for quick identification and exclusion of benign activities. +- Changes in domain ownership or restructuring within the organization can lead to legitimate transfer lock disablement. Establish a communication protocol between IT and security teams to notify them of such changes in advance, reducing unnecessary alerts. + +### Response and remediation + +- Immediately verify the legitimacy of the domain transfer request by contacting the domain owner or the responsible team to confirm if the action was intentional. +- If the transfer lock was disabled without authorization, re-enable the transfer lock on the affected domain to prevent any unauthorized transfer attempts. +- Conduct a thorough review of AWS CloudTrail logs to identify any unauthorized access or suspicious activities related to the domain management account. +- Reset credentials and enforce multi-factor authentication (MFA) for all accounts with access to AWS Route 53 to prevent further unauthorized actions. +- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordination for further investigation and response. +- Escalate the incident to higher management and legal teams if there is evidence of malicious intent or if the domain is critical to business operations. +- Implement additional monitoring and alerting for any future changes to domain transfer locks to ensure rapid detection and response to similar threats. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml b/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml index 758c5f25b39..ee78e5e193b 100644 --- a/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml +++ b/rules/integrations/aws/persistence_route_53_domain_transferred_to_another_account.toml @@ -2,7 +2,7 @@ creation_date = "2021/05/10" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic", "Austin Songer"] @@ -21,7 +21,42 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS Route 53 Domain Transferred to Another Account" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS Route 53 Domain Transferred to Another Account + +AWS Route 53 is a scalable domain name system (DNS) web service designed to route end-user requests to internet applications. Transferring a domain to another AWS account can be legitimate but may also indicate unauthorized access or account manipulation. Adversaries might exploit this to gain persistent control over a domain. The detection rule monitors successful domain transfer requests, flagging potential misuse by correlating specific AWS CloudTrail events, thus aiding in identifying unauthorized domain transfers. + +### Possible investigation steps + +- Review the AWS CloudTrail logs to identify the specific event with event.action:TransferDomainToAnotherAwsAccount and event.outcome:success to gather details about the domain transfer request. +- Verify the identity of the AWS account to which the domain was transferred by examining the event details, including the account ID and any associated user or role information. +- Check the AWS account's activity history for any unusual or unauthorized access patterns around the time of the domain transfer event. +- Contact the domain's original owner or administrator to confirm whether the transfer was authorized and legitimate. +- Investigate any recent changes in IAM policies or permissions that might have allowed unauthorized users to initiate the domain transfer. +- Assess the potential impact of the domain transfer on your organization's operations and security posture, considering the domain's role in your infrastructure. + +### False positive analysis + +- Routine domain transfers between accounts within the same organization can trigger alerts. To manage this, create exceptions for known internal account transfers by whitelisting specific account IDs involved in regular transfers. +- Scheduled domain management activities by IT teams may result in false positives. Coordinate with IT to document and schedule these activities, then exclude them from alerts during these periods. +- Automated scripts or tools used for domain management might inadvertently trigger alerts. Identify these scripts and their associated user accounts, and configure exceptions for these known, benign activities. +- Transfers related to mergers or acquisitions can be mistaken for unauthorized actions. Ensure that such events are communicated to the security team in advance, allowing them to temporarily adjust monitoring rules to accommodate these legitimate transfers. + +### Response and remediation + +- Immediately revoke any unauthorized access to the AWS account by changing the credentials and access keys associated with the account where the domain was transferred. +- Contact AWS Support to report the unauthorized domain transfer and request assistance in reversing the transfer if it was not authorized. +- Review AWS CloudTrail logs to identify any other suspicious activities or unauthorized access attempts around the time of the domain transfer. +- Implement multi-factor authentication (MFA) for all AWS accounts to enhance security and prevent unauthorized access. +- Conduct a thorough audit of IAM roles and permissions to ensure that only authorized users have the ability to transfer domains. +- Notify relevant stakeholders, including IT security teams and domain administrators, about the incident and the steps being taken to remediate it. +- Enhance monitoring and alerting for similar events by configuring additional AWS CloudWatch alarms or integrating with a Security Information and Event Management (SIEM) system to detect future unauthorized domain transfer attempts. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://docs.aws.amazon.com/Route53/latest/APIReference/API_Operations_Amazon_Route_53.html"] diff --git a/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml b/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml index 50c7b0fa2ed..6bc5d1a3a35 100644 --- a/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml +++ b/rules/integrations/aws/persistence_route_53_hosted_zone_associated_with_a_vpc.toml @@ -2,7 +2,7 @@ creation_date = "2021/07/19" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Austin Songer"] @@ -20,7 +20,41 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS Route53 private hosted zone associated with a VPC" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS Route53 private hosted zone associated with a VPC + +AWS Route53 private hosted zones allow for DNS management within a Virtual Private Cloud (VPC), ensuring internal resources are accessible only within the VPC. Adversaries might exploit this by associating unauthorized VPCs to intercept or reroute traffic. The detection rule identifies successful associations of VPCs with hosted zones, signaling potential misuse or unauthorized access attempts. + +### Possible investigation steps + +- Review the CloudTrail logs for the event.dataset:aws.cloudtrail and event.provider:route53.amazonaws.com to gather details about the AssociateVPCWithHostedZone action, including the time of the event and the identity of the user or role that performed the action. +- Verify the event.outcome:success to confirm that the association was successful and identify the specific VPC and hosted zone involved in the association. +- Check the AWS IAM policies and permissions of the user or role that initiated the association to ensure they have the appropriate level of access and determine if the action aligns with their expected responsibilities. +- Investigate the associated VPC to determine if it is authorized and expected to be linked with the private hosted zone. Look for any unusual or unauthorized VPCs that may indicate potential misuse. +- Review recent changes or activities in the AWS account to identify any other suspicious actions or patterns that could suggest a broader security incident or compromise. + +### False positive analysis + +- Routine infrastructure changes may trigger this rule when legitimate VPCs are associated with private hosted zones during regular operations. To manage this, maintain an updated list of authorized VPCs and compare them against the detected associations. +- Automated deployment tools or scripts that frequently associate VPCs with hosted zones can cause false positives. Identify these tools and create exceptions for their known activities to reduce noise. +- Development and testing environments often involve frequent changes and associations of VPCs with hosted zones. Consider excluding these environments from the rule or setting up a separate monitoring policy with adjusted thresholds. +- Scheduled maintenance or updates might involve temporary associations of VPCs with hosted zones. Document these schedules and incorporate them into the monitoring system to prevent false alerts during these periods. + +### Response and remediation + +- Immediately isolate the VPC associated with the unauthorized Route53 private hosted zone to prevent further unauthorized access or data exfiltration. +- Review CloudTrail logs to identify the source and method of the unauthorized VPC association, focusing on the user or role that performed the action. +- Revoke any unauthorized access or permissions identified during the log review, particularly those related to the IAM roles or users involved in the incident. +- Conduct a security review of the affected VPC and associated resources to ensure no other configurations have been tampered with or compromised. +- Notify the security operations team and relevant stakeholders about the incident for further investigation and potential escalation. +- Implement additional monitoring and alerting for similar events in the future, ensuring that any unauthorized associations are detected promptly. +- Review and update IAM policies and security group rules to enforce the principle of least privilege, reducing the risk of similar incidents occurring. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://docs.aws.amazon.com/Route53/latest/APIReference/API_AssociateVPCWithHostedZone.html"] diff --git a/rules/integrations/aws/persistence_route_table_created.toml b/rules/integrations/aws/persistence_route_table_created.toml index c254309c058..97f6c434e2c 100644 --- a/rules/integrations/aws/persistence_route_table_created.toml +++ b/rules/integrations/aws/persistence_route_table_created.toml @@ -2,7 +2,7 @@ creation_date = "2021/06/05" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic", "Austin Songer"] @@ -21,7 +21,43 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS Route Table Created" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS Route Table Created + +AWS Route Tables are crucial components in managing network traffic within AWS environments, directing data between subnets and internet gateways. Adversaries may exploit route tables to reroute traffic for data exfiltration or to establish persistence by creating unauthorized routes. The detection rule monitors successful creation events of route tables, flagging potential misuse by correlating specific AWS CloudTrail logs, thus aiding in identifying unauthorized network configuration changes. + +### Possible investigation steps + +- Review the AWS CloudTrail logs for the specific event.provider:ec2.amazonaws.com and event.action values (CreateRoute or CreateRouteTable) to identify the user or role that initiated the route table creation. +- Check the event.outcome:success field to confirm the successful creation of the route table and gather additional context such as timestamps and source IP addresses. +- Investigate the associated AWS account and IAM user or role to determine if the action aligns with expected behavior and permissions. +- Examine the newly created route table's configuration to identify any unauthorized or suspicious routes that could indicate potential misuse or data exfiltration attempts. +- Correlate the event with other network security monitoring data to identify any unusual traffic patterns or anomalies that coincide with the route table creation. +- Assess the environment for any recent changes or incidents that might explain the creation of the route table, such as new deployments or infrastructure modifications. + +### False positive analysis + +- Routine infrastructure updates or deployments may trigger route table creation events. To manage this, establish a baseline of expected behavior during scheduled maintenance windows and exclude these from alerts. +- Automated cloud management tools often create route tables as part of their operations. Identify these tools and create exceptions for their known activities to reduce noise. +- Development and testing environments frequently undergo changes, including the creation of route tables. Consider excluding these environments from alerts or applying a different set of monitoring rules. +- Legitimate changes by authorized personnel can be mistaken for suspicious activity. Implement a process to verify and document authorized changes, allowing for quick exclusion of these events from alerts. +- Multi-account AWS setups might have centralized networking teams that create route tables across accounts. Coordinate with these teams to understand their activities and exclude them from triggering alerts. + +### Response and remediation + +- Immediately isolate the affected AWS account or VPC to prevent further unauthorized network changes and potential data exfiltration. +- Review the newly created route table and any associated routes to identify unauthorized entries. Remove any routes that are not part of the expected network configuration. +- Conduct a thorough audit of IAM roles and permissions to ensure that only authorized users have the ability to create or modify route tables. Revoke any excessive permissions identified. +- Implement network monitoring to detect unusual traffic patterns that may indicate data exfiltration or other malicious activities. +- Escalate the incident to the security operations team for further investigation and to determine if additional AWS resources have been compromised. +- Review AWS CloudTrail logs for any other suspicious activities around the time of the route table creation to identify potential indicators of compromise. +- Update security policies and procedures to include specific guidelines for monitoring and responding to unauthorized route table modifications, ensuring rapid detection and response in the future. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/aws/persistence_route_table_modified_or_deleted.toml b/rules/integrations/aws/persistence_route_table_modified_or_deleted.toml index 8829dc1659b..b6f0f019f77 100644 --- a/rules/integrations/aws/persistence_route_table_modified_or_deleted.toml +++ b/rules/integrations/aws/persistence_route_table_modified_or_deleted.toml @@ -2,7 +2,7 @@ creation_date = "2021/06/05" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic", "Austin Songer"] @@ -21,7 +21,43 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "AWS Route Table Modified or Deleted" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS Route Table Modified or Deleted + +AWS Route Tables are crucial for directing network traffic within a VPC. Adversaries may exploit these by altering or deleting routes to disrupt services or reroute traffic for data exfiltration. The detection rule monitors AWS CloudTrail logs for specific actions like route replacement or deletion, signaling potential unauthorized modifications that could indicate malicious activity. + +### Possible investigation steps + +- Review the AWS CloudTrail logs to identify the specific user or role associated with the event.provider:ec2.amazonaws.com actions such as ReplaceRoute, ReplaceRouteTableAssociation, DeleteRouteTable, DeleteRoute, or DisassociateRouteTable. +- Check the event.time field in the CloudTrail logs to determine the exact time of the modification or deletion and correlate it with any other suspicious activities or alerts around the same timeframe. +- Investigate the source IP address and location from which the changes were made to assess if they align with expected administrative access patterns. +- Examine the AWS IAM policies and permissions associated with the user or role to determine if they have legitimate access to modify or delete route tables. +- Review recent changes in the AWS environment, such as new deployments or updates, to understand if the route table modifications were part of planned activities. +- Contact the user or team responsible for the changes to verify if the actions were authorized and intended as part of routine operations. + +### False positive analysis + +- Routine infrastructure updates or maintenance activities by authorized personnel can trigger alerts. To manage this, create exceptions for known maintenance windows or specific user accounts that regularly perform these tasks. +- Automated scripts or tools used for infrastructure management might modify route tables as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific user agent strings or IAM roles. +- Changes made by cloud service providers during updates or optimizations can also appear as modifications. Monitor communications from AWS for scheduled changes and temporarily adjust detection rules to accommodate these events. +- Development and testing environments often undergo frequent changes that are non-threatening. Consider excluding these environments from the rule or applying a different risk threshold to reduce noise. +- Multi-account setups where centralized management tools modify route tables across accounts can lead to false positives. Implement account-specific exclusions or adjust the rule to recognize these centralized actions. + +### Response and remediation + +- Immediately isolate the affected VPC to prevent further unauthorized access or data exfiltration. This can be done by temporarily modifying security group rules to restrict inbound and outbound traffic. +- Review the AWS CloudTrail logs to identify the source of the unauthorized modifications. Focus on the user identity, IP address, and time of the event to understand the scope and origin of the threat. +- Revert any unauthorized changes to the route tables by restoring them to their last known good configuration. This may involve manually recreating deleted routes or associations. +- Implement IAM policies to restrict permissions for modifying route tables to only essential personnel. Ensure that the principle of least privilege is enforced. +- Enable AWS Config to continuously monitor and record configuration changes to route tables, providing an audit trail for future incidents. +- Set up CloudWatch Alarms to alert on any future unauthorized modifications to route tables, ensuring rapid detection and response. +- If the incident is confirmed as malicious, escalate to the security operations team for further investigation and potential involvement of AWS support or legal authorities. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml b/rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml index c4dcc60e1a5..bee33bee0ab 100644 --- a/rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml +++ b/rules/integrations/aws/persistence_sts_assume_role_with_new_mfa.toml @@ -2,7 +2,7 @@ creation_date = "2024/10/25" integration = ["aws"] maturity = "production" -updated_date = "2024/10/25" +updated_date = "2025/01/10" [rule] @@ -18,7 +18,43 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"] language = "kuery" license = "Elastic License v2" name = "AWS STS AssumeRole with New MFA Device" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS STS AssumeRole with New MFA Device + +AWS Security Token Service (STS) allows users to assume roles and gain temporary credentials for accessing AWS resources. This process can involve Multi-Factor Authentication (MFA) for enhanced security. However, adversaries may exploit new MFA devices to maintain persistence or escalate privileges. The detection rule identifies successful role assumptions with new MFA devices, flagging potential misuse for further investigation. + +### Possible investigation steps + +- Review the event details in AWS CloudTrail to identify the user who assumed the role, focusing on the user.id field to determine if the user is legitimate and authorized to use the new MFA device. +- Check the serialNumber in the aws.cloudtrail.flattened.request_parameters to verify the registration and legitimacy of the new MFA device associated with the role assumption. +- Investigate the context of the AssumeRole action by examining the event.action field to understand if it was part of a legitimate workflow or an unusual activity. +- Analyze the event.outcome field to confirm the success of the role assumption and cross-reference with any recent changes in user permissions or MFA device registrations. +- Correlate the event with other logs or alerts to identify any patterns of suspicious behavior, such as multiple role assumptions or changes in MFA devices within a short timeframe. +- Contact the user or relevant team to confirm if the new MFA device registration and role assumption were expected and authorized. + +### False positive analysis + +- New employee onboarding processes may trigger this rule when new MFA devices are issued. To manage this, create exceptions for known onboarding activities by correlating with HR records or onboarding schedules. +- Routine device replacements or upgrades can result in new MFA devices being registered. Implement a process to track and verify device changes through IT support tickets or asset management systems. +- Users with multiple roles or responsibilities might frequently switch roles using different MFA devices. Establish a baseline of normal behavior for these users and create exceptions for their typical activity patterns. +- Organizational policy changes that require MFA updates can lead to multiple new MFA device registrations. Coordinate with security teams to whitelist these events during policy rollout periods. +- Temporary contractors or third-party vendors may use new MFA devices when accessing AWS resources. Ensure that their access is logged and reviewed, and create temporary exceptions for their known access periods. + +### Response and remediation + +- Immediately revoke the temporary credentials associated with the assumed role to prevent unauthorized access to AWS resources. +- Verify the legitimacy of the new MFA device by contacting the user or administrator associated with the role assumption. Confirm whether the device was intentionally registered and used. +- If the new MFA device is determined to be unauthorized, disable or remove it from the user's account to prevent further misuse. +- Conduct a review of recent AWS CloudTrail logs to identify any suspicious activities or patterns associated with the user or role in question, focusing on privilege escalation or lateral movement attempts. +- Escalate the incident to the security operations team for further investigation and to determine if additional containment measures are necessary. +- Implement additional monitoring and alerting for unusual MFA device registrations and role assumptions to enhance detection of similar threats in the future. +- Review and update IAM policies and MFA device management procedures to ensure they align with best practices for security and access control. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/aws/privilege_escalation_ec2_instance_connect_ssh_public_key_uploaded.toml b/rules/integrations/aws/privilege_escalation_ec2_instance_connect_ssh_public_key_uploaded.toml index 1e152b855ff..54083cbcec8 100644 --- a/rules/integrations/aws/privilege_escalation_ec2_instance_connect_ssh_public_key_uploaded.toml +++ b/rules/integrations/aws/privilege_escalation_ec2_instance_connect_ssh_public_key_uploaded.toml @@ -2,7 +2,7 @@ creation_date = "2024/04/30" integration = ["aws"] maturity = "production" -updated_date = "2024/07/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -18,7 +18,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"] language = "kuery" license = "Elastic License v2" name = "AWS EC2 Instance Connect SSH Public Key Uploaded" -note = """## Triage and Analysis +note = """## Triage and analysis ### Investigating AWS EC2 Instance Connect SSH Public Key Uploaded diff --git a/rules/integrations/aws/privilege_escalation_iam_customer_managed_policy_attached_to_role.toml b/rules/integrations/aws/privilege_escalation_iam_customer_managed_policy_attached_to_role.toml index 0e20b0ca5e4..edba032c682 100644 --- a/rules/integrations/aws/privilege_escalation_iam_customer_managed_policy_attached_to_role.toml +++ b/rules/integrations/aws/privilege_escalation_iam_customer_managed_policy_attached_to_role.toml @@ -2,7 +2,7 @@ creation_date = "2024/11/04" integration = ["aws"] maturity = "production" -updated_date = "2024/11/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -29,7 +29,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"] language = "kuery" license = "Elastic License v2" name = "AWS IAM Customer-Managed Policy Attached to Role by Rare User" -note = """## Triage and Analysis +note = """## Triage and analysis ### Investigating AWS IAM Customer-Managed Policy Attachment to Role by Unusual User diff --git a/rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml b/rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml index 7d54a01401c..6ed6e68ae9c 100644 --- a/rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml +++ b/rules/integrations/aws/privilege_escalation_iam_saml_provider_updated.toml @@ -2,7 +2,7 @@ creation_date = "2021/09/22" integration = ["aws"] maturity = "production" -updated_date = "2024/07/16" +updated_date = "2025/01/10" [rule] author = ["Elastic", "Austin Songer"] @@ -19,7 +19,42 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"] language = "kuery" license = "Elastic License v2" name = "AWS IAM SAML Provider Updated" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS IAM SAML Provider Updated + +AWS IAM SAML providers facilitate federated access, allowing users to authenticate via external identity providers. Adversaries may exploit this by updating SAML providers to gain unauthorized access or escalate privileges. The detection rule monitors successful updates to SAML providers, flagging potential privilege escalation attempts by correlating specific AWS CloudTrail events. + +### Possible investigation steps + +- Review the AWS CloudTrail logs to identify the user or role associated with the UpdateSAMLProvider event. Check for any unusual or unauthorized users making changes. +- Examine the context of the UpdateSAMLProvider event, including the time of the event and any associated IP addresses or locations, to identify any anomalies or suspicious patterns. +- Investigate the history of changes to the specific SAML provider to determine if there have been any recent unauthorized or unexpected modifications. +- Check for any other related AWS CloudTrail events around the same timeframe, such as changes to IAM roles or policies, which might indicate a broader privilege escalation attempt. +- Assess the permissions and access levels of the user or role that performed the update to ensure they align with expected privileges and responsibilities. +- If suspicious activity is confirmed, consider revoking or limiting access for the involved user or role and review the security posture of the AWS environment to prevent future incidents. + +### False positive analysis + +- Routine administrative updates to SAML providers by authorized personnel can trigger alerts. To manage this, maintain a list of known administrators and their expected activities, and create exceptions for these users in the detection rule. +- Scheduled updates or maintenance activities involving SAML providers may also result in false positives. Document these activities and adjust the detection rule to exclude events occurring during these scheduled times. +- Automated scripts or tools used for managing SAML providers can generate alerts if they perform updates. Identify these scripts and their expected behavior, then configure the detection rule to recognize and exclude these specific actions. +- Changes made by trusted third-party services integrated with AWS IAM might be flagged. Verify the legitimacy of these services and consider adding them to an allowlist to prevent unnecessary alerts. + +### Response and remediation + +- Immediately revoke any unauthorized changes to the SAML provider by restoring the previous configuration from backups or logs. +- Conduct a thorough review of recent IAM activity logs to identify any unauthorized access or privilege escalation attempts associated with the updated SAML provider. +- Temporarily disable the affected SAML provider to prevent further unauthorized access while the investigation is ongoing. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring and alerting for any future changes to SAML providers to ensure rapid detection of unauthorized modifications. +- Review and tighten IAM policies and permissions to ensure that only authorized personnel can update SAML providers. +- Consider implementing multi-factor authentication (MFA) for all users with permissions to modify IAM configurations to enhance security. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/aws/privilege_escalation_role_assumption_by_service.toml b/rules/integrations/aws/privilege_escalation_role_assumption_by_service.toml index c23ae37fbfb..7da0d23fada 100644 --- a/rules/integrations/aws/privilege_escalation_role_assumption_by_service.toml +++ b/rules/integrations/aws/privilege_escalation_role_assumption_by_service.toml @@ -2,7 +2,7 @@ creation_date = "2021/05/17" integration = ["aws"] maturity = "production" -updated_date = "2024/11/07" +updated_date = "2025/01/10" [rule] author = ["Elastic", "Austin Songer"] @@ -25,7 +25,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"] language = "kuery" license = "Elastic License v2" name = "AWS STS Role Assumption by Service" -note = """## Triage and Analysis +note = """## Triage and analysis ### Investigating AWS STS Role Assumption by Service diff --git a/rules/integrations/aws/privilege_escalation_role_assumption_by_user.toml b/rules/integrations/aws/privilege_escalation_role_assumption_by_user.toml index da41ca73b82..b5c3eb59cee 100644 --- a/rules/integrations/aws/privilege_escalation_role_assumption_by_user.toml +++ b/rules/integrations/aws/privilege_escalation_role_assumption_by_user.toml @@ -2,7 +2,7 @@ creation_date = "2024/11/05" integration = ["aws"] maturity = "production" -updated_date = "2024/11/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -24,7 +24,7 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"] language = "kuery" license = "Elastic License v2" name = "AWS STS Role Assumption by User" -note = """## Triage and Analysis +note = """## Triage and analysis ### Investigating AWS STS Role Assumption by User diff --git a/rules/integrations/aws/privilege_escalation_sts_assume_root_from_rare_user_and_member_account.toml b/rules/integrations/aws/privilege_escalation_sts_assume_root_from_rare_user_and_member_account.toml index 3bb48c3b9a7..36cb87e2ac7 100644 --- a/rules/integrations/aws/privilege_escalation_sts_assume_root_from_rare_user_and_member_account.toml +++ b/rules/integrations/aws/privilege_escalation_sts_assume_root_from_rare_user_and_member_account.toml @@ -2,7 +2,7 @@ creation_date = "2024/11/24" integration = ["aws"] maturity = "production" -updated_date = "2024/11/24" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -25,7 +25,7 @@ language = "kuery" license = "Elastic License v2" name = "AWS STS AssumeRoot by Rare User and Member Account" note = """ -## Triage and Analysis +## Triage and analysis ### Investigating AWS STS AssumeRoot by Rare User and Member Account diff --git a/rules/integrations/aws/privilege_escalation_sts_getsessiontoken_abuse.toml b/rules/integrations/aws/privilege_escalation_sts_getsessiontoken_abuse.toml index 7bde75f679e..f39eaf92ea8 100644 --- a/rules/integrations/aws/privilege_escalation_sts_getsessiontoken_abuse.toml +++ b/rules/integrations/aws/privilege_escalation_sts_getsessiontoken_abuse.toml @@ -2,7 +2,7 @@ creation_date = "2021/05/17" integration = ["aws"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Austin Songer"] @@ -21,7 +21,42 @@ index = ["filebeat-*", "logs-aws.cloudtrail-*"] language = "kuery" license = "Elastic License v2" name = "AWS STS GetSessionToken Abuse" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS STS GetSessionToken Abuse + +AWS Security Token Service (STS) provides temporary credentials for AWS resources, crucial for managing access without long-term credentials. Adversaries may exploit GetSessionToken to create temporary credentials, enabling lateral movement and privilege escalation. The detection rule identifies successful GetSessionToken requests by IAM users, flagging potential misuse for further investigation. + +### Possible investigation steps + +- Review the CloudTrail logs for the specific GetSessionToken event to gather details about the IAM user involved, including the time of the request and the source IP address. +- Check the IAM user's activity history to identify any unusual patterns or deviations from their normal behavior, such as accessing resources they typically do not use. +- Investigate the source IP address from which the GetSessionToken request originated to determine if it is associated with known malicious activity or if it is an unexpected location for the user. +- Examine the permissions and roles associated with the temporary credentials issued by the GetSessionToken request to assess the potential impact of their misuse. +- Correlate the GetSessionToken event with other security events or alerts in the same timeframe to identify any related suspicious activities or potential indicators of compromise. + +### False positive analysis + +- Routine administrative tasks by IAM users can trigger GetSessionToken requests. To manage this, identify and whitelist IAM users or roles that regularly perform these tasks as part of their job functions. +- Automated scripts or applications that use GetSessionToken for legitimate purposes may cause false positives. Review and document these scripts, then create exceptions for their activity in the detection rule. +- Scheduled jobs or services that require temporary credentials for periodic tasks might be flagged. Ensure these are documented and excluded from alerts by adjusting the rule to recognize their specific patterns. +- Development and testing environments often generate GetSessionToken requests during normal operations. Consider excluding these environments from the rule or adjusting the risk score to reflect their lower threat level. +- Cross-account access scenarios where users from one account access resources in another using temporary credentials can appear suspicious. Verify these access patterns and exclude them if they are part of regular operations. + +### Response and remediation + +- Immediately revoke the temporary credentials associated with the suspicious GetSessionToken request to prevent further unauthorized access. +- Conduct a thorough review of the IAM user's activity logs to identify any unauthorized actions or access patterns that may indicate lateral movement or privilege escalation. +- Isolate any affected resources or accounts to contain potential threats and prevent further exploitation. +- Reset the credentials of the IAM user involved and enforce multi-factor authentication (MFA) to enhance security. +- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring and alerting for unusual GetSessionToken requests to detect similar activities in the future. +- Review and tighten IAM policies and permissions to ensure the principle of least privilege is enforced, reducing the risk of privilege escalation. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html"] diff --git a/rules/integrations/aws/privilege_escalation_sts_role_chaining.toml b/rules/integrations/aws/privilege_escalation_sts_role_chaining.toml index 8fad43bd2ff..eaf83a850fa 100644 --- a/rules/integrations/aws/privilege_escalation_sts_role_chaining.toml +++ b/rules/integrations/aws/privilege_escalation_sts_role_chaining.toml @@ -2,7 +2,7 @@ creation_date = "2024/10/23" integration = ["aws"] maturity = "production" -updated_date = "2024/10/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -21,7 +21,43 @@ from = "now-6m" language = "esql" license = "Elastic License v2" name = "AWS STS Role Chaining" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS STS Role Chaining + +AWS Security Token Service (STS) allows temporary, limited-privilege credentials for AWS resources. Role chaining involves using one temporary role to assume another, potentially escalating privileges. Adversaries exploit this by gaining elevated access or persistence. The detection rule identifies such activity by monitoring specific API calls and access patterns within a single account, flagging potential misuse. + +### Possible investigation steps + +- Review the AWS CloudTrail logs to identify the source of the AssumeRole API call by examining the aws.cloudtrail.user_identity.arn field to determine which user or service initiated the role chaining. +- Check the cloud.region field to understand the geographical context of the activity and assess if it aligns with expected operational regions for your organization. +- Investigate the aws.cloudtrail.resources.account_id and aws.cloudtrail.recipient_account_id fields to confirm that the role chaining activity occurred within the same account, as cross-account role chaining is not flagged by this rule. +- Analyze the aws.cloudtrail.user_identity.access_key_id to verify that the access key used is a temporary token starting with "ASIA", indicating the use of temporary credentials. +- Assess the permissions associated with the roles involved in the chaining to determine if the subsequent role provides elevated privileges that could be exploited for privilege escalation or persistence. +- Correlate the timing of the AssumeRole events with other security events or alerts to identify any suspicious patterns or activities that may indicate malicious intent. + +### False positive analysis + +- Cross-account role assumptions are common in many AWS environments and can generate false positives. To mitigate this, ensure the rule is configured to only monitor role chaining within a single account, as specified in the rule description. +- Automated processes or applications that frequently assume roles for legitimate purposes may trigger false positives. Identify these processes and create exceptions for their specific access patterns or user identities. +- Scheduled tasks or scripts that use temporary credentials for routine operations might be flagged. Review these tasks and whitelist their access key IDs if they consistently follow a predictable and secure pattern. +- Development and testing environments often involve frequent role assumptions for testing purposes. Exclude these environments from monitoring or adjust the rule to account for their unique access behaviors. +- Regularly review and update the list of exceptions to ensure that only non-threatening behaviors are excluded, maintaining the effectiveness of the detection rule. + +### Response and remediation + +- Immediately revoke the temporary credentials associated with the detected AssumeRole activity to prevent further unauthorized access. +- Conduct a thorough review of the AWS CloudTrail logs to identify any additional suspicious activities or roles assumed using the compromised credentials. +- Isolate the affected AWS resources and accounts to prevent lateral movement and further privilege escalation within the environment. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Implement stricter IAM policies and role permissions to limit the ability to assume roles unnecessarily, reducing the risk of privilege escalation. +- Enhance monitoring and alerting for AssumeRole activities, especially those involving temporary credentials, to detect similar threats in the future. +- Conduct a post-incident review to identify gaps in security controls and update incident response plans to improve future response efforts. + +## Setup The AWS Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/azure/collection_update_event_hub_auth_rule.toml b/rules/integrations/azure/collection_update_event_hub_auth_rule.toml index b3ffe646b7d..06c916b8ae7 100644 --- a/rules/integrations/azure/collection_update_event_hub_auth_rule.toml +++ b/rules/integrations/azure/collection_update_event_hub_auth_rule.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/18" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -25,7 +25,42 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Event Hub Authorization Rule Created or Updated" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Azure Event Hub Authorization Rule Created or Updated + +Azure Event Hub Authorization Rules manage access to Event Hubs via cryptographic keys, akin to administrative credentials. Adversaries may exploit these rules to gain unauthorized access or escalate privileges, potentially exfiltrating data. The detection rule monitors for the creation or modification of these rules, flagging successful operations to identify potential misuse or unauthorized changes. + +### Possible investigation steps + +- Review the Azure activity logs to identify the user or service principal associated with the operation by examining the `azure.activitylogs.operation_name` and `event.outcome` fields. +- Check the timestamp of the event to determine when the authorization rule was created or updated, and correlate this with any other suspicious activities around the same time. +- Investigate the specific Event Hub namespace affected by the rule change to understand its role and importance within the organization. +- Verify if the `RootManageSharedAccessKey` or any other high-privilege authorization rule was involved, as these carry significant risk if misused. +- Assess the necessity and legitimacy of the rule change by contacting the user or team responsible for the Event Hub namespace to confirm if the change was authorized and aligns with operational needs. +- Examine any subsequent access patterns or data transfers from the affected Event Hub to detect potential data exfiltration or misuse following the rule change. + +### False positive analysis + +- Routine administrative updates to authorization rules by IT staff can trigger alerts. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows. +- Automated scripts or deployment tools that update authorization rules as part of regular operations may cause false positives. Identify these scripts and exclude their activity from alerts by filtering based on their service principal or user identity. +- Changes made by trusted third-party services integrated with Azure Event Hub might be flagged. Verify these services and exclude their operations by adding them to an allowlist. +- Frequent updates during development or testing phases can lead to false positives. Consider setting up separate monitoring profiles for development environments to reduce noise. +- Legitimate changes made by users with appropriate permissions might be misinterpreted as threats. Regularly review and update the list of authorized users to ensure only necessary personnel have access, and exclude their actions from alerts. + +### Response and remediation + +- Immediately revoke or rotate the cryptographic keys associated with the affected Event Hub Authorization Rule to prevent unauthorized access. +- Review the Azure Activity Logs to identify any unauthorized access or data exfiltration attempts that may have occurred using the compromised authorization rule. +- Implement conditional access policies to restrict access to Event Hub Authorization Rules based on user roles and network locations. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been compromised. +- Conduct a security review of all Event Hub Authorization Rules to ensure that only necessary permissions are granted and that the RootManageSharedAccessKey is not used in applications. +- Enhance monitoring and alerting for changes to authorization rules by integrating with a Security Information and Event Management (SIEM) system to detect similar threats in the future. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://docs.microsoft.com/en-us/azure/event-hubs/authorize-access-shared-access-signature"] diff --git a/rules/integrations/azure/credential_access_azure_entra_totp_brute_force_attempts.toml b/rules/integrations/azure/credential_access_azure_entra_totp_brute_force_attempts.toml index 8bb0b88fad1..4a01d6cdd80 100644 --- a/rules/integrations/azure/credential_access_azure_entra_totp_brute_force_attempts.toml +++ b/rules/integrations/azure/credential_access_azure_entra_totp_brute_force_attempts.toml @@ -4,7 +4,7 @@ integration = ["azure"] maturity = "production" min_stack_comments = "ES|QL not available until 8.13.0 in technical preview." min_stack_version = "8.13.0" -updated_date = "2024/12/11" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -25,7 +25,7 @@ from = "now-9m" language = "esql" license = "Elastic License v2" name = "Azure Entra MFA TOTP Brute Force Attempts" -note = """## Triage and Analysis +note = """## Triage and analysis ### Investigating Azure Entra MFA TOTP Brute Force Attempts diff --git a/rules/integrations/azure/credential_access_azure_full_network_packet_capture_detected.toml b/rules/integrations/azure/credential_access_azure_full_network_packet_capture_detected.toml index 92c23e47a2b..285b3ba6b92 100644 --- a/rules/integrations/azure/credential_access_azure_full_network_packet_capture_detected.toml +++ b/rules/integrations/azure/credential_access_azure_full_network_packet_capture_detected.toml @@ -2,7 +2,7 @@ creation_date = "2021/08/12" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Austin Songer"] @@ -24,7 +24,42 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Full Network Packet Capture Detected" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Azure Full Network Packet Capture Detected + +Azure's Packet Capture is a feature of Network Watcher that allows for the inspection of network traffic, useful for diagnosing network issues. However, if misused, it can capture sensitive data from unencrypted traffic, posing a security risk. Adversaries might exploit this to access credentials or other sensitive information. The detection rule identifies suspicious packet capture activities by monitoring specific Azure activity logs for successful operations, helping to flag potential misuse. + +### Possible investigation steps + +- Review the Azure activity logs to identify the specific user or service principal associated with the packet capture operation by examining the `azure.activitylogs.operation_name` and `event.dataset` fields. +- Check the timestamp of the detected packet capture activity to determine the exact time frame of the event and correlate it with any other suspicious activities or changes in the environment. +- Investigate the source and destination IP addresses involved in the packet capture to understand the scope and potential impact, focusing on any unencrypted traffic that might have been captured. +- Verify the legitimacy of the packet capture request by contacting the user or team responsible for the operation to confirm if it was authorized and necessary for troubleshooting or other legitimate purposes. +- Assess the risk of exposed sensitive data by identifying any critical systems or services that were part of the captured network traffic, especially those handling credentials or personal information. + +### False positive analysis + +- Routine network diagnostics by authorized personnel can trigger the rule. To manage this, create exceptions for specific user accounts or IP addresses known to perform regular diagnostics. +- Automated network monitoring tools might initiate packet captures as part of their normal operations. Identify these tools and exclude their activities from triggering alerts. +- Scheduled maintenance activities often involve packet captures for performance analysis. Document these schedules and configure the rule to ignore captures during these periods. +- Development and testing environments may frequently use packet capture for debugging purposes. Exclude these environments by filtering based on resource tags or environment identifiers. +- Legitimate security audits may involve packet capture to assess network security. Coordinate with the audit team to whitelist their activities during the audit period. + +### Response and remediation + +- Immediately isolate the affected network segment to prevent further unauthorized packet capture and potential data exfiltration. +- Revoke any suspicious or unauthorized access to Azure Network Watcher and related resources to prevent further misuse. +- Conduct a thorough review of the captured network traffic logs to identify any sensitive data exposure and assess the potential impact. +- Reset credentials and access tokens for any accounts or services that may have been compromised due to exposed unencrypted traffic. +- Implement network encryption protocols to protect sensitive data in transit and reduce the risk of future packet capture exploitation. +- Escalate the incident to the security operations team for further investigation and to determine if additional security measures are necessary. +- Enhance monitoring and alerting for Azure Network Watcher activities to detect and respond to similar threats more effectively in the future. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations"] diff --git a/rules/integrations/azure/credential_access_entra_id_device_code_auth_with_broker_client.toml b/rules/integrations/azure/credential_access_entra_id_device_code_auth_with_broker_client.toml index 65b062f0ebf..543222f945f 100644 --- a/rules/integrations/azure/credential_access_entra_id_device_code_auth_with_broker_client.toml +++ b/rules/integrations/azure/credential_access_entra_id_device_code_auth_with_broker_client.toml @@ -2,7 +2,7 @@ creation_date = "2024/06/24" integration = ["azure"] maturity = "production" -updated_date = "2024/06/26" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -43,6 +43,41 @@ query = ''' azure.activitylogs.properties.appId:29d9ed98-a469-4536-ade2-f981bc1d605e and azure.activitylogs.properties.authentication_protocol:deviceCode) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Entra ID Device Code Auth with Broker Client + +Entra ID Device Code Authentication allows users to authenticate devices using a code, facilitating seamless access to Azure resources. Adversaries exploit this by compromising Primary Refresh Tokens (PRTs) to bypass multi-factor authentication and Conditional Access policies. The detection rule identifies unauthorized access attempts by monitoring successful sign-ins using device code authentication linked to a specific broker client application ID, flagging potential misuse. + +### Possible investigation steps + +- Review the sign-in logs to confirm the use of device code authentication by checking the field azure.signinlogs.properties.authentication_protocol for the value deviceCode. +- Verify the application ID involved in the sign-in attempt by examining azure.signinlogs.properties.conditional_access_audiences.application_id and ensure it matches 29d9ed98-a469-4536-ade2-f981bc1d605e. +- Investigate the user account associated with the successful sign-in to determine if the activity aligns with expected behavior or if it appears suspicious. +- Check for any recent changes or anomalies in the user's account settings or permissions that could indicate compromise. +- Review the history of sign-ins for the user to identify any patterns or unusual access times that could suggest unauthorized access. +- Assess the device from which the sign-in was attempted to ensure it is a recognized and authorized device for the user. + +### False positive analysis + +- Legitimate device code authentication by trusted applications or users may trigger the rule. Review the application ID and user context to confirm legitimacy. +- Frequent access by automated scripts or services using device code authentication can be mistaken for unauthorized access. Identify and document these services, then create exceptions for known application IDs. +- Shared devices in environments with multiple users may cause false positives if device code authentication is used regularly. Implement user-specific logging to differentiate between legitimate and suspicious activities. +- Regular maintenance or updates by IT teams using device code authentication might be flagged. Coordinate with IT to schedule these activities and temporarily adjust monitoring rules if necessary. +- Ensure that any exceptions or exclusions are regularly reviewed and updated to reflect changes in the environment or application usage patterns. + +### Response and remediation + +- Immediately revoke the compromised Primary Refresh Tokens (PRTs) to prevent further unauthorized access. This can be done through the Azure portal by navigating to the user's account and invalidating all active sessions. +- Enforce a password reset for the affected user accounts to ensure that any credentials potentially compromised during the attack are no longer valid. +- Implement additional Conditional Access policies that require device compliance checks and restrict access to trusted locations or devices only, to mitigate the risk of future PRT abuse. +- Conduct a thorough review of the affected accounts' recent activity logs to identify any unauthorized actions or data access that may have occurred during the compromise. +- Escalate the incident to the security operations team for further investigation and to determine if there are any broader implications or additional compromised accounts. +- Enhance monitoring by configuring alerts for unusual sign-in patterns or device code authentication attempts from unexpected locations or devices, to improve early detection of similar threats. +- Coordinate with the incident response team to perform a post-incident analysis and update the incident response plan with lessons learned from this event.""" [[rule.threat]] diff --git a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml b/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml index 32a179c5ecd..eac8b2ce8d6 100644 --- a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml +++ b/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365.toml @@ -4,7 +4,7 @@ integration = ["azure"] maturity = "production" min_stack_comments = "ES|QL not available until 8.13.0 in technical preview." min_stack_version = "8.13.0" -updated_date = "2024/10/09" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -25,7 +25,43 @@ language = "esql" interval = "10m" license = "Elastic License v2" name = "Azure Entra Sign-in Brute Force against Microsoft 365 Accounts" -note = "This rule relies on Azure Entra ID sign-in logs, but filters for Microsoft 365 resources." +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Entra Sign-in Brute Force against Microsoft 365 Accounts + +Azure Entra ID, integral to Microsoft 365, manages user identities and access. Adversaries exploit this by attempting numerous login attempts to breach accounts, targeting services like Exchange and Teams. The detection rule identifies such threats by analyzing failed login patterns within a 30-minute window, flagging unusual activity from multiple sources or excessive failed attempts, thus highlighting potential brute-force attacks. + +### Possible investigation steps + +- Review the `azure.signinlogs.properties.user_principal_name` to identify the specific user account targeted by the brute-force attempts. +- Examine the `source.ip` field to determine the origin of the failed login attempts and assess if multiple IP addresses are involved, indicating a distributed attack. +- Check the `azure.signinlogs.properties.resource_display_name` to understand which Microsoft 365 services (e.g., Exchange, SharePoint, Teams) were targeted during the login attempts. +- Analyze the `target_time_window` to confirm the timeframe of the attack and correlate it with other security events or alerts that may have occurred simultaneously. +- Investigate the `azure.signinlogs.properties.status.error_code` for specific error codes that might provide additional context on the nature of the failed login attempts. +- Assess the user's recent activity and any changes in behavior or access patterns that could indicate a compromised account or insider threat. + +### False positive analysis + +- High volume of legitimate login attempts from a single user can trigger false positives, especially during password resets or account recovery processes. To mitigate this, consider excluding known IP addresses associated with IT support or helpdesk operations. +- Automated scripts or applications that frequently access Microsoft 365 services using non-interactive logins may be misidentified as brute force attempts. Identify and whitelist these applications by their user principal names or IP addresses. +- Users traveling or working remotely may log in from multiple locations in a short period, leading to false positives. Implement geolocation-based exclusions for known travel patterns or use conditional access policies to manage these scenarios. +- Bulk operations performed by administrators, such as batch account updates or migrations, can result in numerous failed logins. Exclude these activities by recognizing the specific user principal names or IP addresses involved in such operations. +- Frequent logins from shared IP addresses, such as those from corporate VPNs or proxy servers, might be flagged. Consider excluding these IP ranges if they are known and trusted within the organization. + +### Response and remediation + +- Immediately isolate the affected user accounts by disabling them to prevent further unauthorized access. +- Conduct a password reset for the compromised accounts, ensuring the new passwords are strong and unique. +- Review and block the IP addresses associated with the failed login attempts to prevent further access attempts from these sources. +- Enable multi-factor authentication (MFA) for the affected accounts and any other accounts that do not have it enabled to add an additional layer of security. +- Monitor the affected accounts and related services for any unusual activity or signs of compromise post-remediation. +- Escalate the incident to the security operations team for further investigation and to determine if there are broader implications or related threats. +- Update and enhance detection rules and monitoring to identify similar brute-force attempts in the future, ensuring quick response to any new threats. + +This rule relies on Azure Entra ID sign-in logs, but filters for Microsoft 365 resources.""" references = [ "https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying", "https://github.com/0xZDH/o365spray" diff --git a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365_repeat_source.toml b/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365_repeat_source.toml index 0517b3b14f8..c32823290dd 100644 --- a/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365_repeat_source.toml +++ b/rules/integrations/azure/credential_access_entra_signin_brute_force_microsoft_365_repeat_source.toml @@ -4,7 +4,7 @@ integration = ["azure"] maturity = "production" min_stack_comments = "ES|QL not available until 8.13.0 in technical preview." min_stack_version = "8.13.0" -updated_date = "2024/10/09" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -25,7 +25,43 @@ language = "esql" interval = "10m" license = "Elastic License v2" name = "Azure Entra Sign-in Brute Force Microsoft 365 Accounts by Repeat Source" -note = "This rule relies on Azure Entra ID sign-in logs, but filters for Microsoft 365 resources." +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Entra Sign-in Brute Force Microsoft 365 Accounts by Repeat Source + +Azure Entra ID, integral to Microsoft 365, manages identity and access, ensuring secure authentication. Adversaries exploit this by attempting numerous failed logins to breach accounts. The detection rule identifies such brute-force attempts by monitoring failed logins from a single IP within a short timeframe, flagging potential unauthorized access efforts. + +### Possible investigation steps + +- Review the source IP address identified in the alert to determine if it is associated with known malicious activity or if it belongs to a legitimate user or organization. +- Examine the list of user principal names targeted by the failed login attempts to identify any patterns or specific users that may be at higher risk. +- Check the azure.signinlogs.properties.resource_display_name to understand which Microsoft 365 services were targeted, such as Exchange, SharePoint, or Teams, and assess the potential impact on those services. +- Investigate the error codes in azure.signinlogs.properties.status.error_code for additional context on why the login attempts failed, which may provide insights into the attacker's methods. +- Correlate the failed login attempts with any successful logins from the same source IP or user accounts to identify potential unauthorized access. +- Assess the risk and exposure of the affected user accounts and consider implementing additional security measures, such as multi-factor authentication, if not already in place. + +### False positive analysis + +- High volume of legitimate login attempts from a single IP, such as a corporate proxy or VPN, can trigger false positives. To mitigate, exclude known IP addresses of trusted network infrastructure from the rule. +- Automated scripts or applications performing frequent login operations on behalf of users may be misidentified as brute force attempts. Identify and whitelist these applications by their source IPs or user agents. +- Shared workstations or kiosks where multiple users log in from the same IP address can result in false positives. Implement user-based exclusions for these environments to prevent unnecessary alerts. +- Frequent password resets or account recovery processes can generate multiple failed login attempts. Monitor and exclude these activities by correlating with password reset logs or helpdesk tickets. +- Training or testing environments where multiple failed logins are expected should be excluded by identifying and filtering out the associated IP ranges or user accounts. + +### Response and remediation + +- Immediately block the source IP address identified in the alert to prevent further unauthorized access attempts. +- Reset passwords for all affected user accounts that experienced failed login attempts from the flagged IP address to ensure account security. +- Enable multi-factor authentication (MFA) for the affected accounts if not already in place, to add an additional layer of security against unauthorized access. +- Review and update conditional access policies to restrict access from suspicious or untrusted locations, enhancing security posture. +- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation. +- Monitor the affected accounts and source IP for any additional suspicious activity, ensuring no further attempts are made. +- Document the incident details, including the source IP, affected accounts, and actions taken, for future reference and compliance purposes. + +This rule relies on Azure Entra ID sign-in logs, but filters for Microsoft 365 resources.""" references = [ "https://cloud.hacktricks.xyz/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-password-spraying", "https://github.com/0xZDH/o365spray" diff --git a/rules/integrations/azure/credential_access_first_time_seen_device_code_auth.toml b/rules/integrations/azure/credential_access_first_time_seen_device_code_auth.toml index 76341ee2959..ad00781c91a 100644 --- a/rules/integrations/azure/credential_access_first_time_seen_device_code_auth.toml +++ b/rules/integrations/azure/credential_access_first_time_seen_device_code_auth.toml @@ -2,7 +2,7 @@ creation_date = "2024/10/14" integration = ["azure"] maturity = "production" -updated_date = "2024/10/14" +updated_date = "2025/01/10" [rule] author = ["Elastic", "Matteo Potito Giorgio"] @@ -38,6 +38,40 @@ query = ''' event.dataset:(azure.activitylogs or azure.signinlogs) and (azure.signinlogs.properties.authentication_protocol:deviceCode or azure.activitylogs.properties.authentication_protocol:deviceCode) and event.outcome:success ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 First Occurrence of Entra ID Auth via DeviceCode Protocol + +The DeviceCode protocol facilitates authentication for devices lacking keyboards, streamlining user access without manual credential entry. However, attackers can exploit this by phishing users to capture access tokens, enabling unauthorized access. The detection rule identifies new instances of this protocol use, flagging potential misuse by monitoring successful authentications within a 14-day window, thus aiding in early threat detection. + +### Possible investigation steps + +- Review the event logs to confirm the presence of the deviceCode protocol in the authentication process by checking the fields azure.signinlogs.properties.authentication_protocol or azure.activitylogs.properties.authentication_protocol. +- Verify the event outcome by examining the event.outcome field to ensure the authentication was successful. +- Identify the user associated with the authentication attempt and review their recent activity for any anomalies or signs of compromise. +- Check the device information to determine if the authentication was performed on a device that typically lacks a keyboard, which would justify the use of the deviceCode protocol. +- Investigate any recent phishing attempts or suspicious communications that could have targeted the user to capture their access tokens. +- Assess the risk score and severity to prioritize the investigation and determine if immediate action is required to mitigate potential threats. + +### False positive analysis + +- Legitimate device setup activities may trigger alerts when new devices without keyboards are being configured. To manage this, maintain a list of known devices and exclude their initial setup from triggering alerts. +- Regular use of shared devices in environments like conference rooms or kiosks can result in repeated alerts. Implement a policy to track and whitelist these shared devices to prevent unnecessary alerts. +- Automated scripts or applications using the deviceCode protocol for legitimate purposes might be flagged. Identify and document these scripts, then create exceptions for their activity to avoid false positives. +- Users who frequently travel and use different devices may trigger alerts. Monitor and verify these users' travel patterns and device usage, and consider excluding their known travel-related activities from the rule. + +### Response and remediation + +- Immediately revoke the access tokens associated with the suspicious deviceCode authentication to prevent further unauthorized access. +- Conduct a thorough review of the affected user's account activity to identify any unauthorized actions or data access that may have occurred. +- Reset the credentials of the affected user and enforce multi-factor authentication (MFA) to enhance account security. +- Isolate any devices that were authenticated using the deviceCode protocol to prevent potential lateral movement within the network. +- Notify the security operations team and escalate the incident to ensure a coordinated response and further investigation into potential phishing attempts. +- Implement additional monitoring for anomalous deviceCode protocol usage across the organization to detect similar threats in the future. +- Review and update access policies to restrict the use of the deviceCode protocol to only those devices and scenarios where it is absolutely necessary.""" [[rule.threat]] diff --git a/rules/integrations/azure/credential_access_key_vault_modified.toml b/rules/integrations/azure/credential_access_key_vault_modified.toml index b58c6dfac3f..fdef9ad5f15 100644 --- a/rules/integrations/azure/credential_access_key_vault_modified.toml +++ b/rules/integrations/azure/credential_access_key_vault_modified.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/31" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -23,7 +23,42 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Key Vault Modified" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Key Vault Modified + +Azure Key Vault is a critical service for managing sensitive information like encryption keys and secrets. It ensures that only authorized users and applications can access these resources. However, adversaries may attempt to modify Key Vault settings to gain unauthorized access to credentials. The detection rule monitors for successful write operations to Key Vaults, flagging potential unauthorized modifications that could indicate credential access attempts. + +### Possible investigation steps + +- Review the Azure activity logs to identify the specific user or application that performed the write operation on the Key Vault by examining the user identity and application ID fields. +- Check the timestamp of the write operation to determine if it aligns with expected maintenance windows or known changes, which could indicate legitimate activity. +- Investigate the specific changes made to the Key Vault by reviewing the operation details to understand what was modified, such as access policies or secret values. +- Correlate the activity with other security logs or alerts to identify any related suspicious behavior, such as failed login attempts or unusual access patterns from the same user or application. +- Verify if the user or application that performed the write operation had legitimate access and permissions to modify the Key Vault by reviewing their role assignments and access policies. +- Assess the potential impact of the modification by determining if any sensitive keys or secrets were exposed or altered, and evaluate the risk to the organization. + +### False positive analysis + +- Routine administrative updates to Key Vault configurations by authorized personnel can trigger alerts. To manage this, maintain a list of known administrative accounts and exclude their activities from triggering alerts. +- Automated scripts or applications that regularly update Key Vault settings as part of normal operations may cause false positives. Identify these scripts and whitelist their operations to prevent unnecessary alerts. +- Scheduled maintenance activities that involve updating Key Vault settings can be mistaken for unauthorized modifications. Document these activities and create exceptions for the time frames during which they occur. +- Integration with third-party services that require periodic updates to Key Vault settings might generate alerts. Verify these integrations and exclude their operations if they are deemed secure and necessary. + +### Response and remediation + +- Immediately revoke access to the affected Key Vault for any unauthorized users or applications identified during the investigation to prevent further unauthorized access. +- Rotate all secrets, keys, and certificates stored in the compromised Key Vault to ensure that any potentially exposed credentials are no longer valid. +- Conduct a thorough review of the Key Vault's access policies and permissions to ensure that only authorized users and applications have the necessary access, and implement stricter access controls if needed. +- Enable logging and monitoring for the Key Vault to capture detailed access and modification events, ensuring that any future unauthorized attempts are quickly detected. +- Notify the security team and relevant stakeholders about the incident, providing them with details of the unauthorized modifications and actions taken to remediate the issue. +- If the unauthorized access is suspected to be part of a larger breach, escalate the incident to the incident response team for further investigation and potential involvement of law enforcement if necessary. +- Review and update incident response plans and playbooks to incorporate lessons learned from this incident, ensuring a more effective response to similar threats in the future. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/azure/credential_access_storage_account_key_regenerated.toml b/rules/integrations/azure/credential_access_storage_account_key_regenerated.toml index 5f1e83dabbf..a18025787ae 100644 --- a/rules/integrations/azure/credential_access_storage_account_key_regenerated.toml +++ b/rules/integrations/azure/credential_access_storage_account_key_regenerated.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/19" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -23,7 +23,42 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Storage Account Key Regenerated" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Storage Account Key Regenerated + +Azure Storage Account keys are critical credentials that grant access to storage resources. They are often used by applications and services to authenticate and interact with Azure Storage. Adversaries may regenerate these keys to gain unauthorized access, potentially disrupting services or exfiltrating data. The detection rule monitors for key regeneration events, flagging successful operations as potential indicators of credential misuse, thus enabling timely investigation and response. + +### Possible investigation steps + +- Review the Azure activity logs to identify the specific storage account associated with the key regeneration event by examining the operation_name field for "MICROSOFT.STORAGE/STORAGEACCOUNTS/REGENERATEKEY/ACTION". +- Check the event.outcome field to confirm the success of the key regeneration and gather details about the user or service principal that initiated the action. +- Investigate the user or service principal's recent activities in Azure to determine if there are any other suspicious actions or patterns that could indicate unauthorized access or misuse. +- Assess the impact on applications and services that rely on the affected storage account key by identifying dependencies and checking for any service disruptions or anomalies. +- Review access policies and permissions for the storage account to ensure they are appropriately configured and consider implementing additional security measures, such as Azure Key Vault, to manage and rotate keys securely. + +### False positive analysis + +- Routine key rotation by administrators or automated scripts can trigger alerts. To manage this, identify and document regular key rotation schedules and exclude these events from alerts. +- Development and testing environments often regenerate keys frequently. Exclude these environments from alerts by filtering based on environment tags or resource names. +- Third-party integrations or services that require periodic key regeneration might cause false positives. Work with service owners to understand these patterns and create exceptions for known, legitimate services. +- Azure policies or compliance checks that enforce key rotation can also lead to false positives. Coordinate with compliance teams to align detection rules with policy schedules and exclude these events. +- Ensure that any automated processes that regenerate keys are logged and documented. Use this documentation to create exceptions for these processes in the detection rule. + +### Response and remediation + +- Immediately revoke the regenerated storage account keys to prevent unauthorized access. This can be done through the Azure portal or using Azure CLI commands. +- Identify and update all applications and services that rely on the compromised storage account keys with new, secure keys to restore functionality and prevent service disruption. +- Conduct a thorough review of access logs and audit trails to identify any unauthorized access or data exfiltration attempts that may have occurred using the regenerated keys. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or accounts have been compromised. +- Implement conditional access policies and multi-factor authentication (MFA) for accessing Azure resources to enhance security and prevent similar incidents. +- Review and update the storage account's access policies and permissions to ensure that only authorized users and applications have the necessary access. +- Enhance monitoring and alerting mechanisms to detect future unauthorized key regeneration attempts promptly, ensuring timely response to potential threats. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/azure/defense_evasion_azure_application_credential_modification.toml b/rules/integrations/azure/defense_evasion_azure_application_credential_modification.toml index e6d6c3ef2b1..e9f7a68124e 100644 --- a/rules/integrations/azure/defense_evasion_azure_application_credential_modification.toml +++ b/rules/integrations/azure/defense_evasion_azure_application_credential_modification.toml @@ -2,7 +2,7 @@ creation_date = "2020/12/14" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -25,7 +25,43 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Application Credential Modification" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Azure Application Credential Modification + +Azure applications use credentials like certificates or secret strings for identity verification during token requests. Adversaries may exploit this by adding unauthorized credentials, enabling persistent access or evading defenses. The detection rule monitors audit logs for successful updates to application credentials, flagging potential misuse by identifying unauthorized credential modifications. + +### Possible investigation steps + +- Review the Azure audit logs to identify the specific application that had its credentials updated, focusing on entries with the operation name "Update application - Certificates and secrets management" and a successful outcome. +- Determine the identity of the user or service principal that performed the credential modification by examining the associated user or principal ID in the audit log entry. +- Investigate the context of the credential modification by checking for any recent changes or unusual activities related to the application, such as modifications to permissions or roles. +- Assess the legitimacy of the new credential by verifying if it aligns with expected operational procedures or if it was authorized by a known and trusted entity. +- Check for any additional suspicious activities in the audit logs around the same timeframe, such as failed login attempts or other modifications to the application, to identify potential indicators of compromise. +- Contact the application owner or relevant stakeholders to confirm whether the credential addition was expected and authorized, and gather any additional context or concerns they might have. + +### False positive analysis + +- Routine credential updates by authorized personnel can trigger alerts. Regularly review and document credential management activities to distinguish between legitimate and suspicious actions. +- Automated processes or scripts that update application credentials as part of maintenance or deployment cycles may cause false positives. Identify and whitelist these processes to prevent unnecessary alerts. +- Credential updates during application scaling or migration might be flagged. Coordinate with IT teams to schedule these activities and temporarily adjust monitoring thresholds or exclusions. +- Third-party integrations that require periodic credential updates can be mistaken for unauthorized changes. Maintain an inventory of such integrations and establish baseline behaviors to filter out benign activities. +- Frequent updates by specific service accounts could be part of normal operations. Monitor these accounts separately and consider creating exceptions for known, non-threatening patterns. + +### Response and remediation + +- Immediately revoke the unauthorized credentials by accessing the Azure portal and removing any suspicious certificates or secret strings associated with the affected application. +- Conduct a thorough review of the application's access logs to identify any unauthorized access or actions performed using the compromised credentials. +- Reset and update all legitimate credentials for the affected application to ensure no further unauthorized access can occur. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized credential modification and any potential impact. +- Implement additional monitoring on the affected application to detect any further unauthorized changes or access attempts. +- Review and tighten access controls and permissions for managing application credentials to prevent unauthorized modifications in the future. +- If necessary, escalate the incident to higher-level security management or external cybersecurity experts for further investigation and response. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/azure/defense_evasion_azure_automation_runbook_deleted.toml b/rules/integrations/azure/defense_evasion_azure_automation_runbook_deleted.toml index 50ea493d443..3e08bd09d05 100644 --- a/rules/integrations/azure/defense_evasion_azure_automation_runbook_deleted.toml +++ b/rules/integrations/azure/defense_evasion_azure_automation_runbook_deleted.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/01" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -15,7 +15,42 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Automation Runbook Deleted" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Azure Automation Runbook Deleted + +Azure Automation Runbooks automate repetitive tasks in cloud environments, enhancing operational efficiency. Adversaries may exploit this by deleting runbooks to disrupt operations or conceal malicious activities. The detection rule monitors Azure activity logs for successful runbook deletions, signaling potential defense evasion tactics, and alerts analysts to investigate further. + +### Possible investigation steps + +- Review the Azure activity logs to confirm the deletion event by checking the operation name "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/DELETE" and ensure the event outcome is marked as Success. +- Identify the user or service principal responsible for the deletion by examining the associated user identity information in the activity logs. +- Investigate the timeline of events leading up to and following the runbook deletion to identify any suspicious activities or patterns, such as unauthorized access attempts or changes to other resources. +- Check for any recent modifications or unusual activities in the affected Azure Automation account to determine if there are other signs of compromise or tampering. +- Assess the impact of the deleted runbook on business operations and determine if any critical automation processes were disrupted. +- If applicable, review any available backup or version history of the deleted runbook to restore it and mitigate operational disruptions. + +### False positive analysis + +- Routine maintenance activities by IT staff may lead to legitimate runbook deletions. To manage this, create exceptions for known maintenance periods or specific user accounts responsible for these tasks. +- Automated scripts or third-party tools that manage runbooks might trigger deletions as part of their normal operation. Identify these tools and exclude their activity from alerts by filtering based on their service accounts or IP addresses. +- Organizational policy changes or cloud environment restructuring can result in planned runbook deletions. Document these changes and adjust the detection rule to exclude these events by correlating with change management records. +- Test environments often involve frequent creation and deletion of runbooks. Exclude these environments from alerts by using tags or specific resource group identifiers associated with non-production environments. + +### Response and remediation + +- Immediately isolate the affected Azure Automation account to prevent further unauthorized deletions or modifications of runbooks. +- Review the Azure activity logs to identify the user or service principal responsible for the deletion and revoke their access if unauthorized. +- Restore the deleted runbook from backups or version control if available, ensuring that the restored version is free from any malicious modifications. +- Conduct a security review of all remaining runbooks to ensure they have not been tampered with or contain malicious code. +- Implement stricter access controls and auditing for Azure Automation accounts, ensuring that only authorized personnel have the ability to delete runbooks. +- Escalate the incident to the security operations team for further investigation and to determine if additional malicious activities have occurred. +- Enhance monitoring and alerting for similar activities by integrating additional context or indicators from the MITRE ATT&CK framework related to defense evasion tactics. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml b/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml index 7802a541aa0..409247055d7 100644 --- a/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml +++ b/rules/integrations/azure/defense_evasion_azure_blob_permissions_modified.toml @@ -2,7 +2,7 @@ creation_date = "2021/09/22" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Austin Songer"] @@ -21,7 +21,42 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Blob Permissions Modification" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Azure Blob Permissions Modification + +Azure Blob Storage is a service for storing large amounts of unstructured data. It uses Azure RBAC to manage access, ensuring only authorized users can modify or access data. Adversaries may exploit this by altering permissions to gain unauthorized access or disrupt operations. The detection rule monitors specific Azure activity logs for successful permission changes, alerting analysts to potential security breaches or misconfigurations. + +### Possible investigation steps + +- Review the Azure activity logs to identify the user or service principal associated with the permission modification event by examining the relevant fields such as `event.dataset` and `azure.activitylogs.operation_name`. +- Check the `event.outcome` field to confirm the success of the permission modification and gather details on the specific permissions that were altered. +- Investigate the context of the modification by reviewing recent activities of the identified user or service principal to determine if the change aligns with their typical behavior or role. +- Assess the potential impact of the permission change on the affected Azure Blob by evaluating the sensitivity of the data and the new access levels granted. +- Cross-reference the modification event with any recent security alerts or incidents to identify if this change is part of a broader attack pattern or misconfiguration issue. +- Consult with the relevant data owners or administrators to verify if the permission change was authorized and necessary, and if not, take corrective actions to revert the changes. + +### False positive analysis + +- Routine administrative changes to Azure Blob permissions by authorized personnel can trigger alerts. To manage this, create exceptions for specific user accounts or roles that frequently perform legitimate permission modifications. +- Automated scripts or tools used for regular maintenance or deployment might modify permissions as part of their operation. Identify these scripts and exclude their activity from triggering alerts by using specific identifiers or tags associated with the scripts. +- Scheduled updates or policy changes that involve permission modifications can result in false positives. Document these schedules and adjust the monitoring rules to account for these timeframes, reducing unnecessary alerts. +- Integration with third-party services that require permission changes might cause alerts. Review and whitelist these services if they are verified and necessary for operations, ensuring they do not trigger false positives. + +### Response and remediation + +- Immediately revoke any unauthorized permissions identified in the Azure Blob Storage to prevent further unauthorized access or data exposure. +- Conduct a thorough review of the Azure Activity Logs to identify any other suspicious activities or permission changes that may have occurred around the same time. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized changes and any potential data exposure. +- Implement additional monitoring on the affected Azure Blob Storage accounts to detect any further unauthorized access attempts or permission modifications. +- Escalate the incident to the incident response team if there is evidence of a broader security breach or if sensitive data has been compromised. +- Review and update Azure RBAC policies to ensure that only necessary permissions are granted, and consider implementing more granular access controls to minimize the risk of future unauthorized modifications. +- Conduct a post-incident analysis to identify the root cause of the permission change and implement measures to prevent similar incidents in the future, such as enhancing logging and alerting capabilities. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles"] diff --git a/rules/integrations/azure/defense_evasion_azure_diagnostic_settings_deletion.toml b/rules/integrations/azure/defense_evasion_azure_diagnostic_settings_deletion.toml index 3d1aed02314..0b463b5a617 100644 --- a/rules/integrations/azure/defense_evasion_azure_diagnostic_settings_deletion.toml +++ b/rules/integrations/azure/defense_evasion_azure_diagnostic_settings_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/17" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -23,7 +23,43 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Diagnostic Settings Deletion" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Azure Diagnostic Settings Deletion + +Azure Diagnostic Settings are crucial for monitoring and logging platform activities, sending data to various destinations for analysis. Adversaries may delete these settings to hinder detection and analysis of their activities, effectively evading defenses. The detection rule identifies such deletions by monitoring specific Azure activity logs for successful deletion operations, flagging potential defense evasion attempts. + +### Possible investigation steps + +- Review the Azure activity logs to confirm the deletion event by filtering for the operation name "MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/DELETE" and ensuring the event outcome is marked as Success. +- Identify the user or service principal responsible for the deletion by examining the associated user identity or service principal ID in the activity logs. +- Check the timestamp of the deletion event to determine when the diagnostic settings were removed and correlate this with other security events or alerts around the same time. +- Investigate the affected resources by identifying which diagnostic settings were deleted and assess the potential impact on monitoring and logging capabilities. +- Review any recent changes or activities performed by the identified user or service principal to determine if there are other suspicious actions that might indicate malicious intent. +- Assess the current security posture by ensuring that diagnostic settings are reconfigured and that logging and monitoring are restored to maintain visibility into platform activities. + +### False positive analysis + +- Routine maintenance activities by authorized personnel may trigger the rule. Ensure that maintenance schedules are documented and align with the detected events. +- Automated scripts or tools used for managing Azure resources might delete diagnostic settings as part of their operation. Review and whitelist these scripts if they are verified as non-threatening. +- Changes in organizational policy or compliance requirements could lead to legitimate deletions. Confirm with relevant teams if such policy changes are in effect. +- Test environments often undergo frequent configuration changes, including the deletion of diagnostic settings. Consider excluding these environments from the rule or adjusting the rule to account for their unique behavior. +- Ensure that any third-party integrations or services with access to Azure resources are reviewed, as they might inadvertently delete diagnostic settings during their operations. + +### Response and remediation + +- Immediately isolate affected Azure resources to prevent further unauthorized changes or deletions. This may involve temporarily restricting access to the affected subscriptions or resource groups. +- Review the Azure activity logs to identify the source of the deletion request, including the user account and IP address involved. This will help determine if the action was authorized or malicious. +- Recreate the deleted diagnostic settings as soon as possible to restore logging and monitoring capabilities. Ensure that logs are being sent to secure and appropriate destinations. +- Conduct a thorough investigation of the user account involved in the deletion. If the account is compromised, reset credentials, and review permissions to ensure they are appropriate and follow the principle of least privilege. +- Escalate the incident to the security operations team for further analysis and to determine if additional resources or expertise are needed to address the threat. +- Implement additional monitoring and alerting for similar deletion activities to ensure rapid detection and response to future attempts. +- Review and update access controls and policies related to diagnostic settings to prevent unauthorized deletions, ensuring that only trusted and necessary personnel have the ability to modify these settings. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://docs.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-settings"] diff --git a/rules/integrations/azure/defense_evasion_event_hub_deletion.toml b/rules/integrations/azure/defense_evasion_event_hub_deletion.toml index b94eb74a53b..406d260880d 100644 --- a/rules/integrations/azure/defense_evasion_event_hub_deletion.toml +++ b/rules/integrations/azure/defense_evasion_event_hub_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/18" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,43 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Event Hub Deletion" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Azure Event Hub Deletion + +Azure Event Hub is a scalable data streaming platform and event ingestion service, crucial for processing large volumes of data in real-time. Adversaries may target Event Hubs to delete them, aiming to disrupt data flow and evade detection by erasing evidence of their activities. The detection rule monitors Azure activity logs for successful deletion operations, flagging potential defense evasion attempts by identifying unauthorized or suspicious deletions. + +### Possible investigation steps + +- Review the Azure activity logs to confirm the deletion event by checking the operation name "MICROSOFT.EVENTHUB/NAMESPACES/EVENTHUBS/DELETE" and ensure the event outcome is marked as Success. +- Identify the user or service principal responsible for the deletion by examining the associated user identity or service principal ID in the activity logs. +- Investigate the context of the deletion by reviewing recent activities performed by the identified user or service principal to determine if there are any other suspicious actions. +- Check for any recent changes in permissions or roles assigned to the user or service principal to assess if the deletion was authorized or if there was a potential privilege escalation. +- Correlate the deletion event with other security alerts or incidents in the environment to identify if this action is part of a larger attack pattern or campaign. +- Communicate with relevant stakeholders or teams to verify if the deletion was part of a planned operation or maintenance activity. + +### False positive analysis + +- Routine maintenance or updates by authorized personnel can trigger deletion logs. Verify if the deletion aligns with scheduled maintenance activities and exclude these operations from alerts. +- Automated scripts or tools used for managing Azure resources might delete Event Hubs as part of their normal operation. Identify these scripts and whitelist their activity to prevent false positives. +- Test environments often involve frequent creation and deletion of resources, including Event Hubs. Exclude known test environments from monitoring to reduce noise. +- Changes in organizational policies or restructuring might lead to legitimate deletions. Ensure that such policy-driven deletions are documented and excluded from alerts. +- Misconfigured automation or deployment processes can inadvertently delete Event Hubs. Regularly review and update configurations to ensure they align with intended operations and exclude these from alerts if verified as non-threatening. + +### Response and remediation + +- Immediately isolate the affected Azure Event Hub namespace to prevent further unauthorized deletions or modifications. This can be done by restricting access through Azure Role-Based Access Control (RBAC) and network security groups. +- Review and revoke any suspicious or unauthorized access permissions associated with the deleted Event Hub. Ensure that only authorized personnel have the necessary permissions to manage Event Hubs. +- Restore the deleted Event Hub from backups if available, or reconfigure it to resume normal operations. Verify the integrity and completeness of the restored data. +- Conduct a thorough audit of recent Azure activity logs to identify any other unauthorized actions or anomalies that may indicate further compromise. +- Escalate the incident to the security operations team for a detailed investigation into the root cause and to assess the potential impact on other Azure resources. +- Implement additional monitoring and alerting for Azure Event Hub operations to detect and respond to similar unauthorized activities promptly. +- Review and update security policies and access controls for Azure resources to prevent recurrence, ensuring adherence to the principle of least privilege. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/azure/defense_evasion_firewall_policy_deletion.toml b/rules/integrations/azure/defense_evasion_firewall_policy_deletion.toml index f0c701c2cb6..450856efaa3 100644 --- a/rules/integrations/azure/defense_evasion_firewall_policy_deletion.toml +++ b/rules/integrations/azure/defense_evasion_firewall_policy_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/18" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,43 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Firewall Policy Deletion" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Azure Firewall Policy Deletion + +Azure Firewall policies are crucial for managing and enforcing network security rules across Azure environments. Adversaries may target these policies to disable security measures, facilitating unauthorized access or data exfiltration. The detection rule monitors Azure activity logs for successful deletion operations of firewall policies, signaling potential defense evasion attempts by identifying specific operation names and outcomes. + +### Possible investigation steps + +- Review the Azure activity logs to confirm the deletion event by filtering for the operation name "MICROSOFT.NETWORK/FIREWALLPOLICIES/DELETE" and ensuring the event outcome is "Success". +- Identify the user or service principal responsible for the deletion by examining the 'caller' field in the activity logs. +- Check the timestamp of the deletion event to determine when the policy was deleted and correlate it with other security events or alerts around the same time. +- Investigate the context of the deletion by reviewing any related activities performed by the same user or service principal, such as modifications to other security settings or unusual login patterns. +- Assess the impact of the deletion by identifying which resources or networks were protected by the deleted firewall policy and evaluating the potential exposure or risk introduced by its removal. +- Contact the responsible user or team to verify if the deletion was authorized and part of a planned change or if it was unexpected and potentially malicious. + +### False positive analysis + +- Routine maintenance or updates by authorized personnel can trigger the deletion event. Ensure that such activities are logged and verified by cross-referencing with change management records. +- Automated scripts or tools used for infrastructure management might delete and recreate firewall policies as part of their operation. Identify these scripts and exclude their activity from alerts by using specific identifiers or tags. +- Test environments often undergo frequent changes, including policy deletions. Consider excluding activity from known test environments by filtering based on resource group or subscription IDs. +- Scheduled policy updates or rotations might involve temporary deletions. Document these schedules and adjust monitoring rules to account for these expected changes. +- Ensure that any third-party integrations or services with permissions to modify firewall policies are accounted for, and their actions are reviewed and whitelisted if necessary. + +### Response and remediation + +- Immediately isolate the affected Azure resources to prevent further unauthorized access or data exfiltration. This can be done by applying restrictive network security group (NSG) rules or using Azure Security Center to quarantine resources. +- Review Azure activity logs to identify the user or service principal responsible for the deletion. Verify if the action was authorized and investigate any suspicious accounts or credentials. +- Restore the deleted firewall policy from backups or recreate it using predefined templates to ensure that network security rules are reinstated promptly. +- Implement conditional access policies to enforce multi-factor authentication (MFA) for all users with permissions to modify or delete firewall policies, reducing the risk of unauthorized changes. +- Escalate the incident to the security operations team for further investigation and to determine if additional resources or systems have been compromised. +- Conduct a post-incident review to identify gaps in security controls and update incident response plans to address similar threats in the future. +- Enhance monitoring by configuring alerts for any future attempts to delete or modify critical security policies, ensuring rapid detection and response to potential threats. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://docs.microsoft.com/en-us/azure/firewall-manager/policy-overview"] diff --git a/rules/integrations/azure/defense_evasion_frontdoor_firewall_policy_deletion.toml b/rules/integrations/azure/defense_evasion_frontdoor_firewall_policy_deletion.toml index acea8b019f8..7b208a2f0e0 100644 --- a/rules/integrations/azure/defense_evasion_frontdoor_firewall_policy_deletion.toml +++ b/rules/integrations/azure/defense_evasion_frontdoor_firewall_policy_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2021/08/01" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Austin Songer"] @@ -24,7 +24,42 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Frontdoor Web Application Firewall (WAF) Policy Deleted" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Azure Frontdoor Web Application Firewall (WAF) Policy Deleted + +Azure Frontdoor WAF policies are crucial for protecting web applications by filtering and monitoring HTTP requests to block malicious traffic. Adversaries may delete these policies to bypass security measures, facilitating unauthorized access or data exfiltration. The detection rule identifies such deletions by monitoring Azure activity logs for specific delete operations, signaling potential defense evasion attempts. + +### Possible investigation steps + +- Review the Azure activity logs to confirm the deletion event by filtering for the operation name "MICROSOFT.NETWORK/FRONTDOORWEBAPPLICATIONFIREWALLPOLICIES/DELETE" and ensure the event outcome is marked as Success. +- Identify the user or service principal responsible for the deletion by examining the associated user identity information in the activity logs. +- Check the timestamp of the deletion event to determine if it coincides with any other suspicious activities or alerts in the environment. +- Investigate the context of the deletion by reviewing any recent changes or incidents involving the affected Azure Frontdoor instance or related resources. +- Assess the impact of the deletion by identifying which web applications were protected by the deleted WAF policy and evaluating their current exposure to threats. +- Review access logs and network traffic for the affected web applications to detect any unusual or unauthorized access attempts following the policy deletion. + +### False positive analysis + +- Routine maintenance or updates by authorized personnel may lead to the deletion of WAF policies. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks. +- Automated scripts or tools used for infrastructure management might delete and recreate WAF policies as part of their normal operation. Identify these scripts and exclude their activity from triggering alerts. +- Changes in organizational policy or architecture could necessitate the removal of certain WAF policies. Document these changes and adjust the detection rule to account for them by excluding specific policy names or identifiers. +- Test environments may frequently add and remove WAF policies as part of development cycles. Consider excluding activity from test environments by filtering based on resource group names or tags associated with non-production environments. + +### Response and remediation + +- Immediately isolate the affected Azure Frontdoor instance to prevent further unauthorized access or data exfiltration. +- Review Azure activity logs to identify the user or service principal responsible for the deletion and assess their access permissions. +- Recreate the deleted WAF policy using the latest backup or configuration template to restore security controls. +- Implement conditional access policies to restrict access to Azure management operations, ensuring only authorized personnel can modify WAF policies. +- Notify the security operations team and relevant stakeholders about the incident for further investigation and monitoring. +- Conduct a post-incident review to identify gaps in security controls and update incident response plans accordingly. +- Enhance monitoring by setting up alerts for any future deletions of critical security policies to ensure rapid detection and response. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/azure/defense_evasion_kubernetes_events_deleted.toml b/rules/integrations/azure/defense_evasion_kubernetes_events_deleted.toml index 12782cf9cb0..a355e7da7a1 100644 --- a/rules/integrations/azure/defense_evasion_kubernetes_events_deleted.toml +++ b/rules/integrations/azure/defense_evasion_kubernetes_events_deleted.toml @@ -2,7 +2,7 @@ creation_date = "2021/06/24" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Austin Songer"] @@ -23,7 +23,43 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Kubernetes Events Deleted" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Azure Kubernetes Events Deleted + +Azure Kubernetes Service (AKS) manages containerized applications using Kubernetes, which logs events like state changes. These logs are crucial for monitoring and troubleshooting. Adversaries may delete these logs to hide their tracks, impairing defenses. The detection rule identifies such deletions by monitoring specific Azure activity logs, flagging successful deletion operations to alert security teams of potential evasion tactics. + +### Possible investigation steps + +- Review the Azure activity logs to confirm the deletion event by checking for the operation name "MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/EVENTS.K8S.IO/EVENTS/DELETE" and ensure the event outcome is marked as "Success". +- Identify the user or service principal responsible for the deletion by examining the associated identity information in the activity logs. +- Investigate the timeline of events leading up to and following the deletion to identify any suspicious activities or patterns, such as unauthorized access attempts or configuration changes. +- Check for any other related alerts or anomalies in the Azure environment that might indicate a broader attack or compromise. +- Assess the impact of the deleted events by determining which Kubernetes resources or operations were affected and if any critical logs were lost. +- Review access controls and permissions for the user or service principal involved to ensure they align with the principle of least privilege and adjust if necessary. +- Consider implementing additional monitoring or alerting for similar deletion activities to enhance detection and response capabilities. + +### False positive analysis + +- Routine maintenance activities by authorized personnel may trigger deletion events. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks. +- Automated scripts or tools used for log rotation or cleanup might delete events as part of their normal operation. Identify these scripts and exclude their activity from triggering alerts by whitelisting their associated service accounts or IP addresses. +- Misconfigured applications or services that inadvertently delete logs can cause false positives. Review application configurations and adjust them to prevent unnecessary deletions, and exclude these applications from alerts if they are verified as non-threatening. +- Test environments often generate log deletions during setup or teardown processes. Exclude these environments from monitoring or create specific rules that differentiate between production and test environments to avoid unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected Azure Kubernetes cluster to prevent further unauthorized access or tampering with logs. +- Conduct a thorough review of recent activity logs and access permissions for the affected cluster to identify any unauthorized access or privilege escalation. +- Restore deleted Kubernetes events from backups or snapshots if available, to ensure continuity in monitoring and auditing. +- Implement stricter access controls and audit logging for Kubernetes event deletion operations to prevent unauthorized deletions in the future. +- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation. +- Escalate the incident to the incident response team if there is evidence of broader compromise or if the deletion is part of a larger attack campaign. +- Review and update incident response plans to incorporate lessons learned from this event, ensuring quicker detection and response to similar threats in the future. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/azure/defense_evasion_network_watcher_deletion.toml b/rules/integrations/azure/defense_evasion_network_watcher_deletion.toml index 4bf9be6b02e..db35de4128f 100644 --- a/rules/integrations/azure/defense_evasion_network_watcher_deletion.toml +++ b/rules/integrations/azure/defense_evasion_network_watcher_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/31" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -23,7 +23,41 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Network Watcher Deletion" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Azure Network Watcher Deletion + +Azure Network Watcher is a vital tool for monitoring and diagnosing network issues within Azure environments. It provides insights and logging capabilities crucial for maintaining network security. Adversaries may delete Network Watchers to disable these monitoring functions, thereby evading detection. The detection rule identifies such deletions by monitoring Azure activity logs for specific delete operations, flagging successful attempts as potential security threats. + +### Possible investigation steps + +- Review the Azure activity logs to confirm the deletion event by checking for the operation name "MICROSOFT.NETWORK/NETWORKWATCHERS/DELETE" and ensuring the event outcome is marked as "Success" or "success". +- Identify the user or service principal responsible for the deletion by examining the associated user identity or service principal ID in the activity logs. +- Investigate the timeline of events leading up to the deletion by reviewing related activity logs for any unusual or unauthorized access patterns or changes in permissions. +- Assess the impact of the deletion by determining which resources were being monitored by the deleted Network Watcher and evaluating the potential security implications. +- Check for any other suspicious activities or alerts in the Azure environment that may indicate a broader attack or compromise, focusing on defense evasion tactics. + +### False positive analysis + +- Routine maintenance activities by authorized personnel may trigger the deletion alert. Verify if the deletion aligns with scheduled maintenance and consider excluding these operations from alerts. +- Automated scripts or tools used for infrastructure management might delete Network Watchers as part of their normal operation. Identify these scripts and whitelist their activity to prevent false positives. +- Changes in network architecture or resource reallocation can lead to legitimate deletions. Review change management logs to confirm if the deletion was planned and adjust the detection rule to exclude these scenarios. +- Test environments often undergo frequent changes, including the deletion of Network Watchers. If these environments are known to generate false positives, consider creating exceptions for specific resource groups or subscriptions associated with testing. + +### Response and remediation + +- Immediately isolate the affected Azure resources to prevent further unauthorized actions. This can be done by restricting network access or applying stricter security group rules. +- Review Azure activity logs to identify the user or service principal responsible for the deletion. Verify if the action was authorized and investigate any suspicious accounts. +- Restore the deleted Network Watcher by redeploying it in the affected regions to resume monitoring and logging capabilities. +- Conduct a security review of the affected Azure environment to identify any other potential misconfigurations or unauthorized changes. +- Implement stricter access controls and auditing for Azure resources, ensuring that only authorized personnel have the ability to delete critical monitoring tools like Network Watchers. +- Escalate the incident to the security operations team for further investigation and to determine if additional security measures are necessary. +- Enhance detection capabilities by ensuring that alerts for similar deletion activities are configured to notify the security team immediately. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://docs.microsoft.com/en-us/azure/network-watcher/network-watcher-monitoring-overview"] diff --git a/rules/integrations/azure/defense_evasion_suppression_rule_created.toml b/rules/integrations/azure/defense_evasion_suppression_rule_created.toml index 5adfd45abdd..cc2c5eb4fa9 100644 --- a/rules/integrations/azure/defense_evasion_suppression_rule_created.toml +++ b/rules/integrations/azure/defense_evasion_suppression_rule_created.toml @@ -2,7 +2,7 @@ creation_date = "2021/08/27" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Austin Songer"] @@ -23,7 +23,43 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Alert Suppression Rule Created or Modified" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Azure Alert Suppression Rule Created or Modified + +Azure Alert Suppression Rules are used to manage alert noise by filtering out known false positives. However, adversaries can exploit these rules to hide malicious activities by suppressing legitimate security alerts. The detection rule monitors Azure activity logs for successful operations related to suppression rule changes, helping identify potential misuse that could lead to defense evasion and reduced security visibility. + +### Possible investigation steps + +- Review the Azure activity logs to identify the specific suppression rule that was created or modified by filtering logs with the operation name "MICROSOFT.SECURITY/ALERTSSUPPRESSIONRULES/WRITE" and ensuring the event outcome is "success". +- Determine the identity of the user or service principal that performed the operation by examining the associated user or service account details in the activity logs. +- Investigate the context and justification for the creation or modification of the suppression rule by checking any related change management records or communications. +- Assess the impact of the suppression rule on security visibility by identifying which alerts are being suppressed and evaluating whether these alerts are critical for detecting potential threats. +- Cross-reference the suppression rule changes with recent security incidents or alerts to determine if there is any correlation or if the rule could have been used to hide malicious activity. +- Verify the legitimacy of the suppression rule by consulting with relevant stakeholders, such as security operations or cloud management teams, to confirm if the change was authorized and aligns with security policies. + +### False positive analysis + +- Routine maintenance activities by IT staff may trigger alerts when legitimate suppression rules are created or modified. To manage this, establish a baseline of expected changes and create exceptions for known maintenance periods or personnel. +- Automated processes or scripts that regularly update suppression rules for operational efficiency can generate false positives. Identify these processes and exclude their activity from alerting by using specific identifiers or tags associated with the automation. +- Changes made by trusted third-party security services that integrate with Azure might be flagged. Verify the legitimacy of these services and whitelist their operations to prevent unnecessary alerts. +- Frequent updates to suppression rules due to evolving security policies can lead to false positives. Document these policy changes and adjust the alerting criteria to accommodate expected modifications. +- Temporary suppression rules created during incident response to manage alert noise can be mistaken for malicious activity. Ensure these rules are documented and time-bound, and exclude them from alerting during the response period. + +### Response and remediation + +- Immediately review the Azure activity logs to confirm the creation or modification of the suppression rule and identify the user or service account responsible for the change. +- Temporarily disable the suspicious suppression rule to restore visibility into potential security alerts that may have been suppressed. +- Conduct a thorough investigation of recent alerts that were suppressed by the rule to determine if any malicious activities were overlooked. +- If malicious activity is confirmed, initiate incident response procedures to contain and remediate the threat, including isolating affected resources and accounts. +- Escalate the incident to the security operations team for further analysis and to assess the potential impact on the organization's security posture. +- Implement additional monitoring and alerting for changes to suppression rules to ensure any future modifications are promptly detected and reviewed. +- Review and update access controls and permissions for creating or modifying suppression rules to ensure only authorized personnel can make such changes. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/azure/discovery_blob_container_access_mod.toml b/rules/integrations/azure/discovery_blob_container_access_mod.toml index 61d9adf1f1c..aae1449665d 100644 --- a/rules/integrations/azure/discovery_blob_container_access_mod.toml +++ b/rules/integrations/azure/discovery_blob_container_access_mod.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/20" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,42 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Blob Container Access Level Modification" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Azure Blob Container Access Level Modification + +Azure Blob Storage is a service for storing large amounts of unstructured data, where access levels can be configured to control data visibility. Adversaries may exploit misconfigured access levels to gain unauthorized access to sensitive data. The detection rule monitors changes in container access settings, focusing on successful modifications, to identify potential security risks associated with unauthorized access level changes. + +### Possible investigation steps + +- Review the Azure activity logs to identify the specific storage account and container where the access level modification occurred, using the operation name "MICROSOFT.STORAGE/STORAGEACCOUNTS/BLOBSERVICES/CONTAINERS/WRITE". +- Verify the identity of the user or service principal that performed the modification by examining the associated user information in the activity logs. +- Check the timestamp of the modification to determine if it aligns with any known maintenance windows or authorized changes. +- Investigate the previous access level settings of the container to assess the potential impact of the change, especially if it involved enabling anonymous public read access. +- Correlate the event with any other recent suspicious activities or alerts in the Azure environment to identify potential patterns or coordinated actions. +- Contact the owner of the storage account or relevant stakeholders to confirm whether the change was authorized and aligns with organizational policies. + +### False positive analysis + +- Routine administrative changes to container access levels by authorized personnel can trigger alerts. To manage this, create exceptions for specific user accounts or roles that regularly perform these tasks. +- Automated scripts or tools used for managing storage configurations may cause false positives. Identify and exclude these scripts or tools from monitoring if they are verified as non-threatening. +- Scheduled updates or maintenance activities that involve access level modifications can be mistaken for unauthorized changes. Document and schedule these activities to align with monitoring rules, allowing for temporary exclusions during these periods. +- Changes made by trusted third-party services integrated with Azure Blob Storage might be flagged. Verify these services and exclude their operations from triggering alerts if they are deemed secure and necessary for business operations. + +### Response and remediation + +- Immediately revoke public read access to the affected Azure Blob container to prevent unauthorized data exposure. +- Review the access logs to identify any unauthorized access or data exfiltration attempts during the period when the access level was modified. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized access level change and any potential data exposure. +- Conduct a thorough audit of all Azure Blob containers to ensure that access levels are configured according to the organization's security policies and that no other containers are misconfigured. +- Implement additional monitoring and alerting for changes to access levels on Azure Blob containers to ensure rapid detection of any future unauthorized modifications. +- If sensitive data was exposed, initiate a data breach response plan, including notifying affected parties and regulatory bodies as required by law. +- Review and update access management policies and procedures to prevent recurrence, ensuring that only authorized personnel can modify container access levels. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://docs.microsoft.com/en-us/azure/storage/blobs/anonymous-read-access-prevent"] diff --git a/rules/integrations/azure/execution_command_virtual_machine.toml b/rules/integrations/azure/execution_command_virtual_machine.toml index 6913c697a2e..b8126b62705 100644 --- a/rules/integrations/azure/execution_command_virtual_machine.toml +++ b/rules/integrations/azure/execution_command_virtual_machine.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/17" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -25,7 +25,43 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Command Execution on Virtual Machine" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Azure Command Execution on Virtual Machine + +Azure Virtual Machines (VMs) allow users to run applications and services in the cloud. While roles like Virtual Machine Contributor can manage VMs, they typically can't access them directly. However, commands can be executed remotely via PowerShell, running as System. Adversaries may exploit this to execute unauthorized commands. The detection rule monitors Azure activity logs for command execution events, flagging successful operations to identify potential misuse. + +### Possible investigation steps + +- Review the Azure activity logs to identify the specific user or service principal that initiated the command execution event, focusing on the operation_name "MICROSOFT.COMPUTE/VIRTUALMACHINES/RUNCOMMAND/ACTION". +- Check the event.outcome field to confirm the success of the command execution and gather details about the command executed. +- Investigate the role and permissions of the user or service principal involved to determine if they have legitimate reasons to execute commands on the VM. +- Analyze the context of the command execution, including the time and frequency of the events, to identify any unusual patterns or anomalies. +- Correlate the command execution event with other logs or alerts from the same time period to identify any related suspicious activities or potential lateral movement. +- If unauthorized access is suspected, review the VM's security settings and access controls to identify and mitigate any vulnerabilities or misconfigurations. + +### False positive analysis + +- Routine maintenance tasks executed by IT administrators can trigger the rule. To manage this, create exceptions for known maintenance scripts or scheduled tasks that are regularly executed. +- Automated deployment processes that use PowerShell scripts to configure or update VMs may be flagged. Identify these processes and exclude them from the rule to prevent unnecessary alerts. +- Security tools or monitoring solutions that perform regular checks on VMs might execute commands that are benign. Whitelist these tools by identifying their specific command patterns and excluding them from detection. +- Development and testing environments often involve frequent command executions for testing purposes. Consider excluding these environments from the rule or setting up a separate monitoring policy with adjusted thresholds. +- Ensure that any exclusion or exception is documented and reviewed periodically to maintain security posture and adapt to any changes in the environment or processes. + +### Response and remediation + +- Immediately isolate the affected virtual machine from the network to prevent further unauthorized command execution and potential lateral movement. +- Review the Azure activity logs to identify the source of the command execution and determine if it was authorized or part of a larger attack pattern. +- Revoke any unnecessary permissions from users or roles that have the ability to execute commands on virtual machines, focusing on those with Virtual Machine Contributor roles. +- Conduct a thorough investigation of the executed commands to assess any changes or impacts on the system, and restore the VM to a known good state if necessary. +- Implement additional monitoring and alerting for similar command execution activities, ensuring that any future unauthorized attempts are detected promptly. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems or data may have been compromised. +- Review and update access control policies and role assignments to ensure that only necessary permissions are granted, reducing the risk of similar incidents in the future. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/azure/impact_azure_service_principal_credentials_added.toml b/rules/integrations/azure/impact_azure_service_principal_credentials_added.toml index d66662ddb29..2080ff09347 100644 --- a/rules/integrations/azure/impact_azure_service_principal_credentials_added.toml +++ b/rules/integrations/azure/impact_azure_service_principal_credentials_added.toml @@ -2,7 +2,7 @@ creation_date = "2021/05/05" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic", "Austin Songer"] @@ -25,7 +25,43 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "Azure Service Principal Credentials Added" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Service Principal Credentials Added + +Azure Service Principals are identities used by applications or services to access Azure resources securely. They are typically granted specific permissions, and credentials are rarely updated. Adversaries may exploit this by adding unauthorized credentials, gaining access to sensitive data without triggering MFA. The detection rule monitors audit logs for successful additions of service principal credentials, flagging potential unauthorized access attempts. + +### Possible investigation steps + +- Review the Azure audit logs to identify the specific service principal for which credentials were added, focusing on entries with the operation name "Add service principal credentials" and a successful outcome. +- Determine the identity of the user or application that performed the credential addition by examining the associated user or application ID in the audit log entry. +- Investigate the permissions and roles assigned to the affected service principal to assess the potential impact of unauthorized access. +- Check for any recent changes or unusual activity associated with the service principal, such as modifications to permissions or unexpected resource access patterns. +- Correlate the event with other security logs and alerts to identify any related suspicious activities or potential indicators of compromise within the environment. +- Contact the owner or responsible team for the service principal to verify if the credential addition was authorized and legitimate. + +### False positive analysis + +- Routine credential updates for service principals used in automated deployment processes can trigger alerts. To manage this, identify and document these processes, then create exceptions for known service principals involved in regular updates. +- Credential additions by authorized IT personnel during scheduled maintenance or upgrades may be flagged. Implement a change management process to log and verify these activities, allowing you to exclude them from triggering alerts. +- Integration of new third-party applications that require service principal credentials might cause false positives. Maintain an inventory of approved third-party integrations and exclude their credential additions from monitoring. +- Development and testing environments often see frequent credential changes. Segregate these environments from production in your monitoring setup to reduce unnecessary alerts. +- Credential rotations as part of security best practices can be mistaken for unauthorized additions. Establish a schedule for credential rotations and configure your monitoring to recognize these as legitimate activities. + +### Response and remediation + +- Immediately revoke the newly added credentials for the affected Azure Service Principal to prevent unauthorized access. +- Conduct a thorough review of the audit logs to identify any unauthorized activities performed using the compromised Service Principal credentials. +- Reset and update the credentials for the affected Service Principal, ensuring they are stored securely and access is restricted to authorized personnel only. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized credential addition and any potential data access. +- Implement additional monitoring on the affected Service Principal and related resources to detect any further suspicious activities. +- Review and tighten the permissions granted to the Service Principal to ensure they follow the principle of least privilege. +- Consider enabling conditional access policies or additional security measures, such as IP whitelisting, to enhance protection against similar threats in the future. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://www.fireeye.com/content/dam/collateral/en/wp-m-unc2452.pdf"] diff --git a/rules/integrations/azure/impact_kubernetes_pod_deleted.toml b/rules/integrations/azure/impact_kubernetes_pod_deleted.toml index 791f2c8c25a..2fc1b2879ed 100644 --- a/rules/integrations/azure/impact_kubernetes_pod_deleted.toml +++ b/rules/integrations/azure/impact_kubernetes_pod_deleted.toml @@ -2,7 +2,7 @@ creation_date = "2021/06/24" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Austin Songer"] @@ -22,7 +22,42 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Kubernetes Pods Deleted" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Azure Kubernetes Pods Deleted + +Azure Kubernetes Service (AKS) enables the deployment, management, and scaling of containerized applications using Kubernetes. Pods, the smallest deployable units in Kubernetes, can be targeted by adversaries to disrupt services or evade detection. Malicious actors might delete pods to cause downtime or hide their activities. The detection rule monitors Azure activity logs for successful pod deletion operations, alerting security teams to potential unauthorized actions that could impact the environment's stability and security. + +### Possible investigation steps + +- Review the Azure activity logs to confirm the details of the pod deletion event, focusing on the operation name "MICROSOFT.KUBERNETES/CONNECTEDCLUSTERS/PODS/DELETE" and ensuring the event outcome is marked as "Success". +- Identify the user or service principal responsible for the deletion by examining the associated identity information in the activity logs. +- Check the timeline of events leading up to the pod deletion to identify any unusual or unauthorized access patterns or activities. +- Investigate the specific Kubernetes cluster and namespace where the pod deletion occurred to assess the potential impact on services and applications. +- Cross-reference the deleted pod's details with recent changes or deployments in the environment to determine if the deletion was part of a legitimate maintenance or deployment activity. +- Consult with the relevant application or infrastructure teams to verify if the pod deletion was authorized and necessary, or if it indicates a potential security incident. + +### False positive analysis + +- Routine maintenance or updates by authorized personnel can lead to legitimate pod deletions. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks. +- Automated scaling operations might delete pods as part of normal scaling activities. Identify and exclude these operations by correlating with scaling events or using tags that indicate automated processes. +- Development and testing environments often experience frequent pod deletions as part of normal operations. Consider excluding these environments from alerts by using environment-specific identifiers or tags. +- Scheduled job completions may result in pod deletions once tasks are finished. Implement rules to recognize and exclude these scheduled operations by matching them with known job schedules or identifiers. + +### Response and remediation + +- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized actions. This can be done by restricting network access or applying stricter security group rules temporarily. +- Review the Azure activity logs to identify the source of the deletion request, including the user or service principal involved, and verify if the action was authorized. +- Recreate the deleted pods using the latest known good configuration to restore services and minimize downtime. +- Conduct a thorough security assessment of the affected cluster to identify any additional unauthorized changes or indicators of compromise. +- Implement stricter access controls and role-based access management to ensure only authorized personnel can delete pods in the future. +- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or resources are affected. +- Enhance monitoring and alerting for similar activities by integrating with a Security Information and Event Management (SIEM) system to detect and respond to unauthorized pod deletions promptly. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/azure/impact_resource_group_deletion.toml b/rules/integrations/azure/impact_resource_group_deletion.toml index 6ccdd075ad5..07c2a1a10df 100644 --- a/rules/integrations/azure/impact_resource_group_deletion.toml +++ b/rules/integrations/azure/impact_resource_group_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/17" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -24,7 +24,43 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Resource Group Deletion" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Azure Resource Group Deletion + +Azure Resource Groups are containers that hold related resources for an Azure solution, enabling efficient management and organization. Adversaries may exploit this by deleting entire groups to disrupt services or erase data, causing significant impact. The detection rule monitors Azure activity logs for successful deletion operations, flagging potential malicious actions for further investigation. + +### Possible investigation steps + +- Review the Azure activity logs to confirm the deletion event by checking for the operation name "MICROSOFT.RESOURCES/SUBSCRIPTIONS/RESOURCEGROUPS/DELETE" and ensure the event outcome is marked as "Success" or "success". +- Identify the user or service principal responsible for the deletion by examining the associated user identity or service principal ID in the activity logs. +- Check the timestamp of the deletion event to determine when the resource group was deleted and correlate this with any other suspicious activities around the same time. +- Investigate the resources contained within the deleted resource group to assess the potential impact, including any critical services or data that may have been affected. +- Review any recent changes in permissions or roles assigned to the user or service principal involved in the deletion to identify potential privilege escalation or misuse. +- Examine any related alerts or logs for unusual activities or patterns that might indicate a broader attack or compromise within the Azure environment. + +### False positive analysis + +- Routine maintenance activities by IT teams may trigger alerts when resource groups are intentionally deleted as part of regular updates or infrastructure changes. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks. +- Automated scripts or deployment tools that manage resource lifecycles might delete resource groups as part of their normal operation. Identify these scripts and exclude their activity from alerts by filtering based on the service principal or automation account used. +- Testing environments often involve frequent creation and deletion of resource groups. Exclude these environments from alerts by tagging them appropriately and configuring the detection rule to ignore actions on tagged resources. +- Mergers or organizational restructuring can lead to legitimate resource group deletions. Coordinate with relevant departments to anticipate these changes and temporarily adjust monitoring rules to prevent false positives. +- Ensure that any third-party services or consultants with access to your Azure environment are accounted for, as their activities might include resource group deletions. Establish clear communication channels to verify their actions and adjust monitoring rules accordingly. + +### Response and remediation + +- Immediately isolate the affected Azure subscription to prevent further unauthorized actions. This can be done by temporarily disabling access or applying strict access controls. +- Review and revoke any suspicious or unauthorized access permissions associated with the affected resource group to prevent further exploitation. +- Restore the deleted resources from backups if available. Ensure that backup and recovery processes are validated and functioning correctly. +- Conduct a thorough audit of recent Azure activity logs to identify any other potentially malicious actions or compromised accounts. +- Escalate the incident to the security operations team for a detailed investigation and to determine if there are broader implications or related threats. +- Implement additional monitoring and alerting for similar deletion activities across all Azure subscriptions to enhance early detection of such threats. +- Review and strengthen access management policies, ensuring that only authorized personnel have the necessary permissions to delete resource groups. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/azure/impact_virtual_network_device_modified.toml b/rules/integrations/azure/impact_virtual_network_device_modified.toml index f1e9e003e68..7c1c87f45e2 100644 --- a/rules/integrations/azure/impact_virtual_network_device_modified.toml +++ b/rules/integrations/azure/impact_virtual_network_device_modified.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/12" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Austin Songer"] @@ -23,7 +23,43 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Virtual Network Device Modified or Deleted" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Virtual Network Device Modified or Deleted + +Azure virtual network devices, such as network interfaces, virtual hubs, and routers, are crucial for managing network traffic and connectivity in cloud environments. Adversaries may target these devices to disrupt services or reroute traffic for malicious purposes. The detection rule monitors specific Azure activity logs for operations indicating modifications or deletions of these devices, helping identify potential unauthorized changes that could signify an attack. + +### Possible investigation steps + +- Review the Azure activity logs to identify the specific operation that triggered the alert, focusing on the operation_name field to determine whether it was a WRITE or DELETE action. +- Check the event.outcome field to confirm the success of the operation, ensuring that the modification or deletion was completed. +- Investigate the user or service principal responsible for the action by examining the identity information in the activity logs to determine if the change was authorized. +- Assess the impact of the modification or deletion by identifying the affected virtual network device, such as a network interface, virtual hub, or virtual router, and evaluate its role in the network architecture. +- Cross-reference the time of the alert with any other suspicious activities or alerts in the environment to identify potential patterns or coordinated actions. +- Consult with relevant stakeholders or system owners to verify if the change was planned or expected, and gather additional context if necessary. + +### False positive analysis + +- Routine maintenance activities by network administrators can trigger alerts when they modify or delete virtual network devices. To manage this, create exceptions for known maintenance windows or specific administrator accounts. +- Automated scripts or tools used for network management might perform frequent updates or deletions, leading to false positives. Identify these scripts and exclude their operations from triggering alerts by using specific identifiers or tags. +- Changes made by authorized third-party services or integrations that manage network configurations can also result in false positives. Review and whitelist these services to prevent unnecessary alerts. +- Regular updates or deployments in a development or testing environment may cause alerts. Consider excluding these environments from monitoring or adjusting the rule to focus on production environments only. +- Temporary changes for troubleshooting or testing purposes might be flagged. Document these activities and use temporary exceptions to avoid false positives during these periods. + +### Response and remediation + +- Immediately isolate the affected virtual network device to prevent further unauthorized access or changes. This can be done by disabling the network interface or applying restrictive network security group rules. +- Review the Azure activity logs to identify the source of the modification or deletion. Correlate this with user activity logs to determine if the action was performed by an authorized user or a compromised account. +- If a compromised account is suspected, reset the credentials for the affected account and any other accounts that may have been exposed. Implement multi-factor authentication if not already in place. +- Restore the modified or deleted virtual network device from a known good backup or configuration snapshot to ensure continuity of services. +- Conduct a thorough security assessment of the affected Azure environment to identify any additional unauthorized changes or indicators of compromise. +- Escalate the incident to the security operations team for further investigation and to determine if additional containment measures are necessary. +- Implement enhanced monitoring and alerting for similar activities in the future, ensuring that any modifications or deletions of virtual network devices are promptly detected and reviewed. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations"] diff --git a/rules/integrations/azure/initial_access_external_guest_user_invite.toml b/rules/integrations/azure/initial_access_external_guest_user_invite.toml index ec46d414b1e..cc5902ae290 100644 --- a/rules/integrations/azure/initial_access_external_guest_user_invite.toml +++ b/rules/integrations/azure/initial_access_external_guest_user_invite.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/31" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -24,7 +24,43 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure External Guest User Invitation" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Azure External Guest User Invitation + +Azure Active Directory (AD) facilitates collaboration by allowing external users to be invited as guest users, enhancing flexibility in cloud environments. However, adversaries may exploit this feature to gain unauthorized access, posing security risks. The detection rule monitors audit logs for successful external user invitations, flagging potential misuse by identifying unusual or unnecessary guest account creations. + +### Possible investigation steps + +- Review the audit logs to confirm the details of the invitation event, focusing on the operation name "Invite external user" and ensuring the event outcome is marked as Success. +- Identify the inviter by examining the properties of the audit log entry, such as the initiator's user ID or email, to determine if the invitation was expected or authorized. +- Check the display name and other attributes of the invited guest user to assess if they align with known business needs or if they appear suspicious or unnecessary. +- Investigate the inviter's recent activity in Azure AD to identify any unusual patterns or deviations from their typical behavior that might indicate compromised credentials. +- Consult with relevant business units or stakeholders to verify if there was a legitimate business requirement for the guest user invitation and if it aligns with current projects or collaborations. +- Review the access permissions granted to the guest user to ensure they are limited to the minimum necessary for their role and do not expose sensitive resources. + +### False positive analysis + +- Invitations for legitimate business partners or vendors may trigger alerts. Regularly review and whitelist known partners to prevent unnecessary alerts. +- Internal users with dual roles or responsibilities that require external access might be flagged. Maintain a list of such users and update it periodically to exclude them from alerts. +- Automated systems or applications that require guest access for integration purposes can cause false positives. Identify these systems and configure exceptions in the monitoring rules. +- Temporary projects or collaborations often involve inviting external users. Document these projects and set expiration dates for guest access to minimize false positives. +- Frequent invitations from specific departments, such as HR or Marketing, for events or collaborations can be common. Establish a process to verify and approve these invitations to reduce false alerts. + +### Response and remediation + +- Immediately disable the guest user account identified in the alert to prevent any unauthorized access or activities. +- Review the audit logs to determine the source and context of the invitation, identifying the user or system that initiated the guest invitation. +- Notify the security team and relevant stakeholders about the unauthorized guest invitation for further investigation and potential escalation. +- Conduct a security assessment of the affected Azure AD environment to identify any other unauthorized guest accounts or suspicious activities. +- Implement conditional access policies to restrict guest user invitations to authorized personnel only, reducing the risk of future unauthorized invitations. +- Enhance monitoring and alerting for guest user invitations by integrating with a Security Information and Event Management (SIEM) system to ensure timely detection and response. +- Review and update the organization's Azure AD guest user policies to ensure they align with security best practices and business needs, minimizing unnecessary guest access. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://docs.microsoft.com/en-us/azure/governance/policy/samples/cis-azure-1-1-0"] diff --git a/rules/integrations/azure/persistence_azure_automation_account_created.toml b/rules/integrations/azure/persistence_azure_automation_account_created.toml index 114f1210d26..63f187ee4d4 100644 --- a/rules/integrations/azure/persistence_azure_automation_account_created.toml +++ b/rules/integrations/azure/persistence_azure_automation_account_created.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/18" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -16,7 +16,41 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Automation Account Created" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Azure Automation Account Created + +Azure Automation accounts facilitate the automation of management tasks and orchestration across cloud environments, enhancing operational efficiency. However, adversaries may exploit these accounts to establish persistence by automating malicious activities. The detection rule monitors the creation of these accounts by analyzing specific Azure activity logs, focusing on successful operations, to identify potential unauthorized or suspicious account creations. + +### Possible investigation steps + +- Review the Azure activity logs to confirm the creation of the Automation account by checking for the operation name "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/WRITE" and ensure the event outcome is marked as Success. +- Identify the user or service principal that initiated the creation of the Automation account by examining the associated user identity information in the activity logs. +- Investigate the context of the Automation account creation by reviewing recent activities performed by the identified user or service principal to determine if there are any other suspicious or unauthorized actions. +- Check the configuration and permissions of the newly created Automation account to ensure it does not have excessive privileges that could be exploited for persistence or lateral movement. +- Correlate the Automation account creation event with other security alerts or logs to identify any patterns or indicators of compromise that may suggest malicious intent. + +### False positive analysis + +- Routine administrative tasks may trigger the rule when legitimate users create Azure Automation accounts for operational purposes. To manage this, maintain a list of authorized personnel and their expected activities, and cross-reference alerts with this list. +- Automated deployment scripts or infrastructure-as-code tools might create automation accounts as part of their normal operation. Identify these scripts and exclude their associated activities from triggering alerts by using specific identifiers or tags. +- Scheduled maintenance or updates by cloud service providers could result in the creation of automation accounts. Verify the timing and context of the account creation against known maintenance schedules and exclude these from alerts if they match. +- Development and testing environments often involve frequent creation and deletion of resources, including automation accounts. Implement separate monitoring rules or environments for these non-production areas to reduce noise in alerts. + +### Response and remediation + +- Immediately review the Azure activity logs to confirm the creation of the Automation account and identify the user or service principal responsible for the action. +- Disable the newly created Azure Automation account to prevent any potential malicious automation tasks from executing. +- Conduct a thorough investigation of the user or service principal that created the account to determine if their credentials have been compromised or if they have acted maliciously. +- Reset credentials and enforce multi-factor authentication for the identified user or service principal to prevent unauthorized access. +- Review and adjust Azure role-based access control (RBAC) policies to ensure that only authorized personnel have the ability to create Automation accounts. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems or accounts have been compromised. +- Implement enhanced monitoring and alerting for future Automation account creations to quickly detect and respond to similar threats. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/azure/persistence_azure_automation_runbook_created_or_modified.toml b/rules/integrations/azure/persistence_azure_automation_runbook_created_or_modified.toml index 94aa992de20..9a6a3e5d00b 100644 --- a/rules/integrations/azure/persistence_azure_automation_runbook_created_or_modified.toml +++ b/rules/integrations/azure/persistence_azure_automation_runbook_created_or_modified.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/18" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -15,7 +15,43 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Automation Runbook Created or Modified" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Azure Automation Runbook Created or Modified + +Azure Automation Runbooks are scripts that automate tasks in cloud environments, enhancing operational efficiency. However, adversaries can exploit them to execute unauthorized code and maintain persistence. The detection rule monitors specific Azure activity logs for runbook creation or modification events, flagging successful operations to identify potential misuse. This helps in early detection of malicious activities, ensuring cloud security. + +### Possible investigation steps + +- Review the Azure activity logs to identify the specific runbook that was created or modified, focusing on the operation names: "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/DRAFT/WRITE", "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/WRITE", or "MICROSOFT.AUTOMATION/AUTOMATIONACCOUNTS/RUNBOOKS/PUBLISH/ACTION". +- Check the event.outcome field to confirm the operation was successful, as indicated by the values "Success" or "success". +- Identify the user or service principal that performed the operation by examining the relevant user identity fields in the activity logs. +- Investigate the content and purpose of the runbook by reviewing its script or configuration to determine if it contains any unauthorized or suspicious code. +- Correlate the runbook activity with other security events or alerts in the environment to identify any patterns or related malicious activities. +- Verify if the runbook changes align with recent legitimate administrative activities or if they were unexpected, which could indicate potential misuse. + +### False positive analysis + +- Routine updates or maintenance activities by authorized personnel can trigger alerts. To manage this, create exceptions for known maintenance windows or specific user accounts that regularly perform these tasks. +- Automated deployment processes that include runbook creation or modification might be flagged. Identify and exclude these processes by tagging them with specific identifiers in the logs. +- Integration with third-party tools that modify runbooks as part of their normal operation can result in false positives. Work with your IT team to whitelist these tools or their associated accounts. +- Frequent testing or development activities in non-production environments may cause alerts. Consider setting up separate monitoring rules or thresholds for these environments to reduce noise. +- Scheduled runbook updates for compliance or policy changes can be mistaken for suspicious activity. Document these schedules and adjust the detection rule to account for them, possibly by excluding specific operation names during these times. + +### Response and remediation + +- Immediately isolate the affected Azure Automation account to prevent further unauthorized runbook executions. This can be done by disabling the account or restricting its permissions temporarily. +- Review the modified or newly created runbooks to identify any malicious code or unauthorized changes. Remove or revert any suspicious modifications to ensure the integrity of the automation scripts. +- Conduct a thorough audit of recent activities associated with the affected Azure Automation account, focusing on identifying any unauthorized access or changes made by adversaries. +- Reset credentials and update access controls for the affected Azure Automation account to prevent further unauthorized access. Ensure that only authorized personnel have the necessary permissions to create or modify runbooks. +- Implement additional monitoring and alerting for Azure Automation activities, specifically focusing on runbook creation and modification events, to enhance early detection of similar threats in the future. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or accounts have been compromised. +- Document the incident, including all actions taken and findings, to improve response strategies and update incident response plans for future reference. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/azure/persistence_azure_automation_webhook_created.toml b/rules/integrations/azure/persistence_azure_automation_webhook_created.toml index 370c2d78c7c..625aae8b651 100644 --- a/rules/integrations/azure/persistence_azure_automation_webhook_created.toml +++ b/rules/integrations/azure/persistence_azure_automation_webhook_created.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/18" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -16,7 +16,42 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Automation Webhook Created" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Azure Automation Webhook Created + +Azure Automation webhooks enable automated task execution via HTTP requests, integrating with external systems. Adversaries may exploit this by creating webhooks to trigger runbooks with harmful scripts, maintaining persistence. The detection rule identifies webhook creation events, focusing on specific operation names and successful outcomes, to flag potential misuse in cloud environments. + +### Possible investigation steps + +- Review the Azure activity logs to identify the user or service principal that initiated the webhook creation by examining the `event.dataset` and `azure.activitylogs.operation_name` fields. +- Check the associated runbook linked to the created webhook to determine its purpose and inspect its content for any potentially malicious scripts or commands. +- Investigate the source IP address and location from which the webhook creation request originated to identify any unusual or unauthorized access patterns. +- Verify the legitimacy of the webhook by contacting the owner of the Azure Automation account or the relevant team to confirm if the webhook creation was expected and authorized. +- Assess the broader context of the activity by reviewing recent changes or activities in the Azure Automation account to identify any other suspicious actions or configurations. + +### False positive analysis + +- Routine webhook creations for legitimate automation tasks can trigger false positives. Review the context of the webhook creation, such as the associated runbook and its purpose, to determine if it aligns with expected operations. +- Frequent webhook creations by trusted users or service accounts may not indicate malicious activity. Consider creating exceptions for these users or accounts to reduce noise in alerts. +- Automated deployment processes that involve creating webhooks as part of their workflow can be mistaken for suspicious activity. Document these processes and exclude them from triggering alerts if they are verified as safe. +- Integration with third-party services that require webhook creation might generate alerts. Verify these integrations and whitelist them if they are part of approved business operations. +- Regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded, maintaining the effectiveness of the detection rule. + +### Response and remediation + +- Immediately disable the suspicious webhook to prevent further execution of potentially harmful runbooks. +- Review the runbook associated with the webhook for any unauthorized or malicious scripts and remove or quarantine any identified threats. +- Conduct a thorough audit of recent changes in the Azure Automation account to identify any unauthorized access or modifications. +- Revoke any compromised credentials and enforce multi-factor authentication (MFA) for all accounts with access to Azure Automation. +- Notify the security team and relevant stakeholders about the incident for further investigation and to ensure awareness of potential threats. +- Implement enhanced monitoring and alerting for webhook creation and execution activities to detect similar threats in the future. +- Document the incident, including actions taken and lessons learned, to improve response strategies and prevent recurrence. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/azure/persistence_azure_conditional_access_policy_modified.toml b/rules/integrations/azure/persistence_azure_conditional_access_policy_modified.toml index fda5b5dbbe4..a7b14c9b569 100644 --- a/rules/integrations/azure/persistence_azure_conditional_access_policy_modified.toml +++ b/rules/integrations/azure/persistence_azure_conditional_access_policy_modified.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/01" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -17,7 +17,42 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Conditional Access Policy Modified" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Conditional Access Policy Modified + +Azure Conditional Access policies are critical for managing secure access to resources by enforcing specific conditions, such as requiring multi-factor authentication. Adversaries may exploit this by altering policies to weaken security, potentially bypassing authentication measures. The detection rule monitors logs for successful modifications to these policies, flagging potential unauthorized changes that could indicate malicious activity. + +### Possible investigation steps + +- Review the Azure activity and audit logs to identify the specific user account associated with the "Update conditional access policy" action and verify if the modification was authorized. +- Examine the details of the modified Conditional Access policy to understand the changes made, focusing on any alterations that could weaken security, such as the removal of multi-factor authentication requirements. +- Check the event.outcome field to confirm the success of the policy modification and correlate it with any recent access attempts or suspicious activities involving the affected resources. +- Investigate the history of changes to the Conditional Access policies to identify any patterns or repeated unauthorized modifications that could indicate persistent malicious activity. +- Assess the user's role and permissions to determine if they have legitimate access to modify Conditional Access policies, and review any recent changes to their account or role assignments. + +### False positive analysis + +- Routine administrative updates to Conditional Access policies by authorized IT personnel can trigger alerts. To manage this, maintain a list of authorized users and their expected activities, and create exceptions for these users in the monitoring system. +- Scheduled policy reviews and updates as part of regular security audits may also result in false positives. Document these activities and schedule them during known maintenance windows to differentiate them from unauthorized changes. +- Automated scripts or tools used for policy management might generate alerts if they modify policies. Ensure these tools are properly documented and their actions are logged separately to distinguish them from potential threats. +- Changes made during the onboarding or offboarding of employees can appear as suspicious activity. Implement a process to log these events separately and cross-reference them with HR records to verify legitimacy. +- Integration with third-party security solutions that modify policies for compliance or optimization purposes can lead to false positives. Establish a clear change management process and whitelist these integrations to prevent unnecessary alerts. + +### Response and remediation + +- Immediately review the modified Conditional Access policy to understand the changes made and assess the potential impact on security controls. +- Revert any unauthorized or suspicious changes to the Conditional Access policy to restore the original security posture. +- Conduct a thorough investigation to identify the source of the modification, including reviewing audit logs for unusual activity or unauthorized access attempts. +- Temporarily increase monitoring and logging of Conditional Access policy changes to detect any further unauthorized modifications. +- Notify the security team and relevant stakeholders about the incident and the steps taken to mitigate the risk. +- If malicious activity is confirmed, initiate an incident response process, including isolating affected accounts and conducting a full security assessment. +- Implement additional security measures, such as stricter access controls or enhanced multi-factor authentication requirements, to prevent similar incidents in the future. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview"] diff --git a/rules/integrations/azure/persistence_azure_global_administrator_role_assigned.toml b/rules/integrations/azure/persistence_azure_global_administrator_role_assigned.toml index d3509a4a043..64cd238b79b 100644 --- a/rules/integrations/azure/persistence_azure_global_administrator_role_assigned.toml +++ b/rules/integrations/azure/persistence_azure_global_administrator_role_assigned.toml @@ -2,7 +2,7 @@ creation_date = "2022/01/06" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -18,7 +18,42 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure AD Global Administrator Role Assigned" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AD Global Administrator Role Assigned + +Azure AD's Global Administrator role grants comprehensive access to manage Azure AD and associated services. Adversaries may exploit this by assigning themselves or others to this role, ensuring persistent control over resources. The detection rule identifies such unauthorized assignments by monitoring specific audit logs for role changes, focusing on the addition of members to the Global Administrator role, thus helping to mitigate potential security breaches. + +### Possible investigation steps + +- Review the Azure audit logs to identify the user account that performed the "Add member to role" operation, focusing on the specific event dataset and operation name. +- Verify the identity of the user added to the Global Administrator role by examining the modified properties in the audit logs, specifically the new_value field indicating "Global Administrator". +- Check the history of role assignments for the identified user to determine if this is a recurring pattern or a one-time event. +- Investigate the source IP address and location associated with the role assignment event to assess if it aligns with expected user behavior or if it indicates potential unauthorized access. +- Review any recent changes or activities performed by the newly assigned Global Administrator to identify any suspicious actions or configurations that may have been altered. +- Consult with the organization's IT or security team to confirm if the role assignment was authorized and aligns with current administrative needs or projects. + +### False positive analysis + +- Routine administrative tasks may trigger alerts when legitimate IT staff are assigned the Global Administrator role temporarily for maintenance or configuration purposes. To manage this, create exceptions for known IT personnel or scheduled maintenance windows. +- Automated scripts or third-party applications that require elevated permissions might be flagged if they are configured to add users to the Global Administrator role. Review and whitelist these scripts or applications if they are verified as safe and necessary for operations. +- Organizational changes, such as mergers or restructuring, can lead to legitimate role assignments that appear suspicious. Implement a review process to verify these changes and exclude them from triggering alerts if they align with documented organizational changes. +- Training or onboarding sessions for new IT staff might involve temporary assignment to the Global Administrator role. Establish a protocol to document and exclude these training-related assignments from detection alerts. + +### Response and remediation + +- Immediately remove any unauthorized users from the Global Administrator role to prevent further unauthorized access and control over Azure AD resources. +- Conduct a thorough review of recent audit logs to identify any additional unauthorized changes or suspicious activities associated with the compromised account or role assignments. +- Reset the credentials of the affected accounts and enforce multi-factor authentication (MFA) to enhance security and prevent further unauthorized access. +- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation. +- Implement conditional access policies to restrict Global Administrator role assignments to specific, trusted locations or devices. +- Review and update role assignment policies to ensure that only a limited number of trusted personnel have the ability to assign Global Administrator roles. +- Enhance monitoring and alerting mechanisms to detect similar unauthorized role assignments in the future, ensuring timely response to potential threats. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/azure/persistence_azure_pim_user_added_global_admin.toml b/rules/integrations/azure/persistence_azure_pim_user_added_global_admin.toml index c27d826a2e9..8944eed62e2 100644 --- a/rules/integrations/azure/persistence_azure_pim_user_added_global_admin.toml +++ b/rules/integrations/azure/persistence_azure_pim_user_added_global_admin.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/24" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -24,7 +24,43 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Global Administrator Role Addition to PIM User" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Azure Global Administrator Role Addition to PIM User + +Azure AD's Global Administrator role grants extensive access, allowing users to modify any administrative setting. Privileged Identity Management (PIM) helps manage and monitor such access. Adversaries may exploit this by adding themselves or others to this role, gaining persistent control. The detection rule identifies suspicious role additions by monitoring specific audit logs, focusing on successful role assignments to PIM users, thus helping to flag potential unauthorized access attempts. + +### Possible investigation steps + +- Review the Azure audit logs to confirm the details of the role addition event, focusing on the event.dataset:azure.auditlogs and azure.auditlogs.properties.category:RoleManagement fields. +- Identify the user account that was added to the Global Administrator role by examining the azure.auditlogs.properties.target_resources.*.display_name field. +- Check the event.outcome field to ensure the role addition was successful and not a failed attempt. +- Investigate the user account's recent activities and login history to determine if there are any anomalies or signs of compromise. +- Verify if the role addition aligns with any recent administrative changes or requests within the organization to rule out legitimate actions. +- Assess the potential impact of the role addition by reviewing the permissions and access levels granted to the user. +- If suspicious activity is confirmed, initiate a response plan to remove unauthorized access and secure the affected accounts. + +### False positive analysis + +- Routine administrative tasks may trigger alerts when legitimate IT staff are assigned the Global Administrator role for maintenance or updates. To manage this, create exceptions for known IT personnel or scheduled maintenance windows. +- Automated scripts or tools used for role assignments can cause false positives if they frequently add users to the Global Administrator role. Consider excluding these automated processes from monitoring or adjusting the detection rule to account for their activity. +- Temporary project-based role assignments might be flagged as suspicious. Implement a process to document and pre-approve such assignments, allowing for their exclusion from alerts. +- Training or onboarding sessions where new administrators are temporarily granted elevated access can result in false positives. Establish a protocol to notify the monitoring team of these events in advance, so they can be excluded from the detection rule. + +### Response and remediation + +- Immediately revoke the Global Administrator role from any unauthorized PIM user identified in the alert to prevent further unauthorized access. +- Conduct a thorough review of recent changes made by the affected account to identify any unauthorized modifications or suspicious activities. +- Reset the credentials of the compromised account and enforce multi-factor authentication (MFA) to secure the account against further unauthorized access. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring on the affected account and related systems to detect any further suspicious activities. +- Review and update access policies and role assignments in Azure AD to ensure that only necessary personnel have elevated privileges. +- Document the incident and response actions taken for future reference and to improve incident response procedures. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/azure/persistence_user_added_as_owner_for_azure_application.toml b/rules/integrations/azure/persistence_user_added_as_owner_for_azure_application.toml index 1da8d4b0099..5df04014061 100644 --- a/rules/integrations/azure/persistence_user_added_as_owner_for_azure_application.toml +++ b/rules/integrations/azure/persistence_user_added_as_owner_for_azure_application.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/20" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -16,7 +16,42 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "User Added as Owner for Azure Application" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating User Added as Owner for Azure Application + +Azure applications often require specific permissions for functionality, managed by assigning user roles. An adversary might exploit this by adding themselves or a compromised account as an owner, gaining elevated privileges to alter configurations or access sensitive data. The detection rule monitors audit logs for successful operations where a user is added as an application owner, flagging potential unauthorized privilege escalations. + +### Possible investigation steps + +- Review the Azure audit logs to confirm the operation by filtering for event.dataset:azure.auditlogs and azure.auditlogs.operation_name:"Add owner to application" with a successful outcome. +- Identify the user account that was added as an owner and the account that performed the operation to determine if they are legitimate or potentially compromised. +- Check the history of activities associated with both the added owner and the account that performed the operation to identify any suspicious behavior or patterns. +- Verify the application's current configuration and permissions to assess any changes made after the new owner was added. +- Contact the legitimate owner or administrator of the Azure application to confirm whether the addition of the new owner was authorized. +- Investigate any recent changes in the organization's user access policies or roles that might explain the addition of a new owner. + +### False positive analysis + +- Routine administrative actions: Regular maintenance or updates by IT staff may involve adding users as application owners. To manage this, create a list of authorized personnel and exclude their actions from triggering alerts. +- Automated processes: Some applications may have automated scripts or services that add users as owners for operational purposes. Identify these processes and configure exceptions for their activities. +- Organizational changes: During mergers or restructuring, there may be legitimate reasons for adding multiple users as application owners. Temporarily adjust the rule to accommodate these changes and review the audit logs manually. +- Testing and development: In development environments, users may be added as owners for testing purposes. Exclude these environments from the rule or set up a separate monitoring policy with adjusted thresholds. + +### Response and remediation + +- Immediately revoke the added user's owner permissions from the Azure application to prevent further unauthorized access or configuration changes. +- Conduct a thorough review of recent activity logs for the affected application to identify any unauthorized changes or data access that may have occurred since the user was added as an owner. +- Reset credentials and enforce multi-factor authentication for the compromised or suspicious account to prevent further misuse. +- Notify the security team and relevant stakeholders about the incident for awareness and potential escalation if further investigation reveals broader compromise. +- Implement additional monitoring on the affected application and related accounts to detect any further unauthorized access attempts or privilege escalations. +- Review and update access control policies to ensure that only authorized personnel can modify application ownership, and consider implementing stricter approval processes for such changes. +- Document the incident, including actions taken and lessons learned, to improve response strategies and prevent recurrence. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" risk_score = 21 diff --git a/rules/integrations/azure/persistence_user_added_as_owner_for_azure_service_principal.toml b/rules/integrations/azure/persistence_user_added_as_owner_for_azure_service_principal.toml index cdb7081845a..46faa2c238f 100644 --- a/rules/integrations/azure/persistence_user_added_as_owner_for_azure_service_principal.toml +++ b/rules/integrations/azure/persistence_user_added_as_owner_for_azure_service_principal.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/20" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -18,7 +18,42 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "User Added as Owner for Azure Service Principal" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating User Added as Owner for Azure Service Principal + +Azure service principals are crucial for managing application permissions within a tenant, defining access and capabilities. Adversaries may exploit this by adding themselves as owners, gaining control over application permissions and access. The detection rule monitors audit logs for successful owner additions, flagging potential unauthorized changes to maintain security integrity. + +### Possible investigation steps + +- Review the audit log entry to confirm the event dataset is 'azure.auditlogs' and the operation name is "Add owner to service principal" with a successful outcome. +- Identify the user account that was added as an owner and gather information about this account, including recent activity and any associated alerts. +- Determine the service principal involved by reviewing its details, such as the application it is associated with and the permissions it holds. +- Check the history of changes to the service principal to identify any other recent modifications or suspicious activities. +- Investigate the context and necessity of the ownership change by contacting the user or team responsible for the service principal to verify if the change was authorized. +- Assess the potential impact of the ownership change on the tenant's security posture, considering the permissions and access granted to the service principal. + +### False positive analysis + +- Routine administrative changes may trigger alerts when legitimate IT staff add themselves or others as owners for maintenance purposes. To manage this, create exceptions for known administrative accounts that frequently perform these actions. +- Automated processes or scripts that manage service principal ownership as part of regular operations can cause false positives. Identify and document these processes, then exclude them from triggering alerts by using specific identifiers or tags. +- Organizational changes, such as team restructuring, might lead to multiple legitimate ownership changes. During these periods, temporarily adjust the rule sensitivity or create temporary exceptions for specific user groups involved in the transition. +- Third-party applications that require ownership changes for integration purposes can also trigger alerts. Verify these applications and whitelist their associated service principal changes to prevent unnecessary alerts. + +### Response and remediation + +- Immediately revoke the added user's ownership from the Azure service principal to prevent unauthorized access and control. +- Conduct a thorough review of the affected service principal's permissions and access logs to identify any unauthorized changes or access attempts. +- Reset credentials and update any secrets or keys associated with the compromised service principal to mitigate potential misuse. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Implement conditional access policies to restrict who can add owners to service principals, ensuring only authorized personnel have this capability. +- Enhance monitoring and alerting for similar activities by increasing the sensitivity of alerts related to changes in service principal ownership. +- Document the incident and response actions taken to improve future incident response and refine security policies. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/azure/privilege_escalation_azure_kubernetes_rolebinding_created.toml b/rules/integrations/azure/privilege_escalation_azure_kubernetes_rolebinding_created.toml index c57337e5f17..d1d537c3f86 100644 --- a/rules/integrations/azure/privilege_escalation_azure_kubernetes_rolebinding_created.toml +++ b/rules/integrations/azure/privilege_escalation_azure_kubernetes_rolebinding_created.toml @@ -2,7 +2,7 @@ creation_date = "2021/10/18" integration = ["azure"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Austin Songer"] @@ -17,7 +17,42 @@ index = ["filebeat-*", "logs-azure*"] language = "kuery" license = "Elastic License v2" name = "Azure Kubernetes Rolebindings Created" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Azure Kubernetes Rolebindings Created +Azure Kubernetes role bindings are crucial for managing access control within Kubernetes clusters, allowing specific permissions to be assigned to users, groups, or service accounts. Adversaries with the ability to create these bindings can escalate privileges by assigning themselves or others high-level roles, such as cluster-admin. The detection rule monitors Azure activity logs for successful creation events of role or cluster role bindings, signaling potential unauthorized privilege escalation attempts. + +### Possible investigation steps + +- Review the Azure activity logs to identify the user or service account associated with the role binding creation event. Focus on the `event.dataset` and `azure.activitylogs.operation_name` fields to confirm the specific operation. +- Check the `event.outcome` field to ensure the operation was successful and not a failed attempt, which might indicate a misconfiguration or testing. +- Investigate the permissions and roles assigned to the identified user or service account to determine if they have legitimate reasons to create role bindings or cluster role bindings. +- Examine the context of the role binding creation, such as the time of the event and any related activities, to identify any unusual patterns or correlations with other suspicious activities. +- Verify if the role binding grants elevated privileges, such as cluster-admin, and assess the potential impact on the cluster's security posture. +- Cross-reference the event with any recent changes in the cluster's configuration or access policies to understand if the role binding creation aligns with authorized administrative actions. + +### False positive analysis + +- Routine administrative tasks may trigger alerts when legitimate users create role bindings for operational purposes. To manage this, identify and whitelist specific user accounts or service accounts that regularly perform these tasks. +- Automated deployment tools or scripts that configure Kubernetes clusters might create role bindings as part of their normal operation. Exclude these tools by filtering out known service accounts or IP addresses associated with these automated processes. +- Scheduled maintenance or updates to the Kubernetes environment can result in multiple role binding creation events. Establish a maintenance window and suppress alerts during this period to avoid unnecessary noise. +- Development and testing environments often have frequent role binding changes. Consider creating separate monitoring rules with adjusted thresholds or risk scores for these environments to reduce false positives. +- Collaboration with the DevOps team can help identify expected role binding changes, allowing for preemptive exclusion of these events from triggering alerts. + +### Response and remediation + +- Immediately revoke any newly created role bindings or cluster role bindings that are unauthorized or suspicious to prevent further privilege escalation. +- Isolate the affected Kubernetes cluster from the network to prevent potential lateral movement or further exploitation by the adversary. +- Conduct a thorough review of recent activity logs to identify any unauthorized access or changes made by the adversary, focusing on the time frame around the alert. +- Reset credentials and access tokens for any compromised accounts or service accounts involved in the unauthorized role binding creation. +- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or resources are affected. +- Implement additional monitoring and alerting for any future role binding or cluster role binding creation events to ensure rapid detection and response. +- Review and tighten role-based access control (RBAC) policies to ensure that only necessary permissions are granted to users, groups, and service accounts, minimizing the risk of privilege escalation. + +## Setup The Azure Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/beaconing/command_and_control_beaconing.toml b/rules/integrations/beaconing/command_and_control_beaconing.toml index 9d4a5ba44d8..6a1620b73f2 100644 --- a/rules/integrations/beaconing/command_and_control_beaconing.toml +++ b/rules/integrations/beaconing/command_and_control_beaconing.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/22" integration = ["beaconing", "endpoint", "network_traffic"] maturity = "production" -updated_date = "2024/11/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -56,6 +56,41 @@ not process.name: ("WaAppAgent.exe" or "metricbeat.exe" or "packetbeat.exe" or " "agentbeat" or "dnf" or "yum" or "apt" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Statistical Model Detected C2 Beaconing Activity + +Statistical models analyze network traffic patterns to identify anomalies indicative of C2 beaconing, a tactic used by attackers to maintain covert communication with compromised systems. Adversaries exploit this by sending periodic signals to C2 servers, often mimicking legitimate traffic. The detection rule leverages statistical analysis to flag unusual beaconing while excluding known benign processes, thus highlighting potential threats without overwhelming analysts with false positives. + +### Possible investigation steps + +- Review the network traffic logs to identify the source and destination IP addresses associated with the beaconing activity flagged by the statistical model. +- Cross-reference the identified IP addresses with threat intelligence databases to determine if they are associated with known malicious C2 servers. +- Analyze the frequency and pattern of the beaconing signals to assess whether they mimic legitimate traffic or exhibit characteristics typical of C2 communication. +- Investigate the processes running on the source system to identify any suspicious or unauthorized applications that may be responsible for the beaconing activity. +- Check for any recent changes or anomalies in the system's configuration or installed software that could indicate a compromise. +- Examine the historical network activity of the source system to identify any other unusual patterns or connections that may suggest a broader compromise. + +### False positive analysis + +- The rule may flag legitimate processes that exhibit periodic network communication patterns similar to C2 beaconing. Processes like "metricbeat.exe" and "packetbeat.exe" are known to generate regular network traffic for monitoring purposes. +- Users can manage these false positives by adding exceptions for these known benign processes in the detection rule, ensuring they are not flagged as threats. +- Regularly review and update the list of excluded processes to include any new legitimate applications that may mimic beaconing behavior, reducing unnecessary alerts. +- Consider implementing a whitelist approach for processes that are verified as non-threatening, allowing the statistical model to focus on truly anomalous activities. +- Engage with network and security teams to understand the normal traffic patterns of your environment, which can help in refining the detection rule and minimizing false positives. + +### Response and remediation + +- Isolate the affected system from the network to prevent further communication with the C2 server and limit potential data exfiltration. +- Terminate any suspicious processes identified by the alert that are not part of the known benign list, ensuring that any malicious activity is halted. +- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious software or files. +- Review and analyze network logs to identify any other systems that may have communicated with the same C2 server, and apply similar containment measures to those systems. +- Restore the affected system from a known good backup to ensure that any persistent threats are removed, and verify the integrity of the restored system. +- Implement network segmentation to limit the ability of compromised systems to communicate with critical infrastructure and sensitive data. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional measures are needed to prevent recurrence.""" [[rule.threat]] diff --git a/rules/integrations/beaconing/command_and_control_beaconing_high_confidence.toml b/rules/integrations/beaconing/command_and_control_beaconing_high_confidence.toml index aaef19e8d11..91d1a58c882 100644 --- a/rules/integrations/beaconing/command_and_control_beaconing_high_confidence.toml +++ b/rules/integrations/beaconing/command_and_control_beaconing_high_confidence.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/22" integration = ["beaconing", "endpoint", "network_traffic"] maturity = "production" -updated_date = "2024/11/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -50,6 +50,42 @@ type = "query" query = ''' beacon_stats.beaconing_score: 3 ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Statistical Model Detected C2 Beaconing Activity with High Confidence + +Statistical models analyze network traffic patterns to identify anomalies indicative of C2 beaconing, a tactic where attackers maintain covert communication with compromised systems. Adversaries exploit this to issue commands, exfiltrate data, and sustain network presence. The detection rule leverages a high beaconing score to flag potential threats, aiding analysts in pinpointing suspicious activities linked to C2 operations. + +### Possible investigation steps + +- Review the network traffic logs to identify the source and destination IP addresses associated with the beaconing activity flagged by the beacon_stats.beaconing_score of 3. +- Correlate the identified IP addresses with known malicious IP databases or threat intelligence feeds to determine if they are associated with known C2 servers. +- Analyze the frequency and pattern of the beaconing activity to assess whether it aligns with typical C2 communication patterns, such as regular intervals or specific time frames. +- Investigate the domain names involved in the communication to check for any associations with malicious activities or suspicious registrations. +- Examine the payloads or data transferred during the flagged communication sessions to identify any potential exfiltration of sensitive information or receipt of malicious instructions. +- Cross-reference the involved systems with internal asset inventories to determine if they are critical assets or have been previously flagged for suspicious activities. +- Consult with the incident response team to decide on containment or remediation actions if the investigation confirms malicious C2 activity. + +### False positive analysis + +- Regularly scheduled software updates or patch management systems may generate network traffic patterns similar to C2 beaconing. Users can create exceptions for known update servers to reduce false positives. +- Automated backup systems that frequently communicate with cloud storage services might be flagged. Identifying and excluding these backup services from the analysis can help mitigate this issue. +- Network monitoring tools that periodically check connectivity or system health can mimic beaconing activity. Whitelisting these monitoring tools can prevent them from being incorrectly flagged. +- Internal applications that use polling mechanisms to check for updates or status changes may trigger alerts. Documenting and excluding these applications from the rule can minimize false positives. +- Frequent communication with trusted third-party services, such as content delivery networks, may appear as beaconing. Establishing a list of trusted domains and excluding them from the analysis can help manage this. + +### Response and remediation + +- Isolate the affected systems from the network to prevent further communication with the C2 server and contain the threat. +- Conduct a thorough analysis of the network traffic logs to identify any additional compromised systems or lateral movement within the network. +- Remove any malicious software or scripts identified on the compromised systems, ensuring all traces of the C2 communication channels are eradicated. +- Apply security patches and updates to all affected systems to close any vulnerabilities exploited by the attackers. +- Change all credentials and authentication tokens associated with the compromised systems to prevent unauthorized access. +- Monitor the network for any signs of re-infection or continued C2 activity, using enhanced detection rules and updated threat intelligence. +- Escalate the incident to the appropriate internal security team or external cybersecurity experts for further investigation and to assess the potential impact on the organization.""" [[rule.threat]] diff --git a/rules/integrations/cloud_defend/container_workload_protection.toml b/rules/integrations/cloud_defend/container_workload_protection.toml index af8cc879b82..e3fc2fe05fa 100644 --- a/rules/integrations/cloud_defend/container_workload_protection.toml +++ b/rules/integrations/cloud_defend/container_workload_protection.toml @@ -2,7 +2,7 @@ creation_date = "2023/04/05" integration = ["cloud_defend"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -37,4 +37,39 @@ type = "query" query = ''' event.kind:alert and event.module:cloud_defend ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Container Workload Protection + +Container Workload Protection is crucial for securing containerized environments by monitoring and defending against threats. Adversaries may exploit vulnerabilities in container orchestration or escape isolation to access host systems. The detection rule leverages alerts from cloud defense modules, focusing on suspicious activities within container domains, enabling timely triage and investigation of potential security incidents. + +### Possible investigation steps + +- Review the alert details to confirm it matches the query criteria, specifically checking for event.kind:alert and event.module:cloud_defend. +- Examine the context of the alert to identify any suspicious activities or anomalies within the container environment. +- Investigate the source and destination of the alert to determine if there are any unauthorized access attempts or lateral movement within the container infrastructure. +- Check for any recent changes or updates in the container orchestration system that might have introduced vulnerabilities. +- Correlate the alert with other security events or logs to identify patterns or repeated attempts that could indicate a larger attack campaign. +- Assess the impact of the alert on the containerized environment and determine if any immediate remediation actions are necessary to protect the host systems. + +### False positive analysis + +- Alerts triggered by routine maintenance tasks in container environments can be false positives. Users can create exceptions for known maintenance activities to reduce unnecessary alerts. +- Automated deployment processes might generate alerts due to rapid changes in container states. Exclude these processes by identifying and whitelisting their specific event patterns. +- Frequent updates to container images can cause alerts. Implement rules to recognize and exclude these updates if they match expected patterns and sources. +- Legitimate administrative actions within container orchestration platforms may be flagged. Document and exclude these actions by correlating them with authorized user activities. +- Network scanning tools used for security assessments might trigger alerts. Ensure these tools are recognized and excluded by defining their IP ranges and expected behaviors. + +### Response and remediation + +- Isolate the affected container to prevent lateral movement and further exploitation. This can be done by stopping the container or disconnecting it from the network. +- Analyze the container's logs and configurations to identify any unauthorized changes or suspicious activities that align with the alert. +- Patch any identified vulnerabilities in the container image or orchestration platform to prevent similar exploits. +- Restore the container from a known good backup or rebuild it using a secure and updated image to ensure no residual threats remain. +- Implement network segmentation and access controls to limit the exposure of containerized environments to potential threats. +- Escalate the incident to the security operations team if the threat appears to have impacted the host system or other critical infrastructure. +- Enhance monitoring and alerting rules to detect similar suspicious activities in the future, ensuring timely response to potential threats.""" diff --git a/rules/integrations/cloud_defend/credential_access_aws_creds_search_inside_a_container.toml b/rules/integrations/cloud_defend/credential_access_aws_creds_search_inside_a_container.toml index da057f623e1..3dac6dc3a37 100644 --- a/rules/integrations/cloud_defend/credential_access_aws_creds_search_inside_a_container.toml +++ b/rules/integrations/cloud_defend/credential_access_aws_creds_search_inside_a_container.toml @@ -2,7 +2,7 @@ creation_date = "2023/06/28" integration = ["cloud_defend"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -39,6 +39,40 @@ process where event.module == "cloud_defend" and (process.name : ("grep", "egrep", "fgrep", "find", "locate", "mlocate") or process.args : ("grep", "egrep", "fgrep", "find", "locate", "mlocate")) and process.args : ("*aws_access_key_id*", "*aws_secret_access_key*", "*aws_session_token*", "*accesskeyid*", "*secretaccesskey*", "*access_key*", "*.aws/credentials*") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS Credentials Searched For Inside A Container + +Containers often house applications that interact with AWS services, necessitating the storage of AWS credentials. Adversaries may exploit this by using search utilities to locate these credentials, potentially leading to unauthorized access. The detection rule identifies suspicious use of search tools within containers, flagging attempts to locate AWS credentials by monitoring specific process names and arguments, thus helping to prevent credential theft and subsequent attacks. + +### Possible investigation steps + +- Review the process details to identify the specific search utility used (e.g., grep, find) and the arguments passed, focusing on those related to AWS credentials such as aws_access_key_id or aws_secret_access_key. +- Examine the container's metadata and environment to determine the context of the process, including the container ID, image name, and any associated labels or tags that might indicate the container's purpose or sensitivity. +- Check the user context under which the suspicious process was executed to assess whether it aligns with expected behavior for that user or role within the container. +- Investigate the source of the container image to ensure it is from a trusted repository and has not been tampered with, which could indicate a supply chain compromise. +- Analyze recent activity logs for the container to identify any other suspicious behavior or anomalies that might correlate with the search for AWS credentials, such as unexpected network connections or file modifications. +- Review access logs for AWS services to detect any unauthorized or unusual access patterns that might suggest the use of compromised credentials. + +### False positive analysis + +- Routine maintenance scripts or automated processes may use search utilities to verify the presence of AWS credentials for legitimate configuration checks. To handle this, identify and whitelist these specific scripts or processes by their unique identifiers or execution paths. +- Developers or system administrators might manually search for AWS credentials during debugging or configuration tasks. Implement a policy to log and review these activities, and consider excluding known user accounts or roles from triggering alerts during specific time windows or in designated environments. +- Security audits or compliance checks often involve searching for sensitive information, including AWS credentials, to ensure proper security measures are in place. Coordinate with audit teams to schedule these activities and temporarily suppress alerts during these periods, or exclude specific audit tools from detection. +- Continuous integration and deployment (CI/CD) pipelines might include steps that search for AWS credentials to validate environment configurations. Identify these pipelines and exclude their associated processes or container environments from triggering alerts, ensuring that only authorized CI/CD tools are used. + +### Response and remediation + +- Immediately isolate the affected container to prevent further unauthorized access or data exfiltration. This can be done by stopping the container or disconnecting it from the network. +- Revoke any AWS credentials that were potentially exposed or accessed. This includes rotating keys and updating any services or applications that rely on these credentials. +- Conduct a thorough review of the container's file system to identify any unauthorized changes or additional malicious files that may have been introduced. +- Implement stricter access controls and monitoring on AWS credentials within containers, ensuring they are stored securely and accessed only by authorized processes. +- Escalate the incident to the cloud security team to assess the potential impact on the broader cloud environment and determine if further investigation or response is needed. +- Enhance logging and monitoring for similar activities across other containers and cloud environments to detect and respond to future attempts promptly. +- Review and update container security policies to include best practices for credential management and access control, reducing the risk of similar incidents.""" [[rule.threat]] diff --git a/rules/integrations/cloud_defend/credential_access_collection_sensitive_files_compression_inside_a_container.toml b/rules/integrations/cloud_defend/credential_access_collection_sensitive_files_compression_inside_a_container.toml index ad37dcc18f5..e4a7b35c05e 100644 --- a/rules/integrations/cloud_defend/credential_access_collection_sensitive_files_compression_inside_a_container.toml +++ b/rules/integrations/cloud_defend/credential_access_collection_sensitive_files_compression_inside_a_container.toml @@ -2,7 +2,7 @@ creation_date = "2023/05/12" integration = ["cloud_defend"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -64,6 +64,41 @@ and process.args: ( "/etc/shadow", "/etc/gshadow") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Sensitive Files Compression Inside A Container + +Containers are lightweight, portable environments used to run applications consistently across different systems. Adversaries may exploit compression utilities within containers to gather and exfiltrate sensitive files, such as credentials and configuration files. The detection rule identifies suspicious compression activities by monitoring for specific utilities and file paths, flagging potential unauthorized data collection attempts. + +### Possible investigation steps + +- Review the process details to confirm the use of compression utilities such as zip, tar, gzip, hdiutil, or 7z within the container environment, focusing on the process.name and process.args fields. +- Examine the specific file paths listed in the process.args to determine if they include sensitive files like SSH keys, AWS credentials, or Docker configurations, which could indicate unauthorized data collection. +- Identify the container.id associated with the alert to gather more context about the container's purpose, owner, and any recent changes or deployments that might explain the activity. +- Check the event.type field for "start" to verify the timing of the process initiation and correlate it with any known legitimate activities or scheduled tasks within the container. +- Investigate the user or service account under which the process was executed to assess whether it has the necessary permissions and if the activity aligns with expected behavior for that account. +- Look for any related alerts or logs that might indicate a broader pattern of suspicious activity within the same container or across other containers in the environment. + +### False positive analysis + +- Routine backup operations may trigger the rule if they involve compressing sensitive files for storage. To handle this, identify and exclude backup processes or scripts that are known and trusted. +- Automated configuration management tools might compress configuration files as part of their normal operation. Exclude these tools by specifying their process names or paths in the exception list. +- Developers or system administrators might compress sensitive files during legitimate troubleshooting or maintenance activities. Establish a process to log and review these activities, and exclude them if they are verified as non-threatening. +- Continuous integration and deployment pipelines could involve compressing configuration files for deployment purposes. Identify these pipelines and exclude their associated processes to prevent false positives. +- Security tools that perform regular audits or scans might compress files for analysis. Ensure these tools are recognized and excluded from triggering the rule. + +### Response and remediation + +- Immediately isolate the affected container to prevent further data exfiltration or unauthorized access. This can be done by stopping the container or disconnecting it from the network. +- Conduct a thorough review of the compressed files and their contents to assess the extent of sensitive data exposure. Focus on the specific file paths identified in the alert. +- Change credentials and keys that may have been compromised, including SSH keys, AWS credentials, and Docker configurations. Ensure that new credentials are distributed securely. +- Review and update access controls and permissions for sensitive files within containers to minimize exposure. Ensure that only necessary processes and users have access to these files. +- Implement monitoring and alerting for similar compression activities in other containers to detect potential threats early. Use the identified process names and arguments as indicators. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected. +- Conduct a post-incident review to identify gaps in security controls and update container security policies to prevent recurrence.""" [[rule.threat]] diff --git a/rules/integrations/cloud_defend/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml b/rules/integrations/cloud_defend/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml index dc8fd0b0b06..1dc5c0c213c 100644 --- a/rules/integrations/cloud_defend/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml +++ b/rules/integrations/cloud_defend/credential_access_sensitive_keys_or_passwords_search_inside_a_container.toml @@ -2,7 +2,7 @@ creation_date = "2023/05/12" integration = ["cloud_defend"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -46,6 +46,41 @@ or and process.args : ("*id_rsa*", "*id_dsa*") )) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Sensitive Keys Or Passwords Searched For Inside A Container + +Containers encapsulate applications, providing isolated environments. Adversaries may exploit search utilities like grep or find to locate sensitive credentials within containers, potentially leading to unauthorized access or container escape. The detection rule identifies suspicious searches for private keys or passwords, flagging potential credential access attempts by monitoring process activities and arguments. + +### Possible investigation steps + +- Review the process details to identify the specific container where the search activity occurred, using the container.id field to gather context about the environment. +- Examine the process.name and process.args fields to determine the exact command executed and assess whether it aligns with typical usage patterns or indicates malicious intent. +- Check the user context under which the process was executed to understand if the activity was performed by a legitimate user or an unauthorized entity. +- Investigate the container's recent activity logs to identify any other suspicious behavior or anomalies that might correlate with the search for sensitive keys or passwords. +- Assess the potential impact by determining if any sensitive files, such as private keys or password files, were accessed or exfiltrated following the search activity. +- If possible, correlate the event with network logs to identify any outbound connections that might suggest data exfiltration attempts. + +### False positive analysis + +- Routine administrative tasks may trigger the rule when system administrators use grep or find to audit or manage SSH keys and passwords within containers. To mitigate this, create exceptions for known administrative scripts or processes that regularly perform these tasks. +- Automated backup or configuration management tools might search for sensitive files as part of their normal operation. Identify these tools and exclude their process IDs or specific command patterns from triggering the rule. +- Security scanning tools that check for the presence of sensitive files could be flagged. Whitelist these tools by their process names or arguments to prevent false positives. +- Developers or DevOps personnel might use search utilities during debugging or development processes. Establish a list of trusted users or roles and exclude their activities from the rule to reduce noise. +- Continuous integration/continuous deployment (CI/CD) pipelines may include steps that search for keys or passwords for validation purposes. Exclude these pipeline processes by identifying their unique process arguments or container IDs. + +### Response and remediation + +- Immediately isolate the affected container to prevent further unauthorized access or potential container escape to the host system. This can be done by stopping the container or disconnecting it from the network. +- Conduct a thorough review of the container's logs and process activities to identify any unauthorized access or data exfiltration attempts. Pay special attention to the processes and arguments flagged by the detection rule. +- Rotate any potentially compromised credentials, including SSH keys and passwords, that were stored or accessed within the container. Ensure that new credentials are securely stored and managed. +- Assess the container's configuration and access controls to identify and rectify any security misconfigurations that may have allowed the unauthorized search for sensitive information. +- Implement additional monitoring and alerting for similar suspicious activities across other containers and the host environment to detect and respond to potential threats promptly. +- Escalate the incident to the security operations team for further investigation and to determine if the threat has spread beyond the initial container. +- Review and update container security policies and practices to prevent recurrence, including enforcing least privilege access and using secrets management solutions to handle sensitive information securely.""" [[rule.threat]] diff --git a/rules/integrations/cloud_defend/defense_evasion_ld_preload_shared_object_modified_inside_a_container.toml b/rules/integrations/cloud_defend/defense_evasion_ld_preload_shared_object_modified_inside_a_container.toml index 14581165c8e..21eddfa9402 100644 --- a/rules/integrations/cloud_defend/defense_evasion_ld_preload_shared_object_modified_inside_a_container.toml +++ b/rules/integrations/cloud_defend/defense_evasion_ld_preload_shared_object_modified_inside_a_container.toml @@ -2,7 +2,7 @@ creation_date = "2023/06/06" integration = ["cloud_defend"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -34,6 +34,41 @@ type = "eql" query = ''' file where event.module== "cloud_defend" and event.type != "deletion" and file.path== "/etc/ld.so.preload" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Modification of Dynamic Linker Preload Shared Object Inside A Container + +The dynamic linker in Linux loads necessary libraries for programs at runtime, with the `ld.so.preload` file specifying libraries to load first. Adversaries exploit this by redirecting it to malicious libraries, gaining unauthorized access and evading detection. The detection rule identifies suspicious modifications to this file within containers, signaling potential hijacking attempts. + +### Possible investigation steps + +- Review the alert details to confirm the file path involved is "/etc/ld.so.preload" and the event type is not "deletion", as specified in the query. +- Examine the container's metadata and context to identify the specific container where the modification occurred, including container ID, image, and host details. +- Investigate recent changes to the "/etc/ld.so.preload" file within the container by checking the file's modification history and identifying the user or process responsible for the change. +- Analyze the contents of the modified "/etc/ld.so.preload" file to determine if it references any suspicious or unauthorized libraries. +- Correlate the event with other security logs and alerts to identify any related suspicious activities or patterns, such as unauthorized access attempts or execution of unknown processes within the container. +- Assess the potential impact of the modification by evaluating the libraries listed in the preload file and their potential to grant unauthorized access or evade detection. +- Consider isolating the affected container to prevent further unauthorized access or malicious activity while the investigation is ongoing. + +### False positive analysis + +- Routine system updates or maintenance activities may modify the ld.so.preload file. Users should verify if the changes coincide with scheduled updates and consider excluding these events if they are confirmed to be benign. +- Some containerized applications might legitimately modify the ld.so.preload file to optimize performance or load specific libraries. Users should identify these applications and create exceptions for their known behaviors to prevent false alerts. +- Automated configuration management tools might alter the ld.so.preload file as part of their normal operations. Users should review the tool's activity logs and whitelist these actions if they are consistent with expected behavior. +- Development or testing environments often involve frequent changes to system files, including ld.so.preload. Users should differentiate between production and non-production environments and apply more lenient rules to the latter to reduce false positives. + +### Response and remediation + +- Immediately isolate the affected container to prevent further unauthorized access or execution of malicious code. This can be done by stopping the container or disconnecting it from the network. +- Conduct a thorough review of the `/etc/ld.so.preload` file within the container to identify any unauthorized or malicious entries. Remove any entries that are not recognized or are confirmed to be malicious. +- Verify the integrity of the container's base image and all installed libraries to ensure no other components have been tampered with. Rebuild the container from a trusted image if necessary. +- Implement monitoring and alerting for any future modifications to the `/etc/ld.so.preload` file across all containers to detect similar threats promptly. +- Review and tighten access controls and permissions for container environments to minimize the risk of unauthorized modifications to critical system files. +- Escalate the incident to the security operations team for further investigation and to determine if the threat has spread to other parts of the infrastructure. +- Document the incident, including the steps taken for containment and remediation, to improve response strategies and update incident response plans for future reference.""" [[rule.threat]] diff --git a/rules/integrations/cloud_defend/discovery_suspicious_network_tool_launched_inside_a_container.toml b/rules/integrations/cloud_defend/discovery_suspicious_network_tool_launched_inside_a_container.toml index bb9fab55b3f..7606594d94a 100644 --- a/rules/integrations/cloud_defend/discovery_suspicious_network_tool_launched_inside_a_container.toml +++ b/rules/integrations/cloud_defend/discovery_suspicious_network_tool_launched_inside_a_container.toml @@ -2,7 +2,7 @@ creation_date = "2023/04/26" integration = ["cloud_defend"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -48,6 +48,40 @@ process where container.id: "*" and event.type== "start" and (process.args: ("nc", "ncat", "nmap", "dig", "nslookup", "tcpdump", "tshark", "ngrep", "telnet", "mitmproxy", "socat", "zmap", "masscan", "zgrab")) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Network Tool Launched Inside A Container + +Containers are lightweight, portable units that encapsulate applications and their dependencies, often used to ensure consistent environments across development and production. Adversaries exploit network tools within containers for reconnaissance or lateral movement, leveraging utilities like `nc` or `nmap` to map networks or intercept traffic. The detection rule identifies these tools' execution by monitoring process starts and arguments, flagging potential misuse for further investigation. + +### Possible investigation steps + +- Review the container ID and process name from the alert to identify which container and network tool triggered the alert. +- Examine the process arguments to understand the specific command or options used, which may provide insight into the intent of the tool's execution. +- Check the container's creation and modification timestamps to determine if the container was recently deployed or altered, which could indicate suspicious activity. +- Investigate the user or service account associated with the process start event to assess if it aligns with expected behavior or if it might be compromised. +- Analyze network logs and traffic patterns from the container to identify any unusual outbound connections or data exfiltration attempts. +- Correlate the alert with other security events or logs from the same container or host to identify potential lateral movement or further malicious activity. + +### False positive analysis + +- Development and testing environments often use network tools for legitimate purposes such as debugging or network configuration. To manage this, create exceptions for containers identified as part of these environments by tagging them appropriately and excluding them from the rule. +- Automated scripts or orchestration tools may trigger network utilities for routine checks or maintenance tasks. Identify these scripts and whitelist their associated container IDs or process names to prevent false alerts. +- Some monitoring solutions deploy containers with built-in network tools for performance analysis. Verify the legitimacy of these containers and exclude them from the rule by using specific labels or container IDs. +- Containers used for educational or training purposes might intentionally run network tools. Ensure these containers are marked and excluded from detection by setting up rules based on their unique identifiers or labels. + +### Response and remediation + +- Immediately isolate the affected container to prevent further network reconnaissance or lateral movement. This can be done by restricting its network access or stopping the container entirely. +- Conduct a thorough review of the container's logs and process history to identify any unauthorized access or data exfiltration attempts. Focus on the execution of the flagged network utilities. +- Remove any unauthorized or suspicious network tools from the container to prevent further misuse. Ensure that only necessary and approved utilities are present. +- Patch and update the container image to address any vulnerabilities that may have been exploited. Rebuild and redeploy the container using the updated image. +- Implement network segmentation to limit the container's access to sensitive resources and reduce the potential impact of similar threats in the future. +- Enhance monitoring and alerting for the execution of network utilities within containers, ensuring that any future occurrences are detected promptly. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or containers have been compromised.""" [[rule.threat]] diff --git a/rules/integrations/cloud_defend/execution_container_management_binary_launched_inside_a_container.toml b/rules/integrations/cloud_defend/execution_container_management_binary_launched_inside_a_container.toml index 24a7ee25a08..802e409051a 100644 --- a/rules/integrations/cloud_defend/execution_container_management_binary_launched_inside_a_container.toml +++ b/rules/integrations/cloud_defend/execution_container_management_binary_launched_inside_a_container.toml @@ -2,7 +2,7 @@ creation_date = "2023/04/26" integration = ["cloud_defend"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -42,6 +42,41 @@ query = ''' process where container.id: "*" and event.type== "start" and process.name: ("dockerd", "docker", "kubelet", "kube-proxy", "kubectl", "containerd", "runc", "systemd", "crictl") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Container Management Utility Run Inside A Container + +Container management utilities like Docker and Kubernetes are essential for orchestrating and managing containerized applications. They facilitate tasks such as deployment, scaling, and networking. However, adversaries can exploit these tools to execute unauthorized commands within containers, potentially leading to system compromise. The detection rule identifies suspicious execution of these utilities within containers, signaling possible misuse or misconfiguration, by monitoring specific process activities and event types. + +### Possible investigation steps + +- Review the specific container ID where the suspicious process was executed to determine its purpose and origin. +- Examine the process name and command line arguments to understand the context of the execution and identify any anomalies or unauthorized commands. +- Check the user and permissions associated with the process to assess if it aligns with expected roles and access levels for container management tasks. +- Investigate the container's creation and deployment history to identify any recent changes or deployments that could explain the presence of the management utility. +- Analyze network activity associated with the container to detect any unusual connections or data transfers that might indicate malicious activity. +- Correlate the event with other security alerts or logs to identify patterns or related incidents that could provide additional context or evidence of compromise. + +### False positive analysis + +- Routine maintenance tasks within containers can trigger the rule. Exclude known maintenance scripts or processes by adding them to an allowlist if they frequently execute container management utilities. +- Development and testing environments often run container management commands for legitimate purposes. Consider excluding these environments from monitoring or adjust the rule to focus on production environments only. +- Automated deployment tools may execute container management commands as part of their workflow. Identify these tools and create exceptions for their activities to prevent false positives. +- System updates or patches might involve running container management utilities. Monitor update schedules and temporarily adjust the rule to avoid unnecessary alerts during these periods. +- Legitimate administrative actions by authorized personnel can trigger the rule. Implement user-based exceptions for known administrators to reduce false positives while maintaining security oversight. + +### Response and remediation + +- Immediately isolate the affected container to prevent further unauthorized access or execution of commands. This can be done by stopping the container or disconnecting it from the network. +- Review the container's configuration and access controls to identify any misconfigurations or unauthorized access permissions that may have allowed the execution of container management utilities. +- Conduct a thorough analysis of the container's logs and process activities to determine the extent of the compromise and identify any additional malicious activities or lateral movement attempts. +- Remove any unauthorized or suspicious binaries and scripts from the container to prevent further exploitation. +- Patch and update the container image and underlying host system to address any known vulnerabilities that may have been exploited. +- Implement stricter access controls and monitoring on container management utilities to ensure they are only accessible by authorized users and processes. +- Escalate the incident to the security operations team for further investigation and to assess the need for broader security measures across the container environment.""" [[rule.threat]] diff --git a/rules/integrations/cloud_defend/execution_file_made_executable_via_chmod_inside_a_container.toml b/rules/integrations/cloud_defend/execution_file_made_executable_via_chmod_inside_a_container.toml index 64fb497ec44..8d6d75577e3 100644 --- a/rules/integrations/cloud_defend/execution_file_made_executable_via_chmod_inside_a_container.toml +++ b/rules/integrations/cloud_defend/execution_file_made_executable_via_chmod_inside_a_container.toml @@ -2,7 +2,7 @@ creation_date = "2023/04/26" integration = ["cloud_defend"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -38,6 +38,41 @@ file where container.id: "*" and event.type in ("change", "creation") and (process.name : "chmod" or process.args : "chmod") and process.args : ("*x*", "777", "755", "754", "700") and not process.args: "-x" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Made Executable via Chmod Inside A Container + +Containers provide isolated environments for running applications, often on Linux systems. The `chmod` command is used to change file permissions, including making files executable. Adversaries may exploit this by altering permissions to execute unauthorized scripts or binaries, potentially leading to malicious activity. The detection rule identifies such actions by monitoring for `chmod` usage that grants execute permissions, focusing on specific permission patterns, and excluding benign cases. This helps in identifying potential threats where attackers attempt to execute unauthorized code within containers. + +### Possible investigation steps + +- Review the container ID associated with the alert to identify the specific container where the `chmod` command was executed. +- Examine the process arguments to determine the exact permissions that were set and identify the file that was made executable. +- Investigate the origin of the `chmod` command by reviewing the process tree to understand which parent process initiated it and whether it aligns with expected behavior. +- Check the user account or service account that executed the `chmod` command to assess if it has legitimate access and reason to modify file permissions. +- Analyze the file that was made executable to determine its contents and origin, checking for any signs of unauthorized or malicious code. +- Correlate this event with other logs or alerts from the same container to identify any patterns or additional suspicious activities that might indicate a broader attack. + +### False positive analysis + +- Routine maintenance scripts or automated processes may use chmod to set execute permissions on files within containers. To handle these, identify and whitelist specific scripts or processes that are known to be safe and necessary for operations. +- Development environments often involve frequent changes to file permissions as developers test and deploy code. Consider excluding specific container IDs or paths associated with development environments to reduce noise. +- Some container orchestration tools might use chmod as part of their normal operation. Review the processes and arguments associated with these tools and create exceptions for known benign activities. +- System updates or package installations within containers might trigger this rule. Monitor and document regular update schedules and processes, and exclude these from triggering alerts if they are verified as non-threatening. +- If certain users or roles are responsible for legitimate permission changes, consider excluding their activities by user ID or role, ensuring that these exclusions are well-documented and reviewed regularly. + +### Response and remediation + +- Immediately isolate the affected container to prevent further execution of unauthorized code. This can be done by stopping the container or disconnecting it from the network. +- Conduct a thorough review of the container's file system to identify any unauthorized or suspicious files that have been made executable. Remove or quarantine these files as necessary. +- Analyze the container's logs to trace the source of the `chmod` command and determine if there are any other indicators of compromise or related malicious activities. +- If the unauthorized execution is confirmed, assess the potential impact on the host system and other containers. Implement additional security measures, such as enhanced monitoring or network segmentation, to protect other assets. +- Escalate the incident to the security operations team for further investigation and to determine if the threat is part of a larger attack campaign. +- Review and update container security policies to prevent unauthorized permission changes, such as implementing stricter access controls and using security tools that enforce policy compliance. +- Enhance detection capabilities by configuring alerts for similar suspicious activities, ensuring that any future attempts to modify file permissions within containers are promptly identified and addressed.""" [[rule.threat]] diff --git a/rules/integrations/cloud_defend/execution_interactive_exec_to_container.toml b/rules/integrations/cloud_defend/execution_interactive_exec_to_container.toml index 16de26f880e..f3ed4d5f336 100644 --- a/rules/integrations/cloud_defend/execution_interactive_exec_to_container.toml +++ b/rules/integrations/cloud_defend/execution_interactive_exec_to_container.toml @@ -2,7 +2,7 @@ creation_date = "2023/05/12" integration = ["cloud_defend"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -58,6 +58,42 @@ process.entry_leader.same_as_process== true and /* interactive process */ process.interactive == true ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Interactive Exec Command Launched Against A Running Container + +In containerized environments, the 'exec' command is used to run processes inside a running container, often for debugging or administrative tasks. Adversaries may exploit this to gain shell access, potentially leading to further compromise or container escape. The detection rule identifies such activities by monitoring for interactive 'exec' sessions, focusing on initial processes within containers, and flagging high-risk interactions. + +### Possible investigation steps + +- Review the container.id to identify which specific container the interactive exec command was executed against and gather information about its purpose and criticality. +- Examine the process.entry_leader.entry_meta.type to confirm that the process was indeed initiated within a container environment, ensuring the context of the alert is accurate. +- Investigate the process.entry_leader.same_as_process field to verify that the process in question is the initial process run in the container, which may indicate a new or unexpected session. +- Analyze the process.interactive field to understand the nature of the interaction and determine if it aligns with expected administrative activities or if it suggests unauthorized access. +- Check for any recent changes or deployments in the container environment that might explain the interactive session, such as updates or debugging activities. +- Correlate the event with user activity logs to identify the user or service account responsible for initiating the exec command and assess their access permissions and recent actions. +- Investigate any subsequent actions or commands executed within the container following the interactive session to identify potential malicious activities or attempts at container breakout. + +### False positive analysis + +- Routine administrative tasks may trigger the rule when system administrators use 'kubectl exec' for legitimate maintenance or debugging. To manage this, create exceptions for known administrator accounts or specific maintenance windows. +- Automated scripts or monitoring tools that use 'exec' for health checks or logging purposes can also cause false positives. Identify these scripts and exclude their associated processes or user accounts from triggering the rule. +- Development and testing activities often involve frequent use of 'exec' commands for container interaction. Consider excluding specific development environments or user roles from the rule to reduce noise. +- Continuous integration/continuous deployment (CI/CD) pipelines might use 'exec' to deploy or test applications within containers. Exclude these pipeline processes or service accounts to prevent false alerts. +- If certain containers are known to require frequent interactive access for legitimate reasons, consider tagging these containers and configuring the rule to ignore interactions with them. + +### Response and remediation + +- Immediately isolate the affected container to prevent further unauthorized access or potential lateral movement within the environment. This can be done by pausing or stopping the container. +- Review and terminate any unauthorized or suspicious interactive sessions identified by the alert to cut off the adversary's access. +- Conduct a thorough analysis of the container's filesystem and running processes to identify any malicious scripts or binaries that may have been introduced during the interactive session. +- Revert the container to a known good state by redeploying it from a trusted image, ensuring that any potential backdoors or malicious modifications are removed. +- Implement network segmentation and access controls to limit the ability of users to execute 'exec' commands on containers, especially for high-risk or production environments. +- Escalate the incident to the security operations team for further investigation and to determine if additional containers or systems have been compromised. +- Enhance monitoring and alerting for similar activities by ensuring that all interactive 'exec' commands are logged and reviewed, and consider implementing stricter access controls for container management tools like kubectl.""" [[rule.threat]] diff --git a/rules/integrations/cloud_defend/execution_interactive_shell_spawned_from_inside_a_container.toml b/rules/integrations/cloud_defend/execution_interactive_shell_spawned_from_inside_a_container.toml index 55c5ccec6c3..3582617b6ba 100644 --- a/rules/integrations/cloud_defend/execution_interactive_shell_spawned_from_inside_a_container.toml +++ b/rules/integrations/cloud_defend/execution_interactive_shell_spawned_from_inside_a_container.toml @@ -2,7 +2,7 @@ creation_date = "2023/04/26" integration = ["cloud_defend"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -47,6 +47,40 @@ event.action in ("fork", "exec") and event.action != "end" process.args: "*/*sh" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Interactive Shell Spawned From Inside A Container + +Containers are lightweight, portable units that encapsulate applications and their dependencies, often used to ensure consistent environments across development and production. Adversaries may exploit containers by spawning interactive shells to execute unauthorized commands, potentially leading to container escape and host compromise. The detection rule identifies such threats by monitoring for shell processes initiated within containers, focusing on specific process actions and arguments indicative of interactive sessions. + +### Possible investigation steps + +- Review the alert details to identify the specific container ID where the interactive shell was spawned. This will help in isolating the affected container for further analysis. +- Examine the process executable and arguments, particularly looking for shell types and interactive flags (e.g., "-i", "-it"), to understand the nature of the shell session initiated. +- Check the process entry leader to determine if the shell process is part of a larger process tree, which might indicate a more complex attack chain or script execution. +- Investigate the user context under which the shell was spawned to assess if it aligns with expected user behavior or if it indicates potential unauthorized access. +- Analyze recent logs and events from the container and host to identify any preceding suspicious activities or anomalies that might have led to the shell spawning. +- Correlate the event with other security alerts or incidents to determine if this is part of a broader attack pattern or campaign targeting the environment. + +### False positive analysis + +- Development and testing activities may trigger this rule when developers intentionally spawn interactive shells within containers for debugging or configuration purposes. To manage this, create exceptions for specific user accounts or container IDs frequently used in development environments. +- Automated scripts or orchestration tools that use interactive shells for legitimate tasks can also cause false positives. Identify these scripts and exclude their associated process names or arguments from the rule. +- Some container management platforms might use interactive shells as part of their normal operations. Review the processes and arguments used by these platforms and add them to an exception list if they are known to be safe. +- Regular maintenance tasks that require interactive shell access, such as system updates or configuration changes, can be excluded by scheduling these tasks during known maintenance windows and temporarily adjusting the rule settings. + +### Response and remediation + +- Immediately isolate the affected container to prevent further unauthorized access or potential container escape. This can be done by stopping the container or disconnecting it from the network. +- Capture and preserve forensic data from the container, including logs, process lists, and network activity, to aid in further investigation and understanding of the attack vector. +- Conduct a thorough review of the container's configuration and permissions to identify and rectify any misconfigurations or vulnerabilities that may have been exploited. +- Patch and update the container image and any associated software to address known vulnerabilities that could have been leveraged by the attacker. +- Implement stricter access controls and monitoring on container environments to prevent unauthorized shell access, such as using role-based access controls and enabling audit logging. +- Escalate the incident to the security operations team for further analysis and to determine if the threat has spread to other parts of the infrastructure. +- Review and enhance detection capabilities to identify similar threats in the future, ensuring that alerts are tuned to detect unauthorized shell access attempts promptly.""" [[rule.threat]] diff --git a/rules/integrations/cloud_defend/execution_netcat_listener_established_inside_a_container.toml b/rules/integrations/cloud_defend/execution_netcat_listener_established_inside_a_container.toml index c739bdcdcbf..50baf63647d 100644 --- a/rules/integrations/cloud_defend/execution_netcat_listener_established_inside_a_container.toml +++ b/rules/integrations/cloud_defend/execution_netcat_listener_established_inside_a_container.toml @@ -2,7 +2,7 @@ creation_date = "2023/04/26" integration = ["cloud_defend"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -52,6 +52,40 @@ process.args: ("nc","ncat","netcat","netcat.openbsd","netcat.traditional") or process.args:("-*l*", "--listen", "-*p*", "--source-port") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Netcat Listener Established Inside A Container + +Netcat is a versatile networking tool used for reading and writing data across network connections, often employed for legitimate purposes like debugging and network diagnostics. However, adversaries can exploit Netcat to establish unauthorized backdoors or exfiltrate data from containers. The detection rule identifies suspicious Netcat activity by monitoring process events within containers, focusing on specific arguments that indicate a listening state, which is a common trait of malicious use. This proactive detection helps mitigate potential threats by flagging unusual network behavior indicative of compromise. + +### Possible investigation steps + +- Review the container ID associated with the alert to identify the specific container where the Netcat listener was established. This can help in understanding the context and potential impact. +- Examine the process name and arguments to confirm the presence of Netcat and its listening state. Look for arguments like "-l", "--listen", "-p", or "--source-port" to verify the listener setup. +- Check the parent process of the Netcat instance to determine how it was initiated. This can provide insights into whether it was started by a legitimate application or a potentially malicious script. +- Investigate the network connections associated with the container to identify any unusual or unauthorized connections that may indicate data exfiltration or communication with a command and control server. +- Analyze the container's recent activity and logs to identify any other suspicious behavior or anomalies that could be related to the Netcat listener, such as unexpected file modifications or other process executions. +- Assess the container's security posture and configuration to determine if there are any vulnerabilities or misconfigurations that could have been exploited to establish the Netcat listener. + +### False positive analysis + +- Development and testing activities within containers may trigger the rule if Netcat is used for legitimate debugging or network diagnostics. Users can create exceptions for specific container IDs or process names associated with known development environments. +- Automated scripts or tools that utilize Netcat for routine network checks or health monitoring might be flagged. To mitigate this, users can whitelist these scripts by identifying their unique process arguments or execution patterns. +- Containers running network services that rely on Netcat for legitimate communication purposes could be mistakenly identified. Users should document and exclude these services by specifying their container IDs and associated process arguments. +- Security tools or monitoring solutions that incorporate Netcat for legitimate scanning or testing purposes may cause false positives. Users can manage this by excluding these tools based on their known process names and arguments. + +### Response and remediation + +- Immediately isolate the affected container to prevent further unauthorized access or data exfiltration. This can be done by stopping the container or disconnecting it from the network. +- Conduct a thorough review of the container's logs and process history to identify any unauthorized access or data transfers that may have occurred. +- Remove any unauthorized Netcat binaries or scripts found within the container to eliminate the backdoor. +- Rebuild the container from a known good image to ensure no residual malicious artifacts remain. +- Update container images and underlying host systems with the latest security patches to mitigate vulnerabilities that could be exploited by similar threats. +- Implement network segmentation and firewall rules to restrict unauthorized outbound connections from containers, reducing the risk of data exfiltration. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other containers or systems within the environment.""" [[rule.threat]] diff --git a/rules/integrations/cloud_defend/initial_access_ssh_connection_established_inside_a_container.toml b/rules/integrations/cloud_defend/initial_access_ssh_connection_established_inside_a_container.toml index d4cdae3dcc6..dd3a14b5e6e 100644 --- a/rules/integrations/cloud_defend/initial_access_ssh_connection_established_inside_a_container.toml +++ b/rules/integrations/cloud_defend/initial_access_ssh_connection_established_inside_a_container.toml @@ -2,7 +2,7 @@ creation_date = "2023/05/12" integration = ["cloud_defend"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -52,6 +52,41 @@ process.entry_leader.entry_meta.type: "sshd" and /* interactive process*/ process.interactive== true ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Connection Established Inside A Running Container + +SSH (Secure Shell) is a protocol used to securely access and manage systems remotely. In containerized environments, running an SSH daemon is generally discouraged due to security risks. Adversaries may exploit SSH to gain unauthorized access or maintain persistence within a compromised container. The detection rule identifies SSH connections initiated within containers by monitoring for SSH daemon processes that start new sessions, indicating potential unauthorized access attempts. This rule is crucial for identifying and mitigating threats related to initial access and lateral movement within containerized environments. + +### Possible investigation steps + +- Review the container ID associated with the alert to identify the specific container where the SSH connection was established. +- Examine the process details, particularly focusing on the entry leader and session leader fields, to determine if the SSH daemon process is the initial process or part of a new session within the container. +- Check for any interactive sessions initiated by the SSH daemon to confirm if the connection was actively used for interaction. +- Investigate the source of the SSH connection by analyzing network logs or connection details to identify the originating IP address and assess if it is known or suspicious. +- Correlate the event with user activity logs to determine if the SSH connection aligns with expected user behavior or if it indicates potential unauthorized access. +- Assess the container's configuration and security posture to understand why an SSH daemon is running and evaluate if it is necessary or a security oversight. +- Review any recent changes or deployments related to the container to identify potential vulnerabilities or misconfigurations that could have been exploited. + +### False positive analysis + +- Legitimate administrative access to containers via SSH may trigger the rule. To manage this, create exceptions for known administrative IP addresses or user accounts that regularly access containers for maintenance. +- Automated scripts or tools that use SSH for legitimate purposes, such as configuration management or deployment, can cause false positives. Identify these tools and exclude their specific process signatures or user accounts from the rule. +- Development or testing environments where SSH is used for debugging or monitoring may also trigger alerts. Consider excluding these environments by tagging them appropriately and adjusting the rule to ignore these tags. +- Containers running legacy applications that require SSH for functionality might be flagged. Document these applications and create exceptions based on their specific container IDs or hostnames. + +### Response and remediation + +- Immediately isolate the affected container to prevent further unauthorized access or lateral movement within the environment. +- Terminate the SSH daemon process running inside the container to cut off any active unauthorized sessions. +- Conduct a thorough review of access logs and container activity to identify any unauthorized access attempts or suspicious behavior. +- Revoke any compromised credentials and enforce a password reset for affected accounts to prevent further unauthorized access. +- Deploy updated container images without SSH daemons and ensure that future container deployments adhere to security best practices. +- Implement network segmentation to limit access to containerized environments and reduce the attack surface for similar threats. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on the broader environment.""" [[rule.threat]] diff --git a/rules/integrations/cloud_defend/lateral_movement_ssh_process_launched_inside_a_container.toml b/rules/integrations/cloud_defend/lateral_movement_ssh_process_launched_inside_a_container.toml index 5ed644ebed5..a0e12e805cb 100644 --- a/rules/integrations/cloud_defend/lateral_movement_ssh_process_launched_inside_a_container.toml +++ b/rules/integrations/cloud_defend/lateral_movement_ssh_process_launched_inside_a_container.toml @@ -2,7 +2,7 @@ creation_date = "2023/05/12" integration = ["cloud_defend"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -47,6 +47,41 @@ process where container.id: "*" and event.type== "start" and event.action in ("fork", "exec") and event.action != "end" and process.name: ("sshd", "ssh", "autossh") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Process Launched From Inside A Container + +SSH (Secure Shell) is a protocol used for secure remote access and management of systems. Within container environments, SSH usage is atypical and can signal potential security risks. Adversaries may exploit SSH to move laterally between containers or escape to the host system. The detection rule identifies SSH processes initiated within containers, flagging potential unauthorized access or persistence attempts by monitoring process events and container identifiers. + +### Possible investigation steps + +- Review the container identifier (container.id) associated with the SSH process to determine which container initiated the process and assess its intended function. +- Examine the process start event details, including the process name (sshd, ssh, autossh) and event actions (fork, exec), to understand the context and nature of the SSH activity. +- Check for any recent changes or deployments related to the container to identify if the SSH process aligns with expected behavior or recent updates. +- Investigate the source and destination of the SSH connection to determine if it involves unauthorized or suspicious endpoints, potentially indicating lateral movement or an attempt to access the host system. +- Analyze user accounts and credentials used in the SSH session to verify if they are legitimate and authorized for container access, looking for signs of compromised credentials. +- Correlate the SSH activity with other security events or alerts to identify patterns or additional indicators of compromise within the container environment. + +### False positive analysis + +- Development and testing environments may intentionally use SSH for debugging or administrative tasks. Users can create exceptions for specific container IDs or hostnames associated with these environments to reduce noise. +- Automated scripts or orchestration tools might use SSH to manage containers. Identify these tools and exclude their process IDs or user accounts from triggering the rule. +- Some legacy applications might rely on SSH for internal communication. Review these applications and whitelist their specific process names or container images to prevent false alerts. +- Containers running SSH for legitimate remote access purposes, such as maintenance, should be documented. Exclude these containers by their unique identifiers or labels to avoid unnecessary alerts. +- Regularly review and update the exclusion list to ensure it aligns with current operational practices and does not inadvertently allow malicious activity. + +### Response and remediation + +- Immediately isolate the affected container to prevent potential lateral movement or further unauthorized access. This can be done by stopping the container or disconnecting it from the network. +- Conduct a thorough review of the container's logs and environment to identify any unauthorized access or changes. Pay special attention to SSH-related logs and any anomalies in user activity. +- Revoke any SSH keys or credentials that may have been compromised. Ensure that all SSH keys used within the container environment are rotated and that access is restricted to only necessary personnel. +- Assess the container image and configuration for vulnerabilities or misconfigurations that may have allowed the SSH process to be initiated. Patch any identified vulnerabilities and update the container image accordingly. +- Implement network segmentation to limit the ability of containers to communicate with each other and the host system, reducing the risk of lateral movement. +- Enhance monitoring and alerting for SSH activity within container environments to ensure rapid detection of similar threats in the future. This includes setting up alerts for any SSH process initiation within containers. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or containers have been affected.""" [[rule.threat]] diff --git a/rules/integrations/cloud_defend/persistence_ssh_authorized_keys_modification_inside_a_container.toml b/rules/integrations/cloud_defend/persistence_ssh_authorized_keys_modification_inside_a_container.toml index 30220e18f92..edd4637f770 100644 --- a/rules/integrations/cloud_defend/persistence_ssh_authorized_keys_modification_inside_a_container.toml +++ b/rules/integrations/cloud_defend/persistence_ssh_authorized_keys_modification_inside_a_container.toml @@ -2,7 +2,7 @@ creation_date = "2023/05/12" integration = ["cloud_defend"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -36,6 +36,41 @@ query = ''' file where container.id:"*" and event.type in ("change", "creation") and file.name: ("authorized_keys", "authorized_keys2", "sshd_config") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Modified Inside a Container + +In containerized environments, SSH keys facilitate secure access, but adversaries can exploit this by altering the authorized_keys file to gain unauthorized access. This detection rule identifies suspicious changes to SSH configuration files within containers, signaling potential persistence tactics. By monitoring file modifications, it helps detect unauthorized SSH usage, a common indicator of compromise. + +### Possible investigation steps + +- Review the container ID associated with the alert to identify the specific container where the modification occurred. +- Examine the timestamp of the event to determine when the file change or creation took place and correlate it with any known activities or changes in the environment. +- Investigate the user account or process that made the modification to the authorized_keys or sshd_config file to assess if it was an authorized action. +- Check for any recent SSH connections to the container, especially those using public key authentication, to identify potential unauthorized access. +- Analyze the contents of the modified authorized_keys or sshd_config file to identify any suspicious or unauthorized keys or configurations. +- Review the container's logs and any related network activity around the time of the modification for signs of compromise or lateral movement attempts. + +### False positive analysis + +- Routine updates or deployments within containers may modify SSH configuration files, leading to false positives. To manage this, create exceptions for known update processes or deployment scripts that regularly alter these files. +- Automated configuration management tools like Ansible or Puppet might change SSH files as part of their normal operation. Identify these tools and exclude their activities from triggering alerts by specifying their process IDs or user accounts. +- Development or testing environments often see frequent changes to SSH keys for legitimate reasons. Consider excluding these environments from the rule or setting up a separate, less sensitive monitoring profile for them. +- Scheduled maintenance tasks that involve SSH key rotation can trigger alerts. Document these tasks and schedule exceptions during their execution windows to prevent unnecessary alerts. +- Container orchestration systems might modify SSH configurations as part of scaling or updating services. Recognize these patterns and adjust the rule to ignore changes made by these systems. + +### Response and remediation + +- Immediately isolate the affected container to prevent further unauthorized access or lateral movement within the environment. +- Revoke any unauthorized SSH keys found in the authorized_keys file to cut off the adversary's access. +- Conduct a thorough review of all SSH configuration files within the container to ensure no additional unauthorized modifications have been made. +- Restore the container from a known good backup if available, ensuring that the backup does not contain the unauthorized changes. +- Implement stricter access controls and monitoring on SSH usage within containers to prevent similar incidents in the future. +- Escalate the incident to the security operations team for further investigation and to determine if other containers or systems have been compromised. +- Update detection and alerting mechanisms to include additional indicators of compromise related to SSH key manipulation and unauthorized access attempts.""" [[rule.threat]] diff --git a/rules/integrations/cloud_defend/privilege_escalation_debugfs_launched_inside_a_privileged_container.toml b/rules/integrations/cloud_defend/privilege_escalation_debugfs_launched_inside_a_privileged_container.toml index 84a94f11ed9..b8300c89e9b 100644 --- a/rules/integrations/cloud_defend/privilege_escalation_debugfs_launched_inside_a_privileged_container.toml +++ b/rules/integrations/cloud_defend/privilege_escalation_debugfs_launched_inside_a_privileged_container.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/26" integration = ["cloud_defend"] maturity = "production" -updated_date = "2024/07/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -42,6 +42,40 @@ process where event.module == "cloud_defend" and process.args : "/dev/sd*" and not process.args == "-R" and container.security_context.privileged == true ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 System Debugger Launched Inside a Privileged Container + +DebugFS is a Linux utility for direct file system manipulation, often used for debugging. In a privileged container, which has extensive access to the host, adversaries can exploit DebugFS to access sensitive host files, potentially leading to privilege escalation or container escape. The detection rule identifies suspicious DebugFS usage by monitoring process initiation with specific arguments in privileged containers, flagging potential misuse. + +### Possible investigation steps + +- Review the alert details to confirm the process name is "debugfs" and check the specific arguments used, particularly looking for "/dev/sd*" to identify potential access to host file systems. +- Verify the container's security context to ensure it is indeed privileged, as this increases the risk of host-level access. +- Investigate the origin of the container image and deployment configuration to determine if the use of a privileged container was intentional or necessary. +- Check the user or service account that initiated the process to assess if it aligns with expected behavior or if it indicates potential unauthorized access. +- Examine recent logs and events from the container and host to identify any unusual activities or patterns that coincide with the alert. +- Assess the potential impact by identifying any sensitive files or directories that may have been accessed or modified by the debugfs process. + +### False positive analysis + +- Routine maintenance tasks using DebugFS in privileged containers can trigger alerts. To manage this, identify and document regular maintenance processes and create exceptions for these specific processes. +- Automated scripts or tools that utilize DebugFS for legitimate monitoring or debugging purposes may cause false positives. Review these scripts and whitelist them by excluding their specific process arguments or execution contexts. +- Development and testing environments often run privileged containers with DebugFS for debugging purposes. Establish a separate set of rules or exceptions for these environments to prevent unnecessary alerts. +- Backup or recovery operations that involve direct disk access might use DebugFS. Ensure these operations are well-documented and create exceptions based on their unique process signatures or execution schedules. + +### Response and remediation + +- Immediately isolate the affected container to prevent further access to sensitive host files. This can be done by stopping the container or removing its network access. +- Conduct a thorough review of the container's security context and capabilities to ensure it does not have unnecessary privileges. Adjust the container's configuration to remove privileged access if not required. +- Analyze the container's logs and process history to identify any unauthorized access or actions taken by the DebugFS utility. This will help determine the extent of the potential breach. +- If unauthorized access to host files is confirmed, perform a security assessment of the host system to identify any changes or breaches. This may include checking for new user accounts, modified files, or unexpected network connections. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. Provide them with all relevant logs and findings. +- Implement additional monitoring and alerting for similar activities across other containers and hosts to detect any recurrence of this threat. +- Review and update container deployment policies to enforce the principle of least privilege, ensuring containers only have the necessary permissions to perform their intended functions.""" [[rule.threat]] diff --git a/rules/integrations/cloud_defend/privilege_escalation_mount_launched_inside_a_privileged_container.toml b/rules/integrations/cloud_defend/privilege_escalation_mount_launched_inside_a_privileged_container.toml index b8ce04a318a..1a68d5bfeb2 100644 --- a/rules/integrations/cloud_defend/privilege_escalation_mount_launched_inside_a_privileged_container.toml +++ b/rules/integrations/cloud_defend/privilege_escalation_mount_launched_inside_a_privileged_container.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/26" integration = ["cloud_defend"] maturity = "production" -updated_date = "2024/07/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -40,6 +40,41 @@ query = ''' process where event.module == "cloud_defend" and event.type== "start" and (process.name== "mount" or process.args== "mount") and container.security_context.privileged == true ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Mount Launched Inside a Privileged Container + +In containerized environments, the `mount` utility is crucial for attaching file systems to the system's directory tree. When executed within a privileged container, which has extensive host capabilities, it can be exploited by adversaries to access sensitive host files, potentially leading to privilege escalation or container escapes. The detection rule identifies such misuse by monitoring the execution of `mount` in privileged containers, flagging potential security threats for further investigation. + +### Possible investigation steps + +- Review the alert details to confirm that the process name or arguments include "mount" and that the container's security context is marked as privileged. +- Identify the container involved in the alert by examining the container ID or name, and gather information about its purpose and the applications it runs. +- Check the container's deployment configuration to verify if it was intentionally set as privileged and assess whether this level of privilege is necessary for its function. +- Investigate the user or process that initiated the mount command within the container to determine if it aligns with expected behavior or if it indicates potential malicious activity. +- Examine the mounted file systems and directories to identify any sensitive host files that may have been accessed or exposed. +- Review logs and historical data for any previous suspicious activities associated with the same container or user to identify patterns or repeated attempts at privilege escalation. + +### False positive analysis + +- Routine maintenance tasks within privileged containers may trigger the rule. Exclude known maintenance scripts or processes by adding them to an exception list based on their unique identifiers or command patterns. +- Backup operations that require mounting file systems might be flagged. Identify and exclude these operations by specifying the backup process names or arguments in the rule exceptions. +- Development or testing environments often use privileged containers for convenience. If these environments are known and controlled, consider excluding them by container IDs or labels to reduce noise. +- Automated deployment tools that use mount commands in privileged containers can be mistaken for threats. Review and whitelist these tools by their process names or specific arguments to prevent false alerts. +- Certain monitoring or logging solutions may use mount operations for data collection. Verify these solutions and exclude their processes if they are legitimate and necessary for system operations. + +### Response and remediation + +- Immediately isolate the affected container to prevent further access to sensitive host files. This can be done by stopping the container or disconnecting it from the network. +- Review and revoke any unnecessary privileges from the container's security context to prevent similar incidents. Ensure that containers run with the least privileges necessary. +- Conduct a thorough analysis of the container's file system and logs to identify any unauthorized access or modifications to host files. +- If unauthorized access is confirmed, perform a comprehensive audit of the host system to check for any signs of compromise or privilege escalation attempts. +- Patch and update the container image and host system to address any vulnerabilities that may have been exploited. +- Implement stricter access controls and monitoring for privileged containers, ensuring that only trusted users and processes can execute sensitive commands like `mount`. +- Escalate the incident to the security operations team for further investigation and to assess the need for additional security measures or incident response actions.""" [[rule.threat]] diff --git a/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_notify_on_release_file.toml b/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_notify_on_release_file.toml index e02c4778a14..f6de548d46d 100644 --- a/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_notify_on_release_file.toml +++ b/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_notify_on_release_file.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/26" integration = ["cloud_defend"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -41,6 +41,41 @@ query = ''' file where event.module == "cloud_defend" and event.action == "open" and event.type == "change" and file.name : "notify_on_release" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Container Escape via Modified notify_on_release File + +In containerized environments, the `notify_on_release` file in cgroups can trigger host-level commands when a cgroup becomes empty. Adversaries exploit this by modifying the file from privileged containers, potentially executing unauthorized commands on the host. The detection rule monitors changes to `notify_on_release` files, flagging suspicious modifications indicative of privilege escalation attempts. + +### Possible investigation steps + +- Review the alert details to confirm the file involved is indeed the "notify_on_release" file and verify the event.module is "cloud_defend" with event.action as "open" and event.type as "change". +- Identify the container from which the modification attempt originated by examining the associated metadata, such as container ID or name, to understand the context of the alert. +- Check the privileges and capabilities assigned to the container, specifically looking for SYS_ADMIN capabilities, which could allow modification of cgroup settings. +- Investigate the release_agent file associated with the cgroup to determine if any unauthorized or suspicious commands are configured to execute upon cgroup release. +- Review recent activity logs and command history within the container to identify any anomalous behavior or commands that could indicate an attempt to exploit the notify_on_release mechanism. +- Assess the potential impact on the host system by determining if any unauthorized commands have been executed as a result of the modification, and evaluate the need for containment or remediation actions. + +### False positive analysis + +- Routine maintenance tasks in containerized environments may involve legitimate modifications to the notify_on_release file. Users should verify if such changes align with scheduled maintenance activities. +- Automated container orchestration tools might modify cgroup settings, including the notify_on_release file, as part of their normal operations. Users can create exceptions for known orchestration tools by identifying their specific process IDs or user accounts. +- Some containerized applications may require modifications to cgroup settings for performance tuning or resource management. Users should document these applications and exclude their expected behavior from triggering alerts. +- Development and testing environments often involve frequent changes to container configurations, including cgroup files. Users can reduce noise by applying the rule only to production environments or by setting up separate monitoring profiles for non-production systems. +- If a specific container consistently triggers alerts without malicious intent, users can whitelist the container by its unique identifier or image name, ensuring that only unexpected changes are flagged. + +### Response and remediation + +- Immediately isolate the affected container to prevent further unauthorized actions. This can be done by stopping the container or disconnecting it from the network. +- Review and revoke any unnecessary privileges or capabilities, such as SYS_ADMIN, from the container to minimize the risk of exploitation. +- Inspect the release_agent file associated with the cgroup to identify any unauthorized commands or scripts that may have been set for execution. +- Remove or reset any malicious or unauthorized entries in the release_agent file to prevent further execution of host-level commands. +- Conduct a thorough audit of the host system for any signs of compromise or unauthorized access, focusing on logs and system changes around the time of the alert. +- Patch and update the container runtime and host operating system to address any known vulnerabilities that could facilitate container escapes. +- Enhance monitoring and alerting for similar activities by ensuring that all cgroup modifications are logged and reviewed regularly, and consider implementing additional security controls such as AppArmor or SELinux to restrict container capabilities.""" [[rule.threat]] diff --git a/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_release_agent_file.toml b/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_release_agent_file.toml index 8c44e8b3c60..0c03015586e 100644 --- a/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_release_agent_file.toml +++ b/rules/integrations/cloud_defend/privilege_escalation_potential_container_escape_via_modified_release_agent_file.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/26" integration = ["cloud_defend"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -40,6 +40,41 @@ query = ''' file where event.module == "cloud_defend" and event.action == "open" and event.type == "change" and file.name : "release_agent" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Container Escape via Modified release_agent File + +In containerized environments, the release_agent file in CGroup directories can execute scripts upon process termination. Adversaries exploit this by modifying the file from privileged containers, potentially escalating privileges or escaping to the host. The detection rule monitors changes to the release_agent file, flagging unauthorized modifications indicative of such exploits. + +### Possible investigation steps + +- Review the alert details to confirm the file involved is the release_agent file and that the event.module is "cloud_defend" with event.action as "open" and event.type as "change". +- Identify the container from which the modification attempt originated, focusing on whether it has SYS_ADMIN capabilities, which could indicate a privileged container. +- Check the history of the release_agent file for any recent changes or modifications, including timestamps and user accounts involved, to understand the context of the modification. +- Investigate the processes running within the container at the time of the alert to identify any suspicious or unauthorized activities that could be related to privilege escalation attempts. +- Examine the network activity and connections from the container to detect any unusual outbound traffic that might suggest an attempt to communicate with external systems or exfiltrate data. +- Review system logs and audit logs on the host for any signs of unauthorized access or privilege escalation attempts that coincide with the alert timestamp. +- Assess the security posture of the container environment, including the configuration of CGroup directories and permissions, to identify potential vulnerabilities that could be exploited for container escape. + +### False positive analysis + +- Routine maintenance scripts or system updates may modify the release_agent file without malicious intent. Users can create exceptions for known maintenance activities by identifying the specific processes or scripts involved and excluding them from the rule. +- Automated container management tools might access and modify the release_agent file as part of their normal operations. Users should verify the legitimacy of these tools and whitelist their actions to prevent unnecessary alerts. +- Custom container orchestration solutions could interact with the release_agent file for legitimate reasons. Users should document these interactions and configure the rule to ignore changes made by these trusted solutions. +- Development and testing environments often involve frequent changes to container configurations, including the release_agent file. Users can reduce false positives by setting up separate monitoring profiles for these environments, allowing more lenient detection thresholds. + +### Response and remediation + +- Immediately isolate the affected container to prevent further unauthorized actions or potential spread to other containers or the host system. +- Revoke SYS_ADMIN capabilities from the container to limit its ability to modify critical system files and directories. +- Conduct a thorough review of the modified release_agent file to identify any malicious scripts or commands that may have been inserted. +- Restore the release_agent file to its original state from a known good backup to ensure no unauthorized scripts are executed. +- Investigate the source of the privilege escalation to determine how the adversary gained SYS_ADMIN capabilities and address any security gaps. +- Escalate the incident to the security operations team for further analysis and to assess the potential impact on the host system. +- Implement additional monitoring and alerting for changes to critical files and directories within privileged containers to enhance detection of similar threats in the future.""" [[rule.threat]] diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_geo_country_iso_code.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_geo_country_iso_code.toml index fc951b330cb..adf915df75f 100644 --- a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_geo_country_iso_code.toml +++ b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_geo_country_iso_code.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/22" integration = ["ded", "endpoint", "network_traffic"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] anomaly_threshold = 75 @@ -52,6 +52,41 @@ tags = [ "Tactic: Exfiltration", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Data Exfiltration Activity to an Unusual ISO Code + +Machine learning models analyze network traffic patterns to identify anomalies, such as data transfers to unexpected geo-locations. Adversaries exploit command and control channels to exfiltrate data to these unusual regions. The detection rule leverages ML to flag deviations from normal traffic, indicating potential exfiltration activities, thus aiding in early threat identification. + +### Possible investigation steps + +- Review the alert details to identify the specific unusual ISO code and geo-location involved in the data transfer. +- Analyze network logs to determine the volume and frequency of data transfers to the identified geo-location, comparing it against baseline traffic patterns. +- Investigate the source IP addresses and devices involved in the data transfer to assess whether they are legitimate or potentially compromised. +- Check for any recent changes or anomalies in user behavior or access patterns associated with the source devices or accounts. +- Correlate the alert with other security events or logs, such as authentication logs or endpoint detection alerts, to identify any related suspicious activities. +- Consult threat intelligence sources to determine if the unusual geo-location is associated with known malicious activities or threat actors. + +### False positive analysis + +- Legitimate business operations involving data transfers to new or infrequent geo-locations may trigger false positives. Users should review these activities and whitelist known safe destinations. +- Regularly scheduled data backups or transfers to international offices or cloud services can be mistaken for exfiltration. Implement exceptions for these routine operations by updating the model's baseline. +- Temporary projects or collaborations with partners in unusual regions might cause alerts. Document these activities and adjust the detection parameters to accommodate such temporary changes. +- Changes in business operations, such as expansion into new markets, can alter normal traffic patterns. Update the model to reflect these changes to prevent unnecessary alerts. +- Use historical data to identify patterns of benign traffic to unusual regions and adjust the model's sensitivity to reduce false positives while maintaining security vigilance. + +### Response and remediation + +- Immediately isolate the affected systems from the network to prevent further data exfiltration. +- Conduct a thorough analysis of the network traffic logs to identify the source and destination of the unusual data transfer, focusing on the specific geo-location flagged by the alert. +- Block the identified IP addresses or domains associated with the unusual ISO code in the organization's firewall and intrusion prevention systems. +- Review and update access controls and permissions to ensure that only authorized personnel have access to sensitive data, reducing the risk of unauthorized data transfers. +- Restore any compromised systems from clean backups, ensuring that all security patches and updates are applied before reconnecting to the network. +- Escalate the incident to the organization's security operations center (SOC) or incident response team for further investigation and to determine if additional systems or data were affected. +- Implement enhanced monitoring and alerting for similar anomalies in network traffic to improve early detection of potential exfiltration activities in the future.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_ip.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_ip.toml index 350448b6a9b..a7001a580c4 100644 --- a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_ip.toml +++ b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_ip.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/22" integration = ["ded", "endpoint", "network_traffic"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] anomaly_threshold = 75 @@ -52,6 +52,40 @@ tags = [ "Tactic: Exfiltration", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Data Exfiltration Activity to an Unusual IP Address + +Machine learning models analyze network traffic patterns to identify anomalies, such as data transfers to atypical geo-locations. Adversaries exploit command and control channels to exfiltrate data to these unusual IP addresses. This detection rule leverages ML to flag deviations from normal traffic, indicating potential exfiltration activities, thus aiding in early threat identification. + +### Possible investigation steps + +- Review the alert details to identify the unusual IP address and geo-location involved in the potential exfiltration activity. +- Cross-reference the identified IP address with threat intelligence databases to determine if it is associated with known malicious activities or threat actors. +- Analyze historical network traffic logs to determine if there have been previous connections to the same IP address or geo-location, and assess the volume and frequency of these connections. +- Investigate the source device or user account associated with the alert to identify any unauthorized access or suspicious behavior leading up to the alert. +- Check for any recent changes in network configurations or security policies that might have inadvertently allowed the data transfer to the unusual IP address. +- Collaborate with the IT team to isolate the affected systems, if necessary, and prevent further data exfiltration while the investigation is ongoing. + +### False positive analysis + +- Legitimate business operations involving data transfers to new or infrequent geo-locations may trigger false positives. Users should review these activities and, if deemed non-threatening, add exceptions for these IP addresses. +- Regularly scheduled data backups or transfers to cloud services located in different regions can be misidentified as exfiltration. Users can whitelist these services to prevent unnecessary alerts. +- Remote work scenarios where employees connect from various locations might cause false positives. Implementing a policy to recognize and exclude known employee IP addresses can mitigate this issue. +- Partner or vendor data exchanges that occur outside typical patterns should be evaluated. If these are routine and secure, users can create exceptions for these specific IP addresses to reduce false alerts. + +### Response and remediation + +- Isolate the affected systems immediately to prevent further data exfiltration. Disconnect them from the network to stop any ongoing communication with the unusual IP address. +- Conduct a thorough analysis of the affected systems to identify any malicious software or unauthorized access points. Remove any identified threats and patch vulnerabilities. +- Change all credentials and access keys that may have been compromised during the exfiltration activity. Ensure that new credentials follow best practices for security. +- Review and update firewall rules and network access controls to block the identified unusual IP address and similar suspicious IP ranges. +- Monitor network traffic closely for any signs of continued exfiltration attempts or communication with command and control channels. Use enhanced logging and alerting to detect any anomalies. +- Escalate the incident to the organization's cybersecurity response team and, if necessary, report the breach to relevant authorities or regulatory bodies as per compliance requirements. +- Conduct a post-incident review to identify gaps in the current security posture and implement measures to prevent recurrence, such as improving network segmentation and enhancing threat detection capabilities.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_port.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_port.toml index 119651afe53..00f61eea102 100644 --- a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_port.toml +++ b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_port.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/22" integration = ["ded", "endpoint", "network_traffic"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] anomaly_threshold = 75 @@ -51,6 +51,41 @@ tags = [ "Tactic: Exfiltration", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Data Exfiltration Activity to an Unusual Destination Port + +Machine learning models analyze network traffic to identify anomalies, such as data transfers to uncommon destination ports, which may suggest exfiltration via command and control channels. Adversaries exploit these channels to stealthily siphon data. This detection rule leverages ML to flag deviations from normal traffic patterns, aiding in early identification of potential threats. + +### Possible investigation steps + +- Review the network traffic logs to identify the source IP address associated with the unusual destination port activity. Determine if this IP is known or expected within the organization's network. +- Analyze the destination port and associated IP address to assess whether it is commonly used for legitimate purposes or if it is known for malicious activity. Cross-reference with threat intelligence databases if necessary. +- Examine the volume and frequency of data transferred to the unusual destination port to identify any patterns or anomalies that deviate from normal behavior. +- Investigate the user or system account associated with the source IP to determine if there are any signs of compromise or unauthorized access. +- Check for any recent changes or updates in the network configuration or security policies that might explain the anomaly. +- Correlate this event with other security alerts or logs to identify any related suspicious activities or patterns that could indicate a broader threat. + +### False positive analysis + +- Routine data transfers to external services using uncommon ports may trigger false positives. Identify and document these services to create exceptions in the monitoring system. +- Internal applications that use non-standard ports for legitimate data transfers can be mistaken for exfiltration attempts. Regularly update the list of approved applications and their associated ports to minimize false alerts. +- Scheduled data backups to cloud services or remote servers might use unusual ports. Verify these activities and configure the system to recognize them as non-threatening. +- Development and testing environments often use non-standard ports for various operations. Ensure these environments are well-documented and excluded from exfiltration alerts when appropriate. +- Collaborate with network administrators to maintain an updated inventory of all legitimate network activities and their corresponding ports, reducing the likelihood of false positives. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further data exfiltration and contain the threat. +- Conduct a thorough analysis of the network traffic logs to identify the scope of the exfiltration and determine if other systems are affected. +- Block the identified unusual destination port at the network perimeter to prevent further unauthorized data transfers. +- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to block similar exfiltration attempts in the future. +- Notify the incident response team and relevant stakeholders about the potential data breach for further investigation and escalation. +- Perform a comprehensive scan of the affected system for malware or unauthorized software that may have facilitated the exfiltration. +- Implement enhanced monitoring on the affected system and network segment to detect any further suspicious activity.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_region_name.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_region_name.toml index b66d2fcbc9f..c801849735d 100644 --- a/rules/integrations/ded/exfiltration_ml_high_bytes_destination_region_name.toml +++ b/rules/integrations/ded/exfiltration_ml_high_bytes_destination_region_name.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/22" integration = ["ded", "endpoint", "network_traffic"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] anomaly_threshold = 75 @@ -52,6 +52,41 @@ tags = [ "Tactic: Exfiltration", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Data Exfiltration Activity to an Unusual Region + +Machine learning models analyze network traffic patterns to identify anomalies, such as data transfers to atypical regions. Adversaries exploit command and control channels to exfiltrate data to these regions, bypassing traditional security measures. This detection rule leverages ML to flag unusual geo-locations, indicating potential exfiltration activities, thus aiding in early threat identification. + +### Possible investigation steps + +- Review the geo-location details flagged by the alert to determine if the region is indeed unusual for the organization's typical network traffic patterns. +- Analyze the network traffic logs associated with the alert to identify the volume and type of data being transferred to the unusual region. +- Cross-reference the IP addresses involved in the data transfer with threat intelligence databases to check for any known malicious activity or associations. +- Investigate the user accounts and devices involved in the data transfer to assess if they have been compromised or are exhibiting other suspicious behaviors. +- Check for any recent changes in network configurations or security policies that might have inadvertently allowed data transfers to atypical regions. +- Collaborate with the organization's IT and security teams to verify if there are legitimate business reasons for the data transfer to the flagged region. + +### False positive analysis + +- Legitimate business operations involving data transfers to new or infrequent regions may trigger false positives. Users should review and whitelist these regions if they are part of regular business activities. +- Scheduled data backups or transfers to cloud services located in atypical regions can be mistaken for exfiltration. Identify and exclude these services from the rule's scope. +- Remote work scenarios where employees connect from different regions might cause alerts. Maintain an updated list of remote work locations to prevent unnecessary alerts. +- Partner or vendor data exchanges that occur outside usual geographic patterns should be documented and excluded if they are verified as non-threatening. +- Temporary projects or collaborations with international teams may result in unusual data flows. Ensure these are accounted for in the rule's configuration to avoid false positives. + +### Response and remediation + +- Isolate the affected systems immediately to prevent further data exfiltration. Disconnect them from the network to stop ongoing communication with the unusual geo-location. +- Conduct a thorough analysis of the network traffic logs to identify the scope of the exfiltration and determine which data was accessed or transferred. +- Revoke any compromised credentials and enforce a password reset for affected accounts to prevent unauthorized access. +- Implement geo-blocking measures to restrict data transfers to the identified unusual region, ensuring that only approved regions can communicate with the network. +- Review and update firewall and intrusion detection system (IDS) rules to detect and block similar command and control traffic patterns in the future. +- Escalate the incident to the security operations center (SOC) and relevant stakeholders, providing them with detailed findings and actions taken for further investigation and response. +- Conduct a post-incident review to assess the effectiveness of the response and identify any gaps in the security posture, implementing necessary improvements to prevent recurrence.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device.toml index 39917340b0a..36b9d7ff333 100644 --- a/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device.toml +++ b/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/22" integration = ["ded", "endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] anomaly_threshold = 75 @@ -51,6 +51,41 @@ tags = [ "Tactic: Exfiltration", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Spike in Bytes Sent to an External Device + +The detection rule leverages machine learning to identify anomalies in data transfer patterns to external devices, which typically follow predictable trends. Adversaries may exploit this by transferring large volumes of data to external media for exfiltration. The rule detects deviations from normal behavior, flagging potential illicit data transfers for further investigation. + +### Possible investigation steps + +- Review the alert details to identify the specific external device involved and the volume of data transferred. +- Correlate the time of the anomaly with user activity logs to determine if the data transfer aligns with any known or authorized user actions. +- Check historical data transfer patterns for the involved device to assess whether the detected spike is truly anomalous or part of a legitimate operational change. +- Investigate the user account associated with the data transfer for any signs of compromise or unusual behavior, such as recent password changes or failed login attempts. +- Examine the content and type of data transferred, if possible, to assess the sensitivity and potential impact of the data exfiltration. +- Cross-reference the device and user activity with other security alerts or incidents to identify any related suspicious activities or patterns. + +### False positive analysis + +- Regular backups to external devices can trigger false positives. Users should identify and exclude backup operations from the rule's scope by specifying known backup software or devices. +- Software updates or installations that involve large data transfers to external media may be misclassified. Users can create exceptions for these activities by defining specific update processes or installation paths. +- Data archiving processes that periodically transfer large volumes of data to external storage can be mistaken for exfiltration. Users should whitelist these scheduled archiving tasks by recognizing the associated patterns or schedules. +- Media content creation or editing, such as video production, often involves significant data transfers. Users can exclude these activities by identifying and excluding the relevant applications or file types. +- Temporary data transfers for legitimate business purposes, like transferring project files to a client, can be flagged. Users should document and exclude these known business processes by specifying the involved devices or file types. + +### Response and remediation + +- Immediately isolate the affected device from the network to prevent further data exfiltration. +- Conduct a forensic analysis of the device to identify the source and scope of the data transfer, focusing on the files transferred and any associated processes or applications. +- Review and revoke any unnecessary permissions or access rights that may have facilitated the data transfer to the external device. +- Notify the security operations center (SOC) and relevant stakeholders about the incident for awareness and potential escalation. +- Implement additional monitoring on similar devices and network segments to detect any further anomalous data transfer activities. +- Update and enforce data transfer policies to restrict unauthorized use of external devices, ensuring compliance with organizational security standards. +- Consider deploying endpoint detection and response (EDR) solutions to enhance visibility and control over data movements to external devices.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device_airdrop.toml b/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device_airdrop.toml index 9236fbdd189..242528144a1 100644 --- a/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device_airdrop.toml +++ b/rules/integrations/ded/exfiltration_ml_high_bytes_written_to_external_device_airdrop.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/22" integration = ["ded", "endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] anomaly_threshold = 75 @@ -52,6 +52,41 @@ tags = [ "Tactic: Exfiltration", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Spike in Bytes Sent to an External Device via Airdrop + +Airdrop facilitates seamless file sharing between Apple devices, leveraging Bluetooth and Wi-Fi. While convenient, adversaries can exploit it for unauthorized data exfiltration by transferring large volumes of sensitive data. The detection rule employs machine learning to identify anomalies in data transfer patterns, flagging unusual spikes in bytes sent as potential exfiltration attempts, thus aiding in early threat detection. + +### Possible investigation steps + +- Review the alert details to identify the specific device and user involved in the data transfer. Check for any known associations with previous incidents or suspicious activities. +- Analyze the volume of data transferred and compare it to typical usage patterns for the device and user. Determine if the spike is significantly higher than usual. +- Investigate the time and context of the data transfer. Correlate with other logs or alerts to identify any concurrent suspicious activities or anomalies. +- Check the destination device's details to verify if it is a recognized and authorized device within the organization. Investigate any unknown or unauthorized devices. +- Contact the user associated with the alert to verify the legitimacy of the data transfer. Gather information on the nature of the files transferred and the purpose of the transfer. +- Review any recent changes in the user's access privileges or roles that might explain the increased data transfer activity. + +### False positive analysis + +- Regular large file transfers for legitimate business purposes, such as media companies transferring video files, can trigger false positives. Users can create exceptions for specific devices or user accounts known to perform these tasks regularly. +- Software updates or backups that involve transferring large amounts of data to external devices may be misidentified as exfiltration attempts. Users should whitelist these activities by identifying the associated processes or applications. +- Educational institutions or creative teams often share large files for collaborative projects. Establishing a baseline for expected data transfer volumes and excluding these from alerts can reduce false positives. +- Devices used for testing or development purposes might frequently send large data volumes. Users can exclude these devices from monitoring by adding them to an exception list. +- Personal use of Airdrop for transferring large media files, such as photos or videos, can be mistaken for suspicious activity. Users can mitigate this by setting thresholds that account for typical personal use patterns. + +### Response and remediation + +- Immediately isolate the affected device from the network to prevent further data exfiltration. +- Verify the identity and permissions of the user associated with the anomalous Airdrop activity to ensure they are authorized to transfer data. +- Conduct a forensic analysis of the device to identify any unauthorized applications or processes that may have facilitated the data transfer. +- Review and revoke any unnecessary permissions or access rights for the user or device involved in the incident. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if the activity is part of a larger threat campaign. +- Implement additional monitoring on the affected device and similar devices to detect any further anomalous Airdrop activities. +- Update security policies and controls to restrict Airdrop usage to only trusted devices and networks, reducing the risk of future unauthorized data transfers.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/integrations/ded/exfiltration_ml_rare_process_writing_to_external_device.toml b/rules/integrations/ded/exfiltration_ml_rare_process_writing_to_external_device.toml index ea9d9ea5633..c57048c344a 100644 --- a/rules/integrations/ded/exfiltration_ml_rare_process_writing_to_external_device.toml +++ b/rules/integrations/ded/exfiltration_ml_rare_process_writing_to_external_device.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/22" integration = ["ded", "endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] anomaly_threshold = 75 @@ -51,6 +51,41 @@ tags = [ "Tactic: Exfiltration", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Writing Data to an External Device + +In modern environments, processes may write data to external devices for legitimate reasons, such as backups or data transfers. However, adversaries can exploit this by using seemingly harmless processes to exfiltrate sensitive data. The detection rule leverages machine learning to identify rare processes engaging in such activities, flagging potential exfiltration attempts by analyzing deviations from typical behavior patterns. + +### Possible investigation steps + +- Review the process name and path to determine if it is commonly associated with legitimate activities or known software. +- Check the user account associated with the process to verify if it has the necessary permissions and if the activity aligns with the user's typical behavior. +- Analyze the external device's details, such as its type and connection history, to assess if it is a recognized and authorized device within the organization. +- Investigate the volume and type of data being written to the external device to identify any sensitive or unusual data transfers. +- Correlate the process activity with other security events or logs to identify any concurrent suspicious activities or anomalies. +- Consult with the user or department associated with the process to confirm if the data transfer was authorized and necessary. + +### False positive analysis + +- Backup processes may trigger alerts when writing data to external devices. Users should identify and whitelist legitimate backup applications to prevent false positives. +- Data transfer applications used for legitimate business purposes can be flagged. Regularly review and approve these applications to ensure they are not mistakenly identified as threats. +- Software updates or installations that involve writing data to external devices might be detected. Establish a list of known update processes and exclude them from triggering alerts. +- IT maintenance activities, such as system diagnostics or hardware testing, can cause false positives. Document and exclude these routine processes to avoid unnecessary alerts. +- User-initiated file transfers for legitimate reasons, such as moving large datasets for analysis, should be monitored and approved to prevent misclassification. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further data exfiltration and contain the threat. +- Identify and terminate the suspicious process writing data to the external device to stop any ongoing exfiltration activities. +- Conduct a forensic analysis of the affected system to determine the scope of the data exfiltration, including what data was accessed or transferred. +- Review and revoke any compromised credentials or access permissions associated with the affected process to prevent unauthorized access. +- 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 on the affected system and similar environments to detect any recurrence of the threat or related suspicious activities. +- Update security policies and controls to prevent similar exfiltration attempts, such as restricting process permissions to write to external devices and enhancing endpoint protection measures.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/integrations/dga/command_and_control_ml_dga_activity_using_sunburst_domain.toml b/rules/integrations/dga/command_and_control_ml_dga_activity_using_sunburst_domain.toml index 8fd4b2d3054..d7c944dca7e 100644 --- a/rules/integrations/dga/command_and_control_ml_dga_activity_using_sunburst_domain.toml +++ b/rules/integrations/dga/command_and_control_ml_dga_activity_using_sunburst_domain.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/14" integration = ["dga", "endpoint", "network_traffic"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -59,6 +59,41 @@ type = "query" query = ''' ml_is_dga.malicious_prediction:1 and dns.question.registered_domain:avsvmcloud.com ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Machine Learning Detected DGA activity using a known SUNBURST DNS domain + +Domain Generation Algorithms (DGAs) are used by adversaries to dynamically generate domain names for command and control (C2) communication, making it difficult to block malicious domains. The SUNBURST malware utilized such techniques. The detection rule leverages machine learning to identify DNS queries linked to these generated domains, specifically targeting those associated with SUNBURST, by analyzing patterns and predicting malicious activity, thus aiding in early threat detection and mitigation. + +### Possible investigation steps + +- Review the DNS logs to identify the source IP address associated with the DNS query for avsvmcloud.com to determine the affected host within the network. +- Check historical DNS query logs for the identified host to see if there are additional queries to other suspicious or known malicious domains, indicating further compromise. +- Investigate the network traffic from the identified host around the time of the alert to detect any unusual patterns or connections to external IP addresses that may suggest command and control activity. +- Examine endpoint security logs and alerts for the affected host to identify any signs of SUNBURST malware or other related malicious activity. +- Correlate the alert with other security events in the environment to determine if there are any related incidents or patterns that could indicate a broader attack campaign. +- Assess the risk and impact of the detected activity on the organization and determine if immediate containment or remediation actions are necessary. + +### False positive analysis + +- Legitimate software updates or network services may occasionally use domain generation algorithms for load balancing or redundancy, leading to false positives. Users should monitor and whitelist these known benign services. +- Internal testing environments or security tools that simulate DGA behavior for research or training purposes might trigger alerts. Exclude these environments by adding them to an exception list. +- Some cloud services might use dynamic DNS techniques that resemble DGA patterns. Identify and document these services, then configure exceptions to prevent unnecessary alerts. +- Frequent legitimate access to avsvmcloud.com by security researchers or analysts could be misclassified. Ensure these activities are logged and reviewed, and create exceptions for known research IPs or user accounts. +- Regularly review and update the exception list to ensure it reflects current network behavior and does not inadvertently allow new threats. + +### Response and remediation + +- Isolate the affected systems immediately to prevent further communication with the malicious domain avsvmcloud.com and halt potential data exfiltration or lateral movement. +- Conduct a thorough scan of the isolated systems using updated antivirus and anti-malware tools to identify and remove any SUNBURST malware or related malicious files. +- Review and block any outbound traffic to the domain avsvmcloud.com at the network perimeter to prevent future connections from other potentially compromised systems. +- Analyze network logs and DNS query records to identify any other systems that may have communicated with the domain, and apply the same isolation and scanning procedures to those systems. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the full scope of the compromise. +- Implement enhanced monitoring and alerting for any DNS queries or network traffic patterns indicative of DGA activity, particularly those resembling SUNBURST characteristics, to detect and respond to similar threats promptly. +- Review and update incident response and recovery plans to incorporate lessons learned from this incident, ensuring faster and more effective responses to future threats.""" [[rule.threat]] diff --git a/rules/integrations/dga/command_and_control_ml_dga_high_sum_probability.toml b/rules/integrations/dga/command_and_control_ml_dga_high_sum_probability.toml index 5f43ccebc1a..08eaf51c9bf 100644 --- a/rules/integrations/dga/command_and_control_ml_dga_high_sum_probability.toml +++ b/rules/integrations/dga/command_and_control_ml_dga_high_sum_probability.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/14" integration = ["dga", "endpoint", "network_traffic"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] anomaly_threshold = 70 @@ -60,6 +60,39 @@ tags = [ "Tactic: Command and Control", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 DGA Activity +Domain Generation Algorithms (DGAs) are used by malware to dynamically generate domain names for command and control (C2) communication, making it difficult to block malicious domains. Adversaries exploit this by frequently changing domains to evade detection. The 'Potential DGA Activity' detection rule leverages machine learning to analyze DNS requests from source IPs, identifying patterns indicative of DGA usage, thus flagging potential threats for further investigation. + +### Possible investigation steps + +- Review the source IP address identified in the alert to determine if it belongs to a known or trusted entity within the organization. +- Analyze the DNS request patterns from the source IP to identify any unusual or suspicious domain names that may indicate DGA activity. +- Cross-reference the flagged domains with threat intelligence feeds to check for known malicious domains or patterns associated with DGAs. +- Investigate the network traffic associated with the source IP to identify any additional indicators of compromise or communication with known malicious IPs. +- Check for any recent changes or anomalies in the system or network configurations that could explain the detected activity. +- Assess the risk score and severity in the context of the organization's environment to prioritize the investigation and response efforts. + +### False positive analysis + +- Legitimate software updates or cloud services may generate high volumes of DNS requests that resemble DGA patterns. Users can create exceptions for known update servers or cloud service domains to reduce false positives. +- Content delivery networks (CDNs) often use dynamically generated subdomains for load balancing and distribution, which can trigger DGA alerts. Identifying and excluding these CDN domains from analysis can help mitigate false positives. +- Large organizations with complex internal networks might have internal applications that generate DNS requests similar to DGA activity. Conducting a thorough review of internal DNS traffic and whitelisting known internal domains can prevent these false positives. +- Some security tools or network appliances may perform DNS lookups as part of their normal operation, which could be misclassified as DGA activity. Identifying these tools and excluding their IP addresses from the analysis can help manage false positives. + +### Response and remediation + +- Isolate the affected systems: Immediately disconnect any systems identified as making suspicious DNS requests from the network to prevent further communication with potential C2 servers. +- Block identified domains: Use firewall and DNS filtering solutions to block the domains flagged by the detection rule, preventing any further communication attempts. +- Conduct a thorough system scan: Use updated antivirus and anti-malware tools to scan the isolated systems for any signs of infection or malicious software. +- Analyze network traffic: Review network logs to identify any additional suspicious activity or other systems that may be affected, focusing on unusual DNS requests and connections. +- Patch and update systems: Ensure all systems, especially those identified in the alert, are fully patched and updated to mitigate vulnerabilities that could be exploited by malware. +- Restore from backups: If malware is confirmed, restore affected systems from clean backups to ensure no remnants of the infection remain. +- Escalate to incident response team: If the threat is confirmed and widespread, escalate the incident to the organization's incident response team for further investigation and coordinated response efforts.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/integrations/dga/command_and_control_ml_dns_request_high_dga_probability.toml b/rules/integrations/dga/command_and_control_ml_dns_request_high_dga_probability.toml index c144bd2ddb0..48a8202ef98 100644 --- a/rules/integrations/dga/command_and_control_ml_dns_request_high_dga_probability.toml +++ b/rules/integrations/dga/command_and_control_ml_dns_request_high_dga_probability.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/14" integration = ["dga", "endpoint", "network_traffic"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -59,6 +59,40 @@ type = "query" query = ''' ml_is_dga.malicious_probability > 0.98 ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Machine Learning Detected a DNS Request With a High DGA Probability Score + +Machine learning models analyze DNS requests to identify patterns indicative of Domain Generation Algorithms (DGAs), often used by attackers to establish command and control channels. These algorithms generate numerous domain names, making detection challenging. The detection rule leverages a model to flag DNS queries with high DGA probability, aiding in identifying potential malicious activity. + +### Possible investigation steps + +- Review the DNS query logs to identify the specific domain name associated with the high DGA probability score and gather additional context about the request, such as the timestamp and the source IP address. +- Cross-reference the identified domain name with threat intelligence databases to determine if it is a known malicious domain or associated with any known threat actors or campaigns. +- Investigate the source IP address to determine if it belongs to a legitimate user or system within the network, and check for any unusual or suspicious activity associated with this IP address. +- Analyze network traffic logs to identify any additional communication attempts to the flagged domain or other suspicious domains, which may indicate further command and control activity. +- Check endpoint security logs for any signs of compromise or suspicious behavior on the device that initiated the DNS request, such as unexpected processes or connections. +- Consider isolating the affected system from the network if there is strong evidence of compromise, to prevent further potential malicious activity while conducting a deeper forensic analysis. + +### False positive analysis + +- Legitimate software updates or services may use domain generation techniques for load balancing or redundancy, leading to false positives. Users can create exceptions for known update services or trusted software to reduce these alerts. +- Content delivery networks (CDNs) often use dynamically generated domains to optimize content delivery, which might be flagged. Identifying and whitelisting these CDN domains can help minimize unnecessary alerts. +- Some security tools and applications use DGA-like patterns for legitimate purposes, such as generating unique identifiers. Users should verify the source and purpose of these requests and consider excluding them if they are confirmed to be non-threatening. +- Internal testing environments or development tools might generate domains that resemble DGA activity. Users can exclude these environments from monitoring or adjust the rule to ignore specific internal IP ranges or domain patterns. + +### Response and remediation + +- Isolate the affected system from the network to prevent further potential command and control communication. +- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious software. +- Review and block the identified suspicious domain names at the network perimeter to prevent any further communication attempts. +- Analyze network traffic logs to identify any other systems that may have communicated with the flagged domains and apply similar containment measures. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if the threat is part of a larger attack campaign. +- Implement additional monitoring on the affected system and network segment to detect any signs of persistence or further malicious activity. +- Update and reinforce endpoint protection measures, ensuring all systems have the latest security patches and configurations to prevent similar threats in the future.""" [[rule.threat]] diff --git a/rules/integrations/dga/command_and_control_ml_dns_request_predicted_to_be_a_dga_domain.toml b/rules/integrations/dga/command_and_control_ml_dns_request_predicted_to_be_a_dga_domain.toml index 9bdf80ef78a..bc817ee6848 100644 --- a/rules/integrations/dga/command_and_control_ml_dns_request_predicted_to_be_a_dga_domain.toml +++ b/rules/integrations/dga/command_and_control_ml_dns_request_predicted_to_be_a_dga_domain.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/14" integration = ["dga", "endpoint", "network_traffic"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -59,6 +59,41 @@ type = "query" query = ''' ml_is_dga.malicious_prediction:1 and not dns.question.registered_domain:avsvmcloud.com ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Machine Learning Detected a DNS Request Predicted to be a DGA Domain + +Machine learning models can identify patterns in DNS requests that suggest the use of Domain Generation Algorithms (DGAs), which adversaries use to dynamically generate domain names for command and control (C2) communication. This detection rule leverages such models to flag DNS queries likely generated by DGAs, excluding known benign domains, thus helping to identify potential C2 activity. + +### Possible investigation steps + +- Review the DNS query logs to identify the specific domain flagged by the machine learning model as a potential DGA domain. Focus on the field ml_is_dga.malicious_prediction:1 to confirm the prediction. +- Cross-reference the flagged domain with threat intelligence sources to determine if it is associated with known malicious activity or threat actors. +- Investigate the source IP address of the DNS request to identify the device or user responsible for the query. This can help determine if the activity is isolated or part of a larger pattern. +- Analyze network traffic logs for any additional suspicious activity originating from the same source IP, such as unusual outbound connections or data transfers. +- Check for any recent changes or anomalies in the endpoint's behavior or configuration that could indicate compromise or unauthorized software installation. +- If the domain is confirmed to be malicious, initiate containment procedures to block further communication with the domain and prevent potential data exfiltration or further compromise. + +### False positive analysis + +- DNS requests to content delivery networks or cloud service providers can be flagged as DGA domains due to their dynamic nature. Users should review these domains and consider adding them to an exception list if they are verified as legitimate. +- Internal applications that generate dynamic DNS requests for load balancing or failover purposes might trigger false positives. Identify these applications and exclude their domains from the rule to prevent unnecessary alerts. +- Automated testing environments often generate numerous DNS requests that can appear suspicious. Regularly update the exception list with domains used by these environments to minimize false alerts. +- Frequent updates or patches from software vendors may involve dynamic DNS requests. Verify these domains and exclude them if they are confirmed to be part of legitimate update processes. +- Consider monitoring the frequency and pattern of flagged DNS requests. If a domain is consistently flagged but verified as non-threatening, it may be a candidate for exclusion from the rule. + +### Response and remediation + +- Isolate the affected system from the network to prevent further potential command and control communication. +- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious software. +- Review and block the identified DGA domain and any associated IP addresses at the network perimeter to prevent further access. +- Analyze network traffic logs to identify any other systems that may have communicated with the DGA domain and apply similar containment measures. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the compromise. +- Implement enhanced monitoring for similar DGA patterns and update detection capabilities to quickly identify future occurrences. +- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to block known DGA patterns and suspicious DNS activity.""" [[rule.threat]] diff --git a/rules/integrations/endpoint/elastic_endpoint_security.toml b/rules/integrations/endpoint/elastic_endpoint_security.toml index 37be3ddc9b9..5a00cedc190 100644 --- a/rules/integrations/endpoint/elastic_endpoint_security.toml +++ b/rules/integrations/endpoint/elastic_endpoint_security.toml @@ -5,7 +5,7 @@ maturity = "production" min_stack_comments = "New fields added: required_fields, related_integrations, setup" min_stack_version = "8.3.0" promotion = true -updated_date = "2024/11/27" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -59,6 +59,41 @@ type = "query" query = ''' event.kind:alert and event.module:(endpoint and not endgame) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Endpoint Security (Elastic Defend) + +Elastic Defend is a robust endpoint security solution that monitors and protects systems by analyzing events and generating alerts for suspicious activities. Adversaries may exploit endpoints by executing unauthorized code or manipulating system processes. The detection rule leverages event data to identify alerts from Elastic Defend, focusing on potential threats while excluding non-relevant modules, thus enabling timely investigation of endpoint anomalies. + +### Possible investigation steps + +- Review the alert details to understand the specific event.kind:alert and event.module: endpoint that triggered the alert, ensuring it is not related to the excluded endgame module. +- Examine the timeline of events leading up to the alert to identify any unusual or unauthorized activities, such as unexpected process executions or system changes. +- Correlate the alert with other security events or logs from the same endpoint to gather additional context and determine if there is a pattern of suspicious behavior. +- Investigate the source and destination of any network connections associated with the alert to identify potential command and control activity or data exfiltration attempts. +- Check for any recent changes or updates to the endpoint's software or configuration that could explain the alert, ensuring they are legitimate and authorized. +- Assess the risk score and severity of the alert in conjunction with other alerts from the same endpoint to prioritize the investigation and response efforts. + +### False positive analysis + +- Alerts triggered by routine software updates can be false positives. Users can create exceptions for known update processes to prevent unnecessary alerts. +- System maintenance activities, such as scheduled scans or backups, may generate alerts. Exclude these activities by identifying their specific event signatures and adding them to the exception list. +- Legitimate administrative actions, like remote desktop sessions or script executions by IT staff, might be flagged. Define exceptions for these actions by correlating them with authorized user accounts or IP addresses. +- Frequent alerts from non-malicious applications that interact with system processes can be excluded by whitelisting these applications based on their hash or path. +- Network monitoring tools that simulate attack patterns for testing purposes may trigger alerts. Exclude these tools by specifying their known behaviors and IP ranges in the exception settings. + +### Response and remediation + +- Isolate the affected endpoint immediately to prevent further unauthorized access or lateral movement within the network. +- Analyze the alert details to identify the specific unauthorized code or process manipulation involved, and terminate any malicious processes identified. +- Remove any unauthorized code or files from the affected endpoint, ensuring that all traces of the threat are eradicated. +- Conduct a thorough review of system logs and event data to identify any additional indicators of compromise or related suspicious activities. +- Update endpoint security configurations and signatures to prevent similar threats from exploiting the same vulnerabilities in the future. +- Restore the affected endpoint from a known good backup if necessary, ensuring that the system is free from any residual threats. +- Escalate the incident to the security operations center (SOC) or relevant team for further analysis and to determine if additional systems may be affected.""" [[rule.exceptions_list]] diff --git a/rules/integrations/fim/persistence_suspicious_file_modifications.toml b/rules/integrations/fim/persistence_suspicious_file_modifications.toml index 3d4d2b5e806..931cfa939bd 100644 --- a/rules/integrations/fim/persistence_suspicious_file_modifications.toml +++ b/rules/integrations/fim/persistence_suspicious_file_modifications.toml @@ -2,7 +2,7 @@ creation_date = "2024/06/03" integration = ["fim"] maturity = "production" -updated_date = "2024/12/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -133,6 +133,41 @@ file.path : ( file.extension in ("dpkg-new", "dpkg-remove", "SEQ") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Persistence via File Modification + +File Integrity Monitoring (FIM) is crucial for detecting unauthorized changes to critical files, often targeted by adversaries for persistence. Attackers may modify cron jobs, systemd services, or shell configurations to maintain access or escalate privileges. The detection rule monitors these files for updates, flagging potential persistence attempts by identifying suspicious modifications outside normal operations. + +### Possible investigation steps + +- Review the file path from the alert to determine which specific file was modified and assess its role in the system, focusing on paths commonly used for persistence such as cron jobs, systemd services, or shell configurations. +- Check the timestamp of the modification event to correlate it with any known legitimate changes or scheduled maintenance activities, ensuring the modification was not part of normal operations. +- Investigate the user or process responsible for the modification by examining the associated user ID or process ID, and verify if the user or process has legitimate reasons to alter the file. +- Analyze recent login and session activity for the user or process involved in the modification to identify any unusual patterns or unauthorized access attempts. +- Cross-reference the modification event with other security logs or alerts to identify any related suspicious activities, such as privilege escalation attempts or unauthorized access to sensitive files. +- If the modified file is a configuration file, review its contents for any unauthorized or suspicious entries that could indicate persistence mechanisms, such as new cron jobs or altered systemd service configurations. + +### False positive analysis + +- Routine system updates or package installations may modify files monitored by the rule, such as those in /etc/cron.d or /etc/systemd/system. To manage these, consider excluding specific file paths or extensions like dpkg-new and dpkg-remove during known maintenance windows. +- User-specific configuration changes, such as updates to shell profiles in /home/*/.bashrc, can trigger alerts. Implement exceptions for user directories where frequent legitimate changes occur, ensuring these are well-documented and reviewed regularly. +- Automated scripts or management tools that update system configurations, like /etc/ssh/sshd_config, can cause false positives. Identify these tools and create exceptions for their expected file modification patterns. +- Temporary files created during system operations, such as /var/spool/cron/crontabs/tmp.*, may be flagged. Exclude these temporary paths to reduce noise while maintaining security oversight. +- Regular updates to known_hosts files in /home/*/.ssh/known_hosts can be mistaken for suspicious activity. Exclude these files from monitoring to prevent unnecessary alerts while ensuring SSH configurations are still monitored. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. +- Review the specific file modifications flagged by the alert to determine if they are unauthorized or malicious. Restore any altered files to their last known good state using backups or system snapshots. +- Change all passwords and SSH keys associated with the affected system to prevent unauthorized access using compromised credentials. +- Conduct a thorough scan of the system for additional indicators of compromise, such as unauthorized user accounts or unexpected running processes, and remove any malicious artifacts found. +- 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 on the affected system and similar systems to detect any further unauthorized file modifications or suspicious activities. +- Review and update access controls and permissions on critical files and directories to minimize the risk of unauthorized modifications in the future.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/integrations/gcp/collection_gcp_pub_sub_subscription_creation.toml b/rules/integrations/gcp/collection_gcp_pub_sub_subscription_creation.toml index 3d33d2ee993..ce3f2e6a451 100644 --- a/rules/integrations/gcp/collection_gcp_pub_sub_subscription_creation.toml +++ b/rules/integrations/gcp/collection_gcp_pub_sub_subscription_creation.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/23" integration = ["gcp"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,41 @@ index = ["filebeat-*", "logs-gcp*"] language = "kuery" license = "Elastic License v2" name = "GCP Pub/Sub Subscription Creation" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GCP Pub/Sub Subscription Creation + +Google Cloud Pub/Sub is a messaging service that enables asynchronous communication between applications by decoupling event producers and consumers. Adversaries might exploit this by creating unauthorized subscriptions to intercept or exfiltrate sensitive data streams. The detection rule monitors audit logs for successful subscription creation events, helping identify potential misuse by flagging unexpected or suspicious activity. + +### Possible investigation steps + +- Review the audit log entry associated with the alert to identify the user or service account responsible for the subscription creation by examining the `event.dataset` and `event.action` fields. +- Verify the legitimacy of the subscription by checking the associated project and topic details to ensure they align with expected configurations and business needs. +- Investigate the history of the user or service account involved in the subscription creation to identify any unusual or unauthorized activities, focusing on recent changes or access patterns. +- Assess the permissions and roles assigned to the user or service account to determine if they have the necessary privileges for subscription creation and whether these permissions are appropriate. +- Consult with relevant stakeholders or application owners to confirm whether the subscription creation was authorized and necessary for operational purposes. + +### False positive analysis + +- Routine subscription creation by automated deployment tools or scripts can trigger false positives. Identify and whitelist these tools by excluding their service accounts from the detection rule. +- Development and testing environments often create and delete subscriptions frequently. Exclude these environments by filtering out specific project IDs associated with non-production use. +- Scheduled maintenance or updates might involve creating new subscriptions temporarily. Coordinate with the operations team to understand regular maintenance schedules and adjust the rule to ignore these activities during known maintenance windows. +- Internal monitoring or logging services that create subscriptions for legitimate data collection purposes can be excluded by identifying their specific patterns or naming conventions and adding them to an exception list. + +### Response and remediation + +- Immediately review the audit logs to confirm the unauthorized subscription creation and identify the source, including the user or service account responsible for the action. +- Revoke access for the identified user or service account to prevent further unauthorized actions. Ensure that the principle of least privilege is enforced. +- Delete the unauthorized subscription to stop any potential data interception or exfiltration. +- Conduct a thorough review of all existing subscriptions to ensure no other unauthorized subscriptions exist. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring and alerting for subscription creation events to detect similar activities in the future. +- If applicable, report the incident to Google Cloud support for further assistance and to understand if there are any broader implications or vulnerabilities. + +## Setup The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://cloud.google.com/pubsub/docs/overview"] diff --git a/rules/integrations/gcp/collection_gcp_pub_sub_topic_creation.toml b/rules/integrations/gcp/collection_gcp_pub_sub_topic_creation.toml index 701fd52c77f..49aebb40751 100644 --- a/rules/integrations/gcp/collection_gcp_pub_sub_topic_creation.toml +++ b/rules/integrations/gcp/collection_gcp_pub_sub_topic_creation.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/23" integration = ["gcp"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,44 @@ index = ["filebeat-*", "logs-gcp*"] language = "kuery" license = "Elastic License v2" name = "GCP Pub/Sub Topic Creation" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GCP Pub/Sub Topic Creation + +Google Cloud Pub/Sub is a messaging service that enables asynchronous communication between independent applications. It uses topics to route messages from publishers to subscribers. Adversaries might exploit this by creating unauthorized topics to exfiltrate data or disrupt services. The detection rule monitors successful topic creation events, helping identify potential misuse by flagging unexpected or suspicious activity. + +### Possible investigation steps + +- Review the event details to confirm the presence of the event.action field with the value google.pubsub.v*.Publisher.CreateTopic and ensure the event.outcome is success. +- Identify the user or service account associated with the topic creation by examining the actor information in the event logs. +- Check the project and resource details to determine the context and environment where the topic was created, including the project ID and resource name. +- Investigate the purpose and necessity of the newly created topic by consulting with relevant stakeholders or reviewing documentation related to the project. +- Analyze historical logs to identify any unusual patterns or anomalies in topic creation activities by the same user or within the same project. +- Assess the permissions and roles assigned to the user or service account to ensure they align with the principle of least privilege. +- If suspicious activity is confirmed, consider implementing additional monitoring or access controls to prevent unauthorized topic creation in the future. + +### False positive analysis + +- Routine topic creation by automated processes or scripts can trigger false positives. Identify and document these processes to create exceptions in the monitoring system. +- Development and testing environments often involve frequent topic creation. Exclude these environments from alerts by using environment-specific tags or labels. +- Scheduled maintenance or updates by cloud administrators may result in legitimate topic creation. Coordinate with the operations team to whitelist these activities during known maintenance windows. +- Third-party integrations or services that rely on Pub/Sub for communication might create topics as part of their normal operation. Review and approve these integrations to prevent unnecessary alerts. +- Internal applications with dynamic topic creation as part of their workflow should be assessed and, if deemed non-threatening, added to an exception list to reduce noise. + +### Response and remediation + +- Immediately review the audit logs to confirm the unauthorized creation of the Pub/Sub topic and identify the user or service account responsible for the action. +- Revoke or limit permissions for the identified user or service account to prevent further unauthorized actions, ensuring that only necessary permissions are granted. +- Delete the unauthorized Pub/Sub topic to prevent any potential data exfiltration or disruption of services. +- Conduct a thorough review of other Pub/Sub topics and related resources to ensure no additional unauthorized topics have been created. +- Notify the security team and relevant stakeholders about the incident for further investigation and to assess potential impacts on the organization. +- Implement additional monitoring and alerting for Pub/Sub topic creation events to detect and respond to similar threats more quickly in the future. +- Consider enabling organization-wide policies that restrict who can create Pub/Sub topics to reduce the risk of unauthorized actions. + +## Setup The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://cloud.google.com/pubsub/docs/admin"] diff --git a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_created.toml b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_created.toml index bf65a769bb5..8441afaca40 100644 --- a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_created.toml +++ b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_created.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/21" integration = ["gcp"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,44 @@ index = ["filebeat-*", "logs-gcp*"] language = "kuery" license = "Elastic License v2" name = "GCP Firewall Rule Creation" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GCP Firewall Rule Creation + +In GCP, firewall rules manage network traffic to and from VPCs and App Engine applications, crucial for maintaining security. Adversaries may exploit this by creating rules that permit unauthorized access, bypassing security measures. The detection rule monitors audit logs for specific actions indicating new rule creation, flagging potential defense evasion attempts to ensure timely investigation and response. + +### Possible investigation steps + +- Review the audit logs for the specific event.dataset:gcp.audit entries to identify the source of the firewall rule creation, focusing on the event.action fields: *.compute.firewalls.insert or google.appengine.*.Firewall.Create*Rule. +- Identify the user or service account responsible for the action by examining the actor information in the audit logs, such as the principalEmail field. +- Determine the network or application affected by the new firewall rule by analyzing the target resources, such as the VPC or App Engine application, to understand the potential impact. +- Assess the rule's configuration details, including the allowed or denied IP ranges, protocols, and ports, to evaluate if it introduces any security risks or deviates from established security policies. +- Check for any recent changes in permissions or roles assigned to the user or service account involved, which might indicate privilege escalation or misuse. +- Correlate the firewall rule creation event with other security events or alerts in the same timeframe to identify any suspicious patterns or activities that might suggest a coordinated attack. +- Consult with relevant stakeholders or teams to verify if the firewall rule creation was authorized and aligns with current operational requirements or projects. + +### False positive analysis + +- Routine administrative actions by authorized personnel can trigger alerts when they create or update firewall rules for legitimate purposes. To manage this, establish a list of known IP addresses or user accounts that frequently perform these actions and create exceptions for them in the detection rule. +- Automated processes or scripts that regularly update firewall configurations as part of normal operations may also cause false positives. Identify these processes and adjust the rule to exclude their specific actions or service accounts. +- Changes made during scheduled maintenance windows might be flagged as suspicious. Implement time-based exceptions to ignore rule creation events during these predefined periods. +- Integration with third-party security tools or services that modify firewall rules for enhanced protection can be mistaken for unauthorized activity. Verify these integrations and whitelist their actions to prevent unnecessary alerts. +- Development and testing environments often require frequent firewall rule changes, which can lead to false positives. Differentiate these environments from production by tagging them appropriately and excluding their events from the detection rule. + +### Response and remediation + +- Immediately review the newly created firewall rule to determine its source and intent. Verify if the rule aligns with organizational security policies and intended network configurations. +- Temporarily disable or delete the suspicious firewall rule to prevent unauthorized access while further investigation is conducted. +- Conduct a thorough audit of recent firewall rule changes in the affected GCP project to identify any other unauthorized modifications. +- Isolate affected systems or applications that may have been exposed due to the unauthorized firewall rule to prevent further exploitation. +- Notify the security operations team and relevant stakeholders about the incident for awareness and further action. +- Implement additional monitoring on the affected VPC or App Engine environment to detect any further unauthorized changes or suspicious activities. +- Review and update access controls and permissions for creating and modifying firewall rules to ensure only authorized personnel have the necessary privileges. + +## Setup The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_deleted.toml b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_deleted.toml index 2bd5d930541..71669e06d5d 100644 --- a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_deleted.toml +++ b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_deleted.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/21" integration = ["gcp"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -21,7 +21,42 @@ index = ["filebeat-*", "logs-gcp*"] language = "kuery" license = "Elastic License v2" name = "GCP Firewall Rule Deletion" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GCP Firewall Rule Deletion + +In GCP, firewall rules are crucial for controlling network traffic to and from VM instances and applications, ensuring robust security. Adversaries may delete these rules to bypass security measures, facilitating unauthorized access or data exfiltration. The detection rule monitors audit logs for deletion actions, flagging potential defense evasion attempts by identifying specific deletion events in VPC or App Engine environments. + +### Possible investigation steps + +- Review the audit logs for the specific event.dataset:gcp.audit to confirm the deletion action and gather details such as the timestamp, user identity, and source IP address associated with the event. +- Investigate the event.action field to determine whether the deletion occurred in the VPC or App Engine environment, and identify the specific firewall rule that was deleted. +- Check the user or service account activity around the time of the deletion to identify any suspicious behavior or unauthorized access attempts. +- Assess the impact of the deleted firewall rule by reviewing the network traffic patterns and security posture before and after the deletion. +- Collaborate with the network security team to determine if the deletion was part of a legitimate change management process or if it indicates a potential security incident. + +### False positive analysis + +- Routine maintenance or updates by authorized personnel may trigger firewall rule deletions. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks. +- Automated scripts or tools used for infrastructure management might delete and recreate firewall rules as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using service accounts or tags associated with these tools. +- Changes in application deployment processes, especially in environments like App Engine, can lead to legitimate firewall rule deletions. Review deployment logs and processes to identify patterns and exclude these from alerts. +- Organizational policy changes that involve restructuring network security may result in bulk deletions of firewall rules. Coordinate with network security teams to understand planned changes and temporarily adjust detection rules during these periods. +- Test environments often have dynamic configurations where firewall rules are frequently added and removed. Exclude specific projects or environments designated for testing from the detection rule to reduce noise. + +### Response and remediation + +- Immediately isolate affected VM instances or applications by applying restrictive firewall rules to prevent further unauthorized access or data exfiltration. +- Review audit logs to identify the source of the deletion action, including user accounts and IP addresses involved, and verify if the action was authorized. +- Recreate the deleted firewall rules based on the last known good configuration to restore security controls and prevent unauthorized access. +- Conduct a security review of the affected environment to identify any additional unauthorized changes or indicators of compromise. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data were impacted. +- Implement enhanced monitoring and alerting for firewall rule changes to detect and respond to similar threats more quickly in the future. +- Review and update access controls and permissions for users and service accounts to ensure that only authorized personnel can modify firewall rules. + +## Setup The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_modified.toml b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_modified.toml index ae5126fc5fb..24f35e7261f 100644 --- a/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_modified.toml +++ b/rules/integrations/gcp/defense_evasion_gcp_firewall_rule_modified.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/21" integration = ["gcp"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,44 @@ index = ["filebeat-*", "logs-gcp*"] language = "kuery" license = "Elastic License v2" name = "GCP Firewall Rule Modification" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GCP Firewall Rule Modification + +In GCP, firewall rules regulate network traffic to and from VPCs and App Engine applications, crucial for maintaining security. Adversaries may alter these rules to weaken defenses, enabling unauthorized access or data exfiltration. The detection rule monitors audit logs for modifications to firewall rules, identifying potential defense evasion attempts by flagging suspicious changes in network configurations. + +### Possible investigation steps + +- Review the audit logs for entries with the event.dataset field set to gcp.audit to confirm the source of the alert. +- Examine the event.action field for values such as *.compute.firewalls.patch or google.appengine.*.Firewall.Update*Rule to identify the specific type of firewall rule modification. +- Identify the user or service account responsible for the modification by checking the actor information in the audit logs. +- Assess the changes made to the firewall rule, including the before and after states, to determine if the modification allows more permissive ingress or egress traffic. +- Investigate the context of the modification by reviewing related activities in the audit logs around the same time to identify any suspicious patterns or sequences of actions. +- Check for any recent security incidents or alerts involving the affected VPC or App Engine application to understand potential motives or impacts of the rule change. +- If unauthorized or suspicious activity is confirmed, initiate incident response procedures to mitigate any potential security risks. + +### False positive analysis + +- Routine updates or maintenance activities by authorized personnel can trigger alerts. To manage this, create exceptions for known IP addresses or user accounts that regularly perform these tasks. +- Automated scripts or tools used for infrastructure management might modify firewall rules as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific service accounts or tags. +- Changes made during scheduled maintenance windows can be considered non-threatening. Implement time-based exceptions to ignore modifications during these periods. +- Modifications related to scaling operations in App Engine or VPCs might be legitimate. Review and whitelist specific actions associated with scaling events to prevent unnecessary alerts. +- Regular audits or compliance checks might involve temporary rule changes. Document these activities and exclude them from detection by correlating with audit logs or change management records. + +### Response and remediation + +- Immediately isolate the affected VPC or App Engine application by applying a restrictive firewall rule to prevent further unauthorized access or data exfiltration. +- Review the audit logs to identify the source of the modification, including user accounts and IP addresses involved, and revoke any suspicious credentials or access. +- Restore the firewall rule to its previous secure state using backup configurations or documented baselines to ensure the network is protected. +- Conduct a thorough security assessment of the affected environment to identify any additional unauthorized changes or indicators of compromise. +- Notify the security operations team and relevant stakeholders about the incident, providing details of the modification and actions taken. +- Implement enhanced monitoring and alerting for future firewall rule changes to detect and respond to similar threats more quickly. +- Consider engaging with Google Cloud support or a third-party security expert if the incident scope is beyond internal capabilities or if further expertise is required. + +## Setup The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/gcp/defense_evasion_gcp_logging_bucket_deletion.toml b/rules/integrations/gcp/defense_evasion_gcp_logging_bucket_deletion.toml index a9e9ba23557..65a080279fb 100644 --- a/rules/integrations/gcp/defense_evasion_gcp_logging_bucket_deletion.toml +++ b/rules/integrations/gcp/defense_evasion_gcp_logging_bucket_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/21" integration = ["gcp"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -24,7 +24,42 @@ index = ["filebeat-*", "logs-gcp*"] language = "kuery" license = "Elastic License v2" name = "GCP Logging Bucket Deletion" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GCP Logging Bucket Deletion + +In GCP, log buckets are essential for storing and organizing log data, crucial for monitoring and auditing activities. Adversaries may delete these buckets to obscure their tracks and evade detection. The detection rule identifies successful deletion events by monitoring specific audit logs, focusing on actions that indicate bucket removal. This helps security analysts quickly spot and respond to potential defense evasion tactics. + +### Possible investigation steps + +- Review the audit logs for the specific event.action: google.logging.v*.ConfigServiceV*.DeleteBucket to confirm the deletion event and gather details such as the timestamp, user identity, and source IP address. +- Investigate the user account associated with the event to determine if the action was authorized or if there are any signs of compromise, such as unusual login locations or times. +- Check for any recent changes to log sinks that might indicate an attempt to stop log routing to the deleted bucket, which could suggest intentional evasion. +- Assess the impact of the bucket deletion by identifying which logs were being routed to the bucket and determining if any critical log data might be lost or compromised. +- Look for any correlated events or alerts around the same timeframe that might indicate a broader attack or unauthorized activity within the GCP environment. + +### False positive analysis + +- Routine maintenance activities by administrators may trigger bucket deletion events. To manage this, create exceptions for known maintenance periods or specific user accounts responsible for these tasks. +- Automated scripts or tools used for log management might delete buckets as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by filtering based on their service accounts or specific identifiers. +- Testing environments often involve the creation and deletion of resources, including log buckets. Exclude events from these environments by using labels or project identifiers to differentiate them from production environments. +- Scheduled cleanup jobs that remove old or unused buckets can generate false positives. Document these jobs and adjust the detection rule to ignore deletions occurring within their scheduled time frames. +- Misconfigured log sinks that inadvertently delete buckets should be reviewed. Regularly audit and adjust sink configurations to ensure they align with intended log routing and retention policies. + +### Response and remediation + +- Immediately halt any ongoing log routing to the deleted bucket by deleting or modifying the log sinks associated with it to prevent further data loss. +- Restore the deleted log bucket from its pending deletion state within the 7-day window to recover any logs that may still be routed to it. +- Conduct a thorough review of IAM permissions and roles to ensure that only authorized personnel have the ability to delete log buckets, reducing the risk of unauthorized deletions. +- Implement additional logging and monitoring for any changes to log sinks and bucket configurations to detect and respond to similar activities promptly. +- Escalate the incident to the security operations team for further investigation and to determine if the deletion was part of a broader attack strategy. +- Review and update incident response plans to include specific procedures for handling log bucket deletions and similar defense evasion tactics. +- Consider enabling alerts for any future attempts to delete log buckets, ensuring rapid detection and response to potential threats. + +## Setup The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://cloud.google.com/logging/docs/buckets", "https://cloud.google.com/logging/docs/storage"] diff --git a/rules/integrations/gcp/defense_evasion_gcp_logging_sink_deletion.toml b/rules/integrations/gcp/defense_evasion_gcp_logging_sink_deletion.toml index 3b91941b1cc..8e2fc2b8f38 100644 --- a/rules/integrations/gcp/defense_evasion_gcp_logging_sink_deletion.toml +++ b/rules/integrations/gcp/defense_evasion_gcp_logging_sink_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/18" integration = ["gcp"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,41 @@ index = ["filebeat-*", "logs-gcp*"] language = "kuery" license = "Elastic License v2" name = "GCP Logging Sink Deletion" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GCP Logging Sink Deletion + +In GCP, logging sinks are crucial for exporting log entries to designated destinations for analysis and storage. Adversaries may delete these sinks to prevent logs from being exported, thereby evading detection. The detection rule identifies successful deletion events by monitoring specific audit logs, helping security teams quickly respond to potential defense evasion tactics. + +### Possible investigation steps + +- Review the audit logs for the specific event.action: google.logging.v*.ConfigServiceV*.DeleteSink to identify the user or service account responsible for the deletion. +- Check the event.dataset:gcp.audit logs for any preceding or subsequent suspicious activities by the same user or service account, which might indicate a pattern of malicious behavior. +- Investigate the event.outcome:success to confirm the deletion was successful and determine the impact on log monitoring and export capabilities. +- Assess the context and timing of the deletion event to see if it coincides with other security alerts or incidents, which might suggest a coordinated attack. +- Verify the permissions and roles assigned to the user or service account involved in the deletion to ensure they align with the principle of least privilege and identify any potential misconfigurations. + +### False positive analysis + +- Routine maintenance or configuration changes by authorized personnel can trigger false positives. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks. +- Automated scripts or tools used for managing logging configurations might inadvertently delete sinks as part of their operation. Identify these scripts and exclude their actions from triggering alerts by using specific identifiers or service accounts. +- Changes in project ownership or restructuring within the organization can lead to legitimate sink deletions. Document these organizational changes and adjust the monitoring rules to account for them, ensuring that alerts are only generated for unexpected deletions. +- Test environments often undergo frequent changes, including sink deletions, which can result in false positives. Implement separate monitoring rules or exceptions for test environments to reduce noise in alerting. + +### Response and remediation + +- Immediately revoke access to the affected GCP project for any suspicious or unauthorized users identified in the audit logs to prevent further malicious activity. +- Restore the deleted logging sink by recreating it with the original configuration to ensure that log entries are once again exported to the designated destination. +- Conduct a thorough review of recent log entries and audit logs to identify any other unauthorized changes or suspicious activities that may have occurred around the time of the sink deletion. +- Implement additional monitoring and alerting for any future attempts to delete logging sinks, focusing on the specific event action and outcome fields used in the detection query. +- Escalate the incident to the security operations team for further investigation and to determine if the sink deletion is part of a larger attack campaign. +- Review and update access controls and permissions for logging sink management to ensure that only authorized personnel have the ability to modify or delete sinks. +- Consider enabling additional security features such as VPC Service Controls or Organization Policy constraints to provide an extra layer of protection against unauthorized modifications to logging configurations. + +## Setup The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://cloud.google.com/logging/docs/export"] diff --git a/rules/integrations/gcp/defense_evasion_gcp_pub_sub_subscription_deletion.toml b/rules/integrations/gcp/defense_evasion_gcp_pub_sub_subscription_deletion.toml index d81d4f1c70e..41f038e2c2e 100644 --- a/rules/integrations/gcp/defense_evasion_gcp_pub_sub_subscription_deletion.toml +++ b/rules/integrations/gcp/defense_evasion_gcp_pub_sub_subscription_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/23" integration = ["gcp"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,42 @@ index = ["filebeat-*", "logs-gcp*"] language = "kuery" license = "Elastic License v2" name = "GCP Pub/Sub Subscription Deletion" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GCP Pub/Sub Subscription Deletion + +Google Cloud Pub/Sub is a messaging service that enables asynchronous communication between event producers and consumers. Subscriptions in Pub/Sub are crucial for message delivery to applications. Adversaries may delete subscriptions to disrupt communication, evade detection, or impair defenses. The detection rule monitors audit logs for successful subscription deletions, flagging potential defense evasion activities. + +### Possible investigation steps + +- Review the audit logs for the specific event.action: google.pubsub.v*.Subscriber.DeleteSubscription to identify the user or service account responsible for the deletion. +- Check the event.dataset:gcp.audit logs for any preceding or subsequent actions by the same user or service account to determine if there is a pattern of suspicious activity. +- Investigate the context of the deleted subscription by examining the associated project and any related resources to understand the potential impact on the application or service. +- Verify if the deletion aligns with any recent changes or maintenance activities within the organization to rule out legitimate actions. +- Assess the permissions and roles assigned to the user or service account to ensure they are appropriate and not overly permissive, which could indicate a security risk. +- Consult with the relevant application or service owners to confirm whether the subscription deletion was authorized and necessary. + +### False positive analysis + +- Routine maintenance activities by administrators may lead to subscription deletions that are not malicious. To manage this, create exceptions for known maintenance windows or specific admin accounts. +- Automated scripts or tools used for managing Pub/Sub resources might delete subscriptions as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using service account identifiers. +- Development and testing environments often involve frequent creation and deletion of subscriptions. Exclude these environments from alerts by filtering based on project IDs or environment tags. +- Subscription deletions as part of a resource cleanup process can be non-threatening. Document and exclude these processes by identifying patterns in the audit logs, such as specific user agents or IP addresses associated with cleanup operations. + +### Response and remediation + +- Immediately verify the legitimacy of the subscription deletion by contacting the responsible team or individual to confirm if the action was authorized. +- If unauthorized, revoke access for the user or service account involved in the deletion to prevent further unauthorized actions. +- Restore the deleted subscription from backup or recreate it if necessary, ensuring that message delivery to the application is resumed. +- Conduct a thorough review of audit logs to identify any other suspicious activities or patterns that may indicate further compromise. +- Implement additional access controls and monitoring for Pub/Sub resources to prevent unauthorized deletions in the future. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data were affected. +- Update incident response plans and playbooks to include specific procedures for handling Pub/Sub subscription deletions and similar threats. + +## Setup The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://cloud.google.com/pubsub/docs/overview"] diff --git a/rules/integrations/gcp/defense_evasion_gcp_pub_sub_topic_deletion.toml b/rules/integrations/gcp/defense_evasion_gcp_pub_sub_topic_deletion.toml index b0c2ba3b66a..a4c66e3681a 100644 --- a/rules/integrations/gcp/defense_evasion_gcp_pub_sub_topic_deletion.toml +++ b/rules/integrations/gcp/defense_evasion_gcp_pub_sub_topic_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/18" integration = ["gcp"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,43 @@ index = ["filebeat-*", "logs-gcp*"] language = "kuery" license = "Elastic License v2" name = "GCP Pub/Sub Topic Deletion" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GCP Pub/Sub Topic Deletion + +Google Cloud Platform's Pub/Sub service facilitates asynchronous messaging, allowing applications to communicate by publishing messages to topics. Deleting a topic can disrupt this communication, potentially as a tactic for defense evasion. Adversaries might exploit this by deleting topics to impair defenses or hide their tracks. The detection rule monitors audit logs for successful topic deletions, flagging potential misuse for further investigation. + +### Possible investigation steps + +- Review the audit logs for the specific event.action: google.pubsub.v*.Publisher.DeleteTopic to identify the exact time and user or service account responsible for the deletion. +- Investigate the event.dataset:gcp.audit logs around the same timeframe to identify any related activities or anomalies that might indicate malicious intent or unauthorized access. +- Check the event.outcome:success to confirm the deletion was completed successfully and correlate it with any reported service disruptions or issues in the affected applications. +- Assess the permissions and roles of the user or service account involved in the deletion to determine if they had legitimate access and reasons for performing this action. +- Contact the user or team responsible for the deletion to verify if the action was intentional and authorized, and gather any additional context or justification for the deletion. +- Review any recent changes in IAM policies or configurations that might have inadvertently allowed unauthorized topic deletions. + +### False positive analysis + +- Routine maintenance or updates by administrators can lead to legitimate topic deletions. To manage this, create exceptions for known maintenance periods or specific admin accounts. +- Automated scripts or tools that manage Pub/Sub topics might delete topics as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using service account identifiers. +- Development and testing environments often involve frequent topic creation and deletion. Exclude these environments from monitoring by filtering based on project IDs or environment tags. +- Scheduled clean-up jobs that remove unused or temporary topics can trigger false positives. Document these jobs and adjust the detection rule to ignore deletions occurring during their execution times. +- Changes in project requirements or architecture might necessitate topic deletions. Ensure that such changes are communicated and documented, allowing for temporary exceptions during the transition period. + +### Response and remediation + +- Immediately assess the impact of the topic deletion by identifying affected services and applications that rely on the deleted topic for message flow. +- Restore the deleted topic from backup if available, or recreate the topic with the same configuration to resume normal operations. +- Notify relevant stakeholders, including application owners and security teams, about the incident and potential service disruptions. +- Review access logs and permissions to identify unauthorized access or privilege escalation that may have led to the topic deletion. +- Implement stricter access controls and permissions for Pub/Sub topics to prevent unauthorized deletions in the future. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if the deletion is part of a larger attack pattern. +- Enhance monitoring and alerting for Pub/Sub topic deletions to ensure rapid detection and response to similar incidents in the future. + +## Setup The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://cloud.google.com/pubsub/docs/overview"] diff --git a/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_configuration_modified.toml b/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_configuration_modified.toml index 58c3e161484..6133b2d43d1 100644 --- a/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_configuration_modified.toml +++ b/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_configuration_modified.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/22" integration = ["gcp"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -20,7 +20,44 @@ index = ["filebeat-*", "logs-gcp*"] language = "kuery" license = "Elastic License v2" name = "GCP Storage Bucket Configuration Modification" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GCP Storage Bucket Configuration Modification + +Google Cloud Platform (GCP) storage buckets are essential for storing and managing data in the cloud. Adversaries may alter bucket configurations to weaken security, enabling unauthorized access or data exfiltration. The detection rule monitors audit logs for successful configuration changes, flagging potential defense evasion attempts by identifying suspicious modifications to storage settings. + +### Possible investigation steps + +- Review the audit logs for the specific event.action "storage.buckets.update" to identify the user or service account responsible for the configuration change. +- Examine the event.outcome field to confirm the success of the configuration modification and gather details on what specific changes were made to the storage bucket settings. +- Investigate the context of the change by checking the timestamp of the event to determine if it aligns with any known maintenance or deployment activities. +- Assess the permissions and roles of the user or service account involved in the modification to ensure they have the appropriate level of access and determine if any privilege escalation occurred. +- Cross-reference the modified bucket's configuration with security policies and best practices to identify any potential security weaknesses introduced by the change. +- Check for any other recent suspicious activities or alerts related to the same user or service account to identify patterns of potentially malicious behavior. +- If unauthorized changes are suspected, initiate a response plan to revert the configuration to its previous state and strengthen access controls to prevent future incidents. + +### False positive analysis + +- Routine administrative updates to storage bucket configurations by authorized personnel can trigger alerts. To manage this, maintain a list of known administrators and their typical activities, and create exceptions for these actions in the monitoring system. +- Automated processes or scripts that regularly update bucket configurations for maintenance or compliance purposes may cause false positives. Identify these processes and exclude their actions from triggering alerts by using service accounts or specific identifiers. +- Changes made by cloud management tools or third-party services integrated with GCP might be flagged. Review and whitelist these tools if they are verified and necessary for operations. +- Scheduled updates or configuration changes as part of regular security audits can appear suspicious. Document these schedules and incorporate them into the monitoring system to prevent unnecessary alerts. +- Temporary configuration changes for testing or development purposes might be misinterpreted as threats. Ensure that such activities are logged and communicated to the security team to adjust monitoring rules accordingly. + +### Response and remediation + +- Immediately revoke any unauthorized access to the affected GCP storage bucket by reviewing and adjusting IAM policies to ensure only legitimate users have access. +- Conduct a thorough review of recent bucket configuration changes to identify any unauthorized modifications and revert them to their original secure state. +- Isolate the affected storage bucket from the network if suspicious activity is detected, to prevent further unauthorized access or data exfiltration. +- Notify the security operations team and relevant stakeholders about the incident for further investigation and to ensure coordinated response efforts. +- Implement additional logging and monitoring on the affected bucket to detect any further unauthorized access attempts or configuration changes. +- Review and update security policies and access controls for all GCP storage buckets to prevent similar incidents in the future. +- Escalate the incident to the cloud security team for a comprehensive analysis and to determine if further action is required, such as involving legal or compliance teams. + +## Setup The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://cloud.google.com/storage/docs/key-terms#buckets"] diff --git a/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_permissions_modified.toml b/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_permissions_modified.toml index 5aa2543b2d8..eb749c4a286 100644 --- a/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_permissions_modified.toml +++ b/rules/integrations/gcp/defense_evasion_gcp_storage_bucket_permissions_modified.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/21" integration = ["gcp"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -21,7 +21,43 @@ index = ["filebeat-*", "logs-gcp*"] language = "kuery" license = "Elastic License v2" name = "GCP Storage Bucket Permissions Modification" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GCP Storage Bucket Permissions Modification + +Google Cloud Platform (GCP) storage buckets are essential for storing and managing data in the cloud. IAM permissions control access to these buckets, ensuring data security. Adversaries may alter these permissions to bypass security measures, leading to unauthorized data access or exposure. The detection rule identifies successful permission changes, signaling potential misuse or accidental misconfigurations, aiding in timely security audits and responses. + +### Possible investigation steps + +- Review the event logs for the specific action "storage.setIamPermissions" to identify which IAM permissions were modified and by whom. +- Check the event.outcome field to confirm the success of the permission change and correlate it with any recent access attempts or data access patterns. +- Investigate the identity of the user or service account that performed the permission change to determine if it aligns with expected administrative activities. +- Assess the current IAM policy of the affected storage bucket to understand the new permissions and evaluate any potential security risks or exposure. +- Cross-reference the timing of the permission change with other security events or alerts to identify any suspicious activity or patterns. +- Consult with the bucket owner or relevant stakeholders to verify if the permission change was authorized and necessary for operational purposes. + +### False positive analysis + +- Routine administrative updates to IAM permissions can trigger alerts. To manage this, create exceptions for known maintenance windows or specific administrative accounts that regularly perform these updates. +- Automated scripts or tools that adjust permissions as part of their normal operation may cause false positives. Identify these scripts and exclude their actions from triggering alerts by using specific service accounts or tags. +- Changes made by trusted third-party services integrated with GCP might be flagged. Review and whitelist these services if they are verified and necessary for business operations. +- Temporary permission changes for troubleshooting or testing purposes can be mistaken for malicious activity. Document and schedule these changes, and exclude them from alerts during the specified timeframes. +- Permissions modified by cloud management platforms or orchestration tools should be reviewed. If these tools are part of standard operations, consider excluding their actions from the detection rule. + +### Response and remediation + +- Immediately revoke any unauthorized IAM permissions changes by restoring the previous known good configuration for the affected GCP storage bucket. +- Conduct a thorough review of the IAM policy change logs to identify the source and nature of the modification, focusing on the user or service account responsible for the change. +- Isolate the affected storage bucket from external access until the permissions are verified and secured to prevent further unauthorized access. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized changes and the steps taken to mitigate the risk. +- Implement additional monitoring on the affected storage bucket and related IAM policies to detect any further unauthorized changes or suspicious activities. +- Review and update IAM policies to ensure the principle of least privilege is enforced, reducing the risk of similar incidents in the future. +- If the incident is suspected to be part of a larger attack, escalate to incident response teams for a comprehensive investigation and potential involvement of law enforcement if necessary. + +## Setup The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://cloud.google.com/storage/docs/access-control/iam-permissions"] diff --git a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_network_deleted.toml b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_network_deleted.toml index ae837651b9c..c163e2a2b85 100644 --- a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_network_deleted.toml +++ b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_network_deleted.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/22" integration = ["gcp"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,42 @@ index = ["filebeat-*", "logs-gcp*"] language = "kuery" license = "Elastic License v2" name = "GCP Virtual Private Cloud Network Deletion" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GCP Virtual Private Cloud Network Deletion + +Google Cloud Platform's Virtual Private Cloud (VPC) networks are essential for managing isolated network environments within a project, encompassing subnets, routes, and firewalls. Adversaries may target VPC deletions to disrupt operations and evade defenses. The detection rule monitors audit logs for successful VPC deletions, flagging potential malicious activity by correlating specific event actions and outcomes. + +### Possible investigation steps + +- Review the audit logs for the specific event.action value "v*.compute.networks.delete" to identify the exact time and user account associated with the VPC network deletion. +- Check the event.outcome field to confirm the success of the deletion and correlate it with any other suspicious activities around the same timeframe. +- Investigate the user account or service account that performed the deletion to determine if it was authorized and if there are any signs of compromise or misuse. +- Examine the project and network configurations to assess the impact of the VPC deletion on the organization's operations and identify any critical resources that were affected. +- Look for any recent changes in IAM roles or permissions that might have allowed unauthorized users to delete the VPC network. +- Cross-reference the deletion event with other security alerts or incidents to identify potential patterns or coordinated attacks. + +### False positive analysis + +- Routine maintenance activities may involve the deletion of VPC networks as part of infrastructure updates or reconfigurations. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks. +- Automated scripts or tools used for environment cleanup might trigger false positives if they delete VPC networks as part of their operation. Identify these scripts and exclude their actions from triggering alerts by using specific service accounts or tags associated with these tools. +- Development and testing environments often undergo frequent changes, including VPC deletions. Consider excluding these environments from alerts by filtering based on project IDs or environment tags to reduce noise. +- Organizational policy changes might lead to the intentional deletion of VPC networks. Ensure that such policy-driven actions are documented and that the responsible teams are excluded from triggering alerts by using role-based access controls or specific user identifiers. + +### Response and remediation + +- Immediately isolate the affected project by restricting network access to prevent further unauthorized deletions or modifications. +- Review the audit logs to identify the source of the deletion request, including the user account and IP address, and verify if it was authorized. +- Recreate the deleted VPC network using the latest backup or configuration snapshot to restore network operations and minimize downtime. +- Implement additional access controls, such as multi-factor authentication and least privilege principles, to prevent unauthorized access to VPC management. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Escalate the incident to Google Cloud Platform support if necessary, especially if there are indications of a broader compromise or if assistance is needed in recovery. +- Enhance monitoring and alerting for VPC-related activities to detect and respond to similar threats more effectively in the future. + +## Setup The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://cloud.google.com/vpc/docs/vpc"] diff --git a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_created.toml b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_created.toml index 14e579912ce..27707e415c6 100644 --- a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_created.toml +++ b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_created.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/22" integration = ["gcp"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,43 @@ index = ["filebeat-*", "logs-gcp*"] language = "kuery" license = "Elastic License v2" name = "GCP Virtual Private Cloud Route Creation" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GCP Virtual Private Cloud Route Creation + +In Google Cloud Platform, VPC routes dictate the network paths for traffic from VM instances to various destinations, both within and outside the VPC. Adversaries may exploit this by creating routes to reroute or intercept traffic, potentially disrupting or spying on network communications. The detection rule identifies such activities by monitoring specific audit events related to route creation, aiding in the early detection of unauthorized network modifications. + +### Possible investigation steps + +- Review the audit logs for the specific event.dataset:gcp.audit and event.action values (v*.compute.routes.insert or "beta.compute.routes.insert") to identify the exact time and user account associated with the route creation. +- Examine the details of the newly created route, including the destination IP range and next hop, to determine if it aligns with expected network configurations or if it appears suspicious. +- Check the IAM permissions and roles of the user account that created the route to assess if they had the necessary privileges and if those privileges are appropriate for their role. +- Investigate any recent changes in the environment that might explain the route creation, such as new deployments or changes in network architecture. +- Correlate the route creation event with other security events or alerts in the same timeframe to identify potential patterns or coordinated activities that could indicate malicious intent. +- Consult with the network or cloud infrastructure team to verify if the route creation was part of an authorized change or if it was unexpected. + +### False positive analysis + +- Routine network configuration changes by authorized personnel can trigger alerts. To manage this, maintain a list of known IP addresses and users who frequently make legitimate changes and exclude their activities from triggering alerts. +- Automated deployment tools that create or modify routes as part of their normal operation may cause false positives. Identify these tools and their associated service accounts, then configure exceptions for these accounts in the monitoring system. +- Scheduled maintenance activities often involve creating or updating routes. Document these activities and set temporary exceptions during the maintenance window to prevent unnecessary alerts. +- Integration with third-party services might require route creation. Verify these integrations and whitelist the associated actions to avoid false positives. +- Development and testing environments may have frequent route changes. Consider applying different monitoring thresholds or rules for these environments to reduce noise. + +### Response and remediation + +- Immediately isolate the affected VM instances by removing or disabling the suspicious route to prevent further unauthorized traffic redirection. +- Conduct a thorough review of recent route creation activities in the GCP environment to identify any other unauthorized or suspicious routes. +- Revoke any unauthorized access or permissions that may have allowed the adversary to create the route, focusing on IAM roles and service accounts with route creation privileges. +- Notify the security operations team and relevant stakeholders about the incident for awareness and further investigation. +- Implement network monitoring and logging to detect any future unauthorized route creation attempts, ensuring that alerts are configured for similar activities. +- Review and update the GCP VPC network security policies to enforce stricter controls on route creation and modification, limiting these actions to trusted administrators only. +- If applicable, report the incident to Google Cloud support for further assistance and to understand if there are any additional security measures or advisories. + +## Setup The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://cloud.google.com/vpc/docs/routes", "https://cloud.google.com/vpc/docs/using-routes"] diff --git a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_deleted.toml b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_deleted.toml index b0b775a5f06..dbeccf5e981 100644 --- a/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_deleted.toml +++ b/rules/integrations/gcp/defense_evasion_gcp_virtual_private_cloud_route_deleted.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/22" integration = ["gcp"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,43 @@ index = ["filebeat-*", "logs-gcp*"] language = "kuery" license = "Elastic License v2" name = "GCP Virtual Private Cloud Route Deletion" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GCP Virtual Private Cloud Route Deletion + +In GCP, VPC routes dictate network traffic paths between VM instances and other destinations. Adversaries may delete these routes to disrupt traffic flow, potentially evading defenses or impairing network operations. The detection rule monitors audit logs for successful route deletions, flagging potential misuse by identifying specific actions linked to route removal, thus aiding in timely threat response. + +### Possible investigation steps + +- Review the audit logs for the specific event.dataset:gcp.audit and event.action:v*.compute.routes.delete to identify the exact time and user account associated with the route deletion. +- Check the event.outcome:success field to confirm the deletion was successful and not an attempted action. +- Investigate the user account or service account that performed the deletion to determine if it was authorized to make such changes, including reviewing recent activity and permissions. +- Assess the impact of the route deletion by identifying which VPC and network traffic paths were affected, and determine if any critical services were disrupted. +- Correlate the route deletion event with other security events or alerts around the same timeframe to identify potential coordinated actions or broader attack patterns. +- Contact the relevant stakeholders or system owners to verify if the route deletion was intentional and part of a planned change or if it was unauthorized. + +### False positive analysis + +- Routine maintenance activities by network administrators can trigger route deletions. To manage this, create exceptions for known maintenance windows or specific administrator accounts. +- Automated scripts or tools used for network configuration updates may delete and recreate routes as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts. +- Cloud infrastructure changes during deployment processes might involve temporary route deletions. Document these processes and exclude related events from detection during deployment periods. +- Scheduled network reconfigurations that involve route deletions should be logged and excluded from alerts by correlating with change management records. +- Test environments often undergo frequent network changes, including route deletions. Exclude events from test environments by filtering based on project or environment tags. + +### Response and remediation + +- Immediately isolate the affected VPC to prevent further unauthorized network traffic disruptions. This can be done by temporarily disabling external access or applying restrictive firewall rules. +- Review the audit logs to identify the user or service account responsible for the route deletion. Verify if the action was authorized and investigate any anomalies in user behavior or access patterns. +- Restore the deleted route using the latest backup or configuration management tools to re-establish normal network traffic flow. Ensure that the restored route aligns with the intended network architecture. +- Implement additional access controls and monitoring for the affected VPC, such as enabling more granular IAM roles and setting up alerts for any future route modifications. +- Conduct a security review of the affected environment to identify any other potential misconfigurations or vulnerabilities that could be exploited in a similar manner. +- Escalate the incident to the security operations team for further investigation and to determine if the route deletion was part of a larger attack campaign. +- Document the incident, including the root cause analysis and remediation steps taken, to enhance organizational knowledge and improve future incident response efforts. + +## Setup The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://cloud.google.com/vpc/docs/routes", "https://cloud.google.com/vpc/docs/using-routes"] diff --git a/rules/integrations/gcp/exfiltration_gcp_logging_sink_modification.toml b/rules/integrations/gcp/exfiltration_gcp_logging_sink_modification.toml index c1b0254c4f0..000bd8e4d33 100644 --- a/rules/integrations/gcp/exfiltration_gcp_logging_sink_modification.toml +++ b/rules/integrations/gcp/exfiltration_gcp_logging_sink_modification.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/22" integration = ["gcp"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,44 @@ index = ["filebeat-*", "logs-gcp*"] language = "kuery" license = "Elastic License v2" name = "GCP Logging Sink Modification" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GCP Logging Sink Modification + +In GCP, logging sinks are used to route log entries to specified destinations for storage or analysis. Adversaries may exploit this by altering sink configurations to redirect logs to unauthorized locations, facilitating data exfiltration. The detection rule identifies successful modifications to logging sinks, signaling potential misuse by monitoring specific audit events related to sink updates. + +### Possible investigation steps + +- Review the event details for the specific `event.action` field value `google.logging.v*.ConfigServiceV*.UpdateSink` to confirm the type of modification made to the logging sink. +- Check the `event.outcome` field to ensure the modification was successful, as indicated by the value `success`. +- Identify the user or service account responsible for the modification by examining the `actor` or `principalEmail` fields in the audit log. +- Investigate the `resource` field to determine which logging sink was modified and assess its intended purpose and usual configuration. +- Analyze the `destination` field in the sink configuration to verify if the new export destination is authorized and aligns with organizational policies. +- Review historical logs for any previous modifications to the same logging sink to identify patterns or repeated unauthorized changes. +- Correlate this event with other security alerts or anomalies in the environment to assess if this modification is part of a broader attack or data exfiltration attempt. + +### False positive analysis + +- Routine updates to logging sinks by authorized personnel can trigger alerts. To manage this, maintain a list of known and trusted users who regularly perform these updates and create exceptions for their actions. +- Automated processes or scripts that update logging sinks as part of regular maintenance or deployment activities may cause false positives. Identify these processes and exclude their specific actions from triggering alerts. +- Changes to logging sinks during scheduled maintenance windows can be mistaken for unauthorized modifications. Define and exclude these time periods from monitoring to reduce unnecessary alerts. +- Integration with third-party tools that require sink modifications for functionality might generate false positives. Document these integrations and adjust the detection rule to account for their expected behavior. +- Frequent changes in a dynamic environment, such as development or testing environments, can lead to false positives. Consider applying the rule more stringently in production environments while relaxing it in non-production settings. + +### Response and remediation + +- Immediately review the audit logs to confirm the unauthorized modification of the logging sink and identify the source of the change, including the user account and IP address involved. +- Revert the logging sink configuration to its original state to ensure logs are directed to the intended, secure destination. +- Temporarily disable or restrict access to the user account or service account that made the unauthorized change to prevent further unauthorized actions. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized modification and initial containment actions taken. +- Conduct a thorough investigation to determine if any data was exfiltrated and assess the potential impact on the organization. +- Implement additional monitoring and alerting for changes to logging sink configurations to detect similar unauthorized modifications in the future. +- Review and strengthen access controls and permissions related to logging sink configurations to prevent unauthorized modifications, ensuring that only authorized personnel have the necessary permissions. + +## Setup The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://cloud.google.com/logging/docs/export#how_sinks_work"] diff --git a/rules/integrations/gcp/impact_gcp_iam_role_deletion.toml b/rules/integrations/gcp/impact_gcp_iam_role_deletion.toml index c999c7eebe1..da66408034c 100644 --- a/rules/integrations/gcp/impact_gcp_iam_role_deletion.toml +++ b/rules/integrations/gcp/impact_gcp_iam_role_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/22" integration = ["gcp"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,43 @@ index = ["filebeat-*", "logs-gcp*"] language = "kuery" license = "Elastic License v2" name = "GCP IAM Role Deletion" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GCP IAM Role Deletion + +Google Cloud Platform's IAM roles define permissions for actions on resources, crucial for managing access. Adversaries might delete roles to disrupt legitimate user access, hindering operations. The detection rule monitors audit logs for successful role deletions, signaling potential unauthorized access removal, thus aiding in identifying and mitigating such security threats. + +### Possible investigation steps + +- Review the audit logs for the specific event.action:google.iam.admin.v*.DeleteRole to identify the exact role that was deleted and the associated project or resource. +- Identify the user or service account responsible for the deletion by examining the actor information in the audit logs. +- Check the event.timestamp to determine when the role deletion occurred and correlate it with any other suspicious activities around the same time. +- Investigate the event.outcome:success to confirm that the role deletion was completed successfully and assess the potential impact on access and operations. +- Analyze the context of the deletion by reviewing recent changes or activities in the project or organization to understand if the deletion was part of a legitimate change or an unauthorized action. +- Contact the user or team responsible for the project to verify if the role deletion was intentional and authorized, and gather additional context if needed. + +### False positive analysis + +- Routine administrative actions may trigger alerts when roles are deleted as part of regular maintenance or restructuring. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows. +- Automated scripts or tools that manage IAM roles might cause false positives if they delete roles as part of their operation. Identify these scripts and exclude their actions from triggering alerts by using specific service accounts or tags. +- Deletion of temporary or test roles used in development environments can be mistaken for malicious activity. Implement filters to exclude actions within designated development projects or environments. +- Changes in organizational structure or policy might necessitate role deletions, which could be misinterpreted as threats. Document and communicate these changes to the security team to adjust monitoring rules accordingly. +- Third-party integrations or services that manage IAM roles could inadvertently cause false positives. Ensure these services are properly documented and their actions are whitelisted if deemed non-threatening. + +### Response and remediation + +- Immediately revoke any active sessions and credentials associated with the deleted IAM role to prevent unauthorized access. +- Restore the deleted IAM role from a backup or recreate it with the same permissions to ensure legitimate users regain access. +- Conduct a thorough review of recent IAM activity logs to identify any unauthorized changes or suspicious activities related to IAM roles. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring on IAM role changes to detect and alert on any future unauthorized deletions promptly. +- Review and tighten IAM role permissions to ensure the principle of least privilege is enforced, reducing the risk of similar incidents. +- Consider enabling additional security features such as multi-factor authentication (MFA) for accounts with permissions to modify IAM roles. + +## Setup The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://cloud.google.com/iam/docs/understanding-roles"] diff --git a/rules/integrations/gcp/impact_gcp_service_account_deleted.toml b/rules/integrations/gcp/impact_gcp_service_account_deleted.toml index 7f30b45a128..d99fd367405 100644 --- a/rules/integrations/gcp/impact_gcp_service_account_deleted.toml +++ b/rules/integrations/gcp/impact_gcp_service_account_deleted.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/22" integration = ["gcp"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -23,7 +23,42 @@ index = ["filebeat-*", "logs-gcp*"] language = "kuery" license = "Elastic License v2" name = "GCP Service Account Deletion" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GCP Service Account Deletion + +In Google Cloud Platform, service accounts are crucial for enabling applications and VMs to perform authorized actions without user intervention. Adversaries may exploit this by deleting service accounts to disrupt operations or remove access. The detection rule monitors audit logs for successful service account deletions, flagging potential malicious activity to ensure timely investigation and response. + +### Possible investigation steps + +- Review the audit logs for the specific event.action:google.iam.admin.v*.DeleteServiceAccount to identify the exact time and source of the deletion. +- Identify the user or service account that initiated the deletion by examining the actor information in the audit logs. +- Check the event.dataset:gcp.audit logs for any preceding or subsequent actions by the same user or service account to determine if there is a pattern of suspicious activity. +- Investigate the context of the deleted service account, including its permissions and the resources it had access to, to assess the potential impact of its deletion. +- Contact the relevant team or individual responsible for the service account to verify if the deletion was authorized and intentional. +- If unauthorized, review access controls and consider implementing additional security measures to prevent future unauthorized deletions. + +### False positive analysis + +- Routine maintenance or updates may involve the deletion and recreation of service accounts. To manage this, create exceptions for known maintenance activities by excluding specific service account names or associated project IDs during these periods. +- Automated scripts or deployment tools might delete and recreate service accounts as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by filtering based on the user or service account executing the script. +- Organizational policy changes or restructuring can lead to legitimate service account deletions. Coordinate with the IT or security team to document these changes and adjust the detection rule to exclude these known events. +- Test environments often involve frequent creation and deletion of service accounts. Exclude test project IDs or environments from the detection rule to prevent unnecessary alerts. + +### Response and remediation + +- Immediately revoke any permissions associated with the deleted service account to prevent unauthorized access or actions by adversaries exploiting the deletion. +- Restore the deleted service account if possible, using GCP's undelete feature, to minimize disruption to business operations and restore normal functionality. +- Review and audit recent IAM activity logs to identify any unauthorized or suspicious actions that may have preceded or followed the service account deletion. +- Notify the security team and relevant stakeholders about the incident to ensure awareness and facilitate coordinated response efforts. +- Implement additional monitoring on critical service accounts to detect and alert on any further unauthorized deletion attempts. +- Conduct a root cause analysis to determine how the service account deletion was initiated and address any security gaps or misconfigurations that allowed it. +- Enhance access controls and consider implementing multi-factor authentication for actions involving service account management to prevent similar incidents in the future. + +## Setup The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://cloud.google.com/iam/docs/service-accounts"] diff --git a/rules/integrations/gcp/impact_gcp_service_account_disabled.toml b/rules/integrations/gcp/impact_gcp_service_account_disabled.toml index 034f249af9b..b88c8aac57e 100644 --- a/rules/integrations/gcp/impact_gcp_service_account_disabled.toml +++ b/rules/integrations/gcp/impact_gcp_service_account_disabled.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/22" integration = ["gcp"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -23,7 +23,42 @@ index = ["filebeat-*", "logs-gcp*"] language = "kuery" license = "Elastic License v2" name = "GCP Service Account Disabled" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GCP Service Account Disabled + +In Google Cloud Platform, service accounts are crucial for applications and VMs to perform authorized actions without user intervention. Adversaries may disable these accounts to disrupt services, impacting business operations. The detection rule identifies successful disablement actions in audit logs, signaling potential malicious activity by correlating specific event actions and outcomes, thus enabling timely investigation and response. + +### Possible investigation steps + +- Review the audit logs for the specific event.action:google.iam.admin.v*.DisableServiceAccount to identify the exact time and source of the disablement action. +- Identify the user or service account that performed the disablement by examining the actor information in the audit logs. +- Check for any recent changes or unusual activities associated with the disabled service account, such as modifications to permissions or roles. +- Investigate any related events or actions in the audit logs around the same timeframe to identify potential patterns or additional suspicious activities. +- Assess the impact of the disabled service account on business operations by determining which applications or services were using the account. +- Contact relevant stakeholders or application owners to verify if the disablement was authorized or if it was an unexpected action. + +### False positive analysis + +- Routine maintenance activities by administrators may involve disabling service accounts temporarily. To manage this, create exceptions for known maintenance periods or specific administrator actions. +- Automated scripts or tools used for testing or deployment might disable service accounts as part of their process. Identify these scripts and exclude their actions from triggering alerts by using specific identifiers or tags. +- Organizational policy changes or restructuring might lead to intentional service account disablement. Document these changes and update the detection rule to recognize these legitimate actions. +- Service accounts associated with deprecated or retired applications may be disabled as part of cleanup efforts. Maintain an updated list of such applications and exclude related disablement actions from alerts. + +### Response and remediation + +- Immediately isolate the affected service account by revoking its permissions to prevent further unauthorized actions. +- Review the audit logs to identify any other suspicious activities associated with the disabled service account and assess the potential impact on business operations. +- Re-enable the service account if it is determined to be legitimate and necessary for business functions, ensuring that it is secured with appropriate permissions and monitoring. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring and alerting for similar disablement actions on service accounts to detect and respond to future incidents promptly. +- Conduct a root cause analysis to understand how the service account was disabled and address any security gaps or misconfigurations that allowed the incident to occur. +- Consider implementing additional security measures such as multi-factor authentication and least privilege access to enhance the protection of service accounts. + +## Setup The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://cloud.google.com/iam/docs/service-accounts"] diff --git a/rules/integrations/gcp/impact_gcp_storage_bucket_deleted.toml b/rules/integrations/gcp/impact_gcp_storage_bucket_deleted.toml index cfc19dbb136..795577a9a02 100644 --- a/rules/integrations/gcp/impact_gcp_storage_bucket_deleted.toml +++ b/rules/integrations/gcp/impact_gcp_storage_bucket_deleted.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/21" integration = ["gcp"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -21,7 +21,42 @@ index = ["filebeat-*", "logs-gcp*"] language = "kuery" license = "Elastic License v2" name = "GCP Storage Bucket Deletion" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GCP Storage Bucket Deletion + +Google Cloud Platform (GCP) storage buckets are essential for storing and managing data in cloud environments. Adversaries may target these buckets to delete critical data, causing operational disruptions. The detection rule monitors audit logs for deletion actions, identifying potential malicious activity by flagging events where storage buckets are removed, thus enabling timely investigation and response. + +### Possible investigation steps + +- Review the audit logs for the specific event.action "storage.buckets.delete" to identify the user or service account responsible for the deletion. +- Check the timestamp of the deletion event to determine when the bucket was deleted and correlate it with any other suspicious activities around that time. +- Investigate the IP address and location from which the deletion request originated to assess if it aligns with expected access patterns. +- Examine the permissions and roles assigned to the user or service account involved in the deletion to determine if they had legitimate access. +- Look for any recent changes in IAM policies or permissions that might have allowed unauthorized access to the storage bucket. +- Contact the relevant stakeholders or data owners to confirm if the deletion was authorized or if it was unexpected. + +### False positive analysis + +- Routine maintenance or scheduled deletions by authorized personnel can trigger false positives. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for these tasks. +- Automated scripts or applications that manage storage lifecycle policies might delete buckets as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using service account identifiers. +- Development or testing environments often involve frequent creation and deletion of storage buckets. Exclude these environments from monitoring by filtering based on project IDs or environment tags. +- Organizational policy changes that involve restructuring storage resources can lead to legitimate bucket deletions. Coordinate with relevant teams to update detection rules temporarily during such changes. + +### Response and remediation + +- Immediately isolate the affected GCP project to prevent further unauthorized access or actions. This can be done by revoking access keys and permissions for any suspicious accounts identified in the audit logs. +- Restore the deleted storage bucket from the most recent backup to minimize data loss and operational disruption. Ensure that the backup is clean and free from any malicious alterations. +- Conduct a thorough review of IAM roles and permissions associated with the affected storage bucket to ensure that only authorized users have the necessary access. Implement the principle of least privilege. +- Enable versioning on critical storage buckets to protect against accidental or malicious deletions in the future, allowing for easier recovery of deleted objects. +- Set up alerts for any future deletion actions on storage buckets to ensure immediate awareness and response to similar threats. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data were compromised. +- Document the incident, including actions taken and lessons learned, to improve response strategies and update incident response plans for future reference. + +## Setup The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://cloud.google.com/storage/docs/key-terms#buckets"] diff --git a/rules/integrations/gcp/initial_access_gcp_iam_custom_role_creation.toml b/rules/integrations/gcp/initial_access_gcp_iam_custom_role_creation.toml index fbf52054537..b73a99e175e 100644 --- a/rules/integrations/gcp/initial_access_gcp_iam_custom_role_creation.toml +++ b/rules/integrations/gcp/initial_access_gcp_iam_custom_role_creation.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/21" integration = ["gcp"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,42 @@ index = ["filebeat-*", "logs-gcp*"] language = "kuery" license = "Elastic License v2" name = "GCP IAM Custom Role Creation" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GCP IAM Custom Role Creation + +Google Cloud Platform's IAM custom roles allow users to define specific permissions tailored to their needs, offering flexibility in access management. However, adversaries can exploit this by creating roles with excessive permissions, leading to privilege escalation. The detection rule monitors audit logs for successful custom role creation events, helping identify potential unauthorized access attempts by flagging unusual role configurations. + +### Possible investigation steps + +- Review the audit logs for the specific event.action:google.iam.admin.v*.CreateRole to identify the user or service account responsible for creating the custom role. +- Examine the permissions assigned to the newly created custom role to determine if they are excessive or deviate from standard role configurations. +- Check the event.outcome:success field to confirm the successful creation of the role and cross-reference with any recent changes in IAM policies or permissions. +- Investigate the context around the role creation, such as the time of creation and any associated IP addresses or locations, to identify any unusual patterns or anomalies. +- Assess the necessity and justification for the custom role by consulting with the relevant team or individual who requested its creation, ensuring it aligns with organizational policies and needs. + +### False positive analysis + +- Routine administrative actions by authorized personnel can trigger alerts. Regularly review and document legitimate role creation activities to establish a baseline of expected behavior. +- Automated processes or scripts that create roles as part of deployment pipelines may cause false positives. Identify and whitelist these processes to prevent unnecessary alerts. +- Temporary roles created for short-term projects or testing purposes might be flagged. Implement a naming convention for such roles and exclude them from alerts based on this pattern. +- Changes in organizational structure or policy updates can lead to legitimate role creations. Ensure that these changes are communicated to the security team to adjust monitoring rules accordingly. +- Third-party integrations that require custom roles might be misidentified as threats. Maintain an inventory of these integrations and their role requirements to differentiate between legitimate and suspicious activities. + +### Response and remediation + +- Immediately review the audit logs to confirm the creation of the custom role and identify the user or service account responsible for the action. +- Revoke the custom role if it is determined to have excessive permissions or if it was created without proper authorization. +- Conduct a thorough review of the permissions assigned to the custom role to ensure they align with the principle of least privilege. +- Notify the security team and relevant stakeholders about the unauthorized role creation for further investigation and potential escalation. +- Implement additional monitoring on the identified user or service account to detect any further suspicious activities. +- Review and update IAM policies to prevent unauthorized role creation, ensuring that only trusted users have the necessary permissions to create custom roles. +- Enhance detection capabilities by setting up alerts for any future custom role creation events, especially those with high-risk permissions. + +## Setup The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://cloud.google.com/iam/docs/understanding-custom-roles"] diff --git a/rules/integrations/gcp/persistence_gcp_iam_service_account_key_deletion.toml b/rules/integrations/gcp/persistence_gcp_iam_service_account_key_deletion.toml index 18048b305d9..3091a47ed2f 100644 --- a/rules/integrations/gcp/persistence_gcp_iam_service_account_key_deletion.toml +++ b/rules/integrations/gcp/persistence_gcp_iam_service_account_key_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/21" integration = ["gcp"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -23,7 +23,42 @@ index = ["filebeat-*", "logs-gcp*"] language = "kuery" license = "Elastic License v2" name = "GCP IAM Service Account Key Deletion" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GCP IAM Service Account Key Deletion + +In GCP, IAM service account keys authenticate applications to access resources. Regular key rotation is crucial for security. Adversaries might delete keys to disrupt services or cover tracks after unauthorized access. The detection rule monitors audit logs for successful key deletions, flagging potential misuse or policy violations, aiding in timely investigation and response. + +### Possible investigation steps + +- Review the audit logs for the specific event.action: google.iam.admin.v*.DeleteServiceAccountKey to identify the service account key that was deleted. +- Check the event.outcome: success to confirm the key deletion was successful and not an attempted action. +- Identify the user or service account responsible for the deletion by examining the actor information in the audit logs. +- Investigate the context around the deletion event, including the timestamp and any preceding or subsequent actions in the logs, to understand the sequence of events. +- Verify if the key deletion aligns with the organization's key rotation policy or if it appears suspicious or unauthorized. +- Assess the impact of the key deletion on applications or services that rely on the affected service account for authentication. +- If unauthorized activity is suspected, initiate a broader investigation into potential unauthorized access or other malicious activities involving the affected service account. + +### False positive analysis + +- Routine key rotation activities by administrators can trigger alerts. To manage this, establish a baseline of expected key rotation schedules and exclude these from alerts. +- Automated scripts or tools that perform regular maintenance and key management might cause false positives. Identify these scripts and whitelist their actions in the monitoring system. +- Service account keys associated with non-critical or test environments may be deleted frequently as part of normal operations. Consider excluding these environments from the alerting criteria to reduce noise. +- Temporary service accounts used for short-term projects or testing may have keys deleted as part of their lifecycle. Document these accounts and adjust the detection rule to ignore deletions from these specific accounts. + +### Response and remediation + +- Immediately revoke any remaining access for the compromised service account to prevent further unauthorized access to Google Cloud resources. +- Investigate the audit logs to identify any unauthorized actions performed using the deleted key and assess the impact on affected resources. +- Recreate the deleted service account key if necessary, ensuring that the new key is securely stored and access is restricted to authorized personnel only. +- Implement additional monitoring on the affected service account to detect any further suspicious activities or unauthorized access attempts. +- Escalate the incident to the security operations team for a comprehensive review and to determine if further investigation or response is required. +- Review and update the key rotation policy to ensure that service account keys are rotated more frequently and securely managed to prevent similar incidents in the future. + +## Setup The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/gcp/persistence_gcp_key_created_for_service_account.toml b/rules/integrations/gcp/persistence_gcp_key_created_for_service_account.toml index 07b969e6a80..5d1bd27a06c 100644 --- a/rules/integrations/gcp/persistence_gcp_key_created_for_service_account.toml +++ b/rules/integrations/gcp/persistence_gcp_key_created_for_service_account.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/21" integration = ["gcp"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -24,7 +24,42 @@ index = ["filebeat-*", "logs-gcp*"] language = "kuery" license = "Elastic License v2" name = "GCP Service Account Key Creation" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GCP Service Account Key Creation + +In GCP, service accounts are crucial for applications to authenticate and interact with Google services securely. They use cryptographic keys for API access, which, if mismanaged, can be exploited by adversaries to gain unauthorized access. The detection rule monitors audit logs for new key creations, flagging potential misuse by identifying successful key generation events, thus helping to mitigate risks associated with unauthorized access. + +### Possible investigation steps + +- Review the audit logs for the specific event.action: google.iam.admin.v*.CreateServiceAccountKey to identify the service account involved in the key creation. +- Check the event.dataset:gcp.audit logs to determine the user or process that initiated the key creation and verify if it aligns with expected behavior or scheduled tasks. +- Investigate the permissions and roles assigned to the service account to assess the potential impact of the new key being used maliciously. +- Examine the event.outcome:success logs to confirm the successful creation of the key and cross-reference with any recent changes or deployments that might justify the key creation. +- Contact the owner or responsible team for the service account to verify if the key creation was authorized and necessary for their operations. +- Review any recent alerts or incidents related to the service account to identify patterns or repeated unauthorized activities. + +### False positive analysis + +- Routine key rotations by automated processes can trigger alerts. To manage this, identify and whitelist these processes by their service account names or associated metadata. +- Development and testing environments often generate new keys frequently. Exclude these environments from alerts by using environment-specific tags or labels. +- Scheduled maintenance activities by cloud administrators may involve key creation. Document these activities and create exceptions based on the timing and user accounts involved. +- Third-party integrations that require periodic key updates can cause false positives. Maintain a list of trusted third-party services and exclude their key creation events from alerts. +- Internal tools or scripts that programmatically create keys for operational purposes should be reviewed and, if deemed safe, added to an exception list based on their execution context. + +### Response and remediation + +- Immediately revoke the newly created service account key to prevent unauthorized access. This can be done through the GCP Console or using the gcloud command-line tool. +- Conduct a thorough review of the service account's permissions to ensure they are aligned with the principle of least privilege. Remove any unnecessary permissions that could be exploited. +- Investigate the source of the key creation event by reviewing audit logs to identify the user or process responsible for the action. Determine if the action was authorized or if it indicates a potential compromise. +- If unauthorized access is suspected, rotate all keys associated with the affected service account and any other potentially compromised accounts to mitigate further risk. +- Implement additional monitoring and alerting for unusual service account activities, such as unexpected key creations or permission changes, to enhance detection of similar threats in the future. +- Escalate the incident to the security team for further investigation and to determine if additional containment or remediation actions are necessary, including notifying affected stakeholders if a breach is confirmed. + +## Setup The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/gcp/persistence_gcp_service_account_created.toml b/rules/integrations/gcp/persistence_gcp_service_account_created.toml index b929f9b69a2..0a1640f1e17 100644 --- a/rules/integrations/gcp/persistence_gcp_service_account_created.toml +++ b/rules/integrations/gcp/persistence_gcp_service_account_created.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/22" integration = ["gcp"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -24,7 +24,41 @@ index = ["filebeat-*", "logs-gcp*"] language = "kuery" license = "Elastic License v2" name = "GCP Service Account Creation" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GCP Service Account Creation + +In GCP, service accounts enable applications and VMs to interact with APIs securely. While essential for automation, they can be exploited if improperly managed. Adversaries might create service accounts to gain persistent access without detection. The detection rule monitors audit logs for successful service account creations, flagging potential unauthorized activities for further investigation. + +### Possible investigation steps + +- Review the audit logs for the specific event.action:google.iam.admin.v*.CreateServiceAccount to identify the time and source of the service account creation. +- Check the identity of the user or service that initiated the service account creation to determine if it aligns with expected administrative activities. +- Investigate the permissions and roles assigned to the newly created service account to assess if they are excessive or unusual for its intended purpose. +- Correlate the service account creation event with other recent activities in the environment to identify any suspicious patterns or anomalies. +- Verify if the service account is being used by any unauthorized applications or VMs by reviewing recent API calls and access logs associated with the account. + +### False positive analysis + +- Routine service account creation by automated deployment tools or scripts can trigger false positives. Identify and document these tools, then create exceptions in the monitoring system to exclude these known activities. +- Service accounts created by trusted internal teams for legitimate projects may also be flagged. Establish a process for these teams to notify security personnel of planned service account creations, allowing for pre-approval and exclusion from alerts. +- Scheduled maintenance or updates that involve creating temporary service accounts can result in false positives. Coordinate with IT operations to understand their schedules and adjust monitoring rules to accommodate these activities. +- Third-party integrations that require service accounts might be mistakenly flagged. Maintain an inventory of authorized third-party services and their associated service accounts to quickly verify and exclude these from alerts. + +### Response and remediation + +- Immediately disable the newly created service account to prevent any unauthorized access or actions. +- Review the IAM policy and permissions associated with the service account to ensure no excessive privileges were granted. +- Conduct a thorough audit of recent activities performed by the service account to identify any suspicious or unauthorized actions. +- Notify the security team and relevant stakeholders about the potential security incident for further investigation and coordination. +- Implement additional monitoring and alerting for service account creations to detect similar activities in the future. +- If malicious activity is confirmed, follow incident response procedures to contain and remediate any impact, including revoking access and conducting a security review of affected resources. +- Document the incident and response actions taken to improve future detection and response capabilities. + +## Setup The GCP Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://cloud.google.com/iam/docs/service-accounts"] diff --git a/rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml b/rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml index 9b43b940301..e818ff1d14f 100644 --- a/rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml +++ b/rules/integrations/github/defense_evasion_github_protected_branch_settings_changed.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/29" integration = ["github"] maturity = "production" -updated_date = "2024/12/10" +updated_date = "2025/01/10" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." @@ -30,6 +30,40 @@ query = ''' configuration where event.dataset == "github.audit" and github.category == "protected_branch" and event.type == "change" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GitHub Protected Branch Settings Changed + +GitHub's protected branch settings are crucial for maintaining code integrity by enforcing rules like requiring reviews before merging. Adversaries may alter these settings to bypass security measures, facilitating unauthorized code changes. The detection rule monitors audit logs for changes in branch protection, flagging potential defense evasion attempts for further investigation. + +### Possible investigation steps + +- Review the GitHub audit logs to identify the specific changes made to the protected branch settings, focusing on entries where event.dataset is "github.audit" and github.category is "protected_branch". +- Determine the user account responsible for the changes by examining the audit log details, and verify if the account has a legitimate reason to modify branch protection settings. +- Check the timing of the changes to see if they coincide with any other suspicious activities or known incidents within the organization. +- Investigate the context of the change by reviewing recent pull requests or commits to the affected branch to assess if the changes align with ongoing development activities. +- Communicate with the repository owner or relevant team members to confirm if the changes were authorized and necessary for current project requirements. +- Evaluate the impact of the changes on the repository's security posture and consider reverting the changes if they were unauthorized or pose a security risk. + +### False positive analysis + +- Routine updates by trusted team members may trigger alerts. To manage this, create exceptions for specific users or teams who regularly update branch protection settings as part of their role. +- Automated tools or scripts that modify branch settings for legitimate reasons can cause false positives. Identify these tools and whitelist their activities in the monitoring system. +- Scheduled maintenance or policy updates might lead to expected changes in branch protection settings. Document these events and adjust the detection rule to ignore changes during these periods. +- Changes made by administrators during onboarding or offboarding processes can be mistaken for unauthorized activity. Ensure these processes are well-documented and communicated to the security team to prevent unnecessary alerts. + +### Response and remediation + +- Immediately revert any unauthorized changes to the protected branch settings to restore the original security posture. +- Conduct a review of recent commits and merges to the affected branch to identify any unauthorized code changes that may have occurred during the period of altered settings. +- Temporarily restrict access to the repository for users who made unauthorized changes until a full investigation is completed. +- Notify the security team and relevant stakeholders about the incident for further analysis and to determine if additional security measures are needed. +- Implement additional monitoring on the affected repository to detect any further unauthorized changes or suspicious activities. +- Review and update access controls and permissions for the repository to ensure that only authorized personnel can modify branch protection settings. +- Document the incident, including the timeline of events and actions taken, to improve future response efforts and update incident response plans.""" [[rule.threat]] diff --git a/rules/integrations/github/execution_github_app_deleted.toml b/rules/integrations/github/execution_github_app_deleted.toml index 7bced445fa9..c6f0da2a2b8 100644 --- a/rules/integrations/github/execution_github_app_deleted.toml +++ b/rules/integrations/github/execution_github_app_deleted.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/11" integration = ["github"] maturity = "production" -updated_date = "2024/12/10" +updated_date = "2025/01/10" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." @@ -24,6 +24,41 @@ type = "eql" query = ''' configuration where event.dataset == "github.audit" and github.category == "integration_installation" and event.type == "deletion" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GitHub App Deleted + +GitHub Apps are integrations that extend GitHub's functionality, often used to automate workflows or manage repositories. Adversaries might delete these apps to disrupt operations or remove security controls. The detection rule monitors audit logs for app deletions, flagging potential unauthorized actions. By focusing on specific event types and categories, it helps identify suspicious deletions that could indicate malicious activity. + +### Possible investigation steps + +- Review the audit logs for the specific event type "deletion" within the "integration_installation" category to identify the exact GitHub app that was deleted. +- Determine the user or account responsible for the deletion by examining the associated user information in the audit logs. +- Check the timing of the deletion event to see if it coincides with any other suspicious activities or anomalies in the repository or organization. +- Investigate the role and permissions of the user who performed the deletion to assess if they had legitimate access and authorization to delete the app. +- Look into the history of the deleted GitHub app to understand its purpose, usage, and any dependencies it might have had within the organization or repository. +- Communicate with the team or organization members to verify if the deletion was intentional and authorized, or if it was unexpected and potentially malicious. + +### False positive analysis + +- Routine maintenance or updates by authorized personnel can trigger app deletions. Verify with the team responsible for GitHub app management to confirm if the deletion was planned. +- Automated scripts or tools used for managing GitHub apps might inadvertently delete apps during updates or reconfigurations. Review the scripts and ensure they have proper safeguards to prevent accidental deletions. +- Organizational policy changes might lead to the removal of certain apps. Check if there have been recent policy updates that could explain the deletion. +- Exclude specific users or service accounts known to perform legitimate app deletions regularly by creating exceptions in the detection rule. +- Monitor for patterns of deletions that align with scheduled maintenance windows and adjust the rule to ignore these timeframes if they consistently result in false positives. + +### Response and remediation + +- Immediately revoke any compromised credentials or tokens associated with the deleted GitHub app to prevent unauthorized access. +- Restore the deleted GitHub app from a backup or re-install it to ensure continuity of operations and security controls. +- Conduct a thorough review of recent changes and activities in the affected repositories or organization to identify any unauthorized actions or data alterations. +- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordinated response efforts. +- Implement additional monitoring on the affected repositories or organization to detect any further suspicious activities or attempts to delete apps. +- Review and tighten permissions for GitHub apps to ensure only authorized personnel have the ability to delete or modify app installations. +- Escalate the incident to higher-level security management if there is evidence of a broader compromise or if the deletion is part of a larger attack campaign.""" [[rule.threat]] diff --git a/rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml b/rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml index 1d14e096df7..a73ab195a5d 100644 --- a/rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml +++ b/rules/integrations/github/execution_github_high_number_of_cloned_repos_from_pat.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/11" integration = ["github"] maturity = "production" -updated_date = "2024/12/10" +updated_date = "2025/01/10" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." @@ -35,6 +35,40 @@ event.dataset:"github.audit" and event.category:"configuration" and event.action github.programmatic_access_type:("OAuth access token" or "Fine-grained personal access token") and github.repository_public:false ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Cloned GitHub Repos From PAT + +Personal Access Tokens (PATs) facilitate automated access to GitHub repositories, enabling seamless integration and management. However, adversaries can exploit compromised PATs to clone numerous private repositories rapidly, potentially exfiltrating sensitive code. The detection rule identifies unusual cloning activity by monitoring for a surge in unique private repo clones from a single PAT, signaling potential misuse. + +### Possible investigation steps + +- Review the specific personal access token (PAT) involved in the alert to determine its owner and associated user account. +- Analyze the event logs for the PAT to identify the number and names of private repositories cloned, focusing on any unusual or unauthorized access patterns. +- Check the access history of the PAT to see if there are any other suspicious activities or anomalies, such as access from unfamiliar IP addresses or locations. +- Contact the owner of the PAT to verify if the cloning activity was authorized and to gather additional context about the usage of the token. +- Investigate the security posture of the affected repositories, including reviewing access permissions and recent changes to repository settings. +- Consider revoking the compromised PAT and issuing a new one if unauthorized access is confirmed, and ensure the user updates any systems or scripts using the old token. + +### False positive analysis + +- Legitimate automated processes or CI/CD pipelines may trigger multiple clone events. Review and whitelist known IP addresses or tokens associated with these processes to prevent false alerts. +- Developers working on multiple projects might clone several private repositories in a short period. Identify and exclude these users or their tokens from triggering alerts by maintaining a list of frequent cloners. +- Organizational scripts or tools that require cloning multiple repositories for updates or backups can cause false positives. Document these scripts and create exceptions for their associated tokens. +- Scheduled maintenance or migration activities involving repository cloning can be mistaken for suspicious activity. Coordinate with relevant teams to anticipate such events and temporarily adjust detection thresholds or exclude specific tokens. + +### Response and remediation + +- Immediately revoke the compromised Personal Access Token (PAT) to prevent further unauthorized access to private repositories. +- Notify the repository owners and relevant stakeholders about the potential breach to assess the impact and initiate internal incident response procedures. +- Conduct a thorough review of the cloned repositories to identify any sensitive or proprietary information that may have been exposed. +- Implement additional access controls, such as IP whitelisting or two-factor authentication, to enhance security for accessing private repositories. +- Monitor for any unusual activity or further unauthorized access attempts using other PATs or credentials. +- Escalate the incident to the security team for a comprehensive investigation and to determine if any other systems or data have been compromised. +- Update and enforce policies regarding the creation, usage, and management of PATs to prevent similar incidents in the future.""" [[rule.threat]] diff --git a/rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml b/rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml index aeefde947c4..a83a83e5b2e 100644 --- a/rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml +++ b/rules/integrations/github/execution_github_ueba_multiple_behavior_alerts_from_account.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2023/12/14" maturity = "production" -updated_date = "2024/12/10" +updated_date = "2025/01/10" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." @@ -34,6 +34,41 @@ type = "threshold" query = ''' signal.rule.tags:("Use Case: UEBA" and "Data Source: Github") and kibana.alert.workflow_status:"open" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GitHub UEBA - Multiple Alerts from a GitHub Account + +User and Entity Behavior Analytics (UEBA) in GitHub environments helps identify unusual patterns that may indicate compromised accounts or tokens. Adversaries might exploit GitHub by executing multiple unauthorized actions within a short period. This detection rule flags such anomalies by monitoring for multiple alerts from the same user within an hour, aiding in prioritizing potential threats for further investigation. + +### Possible investigation steps + +- Review the alert details in the security dashboard to identify the specific user account associated with the multiple alerts. +- Check the recent activity logs for the identified user in GitHub to determine the nature and frequency of actions performed within the alert timeframe. +- Investigate any recent changes to the user's permissions or access levels that might have facilitated unusual activity. +- Correlate the alert data with other security tools or logs to identify any additional suspicious behavior or related alerts involving the same user. +- Contact the user to verify if the actions were legitimate or if they suspect their account or personal access token (PAT) might be compromised. +- If a compromise is suspected, initiate a password reset and revoke any active PATs for the user, and monitor for any further suspicious activity. + +### False positive analysis + +- High-frequency automated workflows or CI/CD pipelines may trigger multiple alerts within an hour. Review these workflows to ensure they are legitimate and consider adding exceptions for known, non-threatening automation. +- Developers or teams working on time-sensitive projects might perform numerous actions in a short period, leading to false positives. Identify these users or teams and create exceptions to prevent unnecessary alerts. +- Scheduled tasks or scripts that interact with GitHub repositories can generate multiple alerts. Verify the legitimacy of these tasks and exclude them from the rule if they are deemed safe. +- Frequent use of GitHub Actions or bots that perform repetitive tasks could be misinterpreted as suspicious activity. Confirm their purpose and add them to an allowlist if they are part of normal operations. +- Consider implementing a review process for alerts that involve known trusted users or service accounts to quickly dismiss false positives without compromising security. + +### Response and remediation + +- Immediately isolate the affected GitHub account by revoking all active sessions and tokens to prevent further unauthorized actions. +- Conduct a password reset for the compromised account and enforce multi-factor authentication (MFA) to enhance security. +- Review recent activity logs for the affected account to identify any unauthorized changes or data exfiltration, and revert any malicious modifications. +- Notify the account owner and relevant security teams about the potential compromise to ensure awareness and coordinated response efforts. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional accounts or systems are affected. +- Implement additional monitoring on the affected account and related systems to detect any further suspicious activity. +- Update and refine access controls and permissions for the affected account to minimize the risk of future unauthorized actions.""" [[rule.threat]] diff --git a/rules/integrations/github/execution_new_github_app_installed.toml b/rules/integrations/github/execution_new_github_app_installed.toml index 10754ac939c..0cd5b02d081 100644 --- a/rules/integrations/github/execution_new_github_app_installed.toml +++ b/rules/integrations/github/execution_new_github_app_installed.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/29" integration = ["github"] maturity = "production" -updated_date = "2024/12/10" +updated_date = "2025/01/10" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." @@ -30,6 +30,40 @@ type = "eql" query = ''' configuration where event.dataset == "github.audit" and event.action == "integration_installation.create" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating New GitHub App Installed + +GitHub Apps enhance functionality by integrating with repositories and organization data, requiring careful scrutiny upon installation. Adversaries may exploit these apps to gain unauthorized access or manipulate data. The detection rule monitors audit logs for new app installations, flagging potential threats by identifying unauthorized or suspicious integrations, thus safeguarding organizational security. + +### Possible investigation steps + +- Review the audit logs for the specific event.dataset "github.audit" and event.action "integration_installation.create" to identify the newly installed GitHub App. +- Verify the identity of the user or service account that performed the installation to ensure it aligns with expected behavior and authorized personnel. +- Check the permissions requested by the newly installed app to assess the level of access it has to your repositories and organization data. +- Cross-reference the app with a list of approved or trusted applications within your organization to determine if it is authorized. +- Investigate the app's developer or vendor to ensure they are reputable and have a history of secure and reliable applications. +- Communicate with the team or individual responsible for the installation to confirm the app's purpose and necessity within the organization. + +### False positive analysis + +- Frequent installations of trusted internal apps may trigger alerts. To manage this, maintain a list of approved internal apps and create exceptions for these in the detection rule. +- Automated deployment tools that integrate with GitHub might cause false positives. Identify these tools and exclude their installation events from triggering alerts. +- Regular updates or re-installations of existing apps can be mistaken for new installations. Track app version updates separately and adjust the rule to differentiate between updates and new installations. +- Development or testing environments often install and remove apps frequently. Consider excluding these environments from the rule or setting up a separate monitoring process for them. + +### Response and remediation + +- Immediately revoke the permissions of the newly installed GitHub App to prevent any unauthorized access or data manipulation. +- Notify the security team and relevant stakeholders about the unauthorized app installation for awareness and further investigation. +- Conduct a review of recent repository and organization changes to identify any unauthorized modifications or data access that may have occurred. +- If malicious activity is detected, initiate a rollback of affected repositories to a secure state prior to the app installation. +- Escalate the incident to higher-level security management if the app installation is linked to a broader security breach or if sensitive data has been compromised. +- Implement stricter access controls and approval processes for future GitHub App installations to prevent unauthorized installations. +- Update detection mechanisms to include additional indicators of compromise related to GitHub App installations, enhancing future threat detection capabilities.""" [[rule.threat]] diff --git a/rules/integrations/github/impact_github_repository_deleted.toml b/rules/integrations/github/impact_github_repository_deleted.toml index da383c6b1d6..e63c22d1281 100644 --- a/rules/integrations/github/impact_github_repository_deleted.toml +++ b/rules/integrations/github/impact_github_repository_deleted.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/29" integration = ["github"] maturity = "production" -updated_date = "2024/12/10" +updated_date = "2025/01/10" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." @@ -35,6 +35,39 @@ type = "eql" query = ''' configuration where event.module == "github" and event.dataset == "github.audit" and event.action == "repo.destroy" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GitHub Repository Deleted +GitHub repositories are essential for managing code and collaboration within organizations. Adversaries may exploit this by deleting repositories to disrupt operations or erase critical data, potentially indicating a security breach. The detection rule monitors GitHub audit logs for repository deletion events, enabling analysts to swiftly identify and investigate unauthorized actions, thereby mitigating potential data loss and compromise. + +### Possible investigation steps + +- Review the GitHub audit logs to confirm the repository deletion event by checking for entries where event.module is "github", event.dataset is "github.audit", and event.action is "repo.destroy". +- Identify the user account associated with the deletion event and verify their access permissions and recent activity to determine if the action was authorized. +- Contact the user or team responsible for the repository to confirm whether the deletion was intentional and documented. +- Check for any recent changes in user access or permissions that could indicate a compromised account or unauthorized access. +- Investigate any other suspicious activities or alerts related to the same user or repository around the time of the deletion event to identify potential patterns of malicious behavior. +- Assess the impact of the repository deletion on ongoing projects and data availability, and initiate recovery procedures if necessary. + +### False positive analysis + +- Routine repository clean-up activities by authorized personnel may trigger alerts. To manage this, maintain a list of users or teams responsible for such tasks and create exceptions for their actions. +- Automated scripts or tools used for repository management might delete repositories as part of their normal operation. Identify these scripts and exclude their actions from triggering alerts by using specific identifiers or tags. +- Test or temporary repositories that are frequently created and deleted during development cycles can cause false positives. Implement naming conventions for these repositories and configure the rule to ignore deletions matching these patterns. +- Scheduled repository deletions as part of a lifecycle management policy can be mistaken for unauthorized actions. Document these schedules and adjust the detection rule to accommodate these planned activities. + +### Response and remediation + +- Immediately revoke access for any user account associated with the unauthorized repository deletion to prevent further malicious actions. +- Restore the deleted repository from backups or snapshots, if available, to recover lost data and minimize operational disruption. +- Conduct a thorough review of recent access logs and user activities to identify any other suspicious actions or potential indicators of compromise. +- Notify the security team and relevant stakeholders about the incident to ensure coordinated response efforts and awareness. +- Implement additional access controls, such as multi-factor authentication and role-based access, to prevent unauthorized deletions in the future. +- Escalate the incident to higher management and legal teams if intellectual property theft or significant data loss is suspected. +- Enhance monitoring and alerting mechanisms to detect similar unauthorized actions promptly, leveraging the MITRE ATT&CK framework for guidance on potential threat vectors.""" [[rule.threat]] diff --git a/rules/integrations/github/persistence_github_org_owner_added.toml b/rules/integrations/github/persistence_github_org_owner_added.toml index 3046b5e72be..05fc5a2f233 100644 --- a/rules/integrations/github/persistence_github_org_owner_added.toml +++ b/rules/integrations/github/persistence_github_org_owner_added.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/11" integration = ["github"] maturity = "production" -updated_date = "2024/12/10" +updated_date = "2025/01/10" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." @@ -34,6 +34,41 @@ type = "eql" query = ''' iam where event.dataset == "github.audit" and event.action == "org.add_member" and github.permission == "admin" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating New GitHub Owner Added + +GitHub organizations allow collaborative management of repositories, where the 'owner' role grants full administrative control. Adversaries may exploit this by adding unauthorized owners, gaining unrestricted access to sensitive data and settings. The detection rule monitors audit logs for new admin-level additions, flagging potential unauthorized access attempts for further investigation. + +### Possible investigation steps + +- Review the GitHub audit logs to identify the specific user account that was added as an owner, focusing on the event.action "org.add_member" and github.permission "admin". +- Verify the identity and role of the newly added owner by cross-referencing with internal HR or user management systems to confirm if the addition was authorized. +- Check the activity history of the newly added owner account for any suspicious actions or changes made to repositories or settings since their addition. +- Contact the individual or team responsible for managing GitHub organization permissions to confirm if they were aware of and approved the new owner addition. +- Investigate any recent changes in the organization's membership or access policies that might explain the addition of a new owner. +- Assess the potential impact of the new owner's access by reviewing the repositories and sensitive data they now have administrative control over. + +### False positive analysis + +- Legitimate organizational changes: New owners may be added during legitimate restructuring or team expansions. Regularly review and document organizational changes to differentiate between authorized and unauthorized additions. +- Automated processes: Some organizations use automated scripts or tools to manage GitHub permissions, which might trigger this rule. Identify and whitelist these processes to prevent unnecessary alerts. +- Temporary access requirements: Occasionally, temporary owner access might be granted for specific projects or tasks. Implement a process to track and review these temporary changes, ensuring they are reverted once the task is completed. +- Onboarding of new senior staff: When new senior staff members join, they might be added as owners. Establish a clear onboarding process that includes notifying the security team to avoid false positives. +- Cross-functional team collaborations: In some cases, cross-functional teams may require owner-level access for collaboration. Maintain a list of such collaborations and review them periodically to ensure they remain necessary and authorized. + +### Response and remediation + +- Immediately revoke the admin privileges of the newly added GitHub owner to prevent further unauthorized access. +- Conduct a thorough review of recent changes and activities performed by the unauthorized owner to identify any potential data breaches or malicious actions. +- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordinated response efforts. +- Reset credentials and enforce multi-factor authentication for all existing GitHub organization owners to enhance security. +- Review and update access control policies to ensure that owner roles are granted only to verified and necessary personnel. +- Implement additional monitoring and alerting for any future changes to GitHub organization roles to detect similar threats promptly. +- If evidence of compromise is found, consider engaging with a digital forensics team to assess the full impact and scope of the breach.""" [[rule.threat]] diff --git a/rules/integrations/github/persistence_organization_owner_role_granted.toml b/rules/integrations/github/persistence_organization_owner_role_granted.toml index fae3507ce48..43877014ef6 100644 --- a/rules/integrations/github/persistence_organization_owner_role_granted.toml +++ b/rules/integrations/github/persistence_organization_owner_role_granted.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/11" integration = ["github"] maturity = "production" -updated_date = "2024/12/10" +updated_date = "2025/01/10" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." @@ -34,6 +34,39 @@ type = "eql" query = ''' iam where event.dataset == "github.audit" and event.action == "org.update_member" and github.permission == "admin" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GitHub Owner Role Granted To User + +In GitHub organizations, the owner role grants comprehensive administrative privileges, enabling full control over repositories, settings, and data. Adversaries may exploit this by elevating privileges to maintain persistence or exfiltrate data. The detection rule monitors audit logs for changes in member roles to 'admin', signaling potential unauthorized access or privilege escalation attempts, thus aiding in early threat identification. + +### Possible investigation steps + +- Review the audit logs for the specific event where the member's role was changed to 'admin' to identify the user who made the change and the user who received the new role. +- Verify the legitimacy of the role change by contacting the user who was granted the owner role and the user who performed the action to confirm if the change was authorized. +- Check the organization's recent activity logs for any unusual or suspicious actions performed by the user who was granted the owner role, such as changes to repository settings or data access. +- Investigate any recent changes in the organization's membership or permissions that could indicate a broader compromise or unauthorized access. +- Assess the potential impact of the role change by identifying sensitive repositories or data that the new owner role could access, and determine if any data exfiltration or unauthorized changes have occurred. + +### False positive analysis + +- Role changes due to organizational restructuring or legitimate promotions can trigger alerts. Regularly update the list of expected role changes to minimize unnecessary alerts. +- Automated scripts or integrations that manage user roles might inadvertently trigger the rule. Identify and whitelist these scripts to prevent false positives. +- Temporary role assignments for project-specific tasks can be mistaken for unauthorized access. Implement a process to document and pre-approve such temporary changes. +- Changes made by trusted administrators during routine audits or maintenance may be flagged. Maintain a log of scheduled maintenance activities to cross-reference with alerts. +- Onboarding processes that involve granting admin roles to new employees can generate alerts. Ensure that onboarding procedures are documented and known exceptions are configured in the detection system. + +### Response and remediation + +- Immediately revoke the owner role from the user account identified in the alert to prevent further unauthorized access or changes. +- Conduct a thorough review of recent activities performed by the user with the elevated privileges to identify any unauthorized changes or data access. +- Reset the credentials and enforce multi-factor authentication for the affected user account to secure it against further compromise. +- Notify the security team and relevant stakeholders about the potential breach and involve them in the investigation and remediation process. +- Review and update access control policies to ensure that owner roles are granted only through a formal approval process and are regularly audited. +- Implement additional monitoring and alerting for changes to high-privilege roles within the organization to detect similar threats in the future.""" [[rule.threat]] diff --git a/rules/integrations/google_workspace/credential_access_google_workspace_drive_encryption_key_accessed_by_anonymous_user.toml b/rules/integrations/google_workspace/credential_access_google_workspace_drive_encryption_key_accessed_by_anonymous_user.toml index 5af838db9fc..8e0711f0156 100644 --- a/rules/integrations/google_workspace/credential_access_google_workspace_drive_encryption_key_accessed_by_anonymous_user.toml +++ b/rules/integrations/google_workspace/credential_access_google_workspace_drive_encryption_key_accessed_by_anonymous_user.toml @@ -2,7 +2,7 @@ creation_date = "2023/03/21" integration = ["google_workspace"] maturity = "production" -updated_date = "2024/09/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -24,7 +24,43 @@ interval = "10m" language = "eql" license = "Elastic License v2" name = "Google Workspace Drive Encryption Key(s) Accessed from Anonymous User" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Google Workspace Drive Encryption Key(s) Accessed from Anonymous User + +Google Workspace Drive allows users to store and share files, including sensitive encryption keys. If shared improperly, these keys can be accessed by unauthorized users, potentially leading to data breaches. Adversaries exploit links with open access to obtain these keys. The detection rule identifies suspicious activities, such as anonymous access to key files, by monitoring file actions and link visibility settings. + +### Possible investigation steps + +- Review the file activity logs to identify the specific file(s) accessed by the anonymous user, focusing on actions such as "copy", "view", or "download" and the file extensions listed in the query. +- Check the sharing settings of the accessed file(s) to confirm if they are set to "people_with_link" and assess whether this level of access is appropriate for the file's sensitivity. +- Investigate the source of the rogue access link by examining any recent changes to the file's sharing settings or any unusual activity in the file's access history. +- Identify and contact the file owner or relevant stakeholders to verify if the sharing of the file was intentional and authorized. +- Assess the potential impact of the accessed encryption key(s) by determining what systems or data they protect and evaluate the risk of unauthorized access. +- Consider revoking or changing the encryption keys if unauthorized access is confirmed to mitigate potential security risks. + +### False positive analysis + +- Shared project files with encryption keys may trigger alerts if accessed by external collaborators. To manage this, ensure that only trusted collaborators have access and consider using Google Workspace's sharing settings to restrict access to specific users. +- Automated backup systems that access encryption keys for legitimate purposes might be flagged. Verify the source of access and, if legitimate, create an exception for the backup system's IP address or service account. +- Internal users accessing encryption keys via shared links for routine tasks could be misidentified as anonymous users. Encourage users to access files through authenticated sessions and adjust monitoring rules to recognize internal IP ranges or user accounts. +- Third-party integrations that require access to encryption keys might cause false positives. Review the integration's access patterns and whitelist known, secure integrations to prevent unnecessary alerts. +- Temporary access links for external audits or compliance checks can be mistaken for unauthorized access. Use time-bound access links and document these activities to differentiate them from potential threats. + +### Response and remediation + +- Immediately revoke access to the specific Google Workspace Drive file by changing its sharing settings to restrict access to only authorized users. +- Conduct a thorough review of the file's access history to identify any unauthorized access and determine the scope of potential data exposure. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized access and any potential data compromise. +- Rotate and replace any encryption keys that were accessed or potentially compromised to prevent unauthorized use. +- Implement additional monitoring and alerting for similar file types and sharing settings to detect future unauthorized access attempts. +- Escalate the incident to senior management and, if necessary, involve legal or compliance teams to assess any regulatory implications. +- Review and update access policies and sharing settings within Google Workspace to ensure that sensitive files are not shared with open access links. + +## Setup The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. diff --git a/rules/integrations/google_workspace/defense_evasion_google_workspace_new_oauth_login_from_third_party_application.toml b/rules/integrations/google_workspace/defense_evasion_google_workspace_new_oauth_login_from_third_party_application.toml index 35730889fc6..70ede72ca9c 100644 --- a/rules/integrations/google_workspace/defense_evasion_google_workspace_new_oauth_login_from_third_party_application.toml +++ b/rules/integrations/google_workspace/defense_evasion_google_workspace_new_oauth_login_from_third_party_application.toml @@ -2,7 +2,7 @@ creation_date = "2023/03/30" integration = ["google_workspace"] maturity = "production" -updated_date = "2024/09/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -23,7 +23,42 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "First Time Seen Google Workspace OAuth Login from Third-Party Application" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 First Time Seen Google Workspace OAuth Login from Third-Party Application + +OAuth is a protocol that allows third-party applications to access user data without exposing credentials, enhancing security in Google Workspace. However, adversaries can exploit OAuth by using compromised credentials to gain unauthorized access, mimicking legitimate users. The detection rule identifies unusual OAuth logins by monitoring authorization events linked to new third-party applications, flagging potential misuse for further investigation. + +### Possible investigation steps + +- Review the event details to identify the specific third-party application involved by examining the google_workspace.token.client.id field. +- Check the google_workspace.token.scope.data field to understand the scope of permissions granted to the third-party application and assess if they align with expected usage. +- Investigate the user account associated with the OAuth authorization event to determine if there are any signs of compromise or unusual activity. +- Correlate the timestamp of the OAuth login event with other security logs to identify any concurrent suspicious activities or anomalies. +- Verify if the third-party application is known and authorized within the organization by consulting with relevant stakeholders or reviewing application whitelists. +- Assess the risk and impact of the OAuth login by considering the privileges of the user account and the sensitivity of the accessed resources. + +### False positive analysis + +- New legitimate third-party applications: Users may frequently integrate new third-party applications for productivity or collaboration. To manage this, maintain a whitelist of known and trusted applications and exclude them from triggering alerts. +- Regular updates to existing applications: Some applications may update their OAuth client IDs during version upgrades. Monitor application update logs and adjust the detection rule to exclude these known updates. +- Internal development and testing: Organizations developing their own applications may trigger this rule during testing phases. Coordinate with development teams to identify and exclude these internal applications from alerts. +- Frequent use of service accounts: Service accounts used for automation or integration purposes might appear as new logins. Document and exclude these service accounts from the detection rule to prevent false positives. + +### Response and remediation + +- Immediately revoke the OAuth token associated with the suspicious third-party application to prevent further unauthorized access. +- Conduct a thorough review of the affected user's account activity to identify any unauthorized actions or data access that may have occurred. +- Reset the credentials of the affected user and any other users who may have been compromised, ensuring that strong, unique passwords are used. +- Notify the affected user and relevant stakeholders about the incident, providing guidance on recognizing phishing attempts and securing their accounts. +- Implement additional monitoring for the affected user and similar OAuth authorization events to detect any further suspicious activity. +- Escalate the incident to the security operations team for a deeper investigation into potential lateral movement or data exfiltration. +- Review and update OAuth application permissions and policies to ensure that only trusted applications have access to sensitive data and services. + +## Setup The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. ### Important Information Regarding Google Workspace Event Lag Times - As per Google's documentation, Google Workspace administrators may observe lag times ranging from minutes up to 3 days between the time of an event's occurrence and the event being visible in the Google Workspace admin/audit logs. diff --git a/rules/integrations/google_workspace/initial_access_google_workspace_suspended_user_renewed.toml b/rules/integrations/google_workspace/initial_access_google_workspace_suspended_user_renewed.toml index a1022b5fa15..652ba565ac7 100644 --- a/rules/integrations/google_workspace/initial_access_google_workspace_suspended_user_renewed.toml +++ b/rules/integrations/google_workspace/initial_access_google_workspace_suspended_user_renewed.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/17" integration = ["google_workspace"] maturity = "production" -updated_date = "2024/09/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -24,7 +24,40 @@ interval = "10m" language = "kuery" license = "Elastic License v2" name = "Google Workspace Suspended User Account Renewed" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Google Workspace Suspended User Account Renewed + +Google Workspace manages user identities and access, crucial for organizational security. Adversaries may exploit the renewal of suspended accounts to regain unauthorized access, bypassing security measures. The detection rule identifies such events by monitoring specific administrative actions, helping analysts spot potential misuse and maintain secure access controls. + +### Possible investigation steps + +- Review the event logs for the specific action `UNSUSPEND_USER` to identify the user account that was renewed and gather details about the timing and context of the action. +- Check the identity of the administrator or service account that performed the `UNSUSPEND_USER` action to determine if the action was authorized or if there are signs of account compromise. +- Investigate the history of the suspended user account to understand why it was initially suspended and assess any potential risks associated with its renewal. +- Examine recent activity logs for the renewed user account to identify any suspicious behavior or unauthorized access attempts following the account's reactivation. +- Cross-reference the event with other security alerts or incidents to determine if the renewal is part of a broader pattern of suspicious activity within the organization. + +### False positive analysis + +- Routine administrative actions may trigger the rule when IT staff unsuspend accounts for legitimate reasons, such as resolving a temporary issue. To manage this, create exceptions for known IT personnel or specific administrative actions that are part of regular account maintenance. +- Automated processes or scripts that unsuspend accounts as part of a workflow can also lead to false positives. Identify and document these processes, then exclude them from triggering alerts by using specific identifiers or tags associated with the automation. +- User accounts that are temporarily suspended due to policy violations or inactivity and later reinstated can cause false positives. Implement a review process to verify the legitimacy of these reinstatements and adjust the rule to exclude such cases when they are part of a documented policy. + +### Response and remediation + +- Immediately review the user account activity logs to determine if any unauthorized actions were taken after the account was unsuspended. Focus on sensitive data access and changes to security settings. +- Temporarily suspend the user account again to prevent further unauthorized access while the investigation is ongoing. +- Notify the security team and relevant stakeholders about the potential security incident to ensure coordinated response efforts. +- Conduct a thorough review of the account's permissions and access levels to ensure they align with the user's current role and responsibilities. Adjust as necessary to follow the principle of least privilege. +- If malicious activity is confirmed, initiate a password reset for the affected account and any other accounts that may have been compromised. +- Implement additional monitoring on the affected account and similar accounts to detect any further suspicious activity. +- Review and update security policies and procedures related to account suspension and reactivation to prevent similar incidents in the future. + +## Setup The Google Workspace Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. diff --git a/rules/integrations/kubernetes/discovery_denied_service_account_request.toml b/rules/integrations/kubernetes/discovery_denied_service_account_request.toml index 50e54311ef7..ffe59981ec8 100644 --- a/rules/integrations/kubernetes/discovery_denied_service_account_request.toml +++ b/rules/integrations/kubernetes/discovery_denied_service_account_request.toml @@ -2,7 +2,7 @@ creation_date = "2022/09/13" integration = ["kubernetes"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -23,7 +23,43 @@ index = ["logs-kubernetes.*"] language = "kuery" license = "Elastic License v2" name = "Kubernetes Denied Service Account Request" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Kubernetes Denied Service Account Request + +Kubernetes service accounts are integral for managing pod permissions and accessing the API server. They typically follow strict access patterns. Adversaries may exploit compromised service account credentials to probe or manipulate cluster resources, potentially leading to unauthorized access or lateral movement. The detection rule identifies anomalies by flagging unauthorized API requests from service accounts, signaling possible security breaches or misconfigurations. + +### Possible investigation steps + +- Review the specific service account involved in the unauthorized request by examining the kubernetes.audit.user.username field to determine which service account was used. +- Analyze the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm the request was indeed forbidden and identify the nature of the denied request. +- Investigate the source of the request by checking the originating pod or node to understand where the unauthorized request was initiated. +- Examine recent activity logs for the service account to identify any unusual patterns or deviations from its typical behavior. +- Check for any recent changes or deployments in the cluster that might have affected service account permissions or configurations. +- Assess whether there have been any recent security incidents or alerts related to the cluster that could be connected to this unauthorized request. + +### False positive analysis + +- Service accounts used for testing or development may generate unauthorized requests if they are not properly configured. Regularly review and update permissions for these accounts to ensure they align with their intended use. +- Automated scripts or tools that interact with the Kubernetes API might trigger false positives if they use service accounts with insufficient permissions. Ensure these tools have the necessary permissions or adjust the detection rule to exclude known benign activities. +- Misconfigured role-based access control (RBAC) settings can lead to legitimate service accounts being denied access. Conduct periodic audits of RBAC policies to verify that service accounts have appropriate permissions. +- Temporary service accounts created for specific tasks might not have the correct permissions, leading to denied requests. Consider excluding these accounts from the rule if they are known to perform non-threatening activities. +- Service accounts from third-party integrations or plugins may not have the required permissions, resulting in false positives. Validate the permissions needed for these integrations and adjust the rule to exclude their expected behavior. + +### Response and remediation + +- Immediately isolate the affected service account by revoking its access tokens and credentials to prevent further unauthorized API requests. +- Conduct a thorough review of the audit logs to identify any other suspicious activities or unauthorized access attempts associated with the compromised service account. +- Rotate credentials for the affected service account and any other potentially impacted accounts to mitigate the risk of further exploitation. +- Assess and remediate any misconfigurations in role-based access control (RBAC) policies that may have allowed the unauthorized request, ensuring that service accounts have the minimum necessary permissions. +- Escalate the incident to the security operations team for further investigation and to determine if additional containment measures are required. +- Implement enhanced monitoring and alerting for similar unauthorized access attempts to improve detection and response times for future incidents. +- Review and update incident response plans to incorporate lessons learned from this event, ensuring readiness for similar threats in the future. + +## Setup The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/kubernetes/discovery_suspicious_self_subject_review.toml b/rules/integrations/kubernetes/discovery_suspicious_self_subject_review.toml index d0589a903d9..db03c051d9e 100644 --- a/rules/integrations/kubernetes/discovery_suspicious_self_subject_review.toml +++ b/rules/integrations/kubernetes/discovery_suspicious_self_subject_review.toml @@ -2,7 +2,7 @@ creation_date = "2022/06/30" integration = ["kubernetes"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -23,7 +23,42 @@ index = ["logs-kubernetes.*"] language = "kuery" license = "Elastic License v2" name = "Kubernetes Suspicious Self-Subject Review" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Kubernetes Suspicious Self-Subject Review + +Kubernetes uses APIs like selfsubjectaccessreview and selfsubjectrulesreview to allow entities to check their own permissions. While useful for debugging, adversaries can exploit these APIs to assess their access level after compromising service accounts or nodes. The detection rule identifies unusual API calls by non-human identities, flagging potential unauthorized privilege enumeration attempts. + +### Possible investigation steps + +- Review the Kubernetes audit logs to identify the specific service account or node that triggered the alert by examining the kubernetes.audit.user.username or kubernetes.audit.impersonatedUser.username fields. +- Check the context of the API call by analyzing the kubernetes.audit.objectRef.resource field to confirm whether it involved selfsubjectaccessreviews or selfsubjectrulesreviews. +- Investigate the source of the API request by looking at the IP address and user agent in the audit logs to determine if the request originated from a known or expected source. +- Assess the recent activity of the implicated service account or node to identify any unusual patterns or deviations from normal behavior. +- Verify if there have been any recent changes to the permissions or roles associated with the service account or node to understand if the access level has been altered. +- Cross-reference the alert with any other security events or alerts in the environment to determine if this is part of a broader attack or compromise. + +### False positive analysis + +- Service accounts used for automated tasks may trigger this rule if they are programmed to check permissions as part of their routine operations. To handle this, identify these accounts and create exceptions for their specific API calls. +- Nodes performing legitimate self-assessment for compliance or security checks might be flagged. Review the node's purpose and, if necessary, whitelist these actions in the detection rule. +- Development or testing environments where permissions are frequently checked by service accounts can generate false positives. Consider excluding these environments from the rule or adjusting the rule's sensitivity for these specific contexts. +- Regularly scheduled jobs or scripts that include permission checks as part of their execution may cause alerts. Document these jobs and adjust the rule to ignore these specific, non-threatening behaviors. + +### Response and remediation + +- Immediately isolate the compromised service account or node by revoking its access tokens and credentials to prevent further unauthorized actions within the cluster. +- Conduct a thorough review of the audit logs to identify any other suspicious activities or access patterns associated with the compromised identity, focusing on any lateral movement or privilege escalation attempts. +- Rotate credentials and tokens for all service accounts and nodes that may have been exposed or compromised, ensuring that new credentials are distributed securely. +- Implement network segmentation and access controls to limit the ability of compromised identities to interact with sensitive resources or other parts of the cluster. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected. +- Enhance monitoring and alerting for similar suspicious activities by tuning detection systems to recognize patterns of unauthorized privilege enumeration attempts. +- Review and update Kubernetes role-based access control (RBAC) policies to ensure that service accounts and nodes have the minimum necessary permissions, reducing the risk of privilege abuse. + +## Setup The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/kubernetes/execution_user_exec_to_pod.toml b/rules/integrations/kubernetes/execution_user_exec_to_pod.toml index 1c134a8e0b8..9506fe0ac92 100644 --- a/rules/integrations/kubernetes/execution_user_exec_to_pod.toml +++ b/rules/integrations/kubernetes/execution_user_exec_to_pod.toml @@ -2,7 +2,7 @@ creation_date = "2022/05/17" integration = ["kubernetes"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -26,7 +26,42 @@ index = ["logs-kubernetes.*"] language = "kuery" license = "Elastic License v2" name = "Kubernetes User Exec into Pod" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Kubernetes User Exec into Pod + +Kubernetes allows users to execute commands within a pod using the 'exec' command, facilitating temporary shell sessions for legitimate management tasks. However, adversaries can exploit this to gain unauthorized access, potentially exposing sensitive data. The detection rule identifies such misuse by monitoring audit logs for specific patterns, such as allowed 'exec' actions on pods, indicating possible malicious activity. + +### Possible investigation steps + +- Review the Kubernetes audit logs to identify the user who executed the 'exec' command by examining the event.dataset field for "kubernetes.audit_logs". +- Check the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed and determine if the user had legitimate access. +- Investigate the kubernetes.audit.objectRef.resource and kubernetes.audit.objectRef.subresource fields to verify that the action involved a pod and the 'exec' subresource. +- Analyze the context of the pod involved, including its purpose and the data it has access to, to assess the potential impact of the unauthorized access. +- Correlate the event with other logs or alerts to identify any suspicious patterns or repeated unauthorized access attempts by the same user or IP address. +- Review the user's activity history to determine if there are other instances of unusual or unauthorized access attempts within the Kubernetes environment. + +### False positive analysis + +- Routine administrative tasks by DevOps teams can trigger the rule when they use 'exec' for legitimate management purposes. To handle this, create exceptions for specific user accounts or roles that are known to perform these tasks regularly. +- Automated scripts or tools that use 'exec' for monitoring or maintenance can also cause false positives. Identify these scripts and whitelist their associated service accounts or IP addresses. +- Scheduled jobs or cron tasks that require 'exec' to perform updates or checks within pods may be flagged. Exclude these by setting up time-based exceptions for known maintenance windows. +- Development environments where frequent testing and debugging occur using 'exec' can lead to alerts. Implement environment-specific exclusions to reduce noise from non-production clusters. + +### Response and remediation + +- Immediately isolate the affected pod to prevent further unauthorized access or data exposure. This can be done by applying network policies or temporarily scaling down the pod. +- Review the audit logs to identify the user or service account responsible for the 'exec' command and assess whether the access was legitimate or unauthorized. +- Revoke or adjust permissions for the identified user or service account to prevent further unauthorized 'exec' actions. Ensure that only necessary permissions are granted following the principle of least privilege. +- Conduct a thorough investigation of the pod's environment to identify any potential data exposure or tampering. Check for unauthorized changes to configurations, secrets, or data within the pod. +- If unauthorized access is confirmed, rotate any exposed secrets or credentials that the pod had access to, and update any affected systems or services. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems or pods have been compromised. +- Enhance monitoring and alerting for similar 'exec' actions in the future by ensuring that audit logs are continuously reviewed and that alerts are configured to notify the security team of any suspicious activity. + +## Setup The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/kubernetes/initial_access_anonymous_request_authorized.toml b/rules/integrations/kubernetes/initial_access_anonymous_request_authorized.toml index 2fd9df0a9e0..4b2aabf0160 100644 --- a/rules/integrations/kubernetes/initial_access_anonymous_request_authorized.toml +++ b/rules/integrations/kubernetes/initial_access_anonymous_request_authorized.toml @@ -2,7 +2,7 @@ creation_date = "2022/09/13" integration = ["kubernetes"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,42 @@ index = ["logs-kubernetes.*"] language = "kuery" license = "Elastic License v2" name = "Kubernetes Anonymous Request Authorized" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Kubernetes Anonymous Request Authorized + +Kubernetes, a container orchestration platform, manages workloads and services. It uses authentication to control access. Adversaries might exploit anonymous access to perform unauthorized actions without leaving traces. The detection rule identifies unauthorized access by monitoring audit logs for anonymous requests that are allowed, excluding common health check endpoints, to flag potential misuse. + +### Possible investigation steps + +- Review the audit logs for the specific event.dataset:kubernetes.audit_logs to identify the context and details of the anonymous request. +- Examine the kubernetes.audit.user.username field to confirm if the request was made by "system:anonymous" or "system:unauthenticated" and assess the potential risk associated with these accounts. +- Analyze the kubernetes.audit.requestURI to determine the target of the request and verify if it is outside the excluded endpoints (/healthz, /livez, /readyz), which could indicate suspicious activity. +- Investigate the source IP address and other network metadata associated with the request to identify the origin and assess if it aligns with known or expected traffic patterns. +- Check for any subsequent or related activities in the audit logs that might indicate further unauthorized actions or attempts to exploit the cluster. + +### False positive analysis + +- Health check endpoints like /healthz, /livez, and /readyz are already excluded, but ensure any custom health check endpoints are also excluded to prevent false positives. +- Regularly scheduled maintenance tasks or automated scripts that use anonymous access for legitimate purposes should be identified and excluded from the rule to avoid unnecessary alerts. +- Some monitoring tools might use anonymous requests for gathering metrics; verify these tools and exclude their specific request patterns if they are known to be safe. +- Development environments might have different access patterns compared to production; consider creating separate rules or exceptions for non-production clusters to reduce noise. +- Review the audit logs to identify any recurring anonymous requests that are part of normal operations and adjust the rule to exclude these specific cases. + +### Response and remediation + +- Immediately isolate the affected Kubernetes cluster to prevent further unauthorized access and potential lateral movement by the adversary. +- Revoke any anonymous access permissions that are not explicitly required for the operation of the cluster, ensuring that all access is authenticated and authorized. +- Conduct a thorough review of the audit logs to identify any unauthorized actions performed by anonymous users and assess the impact on the cluster. +- Reset credentials and access tokens for any accounts that may have been compromised or used in conjunction with the anonymous access. +- Implement network segmentation to limit the exposure of the Kubernetes API server to only trusted networks and users. +- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or systems are affected. +- Enhance monitoring and alerting for unauthorized access attempts, focusing on detecting and responding to similar threats in the future. + +## Setup The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/kubernetes/persistence_exposed_service_created_with_type_nodeport.toml b/rules/integrations/kubernetes/persistence_exposed_service_created_with_type_nodeport.toml index 84e57ae7e00..5c3537f5e6e 100644 --- a/rules/integrations/kubernetes/persistence_exposed_service_created_with_type_nodeport.toml +++ b/rules/integrations/kubernetes/persistence_exposed_service_created_with_type_nodeport.toml @@ -2,7 +2,7 @@ creation_date = "2022/07/05" integration = ["kubernetes"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -29,7 +29,43 @@ index = ["logs-kubernetes.*"] language = "kuery" license = "Elastic License v2" name = "Kubernetes Exposed Service Created With Type NodePort" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Kubernetes Exposed Service Created With Type NodePort + +Kubernetes NodePort services enable external access to cluster pods by opening a port on each worker node. This can be exploited by attackers to bypass network security, intercept traffic, or establish unauthorized communication channels. The detection rule identifies suspicious NodePort service creation or modification by monitoring Kubernetes audit logs for specific actions and authorization decisions, helping to mitigate potential security risks. + +### Possible investigation steps + +- Review the Kubernetes audit logs to identify the specific service that was created or modified with the type NodePort. Focus on entries where kubernetes.audit.objectRef.resource is "services" and kubernetes.audit.verb is "create", "update", or "patch". +- Check the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed, ensuring that the service creation or modification was authorized. +- Identify the user or service account responsible for the action by examining the relevant fields in the audit logs, such as the user identity or service account name. +- Investigate the context of the NodePort service by reviewing the associated pods and their labels to understand what applications or services are being exposed externally. +- Assess the network security implications by determining if the NodePort service could potentially bypass existing firewalls or security controls, and evaluate the risk of unauthorized access or data interception. +- Verify if the NodePort service is necessary for legitimate business purposes or if it was created without proper justification, indicating potential malicious intent. + +### False positive analysis + +- Routine service updates or deployments may trigger the rule if NodePort services are part of standard operations. To manage this, create exceptions for specific namespaces or service accounts that are known to perform these actions regularly. +- Development or testing environments often use NodePort services for ease of access. Exclude these environments from the rule by filtering based on labels or annotations that identify non-production clusters. +- Automated deployment tools or scripts that configure services as NodePort for legitimate reasons can cause false positives. Identify these tools and add their service accounts to an exception list to prevent unnecessary alerts. +- Internal services that require external access for legitimate business needs might be flagged. Document these services and apply exceptions based on their specific labels or annotations to avoid false alarms. +- Temporary configurations during incident response or troubleshooting might involve NodePort services. Ensure that these activities are logged and approved, and consider temporary exceptions during the incident resolution period. + +### Response and remediation + +- Immediately isolate the affected NodePort service by removing or disabling it to prevent further unauthorized access or traffic interception. +- Review and revoke any unauthorized access or permissions granted to users or service accounts that created or modified the NodePort service. +- Conduct a thorough audit of network traffic logs to identify any suspicious or unauthorized external connections made through the NodePort service. +- Implement network segmentation and firewall rules to restrict external access to critical services and ensure that only necessary ports are exposed. +- Escalate the incident to the security operations team for further investigation and to assess potential impacts on the cluster's security posture. +- Apply security patches and updates to Kubernetes components and worker nodes to mitigate any known vulnerabilities that could be exploited. +- Enhance monitoring and alerting mechanisms to detect future unauthorized NodePort service creations or modifications promptly. + +## Setup The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostipc.toml b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostipc.toml index 6b67122e530..76d953a1684 100644 --- a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostipc.toml +++ b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostipc.toml @@ -2,7 +2,7 @@ creation_date = "2022/07/05" integration = ["kubernetes"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -26,7 +26,43 @@ index = ["logs-kubernetes.*"] language = "kuery" license = "Elastic License v2" name = "Kubernetes Pod Created With HostIPC" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Kubernetes Pod Created With HostIPC + +Kubernetes allows pods to share the host's IPC namespace, enabling inter-process communication. While useful for legitimate applications, adversaries can exploit this to access shared memory and IPC mechanisms, potentially leading to data exposure or privilege escalation. The detection rule identifies suspicious pod creation or modification events that enable host IPC, excluding known benign images, to flag potential security threats. + +### Possible investigation steps + +- Review the Kubernetes audit logs to identify the specific pod creation or modification event that triggered the alert, focusing on the event.dataset field with the value "kubernetes.audit_logs". +- Examine the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed, and verify the identity of the user or service account that initiated the request. +- Investigate the kubernetes.audit.objectRef.resource field to ensure the resource involved is indeed a pod, and check the kubernetes.audit.verb field to determine if the action was a create, update, or patch operation. +- Analyze the kubernetes.audit.requestObject.spec.hostIPC field to confirm that host IPC was enabled, and cross-reference with the kubernetes.audit.requestObject.spec.containers.image field to ensure the image is not part of the known benign list. +- Check for any other pods or processes on the host that might be using the host's IPC namespace, and assess if there is any unauthorized access or data exposure risk. +- Look for any suspicious activity or anomalies in the /dev/shm directory or use the ipcs command to identify any IPC facilities that might be exploited. + +### False positive analysis + +- Pods using hostIPC for legitimate inter-process communication may trigger alerts. Review the pod's purpose and verify if hostIPC is necessary for its function. +- Known benign images, such as monitoring or logging agents, might use hostIPC. Update the exclusion list to include these images if they are verified as non-threatening. +- Development or testing environments often use hostIPC for debugging purposes. Consider excluding these environments from the rule or creating a separate rule with a higher threshold for alerts. +- Automated deployment tools might temporarily use hostIPC during setup. Ensure these tools are recognized and excluded if they are part of a controlled and secure process. +- Regularly review and update the exclusion list to reflect changes in your environment, ensuring that only verified and necessary uses of hostIPC are excluded. + +### Response and remediation + +- Immediately isolate the affected pod to prevent further access to the host's IPC namespace. This can be done by cordoning the node or deleting the pod if necessary. +- Review and revoke any unnecessary permissions or roles that allowed the pod to be created or modified with hostIPC enabled. Ensure that only trusted entities have the capability to modify pod specifications. +- Conduct a thorough audit of other pods and configurations in the cluster to identify any additional instances where hostIPC is enabled without a valid justification. +- Implement network policies to restrict communication between pods and the host, limiting the potential impact of any unauthorized access to the host's IPC mechanisms. +- Escalate the incident to the security operations team for further investigation and to determine if any data exposure or privilege escalation occurred. +- Update security policies and configurations to prevent the use of hostIPC in future pod deployments unless explicitly required and approved. +- Enhance monitoring and alerting to detect similar attempts in the future, ensuring that any unauthorized use of hostIPC is promptly flagged and addressed. + +## Setup The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostnetwork.toml b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostnetwork.toml index e1e7005a68c..1cae4551d6b 100644 --- a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostnetwork.toml +++ b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostnetwork.toml @@ -2,7 +2,7 @@ creation_date = "2022/07/05" integration = ["kubernetes"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -25,7 +25,41 @@ index = ["logs-kubernetes.*"] language = "kuery" license = "Elastic License v2" name = "Kubernetes Pod Created With HostNetwork" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Kubernetes Pod Created With HostNetwork + +Kubernetes allows pods to connect to the host's network namespace using HostNetwork, granting them direct access to the node's network interfaces. This capability can be exploited by attackers to monitor or intercept network traffic, potentially bypassing network policies. The detection rule identifies suspicious pod creation or modification events with HostNetwork enabled, excluding known benign images, to flag potential privilege escalation attempts. + +### Possible investigation steps + +- Review the Kubernetes audit logs to identify the source of the pod creation or modification event, focusing on the user or service account associated with the action. +- Examine the pod's configuration details, especially the containers' images, to determine if any unauthorized or suspicious images are being used, excluding known benign images like "docker.elastic.co/beats/elastic-agent:8.4.0". +- Investigate the network activity of the node where the pod is running to identify any unusual traffic patterns or potential data exfiltration attempts. +- Check the Kubernetes RBAC (Role-Based Access Control) settings to ensure that the user or service account has appropriate permissions and is not overly privileged. +- Assess the necessity of using HostNetwork for the pod in question and determine if it can be reconfigured to operate without this setting to reduce potential security risks. + +### False positive analysis + +- Pods used for monitoring or logging may require HostNetwork access to gather network data across nodes. Users can exclude these by adding their specific container images to the exception list in the detection rule. +- Certain system-level services or infrastructure components might need HostNetwork for legitimate reasons, such as network plugins or ingress controllers. Identify these services and update the rule to exclude their specific images or namespaces. +- Development or testing environments might frequently create pods with HostNetwork for debugging purposes. Consider creating a separate rule or environment-specific exceptions to avoid alert fatigue in these scenarios. +- Pods that are part of a known and trusted deployment process, which require HostNetwork for valid operational reasons, should be documented and excluded from the rule to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected pod by cordoning the node to prevent new pods from being scheduled and draining existing pods to other nodes, except the suspicious one. +- Terminate the suspicious pod to stop any potential malicious activity and prevent further network access. +- Review and revoke any unnecessary permissions or roles associated with the service account used by the pod to limit privilege escalation opportunities. +- Conduct a thorough audit of network policies to ensure they are correctly configured to prevent unauthorized access to the host network. +- Escalate the incident to the security operations team for further investigation and to determine if any data was accessed or exfiltrated. +- Implement additional monitoring and alerting for any future pod creations with HostNetwork enabled to quickly detect similar threats. +- Review and update Kubernetes RBAC policies to enforce the principle of least privilege, ensuring only trusted entities can create pods with HostNetwork enabled. + +## Setup The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostpid.toml b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostpid.toml index 49a1dec6249..0ac43d24b60 100644 --- a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostpid.toml +++ b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_hostpid.toml @@ -2,7 +2,7 @@ creation_date = "2022/07/05" integration = ["kubernetes"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -26,7 +26,43 @@ index = ["logs-kubernetes.*"] language = "kuery" license = "Elastic License v2" name = "Kubernetes Pod Created With HostPID" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Kubernetes Pod Created With HostPID + +Kubernetes allows pods to share the host's process ID (PID) namespace, enabling visibility into host processes. While useful for debugging, this can be exploited by attackers to escalate privileges, especially when combined with privileged containers. The detection rule identifies attempts to create or modify pods with HostPID enabled, excluding known safe images, to flag potential privilege escalation activities. + +### Possible investigation steps + +- Review the Kubernetes audit logs to identify the user or service account responsible for the pod creation or modification attempt. Look for the `kubernetes.audit.user.username` field to determine who initiated the action. +- Examine the `kubernetes.audit.requestObject.spec.containers.image` field to identify the container images used in the pod. Verify if any unknown or suspicious images are being deployed. +- Check the `kubernetes.audit.annotations.authorization_k8s_io/decision` field to confirm that the action was allowed and investigate the context or reason for this decision. +- Investigate the `kubernetes.audit.objectRef.resource` and `kubernetes.audit.verb` fields to understand the specific action taken (create, update, or patch) and the resource involved. +- Assess the necessity and legitimacy of using HostPID in the pod's configuration by consulting with the relevant development or operations teams. Determine if there is a valid use case or if it was potentially misconfigured or maliciously set. +- Review any recent changes in the Kubernetes environment or related configurations that might have led to this alert, focusing on changes around the time the alert was triggered. + +### False positive analysis + +- Known safe images like "docker.elastic.co/beats/elastic-agent:8.4.0" are already excluded, but other internal tools or monitoring agents that require HostPID for legitimate reasons might trigger false positives. Review and identify such images and add them to the exclusion list. +- Development or testing environments often use HostPID for debugging purposes. Consider creating a separate rule or exception for these environments to prevent unnecessary alerts. +- Some system maintenance tasks might require temporary use of HostPID. Document these tasks and schedule them during known maintenance windows, then adjust the rule to exclude these specific time frames. +- Regularly review audit logs to identify patterns of benign HostPID usage. Use this information to refine the rule and reduce false positives by updating the exclusion criteria. +- Collaborate with development and operations teams to understand legitimate use cases for HostPID in your environment, and adjust the rule to accommodate these scenarios without compromising security. + +### Response and remediation + +- Immediately isolate the affected pod to prevent further interaction with the host processes. This can be done by cordoning the node or deleting the pod if necessary. +- Review and revoke any unnecessary permissions or roles that may have allowed the creation of pods with HostPID enabled. Ensure that only trusted users and service accounts have the ability to create such pods. +- Conduct a thorough investigation of the container images used in the pod to ensure they are from trusted sources and have not been tampered with. Remove any untrusted or suspicious images from the registry. +- Check for any unauthorized access or changes to the host system's processes and files. If any malicious activity is detected, take steps to restore affected systems from backups and patch any vulnerabilities. +- Implement network segmentation to limit the communication between pods and the host system, reducing the risk of lateral movement by an attacker. +- Enhance monitoring and logging to capture detailed audit logs of Kubernetes API activities, focusing on changes to pod specifications and the use of HostPID. This will aid in detecting similar threats in the future. +- Escalate the incident to the security operations team for further analysis and to determine if additional security measures or incident response actions are required. + +## Setup The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_sensitive_hostpath_volume.toml b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_sensitive_hostpath_volume.toml index 20c8c18652f..8ef13294ac4 100644 --- a/rules/integrations/kubernetes/privilege_escalation_pod_created_with_sensitive_hostpath_volume.toml +++ b/rules/integrations/kubernetes/privilege_escalation_pod_created_with_sensitive_hostpath_volume.toml @@ -2,7 +2,7 @@ creation_date = "2022/07/11" integration = ["kubernetes"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -26,7 +26,43 @@ index = ["logs-kubernetes.*"] language = "kuery" license = "Elastic License v2" name = "Kubernetes Pod created with a Sensitive hostPath Volume" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Kubernetes Pod created with a Sensitive hostPath Volume + +Kubernetes allows containers to access host filesystems via hostPath volumes, which can be crucial for certain applications. However, if a container is compromised, adversaries can exploit these mounts to access sensitive host data or escalate privileges. The detection rule identifies when pods are created or modified with hostPath volumes pointing to critical directories, signaling potential misuse or security risks. + +### Possible investigation steps + +- Review the Kubernetes audit logs to identify the specific pod creation or modification event that triggered the alert, focusing on the event.dataset field with the value "kubernetes.audit_logs". +- Examine the kubernetes.audit.requestObject.spec.volumes.hostPath.path field to determine which sensitive hostPath was mounted and assess the potential risk associated with that specific path. +- Check the kubernetes.audit.annotations.authorization_k8s_io/decision field to confirm that the action was allowed, and verify the legitimacy of the authorization decision. +- Investigate the kubernetes.audit.requestObject.spec.containers.image field to identify the container image used, ensuring it is not a known or suspected malicious image, and cross-reference with any known vulnerabilities or security advisories. +- Analyze the context of the pod creation or modification by reviewing the kubernetes.audit.verb field to understand whether the action was a create, update, or patch operation, and correlate this with recent changes or deployments in the environment. +- Assess the potential impact on the cluster by identifying other pods or services that might be affected by the compromised pod, especially those with elevated privileges or access to sensitive data. + +### False positive analysis + +- Development environments often use hostPath volumes for testing purposes, which can trigger this rule. To manage this, create exceptions for specific namespaces or labels associated with development workloads. +- Monitoring tools or agents may require access to certain host paths for legitimate reasons. Identify these tools and exclude their specific container images from the rule, similar to the exclusion of the elastic-agent image. +- Backup or logging applications might need access to host directories to perform their functions. Review these applications and consider excluding their specific hostPath configurations if they are deemed non-threatening. +- Some system maintenance tasks might temporarily use hostPath volumes. Document these tasks and schedule them during known maintenance windows, then create temporary exceptions during these periods. +- Custom scripts or automation tools that interact with Kubernetes may inadvertently trigger this rule. Audit these scripts and tools, and if they are safe, exclude their specific actions or paths from the rule. + +### Response and remediation + +- Immediately isolate the affected pod to prevent further access to sensitive host data. This can be done by cordoning the node or deleting the pod if necessary. +- Review and revoke any credentials or tokens that may have been exposed through the compromised pod to prevent unauthorized access to other resources. +- Conduct a thorough analysis of the container image and application code to identify any vulnerabilities or malicious code that may have led to the compromise. +- Patch or update the container image and application code to address any identified vulnerabilities, and redeploy the application with the updated image. +- Implement network policies to restrict pod-to-pod and pod-to-node communication, limiting the potential impact of a compromised pod. +- Enhance monitoring and logging for Kubernetes audit logs to ensure timely detection of similar threats in the future, focusing on unauthorized access attempts and privilege escalation activities. +- Escalate the incident to the security operations team for further investigation and to assess the need for additional security measures or incident response actions. + +## Setup The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/kubernetes/privilege_escalation_privileged_pod_created.toml b/rules/integrations/kubernetes/privilege_escalation_privileged_pod_created.toml index f1f93659d1d..2b97c237a44 100644 --- a/rules/integrations/kubernetes/privilege_escalation_privileged_pod_created.toml +++ b/rules/integrations/kubernetes/privilege_escalation_privileged_pod_created.toml @@ -2,7 +2,7 @@ creation_date = "2022/07/05" integration = ["kubernetes"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -26,7 +26,41 @@ index = ["logs-kubernetes.*"] language = "kuery" license = "Elastic License v2" name = "Kubernetes Privileged Pod Created" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Kubernetes Privileged Pod Created + +Kubernetes allows for the creation of privileged pods, which can access the host's resources, breaking container isolation. Adversaries may exploit this to escalate privileges, access sensitive data, or establish persistence. The detection rule identifies such events by monitoring audit logs for pod creation with privileged settings, excluding known safe images, to flag potential security threats. + +### Possible investigation steps + +- Review the Kubernetes audit logs to identify the user or service account responsible for creating the privileged pod by examining the `kubernetes.audit.annotations.authorization_k8s_io/decision` and `kubernetes.audit.verb:create` fields. +- Investigate the context of the privileged pod creation by checking the `kubernetes.audit.requestObject.spec.containers.image` field to determine if the image used is known or potentially malicious. +- Assess the necessity and legitimacy of the privileged pod by consulting with the relevant development or operations teams to understand if there was a valid reason for its creation. +- Examine the `kubernetes.audit.objectRef.resource:pods` field to identify the specific pod and its associated namespace, and verify if it aligns with expected deployment patterns or environments. +- Check for any subsequent suspicious activities or anomalies in the Kubernetes environment that may indicate further exploitation attempts, such as lateral movement or data exfiltration, following the creation of the privileged pod. + +### False positive analysis + +- Known safe images like "docker.elastic.co/beats/elastic-agent:8.4.0" are already excluded from triggering alerts. Ensure that any additional internal or third-party images that are verified as safe are added to the exclusion list to prevent unnecessary alerts. +- Development and testing environments often use privileged pods for legitimate purposes. Consider creating separate rules or exceptions for these environments to avoid false positives while maintaining security in production. +- Automated deployment tools or scripts might create privileged pods as part of their normal operation. Review these tools and, if they are deemed safe, add their specific actions or images to the exclusion list. +- Regularly review and update the exclusion list to reflect changes in your environment, such as new safe images or changes in deployment practices, to maintain an accurate detection rule. + +### Response and remediation + +- Immediately isolate the affected node to prevent further exploitation and lateral movement within the cluster. This can be done by cordoning and draining the node to stop new pods from being scheduled and to safely evict existing pods. +- Terminate the privileged pod to stop any ongoing malicious activity. Ensure that the termination is logged for further analysis. +- Conduct a thorough review of the audit logs to identify any unauthorized access or actions taken by the privileged pod. Focus on any attempts to access sensitive data or escalate privileges. +- Reset credentials and access tokens that may have been exposed or compromised due to the privileged pod's access to the host's resources. +- Patch and update the Kubernetes environment and any affected nodes to address vulnerabilities that may have been exploited to create the privileged pod. +- Implement network segmentation and firewall rules to limit the communication capabilities of pods, especially those with elevated privileges, to reduce the risk of lateral movement. +- Escalate the incident to the security operations team for a comprehensive investigation and to assess the need for further security measures or incident response actions. + +## Setup The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/kubernetes/privilege_escalation_suspicious_assignment_of_controller_service_account.toml b/rules/integrations/kubernetes/privilege_escalation_suspicious_assignment_of_controller_service_account.toml index 051c4b214e9..c8cabc87d9b 100644 --- a/rules/integrations/kubernetes/privilege_escalation_suspicious_assignment_of_controller_service_account.toml +++ b/rules/integrations/kubernetes/privilege_escalation_suspicious_assignment_of_controller_service_account.toml @@ -2,7 +2,7 @@ creation_date = "2022/09/13" integration = ["kubernetes"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -24,7 +24,43 @@ index = ["logs-kubernetes.*"] language = "kuery" license = "Elastic License v2" name = "Kubernetes Suspicious Assignment of Controller Service Account" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Kubernetes Suspicious Assignment of Controller Service Account + +Kubernetes uses service accounts to manage pod permissions, with controller service accounts in the kube-system namespace having elevated privileges. Adversaries may exploit this by assigning these accounts to pods, gaining admin-level access. The detection rule identifies such suspicious assignments by monitoring audit logs for pod creation events in the kube-system namespace with controller service accounts, flagging potential privilege escalation attempts. + +### Possible investigation steps + +- Review the audit logs to confirm the presence of a "create" event for a pod in the "kube-system" namespace with a service account name containing "controller". +- Identify the source of the request by examining the user or service account that initiated the pod creation event in the audit logs. +- Check the history of the involved service account to determine if it has been used in any other suspicious activities or unauthorized access attempts. +- Investigate the pod's configuration and associated resources to understand its purpose and whether it aligns with expected operations within the cluster. +- Assess the potential impact by evaluating the permissions and roles associated with the controller service account assigned to the pod. +- Review recent changes or deployments in the "kube-system" namespace to identify any unauthorized modifications or anomalies. + +### False positive analysis + +- Routine maintenance tasks in the kube-system namespace may involve creating or modifying pods with elevated service accounts. Review the context of such actions to determine if they are part of scheduled maintenance or updates. +- Automated deployment tools might temporarily assign controller service accounts to pods for configuration purposes. Verify if these actions align with known deployment processes and consider excluding these specific tools from triggering alerts. +- Legitimate testing or debugging activities by cluster administrators could involve using controller service accounts. Ensure these activities are documented and consider creating exceptions for known testing environments. +- Some monitoring or logging solutions might require elevated permissions and could inadvertently trigger this rule. Validate the necessity of these permissions and whitelist these solutions if they are deemed non-threatening. +- Regularly review and update the list of known benign service account assignments to ensure that only unexpected or unauthorized assignments are flagged. + +### Response and remediation + +- Immediately isolate the affected pod by cordoning the node it is running on to prevent further scheduling of pods and drain the node if necessary to stop the pod from executing. +- Revoke the service account token associated with the suspicious pod to prevent further unauthorized access or actions using the compromised credentials. +- Conduct a thorough review of recent changes in the kube-system namespace to identify unauthorized modifications or deployments, focusing on the creation and modification of pods and service accounts. +- Reset credentials and rotate keys for any service accounts that may have been compromised to ensure that any stolen credentials are rendered useless. +- Implement network policies to restrict pod-to-pod communication within the kube-system namespace, limiting the potential lateral movement of an attacker. +- Escalate the incident to the security operations team for further investigation and to determine if additional clusters or systems have been affected. +- Enhance monitoring and alerting for similar activities by ensuring audit logs are comprehensive and that alerts are configured to detect unauthorized service account assignments promptly. + +## Setup The Kubernetes Fleet integration with Audit Logs enabled or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_process_args.toml b/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_process_args.toml index 34ee5a28519..8b31089d5c9 100644 --- a/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_process_args.toml +++ b/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_process_args.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/12" integration = ["lmd", "endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] anomaly_threshold = 70 @@ -52,6 +52,40 @@ tags = [ "Tactic: Lateral Movement", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Mean of Process Arguments in an RDP Session + +Remote Desktop Protocol (RDP) facilitates remote access to systems, often targeted by adversaries for lateral movement. Attackers may exploit RDP by executing complex commands with numerous arguments to obfuscate their actions. The detection rule leverages machine learning to identify anomalies in process arguments, flagging potential misuse indicative of sophisticated attacks. + +### Possible investigation steps + +- Review the specific RDP session details, including the source and destination IP addresses, to identify any unusual or unauthorized access patterns. +- Analyze the process arguments flagged by the machine learning model to determine if they include known malicious commands or patterns indicative of obfuscation or redirection. +- Check the user account associated with the RDP session for any signs of compromise, such as recent password changes or login attempts from unusual locations. +- Correlate the alert with other security events or logs, such as firewall logs or intrusion detection system alerts, to identify any related suspicious activities or lateral movement attempts. +- Investigate the historical behavior of the involved systems and users to determine if the high number of process arguments is an anomaly or part of a regular pattern. + +### False positive analysis + +- Routine administrative tasks may generate a high number of process arguments, such as batch scripts or automated maintenance operations. Users can create exceptions for known scripts or processes that are regularly executed by trusted administrators. +- Software updates or installations often involve complex commands with multiple arguments. To mitigate false positives, users should whitelist update processes from trusted vendors. +- Monitoring and management tools that perform extensive logging or diagnostics can trigger this rule. Users should identify and exclude these tools if they are verified as non-threatening. +- Custom applications or scripts developed in-house may use numerous arguments for configuration purposes. Users should document and exclude these applications if they are part of normal business operations. +- Scheduled tasks that run during off-hours might appear suspicious due to their complexity. Users can adjust the rule to ignore these tasks if they are part of a regular, approved schedule. + +### Response and remediation + +- Isolate the affected system from the network to prevent further lateral movement and potential data exfiltration. +- Terminate any suspicious RDP sessions and associated processes that exhibit high numbers of arguments to halt ongoing malicious activities. +- Conduct a thorough review of the affected system's event logs and process execution history to identify any unauthorized access or changes made during the RDP session. +- Reset credentials for any accounts that were accessed during the suspicious RDP session to prevent unauthorized access using compromised credentials. +- Apply security patches and updates to the affected system and any other systems within the network to mitigate vulnerabilities that could be exploited for similar attacks. +- Enhance monitoring and logging for RDP sessions across the network to detect and respond to similar anomalies more quickly in the future. +- 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.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_session_duration.toml b/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_session_duration.toml index 0b13d9e762e..817f0cf6740 100644 --- a/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_session_duration.toml +++ b/rules/integrations/lmd/lateral_movement_ml_high_mean_rdp_session_duration.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/12" integration = ["lmd", "endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] anomaly_threshold = 70 @@ -52,6 +52,41 @@ tags = [ "Tactic: Lateral Movement", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Mean of RDP Session Duration + +Remote Desktop Protocol (RDP) enables remote access to systems, facilitating administrative tasks. However, adversaries exploit prolonged RDP sessions to maintain persistent access, potentially conducting lateral movements undetected. The 'High Mean of RDP Session Duration' detection rule leverages machine learning to identify anomalies in session lengths, flagging potential misuse indicative of malicious activity. + +### Possible investigation steps + +- Review the specific RDP session details, including the start and end times, to understand the duration and identify any patterns or anomalies in session lengths. +- Correlate the flagged RDP session with user activity logs to determine if the session aligns with expected user behavior or if it deviates from normal patterns. +- Check for any concurrent or subsequent suspicious activities, such as file transfers or command executions, that might indicate lateral movement or data exfiltration. +- Investigate the source and destination IP addresses involved in the RDP session to identify if they are known, trusted, or associated with any previous security incidents. +- Analyze the user account involved in the RDP session for any signs of compromise, such as recent password changes, failed login attempts, or unusual access patterns. +- Review any recent changes in the network or system configurations that might have affected RDP session durations or security settings. + +### False positive analysis + +- Extended RDP sessions for legitimate administrative tasks can trigger false positives. To manage this, identify and whitelist IP addresses or user accounts associated with routine administrative activities. +- Scheduled maintenance or software updates often require prolonged RDP sessions. Exclude these activities by setting time-based exceptions during known maintenance windows. +- Remote support sessions from trusted third-party vendors may appear as anomalies. Create exceptions for these vendors by verifying their IP addresses and adding them to an allowlist. +- Training sessions or demonstrations using RDP can result in longer session durations. Document and exclude these events by correlating them with scheduled training times and user accounts involved. +- Automated scripts or processes that maintain RDP sessions for monitoring purposes can be mistaken for threats. Identify these scripts and exclude their associated user accounts or machine names from the detection rule. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious or unauthorized RDP sessions to cut off potential adversary access. +- Conduct a thorough review of user accounts and permissions on the affected system to identify and disable any compromised accounts. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Restore the system from a known good backup if any unauthorized changes or malware are detected. +- Monitor network traffic and logs for any signs of further exploitation attempts or related suspicious activity. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/integrations/lmd/lateral_movement_ml_high_remote_file_size.toml b/rules/integrations/lmd/lateral_movement_ml_high_remote_file_size.toml index 910d0e198f5..8dfcae92b72 100644 --- a/rules/integrations/lmd/lateral_movement_ml_high_remote_file_size.toml +++ b/rules/integrations/lmd/lateral_movement_ml_high_remote_file_size.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/12" integration = ["lmd", "endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] anomaly_threshold = 70 @@ -53,6 +53,40 @@ tags = [ "Tactic: Lateral Movement", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Size +Machine learning models in security environments analyze file transfer patterns to identify anomalies, such as unusually large files shared remotely. Adversaries exploit this by aggregating data into large files to avoid detection during lateral movement. The 'Unusual Remote File Size' rule leverages ML to flag these anomalies, aiding in early detection of potential data exfiltration activities. + +### Possible investigation steps + +- Review the alert details to identify the specific remote host and file size involved in the anomaly. +- Check the historical file transfer patterns of the identified remote host to determine if this large file size is truly unusual. +- Investigate the contents and purpose of the large file, if accessible, to assess whether it contains sensitive or valuable information. +- Analyze network logs to trace the origin and destination of the file transfer, looking for any unauthorized or suspicious connections. +- Correlate the event with other security alerts or logs to identify any concurrent suspicious activities that might indicate lateral movement or data exfiltration. +- Verify the user account associated with the file transfer to ensure it has not been compromised or misused. + +### False positive analysis + +- Large file transfers related to legitimate business operations, such as backups or data migrations, can trigger false positives. Users should identify and whitelist these routine activities to prevent unnecessary alerts. +- Software updates or patches distributed across the network may also appear as unusually large file transfers. Establishing a baseline for expected file sizes during these updates can help in distinguishing them from potential threats. +- Remote file sharing services used for collaboration might generate alerts if large files are shared frequently. Monitoring and excluding these services from the rule can reduce false positives. +- Automated data processing tasks that involve transferring large datasets between systems should be documented and excluded from the rule to avoid false alarms. +- Regularly review and update the list of known safe hosts and services that are permitted to transfer large files, ensuring that only legitimate activities are excluded from detection. + +### Response and remediation + +- Isolate the affected host immediately to prevent further lateral movement and potential data exfiltration. Disconnect it from the network to contain the threat. +- Conduct a thorough analysis of the large file transfer to determine its contents and origin. Verify if sensitive data was included and assess the potential impact. +- Review and terminate any unauthorized remote sessions or connections identified during the investigation to prevent further exploitation. +- Reset credentials and review access permissions for the affected host and any associated accounts to mitigate the risk of compromised credentials being used for further attacks. +- Implement network segmentation to limit the ability of attackers to move laterally within the network, reducing the risk of similar incidents in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation actions are taken. +- Enhance monitoring and logging for unusual file transfer activities and remote access attempts to improve early detection of similar threats in the future.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/integrations/lmd/lateral_movement_ml_high_variance_rdp_session_duration.toml b/rules/integrations/lmd/lateral_movement_ml_high_variance_rdp_session_duration.toml index 9002606a3a3..05052fda4e6 100644 --- a/rules/integrations/lmd/lateral_movement_ml_high_variance_rdp_session_duration.toml +++ b/rules/integrations/lmd/lateral_movement_ml_high_variance_rdp_session_duration.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/12" integration = ["lmd", "endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] anomaly_threshold = 70 @@ -52,6 +52,41 @@ tags = [ "Tactic: Lateral Movement", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Variance in RDP Session Duration + +Remote Desktop Protocol (RDP) enables remote access to systems, facilitating legitimate administrative tasks. However, adversaries exploit prolonged RDP sessions to maintain persistent access, often for lateral movement within networks. The detection rule leverages machine learning to identify anomalies in session duration, flagging potential misuse by highlighting sessions with unusually high variance, which may indicate malicious activity. + +### Possible investigation steps + +- Review the specific RDP session details, including the start and end times, to understand the duration and identify any patterns or anomalies in session length. +- Correlate the flagged RDP session with user activity logs to determine if the session aligns with known user behavior or scheduled administrative tasks. +- Investigate the source and destination IP addresses involved in the RDP session to identify any unusual or unauthorized access points. +- Check for any concurrent alerts or logs indicating lateral movement or other suspicious activities originating from the same source or targeting the same destination. +- Analyze the user account associated with the RDP session for any signs of compromise, such as recent password changes, failed login attempts, or unusual access times. +- Review the network traffic during the RDP session for any signs of data exfiltration or communication with known malicious IP addresses. + +### False positive analysis + +- Long RDP sessions for legitimate administrative tasks can trigger false positives. To manage this, identify and whitelist IP addresses or user accounts associated with routine administrative activities. +- Scheduled maintenance or updates often require extended RDP sessions. Exclude these sessions by setting time-based exceptions during known maintenance windows. +- Automated scripts or tools that require prolonged RDP access for monitoring or data collection can be mistaken for anomalies. Document and exclude these processes by recognizing their unique session patterns. +- Remote support sessions from trusted third-party vendors may appear as high variance. Establish a list of trusted vendor IPs or accounts to prevent these from being flagged. +- Training or demonstration sessions that involve extended RDP use should be accounted for by creating exceptions for specific user groups or departments involved in such activities. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further lateral movement and potential data exfiltration. +- Terminate the suspicious RDP session to disrupt any ongoing unauthorized activities. +- Conduct a thorough review of the affected system for signs of compromise, including checking for unauthorized user accounts, installed software, and changes to system configurations. +- Reset credentials for any accounts that were accessed during the suspicious RDP session to prevent further unauthorized access. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Monitor network traffic and system logs for any signs of continued or related suspicious activity, focusing on RDP connections and lateral movement patterns. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_directory.toml b/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_directory.toml index 95486b7b141..0252319a055 100644 --- a/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_directory.toml +++ b/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_directory.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/12" integration = ["lmd", "endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] anomaly_threshold = 70 @@ -52,6 +52,41 @@ tags = [ "Tactic: Lateral Movement", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Directory + +The 'Unusual Remote File Directory' detection leverages machine learning to identify atypical file transfers in directories not commonly monitored, which may indicate lateral movement by adversaries. Attackers exploit these less scrutinized paths to evade detection, often using remote services to transfer malicious payloads. This rule flags such anomalies, aiding in early detection of potential breaches. + +### Possible investigation steps + +- Review the alert details to identify the specific unusual directory involved in the file transfer and note any associated file names or types. +- Check the source and destination IP addresses involved in the transfer to determine if they are known or trusted entities within the network. +- Investigate the user account associated with the file transfer to verify if the activity aligns with their typical behavior or role within the organization. +- Examine recent logs or events from the host to identify any other suspicious activities or anomalies that may correlate with the file transfer. +- Cross-reference the detected activity with known threat intelligence sources to determine if the file transfer or directory is associated with any known malicious campaigns or tactics. +- Assess the potential impact of the file transfer by evaluating the sensitivity of the data involved and the criticality of the systems affected. + +### False positive analysis + +- Routine administrative tasks may trigger alerts if they involve file transfers to directories not typically monitored. Users can create exceptions for known administrative activities to prevent unnecessary alerts. +- Automated backup processes might be flagged if they store files in uncommon directories. Identifying and excluding these backup operations can reduce false positives. +- Software updates or patches that deploy files to less common directories could be mistaken for suspicious activity. Users should whitelist these update processes to avoid false alerts. +- Development or testing environments often involve file transfers to non-standard directories. Users can configure exceptions for these environments to minimize false positives. +- Legitimate remote services used for file transfers, such as cloud storage synchronization, may be flagged. Users should identify and exclude these trusted services from monitoring. + +### Response and remediation + +- Isolate the affected host immediately to prevent further lateral movement and contain the potential threat. Disconnect it from the network to stop any ongoing malicious activity. +- Conduct a thorough analysis of the unusual directory and any files transferred to identify malicious payloads. Use endpoint detection and response (EDR) tools to scan for known malware signatures and behaviors. +- Remove any identified malicious files and artifacts from the affected directory and host. Ensure that all traces of the threat are eradicated to prevent re-infection. +- Reset credentials and review access permissions for the affected host and any associated accounts to mitigate the risk of unauthorized access. Ensure that least privilege principles are enforced. +- Monitor network traffic and logs for any signs of further lateral movement or exploitation attempts. Pay special attention to remote service connections and unusual directory access. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional hosts or systems are compromised. +- Update detection mechanisms and rules to enhance monitoring of less common directories and improve the detection of similar threats in the future.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_extension.toml b/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_extension.toml index e652d49aef9..dccf3526e38 100644 --- a/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_extension.toml +++ b/rules/integrations/lmd/lateral_movement_ml_rare_remote_file_extension.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/12" integration = ["lmd", "endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] anomaly_threshold = 70 @@ -51,6 +51,41 @@ tags = [ "Tactic: Lateral Movement", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Extension + +The detection of unusual remote file extensions leverages machine learning to identify anomalies in file transfers, which may suggest lateral movement by adversaries. Attackers often exploit remote services to transfer files with uncommon extensions, bypassing standard security measures. This rule flags such anomalies, aiding in early detection of potential threats by correlating rare file extensions with known lateral movement tactics. + +### Possible investigation steps + +- Review the alert details to identify the specific file extension and the source and destination of the file transfer. +- Check the historical data for the identified file extension to determine if it has been used previously in legitimate activities or if it is indeed rare. +- Investigate the source host to identify any recent changes or suspicious activities, such as new user accounts or unusual login patterns. +- Examine the destination host for any signs of compromise or unauthorized access, focusing on recent file modifications or unexpected processes. +- Correlate the file transfer event with other security alerts or logs to identify potential patterns of lateral movement or exploitation of remote services. +- Consult threat intelligence sources to determine if the rare file extension is associated with known malware or adversary tactics. + +### False positive analysis + +- Common internal file transfers with rare extensions may trigger false positives. Review and whitelist known benign file extensions used by internal applications or processes. +- Automated backup or synchronization tools might use uncommon file extensions. Identify these tools and create exceptions for their typical file extensions to prevent unnecessary alerts. +- Development environments often generate files with unique extensions. Collaborate with development teams to understand these patterns and exclude them from detection if they are verified as non-threatening. +- Security tools or scripts that transfer diagnostic or log files with unusual extensions can be mistaken for lateral movement. Document these tools and adjust the rule to ignore their specific file extensions. +- Regularly review and update the list of excluded extensions to ensure it reflects current operational practices and does not inadvertently allow malicious activity. + +### Response and remediation + +- Isolate the affected host immediately to prevent further lateral movement and contain the potential threat. +- Review and terminate any suspicious remote sessions or connections identified on the host to cut off unauthorized access. +- Conduct a thorough scan of the affected system for malware or unauthorized software that may have been transferred using the unusual file extension. +- Restore the affected system from a known good backup if any malicious activity or compromise is confirmed. +- Update and patch all software and systems on the affected host to close any vulnerabilities that may have been exploited. +- Monitor network traffic for any further unusual file transfers or connections, focusing on rare file extensions and remote service exploitation patterns. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_from_a_source_ip.toml b/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_from_a_source_ip.toml index f2f1c672314..72ccbba305d 100644 --- a/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_from_a_source_ip.toml +++ b/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_from_a_source_ip.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/12" integration = ["lmd", "endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] anomaly_threshold = 70 @@ -52,6 +52,41 @@ tags = [ "Tactic: Lateral Movement", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Spike in Number of Connections Made from a Source IP + +Remote Desktop Protocol (RDP) is a common tool for remote management, but adversaries exploit it for lateral movement within networks. By establishing numerous connections from a single IP, attackers seek to expand their access. This detection rule leverages machine learning to identify unusual spikes in RDP connections, signaling potential unauthorized access attempts, and aids in early threat identification. + +### Possible investigation steps + +- Review the source IP address to determine if it is a known or trusted entity within the network. +- Analyze the list of destination IPs to identify any unusual or unauthorized systems being accessed. +- Check the timestamps of the connections to see if they align with expected activity patterns or occur during unusual hours. +- Investigate the user account associated with the RDP connections to verify if it has been compromised or is being misused. +- Correlate the spike in connections with any recent changes or incidents in the network that might explain the activity. +- Examine network logs and RDP session logs for any signs of suspicious behavior or anomalies during the connection attempts. + +### False positive analysis + +- Routine administrative tasks can trigger spikes in RDP connections. Regularly scheduled maintenance or software updates may cause a high number of connections from a single IP. To manage this, identify and whitelist IPs associated with known administrative activities. +- Automated scripts or tools used for network management might establish multiple RDP connections. Review and document these tools, then create exceptions for their IP addresses to prevent false alerts. +- Load balancers or proxy servers can appear as a single source IP making numerous connections. Verify the network architecture and exclude these IPs from the rule to avoid misidentification. +- Security scans or vulnerability assessments conducted by internal teams can result in a spike of connections. Coordinate with security teams to recognize these activities and exclude their IPs from triggering the rule. +- Remote work solutions or VPNs might centralize connections through a single IP, leading to false positives. Identify these IPs and adjust the rule to accommodate legitimate remote access patterns. + +### Response and remediation + +- Isolate the affected system immediately to prevent further lateral movement within the network. Disconnect it from the network or place it in a quarantine VLAN. +- Terminate any unauthorized RDP sessions originating from the identified source IP to halt ongoing unauthorized access attempts. +- Conduct a thorough review of the affected system for signs of compromise, including checking for unauthorized user accounts, changes in system configurations, and the presence of malware or suspicious files. +- Reset credentials for any accounts accessed via the compromised system to prevent further unauthorized access using stolen credentials. +- Implement network segmentation to limit RDP access to only necessary systems and users, reducing the attack surface for lateral movement. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the full scope of the breach. +- Update and enhance monitoring rules to detect similar patterns of unusual RDP connection spikes, ensuring early detection of future attempts.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_to_a_destination_ip.toml b/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_to_a_destination_ip.toml index b155d1cd313..aa4363695b3 100644 --- a/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_to_a_destination_ip.toml +++ b/rules/integrations/lmd/lateral_movement_ml_spike_in_connections_to_a_destination_ip.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/12" integration = ["lmd", "endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] anomaly_threshold = 70 @@ -52,6 +52,40 @@ tags = [ "Tactic: Lateral Movement", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Spike in Number of Connections Made to a Destination IP + +Remote Desktop Protocol (RDP) is crucial for remote management and troubleshooting in IT environments. However, adversaries exploit RDP by using multiple compromised IPs to overwhelm a target, ensuring persistence even if some IPs are blocked. The detection rule leverages machine learning to identify unusual spikes in RDP connections to a single IP, signaling potential lateral movement attempts by attackers. + +### Possible investigation steps + +- Review the list of source IPs that have established RDP connections to the destination IP to identify any known malicious or suspicious IP addresses. +- Check historical data for the destination IP to determine if it has been targeted in previous attacks or if it is a high-value asset within the network. +- Analyze the timing and frequency of the RDP connections to identify any unusual patterns or spikes that could indicate coordinated activity. +- Investigate the user accounts associated with the RDP connections to ensure they are legitimate and have not been compromised. +- Correlate the detected activity with any other security alerts or logs to identify potential lateral movement or further exploitation attempts within the network. + +### False positive analysis + +- Routine administrative tasks may trigger false positives if multiple IT staff connect to a server for maintenance. Consider creating exceptions for known administrative IPs. +- Automated scripts or monitoring tools that frequently connect to servers for health checks can cause spikes. Identify and exclude these IPs from the rule. +- Load balancers or proxy servers that aggregate connections from multiple clients might appear as a spike. Exclude these devices from the detection rule. +- Scheduled software updates or deployments that require multiple connections to a server can be mistaken for an attack. Whitelist the IPs involved in these processes. +- Internal network scans or vulnerability assessments conducted by security teams can generate high connection counts. Ensure these activities are recognized and excluded. + +### Response and remediation + +- Immediately isolate the affected destination IP from the network to prevent further unauthorized RDP connections and potential lateral movement. +- Conduct a thorough review of the logs and network traffic associated with the destination IP to identify all source IPs involved in the spike and assess the scope of the compromise. +- Block all identified malicious source IPs at the firewall or network perimeter to prevent further connections to the destination IP. +- Reset credentials and enforce multi-factor authentication for accounts that were accessed via RDP to mitigate unauthorized access. +- Perform a security assessment of the affected systems to identify any signs of compromise or unauthorized changes, and restore systems from clean backups if necessary. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or networks are affected. +- Update and enhance monitoring rules to detect similar patterns of unusual RDP connection spikes in the future, ensuring quick identification and response to potential threats.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/integrations/lmd/lateral_movement_ml_spike_in_rdp_processes.toml b/rules/integrations/lmd/lateral_movement_ml_spike_in_rdp_processes.toml index 6da8b35fb4b..1881a7cc400 100644 --- a/rules/integrations/lmd/lateral_movement_ml_spike_in_rdp_processes.toml +++ b/rules/integrations/lmd/lateral_movement_ml_spike_in_rdp_processes.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/12" integration = ["lmd", "endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] anomaly_threshold = 70 @@ -51,6 +51,40 @@ tags = [ "Tactic: Lateral Movement", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Spike in Number of Processes in an RDP Session + +Remote Desktop Protocol (RDP) allows users to connect to other computers over a network, facilitating remote work and administration. However, adversaries can exploit RDP for lateral movement by executing numerous processes on a target machine. The detection rule leverages machine learning to identify anomalies in process activity during RDP sessions, flagging potential exploitation attempts indicative of lateral movement tactics. + +### Possible investigation steps + +- Review the specific RDP session details, including the source and destination IP addresses, to identify the involved machines and users. +- Analyze the list of processes that were started during the RDP session to identify any unusual or suspicious processes that are not typically associated with legitimate remote work activities. +- Check the user account associated with the RDP session for any signs of compromise, such as recent password changes or unusual login times. +- Correlate the detected spike in processes with other security events or logs, such as firewall logs or intrusion detection system alerts, to identify any related suspicious activities. +- Investigate the network traffic between the source and destination machines during the RDP session to detect any anomalies or unauthorized data transfers. +- Review historical data for the involved user and machines to determine if similar spikes in process activity have occurred in the past, which could indicate a pattern of malicious behavior. + +### False positive analysis + +- High-volume automated tasks or scripts executed during RDP sessions can trigger false positives. Identify and document these tasks, then create exceptions in the detection rule to exclude them from analysis. +- Routine administrative activities, such as software updates or system maintenance, may result in a spike in processes. Regularly review and whitelist these activities to prevent unnecessary alerts. +- Scheduled batch jobs or data processing tasks that run during RDP sessions can be mistaken for lateral movement. Ensure these are logged and excluded from the rule's scope by setting up appropriate filters. +- Development or testing environments where multiple processes are frequently started as part of normal operations can lead to false positives. Clearly define these environments and adjust the rule to ignore such sessions. + +### Response and remediation + +- Isolate the affected machine from the network to prevent further lateral movement and contain the threat. +- Terminate any suspicious or unauthorized processes identified during the RDP session to halt potential malicious activity. +- Conduct a thorough review of the affected machine's security logs to identify any additional indicators of compromise or related suspicious activity. +- Reset credentials for any accounts that were used during the suspicious RDP session to prevent unauthorized access. +- Apply security patches and updates to the affected machine and any other vulnerable systems to mitigate exploitation of known vulnerabilities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Enhance monitoring and detection capabilities for RDP sessions by implementing stricter access controls and logging to detect similar anomalies in the future.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/integrations/lmd/lateral_movement_ml_spike_in_remote_file_transfers.toml b/rules/integrations/lmd/lateral_movement_ml_spike_in_remote_file_transfers.toml index 793014dff2b..4ac117d38c3 100644 --- a/rules/integrations/lmd/lateral_movement_ml_spike_in_remote_file_transfers.toml +++ b/rules/integrations/lmd/lateral_movement_ml_spike_in_remote_file_transfers.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/12" integration = ["lmd", "endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] anomaly_threshold = 70 @@ -53,6 +53,41 @@ tags = [ "Tactic: Lateral Movement", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Spike in Remote File Transfers + +Remote file transfer technologies facilitate data sharing across networks, essential for collaboration and operations. However, adversaries exploit these to move laterally within a network, often transferring data stealthily to avoid detection. The 'Spike in Remote File Transfers' detection rule leverages machine learning to identify unusual transfer volumes, signaling potential malicious activity by comparing against established network baselines. + +### Possible investigation steps + +- Review the alert details to identify the specific host and time frame associated with the abnormal file transfer activity. +- Analyze network logs and remote file transfer logs to determine the source and destination of the transfers, focusing on any unusual or unauthorized endpoints. +- Cross-reference the identified host with known assets and user accounts to verify if the activity aligns with expected behavior or if it involves unauthorized access. +- Investigate any associated user accounts for signs of compromise, such as unusual login times or locations, by reviewing authentication logs. +- Check for any recent changes or anomalies in the network baseline that could explain the spike in file transfers, such as new software deployments or legitimate large data migrations. +- Correlate the detected activity with other security alerts or incidents to identify potential patterns or coordinated attacks within the network. + +### False positive analysis + +- Regularly scheduled data backups or synchronization tasks can trigger false positives. Identify these tasks and create exceptions to prevent them from being flagged. +- Automated software updates or patch management systems may cause spikes in file transfers. Exclude these systems from the rule to reduce false alerts. +- Internal data sharing between departments for legitimate business purposes might be misidentified. Establish a baseline for these activities and adjust the detection thresholds accordingly. +- High-volume data transfers during specific business operations, such as end-of-month reporting, can be mistaken for malicious activity. Temporarily adjust the rule settings during these periods to accommodate expected increases in transfer volumes. +- Frequent file transfers from trusted external partners or vendors should be monitored and, if consistently benign, added to an allowlist to minimize unnecessary alerts. + +### Response and remediation + +- Isolate the affected host immediately to prevent further lateral movement and potential data exfiltration. Disconnect it from the network to contain the threat. +- Conduct a thorough analysis of the transferred files to determine if sensitive data was involved and assess the potential impact of the data exposure. +- Review and terminate any unauthorized remote access sessions or services on the affected host to prevent further exploitation. +- Reset credentials for any accounts that were used or potentially compromised during the incident to prevent unauthorized access. +- Apply security patches and updates to the affected systems to address any vulnerabilities that may have been exploited by the attackers. +- Monitor network traffic for any additional unusual remote file transfer activities, using enhanced logging and alerting 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 ensure comprehensive remediation efforts are undertaken.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/integrations/lmd/lateral_movement_ml_unusual_time_for_an_rdp_session.toml b/rules/integrations/lmd/lateral_movement_ml_unusual_time_for_an_rdp_session.toml index 91706bb4f63..46c9a8e41c7 100644 --- a/rules/integrations/lmd/lateral_movement_ml_unusual_time_for_an_rdp_session.toml +++ b/rules/integrations/lmd/lateral_movement_ml_unusual_time_for_an_rdp_session.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/12" integration = ["lmd", "endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] anomaly_threshold = 70 @@ -52,6 +52,41 @@ tags = [ "Tactic: Lateral Movement", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Time or Day for an RDP Session + +Remote Desktop Protocol (RDP) enables remote access to systems, crucial for IT management but also a target for adversaries seeking unauthorized access. Attackers exploit RDP by initiating sessions at odd hours to avoid detection. The detection rule leverages machine learning to identify atypical RDP session timings, flagging potential lateral movement attempts for further investigation. + +### Possible investigation steps + +- Review the timestamp of the RDP session to determine the specific unusual time or day it was initiated, and correlate it with known business hours or scheduled maintenance windows. +- Identify the source and destination IP addresses involved in the RDP session to determine if they are internal or external, and check for any known associations with previous security incidents. +- Examine the user account used to initiate the RDP session, verifying if it is a legitimate account and if the login aligns with the user's typical behavior or role within the organization. +- Check for any additional suspicious activities or alerts involving the same user account or IP addresses around the time of the unusual RDP session, such as failed login attempts or access to sensitive files. +- Investigate any recent changes or anomalies in the network or system configurations that could have facilitated the unusual RDP session, such as newly opened ports or modified firewall rules. +- Consult logs from other security tools or systems, such as SIEM or endpoint detection and response (EDR) solutions, to gather more context on the RDP session and any related activities. + +### False positive analysis + +- Regular maintenance activities by IT staff during off-hours can trigger false positives. Identify and document these activities to create exceptions in the detection rule. +- Scheduled automated tasks or scripts that initiate RDP sessions at unusual times may be misclassified. Review and whitelist these tasks to prevent unnecessary alerts. +- Time zone differences for remote employees accessing systems outside of standard business hours can lead to false positives. Adjust detection parameters to account for these time zone variations. +- Third-party vendors or contractors who require access at non-standard times should be documented and their access patterns reviewed to establish exceptions. +- Emergency access situations where IT staff need to respond to critical incidents outside normal hours should be logged and considered when analyzing alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate the suspicious RDP session to halt any ongoing unauthorized activities. +- Conduct a thorough review of the affected system's logs and processes to identify any malicious activities or changes made during the session. +- Reset credentials for any accounts accessed during the unusual RDP session to prevent further unauthorized use. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised. +- Implement enhanced monitoring on the affected system and related network segments to detect any further suspicious activities or attempts at unauthorized access.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/integrations/o365/collection_microsoft_365_new_inbox_rule.toml b/rules/integrations/o365/collection_microsoft_365_new_inbox_rule.toml index 9cd9d0b4429..9860dbe73d5 100644 --- a/rules/integrations/o365/collection_microsoft_365_new_inbox_rule.toml +++ b/rules/integrations/o365/collection_microsoft_365_new_inbox_rule.toml @@ -2,7 +2,7 @@ creation_date = "2021/03/29" integration = ["o365"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic", "Gary Blackwell", "Austin Songer"] @@ -23,7 +23,43 @@ index = ["filebeat-*", "logs-o365*"] language = "kuery" license = "Elastic License v2" name = "Microsoft 365 Inbox Forwarding Rule Created" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft 365 Inbox Forwarding Rule Created + +Microsoft 365 allows users to create inbox rules to automate email management, such as forwarding messages to another address. While useful, attackers can exploit these rules to secretly redirect emails, facilitating data exfiltration. The detection rule monitors for the creation of such forwarding rules, focusing on successful events that specify forwarding parameters, thus identifying potential unauthorized email redirection activities. + +### Possible investigation steps + +- Review the event details to identify the user account associated with the creation of the forwarding rule by examining the o365.audit.Parameters. +- Check the destination email address specified in the forwarding rule (ForwardTo, ForwardAsAttachmentTo, or RedirectTo) to determine if it is an external or suspicious address. +- Investigate the user's recent activity logs in Microsoft 365 to identify any unusual or unauthorized actions, focusing on event.dataset:o365.audit and event.provider:Exchange. +- Verify if the user has a legitimate reason to create such a forwarding rule by consulting with their manager or reviewing their role and responsibilities. +- Assess if there have been any recent security incidents or alerts related to the user or the destination email address to identify potential compromise. +- Consider disabling the forwarding rule temporarily and notifying the user and IT security team if the rule appears suspicious or unauthorized. + +### False positive analysis + +- Legitimate forwarding rules set by users for convenience or workflow purposes may trigger alerts. Review the context of the rule creation, such as the user and the destination address, to determine if it aligns with normal business operations. +- Automated systems or third-party applications that integrate with Microsoft 365 might create forwarding rules as part of their functionality. Identify these systems and consider excluding their associated accounts from the rule. +- Temporary forwarding rules set during user absence, such as vacations or leaves, can be mistaken for malicious activity. Implement a process to document and approve such rules, allowing for their exclusion from monitoring during the specified period. +- Internal forwarding to trusted domains or addresses within the organization might not pose a security risk. Establish a list of trusted internal addresses and configure exceptions for these in the detection rule. +- Frequent rule changes by specific users, such as IT administrators or support staff, may be part of their job responsibilities. Monitor these accounts separately and adjust the rule to reduce noise from expected behavior. + +### Response and remediation + +- Immediately disable the forwarding rule by accessing the affected user's mailbox settings in Microsoft 365 and removing any unauthorized forwarding rules. +- Conduct a thorough review of the affected user's email account for any signs of compromise, such as unusual login activity or unauthorized changes to account settings. +- Reset the password for the affected user's account and enforce multi-factor authentication (MFA) to prevent further unauthorized access. +- Notify the user and relevant IT security personnel about the incident, providing details of the unauthorized rule and any potential data exposure. +- Escalate the incident to the security operations team for further investigation and to determine if other accounts may have been targeted or compromised. +- Implement additional monitoring on the affected account and similar high-risk accounts to detect any further suspicious activity or rule changes. +- Review and update email security policies and configurations to prevent similar incidents, ensuring that forwarding rules are monitored and restricted as necessary. + +## Setup The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/o365/credential_access_microsoft_365_brute_force_user_account_attempt.toml b/rules/integrations/o365/credential_access_microsoft_365_brute_force_user_account_attempt.toml index ceb1b377150..a1fb6bacac4 100644 --- a/rules/integrations/o365/credential_access_microsoft_365_brute_force_user_account_attempt.toml +++ b/rules/integrations/o365/credential_access_microsoft_365_brute_force_user_account_attempt.toml @@ -4,7 +4,7 @@ integration = ["o365"] maturity = "production" min_stack_comments = "ES|QL not available until 8.13.0 in technical preview." min_stack_version = "8.13.0" -updated_date = "2024/10/09" +updated_date = "2025/01/10" [rule] author = ["Elastic", "Willem D'Haese", "Austin Songer"] @@ -86,6 +86,41 @@ from logs-o365.audit-* // filter for users with more than 20 login sources or failed login attempts | where (login_source_count >= 20 or failed_login_count >= 20) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Attempts to Brute Force a Microsoft 365 User Account + +Microsoft 365 is a cloud-based service that provides productivity tools and services. Adversaries may attempt to gain unauthorized access by brute-forcing user accounts, exploiting weak passwords. The detection rule identifies such attempts by analyzing audit logs for numerous failed logins or diverse login sources within a short timeframe, indicating potential brute-force activity. + +### Possible investigation steps + +- Review the audit logs for the specific user identified by o365.audit.UserId to gather additional context on the failed login attempts, including timestamps and source IP addresses. +- Analyze the source.ip field to identify any unusual or suspicious IP addresses, such as those originating from unexpected geographic locations or known malicious sources. +- Check the o365.audit.LogonError field for any patterns or specific errors that might provide insight into the nature of the failed login attempts. +- Investigate the o365.audit.ExtendedProperties.RequestType to determine if the login attempts were consistent with typical user behavior or if they suggest automated or scripted activity. +- Correlate the findings with other security events or alerts in the environment to assess if the brute-force attempts are part of a larger attack campaign or isolated incidents. +- Contact the affected user to verify if they experienced any issues accessing their account and to ensure they are aware of the potential security threat. + +### False positive analysis + +- High volume of legitimate login attempts from a single user can trigger false positives, especially during password resets or account recovery. To mitigate, consider excluding specific users or IP ranges known for such activities. +- Automated scripts or applications performing frequent logins for legitimate purposes may be misidentified as brute-force attempts. Identify and whitelist these scripts or applications by their user IDs or IP addresses. +- Users traveling or using VPNs may log in from multiple locations in a short period, leading to false positives. Implement geolocation-based exceptions for known travel patterns or VPN IP addresses. +- Shared accounts accessed by multiple users from different locations can appear as multiple login sources. Limit monitoring on shared accounts or establish a baseline of expected behavior to differentiate between normal and suspicious activity. +- Temporary spikes in login attempts due to system maintenance or updates can be mistaken for brute-force attacks. Schedule monitoring exclusions during planned maintenance windows to avoid false alerts. + +### Response and remediation + +- Immediately isolate the affected user account by disabling it to prevent further unauthorized access attempts. +- Notify the user and relevant IT security personnel about the potential compromise and provide guidance on secure password creation. +- Conduct a password reset for the affected user account, ensuring the new password adheres to strong password policies. +- Review and analyze the source IP addresses involved in the failed login attempts to identify any patterns or known malicious sources. +- Implement conditional access policies to restrict login attempts from suspicious or untrusted locations and devices. +- Monitor the affected account and related accounts for any unusual activity or further unauthorized access attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional accounts or systems are affected.""" [[rule.threat]] diff --git a/rules/integrations/o365/credential_access_microsoft_365_potential_password_spraying_attack.toml b/rules/integrations/o365/credential_access_microsoft_365_potential_password_spraying_attack.toml index 7b2baeefe60..2f554d1dadf 100644 --- a/rules/integrations/o365/credential_access_microsoft_365_potential_password_spraying_attack.toml +++ b/rules/integrations/o365/credential_access_microsoft_365_potential_password_spraying_attack.toml @@ -2,7 +2,7 @@ creation_date = "2020/12/01" integration = ["o365"] maturity = "production" -updated_date = "2024/09/05" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,41 @@ index = ["filebeat-*", "logs-o365*"] language = "kuery" license = "Elastic License v2" name = "Deprecated - Potential Password Spraying of Microsoft 365 User Accounts" -note = """This rule has been deprecated in favor of `Attempts to Brute Force a Microsoft 365 User Account` (26f68dba-ce29-497b-8e13-b4fde1db5a2d).""" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Deprecated - Potential Password Spraying of Microsoft 365 User Accounts + +Microsoft 365 is a cloud-based suite offering productivity and collaboration tools. Adversaries may exploit its authentication mechanisms through password spraying, a technique involving multiple login attempts with common passwords across many accounts. This detection rule identifies such attempts by monitoring failed logins from a single IP, flagging potential unauthorized access efforts. + +### Possible investigation steps + +- Review the IP address associated with the failed login attempts to determine if it is known or has been flagged in previous incidents. +- Analyze the event logs for the specific event.dataset:o365.audit to identify patterns or anomalies in the failed login attempts, such as the frequency and timing of the attempts. +- Check the user accounts targeted by the failed login attempts to assess if they have been compromised or if there are any unusual activities associated with them. +- Investigate the event.provider field to determine if the attempts were made through Exchange or AzureActiveDirectory, which may provide additional context on the attack vector. +- Correlate the failed login attempts with other security events or alerts to identify if this is part of a larger attack campaign or if there are other related security incidents. + +### False positive analysis + +- High volume of legitimate login attempts from a single IP address can trigger false positives, such as when a large organization uses a centralized proxy or VPN. To mitigate, exclude known IP addresses of trusted proxies or VPNs from the rule. +- Automated scripts or applications performing frequent login checks for service accounts may cause false positives. Identify and whitelist these service accounts to prevent unnecessary alerts. +- Users with incorrect password storage in password managers may repeatedly attempt logins with outdated credentials. Encourage users to update their stored passwords and consider excluding these accounts if they are known to cause frequent alerts. +- Security testing or penetration testing activities might mimic password spraying behavior. Coordinate with security teams to schedule these activities and temporarily adjust the rule to avoid false positives during testing periods. + +### Response and remediation + +- Immediately block the IP address identified in the alert to prevent further unauthorized login attempts. +- Reset passwords for all user accounts targeted by the failed login attempts to ensure any compromised credentials are no longer valid. +- Enable multi-factor authentication (MFA) for all affected accounts to add an additional layer of security against unauthorized access. +- Review and update conditional access policies to restrict login attempts from suspicious or untrusted locations. +- Notify the security operations team to monitor for any further suspicious activity related to the identified IP address or user accounts. +- Escalate the incident to the IT security manager for further investigation and to determine if additional resources are needed for a comprehensive response. +- Conduct a post-incident review to identify any gaps in the current security posture and implement measures to prevent similar attacks in the future. + +This rule has been deprecated in favor of `Attempts to Brute Force a Microsoft 365 User Account` (26f68dba-ce29-497b-8e13-b4fde1db5a2d).""" risk_score = 73 rule_id = "3efee4f0-182a-40a8-a835-102c68a4175d" severity = "high" diff --git a/rules/integrations/o365/credential_access_user_excessive_sso_logon_errors.toml b/rules/integrations/o365/credential_access_user_excessive_sso_logon_errors.toml index f74a123e361..280d82071c7 100644 --- a/rules/integrations/o365/credential_access_user_excessive_sso_logon_errors.toml +++ b/rules/integrations/o365/credential_access_user_excessive_sso_logon_errors.toml @@ -2,7 +2,7 @@ creation_date = "2021/05/17" integration = ["o365"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic", "Austin Songer"] @@ -21,7 +21,43 @@ index = ["filebeat-*", "logs-o365*"] language = "kuery" license = "Elastic License v2" name = "O365 Excessive Single Sign-On Logon Errors" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating O365 Excessive Single Sign-On Logon Errors + +Single Sign-On (SSO) in O365 streamlines user access by allowing one set of credentials for multiple applications. However, adversaries may exploit this by attempting brute force attacks to gain unauthorized access. The detection rule monitors for frequent SSO logon errors, signaling potential abuse, and helps identify compromised accounts by flagging unusual authentication patterns. + +### Possible investigation steps + +- Review the specific account(s) associated with the excessive SSO logon errors by examining the event logs filtered by the query fields, particularly focusing on the o365.audit.LogonError field with the value "SsoArtifactInvalidOrExpired". +- Analyze the timestamps of the logon errors to determine if there is a pattern or specific time frame when the errors are occurring, which might indicate a targeted attack. +- Check for any recent changes or unusual activities in the affected account(s), such as password changes, unusual login locations, or device changes, to assess if the account might be compromised. +- Investigate the source IP addresses associated with the logon errors to identify if they are from known malicious sources or unusual locations for the user. +- Correlate the logon error events with other security alerts or logs from the same time period to identify any related suspicious activities or potential indicators of compromise. +- Contact the user(s) of the affected account(s) to verify if they experienced any issues with their account access or if they recognize the logon attempts, which can help determine if the activity is legitimate or malicious. + +### False positive analysis + +- High volume of legitimate user logins: Users who frequently log in and out of multiple O365 applications may trigger excessive logon errors. To manage this, create exceptions for known high-activity accounts. +- Automated scripts or applications: Some automated processes may use outdated or incorrect credentials, leading to repeated logon errors. Identify and update these scripts to prevent false positives. +- Password changes: Users who recently changed their passwords might experience logon errors if they have not updated their credentials across all devices and applications. Encourage users to update their credentials promptly. +- Network issues: Temporary network disruptions can cause authentication errors. Monitor network stability and consider excluding errors during known network maintenance periods. +- Multi-factor authentication (MFA) misconfigurations: Incorrect MFA settings can lead to logon errors. Verify and correct MFA configurations for affected users to reduce false positives. + +### Response and remediation + +- Immediately isolate the affected account by disabling it to prevent further unauthorized access attempts. +- Conduct a password reset for the compromised account and enforce a strong password policy to mitigate the risk of future brute force attacks. +- Review and analyze the account's recent activity logs to identify any unauthorized access or data exfiltration attempts. +- Implement multi-factor authentication (MFA) for the affected account and other high-risk accounts to add an additional layer of security. +- Notify the user of the affected account about the incident and provide guidance on recognizing phishing attempts and securing their credentials. +- Escalate the incident to the security operations team for further investigation and to determine if additional accounts or systems have been compromised. +- Update and enhance monitoring rules to detect similar patterns of excessive SSO logon errors, ensuring early detection of potential brute force attempts. + +## Setup The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" risk_score = 73 diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_dlp_policy_removed.toml b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_dlp_policy_removed.toml index 77bc6a6dfa9..4df4f2a67dc 100644 --- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_dlp_policy_removed.toml +++ b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_dlp_policy_removed.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/20" integration = ["o365"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -21,7 +21,42 @@ index = ["filebeat-*", "logs-o365*"] language = "kuery" license = "Elastic License v2" name = "Microsoft 365 Exchange DLP Policy Removed" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft 365 Exchange DLP Policy Removed + +Data Loss Prevention (DLP) in Microsoft 365 Exchange is crucial for safeguarding sensitive information by monitoring and controlling data transfers. Adversaries may exploit this by removing DLP policies to bypass data monitoring, facilitating unauthorized data exfiltration. The detection rule identifies such actions by analyzing audit logs for specific events indicating successful DLP policy removal, thus alerting security teams to potential defense evasion tactics. + +### Possible investigation steps + +- Review the audit logs for the specific event.action "Remove-DlpPolicy" to identify the user account responsible for the action. +- Check the event.outcome field to confirm the success of the DLP policy removal and gather additional context from related logs. +- Investigate the user account's recent activities in Microsoft 365 to identify any other suspicious actions or anomalies. +- Verify if the removed DLP policy was critical for protecting sensitive data and assess the potential impact of its removal. +- Contact the user or their manager to confirm if the DLP policy removal was authorized and legitimate. +- Examine any recent changes in permissions or roles for the user account to determine if they had the necessary privileges to remove the DLP policy. + +### False positive analysis + +- Routine administrative changes to DLP policies by authorized personnel can trigger alerts. To manage this, maintain a list of authorized users and correlate their activities with policy changes to verify legitimacy. +- Scheduled updates or maintenance activities might involve temporary removal of DLP policies. Document these activities and create exceptions in the monitoring system for the duration of the maintenance window. +- Automated scripts or third-party tools used for policy management can inadvertently trigger false positives. Ensure these tools are properly documented and their actions are logged to differentiate between legitimate and suspicious activities. +- Changes in organizational policy or compliance requirements may necessitate the removal of certain DLP policies. Keep a record of such changes and adjust the monitoring rules to accommodate these legitimate actions. + +### Response and remediation + +- Immediately isolate the affected Microsoft 365 account to prevent further unauthorized actions and data exfiltration. +- Review the audit logs to identify any additional unauthorized changes or suspicious activities associated with the account or related accounts. +- Restore the removed DLP policy from a backup or recreate it based on the organization's standard configuration to re-enable data monitoring. +- Conduct a thorough investigation to determine the scope of data exposure and identify any data that may have been exfiltrated during the period the DLP policy was inactive. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional containment measures are necessary. +- Implement enhanced monitoring and alerting for similar events, focusing on unauthorized changes to security policies and configurations. +- Review and strengthen access controls and permissions for accounts with the ability to modify DLP policies to prevent unauthorized changes in the future. + +## Setup The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_policy_deletion.toml b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_policy_deletion.toml index ec5a1d9bbc5..e5ade4558ae 100644 --- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_policy_deletion.toml +++ b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_policy_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/19" integration = ["o365"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,43 @@ index = ["filebeat-*", "logs-o365*"] language = "kuery" license = "Elastic License v2" name = "Microsoft 365 Exchange Malware Filter Policy Deletion" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft 365 Exchange Malware Filter Policy Deletion + +Microsoft 365 Exchange uses malware filter policies to detect and alert administrators about malware in emails, crucial for maintaining security. Adversaries may delete these policies to bypass detection, facilitating undetected malware distribution. The detection rule monitors audit logs for successful deletions of these policies, signaling potential defense evasion attempts. + +### Possible investigation steps + +- Review the audit logs for the specific event.action "Remove-MalwareFilterPolicy" to identify the user account responsible for the deletion. +- Investigate the event.outcome to confirm the success of the policy deletion and gather additional context from related logs. +- Check the event.provider "Exchange" and event.category "web" to ensure the activity is consistent with expected administrative actions. +- Assess the recent activity of the identified user account for any unusual behavior or signs of compromise, such as unexpected login locations or times. +- Examine other security alerts or incidents involving the same user account or related systems to identify potential patterns or coordinated attacks. +- Verify if there are any recent changes in permissions or roles for the user account that could explain the ability to delete the malware filter policy. +- Coordinate with IT and security teams to determine if the deletion was authorized or if immediate remediation actions are necessary to restore security controls. + +### False positive analysis + +- Administrative maintenance activities may trigger the rule if administrators are legitimately updating or removing outdated malware filter policies. To manage this, maintain a log of scheduled maintenance activities and cross-reference with alerts to verify legitimacy. +- Automated scripts or third-party tools used for policy management might inadvertently delete policies, leading to false positives. Ensure these tools are configured correctly and consider excluding their actions from the rule if they are verified as non-threatening. +- Changes in organizational policy or security strategy might necessitate the removal of certain malware filter policies. Document these changes and create exceptions in the detection rule for these specific actions to prevent unnecessary alerts. +- User error during policy management could result in accidental deletions. Implement additional verification steps or approval processes for policy deletions to reduce the likelihood of such errors triggering false positives. + +### Response and remediation + +- Immediately isolate the affected account or system to prevent further unauthorized actions or malware distribution. +- Recreate the deleted malware filter policy to restore the email security posture and prevent further evasion attempts. +- Conduct a thorough review of recent audit logs to identify any other suspicious activities or policy changes that may indicate a broader compromise. +- Reset passwords and enforce multi-factor authentication for the affected account to secure access and prevent further unauthorized actions. +- Notify the security team and relevant stakeholders about the incident for awareness and potential escalation if further investigation reveals a larger threat. +- Implement additional monitoring on the affected account and related systems to detect any further suspicious activities or attempts to bypass security measures. +- Review and update security policies and configurations to ensure they are robust against similar evasion tactics in the future. + +## Setup The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_rule_mod.toml b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_rule_mod.toml index 3a8e0b5063c..49f1d59e2d5 100644 --- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_rule_mod.toml +++ b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_malware_filter_rule_mod.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/19" integration = ["o365"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -21,7 +21,42 @@ index = ["filebeat-*", "logs-o365*"] language = "kuery" license = "Elastic License v2" name = "Microsoft 365 Exchange Malware Filter Rule Modification" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft 365 Exchange Malware Filter Rule Modification + +Microsoft 365 Exchange uses malware filter rules to protect email systems by identifying and blocking malicious content. Adversaries may attempt to disable or remove these rules to bypass security measures and facilitate attacks. The detection rule monitors audit logs for successful actions that alter these rules, signaling potential defense evasion tactics. This helps security analysts quickly identify and respond to unauthorized modifications. + +### Possible investigation steps + +- Review the audit logs for the specific event.dataset:o365.audit entries with event.provider:Exchange to confirm the occurrence of the rule modification. +- Identify the user account associated with the event.action:("Remove-MalwareFilterRule" or "Disable-MalwareFilterRule") and verify if the action was authorized or expected. +- Check the event.category:web logs for any related activities around the same timeframe to identify potential patterns or additional suspicious actions. +- Investigate the event.outcome:success to ensure that the modification was indeed successful and assess the impact on the organization's security posture. +- Correlate the identified actions with any recent security incidents or alerts to determine if this modification is part of a larger attack or threat campaign. +- Review the user's recent activity and access logs to identify any other unusual or unauthorized actions that may indicate compromised credentials or insider threat behavior. + +### False positive analysis + +- Routine administrative changes to malware filter rules by authorized IT personnel can trigger alerts. To manage this, maintain a list of authorized users and their expected activities, and create exceptions for these users in the monitoring system. +- Scheduled maintenance or updates to Microsoft 365 configurations might involve temporary disabling of certain rules. Document these activities and adjust the monitoring system to recognize these as non-threatening. +- Automated scripts or third-party tools used for system management may perform actions that resemble rule modifications. Ensure these tools are properly documented and their actions are whitelisted if verified as safe. +- Changes made during incident response or troubleshooting can appear as rule modifications. Coordinate with the incident response team to log these activities and exclude them from triggering alerts. + +### Response and remediation + +- Immediately isolate the affected user accounts and systems to prevent further unauthorized modifications to the malware filter rules. +- Re-enable or recreate the disabled or removed malware filter rules to restore the intended security posture of the Microsoft 365 environment. +- Conduct a thorough review of recent email traffic and logs to identify any potential malicious content that may have bypassed the filters during the period of rule modification. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or accounts have been compromised. +- Implement enhanced monitoring and alerting for any future attempts to modify malware filter rules, ensuring rapid detection and response. +- Review and update access controls and permissions for administrative actions within Microsoft 365 to limit the ability to modify security configurations to only essential personnel. +- Document the incident, including actions taken and lessons learned, to improve future response efforts and update incident response plans accordingly. + +## Setup The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_safe_attach_rule_disabled.toml b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_safe_attach_rule_disabled.toml index 9d9933ff325..716701f4dc1 100644 --- a/rules/integrations/o365/defense_evasion_microsoft_365_exchange_safe_attach_rule_disabled.toml +++ b/rules/integrations/o365/defense_evasion_microsoft_365_exchange_safe_attach_rule_disabled.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/19" integration = ["o365"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,42 @@ index = ["filebeat-*", "logs-o365*"] language = "kuery" license = "Elastic License v2" name = "Microsoft 365 Exchange Safe Attachment Rule Disabled" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft 365 Exchange Safe Attachment Rule Disabled + +Microsoft 365's Safe Attachment feature enhances security by analyzing email attachments in a secure environment to detect unknown malware. Disabling this rule can expose organizations to threats by allowing potentially harmful attachments to bypass scrutiny. Adversaries may exploit this to exfiltrate data or avoid detection. The detection rule monitors audit logs for successful attempts to disable this feature, signaling potential defense evasion activities. + +### Possible investigation steps + +- Review the audit logs for the specific event.action "Disable-SafeAttachmentRule" to identify the user or account responsible for the action. +- Check the event.outcome field to confirm the success of the rule being disabled and gather additional context from related logs around the same timestamp. +- Investigate the event.provider "Exchange" to determine if there are any other recent suspicious activities or changes made by the same user or account. +- Assess the event.category "web" to understand if there were any web-based interactions or anomalies that coincide with the disabling of the safe attachment rule. +- Evaluate the risk score and severity to prioritize the investigation and determine if immediate action is required to mitigate potential threats. +- Cross-reference the identified user or account with known insider threat indicators or previous security incidents to assess the likelihood of malicious intent. + +### False positive analysis + +- Routine administrative changes can trigger alerts when IT staff disable Safe Attachment rules for legitimate reasons, such as testing or maintenance. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows. +- Automated scripts or third-party tools used for email management might disable Safe Attachment rules as part of their operations. Identify these tools and exclude their actions from triggering alerts by whitelisting their associated accounts or IP addresses. +- Changes in organizational policy or security configurations might necessitate temporary disabling of Safe Attachment rules. Document these policy changes and adjust the monitoring rules to account for these temporary exceptions. +- Training or onboarding sessions for new IT staff might involve disabling Safe Attachment rules as part of learning exercises. Ensure these activities are logged and excluded from alerts by setting up temporary exceptions for training periods. + +### Response and remediation + +- Immediately re-enable the Safe Attachment Rule in Microsoft 365 to restore the security posture and prevent further exposure to potentially harmful attachments. +- Conduct a thorough review of recent email logs and quarantine any suspicious attachments that were delivered during the period the rule was disabled. +- Isolate any systems or accounts that interacted with suspicious attachments to prevent potential malware spread or data exfiltration. +- Escalate the incident to the security operations team for further investigation and to determine if there was any unauthorized access or data compromise. +- Implement additional monitoring on the affected accounts and systems to detect any signs of ongoing or further malicious activity. +- Review and update access controls and permissions to ensure that only authorized personnel can modify security rules and configurations. +- Conduct a post-incident analysis to identify the root cause and implement measures to prevent similar incidents, such as enhancing alerting mechanisms for critical security rule changes. + +## Setup The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/o365/defense_evasion_microsoft_365_mailboxauditbypassassociation.toml b/rules/integrations/o365/defense_evasion_microsoft_365_mailboxauditbypassassociation.toml index c702bee9a9c..1eab3695794 100644 --- a/rules/integrations/o365/defense_evasion_microsoft_365_mailboxauditbypassassociation.toml +++ b/rules/integrations/o365/defense_evasion_microsoft_365_mailboxauditbypassassociation.toml @@ -2,7 +2,7 @@ creation_date = "2022/01/13" integration = ["o365"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -21,7 +21,43 @@ index = ["filebeat-*", "logs-o365*"] language = "kuery" license = "Elastic License v2" name = "O365 Mailbox Audit Logging Bypass" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating O365 Mailbox Audit Logging Bypass + +In Microsoft 365 environments, mailbox audit logging is crucial for tracking user activities like accessing or deleting emails. However, administrators can exempt certain accounts from logging to reduce noise, which attackers might exploit to hide their actions. The detection rule identifies successful attempts to create such exemptions, signaling potential misuse of this bypass mechanism. + +### Possible investigation steps + +- Review the event logs for entries with event.dataset set to o365.audit and event.provider set to Exchange to confirm the presence of the Set-MailboxAuditBypassAssociation action. +- Identify the account associated with the event.action Set-MailboxAuditBypassAssociation and verify if it is a known and authorized account for creating audit bypass associations. +- Check the event.outcome field to ensure the action was successful and determine if there are any other related unsuccessful attempts that might indicate trial and error by an attacker. +- Investigate the history of the account involved in the bypass association to identify any unusual or suspicious activities, such as recent changes in permissions or unexpected login locations. +- Cross-reference the account with any known third-party tools or lawful monitoring accounts to determine if the bypass is legitimate or potentially malicious. +- Assess the risk and impact of the bypass by evaluating the types of activities that would no longer be logged for the account in question, considering the organization's security policies and compliance requirements. + +### False positive analysis + +- Authorized third-party tools may generate a high volume of mailbox audit log entries, leading to bypass associations being set. Review and document these tools to ensure they are legitimate and necessary for business operations. +- Accounts used for lawful monitoring might be exempted from logging to reduce noise. Verify that these accounts are properly documented and that their activities align with organizational policies. +- Regularly review the list of accounts with bypass associations to ensure that only necessary and approved accounts are included. Remove any accounts that no longer require exemptions. +- Implement a process for periodically auditing bypass associations to detect any unauthorized changes or additions, ensuring that only intended accounts are exempted from logging. +- Consider setting up alerts for any new bypass associations to quickly identify and investigate potential misuse or unauthorized changes. + +### Response and remediation + +- Immediately isolate the account associated with the successful Set-MailboxAuditBypassAssociation event to prevent further unauthorized actions. +- Review and revoke any unauthorized mailbox audit bypass associations to ensure all relevant activities are logged. +- Conduct a thorough audit of recent activities performed by the affected account to identify any suspicious or malicious actions that may have been concealed. +- Reset credentials for the compromised account and any other accounts that may have been affected to prevent further unauthorized access. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring for similar bypass attempts to enhance detection capabilities and prevent recurrence. +- Consider escalating the incident to a higher security tier or external cybersecurity experts if the scope of the breach is extensive or if internal resources are insufficient to handle the threat. + +## Setup The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://twitter.com/misconfig/status/1476144066807140355"] diff --git a/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_creation.toml b/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_creation.toml index b000de68c75..7c3d6863c66 100644 --- a/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_creation.toml +++ b/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_creation.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/18" integration = ["o365"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,42 @@ index = ["filebeat-*", "logs-o365*"] language = "kuery" license = "Elastic License v2" name = "Microsoft 365 Exchange Transport Rule Creation" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft 365 Exchange Transport Rule Creation + +Microsoft 365 Exchange transport rules automate email handling, applying actions like forwarding or blocking based on conditions. While beneficial for managing communications, adversaries can exploit these rules to redirect emails externally, facilitating data exfiltration. The detection rule monitors successful creation of new transport rules, flagging potential misuse by identifying specific actions and outcomes in audit logs. + +### Possible investigation steps + +- Review the audit logs for the event.dataset:o365.audit to identify the user account responsible for creating the new transport rule. +- Examine the event.provider:Exchange and event.category:web fields to confirm the context and source of the rule creation. +- Investigate the event.action:"New-TransportRule" to understand the specific conditions and actions defined in the newly created transport rule. +- Check the event.outcome:success to ensure the rule creation was completed successfully and assess if it aligns with expected administrative activities. +- Analyze the transport rule settings to determine if it includes actions that forward emails to external domains, which could indicate potential data exfiltration. +- Correlate the findings with other security events or alerts to identify any patterns or anomalies that might suggest malicious intent. + +### False positive analysis + +- Routine administrative tasks may trigger alerts when IT staff create or modify transport rules for legitimate purposes. To manage this, establish a baseline of expected rule creation activities and exclude these from alerts. +- Automated systems or third-party applications that integrate with Microsoft 365 might create transport rules as part of their normal operation. Identify these systems and create exceptions for their known actions. +- Changes in organizational policies or email handling procedures can lead to legitimate rule creations. Document these changes and update the monitoring system to recognize them as non-threatening. +- Regular audits or compliance checks might involve creating temporary transport rules. Coordinate with audit teams to schedule these activities and temporarily adjust alert thresholds or exclusions during these periods. + +### Response and remediation + +- Immediately disable the newly created transport rule to prevent further unauthorized email forwarding or data exfiltration. +- Conduct a thorough review of the audit logs to identify any other suspicious transport rules or related activities that may indicate a broader compromise. +- Isolate the affected user accounts or systems associated with the creation of the transport rule to prevent further unauthorized access or actions. +- Reset passwords and enforce multi-factor authentication for the affected accounts to secure access and prevent recurrence. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Escalate the incident to the incident response team if there is evidence of a broader compromise or if sensitive data has been exfiltrated. +- Implement enhanced monitoring and alerting for transport rule changes to detect and respond to similar threats more effectively in the future. + +## Setup The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_mod.toml b/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_mod.toml index 1d3f8d6595f..143915de013 100644 --- a/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_mod.toml +++ b/rules/integrations/o365/exfiltration_microsoft_365_exchange_transport_rule_mod.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/19" integration = ["o365"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,42 @@ index = ["filebeat-*", "logs-o365*"] language = "kuery" license = "Elastic License v2" name = "Microsoft 365 Exchange Transport Rule Modification" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft 365 Exchange Transport Rule Modification + +Microsoft 365 Exchange transport rules manage email flow by setting conditions and actions for messages. Adversaries may exploit these rules to disable or delete them, facilitating data exfiltration or bypassing security measures. The detection rule monitors audit logs for successful execution of commands that alter these rules, signaling potential misuse and enabling timely investigation. + +### Possible investigation steps + +- Review the audit logs for the specific event.dataset:o365.audit entries with event.provider:Exchange to confirm the occurrence of the "Remove-TransportRule" or "Disable-TransportRule" actions. +- Identify the user account associated with the event by examining the user information in the audit logs to determine if the action was performed by an authorized individual or a potential adversary. +- Check the event.category:web context to understand if the action was performed through a web interface, which might indicate a compromised account or unauthorized access. +- Investigate the event.outcome:success to ensure that the rule modification was indeed successful and not an attempted action. +- Correlate the timing of the rule modification with other security events or alerts to identify any concurrent suspicious activities that might suggest a broader attack or data exfiltration attempt. +- Assess the impact of the rule modification by reviewing the affected transport rules to determine if they were critical for security or compliance, and evaluate the potential risk to the organization. + +### False positive analysis + +- Routine administrative changes to transport rules by IT staff can trigger alerts. To manage this, maintain a list of authorized personnel and their expected activities, and create exceptions for these users in the monitoring system. +- Scheduled maintenance or updates to transport rules may result in false positives. Document these activities and adjust the monitoring system to temporarily exclude these events during known maintenance windows. +- Automated scripts or third-party tools that manage transport rules might cause alerts. Identify these tools and their typical behavior, then configure the monitoring system to recognize and exclude these benign actions. +- Changes made as part of compliance audits or security assessments can be mistaken for malicious activity. Coordinate with audit teams to log these activities separately and adjust the monitoring system to account for these legitimate changes. + +### Response and remediation + +- Immediately disable any compromised accounts identified in the audit logs to prevent further unauthorized modifications to transport rules. +- Revert any unauthorized changes to transport rules by restoring them to their previous configurations using backup data or logs. +- Conduct a thorough review of all transport rules to ensure no additional unauthorized modifications have been made, and confirm that all rules align with organizational security policies. +- Implement additional monitoring on the affected accounts and transport rules to detect any further suspicious activities or attempts to modify rules. +- Escalate the incident to the security operations team for a deeper investigation into potential data exfiltration activities and to assess the scope of the breach. +- Coordinate with legal and compliance teams to determine if any regulatory reporting is required due to potential data exfiltration. +- Enhance security measures by enabling multi-factor authentication (MFA) for all administrative accounts and reviewing access permissions to ensure the principle of least privilege is enforced. + +## Setup The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/o365/exfiltration_microsoft_365_mass_download_by_a_single_user.toml b/rules/integrations/o365/exfiltration_microsoft_365_mass_download_by_a_single_user.toml index ad5ac070602..84c109beb45 100644 --- a/rules/integrations/o365/exfiltration_microsoft_365_mass_download_by_a_single_user.toml +++ b/rules/integrations/o365/exfiltration_microsoft_365_mass_download_by_a_single_user.toml @@ -2,7 +2,7 @@ creation_date = "2021/07/15" integration = ["o365"] maturity = "development" -updated_date = "2023/06/22" +updated_date = "2025/01/10" [rule] author = ["Austin Songer"] @@ -13,7 +13,42 @@ index = ["filebeat-*", "logs-o365*"] language = "kuery" license = "Elastic License v2" name = "Microsoft 365 Mass download by a single user" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft 365 Mass download by a single user + +Microsoft 365 provides cloud-based productivity tools, enabling users to access and download data efficiently. However, adversaries can exploit this by performing mass downloads to exfiltrate sensitive information. The detection rule identifies suspicious activity by flagging instances where a user downloads an unusually high volume of data in a short period, indicating potential data exfiltration attempts. This helps security analysts quickly respond to and mitigate potential threats. + +### Possible investigation steps + +- Review the user's activity logs in Microsoft 365 to confirm the mass download event, focusing on the event.dataset:o365.audit and event.provider:SecurityComplianceCenter fields to ensure the event is accurately captured. +- Check the user's recent login history and IP addresses to identify any unusual access patterns or locations that could indicate unauthorized access. +- Analyze the specific files or data downloaded by the user to assess the sensitivity and potential impact of the data exfiltration. +- Contact the user to verify if the downloads were legitimate and authorized, and gather any additional context or explanations for the activity. +- Investigate any recent changes to the user's account permissions or roles that might have facilitated the mass download, ensuring that access controls are appropriately configured. +- Review any related alerts or incidents in the security information and event management (SIEM) system to identify potential correlations or patterns with other suspicious activities. + +### False positive analysis + +- High-volume legitimate business operations may trigger the rule. Identify and whitelist users or departments known for frequent large data transfers, such as data analysts or IT personnel, to prevent unnecessary alerts. +- Automated backup or synchronization tools can cause mass downloads. Review and exclude these activities by identifying the specific user accounts or applications involved in regular backup processes. +- Software updates or deployments might result in mass downloads. Monitor and exclude these events by correlating them with scheduled maintenance windows or deployment activities. +- Training or onboarding sessions that require downloading large amounts of data can be mistaken for suspicious activity. Coordinate with HR or training departments to anticipate and exclude these events from triggering alerts. + +### Response and remediation + +- Immediately isolate the affected user account to prevent further data exfiltration. This can be done by disabling the account or changing the password. +- Review the downloaded files to assess the sensitivity and potential impact of the data exfiltrated. This will help in understanding the scope of the breach. +- Notify the security team and relevant stakeholders about the incident to ensure coordinated response efforts and compliance with any regulatory requirements. +- Conduct a thorough investigation to determine if the mass download was authorized or if it indicates a compromised account. This may involve checking for unusual login locations or times. +- If the account is confirmed to be compromised, perform a full security audit of the affected user's activities and any other potentially impacted systems. +- Implement additional monitoring on the affected account and similar high-risk accounts to detect any further suspicious activities. +- Review and update access controls and data download policies to prevent similar incidents in the future, ensuring that only necessary permissions are granted to users. + +## Setup The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. """ diff --git a/rules/integrations/o365/impact_microsoft_365_potential_ransomware_activity.toml b/rules/integrations/o365/impact_microsoft_365_potential_ransomware_activity.toml index d249e245d1a..d693a90178b 100644 --- a/rules/integrations/o365/impact_microsoft_365_potential_ransomware_activity.toml +++ b/rules/integrations/o365/impact_microsoft_365_potential_ransomware_activity.toml @@ -2,7 +2,7 @@ creation_date = "2021/07/15" integration = ["o365"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Austin Songer"] @@ -21,7 +21,44 @@ index = ["filebeat-*", "logs-o365*"] language = "kuery" license = "Elastic License v2" name = "Microsoft 365 Potential ransomware activity" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft 365 Potential ransomware activity + +Microsoft 365's cloud services can be exploited by adversaries to distribute ransomware by uploading infected files. This detection rule leverages Microsoft Cloud App Security to identify suspicious uploads, focusing on successful events flagged as potential ransomware activity. By monitoring specific event datasets and actions, it helps security analysts pinpoint and mitigate ransomware threats, aligning with MITRE ATT&CK's impact tactics. + +### Possible investigation steps + +- Review the event details in the Microsoft Cloud App Security console to confirm the specific files and user involved in the "Potential ransomware activity" alert. +- Check the event.dataset field for o365.audit logs to gather additional context about the user's recent activities and any other related events. +- Investigate the event.provider field to ensure the alert originated from the SecurityComplianceCenter, confirming the source of the detection. +- Analyze the event.category field to verify that the activity is categorized as web, which may indicate the method of file upload. +- Assess the user's recent activity history and permissions to determine if the upload was intentional or potentially malicious. +- Contact the user to verify the legitimacy of the uploaded files and gather any additional context or explanations for the activity. +- If the files are confirmed or suspected to be malicious, initiate a response plan to contain and remediate any potential ransomware threat, including isolating affected systems and notifying relevant stakeholders. + +### False positive analysis + +- Legitimate file uploads by trusted users may trigger alerts if the files are mistakenly flagged as ransomware. To manage this, create exceptions for specific users or groups who frequently upload large volumes of files. +- Automated backup processes that upload encrypted files to the cloud can be misidentified as ransomware activity. Exclude these processes by identifying and whitelisting the associated service accounts or IP addresses. +- Certain file types or extensions commonly used in business operations might be flagged. Review and adjust the detection rule to exclude these file types if they are consistently identified as false positives. +- Collaborative tools that sync files across devices may cause multiple uploads that appear suspicious. Monitor and exclude these tools by recognizing their typical behavior patterns and adjusting the rule settings accordingly. +- Regularly review and update the list of exceptions to ensure that only verified non-threatening activities are excluded, maintaining the balance between security and operational efficiency. + +### Response and remediation + +- Immediately isolate the affected user account to prevent further uploads and potential spread of ransomware within the cloud environment. +- Quarantine the uploaded files flagged as potential ransomware to prevent access and further distribution. +- Conduct a thorough scan of the affected user's devices and cloud storage for additional signs of ransomware or other malicious activity. +- Notify the security operations team to initiate a deeper investigation into the source and scope of the ransomware activity, leveraging MITRE ATT&CK techniques for guidance. +- Restore any affected files from secure backups, ensuring that the backups are clean and free from ransomware. +- Review and update access controls and permissions for the affected user and related accounts to minimize the risk of future incidents. +- Escalate the incident to senior security management and, if necessary, involve legal or compliance teams to assess any regulatory implications. + +## Setup The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. """ diff --git a/rules/integrations/o365/impact_microsoft_365_unusual_volume_of_file_deletion.toml b/rules/integrations/o365/impact_microsoft_365_unusual_volume_of_file_deletion.toml index 91ff9f58844..75a2ac3f0fe 100644 --- a/rules/integrations/o365/impact_microsoft_365_unusual_volume_of_file_deletion.toml +++ b/rules/integrations/o365/impact_microsoft_365_unusual_volume_of_file_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2021/07/15" integration = ["o365"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Austin Songer"] @@ -13,7 +13,43 @@ index = ["filebeat-*", "logs-o365*"] language = "kuery" license = "Elastic License v2" name = "Microsoft 365 Unusual Volume of File Deletion" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft 365 Unusual Volume of File Deletion + +Microsoft 365's cloud environment facilitates file storage and collaboration, but its vast data handling capabilities can be exploited by adversaries for data destruction. Attackers may delete large volumes of files to disrupt operations or cover their tracks. The detection rule leverages audit logs to identify anomalies in file deletion activities, flagging successful, unusual deletion volumes as potential security incidents, thus enabling timely investigation and response. + +### Possible investigation steps + +- Review the audit logs for the specific user associated with the alert to confirm the volume and context of the file deletions, focusing on entries with event.action:"Unusual volume of file deletion" and event.outcome:success. +- Correlate the timestamps of the deletion events with other activities in the user's account to identify any suspicious patterns or anomalies, such as unusual login locations or times. +- Check for any recent changes in user permissions or roles that might explain the ability to delete a large volume of files, ensuring these align with the user's typical responsibilities. +- Investigate any recent security alerts or incidents involving the same user or related accounts to determine if this activity is part of a broader attack or compromise. +- Contact the user or their manager to verify if the deletions were intentional and authorized, and gather any additional context that might explain the activity. +- Assess the impact of the deletions on business operations and data integrity, and determine if any recovery actions are necessary to restore critical files. + +### False positive analysis + +- High-volume legitimate deletions during data migration or cleanup projects can trigger false positives. To manage this, create exceptions for users or groups involved in these activities during the specified time frame. +- Automated processes or scripts that perform bulk deletions as part of routine maintenance may be flagged. Identify these processes and whitelist them to prevent unnecessary alerts. +- Users with roles in data management or IT support may regularly delete large volumes of files as part of their job responsibilities. Establish a baseline for these users and adjust the detection thresholds accordingly. +- Temporary spikes in file deletions due to organizational changes, such as department restructuring, can be mistaken for malicious activity. Monitor these events and temporarily adjust the rule parameters to accommodate expected changes. +- Regularly review and update the list of exceptions to ensure that only legitimate activities are excluded from alerts, maintaining the effectiveness of the detection rule. + +### Response and remediation + +- Immediately isolate the affected user account to prevent further unauthorized file deletions. This can be done by disabling the account or changing the password. +- Review the audit logs to identify the scope of the deletion and determine if any critical or sensitive files were affected. Restore these files from backups if available. +- Conduct a thorough review of the affected user's recent activities to identify any other suspicious actions or potential indicators of compromise. +- Escalate the incident to the security operations team for further investigation and to determine if the deletion is part of a larger attack or breach. +- Implement additional monitoring on the affected account and similar high-risk accounts to detect any further unusual activities. +- Review and update access controls and permissions to ensure that users have the minimum necessary access to perform their job functions, reducing the risk of large-scale deletions. +- Coordinate with the IT and security teams to conduct a post-incident review, identifying any gaps in the response process and implementing improvements to prevent recurrence. + +## Setup The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. """ diff --git a/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_policy_deletion.toml b/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_policy_deletion.toml index 19722674349..65239ea08fc 100644 --- a/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_policy_deletion.toml +++ b/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_policy_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/19" integration = ["o365"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,43 @@ index = ["filebeat-*", "logs-o365*"] language = "kuery" license = "Elastic License v2" name = "Microsoft 365 Exchange Anti-Phish Policy Deletion" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft 365 Exchange Anti-Phish Policy Deletion + +Microsoft 365's anti-phishing policies enhance security by fine-tuning detection settings to thwart phishing attacks. Adversaries may delete these policies to weaken defenses, facilitating unauthorized access. The detection rule monitors audit logs for successful deletions of anti-phishing policies, signaling potential malicious activity by identifying specific actions and outcomes associated with policy removal. + +### Possible investigation steps + +- Review the audit logs for the specific event.action "Remove-AntiPhishPolicy" to identify the user account responsible for the deletion. +- Check the event.outcome field to confirm the success of the policy deletion and gather additional context from related logs around the same timestamp. +- Investigate the user account's recent activities in Microsoft 365 to identify any other suspicious actions or anomalies, such as unusual login locations or times. +- Assess whether the user account has been compromised by checking for any unauthorized access attempts or changes in account settings. +- Evaluate the impact of the deleted anti-phishing policy by reviewing the organization's current phishing protection measures and any recent phishing incidents. +- Coordinate with the IT security team to determine if the policy deletion was authorized or part of a legitimate change management process. + +### False positive analysis + +- Routine administrative actions may trigger the rule if IT staff regularly update or remove outdated anti-phishing policies. To manage this, create exceptions for known administrative accounts performing these actions. +- Scheduled policy reviews might involve the removal of policies as part of a legitimate update process. Document these schedules and exclude them from triggering alerts by setting time-based exceptions. +- Automated scripts used for policy management can inadvertently cause false positives. Identify and whitelist these scripts to prevent unnecessary alerts. +- Changes in organizational policy that require the removal of certain anti-phishing policies can be mistaken for malicious activity. Ensure that such changes are communicated and logged, and adjust the rule to recognize these legitimate actions. +- Test environments where policies are frequently added and removed for validation purposes can generate false positives. Exclude these environments from the rule to avoid confusion. + +### Response and remediation + +- Immediately isolate the affected user accounts and systems to prevent further unauthorized access or data exfiltration. +- Recreate the deleted anti-phishing policy using the latest security guidelines and ensure it is applied across all relevant user groups. +- Conduct a thorough review of recent email activity and logs for the affected accounts to identify any phishing emails that may have bypassed security measures. +- Reset passwords for affected accounts and enforce multi-factor authentication (MFA) to enhance account security. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Escalate the incident to the incident response team if there is evidence of broader compromise or if sensitive data has been accessed. +- Implement enhanced monitoring and alerting for similar actions in the future to quickly detect and respond to any further attempts to delete security policies. + +## Setup The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_rule_mod.toml b/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_rule_mod.toml index 71db20bf46d..cf514c9ade5 100644 --- a/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_rule_mod.toml +++ b/rules/integrations/o365/initial_access_microsoft_365_exchange_anti_phish_rule_mod.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/19" integration = ["o365"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,43 @@ index = ["filebeat-*", "logs-o365*"] language = "kuery" license = "Elastic License v2" name = "Microsoft 365 Exchange Anti-Phish Rule Modification" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft 365 Exchange Anti-Phish Rule Modification + +Microsoft 365's anti-phishing rules are crucial for safeguarding users against phishing attacks by enhancing detection and prevention settings. Adversaries may attempt to modify or disable these rules to facilitate phishing campaigns, gaining unauthorized access. The detection rule monitors for successful modifications or disabling of anti-phishing rules, signaling potential malicious activity by tracking specific actions within the Exchange environment. + +### Possible investigation steps + +- Review the event logs for entries with event.dataset set to o365.audit and event.provider set to Exchange to confirm the context of the alert. +- Check the event.action field for "Remove-AntiPhishRule" or "Disable-AntiPhishRule" to identify the specific action taken on the anti-phishing rule. +- Verify the event.outcome field to ensure the action was successful, indicating a potential security concern. +- Identify the user or account associated with the modification by examining the relevant user fields in the event log. +- Investigate the user's recent activity and access patterns to determine if there are any other suspicious actions or anomalies. +- Assess the impact of the rule modification by reviewing any subsequent phishing attempts or security incidents that may have occurred. +- Consider reverting the changes to the anti-phishing rule and implementing additional security measures if unauthorized access is confirmed. + +### False positive analysis + +- Administrative changes: Legitimate administrative tasks may involve modifying or disabling anti-phishing rules for testing or configuration purposes. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows. +- Security audits: Regular security audits might require temporary adjustments to anti-phishing rules. Document these activities and exclude them from alerts by correlating with audit logs. +- Third-party integrations: Some third-party security tools may interact with Microsoft 365 settings, triggering rule modifications. Identify these tools and exclude their actions from triggering alerts by using their specific identifiers. +- Policy updates: Organizational policy changes might necessitate updates to anti-phishing rules. Ensure these changes are documented and exclude them from alerts by associating them with approved change management processes. + +### Response and remediation + +- Immediately isolate the affected user accounts to prevent further unauthorized access and potential spread of phishing attacks. +- Revert any unauthorized changes to the anti-phishing rules by restoring them to their previous configurations using backup or documented settings. +- Conduct a thorough review of recent email logs and user activity to identify any potential phishing emails that may have bypassed the modified rules and take steps to quarantine or delete them. +- Notify the security team and relevant stakeholders about the incident, providing details of the rule modification and any identified phishing attempts. +- Escalate the incident to the incident response team for further investigation and to determine if additional systems or data have been compromised. +- Implement enhanced monitoring and alerting for any further attempts to modify anti-phishing rules, ensuring that similar activities are detected promptly. +- Review and update access controls and permissions for administrative actions within Microsoft 365 to ensure that only authorized personnel can modify security settings. + +## Setup The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/o365/initial_access_microsoft_365_exchange_safelinks_disabled.toml b/rules/integrations/o365/initial_access_microsoft_365_exchange_safelinks_disabled.toml index c0734782b56..72e6d898831 100644 --- a/rules/integrations/o365/initial_access_microsoft_365_exchange_safelinks_disabled.toml +++ b/rules/integrations/o365/initial_access_microsoft_365_exchange_safelinks_disabled.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/18" integration = ["o365"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -21,7 +21,42 @@ index = ["filebeat-*", "logs-o365*"] language = "kuery" license = "Elastic License v2" name = "Microsoft 365 Exchange Safe Link Policy Disabled" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft 365 Exchange Safe Link Policy Disabled + +Microsoft 365's Safe Link policies enhance security by scanning hyperlinks in documents for phishing threats, even post-delivery. Disabling these policies can expose users to phishing attacks. Adversaries might exploit this by disabling Safe Links to facilitate malicious link delivery. The detection rule identifies successful attempts to disable Safe Link policies, signaling potential security breaches. + +### Possible investigation steps + +- Review the event logs for the specific event.dataset:o365.audit and event.provider:Exchange to confirm the occurrence of the "Disable-SafeLinksRule" action with a successful outcome. +- Identify the user account associated with the event.action:"Disable-SafeLinksRule" to determine if the action was performed by an authorized individual or if the account may have been compromised. +- Check the recent activity of the identified user account for any unusual or unauthorized actions that could indicate a broader security incident. +- Investigate any recent changes to Safe Link policies in the Microsoft 365 environment to understand the scope and impact of the policy being disabled. +- Assess whether there have been any recent phishing attempts or suspicious emails delivered to users, which could exploit the disabled Safe Link policy. +- Coordinate with the IT security team to re-enable the Safe Link policy and implement additional monitoring to prevent future unauthorized changes. + +### False positive analysis + +- Administrative changes: Legitimate administrative actions may involve disabling Safe Link policies temporarily for testing or configuration purposes. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows. +- Third-party integrations: Some third-party security tools or integrations might require Safe Link policies to be disabled for compatibility reasons. Identify and document these tools, and set up exceptions for their associated actions. +- Policy updates: During policy updates or migrations, Safe Link policies might be disabled as part of the process. Monitor and document these events, and exclude them from alerts if they match known update patterns. +- User training sessions: Safe Link policies might be disabled during user training or demonstrations to showcase potential threats. Schedule these sessions and exclude related activities from triggering alerts. + +### Response and remediation + +- Immediately re-enable the Safe Link policy in Microsoft 365 to restore phishing protection for hyperlinks in documents. +- Conduct a thorough review of recent email and document deliveries to identify any potentially malicious links that may have been delivered while the Safe Link policy was disabled. +- Isolate any identified malicious links or documents and notify affected users to prevent interaction with these threats. +- Investigate the account or process that disabled the Safe Link policy to determine if it was compromised or misused, and take appropriate actions such as password resets or privilege revocation. +- Escalate the incident to the security operations team for further analysis and to determine if additional security measures are needed to prevent similar incidents. +- Implement additional monitoring and alerting for changes to Safe Link policies to ensure rapid detection of any future unauthorized modifications. +- Review and update access controls and permissions related to Safe Link policy management to ensure only authorized personnel can make changes. + +## Setup The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_activity.toml b/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_activity.toml index 50b93ea0d00..d449f41bc45 100644 --- a/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_activity.toml +++ b/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_activity.toml @@ -2,7 +2,7 @@ creation_date = "2021/07/15" integration = ["o365"] maturity = "development" -updated_date = "2024/09/05" +updated_date = "2025/01/10" [rule] author = ["Austin Songer"] @@ -16,7 +16,43 @@ index = ["filebeat-*", "logs-o365*"] language = "kuery" license = "Elastic License v2" name = "Microsoft 365 Impossible travel activity" -note = """ +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft 365 Impossible travel activity + +Microsoft 365's security features monitor user sign-ins to detect anomalies like impossible travel, where a user appears to log in from geographically distant locations in a short time. Adversaries may exploit compromised credentials to access accounts from unexpected locations. The detection rule identifies such suspicious logins by analyzing audit logs for successful sign-ins flagged as impossible travel, helping to mitigate unauthorized access. + +### Possible investigation steps + +- Review the audit logs for the specific event.dataset:o365.audit to gather details about the sign-in attempt, including the timestamp, IP addresses, and user account involved. +- Cross-reference the event.provider:SecurityComplianceCenter logs to identify any additional security alerts or anomalies associated with the same user account or IP addresses. +- Analyze the event.category:web logs to determine the geographical locations of the sign-ins and assess the feasibility of the travel between these locations within the given timeframe. +- Investigate the user account's recent activity to identify any other suspicious behavior or unauthorized access attempts, focusing on event.action:"Impossible travel activity". +- Check the event.outcome:success to confirm that the sign-in was successful and assess the potential impact of the unauthorized access. +- Contact the user to verify if they were traveling or if they recognize the sign-in activity, and advise them to change their password if the activity is deemed suspicious. +- Consider implementing additional security measures, such as multi-factor authentication, for the affected user account to prevent future unauthorized access. + +### False positive analysis + +- Frequent travel by users can trigger false positives. Implement a policy to whitelist known travel patterns for specific users who often travel between the same locations. +- Use of VPNs or proxy services can result in logins appearing from different geographic locations. Identify and exclude IP addresses associated with trusted VPN services used by your organization. +- Remote work scenarios where users log in from multiple locations in a short time can be misinterpreted. Establish a baseline for remote work patterns and adjust the rule to accommodate these behaviors. +- Shared accounts accessed by multiple users from different locations can cause false positives. Consider implementing stricter access controls or transitioning to individual accounts to reduce this risk. +- Regularly review and update the list of known safe locations and IP addresses to ensure that legitimate activities are not flagged as suspicious. + +### Response and remediation + +- Immediately isolate the affected user account by disabling it to prevent further unauthorized access. +- Initiate a password reset for the compromised account and enforce multi-factor authentication (MFA) to enhance security. +- Review the audit logs for the affected account to identify any unauthorized access or data exfiltration activities and document findings for further analysis. +- Notify the user and relevant stakeholders about the incident, providing guidance on recognizing phishing attempts and securing their credentials. +- Escalate the incident to the security operations team for a thorough investigation to determine the root cause and potential impact. +- Implement geo-blocking policies to restrict access from high-risk locations that are not relevant to the organization's operations. +- Update and refine security monitoring rules to enhance detection capabilities for similar suspicious activities in the future. + ## Important This rule is no longer applicable based on changes to Microsoft Defender for Office 365. Please refer to the following rules for similar detections: diff --git a/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_portal_logins.toml b/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_portal_logins.toml index 2f593839be0..adc57f78674 100644 --- a/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_portal_logins.toml +++ b/rules/integrations/o365/initial_access_microsoft_365_impossible_travel_portal_logins.toml @@ -2,7 +2,7 @@ creation_date = "2024/09/04" integration = ["o365"] maturity = "production" -updated_date = "2024/09/25" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -39,6 +39,41 @@ event.dataset: "o365.audit" and not o365.audit.UserId: "Not Available" and o365.audit.Target.Type: ("0" or "2" or "3" or "5" or "6" or "10") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft 365 Portal Logins from Impossible Travel Locations + +Microsoft 365's cloud-based services enable global access, but this can be exploited by adversaries logging in from disparate locations within short intervals, indicating potential account compromise. The detection rule identifies such anomalies by analyzing login events for rapid geographic shifts, flagging suspicious activity that may suggest unauthorized access attempts. + +### Possible investigation steps + +- Review the login events associated with the specific UserId flagged in the alert to confirm the occurrence of logins from different countries within a short time frame. +- Check the IP addresses associated with the login events to determine if they are from known or suspicious sources, and verify if they are consistent with the user's typical login behavior. +- Investigate the user's recent activity in Microsoft 365 to identify any unusual or unauthorized actions that may indicate account compromise. +- Contact the user to verify if they were traveling or using a VPN service that could explain the login from an unexpected location. +- Examine any recent changes to the user's account settings or permissions that could suggest unauthorized access or tampering. +- Review the organization's security logs and alerts for any other suspicious activities or patterns that might correlate with the detected anomaly. + +### False positive analysis + +- Frequent business travelers may trigger false positives due to legitimate logins from different countries within short time frames. To manage this, create exceptions for users with known travel patterns by whitelisting their accounts or using conditional access policies. +- Use of VPNs or proxy services can result in logins appearing from different geographic locations. Identify and exclude IP ranges associated with trusted VPN services to reduce false positives. +- Employees working remotely from different countries may cause alerts. Implement user-based exceptions for remote workers who regularly log in from multiple locations. +- Automated systems or services that log in from various locations for legitimate reasons can be mistaken for suspicious activity. Exclude these service accounts from the rule to prevent unnecessary alerts. +- Consider time zone differences that might affect the perceived timing of logins. Adjust the rule's sensitivity to account for legitimate time zone shifts that could appear as impossible travel. + +### Response and remediation + +- Immediately isolate the affected user account by disabling it to prevent further unauthorized access. +- Initiate a password reset for the compromised account and enforce multi-factor authentication (MFA) to enhance security. +- Review recent login activity and audit logs for the affected account to identify any unauthorized access or data exfiltration attempts. +- Notify the user of the suspicious activity and advise them to verify any recent changes or actions taken on their account. +- Escalate the incident to the security operations team for further investigation and to determine if other accounts or systems have been compromised. +- Implement geo-blocking for high-risk countries or regions where the organization does not typically conduct business to prevent similar unauthorized access attempts. +- Update and refine security monitoring rules to enhance detection of similar anomalous login patterns in the future.""" [[rule.threat]] diff --git a/rules/integrations/o365/initial_access_microsoft_365_portal_login_from_rare_location.toml b/rules/integrations/o365/initial_access_microsoft_365_portal_login_from_rare_location.toml index 7edab168de5..9179fefe59d 100644 --- a/rules/integrations/o365/initial_access_microsoft_365_portal_login_from_rare_location.toml +++ b/rules/integrations/o365/initial_access_microsoft_365_portal_login_from_rare_location.toml @@ -2,7 +2,7 @@ creation_date = "2024/09/04" integration = ["o365"] maturity = "production" -updated_date = "2024/09/25" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -37,6 +37,42 @@ event.dataset: "o365.audit" and not o365.audit.UserId: "Not Available" and o365.audit.Target.Type: ("0" or "2" or "3" or "5" or "6" or "10") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft 365 Portal Login from Rare Location + +Microsoft 365 is a cloud-based suite offering productivity tools accessible from anywhere, making it crucial for business operations. Adversaries may exploit this by logging in from uncommon locations, potentially using VPNs to mask their origin. The detection rule identifies successful logins from atypical locations, flagging potential unauthorized access attempts by analyzing login events and user location patterns. + +### Possible investigation steps + +- Review the login event details from the o365.audit dataset to confirm the user's identity and the timestamp of the login. +- Analyze the location data associated with the login event to determine if it is indeed rare or unusual for the user's typical access patterns. +- Check the user's recent login history to identify any other logins from the same rare location or any other unusual locations. +- Investigate the IP address used during the login to determine if it is associated with known VPN services or suspicious activity. +- Contact the user to verify if they initiated the login from the rare location or if they are aware of any unauthorized access attempts. +- Examine any recent changes to the user's account settings or permissions that could indicate compromise or unauthorized access. +- Correlate this event with other security alerts or logs to identify any patterns or additional indicators of compromise. + +### False positive analysis + +- Users traveling frequently may trigger alerts due to logins from new locations. Implement a process to update known travel patterns for these users to reduce false positives. +- Employees using VPNs for legitimate purposes might appear to log in from rare locations. Maintain a list of approved VPN IP addresses and exclude them from triggering alerts. +- Remote workers who occasionally connect from different locations can cause false positives. Establish a baseline of expected locations for these users and adjust the detection rule accordingly. +- Shared accounts accessed by multiple users from different locations can lead to false alerts. Consider monitoring these accounts separately and applying stricter access controls. +- Temporary relocations, such as business trips or remote work arrangements, may result in unusual login locations. Communicate with users to anticipate these changes and adjust the detection parameters temporarily. + +### Response and remediation + +- Immediately isolate the affected user account by disabling it to prevent further unauthorized access. +- Notify the user and relevant IT security personnel about the suspicious login activity to ensure awareness and initiate further investigation. +- Conduct a password reset for the affected account and enforce multi-factor authentication (MFA) if not already enabled to enhance account security. +- Review and analyze recent activity logs for the affected account to identify any unauthorized actions or data access that may have occurred. +- If unauthorized access is confirmed, initiate a security incident response plan, including data breach notification procedures if necessary. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems or accounts are compromised. +- Implement geo-blocking or conditional access policies to restrict access from rare or high-risk locations, reducing the likelihood of similar incidents in the future.""" [[rule.threat]] diff --git a/rules/integrations/o365/initial_access_microsoft_365_user_restricted_from_sending_email.toml b/rules/integrations/o365/initial_access_microsoft_365_user_restricted_from_sending_email.toml index 9eb423152f7..48b799580c2 100644 --- a/rules/integrations/o365/initial_access_microsoft_365_user_restricted_from_sending_email.toml +++ b/rules/integrations/o365/initial_access_microsoft_365_user_restricted_from_sending_email.toml @@ -2,7 +2,7 @@ creation_date = "2021/07/15" integration = ["o365"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Austin Songer"] @@ -16,7 +16,42 @@ index = ["filebeat-*", "logs-o365*"] language = "kuery" license = "Elastic License v2" name = "Microsoft 365 User Restricted from Sending Email" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft 365 User Restricted from Sending Email + +Microsoft 365 enforces email sending limits to prevent abuse and ensure service integrity. Adversaries may exploit compromised accounts to send spam or phishing emails, triggering these limits. The detection rule monitors audit logs for successful restrictions by the Security Compliance Center, indicating potential misuse of valid accounts, aligning with MITRE ATT&CK's Initial Access tactic. + +### Possible investigation steps + +- Review the audit logs in Microsoft 365 to confirm the event details, focusing on entries with event.dataset:o365.audit and event.provider:SecurityComplianceCenter to ensure the restriction was logged correctly. +- Identify the user account that was restricted by examining the event.action:"User restricted from sending email" and event.outcome:success fields to understand which account triggered the alert. +- Investigate the recent email activity of the restricted user account to determine if there was any unusual or suspicious behavior, such as a high volume of outbound emails or patterns consistent with spam or phishing. +- Check for any recent changes in account permissions or configurations that might indicate unauthorized access or compromise, aligning with the MITRE ATT&CK technique T1078 for Valid Accounts. +- Assess whether there are any other related alerts or incidents involving the same user or similar patterns, which could indicate a broader security issue or coordinated attack. + +### False positive analysis + +- High-volume legitimate email campaigns by marketing or communication teams can trigger sending limits. Coordinate with these teams to understand their schedules and create exceptions for known campaigns. +- Automated systems or applications using Microsoft 365 accounts for sending notifications or alerts may exceed limits. Identify these accounts and consider using service accounts with appropriate permissions and limits. +- Users with delegated access to multiple mailboxes might inadvertently trigger restrictions. Review and adjust permissions or create exceptions for these users if their activity is verified as legitimate. +- Temporary spikes in email activity due to business needs, such as end-of-quarter communications, can cause false positives. Monitor these periods and adjust thresholds or create temporary exceptions as needed. +- Misconfigured email clients or scripts that repeatedly attempt to send emails can appear as suspicious activity. Ensure proper configuration and monitor for any unusual patterns that may need exceptions. + +### Response and remediation + +- Immediately disable the compromised user account to prevent further unauthorized email activity and potential spread of phishing or spam. +- Conduct a password reset for the affected account and enforce multi-factor authentication (MFA) to enhance security and prevent future unauthorized access. +- Review the audit logs for any additional suspicious activities associated with the compromised account, such as unusual login locations or times, and investigate any anomalies. +- Notify the affected user and relevant stakeholders about the incident, providing guidance on recognizing phishing attempts and securing their accounts. +- Escalate the incident to the security operations team for further analysis and to determine if other accounts or systems have been compromised. +- Implement additional email filtering rules to block similar phishing or spam patterns identified in the incident to prevent recurrence. +- Update and enhance detection rules and monitoring to quickly identify and respond to similar threats in the future, leveraging insights from the current incident. + +## Setup The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. """ diff --git a/rules/integrations/o365/initial_access_o365_user_reported_phish_malware.toml b/rules/integrations/o365/initial_access_o365_user_reported_phish_malware.toml index 0b96dcaff21..3d6fbb4b873 100644 --- a/rules/integrations/o365/initial_access_o365_user_reported_phish_malware.toml +++ b/rules/integrations/o365/initial_access_o365_user_reported_phish_malware.toml @@ -2,7 +2,7 @@ creation_date = "2022/01/12" integration = ["o365"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -18,7 +18,43 @@ index = ["filebeat-*", "logs-o365*"] language = "kuery" license = "Elastic License v2" name = "O365 Email Reported by User as Malware or Phish" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating O365 Email Reported by User as Malware or Phish + +Microsoft 365's email services are integral to business communication, but they can be exploited by adversaries through phishing or malware-laden emails. Attackers may bypass security measures, reaching users who might unwittingly engage with malicious content. The detection rule leverages user reports of suspicious emails, correlating them with security events to identify potential threats, thus enhancing the organization's ability to respond to phishing attempts and malware distribution. + +### Possible investigation steps + +- Review the details of the alert triggered by the rule "Email reported by user as malware or phish" in the SecurityComplianceCenter to understand the context and specifics of the reported email. +- Examine the event dataset from o365.audit to gather additional information about the email, such as sender, recipient, subject line, and any attachments or links included. +- Correlate the reported email with other security events or alerts to identify any patterns or related incidents that might indicate a broader phishing campaign or malware distribution attempt. +- Check the user's report against known phishing or malware indicators, such as suspicious domains or IP addresses, using threat intelligence sources to assess the credibility of the threat. +- Investigate the user's activity following the receipt of the email to determine if any actions were taken that could have compromised the system, such as clicking on links or downloading attachments. +- Assess the effectiveness of current security controls and awareness training by analyzing how the email bypassed existing defenses and was reported by the user. + +### False positive analysis + +- User-reported emails from trusted internal senders can trigger false positives. Encourage users to verify the sender's identity before reporting and consider adding these senders to an allowlist if they are consistently flagged. +- Automated system notifications or newsletters may be mistakenly reported as phishing. Educate users on recognizing legitimate automated communications and exclude these sources from triggering alerts. +- Emails containing marketing or promotional content from known vendors might be reported as suspicious. Train users to differentiate between legitimate marketing emails and phishing attempts, and create exceptions for verified vendors. +- Frequent reports of emails from specific domains that are known to be safe can lead to unnecessary alerts. Implement domain-based exceptions for these trusted domains to reduce false positives. +- Encourage users to provide detailed reasons for reporting an email as suspicious, which can help in refining detection rules and reducing false positives over time. + +### Response and remediation + +- Isolate the affected email account to prevent further interaction with potentially malicious content and to stop any ongoing unauthorized access. +- Quarantine the reported email and any similar emails identified in the system to prevent other users from accessing them. +- Conduct a thorough scan of the affected user's device and network for any signs of malware or unauthorized access, using endpoint detection and response tools. +- Reset the credentials of the affected user account and any other accounts that may have been compromised to prevent further unauthorized access. +- Notify the security team and relevant stakeholders about the incident, providing details of the threat and actions taken, to ensure coordinated response efforts. +- Review and update email filtering and security policies to address any identified gaps that allowed the malicious email to bypass existing controls. +- Monitor for any further suspicious activity related to the incident, using enhanced logging and alerting mechanisms to detect similar threats in the future. + +## Setup The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/o365/lateral_movement_malware_uploaded_onedrive.toml b/rules/integrations/o365/lateral_movement_malware_uploaded_onedrive.toml index 1e179228799..4f91024caab 100644 --- a/rules/integrations/o365/lateral_movement_malware_uploaded_onedrive.toml +++ b/rules/integrations/o365/lateral_movement_malware_uploaded_onedrive.toml @@ -2,7 +2,7 @@ creation_date = "2022/01/10" integration = ["o365"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -18,7 +18,44 @@ index = ["filebeat-*", "logs-o365*"] language = "kuery" license = "Elastic License v2" name = "OneDrive Malware File Upload" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating OneDrive Malware File Upload + +OneDrive, a cloud storage service, facilitates file sharing and collaboration within organizations. However, adversaries can exploit this by uploading malware, which can spread across shared environments, leading to lateral movement within a network. The detection rule identifies such threats by monitoring OneDrive activities for malware detection events, focusing on file operations flagged by Microsoft's security engine. This proactive approach helps in identifying and mitigating potential breaches. + +### Possible investigation steps + +- Review the alert details to confirm the event dataset is 'o365.audit' and the event provider is 'OneDrive' to ensure the alert is relevant to OneDrive activities. +- Examine the specific file operation flagged by the event code 'SharePointFileOperation' and action 'FileMalwareDetected' to identify the file in question and understand the nature of the detected malware. +- Identify the user account associated with the file upload to determine if the account has been compromised or if the user inadvertently uploaded the malicious file. +- Check the sharing settings of the affected file to assess the extent of exposure and identify any other users or systems that may have accessed the file. +- Investigate the file's origin and history within the organization to trace how it was introduced into the environment and whether it has been shared or accessed by other users. +- Review any additional security alerts or logs related to the user account or file to identify potential patterns of malicious activity or further compromise. +- Coordinate with IT and security teams to isolate the affected file and user account, and initiate remediation steps to prevent further spread of the malware. + +### False positive analysis + +- Legitimate software updates or patches may be flagged as malware if they are not yet recognized by the security engine. Users should verify the source and integrity of the file and consider adding it to an exception list if confirmed safe. +- Files containing scripts or macros used for automation within the organization might trigger false positives. Review the file's purpose and origin, and whitelist it if it is a known and trusted internal tool. +- Shared files from trusted partners or vendors could be mistakenly identified as threats. Establish a process to verify these files with the sender and use exceptions for recurring, verified files. +- Archived or compressed files that contain known safe content might be flagged due to their format. Decompress and scan the contents separately to confirm their safety before adding exceptions. +- Files with unusual or encrypted content used for legitimate business purposes may be misclassified. Ensure these files are documented and approved by IT security before excluding them from alerts. + +### Response and remediation + +- Immediately isolate the affected OneDrive account to prevent further file sharing and potential spread of malware within the organization. +- Notify the user associated with the account about the detected malware and instruct them to cease any file sharing activities until further notice. +- Conduct a thorough scan of the affected files using an updated antivirus or endpoint detection and response (EDR) solution to confirm the presence of malware and identify any additional infected files. +- Remove or quarantine the identified malicious files from OneDrive and any other locations they may have been shared to prevent further access or execution. +- Review and revoke any shared links or permissions associated with the infected files to ensure no unauthorized access is possible. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if any lateral movement or additional compromise has occurred. +- Implement enhanced monitoring and alerting for similar OneDrive activities to quickly detect and respond to any future malware uploads or related threats. + +## Setup The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/o365/lateral_movement_malware_uploaded_sharepoint.toml b/rules/integrations/o365/lateral_movement_malware_uploaded_sharepoint.toml index 4ba15633da1..c9b01a46066 100644 --- a/rules/integrations/o365/lateral_movement_malware_uploaded_sharepoint.toml +++ b/rules/integrations/o365/lateral_movement_malware_uploaded_sharepoint.toml @@ -2,7 +2,7 @@ creation_date = "2022/01/10" integration = ["o365"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -18,7 +18,43 @@ index = ["filebeat-*", "logs-o365*"] language = "kuery" license = "Elastic License v2" name = "SharePoint Malware File Upload" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating SharePoint Malware File Upload + +SharePoint, a collaborative platform, facilitates file sharing and storage within organizations. Adversaries exploit this by uploading malware, leveraging the platform's sharing capabilities to propagate threats laterally. The detection rule identifies when SharePoint's file scanning engine flags an upload as malicious, focusing on specific audit events to alert security teams of potential lateral movement threats. + +### Possible investigation steps + +- Review the specific event details in the alert, focusing on the event.dataset, event.provider, event.code, and event.action fields to confirm the alert is related to a SharePoint file upload flagged as malware. +- Identify the user account associated with the file upload by examining the audit logs and determine if the account has a history of suspicious activity or if it has been compromised. +- Analyze the file metadata, including the file name, type, and size, to gather more context about the nature of the uploaded file and assess its potential impact. +- Check the file's sharing permissions and access history to identify other users or systems that may have interacted with the file, assessing the risk of lateral movement. +- Investigate the source of the file upload, such as the originating IP address or device, to determine if it aligns with known malicious activity or if it is an anomaly for the user. +- Coordinate with the IT team to isolate affected systems or accounts if necessary, and initiate a response plan to mitigate any potential spread of the malware within the organization. + +### False positive analysis + +- Legitimate software updates or patches uploaded to SharePoint may be flagged as malware. To handle this, create exceptions for known update files by verifying their source and hash. +- Internal security tools or scripts used for testing purposes might trigger false positives. Maintain a list of these tools and exclude them from alerts after confirming their legitimacy. +- Files with encrypted content, such as password-protected documents, can be mistakenly identified as malicious. Implement a process to review and whitelist these files if they are from trusted sources. +- Large batch uploads from trusted departments, like IT or HR, may occasionally be flagged. Establish a review protocol for these uploads and whitelist them if they are verified as safe. +- Files with macros or executable content used in legitimate business processes might be detected. Work with relevant departments to identify and exclude these files from alerts after thorough validation. + +### Response and remediation + +- Immediately isolate the affected SharePoint site or library to prevent further access and sharing of the malicious file. This can be done by restricting permissions or temporarily disabling access to the site. +- Notify the security operations team and relevant stakeholders about the detected malware to ensure awareness and initiate a coordinated response. +- Quarantine the identified malicious file to prevent it from being accessed or executed by users. Use SharePoint's built-in capabilities or integrated security tools to move the file to a secure location. +- Conduct a thorough scan of the affected SharePoint site and connected systems to identify any additional malicious files or indicators of compromise. Use advanced threat detection tools to ensure comprehensive coverage. +- Review and revoke any unauthorized access or sharing permissions that may have been granted to the malicious file, ensuring that only legitimate users have access to sensitive data. +- Escalate the incident to the incident response team if there are signs of lateral movement or if the malware has spread to other parts of the network, following the organization's escalation protocols. +- Implement enhanced monitoring and logging for SharePoint and related services to detect any future attempts to upload or share malicious files, leveraging the specific query fields used in the detection rule. + +## Setup The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/o365/persistence_exchange_suspicious_mailbox_right_delegation.toml b/rules/integrations/o365/persistence_exchange_suspicious_mailbox_right_delegation.toml index 348964efd89..3d196114b69 100644 --- a/rules/integrations/o365/persistence_exchange_suspicious_mailbox_right_delegation.toml +++ b/rules/integrations/o365/persistence_exchange_suspicious_mailbox_right_delegation.toml @@ -2,7 +2,7 @@ creation_date = "2021/05/17" integration = ["o365"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic", "Austin Songer"] @@ -16,7 +16,42 @@ index = ["filebeat-*", "logs-o365*"] language = "kuery" license = "Elastic License v2" name = "O365 Exchange Suspicious Mailbox Right Delegation" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating O365 Exchange Suspicious Mailbox Right Delegation + +Microsoft 365 Exchange allows users to delegate mailbox access, enabling collaboration by granting permissions like FullAccess, SendAs, or SendOnBehalf. However, adversaries can exploit this by assigning these rights to compromised accounts, facilitating unauthorized access and message manipulation. The detection rule identifies successful permission assignments, excluding system accounts, to flag potential misuse and maintain security integrity. + +### Possible investigation steps + +- Review the event logs to identify the user account that was granted mailbox permissions, focusing on the user.id field to determine if the account is legitimate or potentially compromised. +- Examine the o365.audit.Parameters.AccessRights field to confirm the specific permissions granted (FullAccess, SendAs, or SendOnBehalf) and assess the potential impact of these permissions. +- Investigate the history of the user account that was granted permissions, including recent login activity and any unusual behavior, to identify signs of compromise. +- Check for any recent changes or anomalies in the mailbox that received the permissions, such as unexpected email forwarding rules or unusual email activity. +- Correlate the event with other security alerts or logs to identify any related suspicious activities or patterns that might indicate a broader security incident. + +### False positive analysis + +- Delegation for administrative purposes: Regular delegation of mailbox rights for administrative tasks can trigger alerts. To manage this, create exceptions for known administrative accounts that frequently require such permissions. +- Shared mailbox access: Organizations often use shared mailboxes for collaborative purposes. Identify and exclude these shared mailboxes from the rule to prevent false positives. +- Temporary project-based access: Temporary access granted for specific projects can be mistaken for suspicious activity. Implement a process to document and whitelist these temporary permissions. +- Automated system processes: Some automated processes may require mailbox access rights. Review and exclude these processes from the rule to avoid unnecessary alerts. +- Frequent delegation by specific roles: Certain roles, like executive assistants, may regularly delegate mailbox access. Identify these roles and adjust the rule to accommodate their typical behavior. + +### Response and remediation + +- Immediately revoke the delegated permissions identified in the alert to prevent further unauthorized access to the mailbox. +- Conduct a thorough review of the affected mailbox and any associated accounts to identify any unauthorized changes or suspicious activities, such as unexpected email forwarding rules or message deletions. +- Reset the passwords for the compromised account and any other accounts that may have been affected to prevent further unauthorized access. +- Notify the affected user(s) and relevant stakeholders about the incident, providing guidance on recognizing phishing attempts and securing their accounts. +- Escalate the incident to the security operations team for further investigation and to determine if additional accounts or systems have been compromised. +- Implement additional monitoring on the affected accounts and mailboxes to detect any further suspicious activities or attempts to re-establish unauthorized access. +- Review and update access control policies and permissions settings to ensure that only necessary permissions are granted and that they are regularly audited. + +## Setup The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" risk_score = 21 diff --git a/rules/integrations/o365/persistence_microsoft_365_exchange_dkim_signing_config_disabled.toml b/rules/integrations/o365/persistence_microsoft_365_exchange_dkim_signing_config_disabled.toml index 90ef1163536..ebb283e18d1 100644 --- a/rules/integrations/o365/persistence_microsoft_365_exchange_dkim_signing_config_disabled.toml +++ b/rules/integrations/o365/persistence_microsoft_365_exchange_dkim_signing_config_disabled.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/18" integration = ["o365"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -23,7 +23,42 @@ index = ["filebeat-*", "logs-o365*"] language = "kuery" license = "Elastic License v2" name = "Microsoft 365 Exchange DKIM Signing Configuration Disabled" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft 365 Exchange DKIM Signing Configuration Disabled + +DomainKeys Identified Mail (DKIM) is a security protocol that ensures email authenticity by allowing recipients to verify that messages are sent from authorized servers. Disabling DKIM can expose organizations to email spoofing, where attackers impersonate legitimate domains to conduct phishing attacks. The detection rule identifies when DKIM is disabled in Microsoft 365, signaling potential unauthorized changes that could facilitate persistent threats. + +### Possible investigation steps + +- Review the audit logs in Microsoft 365 to identify the user or service account associated with the event.action "Set-DkimSigningConfig" where o365.audit.Parameters.Enabled is False. This will help determine who or what initiated the change. +- Check the event.timestamp to establish when the DKIM signing configuration was disabled and correlate this with any other suspicious activities or changes in the environment around the same time. +- Investigate the event.outcome field to confirm that the action was successful and not a failed attempt, which could indicate a misconfiguration or unauthorized access attempt. +- Examine the event.provider and event.category fields to ensure that the event is specifically related to Exchange and web actions, confirming the context of the alert. +- Assess the risk score and severity level to prioritize the investigation and determine if immediate action is required to mitigate potential threats. +- Look into any recent changes in administrative roles or permissions that could have allowed unauthorized users to disable DKIM signing, focusing on persistence tactics as indicated by the MITRE ATT&CK framework reference. + +### False positive analysis + +- Routine administrative changes: Sometimes, DKIM signing configurations may be disabled temporarily during routine maintenance or updates by authorized IT personnel. To manage this, establish a process to document and approve such changes, and create exceptions in the monitoring system for these documented events. +- Testing and troubleshooting: IT teams may disable DKIM as part of testing or troubleshooting email configurations. Ensure that these activities are logged and approved, and consider setting up alerts that differentiate between test environments and production environments to reduce noise. +- Configuration migrations: During migrations to new email systems or configurations, DKIM may be disabled as part of the transition process. Implement a change management protocol that includes notifying the security team of planned migrations, allowing them to temporarily adjust monitoring rules. +- Third-party integrations: Some third-party email services may require DKIM to be disabled temporarily for integration purposes. Maintain a list of approved third-party services and create exceptions for these specific cases, ensuring that the security team is aware of and has approved the integration. + +### Response and remediation + +- Immediately re-enable DKIM signing for the affected domain in Microsoft 365 to restore email authenticity and prevent potential spoofing attacks. +- Conduct a review of recent administrative activities in Microsoft 365 to identify any unauthorized changes or suspicious behavior that may have led to the DKIM configuration being disabled. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized change and potential risks associated with it. +- Implement additional monitoring on the affected domain and related accounts to detect any further unauthorized changes or suspicious activities. +- Review and update access controls and permissions for administrative accounts in Microsoft 365 to ensure that only authorized personnel can modify DKIM settings. +- Escalate the incident to the organization's incident response team for further investigation and to determine if any additional security measures are necessary. +- Consider implementing additional email security measures, such as SPF and DMARC, to complement DKIM and enhance overall email security posture. + +## Setup The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/o365/persistence_microsoft_365_exchange_management_role_assignment.toml b/rules/integrations/o365/persistence_microsoft_365_exchange_management_role_assignment.toml index d445e6723d7..4c6ac6ae501 100644 --- a/rules/integrations/o365/persistence_microsoft_365_exchange_management_role_assignment.toml +++ b/rules/integrations/o365/persistence_microsoft_365_exchange_management_role_assignment.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/20" integration = ["o365"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -21,7 +21,43 @@ index = ["filebeat-*", "logs-o365*"] language = "kuery" license = "Elastic License v2" name = "Microsoft 365 Exchange Management Group Role Assignment" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft 365 Exchange Management Group Role Assignment + +Microsoft 365 Exchange Management roles define permissions for managing Exchange environments. Adversaries may exploit this by assigning roles to unauthorized users, ensuring persistent access. The detection rule monitors successful role assignments within Exchange, flagging potential unauthorized changes that align with persistence tactics, thus aiding in identifying and mitigating unauthorized access attempts. + +### Possible investigation steps + +- Review the event details to confirm the event.action is "New-ManagementRoleAssignment" and the event.outcome is "success" to ensure the alert is valid. +- Identify the user account associated with the role assignment by examining the event.dataset and event.provider fields, and verify if the account is authorized to make such changes. +- Check the history of role assignments for the identified user to determine if there are any patterns of unauthorized or suspicious activity. +- Investigate the specific management role that was assigned to understand its permissions and potential impact on the environment. +- Correlate this event with other recent activities from the same user or IP address to identify any additional suspicious behavior or anomalies. +- Consult with the relevant IT or security teams to verify if the role assignment was part of a legitimate administrative task or change request. + +### False positive analysis + +- Routine administrative role assignments can trigger alerts. Regularly review and document legitimate role changes to differentiate them from unauthorized activities. +- Automated scripts or tools used for role management may cause false positives. Identify and whitelist these tools to prevent unnecessary alerts. +- Changes made during scheduled maintenance windows might be flagged. Establish a process to temporarily suppress alerts during these periods while ensuring post-maintenance reviews. +- Role assignments related to onboarding or offboarding processes can appear suspicious. Implement a verification step to confirm these changes align with HR records and expected activities. +- Frequent role changes by specific users with administrative privileges may not indicate malicious intent. Monitor these users' activities and establish a baseline to identify deviations from normal behavior. + +### Response and remediation + +- Immediately revoke the newly assigned management role from the unauthorized user to prevent further unauthorized access or changes. +- Conduct a thorough review of recent activity logs for the affected account to identify any suspicious actions taken since the role assignment. +- Reset the credentials of the compromised account and enforce multi-factor authentication to enhance security. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring on the affected account and similar high-privilege accounts to detect any further unauthorized attempts. +- Review and update access control policies to ensure that only authorized personnel can assign management roles in Microsoft 365. +- Consider conducting a security awareness session for administrators to reinforce the importance of monitoring and managing role assignments securely. + +## Setup The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/o365/persistence_microsoft_365_global_administrator_role_assign.toml b/rules/integrations/o365/persistence_microsoft_365_global_administrator_role_assign.toml index 821b0bf2f8c..c7e9e7b27b1 100644 --- a/rules/integrations/o365/persistence_microsoft_365_global_administrator_role_assign.toml +++ b/rules/integrations/o365/persistence_microsoft_365_global_administrator_role_assign.toml @@ -2,7 +2,7 @@ creation_date = "2022/01/06" integration = ["o365"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -18,7 +18,43 @@ index = ["filebeat-*", "logs-o365*"] language = "kuery" license = "Elastic License v2" name = "Microsoft 365 Global Administrator Role Assigned" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft 365 Global Administrator Role Assigned + +The Microsoft 365 Global Administrator role grants comprehensive administrative access across Azure AD and associated services, enabling full control over resources and settings. Adversaries may exploit this by assigning themselves or others to this role, ensuring persistent access and control. The detection rule identifies such unauthorized assignments by monitoring specific audit events, focusing on role changes to "Global Administrator," thus alerting security teams to potential misuse. + +### Possible investigation steps + +- Review the audit logs for the event dataset "o365.audit" with the event code "AzureActiveDirectory" to identify the specific user who was added to the Global Administrator role. +- Examine the "event.action" field to confirm the action "Add member to role" and verify the "o365.audit.ModifiedProperties.Role_DisplayName.NewValue" to ensure it is "Global Administrator." +- Identify the user account that performed the role assignment and assess their recent activities and login history for any signs of compromise or unusual behavior. +- Check the timestamp of the role assignment event to determine if it aligns with any known maintenance windows or authorized administrative activities. +- Investigate any associated IP addresses or devices used during the role assignment to determine if they are consistent with the user's typical access patterns or if they indicate potential unauthorized access. +- Review any recent changes to user permissions or roles within Azure AD to identify if there are other suspicious modifications that could indicate broader unauthorized access attempts. + +### False positive analysis + +- Routine administrative tasks may trigger alerts when legitimate IT staff are assigned the Global Administrator role temporarily for maintenance or configuration changes. To manage this, create exceptions for known IT personnel or scheduled maintenance windows. +- Automated scripts or third-party applications that require elevated permissions might be flagged if they are set to assign the Global Administrator role as part of their operation. Review and whitelist these scripts or applications if they are verified as safe and necessary. +- Organizational changes such as mergers or acquisitions can lead to legitimate role assignments that appear suspicious. Implement a review process for role changes during such periods to differentiate between legitimate and unauthorized assignments. +- Training or onboarding processes for new IT staff might involve temporary Global Administrator access, which could be misinterpreted as a threat. Establish a protocol for temporary access that includes logging and approval to prevent false positives. +- Changes in role assignments due to policy updates or compliance requirements can also trigger alerts. Ensure that these changes are documented and communicated to the security team to avoid unnecessary investigations. + +### Response and remediation + +- Immediately remove the unauthorized user from the Global Administrator role to prevent further unauthorized access and control over resources. +- Conduct a thorough review of recent changes in Azure AD to identify any other unauthorized role assignments or suspicious activities linked to the compromised account. +- Reset the credentials of the affected account and enforce multi-factor authentication (MFA) to secure the account against further unauthorized access. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized access and actions taken to mitigate the threat. +- Implement conditional access policies to restrict administrative role assignments to trusted locations and devices, reducing the risk of unauthorized changes. +- Review and update access logs and monitoring configurations to ensure comprehensive visibility into role changes and other critical activities in Azure AD. +- Conduct a post-incident analysis to identify the root cause of the breach and implement additional security measures to prevent similar incidents in the future. + +## Setup The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/o365/persistence_microsoft_365_teams_custom_app_interaction_allowed.toml b/rules/integrations/o365/persistence_microsoft_365_teams_custom_app_interaction_allowed.toml index a8da34138b9..830d693b3ac 100644 --- a/rules/integrations/o365/persistence_microsoft_365_teams_custom_app_interaction_allowed.toml +++ b/rules/integrations/o365/persistence_microsoft_365_teams_custom_app_interaction_allowed.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/30" integration = ["o365"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,44 @@ index = ["filebeat-*", "logs-o365*"] language = "kuery" license = "Elastic License v2" name = "Microsoft 365 Teams Custom Application Interaction Allowed" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft 365 Teams Custom Application Interaction Allowed + +Microsoft Teams allows organizations to enhance functionality by integrating custom applications, which can be developed and uploaded beyond the standard app store offerings. While beneficial for tailored solutions, this capability can be exploited by adversaries to maintain unauthorized access. The detection rule monitors changes in tenant settings that permit custom app interactions, flagging successful modifications as potential persistence threats. + +### Possible investigation steps + +- Review the audit logs for the specific event.action: TeamsTenantSettingChanged to identify when the change was made and by whom. +- Verify the identity of the user or account associated with the event to determine if the change was authorized or if the account may have been compromised. +- Check the o365.audit.Name field for "Allow sideloading and interaction of custom apps" to confirm that the alert corresponds to enabling custom app interactions. +- Investigate the o365.audit.NewValue field to ensure it is set to True, indicating that the setting was indeed changed to allow custom apps. +- Assess the event.outcome field to confirm the change was successful and not a failed attempt, which could indicate a different type of issue. +- Examine any recent custom applications uploaded to Microsoft Teams to ensure they are legitimate and not potentially malicious. +- Cross-reference with other security alerts or logs to identify any unusual activity around the time of the setting change that might suggest malicious intent. + +### False positive analysis + +- Routine administrative changes to Microsoft Teams settings can trigger this rule. If a known and authorized administrator frequently updates tenant settings to allow custom apps, consider creating an exception for their user account to reduce noise. +- Organizations that regularly develop and deploy custom applications for internal use may see frequent alerts. In such cases, establish a process to document and approve these changes, and use this documentation to create exceptions for specific application deployment activities. +- Scheduled updates or maintenance activities that involve enabling custom app interactions might be misidentified as threats. Coordinate with IT teams to schedule these activities and temporarily adjust monitoring rules to prevent false positives during these periods. +- If a third-party service provider is authorized to manage Teams settings, their actions might trigger alerts. Verify their activities and, if consistent and legitimate, add their actions to an exception list to prevent unnecessary alerts. +- Changes made during a known testing or development phase can be mistaken for unauthorized access. Clearly define and communicate these phases to the security team, and consider temporary rule adjustments to accommodate expected changes. + +### Response and remediation + +- Immediately disable the custom application interaction setting in Microsoft Teams to prevent further unauthorized access or persistence by adversaries. +- Conduct a thorough review of all custom applications currently uploaded to Microsoft Teams to identify any unauthorized or suspicious applications. Remove any that are not recognized or approved by the organization. +- Analyze the audit logs for any recent changes to the Teams settings and identify the user account responsible for enabling custom application interactions. Investigate the account for signs of compromise or misuse. +- Reset the credentials and enforce multi-factor authentication for the account(s) involved in the unauthorized change to prevent further unauthorized access. +- Notify the security team and relevant stakeholders about the incident and the actions taken. Escalate to higher management if the breach is suspected to have wider implications. +- Implement additional monitoring and alerting for changes to Microsoft Teams settings to quickly detect and respond to similar threats in the future. +- Review and update the organization's security policies and procedures regarding the use of custom applications in Microsoft Teams to ensure they align with best practices and mitigate the risk of similar incidents. + +## Setup The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://docs.microsoft.com/en-us/microsoftteams/platform/concepts/deploy-and-publish/apps-upload"] diff --git a/rules/integrations/o365/persistence_microsoft_365_teams_external_access_enabled.toml b/rules/integrations/o365/persistence_microsoft_365_teams_external_access_enabled.toml index a47f63526f6..6698454c34a 100644 --- a/rules/integrations/o365/persistence_microsoft_365_teams_external_access_enabled.toml +++ b/rules/integrations/o365/persistence_microsoft_365_teams_external_access_enabled.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/30" integration = ["o365"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,43 @@ index = ["filebeat-*", "logs-o365*"] language = "kuery" license = "Elastic License v2" name = "Microsoft 365 Teams External Access Enabled" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft 365 Teams External Access Enabled + +Microsoft Teams' external access feature allows users to communicate with individuals outside their organization, facilitating collaboration. However, adversaries can exploit this by enabling external access or adding trusted domains to exfiltrate data or maintain persistence. The detection rule monitors audit logs for changes in federation settings, specifically when external access is successfully enabled, indicating potential misuse. + +### Possible investigation steps + +- Review the audit logs for the specific event.action "Set-CsTenantFederationConfiguration" to identify when and by whom the external access was enabled. +- Examine the o365.audit.Parameters.AllowFederatedUsers field to confirm that it is set to True, indicating that external access was indeed enabled. +- Investigate the user account associated with the event to determine if the action was authorized and if the account has a history of suspicious activity. +- Check the event.provider field to see if the change was made through SkypeForBusiness or MicrosoftTeams, which may provide additional context on the method used. +- Assess the event.outcome field to ensure the action was successful and not a failed attempt, which could indicate a potential security threat. +- Look into any recent changes in the list of allowed domains to identify if any unauthorized or suspicious domains have been added. + +### False positive analysis + +- Routine administrative changes to federation settings can trigger alerts. Regularly review and document these changes to differentiate between legitimate and suspicious activities. +- Organizations with frequent collaboration with external partners may see increased alerts. Consider creating exceptions for known trusted domains to reduce noise. +- Scheduled updates or policy changes by IT teams might enable external access temporarily. Coordinate with IT to log these activities and exclude them from triggering alerts. +- Automated scripts or tools used for configuration management can inadvertently enable external access. Ensure these tools are properly documented and monitored to prevent false positives. +- Changes made during mergers or acquisitions can appear suspicious. Maintain a record of such events and adjust monitoring rules accordingly to account for expected changes. + +### Response and remediation + +- Immediately disable external access in Microsoft Teams to prevent further unauthorized communication with external domains. +- Review and remove any unauthorized or suspicious domains added to the allowed list in the Teams federation settings. +- Conduct a thorough audit of recent changes in the Teams configuration to identify any other unauthorized modifications or suspicious activities. +- Reset credentials and enforce multi-factor authentication for accounts involved in the configuration change to prevent further unauthorized access. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Escalate the incident to the incident response team if there is evidence of data exfiltration or if the scope of the breach is unclear. +- Implement enhanced monitoring and alerting for changes in Teams federation settings to detect similar threats in the future. + +## Setup The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = ["https://docs.microsoft.com/en-us/microsoftteams/manage-external-access"] diff --git a/rules/integrations/o365/persistence_microsoft_365_teams_guest_access_enabled.toml b/rules/integrations/o365/persistence_microsoft_365_teams_guest_access_enabled.toml index cad302f3660..a4a4bcbe761 100644 --- a/rules/integrations/o365/persistence_microsoft_365_teams_guest_access_enabled.toml +++ b/rules/integrations/o365/persistence_microsoft_365_teams_guest_access_enabled.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/20" integration = ["o365"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -21,7 +21,42 @@ index = ["filebeat-*", "logs-o365*"] language = "kuery" license = "Elastic License v2" name = "Microsoft 365 Teams Guest Access Enabled" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft 365 Teams Guest Access Enabled + +Microsoft Teams allows organizations to collaborate with external users through guest access, facilitating communication and teamwork. However, adversaries can exploit this feature to gain persistent access to sensitive environments by enabling guest access without authorization. The detection rule monitors audit logs for specific configurations that indicate guest access has been enabled, helping identify unauthorized changes and potential security breaches. + +### Possible investigation steps + +- Review the audit logs to confirm the event.action "Set-CsTeamsClientConfiguration" was successfully executed with the parameter o365.audit.Parameters.AllowGuestUser set to True. +- Identify the user account responsible for enabling guest access by examining the event logs for the user ID or account name associated with the action. +- Check the user's activity history to determine if there are any other suspicious actions or patterns, such as changes to other configurations or unusual login times. +- Investigate the context of the change by reviewing any related communications or requests that might justify enabling guest access, ensuring it aligns with organizational policies. +- Assess the potential impact by identifying which teams and channels now have guest access enabled and evaluate the sensitivity of the information accessible to external users. +- Contact the user or their manager to verify if the change was authorized and necessary, and document their response for future reference. + +### False positive analysis + +- Legitimate collaboration with external partners may trigger alerts when guest access is enabled for business purposes. To manage this, create exceptions for known and approved external domains or specific projects that require guest access. +- Routine administrative actions by IT staff to enable guest access for specific teams or channels can be mistaken for unauthorized changes. Implement a process to log and approve such changes internally, and exclude these from triggering alerts. +- Automated scripts or third-party applications that configure Teams settings, including guest access, might cause false positives. Identify and whitelist these scripts or applications to prevent unnecessary alerts. +- Changes made during scheduled maintenance windows can be misinterpreted as unauthorized. Define and exclude these time periods from monitoring to reduce false positives. + +### Response and remediation + +- Immediately disable guest access in Microsoft Teams by updating the Teams client configuration to prevent unauthorized external access. +- Conduct a thorough review of recent audit logs to identify any unauthorized changes or suspicious activities related to guest access settings. +- Notify the security team and relevant stakeholders about the potential breach to ensure awareness and initiate further investigation. +- Revoke any unauthorized guest accounts that have been added to Teams to eliminate potential persistence mechanisms. +- Implement additional monitoring on Teams configurations to detect any future unauthorized changes to guest access settings. +- Escalate the incident to the organization's incident response team for a comprehensive investigation and to determine if further containment actions are necessary. +- Review and update access control policies to ensure that enabling guest access requires appropriate authorization and oversight. + +## Setup The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/o365/privilege_escalation_new_or_modified_federation_domain.toml b/rules/integrations/o365/privilege_escalation_new_or_modified_federation_domain.toml index 273f81c599d..bf5f8f2bf76 100644 --- a/rules/integrations/o365/privilege_escalation_new_or_modified_federation_domain.toml +++ b/rules/integrations/o365/privilege_escalation_new_or_modified_federation_domain.toml @@ -2,7 +2,7 @@ creation_date = "2021/05/17" integration = ["o365"] maturity = "production" -updated_date = "2024/05/31" +updated_date = "2025/01/10" [rule] author = ["Austin Songer"] @@ -14,7 +14,43 @@ index = ["filebeat-*", "logs-o365*"] language = "kuery" license = "Elastic License v2" name = "New or Modified Federation Domain" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating New or Modified Federation Domain + +Federation domains enable trust between Office 365 and external identity providers, facilitating seamless authentication. Adversaries may exploit this by altering federation settings to redirect authentication flows, potentially gaining unauthorized access. The detection rule monitors specific actions like domain modifications, signaling potential privilege escalation attempts, and alerts analysts to investigate these changes. + +### Possible investigation steps + +- Review the event logs for the specific actions listed in the query, such as "Set-AcceptedDomain" or "Add-FederatedDomain", to identify the exact changes made to the federation domain settings. +- Identify the user account associated with the event by examining the event logs, and verify if the account has the necessary permissions to perform such actions. +- Check the event.outcome field to confirm the success of the action and cross-reference with any recent administrative changes or requests to validate legitimacy. +- Investigate the event.provider and event.category fields to ensure the actions were performed through legitimate channels and not via unauthorized or suspicious methods. +- Analyze the timing and frequency of the federation domain changes to detect any unusual patterns or repeated attempts that could indicate malicious activity. +- Correlate the detected changes with any recent alerts or incidents involving privilege escalation or unauthorized access attempts to assess potential links or broader security implications. + +### False positive analysis + +- Routine administrative changes to federation domains by IT staff can trigger alerts. To manage this, create exceptions for known and scheduled maintenance activities by trusted administrators. +- Automated scripts or tools used for domain management may cause false positives. Identify these scripts and exclude their actions from triggering alerts by whitelisting their associated accounts or IP addresses. +- Integration of new services or applications that require federation domain modifications can be mistaken for suspicious activity. Document these integrations and adjust the rule to recognize these legitimate changes. +- Changes made during organizational restructuring, such as mergers or acquisitions, might appear as unauthorized modifications. Coordinate with relevant departments to anticipate these changes and temporarily adjust monitoring thresholds or exclusions. +- Regular audits or compliance checks that involve domain settings adjustments can lead to false positives. Schedule these audits and inform the security team to prevent unnecessary alerts. + +### Response and remediation + +- Immediately disable any newly added or modified federation domains to prevent unauthorized access. This can be done using the appropriate administrative tools in Office 365. +- Review and revoke any suspicious or unauthorized access tokens or sessions that may have been issued through the compromised federation domain. +- Conduct a thorough audit of recent administrative actions and access logs to identify any unauthorized changes or access patterns related to the federation domain modifications. +- Escalate the incident to the security operations team for further investigation and to determine if additional containment measures are necessary. +- Implement additional monitoring on federation domain settings to detect any further unauthorized changes promptly. +- Communicate with affected stakeholders and provide guidance on any immediate actions they need to take, such as password resets or additional authentication steps. +- Review and update federation domain policies and configurations to ensure they align with best practices and reduce the risk of similar incidents in the future. + +## Setup The Office 365 Logs Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/okta/defense_evasion_first_occurence_public_app_client_credential_token_exchange.toml b/rules/integrations/okta/defense_evasion_first_occurence_public_app_client_credential_token_exchange.toml index 7feaeba1c62..5678e743fdd 100644 --- a/rules/integrations/okta/defense_evasion_first_occurence_public_app_client_credential_token_exchange.toml +++ b/rules/integrations/okta/defense_evasion_first_occurence_public_app_client_credential_token_exchange.toml @@ -2,7 +2,7 @@ creation_date = "2024/09/11" integration = ["okta"] maturity = "production" -updated_date = "2024/12/09" +updated_date = "2025/01/10" min_stack_version = "8.15.0" min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration." @@ -51,6 +51,40 @@ event.dataset: okta.system and not okta.debug_context.debug_data.flattened.requestedScopes: ("okta.logs.read" or "okta.eventHooks.read" or "okta.inlineHooks.read") and okta.outcome.reason: "no_matching_scope" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Unauthorized Scope for Public App OAuth2 Token Grant with Client Credentials + +OAuth 2.0 is a protocol for authorization, allowing apps to access resources on behalf of users. Public client apps, lacking secure storage, use client credentials for token grants. Adversaries may exploit compromised credentials to request unauthorized scopes. The detection rule identifies failed token grants due to scope mismatches, signaling potential misuse of client credentials. + +### Possible investigation steps + +- Review the `okta.actor.display_name` field to identify the public client app involved in the failed token grant attempt and determine if it is a known or expected application. +- Examine the `okta.debug_context.debug_data.flattened.requestedScopes` field to understand which unauthorized scopes were requested and assess their potential impact if accessed. +- Investigate the `okta.actor.type` field to confirm that the actor is indeed a public client app, which lacks secure storage, and evaluate the risk of compromised credentials. +- Check the `okta.outcome.reason` field for "no_matching_scope" to verify that the failure was due to a scope mismatch, indicating an attempt to access unauthorized resources. +- Analyze the `okta.client.user_agent.raw_user_agent` field to ensure the request did not originate from known Okta integrations, which are excluded from the rule, to rule out false positives. +- Correlate the event with other security logs or alerts to identify any patterns or additional suspicious activities related to the same client credentials or IP address. + +### False positive analysis + +- Frequent legitimate access attempts by known public client apps may trigger false positives. To manage this, consider creating exceptions for specific `okta.actor.display_name` values that are known to frequently request scopes without malicious intent. +- Automated processes or integrations that use client credentials might occasionally request scopes not typically associated with their function. Review these processes and, if deemed non-threatening, exclude their `okta.client.user_agent.raw_user_agent` from triggering the rule. +- Development or testing environments often simulate various OAuth 2.0 token grant scenarios, which can result in false positives. Identify and exclude these environments by their `okta.actor.display_name` or other distinguishing attributes. +- Regularly review and update the list of non-threatening scopes in `okta.debug_context.debug_data.flattened.requestedScopes` to ensure that legitimate scope requests are not flagged as unauthorized. + +### Response and remediation + +- Immediately revoke the compromised client credentials to prevent further unauthorized access attempts. +- Conduct a thorough review of the affected public client app's access logs to identify any successful unauthorized access or data exfiltration attempts. +- Notify the application owner and relevant security teams about the incident to ensure coordinated response efforts. +- Implement additional monitoring on the affected app and associated user accounts to detect any further suspicious activities. +- Update and enforce stricter access controls and scope permissions for public client apps to minimize the risk of unauthorized scope requests. +- Consider implementing multi-factor authentication (MFA) for accessing sensitive resources to add an additional layer of security. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if broader organizational impacts exist.""" [[rule.threat]] diff --git a/rules/integrations/okta/impact_okta_attempt_to_delete_okta_application.toml b/rules/integrations/okta/impact_okta_attempt_to_delete_okta_application.toml index 816c943f532..a3e7bef86ba 100644 --- a/rules/integrations/okta/impact_okta_attempt_to_delete_okta_application.toml +++ b/rules/integrations/okta/impact_okta_attempt_to_delete_okta_application.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/06" integration = ["okta"] maturity = "production" -updated_date = "2024/12/09" +updated_date = "2025/01/10" min_stack_version = "8.15.0" min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration." @@ -22,7 +22,42 @@ index = ["filebeat-*", "logs-okta*"] language = "kuery" license = "Elastic License v2" name = "Attempt to Delete an Okta Application" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Attempt to Delete an Okta Application + +Okta is a widely used identity management service that helps organizations manage user access to applications securely. Adversaries may target Okta applications to disrupt operations or weaken security by attempting deletions. The detection rule monitors system events for deletion actions, flagging potential threats with a low-risk score, aiding analysts in identifying and mitigating unauthorized attempts. + +### Possible investigation steps + +- Review the event logs for entries with event.dataset:okta.system and event.action:application.lifecycle.delete to confirm the attempted deletion action. +- Identify the user account associated with the deletion attempt and verify their role and permissions within the organization to assess if the action was authorized. +- Check the timestamp of the event to determine if the deletion attempt coincides with any known maintenance windows or authorized changes. +- Investigate the specific Okta application targeted for deletion to understand its importance and potential impact on business operations if it were successfully deleted. +- Examine any recent changes or unusual activities associated with the user account or the targeted application to identify potential indicators of compromise. +- Correlate this event with other security alerts or logs to determine if it is part of a broader attack or isolated incident. + +### False positive analysis + +- Routine maintenance activities by IT staff may trigger the rule when they legitimately delete or modify applications. To manage this, create exceptions for known maintenance periods or specific user accounts responsible for these tasks. +- Automated scripts or tools used for application lifecycle management might generate false positives. Identify these scripts and exclude their actions from triggering alerts by whitelisting their associated user accounts or service accounts. +- Testing environments where applications are frequently created and deleted for development purposes can lead to false positives. Exclude these environments from monitoring or adjust the rule to ignore actions within specific test domains. +- Changes in application configurations by authorized personnel for legitimate business needs may be flagged. Implement a process to log and approve such changes, allowing for easy identification and exclusion from alerts. + +### Response and remediation + +- Immediately isolate the affected Okta application to prevent further unauthorized actions. This can be done by temporarily disabling the application or restricting access to it. +- Review the audit logs and event details associated with the deletion attempt to identify the source of the action, including user accounts and IP addresses involved. +- Revoke access for any compromised or suspicious user accounts identified in the investigation to prevent further unauthorized actions. +- Restore the deleted application from backup if applicable, ensuring that all configurations and settings are intact. +- Notify the security team and relevant stakeholders about the incident, providing details of the attempted deletion and actions taken. +- Conduct a root cause analysis to determine how the unauthorized attempt was made and implement additional security controls to prevent similar incidents in the future. +- Enhance monitoring and alerting for Okta application lifecycle events to ensure rapid detection and response to any future unauthorized modification or deletion attempts. + +## Setup The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/okta/impact_okta_attempt_to_modify_okta_application.toml b/rules/integrations/okta/impact_okta_attempt_to_modify_okta_application.toml index 79b5c489099..05c6149972e 100644 --- a/rules/integrations/okta/impact_okta_attempt_to_modify_okta_application.toml +++ b/rules/integrations/okta/impact_okta_attempt_to_modify_okta_application.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/06" integration = ["okta"] maturity = "production" -updated_date = "2024/12/09" +updated_date = "2025/01/10" min_stack_version = "8.15.0" min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration." @@ -22,7 +22,42 @@ index = ["filebeat-*", "logs-okta*"] language = "kuery" license = "Elastic License v2" name = "Attempt to Modify an Okta Application" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Attempt to Modify an Okta Application + +Okta is a widely used identity management service that helps organizations manage user access to applications securely. Adversaries may target Okta applications to alter, deactivate, or delete them, aiming to compromise security controls or disrupt operations. The detection rule monitors system events for application lifecycle updates, flagging unauthorized modification attempts to preempt potential security breaches. + +### Possible investigation steps + +- Review the event logs for entries with event.dataset:okta.system and event.action:application.lifecycle.update to identify the specific application and user involved in the modification attempt. +- Verify the user's role and permissions within Okta to determine if they have legitimate access to modify the application. +- Check for any recent changes in user permissions or roles that might explain the modification attempt. +- Investigate the history of the application in question to see if there have been any previous unauthorized modification attempts or related security incidents. +- Correlate the event timestamp with other security logs and alerts to identify any concurrent suspicious activities or patterns that might indicate a broader attack. + +### False positive analysis + +- Routine administrative updates to Okta applications by authorized personnel can trigger alerts. To manage this, create exceptions for specific user accounts or roles known to perform regular maintenance. +- Scheduled application updates or maintenance activities may be flagged. Document these activities and adjust the monitoring schedule to avoid unnecessary alerts during these periods. +- Integration or testing environments often undergo frequent changes. Exclude these environments from monitoring or adjust the rule to focus on production environments only. +- Automated scripts or tools used for application management might generate false positives. Identify these tools and whitelist their actions to prevent unnecessary alerts. +- Changes made by third-party vendors or partners with legitimate access can be mistaken for unauthorized attempts. Ensure these entities are properly documented and their actions are accounted for in the monitoring setup. + +### Response and remediation + +- Immediately isolate the affected Okta application to prevent further unauthorized modifications. This can be done by temporarily disabling the application or restricting access to it. +- Review and revoke any unauthorized changes made to the application settings. Restore the application to its last known good configuration using backup or audit logs. +- Conduct a thorough audit of recent access logs to identify any unauthorized users or suspicious activities related to the application lifecycle updates. +- Escalate the incident to the security operations team for further investigation and to determine if there are any broader security implications or related incidents. +- Implement additional monitoring on the affected application and similar applications to detect any further unauthorized modification attempts. +- Review and update access controls and permissions for Okta applications to ensure that only authorized personnel have the ability to modify application settings. +- Communicate with relevant stakeholders, including IT and security teams, to inform them of the incident and any changes made to the application settings as part of the remediation process. + +## Setup The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/okta/impact_possible_okta_dos_attack.toml b/rules/integrations/okta/impact_possible_okta_dos_attack.toml index 6300d7e24df..203da221f31 100644 --- a/rules/integrations/okta/impact_possible_okta_dos_attack.toml +++ b/rules/integrations/okta/impact_possible_okta_dos_attack.toml @@ -2,7 +2,7 @@ creation_date = "2020/05/21" integration = ["okta"] maturity = "production" -updated_date = "2024/12/09" +updated_date = "2025/01/10" min_stack_version = "8.15.0" min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration." @@ -16,7 +16,42 @@ index = ["filebeat-*", "logs-okta*"] language = "kuery" license = "Elastic License v2" name = "Possible Okta DoS Attack" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Possible Okta DoS Attack + +Okta, a leading identity management service, is crucial for managing user access in organizations. Adversaries may exploit Okta by overwhelming it with requests, causing service disruptions. The detection rule identifies potential DoS attacks by monitoring specific Okta system events that indicate rate limit violations, signaling attempts to degrade service availability. + +### Possible investigation steps + +- Review the specific Okta system events that triggered the alert, focusing on event.action values such as application.integration.rate_limit_exceeded, system.org.rate_limit.warning, system.org.rate_limit.violation, and core.concurrency.org.limit.violation to understand the nature of the rate limit violations. +- Analyze the frequency and pattern of the triggered events to determine if there is a consistent or unusual spike in requests that could indicate a DoS attack. +- Identify the source IP addresses or user accounts associated with the excessive requests to determine if they are legitimate users or potential adversaries. +- Check for any recent changes or updates in the Okta configuration or integrations that might have inadvertently caused an increase in request rates. +- Correlate the Okta events with other network or application logs to identify any broader patterns or simultaneous attacks on other services that might suggest a coordinated effort. + +### False positive analysis + +- High-volume legitimate user activity can trigger rate limit warnings. Monitor for patterns of normal usage spikes, such as during company-wide meetings or product launches, and consider setting exceptions for these events. +- Automated processes or integrations that frequently interact with Okta may cause rate limit violations. Identify these processes and adjust their request rates or set exceptions to prevent false positives. +- Scheduled batch jobs that access Okta services might exceed rate limits. Review and optimize the scheduling of these jobs to distribute the load more evenly or whitelist them if they are essential and non-disruptive. +- Third-party applications integrated with Okta could inadvertently cause rate limit issues. Work with vendors to ensure their applications are optimized for Okta's rate limits or create exceptions for trusted applications. +- Temporary spikes in user activity due to password resets or account provisioning can lead to false positives. Implement monitoring to distinguish between these benign activities and potential threats, and adjust the rule to accommodate expected spikes. + +### Response and remediation + +- Immediately assess the impact on business operations by checking the availability and performance of Okta services. Coordinate with IT teams to ensure critical services remain operational. +- Contain the attack by implementing rate limiting or IP blocking for the identified sources of excessive requests. Use network security tools to enforce these restrictions. +- Notify the security operations center (SOC) and relevant stakeholders about the potential DoS attack to ensure awareness and coordinated response efforts. +- Review and adjust Okta's rate limit settings to mitigate the risk of future DoS attempts, ensuring they align with the organization's typical usage patterns. +- Escalate the incident to Okta support for further investigation and assistance in mitigating the attack, providing them with relevant logs and event details. +- Conduct a post-incident analysis to identify any gaps in the current security posture and update incident response plans accordingly. +- Enhance monitoring and alerting for similar threats by refining detection rules and ensuring they are tuned to capture early indicators of rate limit violations. + +## Setup The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/okta/initial_access_okta_fastpass_phishing.toml b/rules/integrations/okta/initial_access_okta_fastpass_phishing.toml index 7b3bfb33839..0b6e86b3b9b 100644 --- a/rules/integrations/okta/initial_access_okta_fastpass_phishing.toml +++ b/rules/integrations/okta/initial_access_okta_fastpass_phishing.toml @@ -2,7 +2,7 @@ creation_date = "2023/05/07" integration = ["okta"] maturity = "production" -updated_date = "2024/12/09" +updated_date = "2025/01/10" min_stack_version = "8.15.0" min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration." @@ -13,7 +13,42 @@ index = ["filebeat-*", "logs-okta*"] language = "kuery" license = "Elastic License v2" name = "Okta FastPass Phishing Detection" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Okta FastPass Phishing Detection + +Okta FastPass is a passwordless authentication solution that enhances security by verifying user identity without traditional credentials. Adversaries may attempt to exploit this by directing users to phishing sites mimicking legitimate services. The detection rule identifies failed authentication attempts where FastPass blocks access, indicating a phishing attempt, by analyzing specific event patterns and outcomes. + +### Possible investigation steps + +- Review the event details to confirm the presence of the specific outcome reason "FastPass declined phishing attempt" to ensure the alert is related to a phishing attempt. +- Identify the user associated with the failed authentication attempt and gather additional context about their recent activities and access patterns. +- Investigate the source IP address and geolocation of the failed authentication attempt to determine if it aligns with the user's typical access locations or if it appears suspicious. +- Check for any other recent authentication attempts from the same user or IP address to identify potential patterns or repeated phishing attempts. +- Communicate with the affected user to verify if they received any suspicious communications or if they attempted to access any unfamiliar websites around the time of the alert. +- Review any additional logs or alerts from other security systems that might provide further context or corroborate the phishing attempt. + +### False positive analysis + +- Legitimate third-party applications that mimic the behavior of phishing sites may trigger false positives. Users can create exceptions for these applications by whitelisting their domains in the Okta FastPass settings. +- Internal testing environments that simulate phishing scenarios for training purposes might be flagged. To prevent this, ensure that these environments are registered and recognized within the Okta system to avoid unnecessary alerts. +- Users accessing legitimate services through unusual network paths or VPNs may be mistakenly identified as phishing attempts. Regularly review and update network configurations and trusted IP addresses to minimize these occurrences. +- Frequent failed authentication attempts due to user error, such as incorrect device settings or outdated software, can be mistaken for phishing. Educate users on maintaining their devices and software to align with Okta FastPass requirements to reduce these false positives. + +### Response and remediation + +- Immediately isolate the affected user accounts to prevent further unauthorized access attempts. This can be done by temporarily disabling the accounts or enforcing additional authentication measures. +- Notify the affected users about the phishing attempt and instruct them to avoid interacting with suspicious emails or websites. Provide guidance on recognizing phishing attempts. +- Conduct a thorough review of the affected users' recent activities to identify any potential data exposure or unauthorized access to sensitive information. +- Escalate the incident to the security operations team for further investigation and to determine if there are any broader implications or related incidents. +- Implement additional monitoring on the affected accounts and related systems to detect any further suspicious activities or attempts to bypass security controls. +- Review and update security policies and configurations related to Okta FastPass to ensure they are optimized for detecting and preventing similar phishing attempts in the future. +- Coordinate with the IT team to ensure that all systems and applications are patched and up-to-date to mitigate any vulnerabilities that could be exploited in conjunction with phishing attacks. + +## Setup The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule. diff --git a/rules/integrations/okta/initial_access_okta_user_attempted_unauthorized_access.toml b/rules/integrations/okta/initial_access_okta_user_attempted_unauthorized_access.toml index 1dcfb9ddfb6..8e66bf1f037 100644 --- a/rules/integrations/okta/initial_access_okta_user_attempted_unauthorized_access.toml +++ b/rules/integrations/okta/initial_access_okta_user_attempted_unauthorized_access.toml @@ -2,7 +2,7 @@ creation_date = "2021/05/14" integration = ["okta"] maturity = "production" -updated_date = "2024/12/09" +updated_date = "2025/01/10" min_stack_version = "8.15.0" min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration." @@ -13,7 +13,43 @@ index = ["filebeat-*", "logs-okta*"] language = "kuery" license = "Elastic License v2" name = "Unauthorized Access to an Okta Application" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Unauthorized Access to an Okta Application + +Okta is a widely used identity management service that facilitates secure user authentication and access to applications. Adversaries may exploit valid credentials to gain unauthorized access, bypassing security controls. The detection rule monitors specific Okta system events for unauthorized access attempts, leveraging event datasets and actions to identify potential breaches, thus aiding in early threat detection and response. + +### Possible investigation steps + +- Review the event logs for entries with event.dataset:okta.system and event.action:app.generic.unauth_app_access_attempt to identify the specific unauthorized access attempts. +- Identify the user accounts involved in the unauthorized access attempts and check for any unusual activity or patterns associated with these accounts. +- Investigate the source IP addresses associated with the unauthorized access attempts to determine if they are known or suspicious, and check for any geolocation anomalies. +- Examine the timestamps of the unauthorized access attempts to see if they coincide with any other suspicious activities or known incidents. +- Check for any recent changes in user permissions or configurations in the Okta system that might have facilitated the unauthorized access attempts. +- Contact the affected users to verify if they were aware of the access attempts and to ensure their credentials have not been compromised. + +### False positive analysis + +- Employees accessing applications from new devices or locations may trigger alerts. Regularly update the list of known devices and locations to minimize these false positives. +- Automated scripts or tools used for application testing might mimic unauthorized access attempts. Identify and whitelist these scripts to prevent unnecessary alerts. +- Users with multiple accounts accessing the same application can be mistaken for unauthorized access. Maintain an updated list of legitimate multi-account users to reduce false positives. +- Changes in user roles or permissions might lead to temporary access issues. Coordinate with HR or IT departments to ensure role changes are reflected promptly in the system. +- Scheduled maintenance or updates to applications can generate access attempts that appear unauthorized. Exclude these events by aligning detection rules with maintenance schedules. + +### Response and remediation + +- Immediately isolate the affected user account by disabling it to prevent further unauthorized access. +- Review and reset the credentials for the compromised account, ensuring the new password adheres to strong security policies. +- Conduct a thorough audit of recent activities associated with the compromised account to identify any unauthorized changes or data access. +- Notify the affected user and relevant stakeholders about the incident, providing guidance on recognizing phishing attempts and securing their accounts. +- Escalate the incident to the security operations team for further investigation and to determine if additional accounts or systems have been compromised. +- Implement multi-factor authentication (MFA) for the affected account and any other accounts that do not currently have it enabled to enhance security. +- Update and refine monitoring rules to detect similar unauthorized access attempts in the future, ensuring quick identification and response. + +## Setup The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/okta/initial_access_successful_application_sso_from_unknown_client_device.toml b/rules/integrations/okta/initial_access_successful_application_sso_from_unknown_client_device.toml index 2da36ae59b4..8d3ccc843e3 100644 --- a/rules/integrations/okta/initial_access_successful_application_sso_from_unknown_client_device.toml +++ b/rules/integrations/okta/initial_access_successful_application_sso_from_unknown_client_device.toml @@ -2,7 +2,7 @@ creation_date = "2024/10/07" integration = ["okta"] maturity = "production" -updated_date = "2024/12/09" +updated_date = "2025/01/10" min_stack_version = "8.15.0" min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration." @@ -40,6 +40,41 @@ event.dataset: "okta.system" and event.outcome: "success" and okta.client.device: ("Unknown" or "unknown") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Application SSO from Rare Unknown Client Device + +Single sign-on (SSO) streamlines user access across applications by using a single set of credentials. However, adversaries can exploit vulnerabilities in SSO systems, like Okta's, to bypass security policies using stolen credentials. The detection rule identifies unusual SSO events from unknown devices, signaling potential unauthorized access attempts, thus helping to mitigate risks associated with credential theft. + +### Possible investigation steps + +- Review the event details in the alert to confirm the presence of the "Unknown" or "unknown" client device in the okta.client.device field. +- Check the user-agent string associated with the event to gather more information about the unknown device and assess if it matches any known legitimate devices used by the user. +- Investigate the user's recent login history and patterns to identify any anomalies or deviations from their typical behavior, such as unusual login times or locations. +- Verify if there have been any recent changes to the user's account, such as password resets or modifications to multi-factor authentication settings, which could indicate account compromise. +- Cross-reference the IP address associated with the SSO event against known malicious IP databases or internal threat intelligence to identify potential threats. +- Contact the user to confirm whether they recognize the login activity and the device used, ensuring it was an authorized access attempt. + +### False positive analysis + +- Employees using new or updated devices may trigger false positives. Regularly update the list of recognized devices to include these changes. +- Legitimate users accessing applications from different locations or networks, such as while traveling, can appear as unknown devices. Implement geolocation checks and allow exceptions for known travel patterns. +- Software updates or changes in user-agent strings can cause devices to be misidentified. Monitor for consistent patterns and adjust the rule to accommodate these variations. +- Shared devices in environments like conference rooms or labs may not have unique identifiers. Establish a process to register these shared devices to prevent them from being flagged. +- Temporary network issues causing devices to appear as unknown can lead to false positives. Correlate with network logs to verify if the device is indeed unknown or if it was a transient issue. + +### Response and remediation + +- Immediately isolate the affected user account by disabling it to prevent further unauthorized access. +- Conduct a thorough review of the affected user's recent activity across all Okta-integrated applications to identify any unauthorized actions or data access. +- Reset the affected user's credentials and enforce a password change, ensuring the new password adheres to strong security policies. +- Implement multi-factor authentication (MFA) for the affected user account if not already in place, to add an additional layer of security. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Review and update Okta's device recognition policies to improve detection of unknown or rare devices, reducing the risk of similar incidents. +- Monitor for any further suspicious SSO activities from unknown devices and escalate to the incident response team if additional alerts are triggered.""" [[rule.threat]] diff --git a/rules/integrations/okta/initial_access_suspicious_activity_reported_by_okta_user.toml b/rules/integrations/okta/initial_access_suspicious_activity_reported_by_okta_user.toml index 12c7bfaf265..e106d1ee33a 100644 --- a/rules/integrations/okta/initial_access_suspicious_activity_reported_by_okta_user.toml +++ b/rules/integrations/okta/initial_access_suspicious_activity_reported_by_okta_user.toml @@ -2,7 +2,7 @@ creation_date = "2020/05/21" integration = ["okta"] maturity = "production" -updated_date = "2024/12/09" +updated_date = "2025/01/10" min_stack_version = "8.15.0" min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration." @@ -17,7 +17,43 @@ index = ["filebeat-*", "logs-okta*"] language = "kuery" license = "Elastic License v2" name = "Suspicious Activity Reported by Okta User" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Activity Reported by Okta User + +Okta is a widely used identity management service that facilitates secure user authentication and access control. Adversaries may exploit compromised credentials to gain unauthorized access, posing a threat to network security. The detection rule monitors for user-reported suspicious activity, signaling potential unauthorized access attempts. By analyzing these alerts, security teams can swiftly identify and mitigate threats, leveraging Okta's logging capabilities to trace and respond to malicious actions. + +### Possible investigation steps + +- Review the specific event details in the Okta logs where event.dataset is okta.system and event.action is user.account.report_suspicious_activity_by_enduser to gather initial context about the reported activity. +- Identify the user who reported the suspicious activity and check their recent login history and access patterns for any anomalies or deviations from their typical behavior. +- Correlate the reported suspicious activity with other security logs and alerts to determine if there are any related incidents or patterns indicating a broader attack. +- Verify if there are any known vulnerabilities or compromised credentials associated with the user's account that could have been exploited. +- Contact the user to gather additional information about the suspicious activity they observed and confirm whether they recognize any recent access attempts or changes to their account. +- Assess the risk and potential impact of the suspicious activity on the network and determine if any immediate containment or remediation actions are necessary. + +### False positive analysis + +- Users frequently accessing their accounts from new devices or locations may trigger false positives. Implement geofencing or device recognition to reduce these alerts. +- Routine administrative actions, such as password resets or account updates, might be misinterpreted as suspicious. Exclude these actions from alerts if they are performed by known administrators. +- Automated scripts or applications using service accounts can generate alerts if not properly configured. Ensure these accounts are whitelisted or have appropriate permissions set. +- Employees using VPNs or proxy services for remote work can cause location-based false positives. Consider marking known VPN IP addresses as safe. +- High-volume login attempts from legitimate users, such as during password recovery, can be mistaken for suspicious activity. Monitor for patterns and adjust thresholds accordingly. + +### Response and remediation + +- Immediately isolate the affected user account by temporarily disabling it to prevent further unauthorized access. +- Notify the user and relevant stakeholders about the suspicious activity and the actions being taken to secure the account. +- Conduct a password reset for the affected user account and enforce multi-factor authentication (MFA) if not already enabled. +- Review recent login activity and access logs for the affected account to identify any unauthorized access or data exfiltration attempts. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if other accounts or systems have been compromised. +- Implement additional monitoring on the affected account and related systems to detect any further suspicious activity. +- Update security policies and procedures based on findings to prevent similar incidents in the future, ensuring alignment with MITRE ATT&CK framework recommendations for Initial Access and Valid Accounts. + +## Setup The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/okta/lateral_movement_multiple_sessions_for_single_user.toml b/rules/integrations/okta/lateral_movement_multiple_sessions_for_single_user.toml index 9d015d679b8..a5a28d81aca 100644 --- a/rules/integrations/okta/lateral_movement_multiple_sessions_for_single_user.toml +++ b/rules/integrations/okta/lateral_movement_multiple_sessions_for_single_user.toml @@ -2,7 +2,7 @@ creation_date = "2023/11/07" integration = ["okta"] maturity = "production" -updated_date = "2024/12/19" +updated_date = "2025/01/10" min_stack_version = "8.15.0" min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration." @@ -20,7 +20,43 @@ interval = "30m" language = "kuery" license = "Elastic License v2" name = "Multiple Okta Sessions Detected for a Single User" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Multiple Okta Sessions Detected for a Single User + +Okta is a widely used identity management service that facilitates secure user authentication and access control. Adversaries may exploit Okta by hijacking session cookies, allowing unauthorized access to user accounts from different locations. The detection rule identifies anomalies by flagging multiple session initiations with distinct session IDs for the same user, excluding legitimate Okta system actors, thus highlighting potential unauthorized access attempts. + +### Possible investigation steps + +- Review the Okta logs to identify the specific user account associated with the multiple session initiations and note the distinct session IDs. +- Check the geographic locations and IP addresses associated with each session initiation to determine if there are any unusual or unexpected locations. +- Investigate the timestamps of the session initiations to see if they align with the user's typical login patterns or if they suggest simultaneous logins from different locations. +- Examine the okta.actor.id and okta.actor.display_name fields to ensure that the sessions were not initiated by legitimate Okta system actors. +- Contact the user to verify if they recognize the session activity and if they have recently logged in from multiple devices or locations. +- Assess if there are any other related security alerts or incidents involving the same user account that could indicate a broader compromise. + +### False positive analysis + +- Legitimate multiple device usage: Users may legitimately access their accounts from multiple devices, leading to multiple session initiations. To handle this, create exceptions for users who frequently use multiple devices for work. +- Frequent travel or remote work: Users who travel often or work remotely may trigger this rule due to accessing Okta from various locations. Consider setting up location-based exceptions for these users. +- Shared accounts: In environments where account sharing is common, multiple sessions may be expected. Implement policies to discourage account sharing or create exceptions for known shared accounts. +- Automated scripts or integrations: Some users may have automated processes that initiate multiple sessions. Identify these scripts and exclude them from the rule by their specific session patterns. +- Testing and development environments: Users involved in testing or development may generate multiple sessions as part of their work. Exclude these environments from the rule to prevent false positives. + +### Response and remediation + +- Immediately terminate all active sessions for the affected user account to prevent further unauthorized access. +- Reset the user's password and invalidate any existing session cookies to ensure that any stolen session cookies are rendered useless. +- Conduct a thorough review of recent login activity and session logs for the affected user to identify any suspicious or unauthorized access patterns. +- Notify the user of the potential compromise and advise them to verify any recent account activity for unauthorized actions. +- Escalate the incident to the security operations team for further investigation and to determine if additional accounts or systems may be affected. +- Implement multi-factor authentication (MFA) for the affected user account if not already in place, to add an additional layer of security against unauthorized access. +- Update and enhance monitoring rules to detect similar anomalies in the future, focusing on unusual session patterns and access from unexpected locations. + +## Setup The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/okta/persistence_administrator_privileges_assigned_to_okta_group.toml b/rules/integrations/okta/persistence_administrator_privileges_assigned_to_okta_group.toml index 0260f558495..4d714f8edb2 100644 --- a/rules/integrations/okta/persistence_administrator_privileges_assigned_to_okta_group.toml +++ b/rules/integrations/okta/persistence_administrator_privileges_assigned_to_okta_group.toml @@ -2,7 +2,7 @@ creation_date = "2020/05/21" integration = ["okta"] maturity = "production" -updated_date = "2024/12/09" +updated_date = "2025/01/10" min_stack_version = "8.15.0" min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration." @@ -23,7 +23,42 @@ index = ["filebeat-*", "logs-okta*"] language = "kuery" license = "Elastic License v2" name = "Administrator Privileges Assigned to an Okta Group" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Administrator Privileges Assigned to an Okta Group + +Okta is a widely used identity management service that facilitates secure user authentication and access control. Administrator privileges in Okta allow users to manage settings and permissions, making them a target for adversaries seeking persistent access. Malicious actors may exploit these privileges by assigning them to groups, thereby extending elevated access to compromised accounts. The detection rule monitors system events for privilege grants to groups, flagging potential unauthorized privilege escalations. + +### Possible investigation steps + +- Review the event logs for entries with event.dataset:okta.system and event.action:group.privilege.grant to identify the specific group and administrator role assigned. +- Identify the user account that initiated the privilege grant action and verify if the account has a history of suspicious activity or if it has been compromised. +- Check the membership of the affected Okta group to determine which user accounts have gained elevated privileges and assess if any of these accounts are unauthorized or compromised. +- Investigate recent activities of the affected group members to identify any unusual or unauthorized actions that may indicate malicious intent. +- Review the organization's change management records to confirm if the privilege assignment was part of an approved change request or if it was unauthorized. +- If unauthorized activity is confirmed, initiate incident response procedures to revoke the unauthorized privileges and secure the affected accounts. + +### False positive analysis + +- Routine administrative tasks may trigger alerts when legitimate IT staff assign administrator roles to groups for maintenance or updates. To manage this, create exceptions for known IT personnel or scheduled maintenance windows. +- Organizational changes such as mergers or department restructuring might require temporary privilege escalations. Document these changes and adjust the detection rule to exclude these specific events during the transition period. +- Automated scripts or third-party integrations that manage group permissions could inadvertently trigger false positives. Identify these scripts and whitelist their actions within the monitoring system to prevent unnecessary alerts. +- Training or onboarding sessions where temporary admin access is granted to groups for demonstration purposes can cause alerts. Ensure these sessions are logged and recognized as non-threatening to avoid false positives. + +### Response and remediation + +- Immediately revoke the administrator privileges assigned to the Okta group to prevent further unauthorized access or privilege escalation. +- Conduct a thorough review of recent group membership changes and privilege assignments in Okta to identify any other unauthorized modifications. +- Isolate and investigate any user accounts that were part of the affected group to determine if they have been compromised. +- Reset passwords and enforce multi-factor authentication (MFA) for all accounts that were part of the affected group to secure them against further unauthorized access. +- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordinated response efforts. +- Implement additional monitoring on the affected group and related user accounts to detect any further suspicious activities. +- Review and update access control policies to ensure that only necessary groups and users have administrative privileges, reducing the risk of similar incidents in the future. + +## Setup The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/okta/persistence_administrator_role_assigned_to_okta_user.toml b/rules/integrations/okta/persistence_administrator_role_assigned_to_okta_user.toml index 65649731dde..7a466c94fe8 100644 --- a/rules/integrations/okta/persistence_administrator_role_assigned_to_okta_user.toml +++ b/rules/integrations/okta/persistence_administrator_role_assigned_to_okta_user.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/06" integration = ["okta"] maturity = "production" -updated_date = "2024/12/09" +updated_date = "2025/01/10" min_stack_version = "8.15.0" min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration." @@ -23,7 +23,42 @@ index = ["filebeat-*", "logs-okta*"] language = "kuery" license = "Elastic License v2" name = "Administrator Role Assigned to an Okta User" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Administrator Role Assigned to an Okta User + +Okta is a widely used identity management service that facilitates secure user authentication and access control. In environments using Okta, assigning an administrator role grants elevated permissions, which can be exploited by adversaries to maintain unauthorized access. The detection rule monitors system events for privilege grants, flagging suspicious role assignments to mitigate potential abuse. + +### Possible investigation steps + +- Review the event details to confirm the presence of the event.dataset:okta.system and event.action:user.account.privilege.grant fields, ensuring the alert is triggered by the correct conditions. +- Identify the user account that was assigned the administrator role and gather information about their recent activities and login history to assess any unusual behavior. +- Check the timestamp of the role assignment event to determine if it coincides with any other suspicious activities or known incidents. +- Investigate the source IP address and location associated with the role assignment event to verify if it aligns with the user's typical access patterns. +- Review the change history for the affected user account to identify any other recent modifications or privilege escalations that may indicate malicious intent. +- Consult with the user or their manager to verify if the role assignment was authorized and legitimate, documenting any discrepancies or unauthorized actions. + +### False positive analysis + +- Routine administrative tasks may trigger the rule when legitimate IT staff assign administrator roles for maintenance or onboarding purposes. To manage this, create exceptions for known IT personnel or scheduled maintenance windows. +- Automated scripts or integrations that require elevated permissions might cause false positives. Identify these scripts and whitelist their associated accounts to prevent unnecessary alerts. +- Organizational changes such as mergers or department restructuring can lead to multiple legitimate role assignments. During these periods, temporarily adjust the rule sensitivity or increase monitoring to differentiate between expected and suspicious activities. +- Training or testing environments where roles are frequently assigned for simulation purposes can generate false positives. Exclude these environments from the rule or set up a separate monitoring profile for them. + +### Response and remediation + +- Immediately revoke the administrator role from the affected Okta user account to prevent further unauthorized access or privilege escalation. +- Conduct a thorough review of recent activity logs for the affected user account to identify any unauthorized actions or changes made while the elevated privileges were active. +- Reset the password and enforce multi-factor authentication (MFA) for the affected user account to secure it against potential compromise. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized role assignment and any identified malicious activities. +- Implement additional monitoring for the affected user account and similar accounts to detect any further suspicious activities or attempts to reassign elevated privileges. +- Review and update access control policies to ensure that administrator role assignments require additional verification or approval processes to prevent unauthorized changes. +- If evidence of broader compromise is found, initiate a full security incident response process, including forensic analysis and potential involvement of external cybersecurity experts. + +## Setup The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/okta/persistence_attempt_to_create_okta_api_token.toml b/rules/integrations/okta/persistence_attempt_to_create_okta_api_token.toml index babed655d21..99b2c26aea0 100644 --- a/rules/integrations/okta/persistence_attempt_to_create_okta_api_token.toml +++ b/rules/integrations/okta/persistence_attempt_to_create_okta_api_token.toml @@ -2,7 +2,7 @@ creation_date = "2020/05/21" integration = ["okta"] maturity = "production" -updated_date = "2024/12/09" +updated_date = "2025/01/10" min_stack_version = "8.15.0" min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration." @@ -23,7 +23,42 @@ index = ["filebeat-*", "logs-okta*"] language = "kuery" license = "Elastic License v2" name = "Attempt to Create Okta API Token" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Attempt to Create Okta API Token + +Okta API tokens are crucial for automating and managing identity and access tasks within an organization. However, if compromised, these tokens can be exploited by adversaries to gain persistent access, manipulate user accounts, or alter security settings. The detection rule identifies suspicious token creation activities by monitoring specific Okta system events, helping to thwart unauthorized access attempts. + +### Possible investigation steps + +- Review the event logs for entries with event.dataset:okta.system and event.action:system.api_token.create to identify the specific instance of API token creation. +- Identify the user account associated with the token creation event to determine if the action aligns with their typical behavior or role within the organization. +- Check the timestamp of the event to correlate with other security events or anomalies that occurred around the same time. +- Investigate the IP address and location from which the API token creation request originated to assess if it matches the user's usual access patterns. +- Examine any recent changes to user accounts or security settings that may have been executed using the newly created API token. +- Review the organization's policy on API token creation to ensure compliance and determine if the action was authorized. + +### False positive analysis + +- Routine administrative tasks may trigger the rule when legitimate IT staff create API tokens for automation or integration purposes. To manage this, maintain a list of authorized personnel and their expected activities, and create exceptions for these known users. +- Scheduled system maintenance or updates might involve creating API tokens, leading to false positives. Document these events and adjust the monitoring window or create temporary exceptions during these periods. +- Third-party integrations that require API tokens for functionality can also trigger alerts. Identify and whitelist these integrations by verifying their necessity and security compliance. +- Development and testing environments often involve frequent token creation for testing purposes. Exclude these environments from the rule or set up separate monitoring with adjusted thresholds to avoid unnecessary alerts. + +### Response and remediation + +- Immediately revoke the suspicious Okta API token to prevent any unauthorized access or actions within the organization's network. +- Conduct a thorough review of recent activities associated with the compromised token to identify any unauthorized changes or access attempts. +- Reset credentials and enforce multi-factor authentication for any accounts that were accessed or potentially compromised using the API token. +- Notify the security team and relevant stakeholders about the incident to ensure awareness and coordination for further investigation and response. +- Implement additional monitoring on Okta API token creation events to detect and respond to any further unauthorized attempts promptly. +- Review and update access controls and permissions related to API token creation to ensure they align with the principle of least privilege. +- Escalate the incident to senior security management if there is evidence of broader compromise or if the threat actor's objectives are unclear. + +## Setup The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/okta/persistence_attempt_to_reset_mfa_factors_for_okta_user_account.toml b/rules/integrations/okta/persistence_attempt_to_reset_mfa_factors_for_okta_user_account.toml index a615d4a5740..93af9c676ae 100644 --- a/rules/integrations/okta/persistence_attempt_to_reset_mfa_factors_for_okta_user_account.toml +++ b/rules/integrations/okta/persistence_attempt_to_reset_mfa_factors_for_okta_user_account.toml @@ -2,7 +2,7 @@ creation_date = "2020/05/21" integration = ["okta"] maturity = "production" -updated_date = "2024/12/09" +updated_date = "2025/01/10" min_stack_version = "8.15.0" min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration." @@ -23,7 +23,42 @@ index = ["filebeat-*", "logs-okta*"] language = "kuery" license = "Elastic License v2" name = "Attempt to Reset MFA Factors for an Okta User Account" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Attempt to Reset MFA Factors for an Okta User Account + +Okta is a widely used identity management service that provides multi-factor authentication (MFA) to enhance security. Adversaries may attempt to reset MFA factors to register their own, gaining unauthorized access while appearing legitimate. The detection rule identifies such attempts by monitoring specific Okta system events, helping to flag potential account manipulation activities. + +### Possible investigation steps + +- Review the Okta system logs for the specific event.action:user.mfa.factor.reset_all to identify the user account involved in the MFA reset attempt. +- Check the timestamp of the event to determine when the reset attempt occurred and correlate it with any other suspicious activities around the same time. +- Investigate the IP address and location associated with the event to assess if it aligns with the user's typical access patterns or if it appears unusual. +- Examine the user account's recent activity history for any anomalies or unauthorized access attempts that might indicate compromise. +- Verify if there have been any recent changes to the user's account settings or permissions that could suggest account manipulation. +- Contact the affected user to confirm whether they initiated the MFA reset or if it was unauthorized, and advise them on securing their account if necessary. + +### False positive analysis + +- Routine administrative actions may trigger the rule if IT staff reset MFA factors for legitimate reasons such as assisting users who have lost access to their MFA devices. To manage this, create exceptions for known IT personnel or specific administrative actions. +- User-initiated resets due to lost or changed devices can also appear as suspicious activity. Implement a process to verify user requests and document these instances to differentiate them from malicious attempts. +- Automated scripts or tools used for account management might reset MFA factors as part of their operations. Identify and whitelist these tools to prevent false positives. +- Scheduled security audits or compliance checks that involve resetting MFA factors should be documented and excluded from triggering alerts by setting up time-based exceptions during these activities. + +### Response and remediation + +- Immediately disable the affected Okta user account to prevent further unauthorized access. +- Review recent login activity and MFA changes for the affected account to identify any unauthorized access or suspicious behavior. +- Reset the MFA factors for the affected account and ensure that only the legitimate user can re-enroll their MFA devices. +- Notify the legitimate user of the account compromise and advise them to change their password and review their account activity. +- Conduct a security review of the affected user's permissions and access to sensitive resources to ensure no unauthorized changes were made. +- Escalate the incident to the security operations team for further investigation and to determine if other accounts may be affected. +- Update security monitoring and alerting to enhance detection of similar MFA reset attempts, leveraging the MITRE ATT&CK framework for guidance on persistence and account manipulation tactics. + +## Setup The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/okta/persistence_okta_attempt_to_modify_or_delete_application_sign_on_policy.toml b/rules/integrations/okta/persistence_okta_attempt_to_modify_or_delete_application_sign_on_policy.toml index 7373dae2b31..78582f3a80a 100644 --- a/rules/integrations/okta/persistence_okta_attempt_to_modify_or_delete_application_sign_on_policy.toml +++ b/rules/integrations/okta/persistence_okta_attempt_to_modify_or_delete_application_sign_on_policy.toml @@ -2,7 +2,7 @@ creation_date = "2020/07/01" integration = ["okta"] maturity = "production" -updated_date = "2024/12/09" +updated_date = "2025/01/10" min_stack_version = "8.15.0" min_stack_comments = "Breaking change at 8.15.0 for the Okta Integration." @@ -22,7 +22,43 @@ index = ["filebeat-*", "logs-okta*"] language = "kuery" license = "Elastic License v2" name = "Modification or Removal of an Okta Application Sign-On Policy" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Modification or Removal of an Okta Application Sign-On Policy + +Okta's sign-on policies are crucial for enforcing authentication controls within an organization. Adversaries may target these policies to weaken security by modifying or removing them, thus bypassing authentication measures. The detection rule monitors system events for updates or deletions of sign-on policies, flagging potential unauthorized changes to maintain security integrity. + +### Possible investigation steps + +- Review the event logs for entries with the dataset field set to okta.system to confirm the source of the alert. +- Examine the event.action field for values application.policy.sign_on.update or application.policy.sign_on.rule.delete to identify the specific action taken. +- Identify the user or system account associated with the event to determine if the action was performed by an authorized individual. +- Check the timestamp of the event to correlate with any other suspicious activities or changes in the system around the same time. +- Investigate the history of changes to the affected sign-on policy to understand the context and frequency of modifications or deletions. +- Assess the impact of the policy change on the organization's security posture and determine if any immediate remediation is necessary. +- If unauthorized activity is suspected, initiate a security incident response to contain and mitigate potential threats. + +### False positive analysis + +- Routine administrative updates to sign-on policies by authorized personnel can trigger alerts. To manage this, establish a list of trusted users or roles and create exceptions for their actions. +- Scheduled maintenance or policy reviews may involve legitimate modifications or deletions. Document these activities and adjust the detection rule to exclude events during known maintenance windows. +- Automated scripts or tools used for policy management might cause false positives. Identify these tools and configure the rule to recognize and exclude their expected actions. +- Changes due to integration with third-party applications can be mistaken for unauthorized modifications. Verify these integrations and whitelist their associated actions to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected Okta application to prevent further unauthorized access or changes. This can be done by disabling the application temporarily until the issue is resolved. +- Review the audit logs to identify the source of the modification or deletion attempt, focusing on the user account and IP address associated with the event. +- Revert any unauthorized changes to the sign-on policy by restoring it to the last known good configuration. Ensure that all security controls are reinstated. +- Conduct a thorough review of user accounts with administrative privileges in Okta to ensure they are legitimate and have not been compromised. Reset passwords and enforce multi-factor authentication (MFA) for these accounts. +- Notify the security team and relevant stakeholders about the incident, providing details of the attempted policy modification or deletion and the steps taken to contain the threat. +- Escalate the incident to higher-level security management if the source of the threat is internal or if there is evidence of a broader compromise. +- Implement additional monitoring and alerting for any future attempts to modify or delete sign-on policies, ensuring that similar threats are detected and addressed promptly. + +## Setup The Okta Fleet integration, Filebeat module, or similarly structured data is required to be compatible with this rule.""" references = [ diff --git a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_host.toml b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_host.toml index d3ae5ec27f7..caffb0df060 100644 --- a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_host.toml +++ b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_host.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/19" integration = ["problemchild", "endpoint", "windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -57,6 +57,40 @@ tags = [ "Tactic: Defense Evasion", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 by a Host + +The detection rule leverages machine learning to identify atypical processes on Windows systems, focusing on those that deviate from normal behavior. Adversaries often exploit legitimate system tools, known as LOLbins, to evade detection. This rule uses the ProblemChild ML model to flag processes that are both statistically unusual and potentially malicious, enhancing detection of stealthy attacks that bypass traditional methods. + +### Possible investigation steps + +- Review the process details flagged by the ProblemChild ML model, including the process name, path, and command line arguments, to understand its nature and potential purpose. +- Check the parent process of the flagged process to determine if it was spawned by a legitimate application or a known LOLbin, which might indicate a Living off the Land attack. +- Investigate the host's historical activity to assess whether this process or similar ones have been executed previously, focusing on any patterns of unusual behavior. +- Correlate the process activity with user logins and network connections to identify any suspicious user behavior or external communications that coincide with the process execution. +- Examine the system's security logs for any related alerts or anomalies around the time the process was detected, which might provide additional context or evidence of malicious activity. + +### False positive analysis + +- Routine administrative tasks may trigger false positives if they involve unusual processes or tools not commonly used on the host. Users can create exceptions for these known tasks to prevent unnecessary alerts. +- Software updates or installations can spawn processes that are atypical but benign. Identifying and excluding these processes during known maintenance windows can reduce false positives. +- Custom scripts or automation tools that mimic LOLbins behavior might be flagged. Users should document and whitelist these scripts if they are verified as safe and necessary for operations. +- Legitimate third-party applications that use system binaries in uncommon ways may be misclassified. Regularly review and update the list of approved applications to ensure they are not mistakenly flagged. +- Temporary spikes in unusual processes due to legitimate business activities, such as end-of-quarter reporting, can be managed by adjusting the detection thresholds or temporarily disabling the rule during these periods. + +### Response and remediation + +- Isolate the affected host from the network to prevent further spread or communication with potential command and control servers. +- Terminate the suspicious process identified by the ProblemChild ML model to halt any ongoing malicious activity. +- Conduct a thorough review of the process's parent and child processes to identify any additional malicious activity or persistence mechanisms. +- Remove any identified LOLbins or unauthorized tools used by the adversary from the system to prevent further exploitation. +- Restore the affected system from a known good backup if any system integrity issues are detected. +- Update endpoint protection and monitoring tools to ensure they can detect similar threats in the future, focusing on the specific techniques used in this incident. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_parent_process.toml b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_parent_process.toml index 479bddbead7..814d60c96cd 100644 --- a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_parent_process.toml +++ b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_parent_process.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/16" integration = ["problemchild", "endpoint", "windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -57,6 +57,42 @@ tags = [ "Tactic: Defense Evasion", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 by a Parent Process + +In Windows environments, processes are often spawned by parent processes to perform legitimate tasks. However, adversaries can exploit this by using legitimate tools, known as LOLbins, to execute malicious activities stealthily. The detection rule leverages machine learning to identify anomalies in process creation patterns, flagging processes that deviate from typical behavior, thus uncovering potential threats that evade traditional detection methods. + +### Possible investigation steps + +- Review the parent process and child process names to determine if they are known legitimate applications or if they are commonly associated with LOLbins or other malicious activities. +- Check the process creation time and correlate it with any known user activity or scheduled tasks to identify if the process execution aligns with expected behavior. +- Investigate the command line arguments used by the suspicious process to identify any unusual or potentially malicious commands or scripts being executed. +- Analyze the network activity associated with the process to detect any suspicious outbound connections or data exfiltration attempts. +- Examine the file path and hash of the executable to verify its legitimacy and check against known malware databases or threat intelligence sources. +- Review any recent changes to the system, such as software installations or updates, that might explain the unusual process behavior. +- Consult endpoint detection and response (EDR) logs or other security tools to gather additional context and evidence related to the process and its activities. + +### False positive analysis + +- Legitimate administrative tools like PowerShell or command prompt may be flagged when used for routine tasks. Users can create exceptions for these tools when executed by known and trusted parent processes. +- Software updates or installations often spawn processes that might appear unusual. Exclude these processes by identifying their typical parent-child relationships during updates. +- Custom scripts or automation tools used within the organization might trigger alerts. Document these scripts and their expected behavior to create exceptions for them. +- Frequent use of remote management tools can lead to false positives. Ensure these tools are whitelisted when used by authorized personnel. +- Regularly review and update the list of exceptions to accommodate changes in legitimate process behaviors over time. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity. +- Terminate the suspicious process identified by the alert to stop any ongoing malicious actions. +- Conduct a thorough analysis of the process and its parent to understand the scope of the compromise and identify any additional malicious activities or files. +- Remove any malicious files or artifacts associated with the process from the system to ensure complete remediation. +- Restore the system from a known good backup if the integrity of the system is compromised beyond repair. +- Update and patch the system to close any vulnerabilities that may have been exploited by the adversary. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_user.toml b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_user.toml index 14b9364879e..529f4d0e6ce 100644 --- a/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_user.toml +++ b/rules/integrations/problemchild/defense_evasion_ml_rare_process_for_a_user.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/16" integration = ["problemchild", "endpoint", "windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -58,6 +58,41 @@ tags = [ "Tactic: Defense Evasion", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 by a User + +The detection of unusual processes spawned by users leverages machine learning to identify anomalies in user behavior and process execution. Adversaries often exploit legitimate tools, known as LOLbins, to evade detection. This rule uses both supervised and unsupervised ML models to flag processes that deviate from typical user activity, indicating potential misuse or masquerading tactics. + +### Possible investigation steps + +- Review the user context associated with the alert to determine if the user has a history of spawning unusual processes or if this is an isolated incident. +- Examine the specific process flagged by the alert, including its command line arguments, parent process, and any associated network activity, to identify potential indicators of compromise. +- Check for the presence of known LOLbins or other legitimate tools that may have been exploited, as indicated by the alert's focus on defense evasion tactics. +- Investigate any recent changes in the user's behavior or system configuration that could explain the anomaly, such as software updates or new application installations. +- Correlate the alert with other security events or logs from the same timeframe to identify any related suspicious activities or patterns. +- Assess the risk score and severity level in the context of the organization's threat landscape to prioritize the response and determine if further action is needed. + +### False positive analysis + +- Legitimate administrative tools may trigger false positives if they are used in atypical contexts. Users should review the context of the process execution and, if deemed safe, add these tools to an exception list to prevent future alerts. +- Scheduled tasks or scripts that run infrequently might be flagged as unusual. Verify the legitimacy of these tasks and consider excluding them if they are part of regular maintenance or updates. +- Software updates or installations can spawn processes that appear anomalous. Confirm the source and purpose of these updates, and if they are routine, create exceptions for these specific processes. +- Developers or IT personnel using command-line tools for legitimate purposes may trigger alerts. Evaluate the necessity of these tools in their workflow and whitelist them if they are consistently used in a non-malicious manner. +- New or infrequently used applications might be flagged due to lack of historical data. Assess the application's legitimacy and, if appropriate, add it to a list of known safe applications to reduce false positives. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Terminate the suspicious process identified by the alert to halt any ongoing malicious activity. +- Conduct a thorough review of the user's recent activity and access logs to identify any unauthorized actions or data access. +- Reset the credentials of the affected user account to prevent further unauthorized access, ensuring that strong, unique passwords are used. +- Scan the system for additional indicators of compromise, such as other unusual processes or modifications to system files, and remove any identified threats. +- Restore the system from a known good backup if any critical system files or configurations have been altered. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_high_probability.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_high_probability.toml index 6e6e84e73d4..88951083683 100644 --- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_high_probability.toml +++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_high_probability.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/16" integration = ["problemchild", "endpoint", "windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -62,6 +62,41 @@ query = ''' process where ((problemchild.prediction == 1 and problemchild.prediction_probability > 0.98) or blocklist_label == 1) and not process.args : ("*C:\\WINDOWS\\temp\\nessus_*.txt*", "*C:\\WINDOWS\\temp\\nessus_*.tmp*") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Machine Learning Detected a Suspicious Windows Event with a High Malicious Probability Score + +The detection leverages a machine learning model, ProblemChild, to identify potentially malicious Windows processes by analyzing patterns and assigning a high probability score to suspicious activities. Adversaries may exploit legitimate processes to evade detection, often using techniques like masquerading. This rule flags high-risk events by focusing on processes with a high malicious probability score or those identified by a blocklist, excluding known benign activities. + +### Possible investigation steps + +- Review the process details flagged by the ProblemChild model, focusing on those with a prediction probability greater than 0.98 or identified by the blocklist. +- Examine the command-line arguments of the suspicious process to identify any unusual or unexpected patterns, excluding those matching known benign patterns like "*C:\\\\WINDOWS\\\\temp\\\\nessus_*.txt*" or "*C:\\\\WINDOWS\\\\temp\\\\nessus_*.tmp*". +- Check the parent process of the flagged event to determine if it is a legitimate process or if it has been potentially compromised. +- Investigate the user account associated with the process to assess if it has been involved in any other suspicious activities or if it has elevated privileges that could be exploited. +- Correlate the event with other security alerts or logs to identify any related activities or patterns that could indicate a broader attack campaign. +- Consult threat intelligence sources to determine if the process or its associated indicators are linked to known malicious activities or threat actors. + +### False positive analysis + +- Nessus scan files in the Windows temp directory may trigger false positives due to their temporary nature and frequent legitimate use. Users can mitigate this by adding exceptions for file paths like C:\\WINDOWS\\temp\\nessus_*.txt and C:\\WINDOWS\\temp\\nessus_*.tmp. +- Legitimate software updates or installations might be flagged if they mimic known malicious patterns. Users should review the process details and whitelist trusted software update processes. +- System administration tools that perform actions similar to those used in attacks could be misidentified. Users should verify the legitimacy of these tools and exclude them from the rule if they are part of regular administrative tasks. +- Custom scripts or automation tools that are not widely recognized might be flagged. Users should ensure these scripts are secure and add them to an allowlist if they are part of routine operations. +- Frequent false positives from specific processes can be managed by adjusting the threshold of the machine learning model or refining the blocklist to better distinguish between benign and malicious activities. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of potential malicious activity. +- Terminate the suspicious process identified by the ProblemChild model to halt any ongoing malicious actions. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional threats. +- Review and analyze the process execution history and associated files to understand the scope of the compromise and identify any persistence mechanisms. +- Restore any altered or deleted files from backups, ensuring that the backup is clean and free from malware. +- 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 enhanced monitoring and logging for similar processes and activities to detect and respond to future attempts at masquerading or defense evasion.""" [[rule.threat]] diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_low_probability.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_low_probability.toml index 12ba9cd1c50..a518558c9d1 100644 --- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_low_probability.toml +++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_event_low_probability.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/16" integration = ["problemchild", "endpoint"] maturity = "production" -updated_date = "2024/08/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -60,6 +60,41 @@ query = ''' process where ((problemchild.prediction == 1 and problemchild.prediction_probability <= 0.98) or blocklist_label == 1) and not process.args : ("*C:\\WINDOWS\\temp\\nessus_*.txt*", "*C:\\WINDOWS\\temp\\nessus_*.tmp*") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Machine Learning Detected a Suspicious Windows Event with a Low Malicious Probability Score + +The detection leverages a machine learning model to identify potentially suspicious Windows processes with a low likelihood of being malicious, focusing on defense evasion tactics like masquerading. Adversaries may exploit legitimate processes to bypass security measures. This rule flags such events, excluding known benign patterns, to highlight potential threats for further analysis. + +### Possible investigation steps + +- Review the process details where the problemchild.prediction is 1 and the prediction_probability is less than or equal to 0.98 to understand why the process was flagged as suspicious. +- Check if the process is listed in the blocklist_label as 1, indicating it has been identified as malicious by the model's blocklist. +- Investigate the command-line arguments of the process to identify any unusual or unexpected patterns, excluding known benign patterns such as those involving "C:\\WINDOWS\\temp\\nessus_*.txt" or "C:\\WINDOWS\\temp\\nessus_*.tmp". +- Correlate the flagged process with other system events or logs to determine if it is part of a larger pattern of suspicious activity, focusing on defense evasion tactics like masquerading. +- Assess the parent process and any child processes spawned by the suspicious process to identify potential lateral movement or further malicious activity. +- Consult threat intelligence sources to see if the process or its associated indicators have been reported in recent threat reports or advisories. + +### False positive analysis + +- Nessus scan files in the Windows temp directory may trigger false positives. Exclude paths like C:\\WINDOWS\\temp\\nessus_*.txt and C:\\WINDOWS\\temp\\nessus_*.tmp to prevent these benign events from being flagged. +- Legitimate software updates or installations might mimic suspicious behavior. Monitor and document regular update schedules to differentiate between expected and unexpected activities. +- System administration scripts that automate tasks can appear suspicious. Identify and whitelist these scripts if they are part of routine operations to avoid unnecessary alerts. +- Custom in-house applications may not be recognized by the model. Work with IT to catalog these applications and create exceptions where necessary to reduce false positives. +- Regularly review and update the blocklist and exception rules to ensure they reflect the current environment and known benign activities. + +### Response and remediation + +- Isolate the affected system from the network to prevent potential lateral movement by the adversary exploiting the masquerading technique. +- Terminate the suspicious process identified by the machine learning model to halt any ongoing malicious activity. +- Conduct a thorough review of the process's parent and child processes to identify any additional suspicious activities or related processes that may require termination. +- Restore the system from a known good backup if any malicious activity is confirmed, ensuring that the backup is free from compromise. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. +- Implement enhanced monitoring for similar masquerading attempts by adjusting alert thresholds or adding specific indicators of compromise (IOCs) related to the detected event. +- Escalate the incident to the security operations center (SOC) or relevant security team for further analysis and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_host.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_host.toml index 0b7e329bef3..0b38e523181 100644 --- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_host.toml +++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_host.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/16" integration = ["problemchild", "endpoint", "windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -57,6 +57,41 @@ tags = [ "Tactic: Defense Evasion", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Windows Process Cluster Spawned by a Host + +The detection leverages machine learning to identify clusters of Windows processes with high malicious probability scores. Adversaries exploit legitimate tools, known as LOLbins, to evade detection. This rule uses both supervised and unsupervised ML models to flag unusual process clusters on a single host, indicating potential masquerading tactics for defense evasion. + +### Possible investigation steps + +- Review the host name associated with the suspicious process cluster to determine if it is a critical asset or has a history of similar alerts. +- Examine the specific processes flagged by the ProblemChild supervised ML model to identify any known LOLbins or unusual command-line arguments that may indicate masquerading. +- Check the timeline of the process execution to see if it coincides with any known scheduled tasks or user activity that could explain the anomaly. +- Investigate the parent-child relationship of the processes to identify any unexpected or unauthorized process spawning patterns. +- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related suspicious activity. +- Assess the network activity associated with the host during the time of the alert to detect any potential data exfiltration or communication with known malicious IP addresses. + +### False positive analysis + +- Legitimate administrative tools like PowerShell or Windows Management Instrumentation (WMI) may be flagged as suspicious due to their dual-use nature. Users can create exceptions for these tools when used by trusted administrators or during scheduled maintenance. +- Automated scripts or scheduled tasks that perform routine system checks or updates might trigger alerts. Review these processes and whitelist them if they are verified as part of regular operations. +- Software updates or installations that involve multiple processes spawning in a short time frame can be mistaken for malicious clusters. Ensure that these activities are documented and create exceptions for known update processes. +- Development or testing environments where new or experimental software is frequently executed may generate false positives. Consider excluding these environments from monitoring or adjusting the sensitivity of the rule for these specific hosts. +- Frequent use of remote desktop or remote management tools by IT staff can appear suspicious. Implement user-based exceptions for known IT personnel to reduce unnecessary alerts. + +### Response and remediation + +- Isolate the affected host immediately to prevent further spread of potential malicious activity. Disconnect it from the network to contain the threat. +- Terminate the suspicious processes identified by the alert. Use task management tools or scripts to ensure all instances of the processes are stopped. +- Conduct a thorough review of the host's system logs and process history to identify any additional indicators of compromise or related malicious activity. +- Restore the host from a known good backup if available, ensuring that the backup is free from any signs of compromise. +- Update and patch the host's operating system and all installed software to close any vulnerabilities that may have been exploited. +- Implement application whitelisting to prevent unauthorized or suspicious processes from executing in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional hosts are affected.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_parent_process.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_parent_process.toml index 7e06990450b..5ab53fcfe3d 100644 --- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_parent_process.toml +++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_parent_process.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/16" integration = ["problemchild", "endpoint", "windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -59,6 +59,41 @@ tags = [ "Tactic: Defense Evasion", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Windows Process Cluster Spawned by a Parent Process + +In Windows environments, processes are often spawned by parent processes, forming a hierarchy. Adversaries exploit this by using legitimate processes to launch malicious ones, often leveraging Living off the Land Binaries (LOLBins) to evade detection. The detection rule employs machine learning to identify clusters of processes with high malicious probability, focusing on those sharing a common parent process. This approach helps uncover stealthy attacks that traditional methods might miss, enhancing defense against tactics like masquerading. + +### Possible investigation steps + +- Review the parent process name associated with the suspicious process cluster to identify if it is a known legitimate process or a potential masquerading attempt. +- Examine the command line arguments and execution context of the suspicious processes to identify any use of LOLBins or unusual patterns that could indicate malicious activity. +- Check the process creation timestamps and correlate them with any known events or user activities to determine if the process execution aligns with expected behavior. +- Investigate the network activity of the suspicious processes to identify any unusual outbound connections or data exfiltration attempts. +- Analyze the user account context under which the suspicious processes were executed to determine if there is any indication of compromised credentials or privilege escalation. +- Cross-reference the detected processes with threat intelligence sources to identify any known indicators of compromise or related threat actor activity. + +### False positive analysis + +- Legitimate administrative tools may trigger false positives if they frequently spawn processes that resemble malicious activity. Users can create exceptions for known safe tools by whitelisting their parent process names. +- Software updates or installations often generate clusters of processes that might be flagged as suspicious. Users should monitor these activities and exclude them if they are verified as legitimate. +- Automated scripts or batch jobs that run regularly and spawn multiple processes can be mistaken for malicious clusters. Identifying these scripts and excluding their parent processes can reduce false positives. +- Security software or monitoring tools that perform regular scans or updates might mimic malicious behavior. Users should ensure these tools are recognized and excluded from the rule's scope. +- Custom business applications that are not widely recognized might be flagged. Users should document and exclude these applications if they are confirmed to be safe and necessary for operations. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any ongoing malicious activity. +- Terminate the suspicious processes identified by the alert to stop any malicious actions they may be performing. +- Conduct a thorough review of the parent process and its associated binaries to ensure they have not been tampered with or replaced by malicious versions. +- Restore any affected files or system components from a known good backup to ensure system integrity and functionality. +- Update and patch the system to close any vulnerabilities that may have been exploited by the adversary, focusing on those related to LOLBins and masquerading techniques. +- Monitor the system and network for any signs of re-infection or related suspicious activity, using enhanced logging and alerting mechanisms. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_user.toml b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_user.toml index a010cb7e723..d289a466c6f 100644 --- a/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_user.toml +++ b/rules/integrations/problemchild/defense_evasion_ml_suspicious_windows_process_cluster_from_user.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/16" integration = ["problemchild", "endpoint", "windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -59,6 +59,41 @@ tags = [ "Tactic: Defense Evasion", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Windows Process Cluster Spawned by a User + +The detection leverages machine learning to identify clusters of Windows processes with high malicious probability, often linked to tactics like masquerading. Adversaries exploit legitimate tools (LOLBins) to evade detection. This rule uses both supervised and unsupervised ML models to flag unusual process clusters, focusing on user-associated anomalies to uncover potential threats. + +### Possible investigation steps + +- Review the list of processes flagged by the alert to identify any known legitimate applications or tools that might have been misclassified. +- Investigate the user account associated with the suspicious process cluster to determine if there is any history of unusual activity or if the account has been compromised. +- Examine the parent-child relationship of the processes to understand the execution chain and identify any potential masquerading attempts or use of LOLBins. +- Check for any recent changes or updates to the system that might explain the unusual process behavior, such as software installations or updates. +- Correlate the detected processes with any known indicators of compromise (IOCs) or threat intelligence feeds to assess if they are linked to known malicious activity. +- Analyze the network activity associated with the processes to identify any suspicious outbound connections or data exfiltration attempts. + +### False positive analysis + +- Legitimate administrative tools like PowerShell or Windows Management Instrumentation (WMI) may trigger false positives due to their frequent use in system management. Users can create exceptions for these tools when used by trusted administrators. +- Software updates or installations often involve processes that mimic suspicious behavior. Exclude these processes by identifying and whitelisting update-related activities from known software vendors. +- Automated scripts or scheduled tasks that perform routine maintenance can be misclassified as malicious. Review and whitelist these tasks if they are part of regular system operations. +- Development environments may spawn multiple processes that resemble malicious clusters. Developers should document and exclude these processes when they are part of legitimate development activities. +- Security software or monitoring tools might generate process clusters that appear suspicious. Ensure these tools are recognized and excluded from analysis to prevent false alerts. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of potential malicious activity. +- Terminate the suspicious processes identified by the alert to halt any ongoing malicious actions. +- Conduct a thorough review of the affected user's account for any unauthorized access or changes, and reset credentials if necessary. +- Analyze the use of any identified LOLBins to determine if they were used maliciously and restrict their execution through application whitelisting or policy adjustments. +- Collect and preserve relevant logs and forensic data from the affected system for further analysis and to aid in understanding the scope of the incident. +- Escalate the incident to the security operations center (SOC) or incident response team for a deeper investigation and to determine if additional systems are compromised. +- Implement enhanced monitoring and detection rules to identify similar patterns of behavior in the future, focusing on the specific tactics and techniques used in this incident.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/linux/collection_linux_clipboard_activity.toml b/rules/linux/collection_linux_clipboard_activity.toml index ab497282884..026edae82d9 100644 --- a/rules/linux/collection_linux_clipboard_activity.toml +++ b/rules/linux/collection_linux_clipboard_activity.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/27" integration = ["endpoint", "auditd_manager"] maturity = "production" -updated_date = "2024/10/18" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -36,6 +36,41 @@ event.action:("exec" or "exec_event" or "executed" or "process_started") and process.name:("xclip" or "xsel" or "wl-clipboard" or "clipman" or "copyq") and not process.parent.name:("bwrap" or "micro") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Clipboard Activity Detected + +Clipboard utilities on Linux, such as xclip and xsel, facilitate data transfer between applications by storing copied content temporarily. Adversaries exploit this by capturing sensitive data copied by users. The detection rule identifies unusual clipboard activity by monitoring processes that start these utilities, excluding common parent processes, to flag potential misuse. This helps in identifying unauthorized data collection attempts. + +### Possible investigation steps + +- Review the alert details to identify the specific process name that triggered the alert, focusing on clipboard utilities like xclip, xsel, wl-clipboard, clipman, or copyq. +- Examine the parent process of the detected clipboard utility to understand the context of its execution, ensuring it is not a common parent process like bwrap or micro. +- Investigate the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Check the timing and frequency of the clipboard utility's execution to assess if it coincides with any known user activities or if it suggests automated or unauthorized access. +- Analyze any related process events or logs around the time of the alert to identify potential data exfiltration attempts or other malicious activities. +- Consider correlating this alert with other security events or alerts to identify patterns or broader attack campaigns targeting clipboard data. + +### False positive analysis + +- Frequent use of clipboard utilities by legitimate applications or scripts can trigger false positives. Identify and document these applications to create exceptions in the detection rule. +- Developers and system administrators often use clipboard utilities in automated scripts. Review and whitelist these scripts to prevent unnecessary alerts. +- Some desktop environments or window managers may use clipboard utilities as part of their normal operation. Monitor and exclude these processes if they are verified as non-threatening. +- Regular user activities involving clipboard utilities for productivity tasks can be mistaken for suspicious behavior. Educate users on safe practices and adjust the rule to exclude known benign parent processes. +- Consider the context of the clipboard utility usage, such as time of day or user role, to refine detection criteria and reduce false positives. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential data exfiltration or further unauthorized access. +- Terminate any suspicious processes identified as running clipboard utilities without a common parent process, such as xclip or xsel, to stop potential data capture. +- Conduct a thorough review of recent clipboard activity logs to identify any sensitive data that may have been captured and assess the potential impact. +- Change passwords and rotate any credentials that may have been copied to the clipboard recently to mitigate the risk of credential theft. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement additional monitoring on the affected system to detect any further unauthorized clipboard activity or related suspicious behavior. +- Review and update endpoint security configurations to ensure that only authorized processes can access clipboard utilities, reducing the risk of future exploitation.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/command_and_control_aws_cli_endpoint_url_used.toml b/rules/linux/command_and_control_aws_cli_endpoint_url_used.toml index 67bd077656d..3ace9cf2077 100644 --- a/rules/linux/command_and_control_aws_cli_endpoint_url_used.toml +++ b/rules/linux/command_and_control_aws_cli_endpoint_url_used.toml @@ -2,7 +2,7 @@ creation_date = "2024/08/21" integration = ["endpoint"] maturity = "production" -updated_date = "2024/08/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -32,6 +32,40 @@ timestamp_override = "event.ingested" query = ''' host.os.type: "linux" and event.category: "process" and process.name: "aws" and process.args: "--endpoint-url" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS CLI Command with Custom Endpoint URL + +The AWS CLI allows users to interact with AWS services via command-line, offering flexibility in managing cloud resources. The `--endpoint-url` option lets users specify alternative endpoints, which can be exploited by adversaries to reroute requests to malicious servers, bypassing security controls. The detection rule identifies such misuse by monitoring for the `--endpoint-url` argument in process logs, flagging potential unauthorized activities. + +### Possible investigation steps + +- Review the process logs to identify the specific command line that triggered the alert, focusing on the presence of the --endpoint-url argument. +- Investigate the custom endpoint URL specified in the command to determine if it is a known malicious or unauthorized domain. +- Check the user account associated with the process to assess if it has a history of suspicious activity or if it has been compromised. +- Analyze network logs to trace any outbound connections to the custom endpoint URL and evaluate the data being transmitted. +- Correlate the event with other security alerts or logs to identify any patterns or additional indicators of compromise related to the same user or endpoint. +- Verify if the AWS credentials used in the command have been exposed or misused in other contexts, potentially indicating credential theft or abuse. + +### False positive analysis + +- Internal testing environments may use custom endpoint URLs for development purposes. To manage this, create exceptions for known internal IP addresses or domain names associated with these environments. +- Organizations using AWS CLI with custom endpoints for legitimate third-party integrations might trigger this rule. Identify and whitelist these specific integrations by their endpoint URLs to prevent false positives. +- Automated scripts or tools that interact with AWS services through custom endpoints for monitoring or backup purposes can be flagged. Review and document these scripts, then exclude them from detection by process name or specific endpoint URL. +- Some organizations may use proxy servers that require custom endpoint URLs for AWS CLI operations. Verify these configurations and exclude the associated endpoint URLs from the detection rule. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Review process logs and network traffic to identify any data that may have been redirected to unauthorized endpoints and assess the extent of potential data exposure. +- Revoke any AWS credentials or access keys used on the affected system to prevent further misuse and rotate them with new credentials. +- Conduct a thorough investigation to determine if any other systems have been compromised or if similar unauthorized endpoint usage has occurred elsewhere in the network. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional containment or remediation actions are necessary. +- Implement network-level controls to block known malicious endpoints and enhance monitoring for unusual AWS CLI usage patterns across the environment. +- Update security policies and endpoint protection configurations to detect and alert on the use of custom endpoint URLs in AWS CLI commands, ensuring rapid response to future incidents.""" [[rule.threat]] diff --git a/rules/linux/command_and_control_curl_socks_proxy_detected.toml b/rules/linux/command_and_control_curl_socks_proxy_detected.toml index 24109e074a5..7d3c4d99ca3 100644 --- a/rules/linux/command_and_control_curl_socks_proxy_detected.toml +++ b/rules/linux/command_and_control_curl_socks_proxy_detected.toml @@ -2,7 +2,7 @@ creation_date = "2024/11/04" integration = ["endpoint"] maturity = "production" -updated_date = "2024/11/04" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -79,6 +79,41 @@ process.name == "curl" and ( process.env_vars like ("http_proxy=socks5h://*", "HTTPS_PROXY=socks5h://*", "ALL_PROXY=socks5h://*") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Curl SOCKS Proxy Activity from Unusual Parent + +Curl is a versatile command-line tool used for transferring data with URLs, often employed for legitimate data retrieval. However, adversaries can exploit its SOCKS proxy capabilities to bypass network restrictions, facilitating covert data exfiltration or communication with command and control servers. The detection rule identifies suspicious curl executions initiated by atypical parent processes, such as those from temporary directories or shell environments, combined with SOCKS proxy arguments, indicating potential misuse. + +### Possible investigation steps + +- Review the parent process details to understand the context of the curl execution, focusing on unusual directories like /dev/shm, /tmp, or shell environments such as bash or zsh. +- Examine the command-line arguments used with curl, specifically looking for SOCKS proxy options like --socks5-hostname or -x, to determine the intent and destination of the network request. +- Investigate the environment variables set for the process, such as http_proxy or HTTPS_PROXY, to identify any proxy configurations that might indicate an attempt to bypass network restrictions. +- Check the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised. +- Analyze network logs to trace the destination IP addresses or domains contacted via the SOCKS proxy to assess if they are known malicious or suspicious entities. +- Correlate this activity with other alerts or logs from the same host to identify any patterns or additional indicators of compromise. + +### False positive analysis + +- Development environments may frequently use curl with SOCKS proxy options for legitimate testing purposes. To manage this, consider excluding specific development directories or user accounts from the rule. +- Automated scripts or cron jobs running from shell environments might use curl with SOCKS proxies for routine data retrieval. Identify these scripts and exclude their parent processes or specific arguments from triggering the rule. +- System administrators might use curl with SOCKS proxies for network diagnostics or maintenance tasks. Document these activities and create exceptions for known administrative accounts or specific command patterns. +- Web applications hosted in directories like /var/www/html may use curl for backend operations involving SOCKS proxies. Review these applications and whitelist their specific processes or arguments if they are verified as non-threatening. +- Temporary directories such as /tmp or /dev/shm might be used by legitimate software for transient operations involving curl. Monitor these occurrences and exclude known benign software from the rule. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further data exfiltration or communication with command and control servers. +- Terminate any suspicious curl processes identified by the detection rule to halt potential malicious activity. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized file modifications or additional malicious processes. +- Review and clean up any unauthorized or suspicious files in temporary directories or other unusual locations, such as /dev/shm, /tmp, or /var/tmp, to remove potential threats. +- Reset credentials and review access logs for any accounts that may have been compromised or used in conjunction with the detected activity. +- Implement network monitoring to detect and block any further attempts to use SOCKS proxy connections from unauthorized sources. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/command_and_control_ip_forwarding_activity.toml b/rules/linux/command_and_control_ip_forwarding_activity.toml index 442f15c5872..d22f4c5d8ef 100644 --- a/rules/linux/command_and_control_ip_forwarding_activity.toml +++ b/rules/linux/command_and_control_ip_forwarding_activity.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/06" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -45,6 +45,41 @@ process.parent.executable != null and process.command_line like ( ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 IPv4/IPv6 Forwarding Activity + +IPv4/IPv6 forwarding allows a Linux system to route traffic between network interfaces, facilitating network communication. While essential for legitimate network operations, adversaries can exploit this capability to pivot across networks, exfiltrate data, or maintain control channels. The detection rule identifies suspicious command executions that enable IP forwarding, focusing on specific command patterns and processes, thus highlighting potential misuse. + +### Possible investigation steps + +- Review the process command line details to understand the context in which IP forwarding was enabled, focusing on the specific command patterns identified in the alert. +- Identify the parent process of the suspicious command execution using the process.parent.executable field to determine if it was initiated by a legitimate or potentially malicious process. +- Check the user account associated with the process execution to assess if the action was performed by an authorized user or if there are signs of compromised credentials. +- Investigate recent network activity on the host to identify any unusual traffic patterns or connections that could indicate data exfiltration or lateral movement. +- Correlate the alert with other security events or logs from the same host or network segment to identify any related suspicious activities or patterns. +- Assess the system's current configuration and network topology to determine if enabling IP forwarding could have been part of a legitimate administrative task or if it poses a security risk. + +### False positive analysis + +- Routine administrative tasks may trigger the rule when system administrators enable IP forwarding for legitimate network configuration purposes. To manage this, create exceptions for known administrative scripts or processes that regularly perform these actions. +- Automated scripts or configuration management tools like Ansible or Puppet might execute commands that match the rule's criteria. Identify these tools and exclude their processes from the rule to prevent false alerts. +- Network testing or troubleshooting activities often require temporary enabling of IP forwarding. Document and exclude these activities when performed by trusted users or during scheduled maintenance windows. +- Virtualization or container orchestration platforms may enable IP forwarding as part of their normal operations. Recognize these platforms and adjust the rule to ignore their specific processes or command patterns. +- Security tools or network monitoring solutions might also enable IP forwarding for analysis purposes. Verify these tools and exclude their processes to avoid unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected Linux system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, particularly those enabling IP forwarding, to halt potential lateral movement or data exfiltration. +- Conduct a thorough review of network traffic logs to identify any unusual or unauthorized connections that may indicate command and control activity. +- Revert any unauthorized changes to system configurations, specifically those related to IP forwarding settings, to restore the system to its secure state. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised. +- Implement network segmentation to limit the ability of attackers to pivot between networks in the future. +- Enhance monitoring and alerting for similar suspicious activities by tuning detection systems to recognize patterns associated with IP forwarding misuse.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/command_and_control_linux_kworker_netcon.toml b/rules/linux/command_and_control_linux_kworker_netcon.toml index cebba118b0b..8ec9f67cd27 100644 --- a/rules/linux/command_and_control_linux_kworker_netcon.toml +++ b/rules/linux/command_and_control_linux_kworker_netcon.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/18" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -70,6 +70,40 @@ process.name:kworker* and not destination.ip:( "FF00::/8" ) and not destination.port:("2049" or "111" or "892" or "597") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Network Activity Detected via Kworker + +Kworker processes are integral to Linux systems, handling kernel tasks like interrupts and background activities. Adversaries may exploit these processes to mask malicious network activities, evading detection by blending in with legitimate kernel operations. The detection rule identifies suspicious network connections initiated by kworker processes, excluding trusted IP ranges and ports, to uncover potential command and control activities. + +### Possible investigation steps + +- Review the alert details to confirm the kworker process is indeed initiating network connections, focusing on the process.name field. +- Examine the destination IP address and port to determine if the connection is to an untrusted or suspicious external network, as the rule excludes trusted IP ranges and ports. +- Check historical data for any previous alerts or network activity involving the same kworker process to identify patterns or repeated behavior. +- Investigate the source host for any signs of compromise or unusual activity, such as unauthorized access attempts or unexpected process executions. +- Correlate the network activity with other security events or logs from the same timeframe to identify potential indicators of compromise or related malicious activities. + +### False positive analysis + +- Network monitoring tools or legitimate applications may occasionally use kworker processes for routine checks or updates, leading to false positives. Users can create exceptions for these specific applications by identifying their typical IP ranges and ports. +- Internal network scanning or monitoring activities might trigger alerts. To mitigate this, users should exclude known internal IP ranges and ports used by these activities from the detection rule. +- Automated backup or synchronization services that operate in the background could be mistaken for suspicious activity. Users should identify these services and adjust the rule to exclude their associated network traffic. +- Some system updates or maintenance tasks might temporarily use kworker processes for network communication. Users can whitelist the IP addresses and ports associated with these tasks to prevent false alerts. +- If a specific kworker process consistently triggers alerts without any malicious intent, users should investigate the process's behavior and, if deemed safe, add it to an exception list to avoid future false positives. + +### Response and remediation + +- Isolate the affected system from the network to prevent further malicious activity and potential lateral movement by the attacker. +- Terminate any suspicious kworker processes identified as initiating unauthorized network connections to halt ongoing malicious activities. +- Conduct a thorough forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized files or processes, and remove them. +- Update and patch the affected system to the latest security standards to close any vulnerabilities that may have been exploited. +- Monitor network traffic for any further suspicious activity originating from other systems, indicating potential spread or persistence of the threat. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Implement enhanced monitoring and logging for kworker processes and network activities to improve detection of similar threats in the future.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/credential_access_collection_sensitive_files.toml b/rules/linux/credential_access_collection_sensitive_files.toml index b4def3d777d..43cf85a3c34 100644 --- a/rules/linux/credential_access_collection_sensitive_files.toml +++ b/rules/linux/credential_access_collection_sensitive_files.toml @@ -2,7 +2,7 @@ creation_date = "2020/12/22" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -106,6 +106,40 @@ event.category:process and host.os.type:linux and event.type:start and /etc/gshadow ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Sensitive Files Compression + +Compression utilities like zip, tar, and gzip are essential for efficiently managing and transferring files. However, adversaries can exploit these tools to compress and exfiltrate sensitive data, such as SSH keys and configuration files. The detection rule identifies suspicious compression activities by monitoring process executions involving these utilities and targeting known sensitive file paths, thereby flagging potential data collection and credential access attempts. + +### Possible investigation steps + +- Review the process execution details to identify the user account associated with the compression activity, focusing on the process.name and process.args fields. +- Examine the command line arguments (process.args) to determine which specific sensitive files were targeted for compression. +- Check the event.timestamp to establish a timeline and correlate with other potentially suspicious activities on the host. +- Investigate the host's recent login history and user activity to identify any unauthorized access attempts or anomalies. +- Analyze network logs for any outbound connections from the host around the time of the event to detect potential data exfiltration attempts. +- Assess the integrity and permissions of the sensitive files involved to determine if they have been altered or accessed inappropriately. + +### False positive analysis + +- Routine system backups or administrative tasks may trigger the rule if they involve compressing sensitive files for legitimate purposes. Users can create exceptions for known backup scripts or administrative processes by excluding specific process names or command-line arguments associated with these tasks. +- Developers or system administrators might compress configuration files during development or deployment processes. To handle this, users can whitelist specific user accounts or directories commonly used for development activities, ensuring these actions are not flagged as suspicious. +- Automated scripts or cron jobs that regularly archive logs or configuration files could be mistakenly identified as threats. Users should review and exclude these scheduled tasks by identifying their unique process identifiers or execution patterns. +- Security tools or monitoring solutions that periodically compress and transfer logs for analysis might be misinterpreted as malicious. Users can exclude these tools by specifying their process names or paths in the detection rule exceptions. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further data exfiltration and unauthorized access. +- Terminate any suspicious processes identified by the detection rule to halt ongoing compression and potential data exfiltration activities. +- Conduct a thorough review of the compressed files and their contents to assess the extent of sensitive data exposure and determine if any data has been exfiltrated. +- Change all credentials associated with the compromised files, such as SSH keys and AWS credentials, to prevent unauthorized access using stolen credentials. +- Restore any altered or deleted configuration files from a known good backup to ensure system integrity and functionality. +- 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 enhanced monitoring and logging for compression utilities and sensitive file access to detect and respond to similar threats more effectively in the future.""" [[rule.threat]] diff --git a/rules/linux/credential_access_credential_dumping.toml b/rules/linux/credential_access_credential_dumping.toml index 8f23688749d..f7ae74be81c 100644 --- a/rules/linux/credential_access_credential_dumping.toml +++ b/rules/linux/credential_access_credential_dumping.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -66,6 +66,40 @@ query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and process.name == "unshadow" and process.args_count >= 3 ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Linux Credential Dumping via Unshadow + +Unshadow is a utility within the John the Ripper suite, used to merge `/etc/shadow` and `/etc/passwd` files, making them vulnerable to password cracking. Adversaries exploit this to extract and crack user credentials, gaining unauthorized access. The detection rule identifies suspicious execution of Unshadow by monitoring process activities, focusing on specific execution patterns and argument counts, thus flagging potential credential dumping attempts. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of the unshadow utility by checking the process name and arguments, ensuring that the process.args_count is 3 or more. +- Investigate the user account under which the unshadow process was executed to determine if it aligns with expected administrative activities or if it indicates potential unauthorized access. +- Examine the command line arguments used with the unshadow process to identify the specific files targeted, such as /etc/shadow and /etc/passwd, and verify if these files were accessed or modified. +- Check for any subsequent processes or activities that might indicate password cracking attempts, such as the execution of John the Ripper or similar tools, following the unshadow execution. +- Correlate the event with other security alerts or logs from the same host or user to identify any patterns or additional suspicious activities that might suggest a broader attack campaign. +- Assess the risk and impact by determining if any sensitive credentials were potentially exposed and consider implementing additional monitoring or access controls to prevent future incidents. + +### False positive analysis + +- System administrators or security teams may use the unshadow utility for legitimate auditing or recovery purposes. To handle this, create exceptions for known administrative accounts or specific maintenance windows. +- Automated scripts or backup processes might invoke unshadow as part of routine operations. Identify these scripts and exclude their execution paths or associated user accounts from triggering alerts. +- Security testing or penetration testing activities could involve the use of unshadow. Coordinate with the testing team to whitelist their activities during the testing period to avoid false positives. +- Development or testing environments might have unshadow executed as part of security tool evaluations. Exclude these environments from monitoring or adjust the rule to focus on production systems only. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes related to the unshadow utility to halt ongoing credential dumping activities. +- Conduct a thorough review of the affected system's `/etc/shadow` and `/etc/passwd` files to identify any unauthorized modifications or access. +- Change passwords for all user accounts on the affected system, prioritizing those with elevated privileges, to mitigate the risk of compromised credentials. +- Review and update access controls and permissions for sensitive files, ensuring that only authorized users have access to `/etc/shadow` and `/etc/passwd`. +- 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 enhanced monitoring and logging for similar activities across the network to detect and respond to future credential dumping attempts promptly.""" [[rule.threat]] diff --git a/rules/linux/credential_access_gdb_init_process_hooking.toml b/rules/linux/credential_access_gdb_init_process_hooking.toml index 316c22a5392..5bd4090db10 100644 --- a/rules/linux/credential_access_gdb_init_process_hooking.toml +++ b/rules/linux/credential_access_gdb_init_process_hooking.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -64,6 +64,40 @@ query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and process.name == "gdb" and process.args in ("--pid", "-p") and process.args == "1" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 init (PID 1) Secret Dump via GDB + +In Linux, the init process (PID 1) is the first process started by the kernel and is responsible for initializing the system. Adversaries may exploit debugging tools like GDB to dump memory from this process, potentially extracting sensitive information. The detection rule identifies suspicious GDB executions targeting PID 1, flagging unauthorized memory access attempts for further investigation. + +### Possible investigation steps + +- Review the alert details to confirm the process name is "gdb" and the process arguments include "--pid" or "-p" with a target of PID "1". +- Check the user account associated with the gdb process execution to determine if it is authorized to perform debugging tasks on the system. +- Investigate the parent process of the gdb execution to understand how it was initiated and whether it was part of a legitimate workflow or script. +- Examine system logs around the time of the alert to identify any other suspicious activities or related events that might indicate a broader attack. +- Assess the system for any unauthorized changes or anomalies, such as new user accounts, modified configurations, or unexpected network connections. +- If possible, capture and analyze memory dumps or other forensic artifacts to identify any sensitive information that may have been accessed or exfiltrated. + +### False positive analysis + +- System administrators or developers may use GDB for legitimate debugging purposes on the init process. To handle this, create exceptions for known maintenance windows or specific user accounts that are authorized to perform such actions. +- Automated scripts or monitoring tools might inadvertently trigger this rule if they include GDB commands targeting PID 1 for health checks. Review and adjust these scripts to avoid unnecessary memory access or exclude them from the rule if they are verified as safe. +- Security tools or forensic analysis software might use GDB as part of their operations. Identify these tools and whitelist their processes to prevent false positives while ensuring they are from trusted sources. +- Training or testing environments may simulate attacks or debugging scenarios involving GDB and PID 1. Exclude these environments from the rule to avoid noise, ensuring they are isolated from production systems. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate the suspicious gdb process targeting PID 1 to stop any ongoing memory dumping activity. +- Conduct a thorough review of system logs and process execution history to identify any additional unauthorized access attempts or related suspicious activities. +- Change all credentials and secrets that may have been exposed or accessed during the memory dump, focusing on those used by the init process and other privileged accounts. +- Implement stricter access controls and monitoring for debugging tools like gdb, ensuring only authorized personnel can execute such tools on critical systems. +- Escalate the incident to the security operations team for a comprehensive investigation and to determine if further forensic analysis is required. +- Update and enhance detection rules and monitoring systems to better identify and alert on similar unauthorized memory access attempts in the future.""" [[rule.threat]] diff --git a/rules/linux/credential_access_gdb_process_hooking.toml b/rules/linux/credential_access_gdb_process_hooking.toml index 25ac63aca2f..2636a3a4f98 100644 --- a/rules/linux/credential_access_gdb_process_hooking.toml +++ b/rules/linux/credential_access_gdb_process_hooking.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_ maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -42,6 +42,41 @@ process where host.os.type == "linux" and event.type == "start" and event.action /* Covered by d4ff2f53-c802-4d2e-9fb9-9ecc08356c3f */ process.args != "1" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Process Hooking via GDB + +GDB, the GNU Debugger, is a powerful tool used for debugging applications by inspecting their memory and execution flow. Adversaries can exploit GDB to attach to running processes, potentially extracting sensitive information like credentials. The detection rule identifies suspicious use of GDB by monitoring process initiation with specific arguments, flagging potential unauthorized memory access attempts for further investigation. + +### Possible investigation steps + +- Review the process details to confirm the presence of GDB by checking if the process name is "gdb" and the arguments include "--pid" or "-p". +- Identify the target process that GDB is attempting to attach to by examining the process arguments and cross-referencing the process ID. +- Investigate the user account under which the GDB process is running to determine if it is authorized to perform debugging tasks on the target process. +- Check the system logs and audit logs for any unusual activity or prior attempts to access sensitive processes or data around the time the GDB process was initiated. +- Correlate the event with other security alerts or anomalies in the environment to assess if this is part of a broader attack pattern or isolated incident. +- Evaluate the necessity and legitimacy of the GDB usage in the context of the system's normal operations and the user's role. +- If unauthorized access is suspected, consider isolating the affected system and conducting a deeper forensic analysis to prevent potential data exfiltration. + +### False positive analysis + +- Development and debugging activities may trigger the rule when developers use GDB for legitimate purposes. To manage this, create exceptions for specific user accounts or development environments where GDB usage is expected. +- Automated scripts or maintenance tasks that utilize GDB for process inspection can also cause false positives. Identify these scripts and exclude their execution paths or associated user accounts from the rule. +- Security tools or monitoring solutions that use GDB for legitimate process analysis might be flagged. Verify these tools and whitelist their processes or execution contexts to prevent unnecessary alerts. +- Training or educational environments where GDB is used for learning purposes can lead to false positives. Consider excluding these environments or specific user groups from the rule to avoid interference with educational activities. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate the GDB process if it is confirmed to be unauthorized, using process management tools to stop the process safely. +- Conduct a memory dump analysis of the affected system to identify any potential data leakage or extraction of sensitive information. +- Review system logs and audit trails to identify any additional unauthorized access attempts or related suspicious activities. +- Change credentials for any accounts that may have been exposed or accessed during the incident to prevent unauthorized use. +- Implement stricter access controls and monitoring for systems that handle sensitive information to prevent similar incidents. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/linux/credential_access_potential_linux_local_account_bruteforce.toml b/rules/linux/credential_access_potential_linux_local_account_bruteforce.toml index c53f414129c..0a91adfb2a8 100644 --- a/rules/linux/credential_access_potential_linux_local_account_bruteforce.toml +++ b/rules/linux/credential_access_potential_linux_local_account_bruteforce.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/26" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -62,6 +62,39 @@ sequence by host.id, process.parent.executable, user.id with maxspan=1s ) ] with runs=10 ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Linux Local Account Brute Force Detected + +In Linux environments, the 'su' command is used to switch user accounts, often requiring a password. Adversaries exploit this by attempting numerous logins with various passwords to gain unauthorized access. The detection rule identifies suspicious activity by monitoring rapid, repeated 'su' command executions from a single process, excluding common legitimate parent processes, indicating potential brute force attempts. + +### Possible investigation steps + +- Review the process execution details to identify the parent process of the 'su' command, focusing on any unusual or unauthorized parent processes not listed in the exclusion list. +- Analyze the frequency and pattern of the 'su' command executions from the identified process to determine if they align with typical user behavior or indicate a brute force attempt. +- Check the user account targeted by the 'su' command attempts to assess if it is a high-value or sensitive account that might be of interest to adversaries. +- Investigate the source host (host.id) to determine if there are any other suspicious activities or anomalies associated with it, such as unusual network connections or other security alerts. +- Correlate the event timestamps with other logs or alerts to identify any concurrent suspicious activities that might indicate a coordinated attack effort. + +### False positive analysis + +- Legitimate administrative scripts or automation tools may trigger the rule if they execute the 'su' command frequently. To mitigate this, identify and whitelist these scripts or tools by adding their parent process names to the exclusion list. +- Scheduled tasks or cron jobs that require switching users might be misidentified as brute force attempts. Review and exclude these tasks by specifying their parent process names in the exclusion criteria. +- Development or testing environments where frequent user switching is part of normal operations can generate false positives. Consider excluding these environments from monitoring or adjust the detection threshold to better fit the operational context. +- Continuous integration or deployment systems that use the 'su' command for user context switching can be mistaken for brute force attempts. Add these systems' parent process names to the exclusion list to prevent false alerts. + +### Response and remediation + +- Immediately isolate the affected host to prevent further unauthorized access or lateral movement within the network. +- Terminate the suspicious process identified by the detection rule to stop ongoing brute force attempts. +- Reset passwords for the targeted user accounts to prevent unauthorized access using potentially compromised credentials. +- Review and update the password policy to enforce strong, complex passwords and consider implementing account lockout mechanisms after a certain number of failed login attempts. +- Conduct a thorough review of the affected system for any signs of successful unauthorized access or additional malicious activity, such as new user accounts or scheduled tasks. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. +- Enhance monitoring and logging on the affected host and similar systems to detect and respond to future brute force attempts more effectively.""" [[rule.threat]] diff --git a/rules/linux/credential_access_potential_successful_linux_ftp_bruteforce.toml b/rules/linux/credential_access_potential_successful_linux_ftp_bruteforce.toml index 936f72da6b4..f07dd8fda75 100644 --- a/rules/linux/credential_access_potential_successful_linux_ftp_bruteforce.toml +++ b/rules/linux/credential_access_potential_successful_linux_ftp_bruteforce.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/06" integration = ["auditd_manager"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -75,6 +75,39 @@ sequence by host.id, auditd.data.addr, related.user with maxspan=5s auditd.data.terminal == "ftp" and event.outcome == "success" and auditd.data.addr != null and auditd.data.addr != "0.0.0.0" and auditd.data.addr != "::"] | tail 1 ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Successful Linux FTP Brute Force Attack Detected + +FTP is a protocol used for transferring files between systems, often requiring authentication. Adversaries exploit this by attempting numerous username-password combinations to gain unauthorized access, potentially leading to data breaches. The detection rule identifies a pattern of repeated failed login attempts from a single source, followed by a successful login, indicating a possible brute force attack. + +### Possible investigation steps + +- Review the source IP address (auditd.data.addr) involved in the failed and successful login attempts to determine if it is known or associated with previous malicious activity. +- Analyze the timeline of the failed login attempts followed by the successful login to assess the likelihood of a brute force attack, considering the maxspan of 5 seconds. +- Check the user account (related.user) targeted by the login attempts to determine if it is a high-value account or has been involved in previous security incidents. +- Investigate the host (host.id) where the login attempts occurred to identify any other suspicious activities or anomalies around the time of the alert. +- Correlate the detected activity with other logs or alerts from the same time period to identify potential lateral movement or further compromise within the network. + +### False positive analysis + +- Repeated failed logins from automated scripts or monitoring tools can trigger false positives. Identify and whitelist IP addresses of known internal systems or services that perform regular FTP checks. +- Users with incorrect credentials saved in FTP clients may cause multiple failed attempts before a successful login. Educate users on updating saved credentials and consider excluding specific user accounts from the rule if they frequently trigger alerts. +- Scheduled tasks or cron jobs that attempt to connect with outdated credentials can result in false positives. Review and update scheduled tasks to ensure they use current credentials, and exclude these tasks from monitoring if they are non-threatening. +- High-volume legitimate FTP traffic from trusted partners or vendors might mimic brute force patterns. Establish a list of trusted external IP addresses and exclude them from the rule to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Reset the compromised user account's password and any other accounts that may have been accessed using the same credentials. +- Review and analyze the logs from the affected system to identify any unauthorized changes or data access that occurred during the breach. +- Implement IP blocking or rate limiting for the source address identified in the alert to prevent further brute force attempts from the same origin. +- Conduct a thorough security assessment of the FTP server configuration to ensure it adheres to best practices, such as disabling anonymous access and enforcing strong password policies. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems were affected. +- Enhance monitoring and alerting for similar brute force patterns by ensuring that detection rules are tuned to capture variations in attack techniques.""" [[rule.threat]] diff --git a/rules/linux/credential_access_potential_successful_linux_rdp_bruteforce.toml b/rules/linux/credential_access_potential_successful_linux_rdp_bruteforce.toml index f4c9c353808..50aec20ada2 100644 --- a/rules/linux/credential_access_potential_successful_linux_rdp_bruteforce.toml +++ b/rules/linux/credential_access_potential_successful_linux_rdp_bruteforce.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/06" integration = ["auditd_manager"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -73,6 +73,40 @@ sequence by host.id, related.user with maxspan=5s [authentication where host.os.type == "linux" and event.action == "authenticated" and auditd.data.terminal : "*rdp*" and event.outcome == "success"] | tail 1 ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Successful Linux RDP Brute Force Attack Detected + +Remote Desktop Protocol (RDP) enables users to connect to and control remote systems, often used for administrative tasks. Adversaries exploit RDP by attempting numerous login attempts to gain unauthorized access, potentially leading to data breaches or further network infiltration. The detection rule identifies a pattern of failed login attempts followed by a successful one, indicating a possible brute force attack, thus alerting security teams to investigate and mitigate the threat. + +### Possible investigation steps + +- Review the authentication logs on the affected Linux host to identify the specific user account targeted by the failed and successful login attempts, focusing on entries with event.action as "authenticated" and auditd.data.terminal containing "*rdp*". +- Analyze the source IP addresses associated with the failed and successful login attempts to determine if they originate from known or suspicious locations. +- Check for any unusual activity or changes on the compromised system following the successful login, such as new user accounts, modified files, or unexpected network connections. +- Correlate the timestamps of the authentication events with other security logs to identify any concurrent suspicious activities or anomalies within the network. +- Investigate the user account's recent activity and permissions to assess potential impacts and determine if the account has been used for unauthorized access or lateral movement within the network. +- Evaluate the risk score and severity of the alert in the context of the organization's security posture and prioritize response actions accordingly. + +### False positive analysis + +- Legitimate administrative activities may trigger the rule if administrators frequently log in using RDP for system management. To handle this, create exceptions for known administrator accounts or IP addresses that regularly perform these tasks. +- Automated scripts or services that use RDP for routine operations can cause false positives. Identify these scripts and whitelist their associated user accounts or IPs to prevent unnecessary alerts. +- Scheduled tasks or cron jobs that involve RDP connections might be misinterpreted as brute force attempts. Exclude these tasks by specifying their user accounts or terminal identifiers in the rule configuration. +- Security testing or penetration testing activities can mimic brute force patterns. Coordinate with security teams to exclude these activities during testing periods by temporarily adjusting the rule parameters or adding exceptions for testing IP ranges. + +### Response and remediation + +- Immediately isolate the affected Linux host from the network to prevent further unauthorized access or lateral movement by the attacker. +- Reset the compromised user account's password and any other accounts that may have been accessed using the same credentials to prevent further unauthorized access. +- Conduct a thorough review of the affected system for any signs of additional compromise, such as unauthorized software installations or changes to system configurations, and remove any malicious artifacts. +- Implement multi-factor authentication (MFA) for RDP access to enhance security and reduce the risk of future brute force attacks. +- Review and tighten firewall rules to restrict RDP access to only trusted IP addresses and consider using a VPN for remote access. +- Monitor the network for any unusual activity or further attempts to exploit RDP, using enhanced logging and alerting mechanisms. +- Escalate the incident to the security operations center (SOC) or relevant security team for further investigation and to ensure comprehensive remediation and recovery actions are taken.""" [[rule.threat]] diff --git a/rules/linux/credential_access_proc_credential_dumping.toml b/rules/linux/credential_access_proc_credential_dumping.toml index d6efb4506b7..e9e86e781aa 100644 --- a/rules/linux/credential_access_proc_credential_dumping.toml +++ b/rules/linux/credential_access_proc_credential_dumping.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -70,6 +70,42 @@ sequence by host.id, process.parent.name with maxspan=1m [process where host.os.type == "linux" and process.name == "strings" and event.action in ("exec", "start", "exec_event") and process.args : "/tmp/*"] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Linux Credential Dumping via Proc Filesystem + +The /proc filesystem in Linux provides a window into the system's processes, offering details like memory usage and command-line arguments. Adversaries exploit this by using tools like mimipenguin to extract plaintext credentials from memory, leveraging vulnerabilities such as CVE-2018-20781. The detection rule identifies suspicious sequences involving the 'ps' and 'strings' commands, which are indicative of attempts to access and parse sensitive data from the /proc filesystem. + +### Possible investigation steps + +- Review the alert details to identify the specific host.id where the suspicious activity was detected, focusing on the processes involved. +- Examine the process execution history on the affected host to confirm the presence of the 'ps' and 'strings' commands executed in sequence, as indicated by the query. +- Investigate the command-line arguments used with the 'ps' and 'strings' commands to determine if they match the suspicious patterns specified in the query, such as '-eo pid command' and '/tmp/*'. +- Check for any recent modifications or suspicious files in the /tmp directory on the affected host, as this is a common location for temporary files used in attacks. +- Analyze the system logs and any available network traffic data to identify potential lateral movement or data exfiltration attempts following the credential dumping activity. +- Assess the system for any signs of compromise or additional malicious activity, such as unauthorized user accounts or unexpected network connections. +- Consider isolating the affected host from the network to prevent further credential exposure and initiate a comprehensive forensic analysis to understand the full scope of the incident. + +### False positive analysis + +- System administrators or monitoring tools may use the 'ps' and 'strings' commands for legitimate system diagnostics and performance monitoring. To mitigate this, create exceptions for known administrative scripts or tools that regularly execute these commands. +- Automated scripts for system health checks might trigger the rule if they use 'ps' and 'strings' to gather process information. Identify and whitelist these scripts by their specific command patterns or execution paths. +- Security tools that perform regular scans or audits might mimic the behavior detected by the rule. Review and exclude these tools by their process names or execution context to prevent false alerts. +- Developers or testers running debugging sessions may inadvertently trigger the rule when analyzing process memory. Establish a process to temporarily disable the rule or exclude specific user accounts during known testing periods. +- Custom monitoring solutions that log process details for analysis could match the rule's criteria. Document and exclude these solutions by their unique execution characteristics or host identifiers. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further credential exposure and potential lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, specifically those involving the 'ps' and 'strings' commands with the specified arguments. +- Conduct a thorough review of the affected system's process memory and logs to identify any additional unauthorized access or data exfiltration attempts. +- Change passwords for all user accounts on the affected system, prioritizing those with elevated privileges, to mitigate the risk of credential misuse. +- Apply patches and updates to address CVE-2018-20781 and any other known vulnerabilities on the affected system to prevent future exploitation. +- Enhance monitoring and logging on the affected host and similar systems to detect any recurrence of the exploit or similar suspicious activities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network.""" [[rule.threat]] diff --git a/rules/linux/credential_access_ssh_backdoor_log.toml b/rules/linux/credential_access_ssh_backdoor_log.toml index bbd78ee7232..d5ff14b489a 100644 --- a/rules/linux/credential_access_ssh_backdoor_log.toml +++ b/rules/linux/credential_access_ssh_backdoor_log.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/01/06" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -111,6 +111,41 @@ file where host.os.type == "linux" and event.type == "change" and process.execut ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 OpenSSH Backdoor Logging Activity + +OpenSSH is a widely used protocol for secure remote administration and file transfers. Adversaries may exploit OpenSSH by modifying its binaries to log credentials or maintain unauthorized access. The detection rule identifies suspicious file changes linked to SSH processes, focusing on unusual file names, extensions, and paths indicative of backdoor activity, thus helping to uncover potential security breaches. + +### Possible investigation steps + +- Review the file change event details to identify the specific file name, extension, and path involved in the alert. Pay particular attention to unusual file names or extensions and paths listed in the query, such as "/usr/lib/*.so.*" or "/private/etc/ssh/.sshd_auth". +- Examine the process executable that triggered the alert, either "/usr/sbin/sshd" or "/usr/bin/ssh", to determine if it has been modified or replaced. Check the integrity of these binaries using hash comparisons against known good versions. +- Investigate the user account associated with the process that made the file change. Determine if the account has a history of suspicious activity or if it has been compromised. +- Check for any recent or unusual login attempts or sessions related to the SSH service on the host. Look for patterns that might indicate unauthorized access or credential harvesting. +- Analyze system logs, such as auth.log or secure.log, for any anomalies or entries that coincide with the time of the file change event. This can provide additional context or evidence of malicious activity. +- If a backdoor is suspected, consider isolating the affected system from the network to prevent further unauthorized access and begin remediation efforts, such as restoring from a clean backup or reinstalling the affected services. + +### False positive analysis + +- Routine system updates or package installations may trigger file changes in SSH-related directories. Users can create exceptions for known update processes to prevent false alerts. +- Custom scripts or administrative tasks that modify SSH configuration files for legitimate purposes might be flagged. Users should whitelist these scripts or processes if they are verified as non-malicious. +- Backup or synchronization tools that create temporary files with unusual extensions or names in SSH directories can cause false positives. Exclude these tools from monitoring if they are part of regular operations. +- Development or testing environments where SSH binaries are frequently modified for testing purposes may generate alerts. Implement exclusions for these environments to reduce noise. +- Automated configuration management tools like Ansible or Puppet that modify SSH settings as part of their operations can be excluded if they are part of authorized workflows. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious SSH processes identified in the alert to halt potential backdoor activity. +- Conduct a thorough review of the modified files and binaries, particularly those listed in the query, to assess the extent of the compromise and identify any malicious code or unauthorized changes. +- Restore affected files and binaries from a known good backup to ensure system integrity and remove any backdoor modifications. +- Change all SSH credentials and keys associated with the compromised system to prevent unauthorized access using potentially logged credentials. +- Implement additional monitoring on the affected system and network for any signs of persistence or further malicious activity, focusing on the paths and file types highlighted in the detection query. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected, ensuring a coordinated response to the threat.""" [[rule.threat]] diff --git a/rules/linux/credential_access_unusual_instance_metadata_service_api_request.toml b/rules/linux/credential_access_unusual_instance_metadata_service_api_request.toml index f333f48428b..e34757ffb3d 100644 --- a/rules/linux/credential_access_unusual_instance_metadata_service_api_request.toml +++ b/rules/linux/credential_access_unusual_instance_metadata_service_api_request.toml @@ -2,7 +2,7 @@ creation_date = "2024/08/22" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -62,6 +62,40 @@ sequence by host.id, process.parent.entity_id with maxspan=1s and event.action == "connection_attempted" and destination.ip == "169.254.169.254"] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Instance Metadata Service (IMDS) API Request + +The Instance Metadata Service (IMDS) API provides essential instance-specific data, including configuration details and temporary credentials, to applications running on cloud instances. Adversaries exploit this by using scripts or tools to access sensitive data, potentially leading to unauthorized access. The detection rule identifies suspicious access attempts by monitoring specific processes and network activities, excluding known legitimate paths, to flag potential misuse. + +### Possible investigation steps + +- Review the process details such as process.name and process.command_line to identify the tool or script used to access the IMDS API and determine if it aligns with known malicious behavior. +- Examine the process.executable and process.working_directory fields to verify if the execution path is unusual or suspicious, especially if it originates from directories like /tmp/* or /var/tmp/*. +- Check the process.parent.entity_id and process.parent.executable to understand the parent process and its legitimacy, which might provide context on how the suspicious process was initiated. +- Investigate the network event details, particularly the destination.ip field, to confirm if there was an attempted connection to the IMDS API endpoint at 169.254.169.254. +- Correlate the host.id with other security events or logs to identify any additional suspicious activities or patterns on the same host that might indicate a broader compromise. +- Assess the risk score and severity to prioritize the investigation and determine if immediate action is required to mitigate potential threats. + +### False positive analysis + +- Security and monitoring tools like Rapid7, Nessus, and Amazon SSM Agent may trigger false positives due to their legitimate access to the IMDS API. Users can exclude these by adding their working directories to the exception list. +- Automated scripts or processes running from known directories such as /opt/rumble/bin or /usr/share/ec2-instance-connect may also cause false positives. Exclude these directories or specific executables from the rule to prevent unnecessary alerts. +- System maintenance or configuration scripts that access the IMDS API for legitimate purposes might be flagged. Identify these scripts and add their paths or parent executables to the exclusion list to reduce noise. +- Regular network monitoring tools that attempt connections to the IMDS IP address for health checks or status updates can be excluded by specifying their process names or executable paths in the exception criteria. + +### Response and remediation + +- Immediately isolate the affected instance from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified in the alert that are attempting to access the IMDS API, especially those using tools like curl, wget, or python. +- Revoke any temporary credentials that may have been exposed or accessed through the IMDS API to prevent unauthorized use. +- Conduct a thorough review of the instance's security groups and IAM roles to ensure that only necessary permissions are granted and that there are no overly permissive policies. +- Escalate the incident to the security operations team for further investigation and to determine if additional instances or resources are affected. +- Implement network monitoring to detect and alert on any future attempts to access the IMDS API from unauthorized processes or locations. +- Review and update the instance's security configurations and apply any necessary patches or updates to mitigate vulnerabilities that could be exploited in similar attacks.""" [[rule.threat]] diff --git a/rules/linux/defense_evasion_acl_modification_via_setfacl.toml b/rules/linux/defense_evasion_acl_modification_via_setfacl.toml index 14a99c7acf8..7cc08446c53 100644 --- a/rules/linux/defense_evasion_acl_modification_via_setfacl.toml +++ b/rules/linux/defense_evasion_acl_modification_via_setfacl.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_ maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -41,6 +41,39 @@ process.name == "setfacl" and not ( process.args == "/var/log/journal/" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Access Control List Modification via setfacl + +Access Control Lists (ACLs) in Linux enhance file permission management by allowing more granular access control. The `setfacl` command modifies these ACLs, potentially altering who can access or modify files. Adversaries may exploit `setfacl` to stealthily change permissions, evading detection and maintaining persistence. The detection rule identifies suspicious `setfacl` executions, excluding benign patterns, to flag potential misuse. + +### Possible investigation steps + +- Review the process details to confirm the execution of the setfacl command, focusing on the process.name and event.type fields to ensure the alert is valid. +- Examine the process.command_line to understand the specific ACL modifications attempted and identify any unusual or unauthorized changes. +- Investigate the user account associated with the process execution to determine if the action aligns with their typical behavior or role. +- Check the process's parent process to identify how the setfacl command was initiated and assess if it was part of a legitimate workflow or a potential compromise. +- Correlate the event with other security logs or alerts from the same host to identify any related suspicious activities or patterns that might indicate a broader attack. + +### False positive analysis + +- Routine system maintenance tasks may trigger the rule if they involve legitimate use of setfacl. To manage this, identify and document regular maintenance scripts or processes that use setfacl and create exceptions for these specific command lines. +- Backup operations that restore ACLs using setfacl can be mistaken for suspicious activity. Exclude these by adding exceptions for command lines that match known backup procedures, such as those using the --restore option. +- Automated log management tools might use setfacl to manage permissions on log directories like /var/log/journal/. To prevent false positives, exclude these specific directory paths from triggering the rule. +- Custom applications or services that require dynamic permission changes using setfacl could be flagged. Review these applications and, if deemed safe, add their specific command patterns to the exception list to avoid unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or changes. +- Review the process execution logs to identify any unauthorized users or processes that executed the `setfacl` command. +- Revert any unauthorized ACL changes by restoring the original file permissions from a known good backup or configuration. +- Conduct a thorough scan of the system for any additional signs of compromise, such as unauthorized user accounts or unexpected processes. +- Update and patch the system to address any vulnerabilities that may have been exploited to gain access. +- Implement stricter access controls and monitoring on critical systems to detect and prevent unauthorized ACL modifications in the future. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml b/rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml index 581929efea0..8a51b79be43 100644 --- a/rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml +++ b/rules/linux/defense_evasion_attempt_to_disable_auditd_service.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -66,6 +66,39 @@ process where host.os.type == "linux" and event.type == "start" and event.action ) and process.args in ("auditd", "auditd.service") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Attempt to Disable Auditd Service + +Auditd is a critical Linux service responsible for system auditing and logging, capturing security-relevant events. Adversaries may target this service to evade detection by disabling it, thus preventing the logging of their activities. The detection rule identifies suspicious processes attempting to stop or disable Auditd, such as using commands like `service stop` or `systemctl disable`, signaling potential defense evasion tactics. + +### Possible investigation steps + +- Review the process details to identify the user account associated with the suspicious command execution, focusing on the process fields such as process.name and process.args. +- Check the system logs for any preceding or subsequent suspicious activities around the time of the alert, particularly looking for other defense evasion tactics or unauthorized access attempts. +- Investigate the command history of the user identified to determine if there are any other unauthorized or suspicious commands executed. +- Verify the current status of the Auditd service on the affected host to ensure it is running and properly configured. +- Correlate the alert with any other security events or alerts from the same host or user to identify potential patterns or broader attack campaigns. + +### False positive analysis + +- System administrators may intentionally stop or disable the Auditd service during maintenance or troubleshooting. To handle this, create exceptions for known maintenance windows or specific administrator accounts. +- Automated scripts or configuration management tools might stop or disable Auditd as part of routine system updates or deployments. Identify these scripts and whitelist their activities to prevent false alerts. +- Some Linux distributions or custom setups might have alternative methods for managing services that could trigger this rule. Review and adjust the detection criteria to align with the specific service management practices of your environment. +- In environments where Auditd is not used or is replaced by another logging service, the rule might trigger unnecessarily. Consider disabling the rule or adjusting its scope in such cases. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity and potential lateral movement by the adversary. +- Terminate any suspicious processes identified in the alert that are attempting to disable the Auditd service to stop the adversary's actions. +- Re-enable and restart the Auditd service on the affected system to ensure that auditing and logging are resumed, capturing any further suspicious activities. +- Conduct a thorough review of the system logs and audit records to identify any unauthorized changes or additional indicators of compromise that may have occurred prior to the alert. +- Apply any necessary security patches or updates to the affected system to address vulnerabilities that may have been exploited by the adversary. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. +- Implement enhanced monitoring and alerting for similar activities across the network to detect and respond to future attempts to disable critical security services.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/defense_evasion_attempt_to_disable_iptables_or_firewall.toml b/rules/linux/defense_evasion_attempt_to_disable_iptables_or_firewall.toml index 3d423f932de..df8a5967c54 100644 --- a/rules/linux/defense_evasion_attempt_to_disable_iptables_or_firewall.toml +++ b/rules/linux/defense_evasion_attempt_to_disable_iptables_or_firewall.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -77,6 +77,41 @@ process where host.os.type == "linux" and event.type == "start" and event.action ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Attempt to Disable IPTables or Firewall + +Firewalls like IPTables on Linux systems are crucial for controlling network traffic and protecting against unauthorized access. Adversaries may attempt to disable these firewalls to bypass security measures and facilitate malicious activities. The detection rule identifies suspicious processes that attempt to disable or stop firewall services, such as using commands to flush IPTables rules or halt firewall services, indicating potential defense evasion tactics. + +### Possible investigation steps + +- Review the process details, including process.name and process.args, to confirm if the command was intended to disable or stop firewall services. +- Check the process.parent.args to understand the context in which the suspicious process was executed, especially if it was triggered by a parent process with arguments like "force-stop". +- Investigate the user account associated with the process execution to determine if it was an authorized user or potentially compromised. +- Examine the host's recent activity logs for any other suspicious behavior or anomalies around the time of the alert, focusing on event.type "start" and event.action "exec" or "exec_event". +- Assess the network traffic logs to identify any unusual inbound or outbound connections that might have occurred after the firewall was disabled or stopped. +- Correlate this event with other alerts or incidents involving the same host or user to identify potential patterns or coordinated attack attempts. + +### False positive analysis + +- Routine system maintenance or updates may trigger the rule when legitimate processes like systemctl or service are used to stop or restart firewall services. To manage this, create exceptions for known maintenance scripts or scheduled tasks that perform these actions. +- Network troubleshooting activities often involve temporarily disabling firewalls to diagnose connectivity issues. Users can exclude specific user accounts or IP addresses associated with network administrators from triggering the rule during these activities. +- Automated deployment scripts that configure or reconfigure firewall settings might match the rule's criteria. Identify and whitelist these scripts by their process names or execution paths to prevent false positives. +- Security software updates or installations may require temporary firewall adjustments, which could be flagged by the rule. Consider excluding processes associated with trusted security software vendors during update windows. +- Development or testing environments often have different security requirements, leading to frequent firewall changes. Implement environment-specific exceptions to avoid false positives in these contexts. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or potential lateral movement by the adversary. +- Terminate any suspicious processes identified in the alert, such as those attempting to disable or stop firewall services, to halt ongoing malicious activities. +- Review and restore the firewall configurations to their last known good state to ensure that network traffic is properly controlled and unauthorized access is blocked. +- Conduct a thorough examination of the affected system for any signs of compromise or additional malicious activity, focusing on logs and system changes around the time of the alert. +- Escalate the incident to the security operations team for further analysis and to determine if the threat is part of a larger attack campaign. +- Implement additional monitoring and alerting for similar activities across the network to detect and respond to future attempts to disable firewall services promptly. +- Review and update firewall policies and configurations to enhance security measures and prevent similar defense evasion tactics in the future.""" [[rule.threat]] diff --git a/rules/linux/defense_evasion_attempt_to_disable_syslog_service.toml b/rules/linux/defense_evasion_attempt_to_disable_syslog_service.toml index 11b15107458..afa53a4a986 100644 --- a/rules/linux/defense_evasion_attempt_to_disable_syslog_service.toml +++ b/rules/linux/defense_evasion_attempt_to_disable_syslog_service.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -78,6 +78,40 @@ process where host.os.type == "linux" and event.action in ("exec", "exec_event", (process.name == "systemctl" and process.args in ("disable", "stop", "kill")) ) and process.args in ("syslog", "rsyslog", "syslog-ng", "syslog.service", "rsyslog.service", "syslog-ng.service") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Attempt to Disable Syslog Service + +Syslog is a critical component in Linux environments, responsible for logging system events and activities. Adversaries may target syslog to disable logging, thereby evading detection and obscuring their malicious actions. The detection rule identifies attempts to stop or disable syslog services by monitoring specific process actions and arguments, flagging suspicious commands that could indicate an attempt to impair logging defenses. + +### Possible investigation steps + +- Review the process details to identify the user account associated with the command execution, focusing on the process.name and process.args fields to determine if the action was legitimate or suspicious. +- Check the system's recent login history and user activity to identify any unauthorized access attempts or anomalies around the time the syslog service was targeted. +- Investigate the parent process of the flagged command to understand the context of its execution and determine if it was initiated by a legitimate application or script. +- Examine other logs and alerts from the same host around the time of the event to identify any correlated suspicious activities or patterns that might indicate a broader attack. +- Assess the system for any signs of compromise, such as unexpected changes in configuration files, unauthorized software installations, or unusual network connections, to determine if the attempt to disable syslog is part of a larger attack. + +### False positive analysis + +- Routine maintenance activities may trigger this rule, such as scheduled service restarts or system updates. To manage this, create exceptions for known maintenance windows or specific administrative accounts performing these tasks. +- Automated scripts or configuration management tools like Ansible or Puppet might stop or disable syslog services as part of their operations. Identify these scripts and whitelist their execution paths or associated user accounts. +- Testing environments often simulate service disruptions, including syslog, for resilience testing. Exclude these environments from the rule or adjust the rule to ignore specific test-related processes. +- Some legitimate software installations or updates may require stopping syslog services temporarily. Monitor installation logs and exclude these processes if they are verified as non-threatening. +- In environments with multiple syslog implementations, ensure that the rule is not overly broad by refining the process arguments to match only the specific syslog services in use. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity and potential lateral movement by the adversary. +- Terminate any suspicious processes identified in the alert, specifically those attempting to stop or disable syslog services, to restore normal logging functionality. +- Restart the syslog service on the affected system to ensure that logging is re-enabled and operational, using commands like `systemctl start syslog` or `service syslog start`. +- Conduct a thorough review of recent logs, if available, to identify any additional suspicious activities or indicators of compromise that may have occurred prior to the syslog service being disabled. +- Escalate the incident to the security operations team for further investigation and to determine if the attack is part of a larger campaign or if other systems are affected. +- Implement additional monitoring on the affected system and similar systems to detect any further attempts to disable logging services, using enhanced logging and alerting mechanisms. +- Review and update access controls and permissions to ensure that only authorized personnel have the ability to modify or stop critical services like syslog, reducing the risk of future incidents.""" [[rule.threat]] diff --git a/rules/linux/defense_evasion_base16_or_base32_encoding_or_decoding_activity.toml b/rules/linux/defense_evasion_base16_or_base32_encoding_or_decoding_activity.toml index aa3acf071d1..22399510f46 100644 --- a/rules/linux/defense_evasion_base16_or_base32_encoding_or_decoding_activity.toml +++ b/rules/linux/defense_evasion_base16_or_base32_encoding_or_decoding_activity.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_ maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -80,6 +80,41 @@ process where host.os.type == "linux" and event.type == "start" and process.name in ("base16", "base32", "base32plain", "base32hex") and not process.args in ("--help", "--version") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Base16 or Base32 Encoding/Decoding Activity + +Base16 and Base32 are encoding schemes used to convert binary data into text, facilitating data transmission and storage. Adversaries exploit these encodings to obfuscate malicious payloads, evading detection by security systems. The detection rule identifies suspicious encoding/decoding activities on Linux systems by monitoring specific processes and actions, excluding benign uses like help or version checks. + +### Possible investigation steps + +- Review the process name and arguments to confirm if the activity is related to encoding/decoding using base16 or base32, ensuring it is not a benign use case like help or version checks. +- Examine the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Check the parent process of the encoding/decoding activity to identify if it was initiated by a legitimate application or a potentially malicious script or program. +- Investigate the timing and frequency of the encoding/decoding events to assess if they coincide with other suspicious activities or known attack patterns. +- Correlate the event with network activity logs to see if there is any data exfiltration attempt or communication with known malicious IP addresses or domains. +- Look into any recent changes or anomalies in the system that might indicate a compromise, such as unauthorized file modifications or new user accounts. + +### False positive analysis + +- Routine administrative tasks may trigger the rule if administrators use base16 or base32 commands for legitimate data encoding or decoding. To manage this, create exceptions for specific user accounts or scripts known to perform these tasks regularly. +- Automated backup or data transfer processes might use base16 or base32 encoding as part of their operations. Identify these processes and exclude them by specifying their unique process arguments or execution paths. +- Development and testing environments often involve encoding and decoding operations for debugging or data manipulation. Exclude these environments by filtering based on hostnames or IP addresses associated with non-production systems. +- Security tools or scripts that perform regular encoding checks for data integrity or compliance purposes can also trigger false positives. Whitelist these tools by their process names or execution contexts to prevent unnecessary alerts. +- Educational or research activities involving encoding techniques may inadvertently match the rule criteria. Consider excluding known educational user groups or specific research project identifiers to reduce false positives. + +### Response and remediation + +- Isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the adversary. +- Terminate any suspicious processes identified by the detection rule, specifically those involving base16 or base32 encoding/decoding without benign arguments. +- Conduct a thorough review of recent system logs and process execution history to identify any additional suspicious activities or related processes. +- Remove any malicious files or payloads that have been identified as part of the encoding/decoding activity. +- Restore any affected files or systems from known good backups to ensure system integrity and data accuracy. +- Update and patch the affected system to close any vulnerabilities that may have been exploited by the adversary. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/linux/defense_evasion_binary_copied_to_suspicious_directory.toml b/rules/linux/defense_evasion_binary_copied_to_suspicious_directory.toml index b2a6a079cf5..be0c8087b9d 100644 --- a/rules/linux/defense_evasion_binary_copied_to_suspicious_directory.toml +++ b/rules/linux/defense_evasion_binary_copied_to_suspicious_directory.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/29" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -95,6 +95,40 @@ file.Ext.original.path : ( (process.name == "perl" and file.name : "e2scrub_all.tmp*") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 System Binary Moved or Copied + +System binaries are essential executables in Linux environments, crucial for system operations. Adversaries may move or copy these binaries to alternate locations to evade detection, often renaming them to blend in with legitimate processes. The detection rule identifies unusual movements or copies of these binaries, excluding common system processes and paths, to flag potential malicious activity. This helps in identifying attempts at masquerading, a tactic used to bypass security measures. + +### Possible investigation steps + +- Review the file path and name in the alert to determine if the binary was moved or copied to a suspicious or unusual location, which could indicate an attempt to masquerade. +- Examine the process name and executable path that triggered the alert to identify if it is associated with known legitimate processes or if it appears suspicious or unexpected. +- Check the user account associated with the process to determine if the action was performed by a privileged or unauthorized user, which could suggest malicious intent. +- Investigate the historical activity of the process and user involved to identify any patterns or previous suspicious behavior that might correlate with the current alert. +- Correlate the alert with other security events or logs from the same timeframe to identify any related activities or anomalies that could provide additional context or evidence of malicious activity. + +### False positive analysis + +- System updates and package installations often involve legitimate movement or copying of binaries. Exclude processes like dpkg, rpm, and apt-get from triggering alerts by adding them to the exception list. +- Development and testing environments may frequently rename or move binaries for testing purposes. Consider excluding paths like /tmp or /dev/fd from monitoring if they are commonly used for non-malicious activities. +- Automated scripts or configuration management tools such as Puppet or Chef may move binaries as part of their normal operations. Add these tools to the exception list to prevent unnecessary alerts. +- Temporary files created during software installations or updates, such as those with extensions like .tmp or .dpkg-new, can trigger false positives. Exclude these extensions from monitoring to reduce noise. +- Custom scripts or applications that mimic system processes for legitimate reasons might be flagged. Review and whitelist these specific scripts or applications if they are verified as non-threatening. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified in the alert that are associated with the unauthorized movement or copying of system binaries. +- Restore any altered or moved system binaries to their original locations and verify their integrity using known good backups or checksums. +- Conduct a thorough review of system logs and the alert details to identify any additional indicators of compromise or related malicious activity. +- 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 on the affected system and similar environments to detect any recurrence of the activity, focusing on the specific paths and processes identified in the alert. +- Review and update access controls and permissions to ensure that only authorized users and processes can modify or move system binaries, reducing the risk of similar incidents in the future.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/defense_evasion_chattr_immutable_file.toml b/rules/linux/defense_evasion_chattr_immutable_file.toml index 6d5ba1837fd..cf939f21519 100644 --- a/rules/linux/defense_evasion_chattr_immutable_file.toml +++ b/rules/linux/defense_evasion_chattr_immutable_file.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/01/06" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -84,6 +84,40 @@ process.executable : "/usr/bin/chattr" and process.args : ("-*i*", "+*i*") and n ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 made Immutable by Chattr + +The `chattr` command in Linux is used to change file attributes, including making files immutable, which prevents modifications or deletions. Adversaries exploit this to secure malicious files or altered system files against tampering, aiding persistence. The detection rule identifies suspicious use of `chattr` by monitoring process executions, filtering out benign parent processes, and focusing on those altering immutability attributes, thus highlighting potential misuse. + +### Possible investigation steps + +- Review the process execution details to confirm the use of the chattr command with arguments altering immutability, specifically looking for "+i" or "-i" in process.args. +- Identify the file(s) targeted by the chattr command to determine if they are critical system files or files commonly targeted by threat actors, such as .ssh or /etc/passwd. +- Investigate the parent process of the chattr execution by examining process.parent.executable and process.parent.name to determine if it is a known benign process or potentially malicious. +- Check the user context under which the chattr command was executed to assess if it aligns with expected administrative activity or if it indicates unauthorized access. +- Correlate the event with other security alerts or logs to identify any related suspicious activities, such as unauthorized access attempts or changes to other system files. +- Evaluate the risk and impact of the immutable file(s) on system operations and security posture, considering the potential for persistence or defense evasion by threat actors. + +### False positive analysis + +- System processes like systemd and cf-agent may invoke chattr for legitimate reasons, such as system maintenance or configuration management. To handle these, exclude these processes by adding them to the exception list in the detection rule. +- Scheduled tasks or scripts that use chattr to manage file attributes for security or operational purposes can trigger false positives. Identify these tasks and exclude their parent processes from the rule. +- Administrative actions performed by authorized users, such as securing configuration files, might be flagged. Regularly review and update the list of known benign parent processes to prevent unnecessary alerts. +- Security tools or agents that modify file attributes as part of their protection mechanisms can cause false positives. Ensure these tools are recognized and excluded by their executable paths or parent process names. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Identify and terminate any malicious processes associated with the `chattr` command to stop further unauthorized file modifications. +- Restore the affected files from a known good backup, ensuring that any immutable attributes set by the attacker are removed. +- Conduct a thorough review of user accounts and permissions on the affected system to ensure no unauthorized access or privilege escalation has occurred. +- Implement file integrity monitoring to detect unauthorized changes to critical system files, enhancing detection capabilities for similar threats. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised. +- Review and update security policies and configurations to prevent unauthorized use of the `chattr` command, such as restricting its execution to trusted administrators only.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/defense_evasion_clear_kernel_ring_buffer.toml b/rules/linux/defense_evasion_clear_kernel_ring_buffer.toml index 92f07b4a59a..5a92e1e3792 100644 --- a/rules/linux/defense_evasion_clear_kernel_ring_buffer.toml +++ b/rules/linux/defense_evasion_clear_kernel_ring_buffer.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_ maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -63,6 +63,39 @@ query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and process.name == "dmesg" and process.args == "-c" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Attempt to Clear Kernel Ring Buffer + +The kernel ring buffer logs system messages, crucial for diagnosing issues. Adversaries may clear these logs using the `dmesg -c` command to hide traces of malicious activities, such as installing unauthorized kernel modules. The detection rule identifies this behavior by monitoring the execution of `dmesg` with specific arguments, flagging potential evasion attempts for further investigation. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of the `dmesg -c` command, focusing on the process name and arguments to ensure the alert is valid. +- Investigate the user account associated with the execution of the `dmesg -c` command to determine if it is a known and authorized user or potentially compromised. +- Check for any recent installations or modifications of Linux kernel modules (LKMs) on the host to identify unauthorized changes that may coincide with the log clearing attempt. +- Examine other system logs and security alerts around the same timeframe to identify any suspicious activities or patterns that may indicate a broader attack or compromise. +- Assess the host's network activity for any unusual outbound connections or data exfiltration attempts that could suggest further malicious intent. + +### False positive analysis + +- Routine system maintenance activities may trigger the rule if administrators use the dmesg -c command to clear logs for legitimate purposes. To handle this, create exceptions for known maintenance scripts or processes that regularly execute this command. +- Automated scripts or monitoring tools that include dmesg -c as part of their log management routine can cause false positives. Identify these scripts and exclude them from the rule by specifying their process IDs or user accounts. +- Development and testing environments where kernel modules are frequently installed and removed might generate alerts. Consider excluding these environments from the rule or adjusting the risk score to reflect the lower threat level in these contexts. +- System administrators may use dmesg -c during troubleshooting to clear logs and view new messages. Document these activities and create exceptions for specific user accounts or roles that perform this task regularly. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement. +- Conduct a thorough review of the system to identify any unauthorized kernel modules or other suspicious changes, and remove them if found. +- Restore the system from a known good backup if unauthorized changes are detected and cannot be easily reversed. +- Review and update access controls and permissions to ensure that only authorized users have the ability to execute commands like `dmesg -c`. +- Implement enhanced monitoring and logging for the affected system to detect any future attempts to clear the kernel ring buffer or similar evasion tactics. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Conduct a post-incident review to identify gaps in detection and response, and update security policies and procedures to prevent recurrence.""" [[rule.threat]] diff --git a/rules/linux/defense_evasion_creation_of_hidden_files_directories.toml b/rules/linux/defense_evasion_creation_of_hidden_files_directories.toml index ca6700c78de..339bbe54094 100644 --- a/rules/linux/defense_evasion_creation_of_hidden_files_directories.toml +++ b/rules/linux/defense_evasion_creation_of_hidden_files_directories.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "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/01/06" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -36,6 +36,41 @@ type = "eql" query = ''' file where host.os.type == "linux" and event.type == "creation" and process.name == "chflags" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Hidden Files and Directories via Hidden Flag + +In Unix-like systems, the 'hidden' flag can be set on files to conceal them from standard directory listings, a feature often exploited by adversaries to obscure malicious files. Attackers may use commands like `chflags` to apply this flag, making detection challenging. The detection rule targets file creation events involving `chflags`, helping identify potential misuse by monitoring for suspicious activity on Linux and macOS systems. + +### Possible investigation steps + +- Review the alert details to confirm the host operating system is Linux, as specified by the query field `host.os.type == "linux"`. +- Examine the process execution details to verify that the `chflags` command was used, as indicated by `process.name == "chflags"`. +- Investigate the file creation event to identify the specific file or directory that had the 'hidden' flag applied, focusing on the `event.type == "creation"` field. +- Check the user account associated with the `chflags` command execution to determine if it aligns with expected user behavior or if it might indicate unauthorized access. +- Analyze recent system logs and user activity on the affected host to identify any other suspicious behavior or anomalies that could suggest malicious intent. +- Correlate this event with other alerts or indicators of compromise on the same host to assess if this is part of a larger attack pattern or isolated incident. + +### False positive analysis + +- System maintenance scripts may use the chflags command to manage file visibility for legitimate purposes. Review scheduled tasks and scripts to identify benign uses and create exceptions for these processes. +- Backup and recovery operations might employ the hidden flag to protect critical files from accidental deletion. Verify backup software configurations and exclude these operations from triggering alerts. +- Development environments could use hidden files to manage version control or configuration settings. Collaborate with development teams to understand their workflows and whitelist known development-related activities. +- Security tools and utilities may use the hidden flag as part of their normal operation to protect sensitive files. Identify these tools and add them to an exception list to prevent unnecessary alerts. +- User customization scripts might apply the hidden flag to personalize the user environment. Engage with users to document these customizations and exclude them from detection rules. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement. +- Terminate any suspicious processes associated with `chflags` to halt any ongoing attempts to hide files. +- Conduct a thorough review of recently created files and directories on the affected system to identify and assess any hidden files for malicious content. +- Restore any critical files that may have been hidden or altered from known good backups to ensure system integrity. +- Implement file integrity monitoring to detect unauthorized changes to file attributes, including the hidden flag, on critical systems. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Update and enhance endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/defense_evasion_directory_creation_in_bin.toml b/rules/linux/defense_evasion_directory_creation_in_bin.toml index a38e54d6203..3721241207a 100644 --- a/rules/linux/defense_evasion_directory_creation_in_bin.toml +++ b/rules/linux/defense_evasion_directory_creation_in_bin.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -65,6 +65,40 @@ process where host.os.type == "linux" and event.type == "start" and process.args like ("/bin/*", "/usr/bin/*", "/usr/local/bin/*", "/sbin/*", "/usr/sbin/*", "/usr/local/sbin/*") and not process.args in ("/bin/mkdir", "/usr/bin/mkdir", "/usr/local/bin/mkdir") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Directory Creation in /bin directory + +The /bin directory is crucial for Linux systems, housing essential binaries for system operations. Adversaries may exploit this by creating directories here to conceal malicious files, leveraging the directory's trusted status. The detection rule identifies suspicious directory creation by monitoring 'mkdir' executions in critical binary paths, excluding legitimate system operations, thus flagging potential threats for further investigation. + +### Possible investigation steps + +- Review the process details to confirm the execution of 'mkdir' in the specified critical binary paths such as /bin, /usr/bin, /usr/local/bin, /sbin, /usr/sbin, and /usr/local/sbin. +- Check the parent process of the 'mkdir' command to determine if it was initiated by a legitimate system process or a potentially malicious one. +- Investigate the user account associated with the 'mkdir' process to assess if it has the necessary permissions and if the activity aligns with the user's typical behavior. +- Examine the system logs around the time of the directory creation for any other suspicious activities or anomalies that might indicate a broader attack. +- Verify if any files or executables have been placed in the newly created directory and assess their legitimacy and potential threat level. +- Cross-reference the event with threat intelligence sources to identify if the activity matches any known malicious patterns or indicators of compromise. + +### False positive analysis + +- System updates or package installations may trigger directory creation in the /bin directory as part of legitimate operations. Users can mitigate this by creating exceptions for known package management processes like apt, yum, or rpm. +- Custom scripts or administrative tasks that require creating directories in the /bin directory for temporary storage or testing purposes can also lead to false positives. Users should document and exclude these specific scripts or tasks from the detection rule. +- Automated deployment tools or configuration management systems such as Ansible, Puppet, or Chef might create directories in the /bin directory as part of their setup routines. Users should identify these tools and add them to the exclusion list to prevent unnecessary alerts. +- Development or testing environments where developers have permissions to create directories in the /bin directory for application testing can result in false positives. Users should differentiate between production and non-production environments and apply the rule accordingly. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the adversary. +- Terminate any suspicious processes related to the directory creation in the /bin directory to halt any ongoing malicious activity. +- Conduct a thorough review of the newly created directories and files within the /bin directory to identify and remove any malicious binaries or scripts. +- Restore any altered or deleted legitimate binaries from a known good backup to ensure system integrity and functionality. +- Implement file integrity monitoring on critical system directories, including /bin, to detect unauthorized changes in real-time. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised. +- Review and update access controls and permissions for the /bin directory to restrict unauthorized directory creation and enhance security posture.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/defense_evasion_disable_apparmor_attempt.toml b/rules/linux/defense_evasion_disable_apparmor_attempt.toml index 3c61939ffe3..a5ca2b34d3e 100644 --- a/rules/linux/defense_evasion_disable_apparmor_attempt.toml +++ b/rules/linux/defense_evasion_disable_apparmor_attempt.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_ maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -69,6 +69,41 @@ process where host.os.type == "linux" and event.type == "start" and (process.name == "ln" and process.args : "/etc/apparmor.d/*" and process.args == "/etc/apparmor.d/disable/") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Disabling of AppArmor + +AppArmor is a Linux security module that enforces strict access controls, limiting what applications can do. Adversaries may attempt to disable AppArmor to evade detection and freely execute malicious activities. The detection rule identifies suspicious processes attempting to stop or disable AppArmor services, such as using commands like `systemctl` or `service` with specific arguments, indicating potential tampering with security defenses. + +### Possible investigation steps + +- Review the process details to confirm the command used, focusing on the process name and arguments, such as "systemctl", "service", "chkconfig", or "ln" with arguments related to AppArmor. +- Check the user account associated with the process execution to determine if it is a legitimate user or potentially compromised. +- Investigate the host's recent activity logs to identify any other suspicious behavior or anomalies around the time the alert was triggered. +- Examine the system's AppArmor status to verify if it has been disabled or tampered with, and assess any potential impact on system security. +- Correlate this event with other alerts or logs from the same host or user to identify patterns or a broader attack campaign. +- Consult threat intelligence sources to determine if there are known adversaries or malware that commonly attempt to disable AppArmor in similar ways. + +### False positive analysis + +- Routine system maintenance activities may trigger this rule, such as administrators stopping AppArmor for legitimate updates or configuration changes. To manage this, create exceptions for known maintenance windows or specific administrator accounts. +- Automated scripts or configuration management tools like Ansible or Puppet might stop or disable AppArmor as part of their deployment processes. Identify these scripts and whitelist their execution paths or associated user accounts. +- Testing environments where security modules are frequently enabled and disabled for testing purposes can generate false positives. Consider excluding these environments from the rule or adjusting the rule's sensitivity for these specific hosts. +- Some legitimate software installations may require temporarily disabling AppArmor. Monitor installation logs and correlate them with the rule triggers to identify and exclude these benign activities. +- In environments where AppArmor is not actively used or managed, the rule may trigger on default system actions. Evaluate the necessity of monitoring AppArmor in such environments and adjust the rule scope accordingly. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, specifically those attempting to disable AppArmor, to halt any ongoing malicious activities. +- Conduct a thorough review of system logs and process execution history to identify any additional indicators of compromise or related malicious activities. +- Restore AppArmor to its intended operational state by re-enabling the service and ensuring all security policies are correctly applied. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected. +- Implement enhanced monitoring on the affected system and similar environments to detect any future attempts to disable AppArmor or other security controls. +- Review and update access controls and permissions to ensure that only authorized personnel can modify security settings, reducing the risk of similar incidents.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/defense_evasion_disable_selinux_attempt.toml b/rules/linux/defense_evasion_disable_selinux_attempt.toml index 491a0e169ca..543966a140a 100644 --- a/rules/linux/defense_evasion_disable_selinux_attempt.toml +++ b/rules/linux/defense_evasion_disable_selinux_attempt.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_ maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -77,6 +77,40 @@ process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and process.name == "setenforce" and process.args == "0" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Disabling of SELinux + +SELinux is a critical security feature in Linux environments, enforcing access control policies to protect against unauthorized access. Adversaries may attempt to disable SELinux to evade detection and carry out malicious activities undetected. The detection rule identifies such attempts by monitoring for the execution of the 'setenforce 0' command, which switches SELinux to permissive mode, effectively disabling its enforcement capabilities. This rule leverages process monitoring to alert security teams of potential defense evasion tactics. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of the 'setenforce 0' command, ensuring that the process name is 'setenforce' and the argument is '0'. +- Check the user account associated with the process execution to determine if it is a legitimate administrative user or a potential compromised account. +- Investigate the timeline of events leading up to and following the execution of the 'setenforce 0' command to identify any related suspicious activities or processes. +- Examine system logs and audit logs for any other unusual or unauthorized changes to SELinux settings or other security configurations. +- Assess the system for any signs of compromise or malicious activity, such as unexpected network connections, file modifications, or the presence of known malware indicators. +- Verify the current SELinux status and configuration to ensure it has been restored to enforcing mode if it was indeed set to permissive mode. + +### False positive analysis + +- System administrators may execute the 'setenforce 0' command during routine maintenance or troubleshooting, leading to false positives. To manage this, create exceptions for known maintenance windows or specific administrator accounts. +- Some automated scripts or configuration management tools might temporarily set SELinux to permissive mode for deployment purposes. Identify these scripts and exclude their execution context from triggering alerts. +- Development environments might require SELinux to be set to permissive mode for testing purposes. Consider excluding specific development hosts or environments from the rule to prevent unnecessary alerts. +- In certain cases, SELinux might be disabled as part of a controlled security audit or penetration test. Coordinate with security teams to whitelist these activities during the audit period. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Verify the current SELinux status on the affected system using the command `sestatus` to confirm if it has been switched to permissive mode. +- If SELinux is in permissive mode, re-enable it by executing `setenforce 1` and ensure that the SELinux policy is correctly enforced. +- Conduct a thorough review of system logs and process execution history to identify any unauthorized changes or suspicious activities that occurred while SELinux was disabled. +- Scan the affected system for malware or unauthorized software installations using a trusted antivirus or endpoint detection and response (EDR) tool. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Implement additional monitoring and alerting for similar SELinux-related events to enhance detection capabilities and prevent recurrence.""" [[rule.threat]] diff --git a/rules/linux/defense_evasion_doas_configuration_creation_or_rename.toml b/rules/linux/defense_evasion_doas_configuration_creation_or_rename.toml index 1b325e4f75f..05fce5c3b7d 100644 --- a/rules/linux/defense_evasion_doas_configuration_creation_or_rename.toml +++ b/rules/linux/defense_evasion_doas_configuration_creation_or_rename.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/01/06" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -61,6 +61,40 @@ type = "eql" query = ''' file where host.os.type == "linux" and event.type != "deletion" and file.path == "/etc/doas.conf" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Defense Evasion via Doas + +Doas is a command-line utility on Linux systems that allows users to execute commands as another user, typically with elevated privileges. Adversaries may exploit this by altering the Doas configuration file to gain unauthorized access or escalate privileges, bypassing security measures. The detection rule identifies suspicious activities by monitoring changes to the Doas configuration file, signaling potential misuse aimed at evading defenses. + +### Possible investigation steps + +- Review the alert details to confirm the file path involved is "/etc/doas.conf" and the event type is not "deletion", as specified in the query. +- Check the timestamp of the alert to determine when the configuration file was created or modified, and correlate this with any known scheduled changes or maintenance activities. +- Investigate the user account associated with the event to determine if they have legitimate reasons to modify the Doas configuration file, and verify their access permissions. +- Examine system logs and command history around the time of the alert to identify any suspicious activities or commands executed by the user. +- Assess the current Doas configuration file for unauthorized changes or entries that could indicate privilege escalation attempts. +- Cross-reference the alert with other security events or alerts from the same host to identify potential patterns or related activities that could suggest a broader attack. + +### False positive analysis + +- Routine administrative updates to the Doas configuration file can trigger alerts. To manage this, create exceptions for known maintenance windows or specific user accounts responsible for legitimate updates. +- Automated configuration management tools may modify the Doas configuration file as part of their normal operation. Identify these tools and exclude their activities from triggering alerts by specifying their process names or user accounts. +- System backups or restoration processes might involve creating or renaming the Doas configuration file. Exclude these processes by identifying the backup software and adding it to the exception list. +- Development or testing environments where frequent changes to the Doas configuration file are expected can generate false positives. Consider excluding these environments from monitoring or adjusting the rule to account for their unique activity patterns. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Review and revert any unauthorized changes to the Doas configuration file located at /etc/doas.conf to its last known good state. +- Conduct a thorough audit of user accounts and permissions on the affected system to identify and remove any unauthorized accounts or privilege escalations. +- Implement additional monitoring on the affected system to detect any further attempts to modify the Doas configuration file or other critical system files. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems. +- Apply patches and updates to the affected system to address any vulnerabilities that may have been exploited by the adversary. +- Review and enhance access controls and authentication mechanisms to prevent unauthorized privilege escalation attempts in the future.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/defense_evasion_dynamic_linker_file_creation.toml b/rules/linux/defense_evasion_dynamic_linker_file_creation.toml index 2e7b12d950d..a0b6027a4e1 100644 --- a/rules/linux/defense_evasion_dynamic_linker_file_creation.toml +++ b/rules/linux/defense_evasion_dynamic_linker_file_creation.toml @@ -2,7 +2,7 @@ creation_date = "2024/08/08" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -80,6 +80,40 @@ not ( (process.name == "perl" and file.name : "e2scrub_all.tmp*") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Dynamic Linker Creation or Modification + +The dynamic linker in Linux systems is crucial for loading shared libraries needed by programs at runtime. Adversaries may exploit this by altering linker configuration files to hijack program execution, enabling persistence or evasion. The detection rule identifies suspicious creation or renaming of these files, excluding benign processes and extensions, to flag potential threats. + +### Possible investigation steps + +- Review the file path involved in the alert to determine if it matches any of the critical dynamic linker configuration files such as /etc/ld.so.preload, /etc/ld.so.conf.d/*, or /etc/ld.so.conf. +- Identify the process that triggered the alert by examining the process.executable field and verify if it is listed as a benign process in the exclusion list. If not, investigate the legitimacy of the process. +- Check the file extension and file.Ext.original.extension fields to ensure the file is not a temporary or expected system file, such as those with extensions like swp, swpx, swx, or dpkg-new. +- Investigate the process.name field to determine if the process is a known system utility like java, sed, or perl, and assess if its usage in this context is typical or suspicious. +- Gather additional context by reviewing recent system logs and other security alerts to identify any related or preceding suspicious activities that might indicate a broader attack or compromise. + +### False positive analysis + +- Package management operations can trigger false positives when legitimate package managers like dpkg, rpm, or yum modify linker configuration files. To handle this, ensure these processes are included in the exclusion list to prevent unnecessary alerts. +- System updates or software installations often involve temporary file modifications with extensions like swp or dpkg-new. Exclude these extensions to reduce false positives. +- Automated system management tools such as Puppet or Chef may modify linker files as part of their configuration management tasks. Add these tools to the exclusion list to avoid false alerts. +- Virtualization and containerization platforms like Docker or VMware may alter linker configurations during normal operations. Verify these processes and exclude them if they are part of routine system behavior. +- Custom scripts or applications that use common names like sed or perl might be flagged if they interact with linker files. Review these scripts and consider excluding them if they are verified as safe. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Review and restore the original dynamic linker configuration files from a known good backup to ensure the integrity of the system's execution flow. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious software or scripts. +- Analyze system logs and the process execution history to identify the source of the unauthorized changes and determine if any other systems may be compromised. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the organization. +- Implement additional monitoring on the affected system and similar systems to detect any future attempts to modify dynamic linker configuration files. +- Review and update access controls and permissions to ensure that only authorized personnel have the ability to modify critical system files, reducing the risk of similar incidents in the future.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/defense_evasion_esxi_suspicious_timestomp_touch.toml b/rules/linux/defense_evasion_esxi_suspicious_timestomp_touch.toml index 6bf55b5f216..81ee59285f9 100644 --- a/rules/linux/defense_evasion_esxi_suspicious_timestomp_touch.toml +++ b/rules/linux/defense_evasion_esxi_suspicious_timestomp_touch.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_ maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -70,6 +70,41 @@ process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and process.name == "touch" and process.args == "-r" and process.args : ("/etc/vmware/*", "/usr/lib/vmware/*", "/vmfs/*") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 ESXI Timestomping using Touch Command + +VMware ESXi is a hypervisor used to manage virtual machines. Adversaries may exploit the 'touch' command with the "-r" flag to alter file timestamps, masking unauthorized changes in VM-related directories. The detection rule identifies such activities by monitoring the execution of 'touch' with specific arguments, signaling potential timestamp tampering in critical VMware paths. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of the 'touch' command with the "-r" flag and verify the specific VM-related paths involved, such as "/etc/vmware/", "/usr/lib/vmware/", or "/vmfs/*". +- Check the user account associated with the process execution to determine if it is a legitimate user or potentially compromised account. +- Investigate the parent process of the 'touch' command to understand the context of its execution and identify any related suspicious activities. +- Examine recent changes to the files in the specified paths to identify any unauthorized modifications or anomalies. +- Correlate the event with other security alerts or logs from the same host to identify patterns or additional indicators of compromise. +- Assess the system for any signs of unauthorized access or other defense evasion techniques that may have been employed by the threat actor. + +### False positive analysis + +- Routine administrative tasks in VMware environments may trigger the rule if administrators use the touch command with the -r flag for legitimate purposes. To manage this, create exceptions for known administrative scripts or processes that regularly perform these actions. +- Automated backup or synchronization tools that update file timestamps as part of their normal operation can cause false positives. Identify these tools and exclude their processes from the rule to prevent unnecessary alerts. +- System maintenance activities, such as updates or patches, might involve timestamp modifications in VMware directories. Coordinate with IT teams to whitelist these activities during scheduled maintenance windows. +- Custom scripts developed in-house for managing VMware environments might use the touch command with the -r flag. Review these scripts and, if verified as safe, add them to an exception list to avoid false positives. +- Security tools or monitoring solutions that perform integrity checks on VMware files may inadvertently alter timestamps. Ensure these tools are recognized and excluded from the rule to maintain accurate threat detection. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or tampering with VMware-related files. +- Conduct a thorough review of the affected system's logs and processes to identify any unauthorized changes or additional malicious activities. +- Restore the original timestamps of the affected files using verified backups to ensure the integrity of the VMware-related configurations. +- Revert any unauthorized changes to the VMware environment by restoring from a known good backup or snapshot. +- Update and patch the VMware ESXi and associated software to the latest versions to mitigate any known vulnerabilities that could be exploited. +- Implement stricter access controls and monitoring on critical VMware directories to prevent unauthorized modifications in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/linux/defense_evasion_file_deletion_via_shred.toml b/rules/linux/defense_evasion_file_deletion_via_shred.toml index e942a964e63..7989ced7ec0 100644 --- a/rules/linux/defense_evasion_file_deletion_via_shred.toml +++ b/rules/linux/defense_evasion_file_deletion_via_shred.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "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/01/06" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -64,6 +64,40 @@ process where host.os.type == "linux" and event.type == "start" and process.name "-u", "--remove", "-z", "--zero" ) and not process.parent.name == "logrotate" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Deletion via Shred + +The `shred` command in Linux is used to securely delete files by overwriting them, making recovery difficult. Adversaries exploit this to erase traces of malicious activity, hindering forensic analysis. The detection rule identifies suspicious use of `shred` by monitoring its execution with specific arguments, excluding benign processes like `logrotate`, to flag potential defense evasion attempts. + +### Possible investigation steps + +- Review the process execution details to confirm the use of the `shred` command with suspicious arguments such as "-u", "--remove", "-z", or "--zero". +- Identify the user account associated with the `shred` process to determine if the activity aligns with expected behavior for that user. +- Investigate the parent process of `shred` to ensure it is not `logrotate` and assess whether the parent process is legitimate or potentially malicious. +- Examine the timeline of events leading up to and following the `shred` execution to identify any related suspicious activities or file modifications. +- Check for any other alerts or logs related to the same host or user to identify patterns or additional indicators of compromise. +- Assess the impact of the file deletion by determining which files were targeted and whether they are critical to system operations or security. + +### False positive analysis + +- Logrotate processes may trigger false positives as they use shred for legitimate log file management. Exclude logrotate as a parent process in detection rules to prevent these alerts. +- System maintenance scripts that securely delete temporary files using shred can cause false positives. Identify and whitelist these scripts to reduce unnecessary alerts. +- Backup or cleanup operations that involve shredding old data might be flagged. Review and exclude these operations if they are part of routine system management. +- User-initiated file deletions for privacy or space management can appear suspicious. Educate users on the implications of using shred and consider excluding known user actions if they are frequent and benign. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity or data exfiltration. +- Terminate any active `shred` processes that are not associated with legitimate applications like `logrotate` to halt ongoing file deletion. +- Conduct a thorough review of recent system logs and file access records to identify any additional malicious activities or files that may have been created or modified by the adversary. +- Restore any critical files that were deleted using `shred` from the most recent backup, ensuring the integrity and security of the backup source. +- 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 enhanced monitoring on the affected system and similar environments to detect any future unauthorized use of `shred` or similar file deletion tools. +- Review and update endpoint security configurations to prevent unauthorized execution of file deletion commands by non-administrative users.""" [[rule.threat]] diff --git a/rules/linux/defense_evasion_file_mod_writable_dir.toml b/rules/linux/defense_evasion_file_mod_writable_dir.toml index 7c4265bf95b..13646f48834 100644 --- a/rules/linux/defense_evasion_file_mod_writable_dir.toml +++ b/rules/linux/defense_evasion_file_mod_writable_dir.toml @@ -2,7 +2,7 @@ creation_date = "2020/04/21" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -76,6 +76,40 @@ host.os.type:linux and event.category:process and event.type:start and process.name:(chattr or chgrp or chmod or chown) and process.working_directory:(/dev/shm or /tmp or /var/tmp) and not process.parent.name:(apt-key or update-motd-updates-available or apt-get) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Permission Modification in Writable Directory + +In Linux environments, writable directories like /tmp or /var/tmp are often used for temporary file storage. Adversaries exploit these by modifying file permissions to execute malicious payloads. The detection rule identifies non-root users altering permissions in these directories using commands like chmod or chown, excluding benign processes, to flag potential threats. This helps in identifying unauthorized permission changes indicative of defense evasion tactics. + +### Possible investigation steps + +- Review the process details to identify the non-root user who executed the permission modification command (chattr, chgrp, chmod, or chown) in the specified writable directories (/dev/shm, /tmp, or /var/tmp). +- Examine the parent process of the detected command to determine if it is associated with any known malicious activity or if it deviates from typical user behavior, ensuring it is not one of the excluded benign processes (apt-key, update-motd-updates-available, apt-get). +- Investigate the specific file or directory whose permissions were altered to assess its legitimacy and check for any associated suspicious files or payloads. +- Analyze recent activities by the identified user to detect any other anomalous behavior or unauthorized access attempts that could indicate a broader compromise. +- Cross-reference the event with other security logs and alerts to identify any correlated incidents or patterns that might suggest a coordinated attack or persistent threat. + +### False positive analysis + +- System updates and maintenance scripts may trigger permission changes in writable directories. Exclude processes like apt-key, update-motd-updates-available, and apt-get to reduce noise from legitimate system activities. +- Development and testing environments often involve frequent permission changes by non-root users. Consider excluding specific user accounts or processes known to be part of regular development workflows. +- Automated backup or synchronization tools might modify file permissions as part of their operations. Identify and exclude these tools if they are verified to be non-threatening. +- Custom scripts or applications that require permission changes for functionality should be reviewed and, if deemed safe, added to an exception list to prevent false alerts. +- Regularly review and update the exclusion list to ensure it reflects current operational practices and does not inadvertently allow malicious activities. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified in the alert that are associated with unauthorized permission changes. +- Revert any unauthorized file permission changes in the writable directories to their original state to prevent execution of malicious payloads. +- Conduct a thorough scan of the affected directories (/dev/shm, /tmp, /var/tmp) for any malicious files or payloads and remove them. +- Review user accounts and permissions to ensure that only authorized users have access to modify file permissions in sensitive directories. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for file permission changes in writable directories to detect similar threats in the future.""" [[rule.threat]] diff --git a/rules/linux/defense_evasion_hex_payload_execution.toml b/rules/linux/defense_evasion_hex_payload_execution.toml index 2077dd5f76e..becce22f8b1 100644 --- a/rules/linux/defense_evasion_hex_payload_execution.toml +++ b/rules/linux/defense_evasion_hex_payload_execution.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -70,6 +70,41 @@ process where host.os.type == "linux" and event.type == "start" and (process.name like "lua*" and process.command_line like "*tonumber(cc, 16)*") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Hex Payload Execution + +Hex encoding is often used in Linux environments to obfuscate data, making it harder for security tools to detect malicious payloads. Adversaries exploit this by encoding their payloads in hex to bypass security measures. The detection rule identifies suspicious processes like `xxd`, `python`, `php`, and others that use hex-related functions, signaling potential obfuscation attempts. By monitoring these patterns, the rule helps uncover hidden threats. + +### Possible investigation steps + +- Review the process details, including the process name and command line arguments, to confirm if the execution aligns with typical hex decoding or encoding activities. +- Check the parent process of the suspicious process to understand the context of how the process was initiated and whether it was expected or part of a legitimate workflow. +- Investigate the user account associated with the process execution to determine if the activity is consistent with the user's normal behavior or if the account may have been compromised. +- Examine the network activity associated with the process to identify any potential data exfiltration or communication with known malicious IP addresses. +- Look for any related file modifications or creations around the time of the process execution to identify if the decoded payload was written to disk or executed further. +- Cross-reference the alert with other security tools or logs, such as Crowdstrike or SentinelOne, to gather additional context or corroborating evidence of malicious activity. + +### False positive analysis + +- Development and testing environments may frequently use hex encoding functions for legitimate purposes. To reduce noise, consider excluding processes running on known development servers from the rule. +- System administrators might use hex encoding tools like `xxd` for data conversion tasks. Identify and whitelist these routine administrative scripts to prevent false alerts. +- Automated scripts or applications that process data in hex format for encoding or decoding purposes can trigger this rule. Review and exclude these scripts if they are verified as non-malicious. +- Security tools or monitoring solutions themselves might use hex encoding for data analysis. Ensure these tools are recognized and excluded from triggering the rule. +- Regularly review and update the exclusion list to adapt to changes in the environment and ensure that only verified non-threatening behaviors are excluded. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of potentially malicious payloads. +- Terminate any suspicious processes identified by the detection rule, such as those involving `xxd`, `python`, `php`, `ruby`, `perl`, or `lua` with hex-related functions. +- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious payloads or remnants. +- Review and analyze system logs and process execution history to determine the scope of the compromise and identify any additional affected systems. +- Restore the system from a known good backup if malicious activity is confirmed and cannot be fully remediated. +- Implement additional monitoring on the affected system and network to detect any recurrence of similar obfuscation attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/defense_evasion_hidden_directory_creation.toml b/rules/linux/defense_evasion_hidden_directory_creation.toml index 621d5aa8d1d..8418391f3e1 100644 --- a/rules/linux/defense_evasion_hidden_directory_creation.toml +++ b/rules/linux/defense_evasion_hidden_directory_creation.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -76,6 +76,41 @@ process.name == "mkdir" and process.parent.executable like ( ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Hidden Directory Creation via Unusual Parent + +In Linux environments, hidden directories, often prefixed with a dot, are typically used for configuration files but can be exploited by attackers to conceal malicious activities. Adversaries may create these directories using unexpected parent processes in sensitive locations. The detection rule identifies such anomalies by monitoring directory creation commands executed by unusual parent executables, focusing on specific directories and excluding known benign patterns. + +### Possible investigation steps + +- Review the process.parent.executable field to identify the parent process that initiated the directory creation and assess its legitimacy based on its typical behavior and location. +- Examine the process.args field to understand the specific arguments used with the mkdir command, focusing on the directory path and any patterns that may indicate malicious intent. +- Check the process.command_line field for any unusual or suspicious command-line patterns that might suggest an attempt to evade detection. +- Investigate the context of the parent process by reviewing recent activities or logs associated with it, especially if it originates from sensitive directories like /dev/shm, /tmp, or /var/tmp. +- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or patterns that could indicate a broader attack or compromise. +- Consult threat intelligence sources or databases to determine if the parent executable or directory path has been associated with known malicious activities or threat actors. + +### False positive analysis + +- Temporary directories used by legitimate applications can trigger false positives. Exclude known benign parent executables like those in "/tmp/newroot/*" or "/run/containerd/*" to reduce noise. +- Automated build processes may create hidden directories during software compilation. Add exceptions for parent executables such as "/var/tmp/buildah*" or "/tmp/python-build.*" to prevent unnecessary alerts. +- Development tools and scripts might create hidden directories for caching or temporary storage. Consider excluding parent executables like "/tmp/pear/temp/*" or "/tmp/cliphist-wofi-img" if they are part of regular development activities. +- Ensure that the command line patterns like "mkdir -p ." or "mkdir ./*" are excluded, as these are common in scripts and do not typically indicate malicious intent. +- Regularly review and update the list of excluded patterns and parent executables to align with changes in the environment and reduce false positives effectively. + +### Response and remediation + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes associated with the unusual parent executable identified in the alert to halt potential malicious operations. +- Conduct a thorough review of the hidden directory and its contents to identify and remove any malicious files or tools. +- Restore any affected files or configurations from a known good backup to ensure system integrity. +- Implement stricter access controls and monitoring on sensitive directories to prevent unauthorized directory creation. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised. +- Update and enhance endpoint detection and response (EDR) solutions to improve detection capabilities for similar threats in the future.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/defense_evasion_hidden_file_dir_tmp.toml b/rules/linux/defense_evasion_hidden_file_dir_tmp.toml index f013e542b90..efd76398391 100644 --- a/rules/linux/defense_evasion_hidden_file_dir_tmp.toml +++ b/rules/linux/defense_evasion_hidden_file_dir_tmp.toml @@ -2,7 +2,7 @@ creation_date = "2020/04/29" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -84,6 +84,41 @@ not process.name in ( "command-not-found" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Creation of Hidden Files and Directories via CommandLine + +In Linux environments, files and directories prefixed with a dot (.) are hidden by default, a feature often exploited by adversaries to conceal malicious activities. Attackers may create hidden files in writable directories like /tmp to evade detection. The detection rule identifies suspicious processes creating such hidden files, excluding benign commands, to flag potential threats. This helps in uncovering stealthy persistence and defense evasion tactics. + +### Possible investigation steps + +- Review the process details to identify the command executed, focusing on the process.working_directory field to confirm if the hidden file was created in a common writable directory like /tmp, /var/tmp, or /dev/shm. +- Examine the process.args field to determine the specific hidden file or directory name created, and assess if it matches known malicious patterns or naming conventions. +- Check the process lineage by investigating the parent process to understand the context of how the hidden file creation was initiated and identify any potential malicious parent processes. +- Investigate the user account associated with the process to determine if it is a legitimate user or potentially compromised, and review recent activities by this user for any anomalies. +- Search for any additional hidden files or directories created around the same time or by the same process to identify further suspicious activities or artifacts. +- Correlate this event with other security alerts or logs from the same host to identify any related suspicious activities or patterns that could indicate a broader attack or compromise. + +### False positive analysis + +- System maintenance scripts may create hidden files in directories like /tmp for temporary storage. Review these scripts and consider excluding them if they are verified as non-threatening. +- Development tools and processes, such as version control systems or build scripts, might generate hidden files for configuration or state tracking. Identify these tools and add them to the exclusion list if they are part of regular operations. +- Monitoring and logging tools may use hidden files to store temporary data or logs. Verify these tools and exclude them if they are essential for system monitoring. +- User-specific applications or scripts might create hidden files for legitimate purposes. Conduct a review of user activities and exclude known benign applications to reduce noise. +- Automated backup or synchronization services could generate hidden files as part of their operation. Confirm these services and exclude them if they are part of the expected environment setup. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement. +- Terminate any suspicious processes identified by the detection rule that are creating hidden files in the specified directories. +- Remove any hidden files or directories created by unauthorized processes in the /tmp, /var/tmp, and /dev/shm directories to eliminate potential persistence mechanisms. +- Conduct a thorough review of system logs and process execution history to identify any additional indicators of compromise or related malicious activities. +- Restore any affected files or system components from a known good backup to ensure system integrity. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and alerting for similar activities to improve detection and response capabilities for future incidents.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/defense_evasion_hidden_shared_object.toml b/rules/linux/defense_evasion_hidden_shared_object.toml index 3f6201d9255..8bb847f64f2 100644 --- a/rules/linux/defense_evasion_hidden_shared_object.toml +++ b/rules/linux/defense_evasion_hidden_shared_object.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/01/06" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -78,6 +78,40 @@ query = ''' file where host.os.type == "linux" and event.type == "creation" and file.extension == "so" and file.name : ".*.so" and not process.name == "dockerd" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Creation of Hidden Shared Object File + +Shared object files (.so) are dynamic libraries used in Linux environments to provide reusable code. Adversaries may exploit the ability to hide files by prefixing them with a dot, concealing malicious .so files for persistence and evasion. The detection rule identifies the creation of such hidden files, excluding benign processes like Docker, to flag potential threats. + +### Possible investigation steps + +- Review the alert details to identify the specific hidden shared object file (.so) that was created, noting its full path and filename. +- Investigate the process that created the file by examining the process name and its parent process, excluding "dockerd" as per the query, to determine if the process is legitimate or potentially malicious. +- Check the file creation timestamp and correlate it with other system activities or logs to identify any suspicious behavior or patterns around the time of creation. +- Analyze the contents of the hidden .so file, if accessible, to determine its purpose and whether it contains any malicious code or indicators of compromise. +- Investigate the user account associated with the file creation event to assess if the account has been compromised or is involved in unauthorized activities. +- Search for any other hidden files or suspicious activities on the system that may indicate a broader compromise or persistence mechanism. + +### False positive analysis + +- Development and testing environments may frequently create hidden .so files as part of routine operations. Users can mitigate this by excluding specific directories or processes known to be part of development workflows. +- Backup or system maintenance scripts might generate hidden .so files temporarily. Identify and exclude these scripts or their associated processes to prevent false alerts. +- Some legitimate software installations or updates may create hidden .so files as part of their setup process. Users should monitor installation logs and whitelist these processes if they are verified as non-threatening. +- Custom applications or services that use hidden .so files for legitimate purposes should be documented, and their creation processes should be excluded from detection to avoid unnecessary alerts. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Terminate any suspicious processes associated with the creation of the hidden .so file, except for known benign processes like Docker. +- Remove the hidden .so file from the system to eliminate the immediate threat. Ensure that the file is securely deleted to prevent recovery. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or artifacts. +- Review system logs and process execution history to identify any unauthorized access or changes made around the time of the file creation. This can help in understanding the scope of the compromise. +- 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 enhanced monitoring and alerting for similar activities, such as the creation of hidden files, to improve detection and response times for future incidents.""" [[rule.threat]] diff --git a/rules/linux/defense_evasion_interactive_shell_from_system_user.toml b/rules/linux/defense_evasion_interactive_shell_from_system_user.toml index caeffc29de3..43691835f98 100644 --- a/rules/linux/defense_evasion_interactive_shell_from_system_user.toml +++ b/rules/linux/defense_evasion_interactive_shell_from_system_user.toml @@ -2,7 +2,7 @@ creation_date = "2024/11/04" integration = ["endpoint"] maturity = "production" -updated_date = "2024/11/04" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -69,6 +69,42 @@ event.category:process and host.os.type:linux and event.type:start and event.act (user.name:daemon and process.name:at) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Interactive Shell Launched from System User + +In Linux environments, system users are typically non-interactive and serve specific system functions. Adversaries may exploit these accounts to launch interactive shells, bypassing security measures and evading detection. The detection rule identifies such anomalies by monitoring process activities linked to system users, excluding legitimate processes, and flagging unexpected interactive shell launches, thus highlighting potential malicious activity. + +### Possible investigation steps + +- Review the process details to identify the specific interactive shell that was launched, focusing on the process.interactive:true field. +- Examine the user.name field to determine which system user account was used to launch the shell and assess whether this account should have interactive shell access. +- Investigate the process.parent.executable and process.parent.name fields to understand the parent process that initiated the shell, checking for any unusual or unauthorized parent processes. +- Analyze the process.args field for any suspicious or unexpected command-line arguments that might indicate malicious intent. +- Cross-reference the event.timestamp with other security logs to identify any correlated activities or anomalies around the same time frame. +- Check for any recent changes or anomalies in the system user's account settings or permissions that could have facilitated the shell launch. +- Assess the risk and impact of the activity by considering the context of the system and the potential for further malicious actions. + +### False positive analysis + +- System maintenance tasks may trigger interactive shells from system users like 'daemon' or 'systemd-timesync'. To handle these, review the specific maintenance scripts and add exceptions for known benign processes. +- Automated backup or update processes might launch interactive shells under system users such as 'backup' or 'apt'. Identify these processes and exclude them by adding their parent process names or arguments to the exception list. +- Some monitoring or logging tools may use system accounts like 'messagebus' or 'dbus' to execute interactive shells. Verify these tools and exclude their activities if they are legitimate and necessary for system operations. +- Custom scripts or applications running under system users for specific tasks could be misidentified. Document these scripts and add their process names to the exclusion criteria to prevent false alerts. +- In environments where certain system users are repurposed for non-standard tasks, ensure these tasks are documented and create exceptions for their associated processes to avoid unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious interactive shell sessions initiated by system users to halt potential malicious activities. +- Conduct a thorough review of the affected system's logs and processes to identify any additional indicators of compromise or unauthorized changes. +- Reset credentials for the compromised system user accounts and any other accounts that may have been accessed or affected. +- Implement stricter access controls and monitoring for system user accounts to prevent unauthorized interactive shell launches in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Update detection mechanisms and rules to enhance monitoring for similar threats, ensuring that any future attempts are quickly identified and addressed.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/defense_evasion_kernel_module_removal.toml b/rules/linux/defense_evasion_kernel_module_removal.toml index 3b7b0ffd12f..fb12c921d8f 100644 --- a/rules/linux/defense_evasion_kernel_module_removal.toml +++ b/rules/linux/defense_evasion_kernel_module_removal.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -74,6 +74,41 @@ process where host.os.type == "linux" and event.type == "start" and ) and process.parent.name in ("sudo", "bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Kernel Module Removal + +Kernel modules dynamically extend a Linux kernel's capabilities without rebooting. Adversaries may exploit this by removing modules to disable security features or hide malicious activities. The detection rule identifies suspicious module removal attempts by monitoring processes like `rmmod` or `modprobe` with removal arguments, especially when initiated by common shell environments, indicating potential defense evasion tactics. + +### Possible investigation steps + +- Review the process details to confirm the execution of `rmmod` or `modprobe` with removal arguments. Check the command line arguments to ensure they match the suspicious activity criteria. +- Identify the parent process of the suspicious activity, focusing on shell environments like `sudo`, `bash`, `dash`, `ash`, `sh`, `tcsh`, `csh`, `zsh`, `ksh`, or `fish`, to understand the context in which the module removal was initiated. +- Investigate the user account associated with the process to determine if the activity aligns with expected behavior or if it indicates potential unauthorized access. +- Check system logs and audit logs for any preceding or subsequent suspicious activities that might correlate with the module removal attempt, such as privilege escalation or other defense evasion tactics. +- Assess the impact of the module removal on system security features and functionality, and determine if any critical security modules were targeted. +- Review recent changes or updates to the system that might explain the module removal, such as legitimate maintenance or updates, to rule out false positives. + +### False positive analysis + +- Routine administrative tasks may trigger the rule when system administrators use `rmmod` or `modprobe` for legitimate maintenance. To handle this, create exceptions for specific user accounts or scripts known to perform these tasks regularly. +- Automated scripts or configuration management tools that manage kernel modules might cause false positives. Identify these tools and exclude their processes from the rule to prevent unnecessary alerts. +- Some Linux distributions or custom setups might use shell scripts that invoke `rmmod` or `modprobe` during system updates or package installations. Monitor these activities and whitelist the associated parent processes if they are verified as non-threatening. +- Development environments where kernel module testing is frequent can generate alerts. Exclude specific development machines or user accounts involved in module testing to reduce noise. +- Security tools that perform regular checks or updates on kernel modules might inadvertently trigger the rule. Verify these tools and add them to the exception list to avoid false positives. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary. +- Terminate any suspicious processes identified as attempting to remove kernel modules, such as those initiated by `rmmod` or `modprobe` with removal arguments. +- Conduct a thorough review of user accounts and privileges on the affected system to ensure no unauthorized access or privilege escalation has occurred. +- Restore any disabled security features or kernel modules to their original state to ensure the system's defenses are intact. +- Analyze system logs and audit trails to identify any additional indicators of compromise or related malicious activities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign. +- Implement enhanced monitoring and alerting for similar activities across the network to detect and respond to future attempts promptly.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/defense_evasion_kthreadd_masquerading.toml b/rules/linux/defense_evasion_kthreadd_masquerading.toml index af5551a5132..bd3a8116434 100644 --- a/rules/linux/defense_evasion_kthreadd_masquerading.toml +++ b/rules/linux/defense_evasion_kthreadd_masquerading.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -65,6 +65,40 @@ query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and process.name : ("kworker*", "kthread*") and process.executable != null ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Executable Masquerading as Kernel Process + +In Linux environments, kernel processes like `kthreadd` and `kworker` typically run without associated executable paths. Adversaries exploit this by naming malicious executables after these processes to evade detection. The detection rule identifies anomalies by flagging kernel-named processes with non-empty executable fields, indicating potential masquerading attempts. This helps in uncovering stealthy threats that mimic legitimate system activities. + +### Possible investigation steps + +- Review the process details for the flagged process, focusing on the process.executable field to identify the path and name of the executable. This can provide initial insights into whether the executable is legitimate or potentially malicious. +- Check the process's parent process (process.parent) to understand the context in which the process was started. This can help determine if the process was spawned by a legitimate system process or a suspicious one. +- Investigate the file at the path specified in the process.executable field. Verify its legitimacy by checking its hash against known malware databases or using a file reputation service. +- Examine the process's command line arguments (process.command_line) for any unusual or suspicious parameters that might indicate malicious activity. +- Review recent system logs and events around the time the process was started to identify any related activities or anomalies that could provide additional context or evidence of compromise. +- If available, use threat intelligence sources to check for any known indicators of compromise (IOCs) related to the process name or executable path. + +### False positive analysis + +- Custom scripts or administrative tools may be named similarly to kernel processes for convenience or organizational standards. Review these scripts and tools to ensure they are legitimate and consider adding them to an exception list if verified. +- Some legitimate software or monitoring tools might use kernel-like names for their processes to integrate closely with system operations. Verify the source and purpose of these processes and exclude them if they are confirmed to be non-malicious. +- System updates or patches might temporarily create processes with kernel-like names that have executable paths. Monitor these occurrences and exclude them if they are part of a verified update process. +- Development or testing environments may intentionally use kernel-like names for process simulation. Ensure these environments are isolated and add exceptions for these processes if they are part of controlled testing scenarios. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity. +- Terminate the suspicious process immediately to stop any ongoing malicious actions. Use process management tools to kill the process identified by the alert. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise (IOCs) and assess the extent of the intrusion. +- Remove any malicious executables or files associated with the masquerading process from the system to ensure complete remediation. +- Restore the system from a known good backup if the integrity of the system is compromised, ensuring that the backup is free from any malicious artifacts. +- Update and patch the system to close any vulnerabilities that may have been exploited by the attacker, ensuring all software and security tools are up to date. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/linux/defense_evasion_ld_so_creation.toml b/rules/linux/defense_evasion_ld_so_creation.toml index e7cda7b8898..0cee4f4a0ab 100644 --- a/rules/linux/defense_evasion_ld_so_creation.toml +++ b/rules/linux/defense_evasion_ld_so_creation.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/01/06" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -64,6 +64,42 @@ file where host.os.type == "linux" and event.type == "creation" and process.exec file.path like~ ("/lib/ld-linux*.so*", "/lib64/ld-linux*.so*", "/usr/lib/ld-linux*.so*", "/usr/lib64/ld-linux*.so*") and not process.name in ("dockerd", "yum", "dnf", "microdnf", "pacman") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Dynamic Linker (ld.so) Creation + +The dynamic linker, ld.so, is crucial in Linux environments for loading shared libraries required by executables. Adversaries may exploit this by replacing it with a malicious version to execute unauthorized code, achieving persistence or evading defenses. The detection rule identifies suspicious creation of ld.so files, excluding benign processes, to flag potential threats. + +### Possible investigation steps + +- Review the process that triggered the alert by examining the process.executable field to understand which application attempted to create the ld.so file. +- Check the process.name field to ensure the process is not one of the benign processes listed in the exclusion criteria, such as "dockerd", "yum", "dnf", "microdnf", or "pacman". +- Investigate the file.path to confirm the location of the newly created ld.so file and verify if it matches any of the specified directories like "/lib", "/lib64", "/usr/lib", or "/usr/lib64". +- Analyze the parent process of the suspicious executable to determine if it was initiated by a legitimate or potentially malicious source. +- Look for any recent changes or anomalies in the system logs around the time of the file creation event to identify any related suspicious activities. +- Cross-reference the event with other security tools or logs, such as Elastic Defend or SentinelOne, to gather additional context or corroborating evidence of malicious activity. +- Assess the risk and impact of the event by considering the system's role and the potential consequences of a compromised dynamic linker on that system. + +### False positive analysis + +- Package managers like yum, dnf, microdnf, and pacman can trigger false positives when they update or install packages that involve the dynamic linker. These processes are already excluded in the rule, but ensure any custom package managers or scripts are also considered for exclusion. +- Container management tools such as dockerd may create or modify ld.so files during container operations. If you use other container tools, consider adding them to the exclusion list to prevent false positives. +- System updates or maintenance scripts that involve library updates might create ld.so files. Review these scripts and add them to the exclusion list if they are verified as non-threatening. +- Custom administrative scripts or automation tools that interact with shared libraries could inadvertently trigger the rule. Identify these scripts and exclude them if they are part of regular, secure operations. +- Development environments where ld.so files are frequently created or modified during testing and compilation processes may need specific exclusions for development tools or environments to avoid false positives. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Verify the integrity of the dynamic linker (ld.so) on the affected system by comparing it with a known good version from a trusted source or repository. +- If the dynamic linker has been tampered with, replace it with the verified version and ensure all system binaries are intact. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection tools to identify and remove any additional malicious files or processes. +- Review system logs and the process creation history to identify the source of the unauthorized ld.so creation and any associated malicious activity. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems are affected. +- Implement additional monitoring and alerting for similar suspicious activities, such as unauthorized file creations in critical system directories, to enhance future detection capabilities.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/defense_evasion_log_files_deleted.toml b/rules/linux/defense_evasion_log_files_deleted.toml index 4004647cc05..1f258e11a0a 100644 --- a/rules/linux/defense_evasion_log_files_deleted.toml +++ b/rules/linux/defense_evasion_log_files_deleted.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/01/06" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -95,6 +95,41 @@ file where host.os.type == "linux" and event.type == "deletion" and ) and not process.name in ("gzip", "executor", "dockerd") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 System Log File Deletion + +System logs are crucial for monitoring and auditing activities on Linux systems, providing insights into system events and user actions. Adversaries may delete these logs to cover their tracks, hindering forensic investigations. The detection rule identifies suspicious deletions of key log files, excluding benign processes like compression tools, to flag potential evasion attempts. This helps security analysts quickly respond to and investigate unauthorized log deletions. + +### Possible investigation steps + +- Review the specific file path involved in the deletion event to determine which log file was targeted, using the file.path field from the alert. +- Investigate the process responsible for the deletion by examining the process.name and related process metadata to identify any suspicious or unauthorized activity. +- Check for any recent login or session activity around the time of the log deletion by reviewing other logs or authentication records, focusing on the /var/log/auth.log and /var/log/secure files if they are still available. +- Analyze the user account associated with the deletion event to determine if it has a history of suspicious activity or if it was potentially compromised. +- Correlate the deletion event with other security alerts or anomalies in the system to identify any patterns or related incidents that might indicate a broader attack or compromise. +- Assess the impact of the log deletion on the system's security posture and determine if any critical forensic evidence has been lost, considering the importance of the deleted log file. + +### False positive analysis + +- Compression tools like gzip may trigger false positives when they temporarily delete log files during compression. To mitigate this, ensure gzip is included in the exclusion list within the detection rule. +- Automated system maintenance scripts might delete or rotate log files as part of routine operations. Review these scripts and add their process names to the exclusion list if they are verified as non-threatening. +- Docker-related processes, such as dockerd, can also cause false positives when managing container logs. Confirm these activities are legitimate and include dockerd in the exclusion list to prevent unnecessary alerts. +- Custom backup or log management tools may delete logs as part of their normal function. Identify these tools and add their process names to the exclusion list after verifying their benign nature. +- Scheduled tasks or cron jobs that manage log files should be reviewed. If they are confirmed to be safe, their associated process names should be added to the exclusion list to avoid false positives. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data tampering. +- Conduct a thorough review of user accounts and permissions on the affected system to identify any unauthorized access or privilege escalation. +- Restore deleted log files from backups if available, to aid in further forensic analysis and to maintain system integrity. +- Implement enhanced monitoring on the affected system and similar systems to detect any further unauthorized log deletions or suspicious activities. +- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the scope of the breach. +- Review and update security policies and configurations to ensure that only authorized processes can delete critical log files, leveraging access controls and audit policies. +- Consider deploying additional endpoint detection and response (EDR) solutions to improve visibility and detection capabilities for similar threats in the future.""" [[rule.threat]] diff --git a/rules/linux/defense_evasion_mount_execution.toml b/rules/linux/defense_evasion_mount_execution.toml index 9d6d2c01c6b..321677f4be1 100644 --- a/rules/linux/defense_evasion_mount_execution.toml +++ b/rules/linux/defense_evasion_mount_execution.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -69,6 +69,41 @@ process where host.os.type == "linux" and event.type == "start" and process.name == "mount" and process.args == "/proc" and process.args == "-o" and process.args : "*hidepid=2*" and not process.parent.command_line like "/opt/cloudlinux/*" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Hidden Process via Mount Hidepid + +The 'hidepid' mount option in Linux allows users to restrict visibility of process information in the /proc filesystem, enhancing privacy by limiting process visibility to the owner. Adversaries exploit this by remounting /proc with 'hidepid=2', concealing their processes from non-root users and evading detection tools like ps or top. The detection rule identifies such activity by monitoring for the execution of the mount command with specific arguments, flagging potential misuse for further investigation. + +### Possible investigation steps + +- Review the alert details to confirm the presence of the 'mount' process execution with arguments indicating '/proc' and 'hidepid=2'. +- Check the user account associated with the process execution to determine if it is a legitimate administrative user or a potential adversary. +- Investigate the parent process of the 'mount' command to understand the context and origin of the execution, ensuring it is not part of a known or legitimate administrative script. +- Examine recent login activity and user sessions on the host to identify any unauthorized access or suspicious behavior around the time of the alert. +- Analyze other processes running on the system to identify any hidden or suspicious activities that might be related to the use of 'hidepid=2'. +- Review system logs and audit logs for any additional indicators of compromise or related suspicious activities that coincide with the alert. + +### False positive analysis + +- System administrators or automated scripts may remount /proc with hidepid=2 for legitimate privacy or security reasons. To handle this, create exceptions for known administrative scripts or users by excluding their specific command lines or user IDs. +- Some security tools or monitoring solutions might use hidepid=2 as part of their normal operation to enhance system security. Identify these tools and exclude their processes from triggering alerts by adding them to an allowlist. +- Cloud environments or containerized applications might use hidepid=2 to isolate processes for multi-tenant security. Review the environment's standard operating procedures and exclude these known behaviors from detection. +- Regular system updates or maintenance scripts might temporarily use hidepid=2. Document these occurrences and adjust the detection rule to ignore these specific maintenance windows or scripts. +- If using a specific Linux distribution that employs hidepid=2 by default for certain operations, verify these defaults and configure the detection rule to exclude them. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Use root privileges to remount the /proc filesystem without the 'hidepid=2' option to restore visibility of all processes. +- Conduct a thorough review of running processes and system logs to identify any unauthorized or suspicious activities that may have been concealed. +- Terminate any identified malicious processes and remove any associated files or scripts from the system. +- Change all system and user passwords to prevent unauthorized access, especially if credential theft is suspected. +- 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 attempts to use the 'hidepid' option, ensuring rapid detection and response.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/defense_evasion_potential_proot_exploits.toml b/rules/linux/defense_evasion_potential_proot_exploits.toml index d5a8be6b691..37a3fa35661 100644 --- a/rules/linux/defense_evasion_potential_proot_exploits.toml +++ b/rules/linux/defense_evasion_potential_proot_exploits.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -70,6 +70,39 @@ query = ''' process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and process.parent.name == "proot" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Defense Evasion via PRoot + +PRoot is a versatile tool that emulates a chroot-like environment, allowing users to run applications across different Linux distributions seamlessly. Adversaries exploit PRoot to create consistent environments for executing malicious payloads, bypassing traditional defenses. The detection rule identifies suspicious PRoot activity by monitoring process executions initiated by PRoot, flagging potential misuse for defense evasion. + +### Possible investigation steps + +- Review the process tree to identify the parent process of PRoot and any child processes it spawned, focusing on the process.parent.name field to confirm PRoot as the parent. +- Examine the command line arguments used with PRoot to understand the context of its execution and identify any potentially malicious payloads or scripts being executed. +- Check the user account associated with the PRoot process to determine if it aligns with expected usage patterns or if it indicates potential compromise. +- Investigate the network activity associated with the PRoot process to identify any unusual connections or data transfers that could suggest malicious intent. +- Correlate the PRoot activity with other security alerts or logs to identify any related suspicious behavior or indicators of compromise within the same timeframe. + +### False positive analysis + +- Legitimate use of PRoot for cross-distribution development or testing environments may trigger alerts. Users can create exceptions for known development teams or specific projects that require PRoot for legitimate purposes. +- System administrators using PRoot for system maintenance or migration tasks might be flagged. To mitigate this, document and whitelist these activities by correlating them with scheduled maintenance windows or specific administrator accounts. +- Security researchers or penetration testers employing PRoot for controlled testing scenarios could cause false positives. Establish a process to identify and exclude these activities by verifying the involved personnel and their testing scope. +- Automated scripts or tools that utilize PRoot for non-malicious purposes, such as software compatibility testing, should be reviewed. Implement a tagging system to differentiate these benign activities from potential threats, allowing for easier exclusion in future detections. + +### Response and remediation + +- Isolate the affected system immediately to prevent further spread of the threat across the network. Disconnect it from the network and any shared resources. +- Terminate any suspicious processes initiated by PRoot to halt any ongoing malicious activities. Use process management tools to identify and kill these processes. +- Conduct a thorough examination of the filesystem for any unauthorized changes or suspicious files that may have been introduced by the adversary using PRoot. +- Restore the system from a known good backup if any malicious modifications are detected, ensuring that the backup is free from compromise. +- Update and patch the affected system to the latest security standards to close any vulnerabilities that may have been exploited. +- Implement enhanced monitoring for PRoot activity across the environment to detect any future unauthorized use. This includes setting up alerts for any process executions with PRoot as the parent process. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/linux/defense_evasion_rename_esxi_files.toml b/rules/linux/defense_evasion_rename_esxi_files.toml index 114e0492005..464795fc2cb 100644 --- a/rules/linux/defense_evasion_rename_esxi_files.toml +++ b/rules/linux/defense_evasion_rename_esxi_files.toml @@ -2,7 +2,7 @@ creation_date = "2023/04/11" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -62,6 +62,41 @@ file where host.os.type == "linux" and event.action == "rename" and file.Ext.original.name : ("*.vmdk", "*.vmx", "*.vmxf", "*.vmsd", "*.vmsn", "*.vswp", "*.vmss", "*.nvram", "*.vmem") and not file.name : ("*.vmdk", "*.vmx", "*.vmxf", "*.vmsd", "*.vmsn", "*.vswp", "*.vmss", "*.nvram", "*.vmem") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Renaming of ESXI Files + +VMware ESXi files are critical for virtual machine operations, storing configurations and states. Adversaries may rename these files to evade detection or disrupt services, a tactic known as masquerading. The detection rule identifies renaming events of specific VMware file types on Linux systems, flagging potential malicious activity by monitoring deviations from expected file extensions. + +### Possible investigation steps + +- Review the alert details to identify the specific file that was renamed, including its original and new name, to understand the nature of the change. +- Check the timestamp of the rename event to correlate it with other activities on the system, such as user logins or other file operations, to identify potential patterns or anomalies. +- Investigate the user account or process responsible for the rename action by examining system logs or user activity to determine if the action was authorized or suspicious. +- Analyze the system for any other recent rename events involving VMware-related files to assess if this is an isolated incident or part of a broader pattern. +- Examine the system for signs of compromise or unauthorized access, such as unexpected processes, network connections, or changes in system configurations, to identify potential threats. +- Consult with relevant stakeholders, such as system administrators or security teams, to verify if the rename action was part of a legitimate maintenance or operational task. + +### False positive analysis + +- Routine maintenance or administrative tasks may involve renaming VMware ESXi files for organizational purposes. To manage this, identify and exclude specific users or processes that regularly perform these tasks from triggering alerts. +- Automated backup or snapshot processes might rename files temporarily as part of their operation. Review and whitelist these processes to prevent unnecessary alerts. +- Development or testing environments often involve frequent renaming of virtual machine files for configuration testing. Consider excluding these environments from the rule or setting up a separate monitoring profile with adjusted thresholds. +- System updates or patches might include scripts that rename files as part of the update process. Verify and exclude these scripts if they are known and trusted. +- Custom scripts or tools used by IT teams for managing virtual machines may rename files as part of their functionality. Ensure these scripts are documented and excluded from triggering the rule. + +### Response and remediation + +- Immediately isolate the affected Linux system from the network to prevent further unauthorized access or potential spread of malicious activity. +- Verify the integrity of the renamed VMware ESXi files by comparing them with known good backups or snapshots, and restore any altered files from a secure backup if necessary. +- Conduct a thorough review of recent system logs and user activity to identify any unauthorized access or actions that may have led to the file renaming. +- Revert any unauthorized changes to system configurations or permissions that may have facilitated the renaming of critical 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 on the affected system and similar environments to detect any further attempts at file masquerading or other suspicious activities. +- Review and update access controls and permissions for VMware ESXi files to ensure only authorized users have the ability to rename or modify these files.""" [[rule.threat]] diff --git a/rules/linux/defense_evasion_rename_esxi_index_file.toml b/rules/linux/defense_evasion_rename_esxi_index_file.toml index c9061d947da..f8f22fb3ac7 100644 --- a/rules/linux/defense_evasion_rename_esxi_index_file.toml +++ b/rules/linux/defense_evasion_rename_esxi_index_file.toml @@ -2,7 +2,7 @@ creation_date = "2023/04/11" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -61,6 +61,41 @@ query = ''' file where host.os.type == "linux" and event.action == "rename" and file.name : "index.html" and file.Ext.original.path : "/usr/lib/vmware/*" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Renaming of ESXI index.html File + +VMware ESXi hosts use the index.html file within their web interface for management tasks. Adversaries may rename this file to evade detection or to replace it with a malicious version, facilitating unauthorized access or data exfiltration. The detection rule monitors Linux systems for renaming actions targeting this file in the VMware directory, flagging potential defense evasion attempts by correlating file path and event actions. + +### Possible investigation steps + +- Review the alert details to confirm the file path and event action, ensuring the "rename" action occurred on the "index.html" file within the "/usr/lib/vmware/*" directory. +- Check the timestamp of the rename event to determine when the activity occurred and correlate it with any other suspicious activities or alerts around the same time. +- Identify the user or process responsible for the rename action by examining the associated user account and process details in the event logs. +- Investigate the system's recent login history and user activity to identify any unauthorized access or anomalies that could be linked to the rename event. +- Analyze the renamed file and any new files in the directory for signs of tampering or malicious content, using file integrity monitoring tools or antivirus scans. +- Review network logs for any unusual outbound connections from the affected host that could indicate data exfiltration or communication with a command and control server. +- Consider isolating the affected host from the network to prevent further potential malicious activity while the investigation is ongoing. + +### False positive analysis + +- Routine maintenance or updates on VMware ESXi hosts may involve renaming the index.html file temporarily. Users can create exceptions for known maintenance windows to prevent unnecessary alerts. +- Automated scripts or backup processes might rename the index.html file as part of their operations. Identify and whitelist these scripts or processes to avoid false positives. +- System administrators may manually rename the index.html file for legitimate customization or troubleshooting purposes. Document and exclude these actions by specific user accounts or during specific time frames. +- Security tools or monitoring solutions might trigger renaming actions as part of their scanning or remediation tasks. Verify and exclude these tools from the rule to reduce false alerts. + +### Response and remediation + +- Immediately isolate the affected VMware ESXi host from the network to prevent further unauthorized access or data exfiltration. +- Verify the integrity of the index.html file by comparing it with a known good version from a trusted source to determine if it has been tampered with or replaced. +- Restore the original index.html file from a secure backup if it has been altered or replaced, ensuring that the backup is from a time before the suspicious activity was detected. +- Conduct a thorough review of recent access logs and system changes on the affected host to identify any unauthorized access or modifications that may have occurred. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be compromised. +- Implement additional monitoring on the affected host and similar systems to detect any further attempts to rename or modify critical files. +- Review and update access controls and permissions on the VMware ESXi host to ensure that only authorized personnel have the ability to modify critical system files.""" [[rule.threat]] diff --git a/rules/linux/defense_evasion_root_certificate_installation.toml b/rules/linux/defense_evasion_root_certificate_installation.toml index c462f2c7dab..6ba56e5ca95 100644 --- a/rules/linux/defense_evasion_root_certificate_installation.toml +++ b/rules/linux/defense_evasion_root_certificate_installation.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -70,6 +70,41 @@ process.name in ("update-ca-trust", "update-ca-certificates") and not ( (process.parent.name in ("sh", "bash", "zsh") and process.args == "-e") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Root Certificate Installation + +Root certificates are pivotal in establishing trust within public key infrastructures, enabling secure communications by verifying the authenticity of entities. Adversaries exploit this by installing rogue root certificates on compromised Linux systems, thus bypassing security warnings and facilitating undetected command and control communications. The detection rule identifies suspicious certificate installations by monitoring specific processes and excluding legitimate parent processes, thereby highlighting potential unauthorized activities. + +### Possible investigation steps + +- Review the process details to confirm the execution of "update-ca-trust" or "update-ca-certificates" on the Linux host, focusing on the event type "start" and action "exec" or "exec_event". +- Examine the parent process name and arguments to ensure they do not match any of the legitimate exclusions such as "ca-certificates.postinst", "pacman", or "/var/tmp/rpm*". +- Investigate the user account associated with the process to determine if it is a known or expected user for such operations. +- Check the system logs and recent changes to identify any unauthorized modifications or installations that coincide with the alert. +- Correlate the alert with other security events or logs to identify any potential command and control communications or other suspicious activities on the host. +- Assess the network connections from the host around the time of the alert to detect any unusual or unauthorized outbound traffic. + +### False positive analysis + +- Legitimate system updates or package installations may trigger the rule when processes like "update-ca-trust" or "update-ca-certificates" are executed by trusted package managers such as "pacman" or "pamac-daemon". To mitigate this, ensure these parent processes are included in the exclusion list. +- Automated scripts or system maintenance tasks that use shell scripts (e.g., "sh", "bash", "zsh") to update certificates might be flagged. If these scripts are verified as safe, consider adding specific script names or paths to the exclusion criteria. +- Custom applications or services that require certificate updates and are known to be safe can be excluded by adding their parent process names to the exclusion list, ensuring they do not trigger false alerts. +- Security tools or agents like "kesl" or "execd" that manage certificates as part of their operations may cause false positives. Verify their activities and include them in the exclusion list if they are part of legitimate security operations. +- Temporary files or scripts located in directories like "/var/tmp/rpm*" used during legitimate installations should be reviewed and excluded if they are part of routine system operations. + +### Response and remediation + +- Immediately isolate the affected Linux system from the network to prevent further unauthorized communications with potential command and control servers. +- Revoke any unauthorized root certificates installed on the system by removing them from the trusted certificate store to restore the integrity of the system's trust chain. +- Conduct a thorough review of system logs and process execution history to identify any additional unauthorized activities or changes made by the adversary. +- Restore the system from a known good backup if unauthorized changes or persistent threats are detected that cannot be easily remediated. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited by the adversary. +- Implement enhanced monitoring and alerting for similar suspicious activities, focusing on process executions related to certificate management. +- Escalate the incident to the security operations center (SOC) or relevant incident response team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/defense_evasion_selinux_configuration_creation_or_renaming.toml b/rules/linux/defense_evasion_selinux_configuration_creation_or_renaming.toml index 46d5a10dc28..3b1a3fbcc78 100644 --- a/rules/linux/defense_evasion_selinux_configuration_creation_or_renaming.toml +++ b/rules/linux/defense_evasion_selinux_configuration_creation_or_renaming.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_comments = "Breaking change at 8.16.2 for the SentinelOne Integration." min_stack_version = "8.16.2" -updated_date = "2025/01/06" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -62,6 +62,42 @@ query = ''' file where host.os.type == "linux" and event.action in ("creation", "file_create_event", "rename", "file_rename_event") and file.path : "/etc/selinux/config" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 SELinux Configuration Creation or Renaming + +SELinux, a Linux kernel security module, enforces access control policies to protect systems. Adversaries may target the SELinux configuration file to disable or alter these defenses, facilitating unauthorized access or evasion of security measures. The detection rule identifies suspicious activities like file creation or renaming in the SELinux configuration path, signaling potential defense evasion attempts. + +### Possible investigation steps + +- Review the alert details to confirm the event action is either "creation", "file_create_event", "rename", or "file_rename_event" and that the file path is "/etc/selinux/config". +- Check the timestamp of the event to determine when the SELinux configuration file was created or renamed. +- Identify the user account and process responsible for the action by examining the event logs for associated user and process information. +- Investigate the history of changes to the SELinux configuration file to determine if there have been any recent unauthorized modifications. +- Correlate the event with other security alerts or logs to identify any related suspicious activities or patterns on the host. +- Assess the current state of SELinux on the affected system to ensure it is configured correctly and has not been disabled or altered inappropriately. +- If unauthorized changes are confirmed, initiate a response plan to mitigate potential security risks, which may include restoring the original configuration and conducting a broader security assessment of the system. + +### False positive analysis + +- Routine system updates or administrative tasks may trigger file creation or renaming events in the SELinux configuration path. Users can create exceptions for known update processes or trusted administrative scripts to prevent unnecessary alerts. +- Automated configuration management tools like Ansible, Puppet, or Chef might modify the SELinux configuration file as part of their normal operations. Users should identify and whitelist these tools to reduce false positives. +- Initial system setup or reconfiguration activities often involve legitimate changes to the SELinux configuration. Users can temporarily disable the rule during planned maintenance windows or add exceptions for specific time frames to avoid false alerts. +- Security audits or compliance checks may involve accessing or modifying SELinux settings. Users should coordinate with audit teams to recognize these activities and adjust the rule settings accordingly. +- Custom scripts or applications developed in-house that interact with SELinux settings should be reviewed and, if deemed safe, added to an exception list to minimize false positives. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary. +- Verify the integrity of the SELinux configuration file by comparing it with a known good backup. If discrepancies are found, restore the file from a trusted backup. +- Conduct a thorough review of recent user and process activity on the affected system to identify any unauthorized changes or suspicious behavior that may have led to the SELinux configuration modification. +- Re-enable SELinux enforcement if it has been disabled, and ensure that the correct security policies are applied to maintain system protection. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. +- Implement additional monitoring on the affected system and similar systems to detect any further attempts to modify SELinux configurations or other critical security settings. +- Review and update access controls and permissions to ensure that only authorized personnel have the ability to modify SELinux configurations, reducing the risk of future unauthorized changes.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/defense_evasion_ssl_certificate_deletion.toml b/rules/linux/defense_evasion_ssl_certificate_deletion.toml index 861b9a5dd90..c3bba78eae9 100644 --- a/rules/linux/defense_evasion_ssl_certificate_deletion.toml +++ b/rules/linux/defense_evasion_ssl_certificate_deletion.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/06" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -61,6 +61,40 @@ query = ''' file where host.os.type == "linux" and event.type == "deletion" and file.path : "/etc/ssl/certs/*" and file.extension in ("pem", "crt") and not process.name in ("dockerd", "pacman") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 SSL Certificate Deletion +SSL certificates are crucial for establishing secure communications in Linux environments. Adversaries may delete these certificates to undermine trust and disrupt system operations, often as part of defense evasion tactics. The detection rule identifies suspicious deletions by monitoring specific directories for certificate files, excluding benign processes, thus highlighting potential malicious activity. + +### Possible investigation steps + +- Review the alert details to confirm the file path and extension of the deleted SSL certificate, ensuring it matches the pattern "/etc/ssl/certs/*" with extensions "pem" or "crt". +- Identify the process responsible for the deletion by examining the process name and compare it against the exclusion list (e.g., "dockerd", "pacman") to determine if the process is potentially malicious. +- Investigate the user account associated with the process that performed the deletion to assess if the account has a history of suspicious activity or unauthorized access. +- Check system logs and audit trails around the time of the deletion event to identify any related activities or anomalies that could indicate a broader attack or compromise. +- Assess the impact of the certificate deletion on system operations and security, including any disruptions to secure communications or trust relationships. +- If the deletion is deemed suspicious, consider restoring the deleted certificate from backups and implementing additional monitoring to detect further unauthorized deletions. + +### False positive analysis + +- Routine system updates or package installations may trigger certificate deletions. Exclude processes like package managers or update services that are known to perform these actions. +- Automated certificate renewal services might delete old certificates as part of their renewal process. Identify and exclude these services to prevent false alerts. +- Custom scripts or maintenance tasks that manage SSL certificates could be flagged. Review and whitelist these scripts if they are verified as non-malicious. +- Backup or cleanup operations that involve certificate files might cause false positives. Ensure these operations are recognized and excluded from monitoring. +- Development or testing environments where certificates are frequently added and removed can generate alerts. Consider excluding these environments if they are isolated and secure. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or damage. +- Verify the deletion of SSL certificates by checking the specified directories and confirm the absence of expected certificate files. +- Restore deleted SSL certificates from a secure backup to re-establish secure communications and trust controls. +- Conduct a thorough review of system logs and process activity to identify the source of the deletion and any associated malicious activity. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement additional monitoring on the affected system and similar environments to detect any further unauthorized deletions or related suspicious activities. +- Review and update access controls and permissions to ensure only authorized processes and users can modify or delete SSL certificates.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/defense_evasion_sus_utility_executed_via_tmux_or_screen.toml b/rules/linux/defense_evasion_sus_utility_executed_via_tmux_or_screen.toml index 86b5173a792..e50e1d9f09f 100644 --- a/rules/linux/defense_evasion_sus_utility_executed_via_tmux_or_screen.toml +++ b/rules/linux/defense_evasion_sus_utility_executed_via_tmux_or_screen.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -41,6 +41,40 @@ process where host.os.type == "linux" and event.type == "start" and "openssl", "telnet", "wget", "curl", "id" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Potentially Suspicious Process Started via tmux or screen + +Tmux and screen are terminal multiplexers that allow users to manage multiple terminal sessions from a single window, facilitating multitasking and session persistence. Adversaries may exploit these tools to execute commands stealthily, detaching sessions to run processes in the background. The detection rule identifies suspicious processes initiated by tmux or screen, focusing on potentially malicious commands, to uncover attempts at evading security measures. + +### Possible investigation steps + +- Review the process details to identify the specific command executed by tmux or screen, focusing on the process.name field to determine if it matches any known suspicious commands like "nmap", "nc", "wget", etc. +- Examine the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears anomalous. +- Check the parent process information, specifically process.parent.name, to confirm that the process was indeed initiated by tmux or screen, and assess if this behavior is expected for the user or system. +- Investigate the network activity associated with the process, especially if the command involves network utilities like "curl" or "ping", to identify any unusual or unauthorized connections. +- Correlate the event with other security alerts or logs from the same host or user to identify any patterns or additional suspicious activities that might indicate a broader attack or compromise. + +### False positive analysis + +- System administrators or developers may use tmux or screen to run legitimate maintenance scripts or development tools like Java, PHP, or Perl. To manage these, create exceptions for known scripts or processes that are regularly executed by trusted users. +- Automated monitoring or testing tools might utilize tmux or screen to execute network diagnostic commands such as ping or nmap. Identify and whitelist these tools if they are part of routine operations. +- Some backup or data transfer processes might use wget or curl to fetch resources. Verify the source and destination of these processes and exclude them if they are part of scheduled tasks. +- Developers might use tmux or screen to run interactive sessions with languages like Ruby or Lua for debugging purposes. Establish a list of trusted users and exclude their sessions from triggering alerts. +- In environments where remote management is common, tools like ngrok might be used for legitimate purposes. Ensure that these tools are configured securely and exclude them if they are part of authorized workflows. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified as being initiated by tmux or screen, especially those matching the query criteria. +- Conduct a thorough review of the affected system's process tree and logs to identify any additional malicious activity or persistence mechanisms. +- Reset credentials and review access permissions for any accounts that were active on the affected system to prevent unauthorized access. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised. +- Implement network monitoring to detect any unusual outbound connections or data exfiltration attempts from the affected host. +- Update and enhance detection rules to include additional suspicious command patterns or behaviors observed during the investigation.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/defense_evasion_unusual_preload_env_vars.toml b/rules/linux/defense_evasion_unusual_preload_env_vars.toml index 06cc415ae7d..725077a44dc 100644 --- a/rules/linux/defense_evasion_unusual_preload_env_vars.toml +++ b/rules/linux/defense_evasion_unusual_preload_env_vars.toml @@ -2,7 +2,7 @@ creation_date = "2024/12/16" integration = ["endpoint"] maturity = "production" -updated_date = "2024/12/16" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -70,6 +70,41 @@ type = "new_terms" query = ''' event.category:process and host.os.type:linux and event.type:start and event.action:exec and process.env_vars:* ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Preload Environment Variable Process Execution + +In Linux environments, preload environment variables can dictate which libraries are loaded into a process, potentially altering its behavior. Adversaries exploit this by injecting malicious libraries to hijack execution flow, achieving persistence or evasion. The detection rule identifies atypical environment variables during process execution, signaling potential misuse by attackers. + +### Possible investigation steps + +- Review the process details associated with the alert, focusing on the process name, command line, and any unusual environment variables listed in process.env_vars. +- Investigate the parent process to understand the context of how the process was initiated and whether it aligns with expected behavior. +- Check the history of the process and its associated user account to identify any recent changes or suspicious activities that might indicate compromise. +- Analyze the libraries or binaries specified in the environment variables to determine if they are legitimate or potentially malicious. +- Cross-reference the process and environment variables with known threat intelligence sources to identify any matches with known malicious activity. +- Examine system logs and other related alerts around the same timeframe to identify any correlated or supporting evidence of malicious activity. + +### False positive analysis + +- Development and testing environments often use custom preload variables to test new libraries, which can trigger false positives. Users should identify and whitelist these known variables to prevent unnecessary alerts. +- Some legitimate software applications may use uncommon preload environment variables for performance optimization or compatibility reasons. Users can create exceptions for these applications by verifying their source and behavior. +- System administrators might employ preload variables for system tuning or debugging purposes. Documenting and excluding these specific cases can help reduce false positives. +- Security tools and monitoring solutions might use preload variables as part of their operation. Ensure these tools are recognized and excluded from triggering alerts by maintaining an updated list of their known behaviors. +- Regularly review and update the list of excluded variables and processes to adapt to changes in the environment and software updates, ensuring that only non-threatening behaviors are excluded. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified with unusual preload environment variables to halt potential malicious execution. +- Conduct a thorough review of the affected system's environment variables and loaded libraries to identify and remove any unauthorized or malicious entries. +- Restore the affected system from a known good backup to ensure all malicious modifications are removed. +- Update and patch the system to the latest security standards to mitigate vulnerabilities that could be exploited for similar attacks. +- Monitor the network and system logs for any signs of re-infection or similar suspicious activity, focusing on process execution patterns. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/discovery_dynamic_linker_via_od.toml b/rules/linux/discovery_dynamic_linker_via_od.toml index cb335926989..bcd8322402a 100644 --- a/rules/linux/discovery_dynamic_linker_via_od.toml +++ b/rules/linux/discovery_dynamic_linker_via_od.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_ maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -70,6 +70,39 @@ process where host.os.type == "linux" and event.type == "start" and event.action "/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2", "/usr/lib64/ld-linux-x86-64.so.2" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Dynamic Linker Discovery via od + +The dynamic linker in Linux environments is crucial for loading shared libraries needed by programs. Attackers may exploit the `od` utility to inspect these linkers, seeking vulnerabilities for code injection. The detection rule identifies suspicious use of `od` targeting specific linker files, flagging potential reconnaissance activities that could precede an exploit attempt. + +### Possible investigation steps + +- Review the process execution details to confirm the use of the 'od' utility, focusing on the process name and arguments to ensure they match the suspicious patterns identified in the query. +- Investigate the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it appears anomalous. +- Check the system's process execution history for any other unusual or related activities around the same time, such as attempts to access or modify linker files. +- Analyze any network connections or data transfers initiated by the host around the time of the alert to identify potential data exfiltration or communication with known malicious IPs. +- Correlate this event with other security alerts or logs from the same host to identify patterns or sequences of actions that could indicate a broader attack campaign. + +### False positive analysis + +- System administrators or developers may use the od utility to inspect dynamic linker files for legitimate debugging or system maintenance purposes. To handle this, create exceptions for known user accounts or processes that regularly perform these activities. +- Automated scripts or monitoring tools might invoke od on dynamic linker files as part of routine system checks. Identify these scripts and whitelist their execution paths to prevent unnecessary alerts. +- Security researchers or penetration testers could use od during authorized security assessments. Establish a process to temporarily disable the rule or add exceptions for the duration of the assessment to avoid false positives. +- Some software installations or updates might involve the use of od to verify linker integrity. Monitor installation logs and correlate with od usage to determine if the activity is benign, and consider adding exceptions for these specific scenarios. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement or further exploitation. +- Terminate any suspicious processes associated with the `od` utility that are targeting dynamic linker files to halt any ongoing reconnaissance or exploitation attempts. +- Conduct a thorough review of system logs and process execution history to identify any unauthorized access or modifications to the dynamic linker files. +- Restore any altered or compromised dynamic linker files from a known good backup to ensure system integrity. +- Implement stricter access controls and monitoring on critical system files, including dynamic linkers, to prevent unauthorized access and modifications. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected or if there is a broader threat campaign. +- Update detection and monitoring systems to enhance visibility and alerting for similar suspicious activities involving the `od` utility and critical system files.""" [[rule.threat]] diff --git a/rules/linux/discovery_esxi_software_via_find.toml b/rules/linux/discovery_esxi_software_via_find.toml index b5f479b5766..40215439bb0 100644 --- a/rules/linux/discovery_esxi_software_via_find.toml +++ b/rules/linux/discovery_esxi_software_via_find.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -68,6 +68,40 @@ process where host.os.type == "linux" and event.type == "start" and process.name == "find" and process.args : ("/etc/vmware/*", "/usr/lib/vmware/*", "/vmfs/*") and not process.parent.executable == "/usr/lib/vmware/viewagent/bin/uninstall_viewagent.sh" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 ESXI Discovery via Find + +VMware ESXi is a hypervisor used to deploy and manage virtual machines. Adversaries may exploit the 'find' command on Linux systems to locate VM-related files, potentially to gather information or manipulate configurations. The detection rule identifies suspicious 'find' command executions targeting VMware paths, excluding legitimate processes, to flag potential reconnaissance activities. + +### Possible investigation steps + +- Review the process execution details to confirm the 'find' command was executed with arguments targeting VMware paths such as "/etc/vmware/*", "/usr/lib/vmware/*", or "/vmfs/*". +- Check the parent process of the 'find' command to ensure it is not "/usr/lib/vmware/viewagent/bin/uninstall_viewagent.sh", which is excluded from the rule as a legitimate process. +- Investigate the user account associated with the 'find' command execution to determine if it is a known and authorized user for VMware management tasks. +- Examine recent login and access logs for the user account to identify any unusual or unauthorized access patterns. +- Correlate this event with other security alerts or logs to identify if there are additional signs of reconnaissance or unauthorized activity on the system. +- Assess the system's current state and configuration to ensure no unauthorized changes have been made to VMware-related files or settings. + +### False positive analysis + +- Legitimate administrative tasks may trigger the rule if system administrators use the 'find' command to audit or manage VMware-related files. To handle this, create exceptions for known administrative scripts or user accounts that regularly perform these tasks. +- Automated backup or monitoring scripts that scan VMware directories can also cause false positives. Identify these scripts and exclude their parent processes from the detection rule. +- Software updates or maintenance activities involving VMware components might execute the 'find' command in a non-threatening manner. Consider scheduling these activities during known maintenance windows and temporarily adjusting the rule to prevent unnecessary alerts. +- If the 'find' command is part of a legitimate software installation or uninstallation process, such as the VMware View Agent uninstallation, ensure these processes are whitelisted by adding their parent executable paths to the exception list. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious 'find' processes identified in the alert to halt potential reconnaissance activities. +- Conduct a thorough review of the system's recent command history and logs to identify any unauthorized access or changes made to VM-related files. +- Restore any altered or deleted VM-related files from a known good backup to ensure system integrity. +- Update and patch the VMware ESXi and related software to the latest versions to mitigate any known vulnerabilities. +- Implement stricter access controls and monitoring on VMware-related directories to prevent unauthorized access in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/discovery_esxi_software_via_grep.toml b/rules/linux/discovery_esxi_software_via_grep.toml index ab1ce5793f0..03e20db0f7b 100644 --- a/rules/linux/discovery_esxi_software_via_grep.toml +++ b/rules/linux/discovery_esxi_software_via_grep.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -69,6 +69,39 @@ process where host.os.type == "linux" and event.type == "start" and process.args in ("vmdk", "vmx", "vmxf", "vmsd", "vmsn", "vswp", "vmss", "nvram", "vmem") and not process.parent.executable == "/usr/share/qemu/init/qemu-kvm-init" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 ESXI Discovery via Grep + +In Linux environments, tools like 'grep' are used to search through files for specific patterns. Adversaries may exploit these tools to locate and analyze virtual machine files, which are crucial for ESXi environments. The detection rule identifies suspicious use of 'grep' variants targeting VM file extensions, signaling potential reconnaissance or manipulation attempts by threat actors. This rule helps in early detection of such malicious activities by monitoring process execution patterns. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of 'grep', 'egrep', or 'pgrep' with arguments related to VM file extensions such as "vmdk", "vmx", "vmxf", "vmsd", "vmsn", "vswp", "vmss", "nvram", or "vmem". +- Check the parent process of the suspicious 'grep' command to determine if it is a legitimate process or potentially malicious, ensuring it is not "/usr/share/qemu/init/qemu-kvm-init". +- Investigate the user account associated with the process execution to assess if the activity aligns with their typical behavior or if it appears anomalous. +- Examine recent system logs and other security alerts for additional indicators of compromise or related suspicious activities on the host. +- Assess the network activity from the host to identify any unusual connections or data exfiltration attempts that may correlate with the discovery activity. + +### False positive analysis + +- System administrators or automated scripts may use grep to search for VM-related files as part of routine maintenance or monitoring tasks. To handle this, create exceptions for known administrative scripts or processes by excluding specific parent processes or user accounts. +- Backup or snapshot management tools might invoke grep to verify the presence of VM files. Identify these tools and exclude their process names or paths from the detection rule to prevent false alerts. +- Developers or IT staff conducting legitimate audits or inventory checks on VM files may trigger this rule. Consider excluding specific user accounts or groups that are authorized to perform such activities. +- Security tools or monitoring solutions that perform regular checks on VM files could also cause false positives. Whitelist these tools by excluding their executable paths or process names from the rule. + +### Response and remediation + +- Isolate the affected Linux system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, specifically those involving 'grep', 'egrep', or 'pgrep' with VM-related file extensions. +- Conduct a thorough review of the system's recent process execution history and file access logs to identify any unauthorized access or changes to VM files. +- Restore any compromised or altered VM files from a known good backup to ensure system integrity and continuity. +- Implement stricter access controls and permissions on VM-related files to limit exposure to unauthorized users or processes. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Update and enhance monitoring rules to detect similar patterns of suspicious activity, ensuring early detection of future threats.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/discovery_kernel_module_enumeration.toml b/rules/linux/discovery_kernel_module_enumeration.toml index e57a6d27d55..d9c2f985ffa 100644 --- a/rules/linux/discovery_kernel_module_enumeration.toml +++ b/rules/linux/discovery_kernel_module_enumeration.toml @@ -2,7 +2,7 @@ creation_date = "2020/04/23" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -75,6 +75,40 @@ not ( ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Enumeration of Kernel Modules + +Loadable Kernel Modules (LKMs) enhance a Linux kernel's capabilities dynamically, without requiring a system reboot. Adversaries may exploit this by enumerating kernel modules to gather system information or identify vulnerabilities. The detection rule identifies suspicious enumeration activities by monitoring specific processes and arguments associated with module listing commands, while excluding benign parent processes to reduce false positives. + +### Possible investigation steps + +- Review the process details in the alert to identify the specific command used for kernel module enumeration, such as lsmod, modinfo, kmod with list argument, or depmod with --all or -a arguments. +- Examine the process parent name to ensure it is not one of the benign processes listed in the exclusion criteria, such as mkinitramfs, dracut, or systemd, which could indicate a false positive. +- Investigate the user account associated with the process to determine if the activity aligns with expected behavior or if it might indicate unauthorized access. +- Check the timing and frequency of the enumeration activity to assess whether it is part of routine system operations or an anomaly that warrants further investigation. +- Correlate the alert with other security events or logs from the same host to identify any additional suspicious activities or patterns that could suggest a broader attack or compromise. + +### False positive analysis + +- System maintenance tools like mkinitramfs and dracut may trigger the rule during legitimate operations. To handle this, ensure these processes are included in the exclusion list to prevent unnecessary alerts. +- Backup and recovery processes such as rear and casper can cause false positives when they interact with kernel modules. Verify these processes are part of the exclusion criteria to avoid misidentification. +- Disk management and storage tools like lvm2 and mdadm might enumerate kernel modules as part of their normal function. Add these to the exclusion list to reduce false positives. +- Virtualization and container management tools such as vz-start and overlayroot may also enumerate modules. Confirm these are excluded to maintain focus on genuine threats. +- Kernel update and management utilities like dkms and kernel-install can trigger alerts during updates. Ensure these are accounted for in the exclusion list to minimize false alarms. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, specifically those involving unauthorized use of lsmod, modinfo, kmod, or depmod commands. +- Conduct a thorough review of recent system logs and process execution history to identify any unauthorized access or changes made to the system. +- Restore the system from a known good backup if any unauthorized modifications to kernel modules or system files are detected. +- Update and patch the system to the latest security standards to mitigate any known vulnerabilities that could be exploited through kernel modules. +- Implement stricter access controls and monitoring for kernel module management, ensuring only authorized personnel can load or unload modules. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/discovery_linux_hping_activity.toml b/rules/linux/discovery_linux_hping_activity.toml index 526bdb48d37..e978852c1f7 100644 --- a/rules/linux/discovery_linux_hping_activity.toml +++ b/rules/linux/discovery_linux_hping_activity.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_ maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -83,6 +83,41 @@ process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and process.name in ("hping", "hping2", "hping3") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Hping Process Activity + +Hping is a versatile command-line tool used for crafting and analyzing network packets, often employed in network security testing. Adversaries may exploit Hping to perform reconnaissance, such as scanning networks or probing firewalls, to gather system information. The detection rule identifies Hping's execution on Linux systems by monitoring specific process start events, helping to flag potential misuse indicative of discovery tactics. + +### Possible investigation steps + +- Review the process start event details to confirm the execution of Hping, focusing on the process.name field to ensure it matches "hping", "hping2", or "hping3". +- Identify the user account associated with the Hping process by examining the user context in the event data to determine if the activity aligns with expected behavior for that user. +- Analyze the command line arguments used with the Hping process to understand the intent of the execution, such as specific network targets or options that indicate scanning or probing activities. +- Check the timing and frequency of the Hping process execution to assess whether it aligns with routine network testing schedules or if it appears anomalous. +- Investigate the source and destination IP addresses involved in the Hping activity to identify potential targets and assess whether they are internal or external to the organization. +- Correlate the Hping activity with other security events or alerts from the same host or network segment to identify any related suspicious activities or patterns. +- Consult with the system owner or network security team to verify if the Hping activity was authorized as part of legitimate security testing or if it requires further investigation. + +### False positive analysis + +- Routine network testing by IT teams may trigger the rule when using Hping for legitimate purposes. To manage this, create exceptions for known IP addresses or user accounts involved in regular network audits. +- Automated scripts or cron jobs that utilize Hping for monitoring network performance can lead to false positives. Identify these scripts and exclude their execution paths or associated user accounts from the detection rule. +- Security training exercises or penetration testing activities might involve Hping usage. Coordinate with security teams to whitelist these activities by specifying time windows or specific user roles. +- Development or testing environments where Hping is used for application testing can cause alerts. Exclude these environments by filtering based on hostnames or network segments associated with non-production systems. + +### Response and remediation + +- Immediately isolate the affected Linux host from the network to prevent further reconnaissance or potential lateral movement by the adversary. +- Terminate any active Hping processes on the affected host to stop ongoing packet crafting or network probing activities. +- Conduct a thorough review of network logs and firewall configurations to identify any unauthorized access or anomalies that may have been exploited using Hping. +- Perform a comprehensive scan of the affected system for additional indicators of compromise, such as unauthorized user accounts or unexpected changes to system files. +- Reset credentials and review access permissions for accounts on the affected host to ensure no unauthorized access persists. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Update detection and monitoring systems to enhance visibility and alerting for similar reconnaissance activities, ensuring rapid response to future threats.""" [[rule.threat]] diff --git a/rules/linux/discovery_linux_nping_activity.toml b/rules/linux/discovery_linux_nping_activity.toml index 5d217c0f4fb..b1a6e1627ad 100644 --- a/rules/linux/discovery_linux_nping_activity.toml +++ b/rules/linux/discovery_linux_nping_activity.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_ maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -83,6 +83,41 @@ process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and process.name == "nping" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Nping Process Activity + +Nping, a component of the Nmap suite, is used for crafting raw packets, aiding in network diagnostics and security testing. Adversaries may exploit Nping to perform network reconnaissance or denial-of-service attacks by sending crafted packets to probe network services. The detection rule identifies Nping's execution on Linux systems by monitoring process start events, helping to flag potential misuse for malicious network discovery activities. + +### Possible investigation steps + +- Review the process start event details to confirm the execution of Nping, focusing on the process name field to ensure it matches "nping". +- Identify the user account associated with the Nping process execution to determine if it aligns with expected or authorized usage patterns. +- Examine the command line arguments used with Nping to understand the intent of the execution, such as specific network targets or packet types. +- Check the timing and frequency of the Nping execution to assess if it correlates with any known maintenance windows or unusual activity patterns. +- Investigate network logs or traffic data to identify any unusual or unauthorized network scanning or probing activities originating from the host where Nping was executed. +- Correlate the Nping activity with other security alerts or logs from the same host to identify potential indicators of compromise or broader attack patterns. + +### False positive analysis + +- Routine network diagnostics by IT teams using Nping for legitimate purposes can trigger alerts. To manage this, create exceptions for specific user accounts or IP addresses known to perform regular network testing. +- Automated scripts or monitoring tools that incorporate Nping for network health checks may cause false positives. Identify these scripts and whitelist their execution paths or associated processes. +- Security assessments or penetration tests conducted by authorized personnel might involve Nping usage. Coordinate with security teams to schedule these activities and temporarily adjust detection rules or add exceptions for the duration of the tests. +- Development or testing environments where Nping is used for application testing can generate alerts. Exclude these environments from monitoring or adjust the rule to ignore specific hostnames or network segments. +- Training sessions or workshops that include Nping demonstrations can lead to false positives. Notify the security team in advance and apply temporary exceptions for the event duration. + +### Response and remediation + +- Immediately isolate the affected Linux host from the network to prevent further reconnaissance or potential denial-of-service attacks. +- Terminate the Nping process on the affected host to stop any ongoing malicious activity. +- Conduct a thorough review of recent network traffic logs from the affected host to identify any unusual or unauthorized network service discovery attempts. +- Check for any unauthorized changes or installations on the affected host that may indicate further compromise or persistence mechanisms. +- Update and apply network security policies to restrict the use of network diagnostic tools like Nping to authorized personnel only. +- Escalate the incident to the security operations team for further investigation and to determine if the activity is part of a larger attack campaign. +- Enhance monitoring and alerting for similar activities across the network by ensuring that detection rules are in place for unauthorized use of network diagnostic tools.""" [[rule.threat]] diff --git a/rules/linux/discovery_pam_version_discovery.toml b/rules/linux/discovery_pam_version_discovery.toml index e4c58f72f89..825d5c74454 100644 --- a/rules/linux/discovery_pam_version_discovery.toml +++ b/rules/linux/discovery_pam_version_discovery.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -71,6 +71,40 @@ process where host.os.type == "linux" and event.type == "start" and (process.name == "rpm" and process.args == "pam") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Pluggable Authentication Module (PAM) Version Discovery + +Pluggable Authentication Modules (PAM) provide a flexible mechanism for authenticating users on Linux systems. Adversaries may exploit PAM by discovering its version to identify vulnerabilities or backdoor the authentication process with malicious modules. The detection rule identifies suspicious processes querying PAM-related packages, indicating potential reconnaissance or tampering attempts, thus alerting security teams to possible threats. + +### Possible investigation steps + +- Review the process details to confirm the presence of suspicious activity, focusing on processes with names "dpkg", "dpkg-query", or "rpm" and their arguments "libpam-modules" or "pam". +- Check the user account associated with the process to determine if it is a legitimate user or potentially compromised. +- Investigate the parent process to understand the origin of the command execution and assess if it aligns with normal user behavior. +- Analyze recent login attempts and authentication logs to identify any unusual patterns or failed attempts that may indicate unauthorized access attempts. +- Correlate this activity with other alerts or logs from the same host to identify if there are additional indicators of compromise or related suspicious activities. + +### False positive analysis + +- Routine system updates or package management activities may trigger the rule when legitimate processes like dpkg or rpm query PAM-related packages. To manage this, consider creating exceptions for known maintenance windows or trusted administrative scripts. +- Automated configuration management tools, such as Ansible or Puppet, might execute commands that match the rule's criteria. Identify these tools and exclude their processes from triggering alerts by specifying their execution context. +- Security compliance checks or vulnerability assessments often involve querying system packages, including PAM. If these are regularly scheduled and verified, whitelist the associated processes to prevent unnecessary alerts. +- Developers or system administrators testing PAM configurations might inadvertently trigger the rule. Establish a protocol for notifying the security team of such activities in advance, allowing for temporary exceptions during testing periods. +- Custom scripts used for system monitoring or auditing may include commands that match the rule. Review these scripts and, if deemed safe, add them to an exclusion list to reduce false positives. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, specifically those involving 'dpkg', 'dpkg-query', or 'rpm' with arguments related to PAM. +- Conduct a thorough review of PAM configuration files and modules on the affected system to identify and remove any unauthorized or malicious modifications. +- Restore any compromised PAM modules from a known good backup to ensure the integrity of the authentication process. +- Monitor for any additional suspicious activity on the affected system and related systems, focusing on unusual authentication attempts or process executions. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for PAM-related activities across the network to detect similar threats in the future.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/discovery_ping_sweep_detected.toml b/rules/linux/discovery_ping_sweep_detected.toml index 0fa247325c9..56eff74834c 100644 --- a/rules/linux/discovery_ping_sweep_detected.toml +++ b/rules/linux/discovery_ping_sweep_detected.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/04" integration = ["endpoint", "auditd_manager"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -61,6 +61,41 @@ query = ''' event.category:process and host.os.type:linux and event.action:(exec or exec_event or executed or process_started) and event.type:start and process.name:(ping or nping or hping or hping2 or hping3 or nc or ncat or netcat or socat) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Network Scan Executed From Host + +In Linux environments, utilities like ping, netcat, and socat are essential for network diagnostics and communication. However, adversaries can exploit these tools to perform network scans, identifying active hosts and services for further exploitation. The detection rule identifies rapid execution of these utilities, signaling potential misuse for network reconnaissance, by monitoring process initiation events linked to these tools. + +### Possible investigation steps + +- Review the process initiation events to confirm the rapid execution of utilities like ping, netcat, or socat by examining the process.name field in the alert. +- Identify the user account associated with the process execution by checking the user information in the event data to determine if the activity aligns with expected behavior. +- Analyze the command line arguments used with the executed utilities by inspecting the process.command_line field to understand the scope and intent of the network scan. +- Correlate the alert with other recent events on the host by reviewing event timestamps and related process activities to identify any patterns or additional suspicious behavior. +- Check network logs or firewall logs for any unusual outbound connections or traffic patterns originating from the host to assess the potential impact of the network scan. +- Investigate the host's recent login history and user activity to determine if there are signs of unauthorized access or compromise that could explain the network scan activity. + +### False positive analysis + +- Routine network diagnostics by system administrators can trigger alerts. To manage this, create exceptions for known administrator accounts or specific IP addresses frequently used for legitimate network diagnostics. +- Automated monitoring scripts that use these utilities for health checks or performance monitoring may cause false positives. Identify and exclude these scripts by their process names or execution paths. +- Scheduled tasks or cron jobs that involve network utilities for maintenance purposes can be mistaken for network scans. Exclude these tasks by their specific scheduling patterns or associated user accounts. +- Security tools that perform regular network sweeps as part of their functionality might be flagged. Whitelist these tools by their process names or hash values to prevent unnecessary alerts. +- Development or testing environments where network utilities are used for testing purposes can generate false positives. Implement exclusions based on environment-specific identifiers or network segments. + +### Response and remediation + +- Isolate the affected host from the network to prevent further reconnaissance or lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, such as those involving ping, netcat, or socat, to halt ongoing network scans. +- Conduct a thorough review of the host's process logs and network activity to identify any additional indicators of compromise or related malicious activity. +- Reset credentials and review access permissions for accounts that were active on the compromised host to prevent unauthorized access. +- Apply patches and updates to the host's operating system and installed software to mitigate vulnerabilities that could be exploited by adversaries. +- Enhance network monitoring and logging to detect similar reconnaissance activities in the future, ensuring that alerts are configured to notify security teams promptly. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional hosts or systems are affected.""" [[rule.threat]] diff --git a/rules/linux/discovery_private_key_password_searching_activity.toml b/rules/linux/discovery_private_key_password_searching_activity.toml index 13ef862b2a7..32c338e367e 100644 --- a/rules/linux/discovery_private_key_password_searching_activity.toml +++ b/rules/linux/discovery_private_key_password_searching_activity.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -63,6 +63,40 @@ process where host.os.type == "linux" and event.type == "start" and process.command_line like ("*id_dsa*", "*id_rsa*", "*id_ed*", "*id_ecdsa*", "*id_xmss*", "*id_dh*") and process.command_line like ("*/home/*", "*/etc/ssh*", "*/root/*", "/") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Private Key Searching Activity + +In Linux environments, private keys are crucial for secure communications and authentication. Adversaries may exploit this by searching for private keys to gain unauthorized access or escalate privileges. The detection rule identifies suspicious use of the 'find' command targeting key files in sensitive directories, signaling potential malicious intent. This proactive monitoring helps mitigate risks associated with unauthorized key access. + +### Possible investigation steps + +- Review the process details to confirm the 'find' command was executed with parameters targeting private key files, as indicated by the command line containing patterns like "*id_dsa*", "*id_rsa*", etc., and directories such as "/home/", "/etc/ssh", or "/root/". +- Identify the user account associated with the process to determine if the activity aligns with expected behavior for that user or if it suggests potential compromise. +- Check the process's parent process to understand the context in which the 'find' command was executed, which may provide insights into whether this was part of a legitimate script or an unauthorized action. +- Investigate any recent login activity or changes in user privileges for the account involved to assess if there has been any unauthorized access or privilege escalation. +- Examine system logs and other security alerts around the time of the event to identify any correlated suspicious activities or anomalies that might indicate a broader attack campaign. + +### False positive analysis + +- System administrators or automated scripts may use the 'find' command to locate private keys for legitimate maintenance tasks. To handle this, create exceptions for known administrative accounts or scripts that regularly perform these actions. +- Backup processes might search for private keys as part of routine data protection activities. Identify and exclude these processes by specifying their unique command-line patterns or process IDs. +- Security audits or compliance checks often involve scanning for private keys to ensure proper security measures are in place. Exclude these activities by recognizing the specific tools or scripts used during audits. +- Developers or DevOps teams may search for private keys during application deployment or configuration. Establish a list of trusted users or processes involved in these operations and exclude them from triggering alerts. +- Automated configuration management tools like Ansible or Puppet might search for keys as part of their operations. Identify these tools and exclude their specific command-line patterns to prevent false positives. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, particularly those involving the 'find' command searching for private keys. +- Conduct a thorough review of access logs and process execution history to identify any unauthorized access or privilege escalation attempts. +- Change all potentially compromised private keys and associated credentials, ensuring new keys are securely generated and stored. +- Implement stricter access controls and permissions on directories containing private keys to limit exposure to unauthorized users. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Enhance monitoring and alerting for similar activities by ensuring that detection rules are tuned to capture variations of the 'find' command targeting sensitive files.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/discovery_proc_maps_read.toml b/rules/linux/discovery_proc_maps_read.toml index fa5cc29d2ef..f723c431069 100644 --- a/rules/linux/discovery_proc_maps_read.toml +++ b/rules/linux/discovery_proc_maps_read.toml @@ -2,7 +2,7 @@ creation_date = "2024/01/29" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -62,6 +62,40 @@ process.name in ("cat", "grep") and process.args : "/proc/*/maps" and process.en "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious /proc/maps Discovery + +In Linux environments, the `/proc/*/maps` files provide detailed memory mapping of processes, crucial for system diagnostics. However, adversaries exploit this by reading these files to pinpoint memory addresses for malicious activities like code injection. The detection rule identifies suspicious reads of these files by monitoring specific command executions, such as `cat` or `grep`, initiated from common shell environments, flagging potential reconnaissance attempts. + +### Possible investigation steps + +- Review the process details, including the process name and arguments, to confirm if the access to /proc/*/maps was initiated by a legitimate user or application. Pay special attention to the process.name and process.args fields. +- Check the process.entry_leader.name to determine the shell environment from which the command was executed, and assess if this aligns with typical user behavior or known scripts. +- Investigate the user account associated with the process to determine if there are any signs of compromise or unusual activity, such as recent logins from unfamiliar IP addresses or changes in user permissions. +- Examine the parent process and any related child processes to understand the broader context of the command execution, looking for any signs of a script or automated task that might have triggered the alert. +- Correlate this event with other security alerts or logs from the same host or user to identify any patterns or sequences of suspicious activities that could indicate a larger attack or reconnaissance effort. + +### False positive analysis + +- System diagnostics tools may read /proc/*/maps files as part of routine checks. Identify these tools and create exceptions for their processes to avoid unnecessary alerts. +- Developers and system administrators might manually inspect /proc/*/maps during debugging or performance tuning. Establish a list of known users and processes that perform these actions regularly and exclude them from triggering the rule. +- Automated scripts for monitoring or logging purposes could access /proc/*/maps files. Review these scripts and whitelist them if they are verified to be non-malicious. +- Security software might access these files as part of its scanning operations. Confirm the legitimacy of such software and add it to an exception list to prevent false positives. +- Consider the context of the process entry leader. If certain shell environments are used predominantly for legitimate administrative tasks, adjust the rule to reduce sensitivity for those specific environments. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes identified as reading the `/proc/*/maps` files using commands like `cat` or `grep` from unauthorized shell environments. +- Conduct a memory analysis on the affected system to identify any injected code or unauthorized modifications in the process memory. +- Review and audit user accounts and permissions on the affected system to ensure that only authorized users have access to sensitive files and directories. +- Implement stricter access controls and monitoring on `/proc/*/maps` files to limit exposure and detect unauthorized access attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Update and enhance endpoint detection and response (EDR) solutions to improve monitoring and alerting for similar suspicious activities in the future.""" [[rule.threat]] diff --git a/rules/linux/discovery_process_capabilities.toml b/rules/linux/discovery_process_capabilities.toml index cb11c2facc4..d7c4f6674f1 100644 --- a/rules/linux/discovery_process_capabilities.toml +++ b/rules/linux/discovery_process_capabilities.toml @@ -2,7 +2,7 @@ creation_date = "2024/01/09" integration = ["endpoint", "crowdstrike"] maturity = "production" -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -62,6 +62,40 @@ process where host.os.type == "linux" and event.type == "start" and process.name == "getcap" and process.args == "-r" and process.args == "/" and process.args_count == 3 and user.id != "0" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Process Capability Enumeration + +In Linux environments, the `getcap` command is used to list file capabilities, which define specific privileges for executables. Adversaries may exploit this by recursively scanning the filesystem to identify and manipulate capabilities, potentially escalating privileges. The detection rule identifies suspicious use of `getcap` by monitoring for its execution with specific arguments, especially by non-root users, indicating potential misuse. + +### Possible investigation steps + +- Review the alert details to confirm the execution of the `getcap` command with the arguments `-r` and `/`, ensuring the process was initiated by a non-root user (user.id != "0"). +- Identify the user account associated with the process execution to determine if the user has a legitimate reason to perform such actions. +- Examine the process execution history for the identified user to check for any other suspicious activities or commands executed around the same time. +- Investigate the system logs for any signs of privilege escalation attempts or unauthorized access following the execution of the `getcap` command. +- Check for any recent changes to file capabilities on the system that could indicate manipulation by the adversary. +- Assess the system for any other indicators of compromise or related alerts that might suggest a broader attack campaign. + +### False positive analysis + +- System administrators or automated scripts may use the getcap command for legitimate auditing purposes. To handle this, create exceptions for known administrative accounts or scripts that regularly perform capability checks. +- Security tools or monitoring solutions might trigger the rule during routine scans. Identify these tools and exclude their processes from triggering alerts by adding them to an allowlist. +- Developers or testing environments may execute getcap as part of software testing or development processes. Exclude specific user IDs or groups associated with these environments to prevent unnecessary alerts. +- Scheduled maintenance tasks might involve capability enumeration. Document and exclude these tasks by specifying the time frames or user accounts involved in the maintenance activities. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary. +- Terminate any unauthorized or suspicious processes associated with the `getcap` command to halt potential privilege escalation activities. +- Conduct a thorough review of the system's file capabilities using a trusted method to identify any unauthorized changes or suspicious capabilities that may have been set. +- Revert any unauthorized capability changes to their original state to ensure that no elevated privileges are retained by malicious users. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement monitoring for similar `getcap` command executions across the environment to detect and respond to future attempts promptly. +- Review and update access controls and user permissions to ensure that only authorized users have the necessary privileges to execute potentially sensitive commands like `getcap`.""" [[rule.threat]] diff --git a/rules/linux/discovery_pspy_process_monitoring_detected.toml b/rules/linux/discovery_pspy_process_monitoring_detected.toml index a61e6a1a297..1af81c74158 100644 --- a/rules/linux/discovery_pspy_process_monitoring_detected.toml +++ b/rules/linux/discovery_pspy_process_monitoring_detected.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/20" integration = ["auditd_manager"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -60,6 +60,41 @@ sequence by process.pid, host.id with maxspan=5s not process.name == "agentbeat" ] with runs=10 ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Pspy Process Monitoring Detected + +Auditd is a Linux auditing system that tracks system calls, providing insights into process activities. Adversaries exploit tools like pspy to monitor processes via the /proc directory, seeking privilege escalation opportunities without root access. The detection rule identifies suspicious openat syscalls targeting /proc, excluding benign processes, to flag potential misuse of pspy for process discovery. + +### Possible investigation steps + +- Review the process details associated with the alert, focusing on the process.pid and process.name fields to identify the process attempting to access the /proc directory. +- Investigate the host.id to determine if this activity is isolated to a single host or part of a broader pattern across multiple systems. +- Examine the process tree and parent processes of the flagged process to understand how it was initiated and if it is part of a legitimate workflow or potentially malicious activity. +- Check for any recent changes or installations on the host that might explain the presence of a tool like pspy, such as new software installations or updates. +- Correlate the timing of the alert with any other suspicious activities or alerts on the same host to identify potential lateral movement or privilege escalation attempts. +- Verify if the process name is a known benign process that might have been mistakenly excluded from the query, ensuring that the exclusion list is up-to-date and accurate. + +### False positive analysis + +- Frequent scanning by legitimate monitoring tools can trigger the rule. Identify and whitelist these tools by adding their process names to the exclusion list. +- System management scripts that regularly access the /proc directory may cause false positives. Review these scripts and exclude their process names if they are verified as non-threatening. +- Automated backup or security software that interacts with the /proc directory might be flagged. Confirm their legitimacy and add them to the exception list to prevent unnecessary alerts. +- Custom applications developed in-house that require access to the /proc directory for performance monitoring should be reviewed and excluded if they are deemed safe. +- Regularly update the exclusion list to reflect changes in legitimate software and tools used within the organization to minimize false positives. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes identified as using the pspy utility to halt further unauthorized process monitoring. +- Conduct a thorough review of the affected system's /proc directory access logs to identify any other unauthorized access attempts or anomalies. +- Reset credentials and review permissions for any accounts that may have been compromised or used in the attack to prevent further unauthorized access. +- Apply patches and updates to the affected system to address any vulnerabilities that may have been exploited for privilege escalation. +- Enhance monitoring and logging on the affected host to detect any future attempts to access the /proc directory using similar methods. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/discovery_security_file_access_via_common_utility.toml b/rules/linux/discovery_security_file_access_via_common_utility.toml index fdb6eb3c908..0827780f6df 100644 --- a/rules/linux/discovery_security_file_access_via_common_utility.toml +++ b/rules/linux/discovery_security_file_access_via_common_utility.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -69,6 +69,41 @@ process where host.os.type == "linux" and event.type == "start" and "/home/*/.azure/azureProfile.json" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Security File Access via Common Utilities + +In Linux environments, common utilities like `cat`, `grep`, and `less` are essential for file manipulation and viewing. Adversaries exploit these tools to access sensitive security files, aiming to gather system and security configuration data. The detection rule identifies suspicious use of these utilities by monitoring process execution patterns and arguments, flagging attempts to access critical security files, thus helping to thwart potential reconnaissance activities. + +### Possible investigation steps + +- Review the process execution details to identify the specific utility used (e.g., cat, grep, less) and the exact file path accessed, as indicated by the process.name and process.args fields. +- Check the user account associated with the process execution to determine if the access was performed by a legitimate user or a potentially compromised account. +- Investigate the timing and frequency of the access attempt to assess whether it aligns with normal user behavior or indicates suspicious activity. +- Correlate the alert with other security events or logs from the same host to identify any preceding or subsequent suspicious activities, such as unauthorized logins or privilege escalation attempts. +- Examine the host's recent changes or updates to security configurations or user permissions that might explain the access attempt. +- If possible, contact the user or system owner to verify whether the access was intentional and authorized, providing additional context for the investigation. + +### False positive analysis + +- System administrators or automated scripts may frequently access security files for legitimate maintenance or configuration purposes. To handle this, create exceptions for known administrative accounts or specific scripts that regularly perform these actions. +- Security monitoring tools or compliance checks might trigger the rule when scanning security files. Identify these tools and exclude their processes from the rule to prevent unnecessary alerts. +- Backup processes that involve copying or reading security files can be mistaken for suspicious activity. Exclude backup software processes or scheduled tasks that are known to perform these operations. +- Developers or DevOps personnel accessing configuration files for application deployment or troubleshooting might trigger the rule. Establish a list of trusted users or roles and exclude their access patterns from detection. +- Regular system updates or package management operations may involve accessing security-related files. Recognize these update processes and exclude them to avoid false positives during routine maintenance. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule to halt potential reconnaissance activities. +- Conduct a thorough review of the accessed files to determine if any sensitive information was exposed or altered. +- Change credentials and access tokens for any compromised accounts, especially those related to AWS, GCP, or Azure, to prevent unauthorized access. +- Implement stricter access controls and permissions on sensitive security files to limit exposure to only necessary users and processes. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on the broader network. +- Enhance monitoring and logging for similar activities to improve detection and response times for future incidents.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/discovery_sudo_allowed_command_enumeration.toml b/rules/linux/discovery_sudo_allowed_command_enumeration.toml index e0ec108809d..3fb1447da08 100644 --- a/rules/linux/discovery_sudo_allowed_command_enumeration.toml +++ b/rules/linux/discovery_sudo_allowed_command_enumeration.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -64,6 +64,39 @@ process where host.os.type == "linux" and event.type == "start" and process.args_count == 2 and process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and not process.args == "dpkg" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Sudo Command Enumeration Detected + +The sudo command in Linux environments allows users to execute commands with elevated privileges, typically as the root user. Attackers may exploit this by using the `sudo -l` command to list permissible commands, potentially identifying paths to escalate privileges. The detection rule identifies this behavior by monitoring for the execution of `sudo -l` from common shell environments, flagging potential misuse for privilege escalation. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of the `sudo -l` command, ensuring the process name is "sudo" and the arguments include "-l" with an argument count of 2. +- Identify the parent process of the `sudo` command to determine the shell environment used, checking if it matches any of the specified shells like "bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", or "fish". +- Investigate the user account that executed the `sudo -l` command to assess if the activity aligns with their typical behavior or if it appears suspicious. +- Check for any recent changes in user permissions or sudoers configuration that might indicate unauthorized modifications. +- Correlate this event with other logs or alerts to identify any subsequent suspicious activities that might suggest privilege escalation attempts. + +### False positive analysis + +- System administrators frequently use the sudo -l command to verify their permissions. To reduce noise, consider excluding specific user accounts or groups known for legitimate use. +- Automated scripts or configuration management tools may execute sudo -l as part of routine checks. Identify these scripts and exclude their execution paths or parent processes from the rule. +- Some software installations or updates might invoke sudo -l to check permissions. Monitor and document these processes, then create exceptions for known benign software. +- Developers or testers might use sudo -l during debugging or testing phases. Coordinate with development teams to identify and exclude these activities when they are part of approved workflows. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker. +- Review the sudoers file on the affected system to identify any unauthorized or suspicious entries that may have been added or modified, and revert any changes to their original state. +- Terminate any suspicious processes initiated by the user who executed the `sudo -l` command, especially if they are not part of normal operations. +- Reset the password of the user account involved in the alert to prevent further unauthorized access. +- Conduct a thorough review of system logs to identify any additional suspicious activity or commands executed by the user, and assess the scope of potential compromise. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. +- Implement additional monitoring and alerting for similar `sudo -l` command executions across the environment to enhance detection and response capabilities.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/discovery_suid_sguid_enumeration.toml b/rules/linux/discovery_suid_sguid_enumeration.toml index 131a1e897c6..810fecf6686 100644 --- a/rules/linux/discovery_suid_sguid_enumeration.toml +++ b/rules/linux/discovery_suid_sguid_enumeration.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/24" integration = ["endpoint"] maturity = "production" -updated_date = "2024/09/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -67,6 +67,39 @@ process.name == "find" and process.args : "-perm" and process.args : ( (process.args : "/usr/bin/pkexec" and process.args : "-xdev" and process.args_count == 7) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 SUID/SGUID Enumeration Detected + +In Linux, SUID and SGID permissions allow programs to execute with elevated privileges, potentially exposing systems to privilege escalation if misconfigured. Adversaries exploit this by searching for binaries with these permissions to gain unauthorized access. The detection rule identifies suspicious use of the "find" command to locate such binaries, flagging potential misuse by monitoring specific command arguments and execution contexts. + +### Possible investigation steps + +- Review the process execution details to confirm the use of the "find" command with SUID/SGID permission arguments by checking the process.name and process.args fields. +- Identify the user and group context in which the command was executed by examining the user.Ext.real.id and group.Ext.real.id fields to determine if the command was run by a non-root user. +- Analyze the command's arguments to understand the scope of the search, focusing on the process.args field to see if specific directories or files were targeted. +- Check for any other suspicious activities or commands executed by the same user or process around the same time to identify potential follow-up actions or privilege escalation attempts. +- Investigate the system for any newly created or modified files with SUID/SGID permissions that could indicate successful privilege escalation or preparation for future attacks. + +### False positive analysis + +- System administrators or security tools may use the find command with SUID/SGID arguments for legitimate audits. To handle this, create exceptions for known administrative users or specific scripts that regularly perform these checks. +- Automated scripts or cron jobs might execute the find command with these arguments as part of routine maintenance tasks. Identify these scripts and exclude them from monitoring by specifying their process paths or user IDs. +- Some legitimate software installations or updates might temporarily use the find command with SUID/SGID arguments. Monitor installation logs and exclude these processes by correlating them with known software update activities. +- Developers or testers might use the find command in development environments to test security configurations. Exclude these environments from the rule by specifying their hostnames or IP addresses in the exception list. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, particularly those involving the "find" command with SUID/SGID arguments. +- Conduct a thorough review of the system's SUID/SGID binaries to identify any misconfigurations or unauthorized changes. Remove or correct permissions on any binaries that are not required to have elevated privileges. +- Implement additional monitoring on the affected system to detect any further attempts to exploit SUID/SGID binaries, focusing on process execution and permission changes. +- Escalate the incident to the security operations team for a deeper forensic analysis to determine the scope of the compromise and identify any other affected systems. +- Apply patches and updates to the system and any vulnerable applications to mitigate known vulnerabilities that could be exploited through SUID/SGID binaries. +- Review and enhance access controls and privilege management policies to minimize the risk of privilege escalation through misconfigured binaries in the future.""" [[rule.threat]] diff --git a/rules/linux/discovery_suspicious_memory_grep_activity.toml b/rules/linux/discovery_suspicious_memory_grep_activity.toml index 83efd842f34..cc556ba4db0 100644 --- a/rules/linux/discovery_suspicious_memory_grep_activity.toml +++ b/rules/linux/discovery_suspicious_memory_grep_activity.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -39,6 +39,41 @@ process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2") and process.name in ("grep", "egrep", "fgrep", "rgrep") and process.args in ("[stack]", "[vdso]", "[heap]") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Memory grep Activity + +In Linux, the `/proc/*/maps` file reveals a process's memory layout, crucial for debugging but exploitable by attackers for malicious activities like code injection. Adversaries may use tools like `grep` to scan these memory maps for specific segments, aiding in process manipulation. The detection rule identifies such suspicious `grep` usage by monitoring process initiation events, focusing on arguments that indicate potential memory mapping exploration. + +### Possible investigation steps + +- Review the process initiation event details to confirm the presence of grep or its variants (egrep, fgrep, rgrep) in the process name field. +- Examine the process arguments to verify if they include memory segments like [stack], [vdso], or [heap], which could indicate an attempt to explore memory mappings. +- Identify the user or service account associated with the suspicious process to determine if the activity aligns with expected behavior or if it might be unauthorized. +- Check the parent process of the suspicious grep activity to understand the context in which it was executed and assess if it was initiated by a legitimate application or script. +- Investigate any recent changes or anomalies in the system logs around the time of the alert to identify potential indicators of compromise or related suspicious activities. +- Correlate this event with other security alerts or logs from the same host to identify patterns or a broader attack campaign. + +### False positive analysis + +- System administrators or developers may use grep to inspect memory maps for legitimate debugging or performance tuning. To handle this, create exceptions for known user accounts or specific scripts that perform these tasks regularly. +- Automated monitoring tools might use grep to check memory usage patterns as part of routine health checks. Identify these tools and exclude their process IDs or command patterns from triggering alerts. +- Security software or intrusion detection systems could use grep to scan memory maps as part of their normal operations. Verify these processes and whitelist them to prevent unnecessary alerts. +- Developers running test scripts that include memory map analysis might trigger this rule. Document these scripts and add them to an exception list to avoid false positives. +- Some legitimate applications may use grep to read memory maps for configuration or optimization purposes. Monitor these applications and adjust the rule to exclude their specific command-line arguments. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement or further exploitation. +- Terminate any suspicious processes identified by the detection rule, specifically those involving `grep` or its variants accessing memory maps. +- Conduct a memory dump and forensic analysis of the affected system to identify any injected code or unauthorized modifications. +- Review and audit access logs to determine if there was unauthorized access to the `/proc/*/maps` files and identify any potential data exfiltration. +- Apply patches and updates to the operating system and applications to mitigate known vulnerabilities that could be exploited for similar attacks. +- Implement stricter access controls and monitoring on sensitive files and directories, such as `/proc/*/maps`, to prevent unauthorized access. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/discovery_suspicious_which_command_execution.toml b/rules/linux/discovery_suspicious_which_command_execution.toml index a480c04a7ae..bcaa43b910d 100644 --- a/rules/linux/discovery_suspicious_which_command_execution.toml +++ b/rules/linux/discovery_suspicious_which_command_execution.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -46,6 +46,40 @@ and process.args in ("nmap", "nc", "ncat", "netcat", nc.traditional", "gcc", "g+ process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") */ ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious which Enumeration + +The `which` command in Linux environments is typically used to locate the executable path of a command. Adversaries may exploit this utility to identify installed software that can aid in privilege escalation or lateral movement. The detection rule flags unusual usage patterns, such as excessive arguments, which may indicate malicious enumeration. It filters out benign scenarios, focusing on potential threats by examining process attributes and parent-child relationships. + +### Possible investigation steps + +- Review the process details to confirm the command line arguments used with the which command, focusing on whether the args_count is unusually high and if the arguments are related to known enumeration or exploitation tools. +- Examine the parent process of the which command to determine if it is a legitimate process or if it is associated with suspicious activity, especially if it is not one of the excluded parent names or paths. +- Investigate the user account associated with the process to determine if it is a legitimate user or if there are signs of compromise, such as unusual login times or locations. +- Check for any other recent alerts or logs related to the same host or user that might indicate a broader attack pattern or ongoing compromise. +- Assess the network activity from the host to identify any connections to known malicious IP addresses or unusual outbound traffic that could suggest lateral movement or data exfiltration. + +### False positive analysis + +- Processes initiated by the 'jem' parent process may trigger false positives. To handle this, add 'jem' to the list of exceptions in the rule configuration. +- Executions within containerized environments, such as those under '/vz/root/' or '/var/lib/docker/', are often benign. Exclude these paths from the rule to reduce noise. +- The '--tty-only' argument is typically used in legitimate scenarios. Consider adding this argument to the exception list to prevent unnecessary alerts. +- If the rule is noisy due to common utilities like 'nmap', 'nc', 'gcc', or 'socat' being used with shell interpreters like 'bash' or 'zsh', refine the rule by excluding these combinations. +- Regularly review and update the list of exceptions based on the evolving environment and usage patterns to maintain an effective balance between detection and false positive reduction. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes associated with the `which` command that have an unusually high number of arguments, as identified by the detection rule. +- Conduct a thorough review of the system's installed software and utilities to identify any unauthorized or suspicious installations that could be leveraged for privilege escalation. +- Analyze the process tree and parent-child relationships of the flagged `which` command execution to identify potential malicious scripts or binaries that initiated the command. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised. +- Implement enhanced monitoring and logging for the `which` command and similar enumeration tools to detect future misuse. +- Review and update access controls and permissions to ensure that only authorized users have the ability to execute potentially sensitive commands and utilities.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/discovery_unusual_user_enumeration_via_id.toml b/rules/linux/discovery_unusual_user_enumeration_via_id.toml index 860c3e226b4..379b03f4a52 100644 --- a/rules/linux/discovery_unusual_user_enumeration_via_id.toml +++ b/rules/linux/discovery_unusual_user_enumeration_via_id.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/29" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -59,6 +59,40 @@ sequence by host.id, process.parent.entity_id with maxspan=1s process.name == "id" and process.args_count == 2 and not (process.parent.name == "rpm" or process.parent.args : "/var/tmp/rpm-tmp*")] with runs=20 ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 User Privilege Enumeration via id + +The `id` command in Linux environments is used to display user identity information, including user and group IDs. Adversaries may exploit this command in enumeration scripts to gather extensive user privilege data rapidly, which can aid in lateral movement or privilege escalation. The detection rule identifies suspicious activity by flagging rapid, repeated executions of the `id` command, suggesting potential misuse by scripts like LinPEAS or LinEnum. + +### Possible investigation steps + +- Review the alert details to identify the specific host.id and process.parent.entity_id associated with the suspicious activity. +- Examine the parent process of the 'id' command executions to determine if it is a known or legitimate process, and check for any unusual or unexpected parent process names or arguments. +- Investigate the timeline of events on the affected host around the time of the alert to identify any other suspicious activities or related processes that may indicate a broader attack or script execution. +- Check the user account associated with the process executions to verify if it has legitimate access and if there are any signs of compromise or misuse. +- Look for any additional indicators of compromise on the host, such as unauthorized file modifications, network connections, or other unusual command executions, to assess the scope of potential malicious activity. + +### False positive analysis + +- System management scripts or automated tasks may execute the id command frequently for legitimate purposes. Review the parent process to determine if it is a known management tool or script. +- Software installation or update processes might trigger the rule if they use the id command to verify user permissions. Consider excluding processes with parent names like rpm or similar package managers. +- Custom scripts developed in-house for system monitoring or auditing could inadvertently match the rule's criteria. Identify these scripts and add exceptions for their parent process entity IDs. +- Security tools or compliance checks that perform regular user enumeration might cause false positives. Verify the source of these tools and exclude them if they are part of a trusted security suite. +- In environments with high user account turnover, scripts that manage user accounts might execute the id command in rapid succession. Evaluate these scripts and exclude them if they are part of routine account management. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes associated with the parent process identified in the alert to halt further enumeration activities. +- Conduct a thorough review of the parent process and its associated scripts to determine if they are legitimate or malicious. +- If malicious activity is confirmed, perform a comprehensive scan of the system for additional indicators of compromise, such as unauthorized user accounts or altered system files. +- Reset credentials for any user accounts that may have been exposed or compromised during the enumeration activity. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network. +- Implement enhanced monitoring and logging for similar enumeration activities to improve detection and response capabilities for future incidents.""" [[rule.threat]] diff --git a/rules/linux/discovery_virtual_machine_fingerprinting.toml b/rules/linux/discovery_virtual_machine_fingerprinting.toml index 62990271aa5..b3683e3aff7 100644 --- a/rules/linux/discovery_virtual_machine_fingerprinting.toml +++ b/rules/linux/discovery_virtual_machine_fingerprinting.toml @@ -2,7 +2,7 @@ creation_date = "2020/04/27" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -82,6 +82,41 @@ event.category:process and host.os.type:linux and event.type:(start or process_s "/proc/ide/hd0/model") and not user.name:root ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Virtual Machine Fingerprinting + +Virtual Machine Fingerprinting involves identifying characteristics of a virtual environment, often to tailor attacks or evade detection. Adversaries exploit this by querying system files for hardware details, a tactic seen in malware like Pupy RAT. The detection rule flags non-root users accessing specific Linux paths indicative of VM queries, signaling potential reconnaissance activities. + +### Possible investigation steps + +- Review the process execution details to identify the non-root user involved in accessing the specified paths, focusing on the user.name field. +- Examine the process.args field to determine which specific file paths were accessed, as this can indicate the type of virtual machine information being targeted. +- Investigate the parent process and command line arguments to understand the context of the process initiation and whether it aligns with legitimate user activity. +- Check for any related alerts or logs around the same timeframe to identify potential patterns or repeated attempts at virtual machine fingerprinting. +- Assess the system for any signs of compromise or unauthorized access, particularly focusing on the presence of known malware like Pupy RAT or similar threats. +- Correlate the findings with MITRE ATT&CK framework references (TA0007, T1082) to understand the broader tactics and techniques potentially in use by the adversary. + +### False positive analysis + +- Non-root users running legitimate scripts or applications that query system files for hardware information may trigger the rule. Review the context of the process and user activity to determine if it aligns with expected behavior. +- System administrators or developers using automated tools for inventory or monitoring purposes might access these paths. Consider creating exceptions for known tools or scripts that are verified as safe. +- Security or compliance audits conducted by non-root users could inadvertently match the rule's criteria. Document and whitelist these activities if they are part of regular operations. +- Development environments where virtual machine detection is part of testing processes may cause false positives. Identify and exclude these environments from the rule's scope if they are consistently flagged. +- Regularly review and update the list of exceptions to ensure that only verified and necessary exclusions are maintained, minimizing the risk of overlooking genuine threats. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further reconnaissance or potential lateral movement by the adversary. +- Terminate any suspicious processes identified in the alert that are attempting to access the specified system files, especially those not initiated by the root user. +- Conduct a thorough review of recent user activity and process logs to identify any unauthorized access or anomalies that may indicate further compromise. +- Reset credentials for any non-root users involved in the alert to prevent unauthorized access, and review user permissions to ensure least privilege principles are enforced. +- Deploy endpoint detection and response (EDR) tools to monitor for similar suspicious activities and enhance visibility into system processes and user actions. +- 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 the specific file paths and processes identified in the query to detect and respond to future attempts at virtual machine fingerprinting.""" [[rule.threat]] diff --git a/rules/linux/discovery_yum_dnf_plugin_detection.toml b/rules/linux/discovery_yum_dnf_plugin_detection.toml index 751c8c67492..0cac6758ff0 100644 --- a/rules/linux/discovery_yum_dnf_plugin_detection.toml +++ b/rules/linux/discovery_yum_dnf_plugin_detection.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -68,6 +68,39 @@ process where host.os.type == "linux" and event.type == "start" and "/usr/lib/python*/site-packages/dnf-plugins/*", "/etc/dnf/plugins/*", "/etc/dnf/dnf.conf" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Yum/DNF Plugin Status Discovery + +Yum and DNF are package managers for Linux, managing software installations and updates. They support plugins to extend functionality, which can be targeted by attackers to maintain persistence. Adversaries may use commands to identify active plugins, potentially altering them for malicious purposes. The detection rule identifies suspicious use of the `grep` command to search for plugin configurations, signaling possible reconnaissance or tampering attempts. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of the `grep` command with arguments related to plugin configurations, such as `/etc/yum.conf` or `/etc/dnf/dnf.conf`, to verify the alert's accuracy. +- Examine the user account associated with the process execution to determine if it is a legitimate user or potentially compromised account. +- Check the system's command history for any preceding or subsequent commands executed by the same user to identify potential patterns or further suspicious activity. +- Investigate any recent changes to the plugin configuration files located in directories like `/etc/yum/pluginconf.d/` or `/etc/dnf/plugins/` to detect unauthorized modifications. +- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related malicious activity. + +### False positive analysis + +- System administrators or automated scripts may use the grep command to verify plugin configurations during routine maintenance. To handle this, create exceptions for known administrative scripts or user accounts that regularly perform these checks. +- Security audits or compliance checks might involve scanning for plugin configurations to ensure they are correctly set up. Exclude these activities by identifying and whitelisting the specific processes or tools used for such audits. +- Developers or IT staff might search for plugin configurations while troubleshooting or developing new features. Consider excluding processes initiated by trusted development environments or specific user groups involved in these activities. +- Monitoring tools that perform regular checks on system configurations could trigger this rule. Identify these tools and add them to an exclusion list to prevent false alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker. +- Terminate any suspicious processes related to the `grep` command that are actively searching for YUM/DNF plugin configurations. +- Conduct a thorough review of the YUM and DNF plugin configuration files and directories for unauthorized changes or additions, specifically in the paths `/etc/yum.conf`, `/usr/lib/yum-plugins/*`, `/etc/yum/pluginconf.d/*`, `/usr/lib/python*/site-packages/dnf-plugins/*`, `/etc/dnf/plugins/*`, and `/etc/dnf/dnf.conf`. +- Restore any altered plugin configurations from a known good backup to ensure system integrity. +- Implement file integrity monitoring on the YUM and DNF configuration directories to detect future unauthorized changes. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised. +- Review and update access controls and permissions for users and processes interacting with YUM and DNF configurations to minimize the risk of unauthorized access.""" [[rule.threat]] diff --git a/rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml b/rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml index e07e6d73e79..31cc81b317c 100644 --- a/rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml +++ b/rules/linux/execution_curl_cve_2023_38545_heap_overflow.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/11" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -86,6 +86,39 @@ and ( process.parent.executable like ("/vz/root/*", "/var/rudder/*") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 curl CVE-2023-38545 Exploitation + +Curl is a command-line tool used for transferring data with URLs, often employed in scripts and automation. A vulnerability in versions up to 8.3 allows a buffer overflow during SOCKS5 proxy handshakes, potentially leading to arbitrary code execution. Adversaries might exploit this by crafting specific command lines or environment variables. The detection rule identifies suspicious curl usage patterns, such as unusual command lengths and specific proxy settings, to flag potential exploitation attempts. + +### Possible investigation steps + +- Review the process command line arguments and environment variables to confirm the presence of SOCKS5 proxy settings, such as "--socks5-hostname", "--proxy", "--preproxy", or environment variables like "http_proxy=socks5h://*", "HTTPS_PROXY=socks5h://*", and "ALL_PROXY=socks5h://*". +- Check the length of the command line to ensure it exceeds 255 characters, as this is a key indicator of potential exploitation attempts. +- Investigate the parent process of the curl execution to determine if it is one of the known benign processes like "cf-agent", "agent-run", "agent-check", "rudder", "agent-inventory", or "cf-execd", or if it originates from directories like "/opt/rudder/*", "/vz/root/*", or "/var/rudder/*". +- Examine the network activity associated with the curl process to identify any unusual or unauthorized data transfers, especially those involving SOCKS5 proxies. +- Cross-reference the alert with other security logs and alerts to identify any correlated suspicious activities or patterns that might indicate a broader attack campaign. + +### False positive analysis + +- Legitimate administrative tools like cf-agent, agent-run, and rudder may trigger the rule due to their use of curl with SOCKS5 proxies. To mitigate this, add these tools to the exception list in the rule configuration. +- Automated scripts running in environments like /opt/rudder or /var/rudder might be flagged. Exclude these paths from the rule to prevent false positives. +- Processes executed within virtualized environments, such as those under /vz/root, can be mistakenly identified. Consider excluding these directories if they are known to host benign activities. +- Regularly review and update the list of known safe parent processes and directories to ensure that legitimate operations are not disrupted by the detection rule. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary. +- Terminate any suspicious curl processes identified by the detection rule to halt potential exploitation activities. +- Upgrade curl to version 8.4 or later on all affected systems to patch the vulnerability and prevent future exploitation attempts. +- Review and reset any potentially compromised environment variables, such as http_proxy, HTTPS_PROXY, and ALL_PROXY, to ensure they are not being used maliciously. +- Conduct a thorough investigation of the affected system for signs of further compromise, such as unauthorized access or changes to critical files, and take appropriate remediation actions. +- Notify the security team and relevant stakeholders about the incident for awareness and further analysis, ensuring that any findings are documented for future reference. +- Enhance monitoring and logging for curl usage and SOCKS5 proxy connections to improve detection capabilities for similar threats in the future.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/execution_egress_connection_from_entrypoint_in_container.toml b/rules/linux/execution_egress_connection_from_entrypoint_in_container.toml index 63d52d93d78..0958a57f9ee 100644 --- a/rules/linux/execution_egress_connection_from_entrypoint_in_container.toml +++ b/rules/linux/execution_egress_connection_from_entrypoint_in_container.toml @@ -2,7 +2,7 @@ creation_date = "2024/07/10" integration = ["endpoint"] maturity = "production" -updated_date = "2024/07/10" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -44,6 +44,40 @@ sequence by host.id with maxspan=3s ) )] by process.parent.entity_id ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Egress Connection from Entrypoint in Container + +Containers, often used for deploying applications, start with an entrypoint script that initializes the environment. Adversaries may exploit this by embedding malicious commands to initiate unauthorized network connections, potentially breaching security boundaries. The detection rule monitors for processes named `entrypoint.sh` followed by suspicious network activity, flagging attempts to connect to external IPs, thus identifying potential threats. + +### Possible investigation steps + +- Review the process details for the `entrypoint.sh` script execution, focusing on the `process.entity_id` and `host.id` to understand the context of the container where the script was executed. +- Examine the network connection attempt details, particularly the `destination.ip`, to determine if the IP address is known to be malicious or associated with suspicious activity. +- Check the container's Dockerfile or image configuration to verify if the `entrypoint.sh` script is expected and whether it contains any unauthorized modifications or additions. +- Investigate the parent process of the network connection attempt using `process.parent.entity_id` to identify if there are any other suspicious processes or activities linked to the same parent. +- Correlate the event with other logs or alerts from the same `host.id` to identify any additional indicators of compromise or related suspicious activities within the same timeframe. + +### False positive analysis + +- Legitimate application updates or installations may trigger the rule if they involve network connections from the entrypoint script. To handle this, identify and whitelist specific applications or update processes that are known to perform such actions. +- Automated configuration management tools might execute scripts that initiate network connections as part of their normal operations. Exclude these tools by specifying their process names or parent entity IDs in the rule exceptions. +- Containers designed to perform network diagnostics or monitoring could naturally attempt connections to external IPs. Review and exclude these containers by their image names or specific entrypoint scripts. +- Development or testing environments often run scripts that connect to external services for integration testing. Consider excluding these environments by tagging them appropriately and adjusting the rule to ignore these tags. +- Scheduled maintenance scripts that run periodically and require network access might be flagged. Document these scripts and create exceptions based on their execution schedule or specific network destinations. + +### Response and remediation + +- Immediately isolate the affected container to prevent further unauthorized network connections. This can be done by stopping the container or disconnecting it from the network. +- Conduct a thorough review of the `entrypoint.sh` script within the container to identify and remove any malicious commands or scripts that may have been injected. +- Analyze the network traffic logs to identify any external IP addresses that the container attempted to connect to. Block these IPs at the firewall level to prevent future connections. +- Check for any signs of lateral movement or attempts to escape the container to the host system. If detected, escalate to the security team for a comprehensive investigation. +- Restore the container from a known good backup if available, ensuring that the restored version is free from any malicious modifications. +- Implement additional monitoring on the affected host and container environment to detect any similar suspicious activities in the future. +- Report the incident to the appropriate internal security team or incident response team for further analysis and to update threat intelligence databases.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/execution_file_execution_followed_by_deletion.toml b/rules/linux/execution_file_execution_followed_by_deletion.toml index 4547501ded4..9793c814549 100644 --- a/rules/linux/execution_file_execution_followed_by_deletion.toml +++ b/rules/linux/execution_file_execution_followed_by_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/28" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -68,6 +68,41 @@ sequence by host.id, user.id with maxspan=1m file.path : ("/dev/shm/*", "/run/shm/*", "/tmp/*", "/var/tmp/*", "/run/*", "/var/run/*", "/var/www/*", "/proc/*/fd/*")] by file.name ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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, Execution and Self-Deletion in Suspicious Directory + +In Linux environments, temporary directories like `/tmp` and `/var/tmp` are often used for storing transient files. Adversaries exploit these directories to execute malicious payloads and erase traces by creating, running, and deleting files swiftly. The detection rule identifies this pattern by monitoring file creation, execution, and deletion events within these directories, flagging suspicious activities that align with common malware behaviors. + +### Possible investigation steps + +- Review the file creation event details, focusing on the file path and name to determine if it matches known malicious patterns or if it is a legitimate file. +- Examine the process execution event, paying attention to the process name and parent process name to identify if the execution was initiated by a suspicious or unauthorized shell. +- Investigate the user.id and host.id associated with the events to determine if the activity aligns with expected user behavior or if it indicates potential compromise. +- Check for any network activity or connections initiated by the process to identify potential data exfiltration or communication with command and control servers. +- Analyze the deletion event to confirm whether the file was removed by a legitimate process or if it was part of a self-deletion mechanism used by malware. +- Correlate these events with any other alerts or logs from the same host or user to identify patterns or additional indicators of compromise. + +### False positive analysis + +- Development and testing activities in temporary directories can trigger false positives. Exclude specific paths or processes related to known development tools or scripts that frequently create, execute, and delete files in these directories. +- Automated system maintenance scripts may perform similar actions. Identify and whitelist these scripts by their process names or paths to prevent unnecessary alerts. +- Backup or deployment tools like Veeam or Spack may use temporary directories for legitimate operations. Add exceptions for these tools by specifying their executable paths or process names. +- Temporary file operations by legitimate applications such as web servers or database services might be flagged. Monitor and exclude these applications by their known behaviors or specific file paths they use. +- Regular system updates or package installations can involve temporary file handling. Recognize and exclude these activities by identifying the associated package manager processes or update scripts. + +### Response and remediation + +- Isolate the affected host immediately to prevent further spread of the potential malware. Disconnect it from the network to contain the threat. +- Terminate any suspicious processes identified in the alert, especially those executed from temporary directories, to stop any ongoing malicious activity. +- Conduct a thorough examination of the affected directories (/tmp, /var/tmp, etc.) to identify and remove any remaining malicious files or scripts. +- Restore any affected systems from a known good backup to ensure that no remnants of the malware remain. +- Update and patch the affected system to close any vulnerabilities that may have been exploited by the threat actor. +- Enhance monitoring and logging on the affected host and similar systems to detect any recurrence of this behavior, focusing on file creation, execution, and deletion events in temporary directories. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems may be compromised.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/execution_interpreter_tty_upgrade.toml b/rules/linux/execution_interpreter_tty_upgrade.toml index 3df209bbcc9..5019e5be9ec 100644 --- a/rules/linux/execution_interpreter_tty_upgrade.toml +++ b/rules/linux/execution_interpreter_tty_upgrade.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/08" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -68,6 +68,39 @@ process where host.os.type == "linux" and event.type == "start" and process.args_count == 4) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Upgrade of Non-interactive Shell + +In Linux environments, attackers often seek to enhance a basic reverse shell to a fully interactive shell to gain a more robust foothold. This involves using tools like `stty` or `script` to manipulate terminal settings, enabling features like command history and job control. The detection rule identifies such activities by monitoring specific process executions and arguments, flagging potential misuse indicative of an upgrade attempt. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of `stty` or `script` commands with the specific arguments outlined in the detection rule, such as `stty raw -echo` or `script -qc /dev/null`. +- Examine the parent process of the flagged `stty` or `script` command to determine how the shell was initially spawned and identify any potentially malicious scripts or binaries. +- Check the user account associated with the process execution to assess if it aligns with expected user behavior or if it indicates potential compromise. +- Investigate the network connections associated with the host at the time of the alert to identify any suspicious remote connections that could be indicative of a reverse shell. +- Review historical process execution and login records for the user and host to identify any patterns of suspicious activity or previous attempts to establish a reverse shell. + +### False positive analysis + +- System administrators or legitimate users may use stty or script commands for routine maintenance or troubleshooting, which can trigger the rule. To manage this, create exceptions for known user accounts or specific maintenance windows. +- Automated scripts or cron jobs that utilize stty or script for legitimate purposes might be flagged. Review these scripts and whitelist them by process hash or command line pattern to prevent false positives. +- Development environments where developers frequently use stty or script for testing purposes can generate alerts. Consider excluding specific development machines or user groups from the rule to reduce noise. +- Monitoring tools or security solutions that simulate shell upgrades for testing or auditing purposes may inadvertently trigger the rule. Identify these tools and add them to an exception list based on their process name or execution path. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement by the attacker. +- Terminate any suspicious processes identified by the detection rule, specifically those involving `stty` or `script` with the flagged arguments, to disrupt the attacker's attempt to upgrade the shell. +- Conduct a thorough review of the affected system's logs and process history to identify any additional malicious activities or compromised accounts. +- Reset credentials for any user accounts that were active during the time of the alert to prevent unauthorized access using potentially compromised credentials. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited by the attacker. +- Enhance monitoring and logging on the affected host and similar systems to detect any future attempts to upgrade non-interactive shells or other suspicious activities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be affected.""" [[rule.threat]] diff --git a/rules/linux/execution_nc_listener_via_rlwrap.toml b/rules/linux/execution_nc_listener_via_rlwrap.toml index 9298d4d3de7..36b6dd20033 100644 --- a/rules/linux/execution_nc_listener_via_rlwrap.toml +++ b/rules/linux/execution_nc_listener_via_rlwrap.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/08" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -73,6 +73,40 @@ process where host.os.type == "linux" and event.type == "start" and process.name == "rlwrap" and process.args in ("nc", "ncat", "netcat", "nc.openbsd", "socat") and process.args : "*l*" and process.args_count >= 4 ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Netcat Listener Established via rlwrap + +Netcat, a versatile networking tool, can establish connections for data transfer or remote shell access. When combined with rlwrap, which enhances command-line input, it can create a more stable reverse shell environment. Adversaries exploit this to maintain persistent access. The detection rule identifies such misuse by monitoring rlwrap's execution with netcat-related arguments, signaling potential unauthorized activity. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of rlwrap with netcat-related arguments by examining the process.name and process.args fields. +- Check the process start time and correlate it with any known scheduled tasks or user activity to determine if the execution was expected or authorized. +- Investigate the source IP address and port used in the netcat connection to identify potential external connections or data exfiltration attempts. +- Analyze the user account associated with the process execution to verify if the account has a history of similar activities or if it has been compromised. +- Examine any related network traffic logs to identify unusual patterns or connections that coincide with the alert, focusing on the host where the process was executed. +- Look for any additional processes spawned by the netcat listener to detect further malicious activity or persistence mechanisms. + +### False positive analysis + +- Development and testing environments may frequently use rlwrap with netcat for legitimate purposes, such as testing network applications or scripts. To manage this, create exceptions for specific user accounts or IP addresses known to be involved in development activities. +- System administrators might use rlwrap with netcat for troubleshooting or network diagnostics. Identify and exclude these activities by setting up rules that recognize the specific command patterns or user roles associated with administrative tasks. +- Automated scripts or cron jobs that utilize rlwrap and netcat for routine maintenance or monitoring can trigger false positives. Review and whitelist these scripts by their unique process identifiers or command structures to prevent unnecessary alerts. +- Educational or training environments where rlwrap and netcat are used for learning purposes can generate alerts. Implement exceptions based on the environment's network segment or user group to reduce noise from these benign activities. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate the rlwrap and netcat processes on the affected host to disrupt the reverse shell connection. +- Conduct a forensic analysis of the affected system to identify any additional malicious activities or persistence mechanisms. +- Review and secure any compromised accounts or credentials that may have been used or accessed during the incident. +- Apply security patches and updates to the affected system to mitigate any exploited vulnerabilities. +- Enhance monitoring and logging on the affected host and network to detect similar activities in the future. +- Report the incident to the appropriate internal security team or external authorities if required, following organizational protocols.""" [[rule.threat]] diff --git a/rules/linux/execution_netcon_from_rwx_mem_region_binary.toml b/rules/linux/execution_netcon_from_rwx_mem_region_binary.toml index 4caaf8cd36e..b2a0eb82410 100644 --- a/rules/linux/execution_netcon_from_rwx_mem_region_binary.toml +++ b/rules/linux/execution_netcon_from_rwx_mem_region_binary.toml @@ -2,7 +2,7 @@ creation_date = "2024/03/13" integration = ["auditd_manager", "endpoint"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -61,6 +61,41 @@ sample by host.id, process.pid, process.name [network where host.os.type == "linux" and event.type == "start" and event.action == "connection_attempted" and not cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1")] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Network Connection from Binary with RWX Memory Region + +In Linux environments, the `mprotect()` system call adjusts memory permissions, potentially enabling read, write, and execute (RWX) access. Adversaries exploit this to execute malicious code in memory, often followed by network connections to exfiltrate data or communicate with command-and-control servers. The detection rule identifies such behavior by monitoring for RWX memory changes and subsequent network activity, flagging suspicious processes for further analysis. + +### Possible investigation steps + +- Review the process details using the process.pid and process.name fields to identify the binary that requested RWX memory permissions. +- Investigate the context of the mprotect() syscall by examining the process's command line arguments and parent process to understand its origin and purpose. +- Analyze the network connection details, focusing on the destination.ip field, to determine if the connection was made to a known malicious IP or an unusual external server. +- Check the process's execution history and any associated files or scripts to identify potential malicious payloads or scripts that may have been executed. +- Correlate the event with other security logs or alerts from the same host.id to identify any related suspicious activities or patterns. +- Assess the risk and impact by determining if any sensitive data was accessed or exfiltrated during the network connection attempt. + +### False positive analysis + +- Legitimate software updates or patches may temporarily use RWX memory regions. Monitor the specific process names and verify if they are associated with known update mechanisms. Consider adding these processes to an exception list if they are verified as safe. +- Development tools and environments often require RWX permissions for debugging or testing purposes. Identify these tools and exclude them from the rule if they are part of a controlled and secure development environment. +- Certain system services or daemons, like custom web servers or network services, might use RWX memory regions for legitimate reasons. Review the process names and network destinations to determine if they are part of expected system behavior, and exclude them if confirmed. +- Security software or monitoring tools may exhibit this behavior as part of their normal operation. Validate these processes and consider excluding them if they are recognized as part of your security infrastructure. +- Custom scripts or automation tasks that require dynamic code execution might trigger this rule. Ensure these scripts are reviewed and approved, then exclude them if they are deemed non-threatening. + +### Response and remediation + +- Isolate the affected host from the network immediately to prevent further data exfiltration or communication with potential command-and-control servers. +- Terminate the suspicious process identified by the detection rule to halt any ongoing malicious activity. +- Conduct a memory dump of the affected system to capture the current state for forensic analysis, focusing on the RWX memory regions. +- Review and analyze the network logs to identify any external IP addresses or domains the process attempted to connect to, and block these on the network firewall. +- Patch and update the affected system to the latest security updates to mitigate any known vulnerabilities that could have been exploited. +- Implement stricter memory protection policies to prevent processes from obtaining RWX permissions unless absolutely necessary. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if this is part of a larger attack campaign.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/execution_network_event_post_compilation.toml b/rules/linux/execution_network_event_post_compilation.toml index 366caed4d72..0883155d452 100644 --- a/rules/linux/execution_network_event_post_compilation.toml +++ b/rules/linux/execution_network_event_post_compilation.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/28" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -63,6 +63,41 @@ sequence by host.id with maxspan=1m process.name in ("simpleX", "conftest", "ssh", "python", "ispnull", "pvtui") )] by process.name ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Network Connection via Recently Compiled Executable + +In Linux environments, compiling and executing programs is routine for development. However, adversaries exploit this by compiling malicious code to establish reverse shells, enabling remote control. The detection rule identifies this threat by monitoring sequences of compilation, execution, and network activity, flagging unusual connections that deviate from typical patterns, thus indicating potential compromise. + +### Possible investigation steps + +- Review the process execution details to identify the compiler used (e.g., gcc, g++, cc) and examine the arguments passed during the compilation to understand the nature of the compiled code. +- Investigate the file creation event associated with the linker (ld) to determine the output executable file and its location on the system. +- Analyze the subsequent process execution to identify the newly compiled executable and verify its legitimacy by checking its hash against known malware databases. +- Examine the network connection attempt details, focusing on the destination IP address, to determine if it is associated with known malicious activity or command-and-control servers. +- Check the process name involved in the network connection attempt to ensure it is not a commonly used legitimate process, as specified in the query exclusions (e.g., simpleX, conftest, ssh, python, ispnull, pvtui). +- Correlate the timing of the compilation, execution, and network connection events to assess if they align with typical user behavior or indicate suspicious activity. + +### False positive analysis + +- Development activities involving frequent compilation and execution of new code can trigger false positives. To manage this, exclude specific user accounts or directories commonly used for legitimate development work. +- Automated build systems or continuous integration pipelines may compile and execute code regularly. Identify and exclude these processes or IP addresses from monitoring to prevent false alerts. +- Legitimate software updates or installations that involve compiling source code can be mistaken for malicious activity. Exclude known update processes or package managers from the rule. +- Network connections to internal or trusted IP addresses that are not part of the typical exclusion list might be flagged. Update the exclusion list to include these trusted IP ranges. +- Certain legitimate applications that compile and execute code as part of their normal operation, such as IDEs or scripting environments, should be identified and excluded from the rule to reduce noise. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified in the alert, especially those related to the recently compiled executable and any associated network connections. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized user accounts or scheduled tasks. +- Remove any malicious executables or scripts identified during the investigation from the system to prevent re-execution. +- Reset credentials for any accounts that may have been compromised, focusing on those with elevated privileges. +- Update and patch the affected system to close any vulnerabilities that may have been exploited by the attacker. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/execution_perl_tty_shell.toml b/rules/linux/execution_perl_tty_shell.toml index e8399decc4a..2aefc2e52ef 100644 --- a/rules/linux/execution_perl_tty_shell.toml +++ b/rules/linux/execution_perl_tty_shell.toml @@ -2,7 +2,7 @@ creation_date = "2020/04/16" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -70,6 +70,40 @@ query = ''' event.category:process and host.os.type:linux and event.type:(start or process_started) and process.name:perl and process.args:("exec \"/bin/sh\";" or "exec \"/bin/dash\";" or "exec \"/bin/bash\";") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Interactive Terminal Spawned via Perl + +Perl, a versatile scripting language, can execute system commands, making it a target for adversaries seeking to escalate privileges or maintain persistence. Attackers may exploit Perl to spawn interactive terminals, transforming basic shells into robust command interfaces. The detection rule identifies such activity by monitoring process events on Linux systems, specifically when Perl executes shell commands, signaling potential misuse. + +### Possible investigation steps + +- Review the process event logs to confirm the presence of a Perl process with arguments indicating the execution of a shell, such as "exec \\"/bin/sh\\";", "exec \\"/bin/dash\\";", or "exec \\"/bin/bash\\";". +- Identify the user account associated with the Perl process to determine if it aligns with expected activity or if it suggests unauthorized access. +- Examine the parent process of the Perl execution to understand how the Perl script was initiated and assess if it correlates with legitimate user activity or a potential compromise. +- Check for any network connections or data transfers initiated by the Perl process to identify possible exfiltration or communication with external command and control servers. +- Investigate any recent changes to user accounts, permissions, or scheduled tasks that might indicate privilege escalation or persistence mechanisms associated with the Perl activity. +- Correlate the event with other security alerts or logs from the same host to identify patterns or additional indicators of compromise that could suggest a broader attack campaign. + +### False positive analysis + +- System maintenance scripts that use Perl to execute shell commands may trigger this rule. Review and whitelist known maintenance scripts by adding exceptions for specific script paths or process arguments. +- Automated deployment tools that utilize Perl for executing shell commands can cause false positives. Identify these tools and exclude their specific process arguments or execution paths from the detection rule. +- Development environments where Perl is used for testing or debugging purposes might inadvertently spawn interactive terminals. Consider excluding processes initiated by known development user accounts or within specific development directories. +- Backup or monitoring scripts that rely on Perl to perform system checks or data collection could be flagged. Analyze these scripts and create exceptions based on their unique process arguments or execution context. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious Perl processes identified by the detection rule to halt any ongoing malicious activity. +- Conduct a thorough review of the affected system's logs and process history to identify any additional indicators of compromise or related malicious activity. +- Reset credentials and review access permissions for any accounts that may have been compromised or used in the attack. +- Restore the affected system from a known good backup to ensure any malicious changes are removed. +- Implement additional monitoring on the affected host and network to detect any further attempts to exploit Perl for spawning interactive terminals. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist.""" [[rule.threat]] diff --git a/rules/linux/execution_potential_hack_tool_executed.toml b/rules/linux/execution_potential_hack_tool_executed.toml index c1c2f7c4f02..1f10787bfc8 100644 --- a/rules/linux/execution_potential_hack_tool_executed.toml +++ b/rules/linux/execution_potential_hack_tool_executed.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_ maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/08" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -81,6 +81,41 @@ process.name in~ ( "linux-exploit-suggester-2.pl", "linux-exploit-suggester.sh", "panix.sh" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Linux Hack Tool Launched + +Linux environments often utilize various tools for system administration and security testing. While these tools serve legitimate purposes, adversaries can exploit them for malicious activities, such as unauthorized access or data exfiltration. The detection rule identifies suspicious process executions linked to known hacking tools, flagging potential misuse by monitoring specific process names and actions indicative of exploitation attempts. + +### Possible investigation steps + +- Review the process name that triggered the alert to determine if it matches any known hacking tools listed in the query, such as "crackmapexec" or "sqlmap". +- Check the user account associated with the process execution to assess if it is a legitimate user or potentially compromised. +- Investigate the source and destination IP addresses involved in the process execution to identify any unusual or unauthorized network activity. +- Examine the command line arguments used during the process execution to understand the intent and scope of the activity. +- Correlate the event with other logs or alerts from the same host to identify any patterns or additional suspicious activities. +- Verify if the process execution aligns with any scheduled tasks or known administrative activities to rule out false positives. + +### False positive analysis + +- System administrators and security teams often use tools like "john", "hashcat", and "hydra" for legitimate security testing and password recovery. To reduce false positives, create exceptions for these tools when used by authorized personnel or during scheduled security assessments. +- Blue team exercises may involve the use of exploitation frameworks such as "msfconsole" and "msfvenom". Implement a process to whitelist these activities when they are part of a sanctioned security drill. +- Network scanning tools like "zenmap" and "nuclei" are frequently used for network mapping and vulnerability assessments. Establish a baseline of normal usage patterns and exclude these from alerts when they match expected behavior. +- Web enumeration tools such as "gobuster" and "dirbuster" might be used by web developers for testing purposes. Coordinate with development teams to identify legitimate use cases and exclude these from triggering alerts. +- Regularly review and update the list of excluded processes to ensure that only non-threatening activities are exempted, maintaining a balance between security and operational efficiency. + +### Response and remediation + +- Immediately isolate the affected Linux host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the alert, such as those listed in the detection query, to halt potential malicious activities. +- Conduct a thorough review of system logs and process execution history to identify any additional indicators of compromise or lateral movement attempts. +- Restore the affected system from a known good backup if any unauthorized changes or data exfiltration are confirmed. +- Update and patch all software and applications on the affected host to mitigate vulnerabilities that could be exploited by the identified tools. +- Implement stricter access controls and monitoring on the affected host to prevent unauthorized execution of potentially malicious tools in the future. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/execution_potentially_overly_permissive_container_creation.toml b/rules/linux/execution_potentially_overly_permissive_container_creation.toml index d70d112d89b..5c3b93f27ec 100644 --- a/rules/linux/execution_potentially_overly_permissive_container_creation.toml +++ b/rules/linux/execution_potentially_overly_permissive_container_creation.toml @@ -2,7 +2,7 @@ creation_date = "2024/07/10" integration = ["endpoint"] maturity = "production" -updated_date = "2024/11/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -55,6 +55,47 @@ query = ''' host.os.type:linux and event.category:process and event.type:start and event.action:exec and process.name:docker and process.args:(run and --privileged) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Privileged Docker Container Creation + +Docker containers are lightweight, portable units that package applications and their dependencies. The `--privileged` flag grants containers extensive host access, posing security risks. Adversaries exploit this to escalate privileges or escape containers. The detection rule identifies unusual privileged container creation by monitoring specific process actions and arguments, helping to flag potential threats early. + +### Possible investigation steps + +- Review the alert details to confirm the presence of the `--privileged` flag in the process arguments, as indicated by the query field `process.args:(run and --privileged)`. +- Identify the parent process of the Docker command by examining the `event.category:process` and `event.type:start` fields to determine if it originates from an unusual or unauthorized source. +- Check the user account associated with the Docker process to verify if it has legitimate access and permissions to create privileged containers. +- Investigate the timeline of events leading up to the container creation by reviewing related logs and events around the `event.action:exec` to identify any suspicious activities or patterns. +- Assess the container's configuration and running processes to determine if any unauthorized or potentially harmful applications are being executed within the container. +- Correlate the alert with other security events or alerts in the environment to identify potential indicators of compromise or broader attack patterns. + +### False positive analysis + +- Routine administrative tasks may trigger the rule if system administrators use the --privileged flag for legitimate container management. To handle this, identify and document these tasks, then create exceptions for known administrative processes. +- Automated deployment scripts that require elevated privileges might also cause false positives. Review these scripts and whitelist them by specifying the parent process or script name in the exclusion criteria. +- Development environments often use privileged containers for testing purposes. To reduce noise, exclude processes originating from known development machines or user accounts. +- Some monitoring or security tools may use privileged containers for legitimate purposes. Verify these tools and add them to the exception list to prevent unnecessary alerts. +- Regularly review and update the exclusion list to ensure it reflects current operational practices and does not inadvertently allow malicious activity. + +### Response and remediation + +- Immediately isolate the affected container to prevent further interaction with the host system. This can be done by stopping the container using `docker stop `. + +- Review and revoke any unnecessary permissions or access rights granted to the container. Ensure that the `--privileged` flag is not used unless absolutely necessary. + +- Conduct a thorough investigation of the container's filesystem and running processes to identify any malicious activity or unauthorized changes. Use tools like `docker exec` to inspect the container's environment. + +- Check for any signs of container escape or host compromise by reviewing system logs and monitoring for unusual activity on the host machine. + +- If a compromise is confirmed, initiate a full incident response procedure, including forensic analysis and system restoration from clean backups. + +- Update and patch the Docker daemon and any related software to the latest versions to mitigate known vulnerabilities that could be exploited. + +- Enhance monitoring and alerting for privileged container creation by integrating additional security tools or services that provide real-time threat intelligence and anomaly detection.""" [[rule.threat]] diff --git a/rules/linux/execution_process_started_in_shared_memory_directory.toml b/rules/linux/execution_process_started_in_shared_memory_directory.toml index f3f896a29d3..357478ce610 100644 --- a/rules/linux/execution_process_started_in_shared_memory_directory.toml +++ b/rules/linux/execution_process_started_in_shared_memory_directory.toml @@ -2,7 +2,7 @@ creation_date = "2022/05/10" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -74,6 +74,42 @@ user.id == "0" and process.executable : ("/dev/shm/*", "/run/shm/*", "/var/run/* not process.executable : ("/var/run/docker/*", "/var/run/utsns/*", "/var/run/s6/*", "/var/run/cloudera-scm-agent/*", "/var/run/argo/argoexec") and not process.parent.command_line : "/usr/bin/runc init" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Binary Executed from Shared Memory Directory + +Shared memory directories in Linux, such as /dev/shm and /run/shm, are designed for efficient inter-process communication. However, adversaries exploit these directories to execute binaries stealthily, often as root, bypassing traditional security measures. The detection rule identifies such anomalies by monitoring for root-executed binaries in these directories, excluding known legitimate processes, thus flagging potential backdoor activities. + +### Possible investigation steps + +- Review the process executable path to confirm it resides in a shared memory directory such as /dev/shm, /run/shm, /var/run, or /var/lock, and verify it is not part of the known exclusions like /var/run/docker or /var/run/utsns. +- Investigate the parent process of the suspicious executable to understand the context of its execution, focusing on the command line used, especially if it does not match the exclusion pattern /usr/bin/runc init. +- Check the process's creation time and correlate it with any other suspicious activities or alerts around the same timeframe to identify potential patterns or related incidents. +- Analyze the binary file in question for any known malicious signatures or unusual characteristics using tools like file integrity checkers or antivirus solutions. +- Review system logs and audit logs for any unauthorized access or privilege escalation attempts that might have led to the execution of the binary as root. +- Investigate the user account activity associated with user.id "0" to ensure there are no signs of compromise or misuse of root privileges. +- If possible, isolate the affected system to prevent further potential malicious activity while the investigation is ongoing. + +### False positive analysis + +- Docker-related processes can trigger false positives when binaries are executed from shared memory directories. To mitigate this, exclude paths like /var/run/docker/* from the detection rule. +- Processes related to container orchestration tools such as Kubernetes might also cause false positives. Exclude paths like /var/run/utsns/* and /var/run/s6/* to prevent these. +- Cloudera services may execute binaries from shared memory directories as part of their normal operations. Exclude /var/run/cloudera-scm-agent/* to avoid false alerts. +- Argo workflows might execute binaries in these directories. Exclude /var/run/argo/argoexec to reduce false positives. +- Legitimate use of /usr/bin/runc init as a parent process can be excluded to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the threat actor. +- Terminate any suspicious processes running from the shared memory directories (/dev/shm, /run/shm, /var/run, /var/lock) to halt potential malicious activity. +- Conduct a thorough review of the system's process tree and logs to identify any additional malicious binaries or scripts that may have been executed or are scheduled to run. +- Remove any unauthorized binaries or scripts found in the shared memory directories and other critical system paths to eliminate persistence mechanisms. +- Restore the system from a known good backup if the integrity of the system is compromised and cannot be assured through manual remediation. +- Implement enhanced monitoring and alerting for any future execution of binaries from shared memory directories, ensuring that legitimate processes are whitelisted appropriately. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/linux/execution_python_tty_shell.toml b/rules/linux/execution_python_tty_shell.toml index 5dd00e41674..fd3e8ca50c8 100644 --- a/rules/linux/execution_python_tty_shell.toml +++ b/rules/linux/execution_python_tty_shell.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/08" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -66,6 +66,40 @@ process where host.os.type == "linux" and event.type == "start" and event.action "fish") and process.args : "*sh" and process.args_count == 1 and process.parent.args_count == 1) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Interactive Terminal Spawned via Python + +Python's ability to spawn interactive terminals is a powerful feature often used for legitimate administrative tasks. However, adversaries can exploit this to escalate a basic reverse shell into a fully interactive terminal, enhancing their control over a compromised system. The detection rule identifies such abuse by monitoring processes where Python spawns a shell, focusing on specific patterns in process arguments and parent-child process relationships, indicating potential malicious activity. + +### Possible investigation steps + +- Review the process tree to understand the parent-child relationship, focusing on the parent process named "python*" and the child process that is a shell (e.g., bash, sh, zsh). +- Examine the command-line arguments of the parent Python process to identify the use of "pty.spawn" and the presence of the "-c" flag, which may indicate an attempt to spawn an interactive terminal. +- Check the process start event details, including the timestamp and user context, to determine if the activity aligns with expected administrative tasks or if it appears suspicious. +- Investigate the source IP address and user account associated with the process to assess if they are known and authorized entities within the network. +- Look for any related alerts or logs that might indicate prior suspicious activity, such as initial access vectors or other execution attempts, to build a timeline of events. +- Correlate this activity with any recent changes or incidents reported on the host to determine if this is part of a larger attack or an isolated event. + +### False positive analysis + +- Administrative scripts or automation tools that use Python to manage system processes may trigger this rule. To handle this, identify and whitelist specific scripts or tools that are known to perform legitimate tasks. +- Developers or system administrators using Python for interactive debugging or system management might inadvertently match the rule's criteria. Consider excluding processes initiated by trusted user accounts or within specific directories associated with development or administration. +- Scheduled tasks or cron jobs that utilize Python to execute shell commands could be mistaken for malicious activity. Review and exclude these tasks by specifying their unique process arguments or parent-child process relationships. +- Security tools or monitoring solutions that leverage Python for executing shell commands as part of their normal operation may also trigger this rule. Identify these tools and create exceptions based on their process signatures or execution context. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious Python processes identified in the alert, especially those spawning shell processes, to disrupt the attacker's control. +- Conduct a thorough review of the affected system for any additional signs of compromise, such as unauthorized user accounts, scheduled tasks, or modified system files. +- Reset credentials for any accounts accessed from the compromised host to prevent further unauthorized access. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Enhance monitoring and logging on the affected host and network to detect any similar activities in the future, focusing on process creation and network connections. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/linux/execution_python_webserver_spawned.toml b/rules/linux/execution_python_webserver_spawned.toml index 9f0f14b0134..3420984428c 100644 --- a/rules/linux/execution_python_webserver_spawned.toml +++ b/rules/linux/execution_python_webserver_spawned.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/08" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -68,6 +68,41 @@ process where host.os.type == "linux" and event.type == "start" and ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Web Server Spawned via Python + +Python's built-in HTTP server module allows quick web server deployment, often used for testing or file sharing. Adversaries exploit this to exfiltrate data or facilitate lateral movement within networks. The detection rule identifies processes starting a Python-based server, focusing on command patterns and shell usage, to flag potential misuse on Linux systems. + +### Possible investigation steps + +- Review the process details to confirm the presence of a Python-based web server by checking the process name and arguments, specifically looking for "python" with "http.server" or "SimpleHTTPServer". +- Investigate the user account associated with the process to determine if it is a known or expected user for running such services. +- Examine the command line used to start the process for any unusual or suspicious patterns, especially if it involves shell usage like "bash" or "sh" with the command line containing "python -m http.server". +- Check the network activity from the host to identify any unusual outbound connections or data transfers that could indicate data exfiltration. +- Correlate the event with other logs or alerts from the same host to identify any preceding or subsequent suspicious activities that might suggest lateral movement or further exploitation attempts. +- Assess the host's security posture and recent changes to determine if there are any vulnerabilities or misconfigurations that could have been exploited to spawn the web server. + +### False positive analysis + +- Development and testing environments often use Python's HTTP server for legitimate purposes such as serving static files or testing web applications. To manage this, create exceptions for known development servers by excluding specific hostnames or IP addresses. +- Automated scripts or cron jobs may start a Python web server for routine tasks like file distribution within a controlled environment. Identify these scripts and exclude their execution paths or user accounts from the detection rule. +- Educational or training sessions might involve participants using Python's HTTP server to learn web technologies. Exclude these activities by setting time-based exceptions during scheduled training periods. +- System administrators might use Python's HTTP server for quick file transfers or troubleshooting. Document these use cases and exclude the associated user accounts or process command lines from triggering alerts. +- Internal tools or utilities developed in-house may rely on Python's HTTP server for functionality. Review these tools and exclude their specific command patterns or execution contexts from the detection rule. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further data exfiltration or lateral movement. +- Terminate the suspicious Python process identified by the detection rule to stop the unauthorized web server. +- Conduct a forensic analysis of the affected system to identify any data that may have been accessed or exfiltrated and to determine the initial access vector. +- Review and secure any exposed credentials or sensitive data that may have been compromised during the incident. +- Apply patches and updates to the affected system and any related software to mitigate vulnerabilities that may have been exploited. +- Implement network segmentation to limit the ability of unauthorized processes to communicate across the network. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation and recovery actions are taken.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/execution_remote_code_execution_via_postgresql.toml b/rules/linux/execution_remote_code_execution_via_postgresql.toml index 67ad46d0a1e..86eb35a058e 100644 --- a/rules/linux/execution_remote_code_execution_via_postgresql.toml +++ b/rules/linux/execution_remote_code_execution_via_postgresql.toml @@ -2,7 +2,7 @@ creation_date = "2022/06/20" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -68,6 +68,40 @@ event.action in ("exec", "exec_event", "fork", "fork_event") and user.name == "p process.parent.command_line like "*BECOME-SUCCESS-*" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Code Execution via Postgresql + +PostgreSQL, a robust open-source database system, can be exploited by attackers to execute arbitrary code if they gain unauthorized access or exploit vulnerabilities like SQL injection. Adversaries may leverage command execution capabilities to perform malicious actions. The detection rule identifies suspicious processes initiated by the PostgreSQL user, focusing on shell executions that resemble command injection patterns, while excluding legitimate operations, to flag potential threats. + +### Possible investigation steps + +- Review the process details to confirm the presence of suspicious shell executions by the PostgreSQL user, focusing on processes with arguments containing "*sh" and "echo*". +- Check the parent process information to determine if the process was initiated by a known legitimate service, such as "puppet", or if it includes "BECOME-SUCCESS-" in the command line, which are excluded from the rule. +- Investigate the source of the PostgreSQL access to identify if it originated from an unauthorized or unusual IP address or user account. +- Analyze the timeline of events leading up to and following the alert to identify any patterns or additional suspicious activities that may indicate a broader attack. +- Correlate the alert with other security events or logs from the same host or network segment to assess if there are related indicators of compromise or ongoing threats. + +### False positive analysis + +- Puppet processes may trigger false positives due to their legitimate use of shell commands. To mitigate this, ensure that puppet-related processes are excluded by verifying that process.parent.name is set to "puppet". +- Automation tools that use shell scripts for configuration management might be flagged. Review and exclude these by checking for specific command patterns that are known to be safe, such as those containing "BECOME-SUCCESS". +- Scheduled maintenance scripts executed by the postgres user could be misidentified as threats. Identify these scripts and add them to an exclusion list based on their command line patterns. +- Regular database backup operations that involve shell commands might be mistakenly flagged. Document these operations and exclude them by matching their specific command line arguments. +- Custom monitoring scripts that execute shell commands under the postgres user should be reviewed and excluded if they are verified as non-malicious. + +### Response and remediation + +- Immediately isolate the affected PostgreSQL server from the network to prevent further unauthorized access or malicious actions. +- Terminate any suspicious processes identified by the detection rule to halt potential malicious activities. +- Conduct a thorough review of the PostgreSQL server logs to identify any unauthorized access attempts or successful exploitations, focusing on the timeframes around the detected events. +- Reset credentials for the PostgreSQL user and any other potentially compromised accounts to prevent further unauthorized access. +- Apply the latest security patches and updates to the PostgreSQL server to mitigate known vulnerabilities that could be exploited. +- Implement network segmentation to limit access to the PostgreSQL server, ensuring only authorized systems and users can connect. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/execution_shell_openssl_client_or_server.toml b/rules/linux/execution_shell_openssl_client_or_server.toml index 4333ff0ccd9..3ae5383ced2 100644 --- a/rules/linux/execution_shell_openssl_client_or_server.toml +++ b/rules/linux/execution_shell_openssl_client_or_server.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/08" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -66,6 +66,40 @@ process where host.os.type == "linux" and event.type == "start" and event.action ) and not process.parent.executable in ("/pro/xymon/client/ext/awsXymonCheck.sh", "/opt/antidot-svc/nrpe/plugins/check_cert") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Openssl Client or Server Activity + +OpenSSL is a widely-used toolkit for implementing secure communication via SSL/TLS protocols. In Linux environments, it can function as a client or server to encrypt data transmissions. Adversaries may exploit OpenSSL to establish encrypted channels for data exfiltration or command and control. The detection rule identifies suspicious OpenSSL usage by monitoring process execution patterns, specifically targeting atypical client-server interactions, while excluding known benign processes. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of the "openssl" process with arguments indicating client or server activity, such as "s_client" with "-connect" or "s_server" with "-port". +- Check the parent process of the "openssl" execution to determine if it is a known benign process or if it is potentially suspicious, especially if it is not in the excluded list (e.g., "/pro/xymon/client/ext/awsXymonCheck.sh", "/opt/antidot-svc/nrpe/plugins/check_cert"). +- Investigate the network connections established by the "openssl" process to identify the remote server's IP address and port, and assess whether these are known or potentially malicious. +- Analyze the timing and frequency of the "openssl" executions to determine if they align with normal operational patterns or if they suggest unusual or unauthorized activity. +- Correlate the "openssl" activity with other security events or logs to identify any related suspicious behavior, such as data exfiltration attempts or command and control communications. + +### False positive analysis + +- Known benign processes such as "/pro/xymon/client/ext/awsXymonCheck.sh" and "/opt/antidot-svc/nrpe/plugins/check_cert" are already excluded to reduce false positives. Ensure these paths are accurate and up-to-date in your environment. +- Regularly review and update the list of excluded parent processes to include any additional internal scripts or monitoring tools that frequently use OpenSSL for legitimate purposes. +- Monitor for any internal applications or services that may use OpenSSL in a similar manner and consider adding them to the exclusion list if they are verified as non-threatening. +- Implement logging and alerting to track the frequency and context of OpenSSL usage, which can help identify patterns that are consistently benign and warrant exclusion. +- Engage with system administrators to understand routine OpenSSL usage patterns in your environment, which can inform further refinement of the detection rule to minimize false positives. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further data exfiltration or command and control activities. +- Terminate the suspicious OpenSSL process identified by the alert to halt any ongoing unauthorized encrypted communications. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unusual network connections or unauthorized file access. +- Review and update firewall rules to block unauthorized outbound connections from the affected system, focusing on the ports and IP addresses involved in the suspicious activity. +- Reset credentials and review access permissions for accounts on the affected system to prevent unauthorized access. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems. +- Implement enhanced monitoring and logging for OpenSSL usage across the network to detect similar activities in the future, ensuring that alerts are promptly reviewed and acted upon.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/execution_shell_via_background_process.toml b/rules/linux/execution_shell_via_background_process.toml index 1b18cd14333..1785aac5b1c 100644 --- a/rules/linux/execution_shell_via_background_process.toml +++ b/rules/linux/execution_shell_via_background_process.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/08" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -64,6 +64,41 @@ process where host.os.type == "linux" and event.type == "start" and process.name in ("setsid", "nohup") and process.args : "*/dev/tcp/*0>&1*" and process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Reverse Shell via Background Process + +In Linux environments, background processes can be manipulated to establish reverse shells, allowing adversaries to gain remote access. By exploiting shell commands to open network sockets, attackers can create backdoor connections. The detection rule identifies suspicious executions of background processes, like 'setsid' or 'nohup', with arguments indicating socket activity in '/dev/tcp', often initiated by common shell interpreters. This helps in flagging potential reverse shell activities for further investigation. + +### Possible investigation steps + +- Review the process details to confirm the presence of suspicious arguments, specifically looking for '/dev/tcp' in the process.args field, which indicates an attempt to open a network socket. +- Identify the parent process by examining the process.parent.name field to determine if it is one of the common shell interpreters like 'bash', 'dash', 'sh', etc., which could suggest a script-based execution. +- Check the user context under which the process was executed to assess if it aligns with expected user behavior or if it indicates potential compromise of a user account. +- Investigate the network activity associated with the host to identify any unusual outbound connections that could correlate with the reverse shell attempt. +- Correlate the event with other security alerts or logs from the same host to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern. +- Review historical data for similar process executions on the host to determine if this is an isolated incident or part of a recurring pattern. + +### False positive analysis + +- Legitimate administrative scripts may use background processes with network socket activity for maintenance tasks. Review the script's purpose and source to determine if it is authorized. +- Automated monitoring tools might execute commands that match the rule's criteria. Identify these tools and consider excluding their specific process names or paths from the rule. +- Development environments often run test scripts that open network connections. Verify the development context and exclude known development-related processes to reduce noise. +- Backup or synchronization software may use similar techniques to transfer data. Confirm the software's legitimacy and add exceptions for its processes if necessary. +- System updates or package management tools might trigger alerts when installing or updating software. Monitor these activities and whitelist trusted update processes. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious background processes identified by the alert, specifically those involving 'setsid' or 'nohup' with '/dev/tcp' in their arguments. +- Conduct a thorough review of the affected system's process and network activity logs to identify any additional indicators of compromise or lateral movement. +- Reset credentials for any accounts that were active on the affected system to prevent unauthorized access using potentially compromised credentials. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Implement network segmentation to limit the ability of compromised systems to communicate with critical infrastructure or sensitive data repositories. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/linux/execution_shell_via_child_tcp_utility_linux.toml b/rules/linux/execution_shell_via_child_tcp_utility_linux.toml index dcbcb5da900..ffb033bbdd6 100644 --- a/rules/linux/execution_shell_via_child_tcp_utility_linux.toml +++ b/rules/linux/execution_shell_via_child_tcp_utility_linux.toml @@ -2,7 +2,7 @@ creation_date = "2023/11/02" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -69,6 +69,41 @@ sequence by host.id, process.entity_id with maxspan=5s (process.args : ("-i", "-l")) or (process.parent.name == "socat" and process.parent.args : "*exec*") )] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Reverse Shell via Child + +Reverse shells are a technique where attackers gain remote access to a system by initiating a connection from the target back to the attacker's machine. This is often achieved using shell processes like bash or socat. Adversaries exploit this by executing commands remotely, bypassing firewalls. The detection rule identifies such activity by monitoring for network events followed by suspicious shell process executions, focusing on unusual command-line arguments and parent-child process relationships. + +### Possible investigation steps + +- Review the network event details to identify the source and destination IP addresses involved in the connection attempt or acceptance. Pay special attention to any external IP addresses that are not part of the internal network. +- Examine the process execution details, focusing on the command-line arguments used by the shell process. Look for unusual or suspicious arguments such as "-i" or "-l" that may indicate interactive or login shells. +- Investigate the parent-child process relationship, especially if the parent process is "socat" with arguments containing "exec". This could suggest an attempt to execute a reverse shell. +- Check the timeline of events to determine if the network event and shell process execution occurred within a short time frame (maxspan=5s), which may indicate a coordinated attack. +- Correlate the alert with any other recent suspicious activities on the host, such as unauthorized access attempts or changes in system configurations, to assess the broader context of the potential threat. +- Verify the legitimacy of the involved processes and connections by consulting with system owners or reviewing system documentation to rule out any false positives due to legitimate administrative activities. + +### False positive analysis + +- Legitimate administrative scripts or tools that use shell processes with interactive flags may trigger the rule. To manage this, identify and document these scripts, then create exceptions for their specific command-line arguments or parent processes. +- Automated maintenance tasks or cron jobs that involve shell execution with similar command-line arguments can be mistaken for reverse shell activity. Review these tasks and exclude them by specifying their unique process names or arguments. +- Development or testing environments where developers frequently use shell processes for debugging or testing purposes might cause false positives. Consider excluding these environments by filtering based on host identifiers or specific user accounts. +- Network monitoring tools or legitimate applications that use socat for network connections may appear suspicious. Identify these applications and exclude their specific process names or parent-child relationships from the detection rule. +- Custom scripts or applications that mimic reverse shell behavior for legitimate purposes should be reviewed and excluded by adding their specific process names or command-line patterns to the exception list. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious shell processes identified by the detection rule, especially those initiated by or involving the listed shell programs (e.g., bash, socat). +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized user accounts or modified system files. +- Review and reset credentials for any accounts that may have been compromised, ensuring the use of strong, unique passwords. +- Apply relevant security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Monitor network traffic for any further suspicious activity, particularly outgoing connections to unknown or suspicious IP addresses. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/linux/execution_shell_via_java_revshell_linux.toml b/rules/linux/execution_shell_via_java_revshell_linux.toml index 8294a0bd405..c900b422fd8 100644 --- a/rules/linux/execution_shell_via_java_revshell_linux.toml +++ b/rules/linux/execution_shell_via_java_revshell_linux.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/04" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -75,6 +75,39 @@ sequence by host.id with maxspan=5s "/usr/lib64/NetExtender.jar", "/usr/lib/jenkins/jenkins.war" )] by process.parent.entity_id ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Reverse Shell via Java + +Java applications, often run on Linux systems, can be exploited by adversaries to establish reverse shells, allowing remote control over a compromised system. Attackers may execute shell commands via Java processes post-network connection. The detection rule identifies suspicious Java activity by monitoring for shell executions following network connections, excluding benign processes, to flag potential reverse shell attempts. + +### Possible investigation steps + +- Review the network connection details, focusing on the destination IP address to determine if it is external or potentially malicious, as the rule excludes common internal and reserved IP ranges. +- Examine the Java process that initiated the network connection, including its executable path and arguments, to identify any unusual or unauthorized JAR files being executed. +- Investigate the child shell process spawned by the Java application, checking its command-line arguments and execution context to assess if it aligns with known reverse shell patterns. +- Cross-reference the parent Java process and the child shell process with known benign applications or services, such as Jenkins or NetExtender, to rule out false positives. +- Analyze historical data for the host to identify any previous similar activities or patterns that might indicate a persistent threat or repeated exploitation attempts. + +### False positive analysis + +- Java-based administrative tools like Jenkins may trigger false positives when executing shell commands. Exclude known benign Java applications such as Jenkins by adding their specific JAR paths to the exception list. +- Automated scripts or maintenance tasks that use Java to execute shell commands can be mistaken for reverse shell activity. Identify and exclude these scripts by specifying their unique process arguments or executable paths. +- Development environments where Java applications frequently execute shell commands for testing purposes can generate false alerts. Consider excluding these environments by filtering based on specific host identifiers or network segments. +- Security tools that utilize Java for network operations and shell executions might be flagged. Verify and exclude these tools by adding their process names or executable paths to the exception list. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious Java processes identified in the alert to stop potential reverse shell activity. +- Conduct a thorough review of the affected system's logs to identify any additional indicators of compromise or lateral movement attempts. +- Remove any unauthorized or malicious Java JAR files and associated scripts from the system. +- Apply security patches and updates to the Java environment and any other vulnerable software on the affected host. +- Restore the system from a known good backup if any unauthorized changes or persistent threats are detected. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] diff --git a/rules/linux/execution_shell_via_lolbin_interpreter_linux.toml b/rules/linux/execution_shell_via_lolbin_interpreter_linux.toml index 4d5cb20854a..3171d79f636 100644 --- a/rules/linux/execution_shell_via_lolbin_interpreter_linux.toml +++ b/rules/linux/execution_shell_via_lolbin_interpreter_linux.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/04" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -84,6 +84,41 @@ sequence by host.id, process.entity_id with maxspan=1s process.name : ("python*", "php*", "perl", "ruby", "lua*", "openssl", "nc", "netcat", "ncat", "telnet", "awk") and destination.ip != null and not cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1")] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Reverse Shell via Suspicious Child Process + +Reverse shells are a common technique used by attackers to gain remote access to a compromised system. They exploit scripting languages and utilities like Python, Perl, and Netcat to execute commands remotely. The detection rule identifies suspicious process chains and network activities, such as unexpected shell spawns and outbound connections, to flag potential reverse shell attempts, leveraging process and network event analysis to detect anomalies. + +### Possible investigation steps + +- Review the process chain to identify the parent process and determine if it is expected behavior for the system. Check the process.parent.name field for any unusual or unauthorized parent processes. +- Analyze the process arguments captured in the alert, such as process.args, to understand the command being executed and assess if it aligns with known reverse shell patterns. +- Investigate the network connection details, focusing on the destination.ip field, to determine if the connection is to a known malicious IP or an unexpected external address. +- Check the process.name field to identify the specific utility used (e.g., python, perl, nc) and verify if its usage is legitimate or if it indicates a potential compromise. +- Correlate the alert with other security events or logs from the same host.id to identify any additional suspicious activities or patterns that may indicate a broader attack. +- Consult threat intelligence sources to gather information on any identified IP addresses or domains involved in the network connection to assess their reputation and potential threat level. + +### False positive analysis + +- Development and testing environments may frequently execute scripts using languages like Python, Perl, or Ruby, which can trigger the rule. To manage this, consider excluding specific host IDs or process names associated with known development activities. +- Automated scripts or cron jobs that utilize network connections for legitimate purposes, such as data backups or updates, might be flagged. Identify these processes and add them to an exception list based on their parent process names or specific arguments. +- System administrators might use tools like Netcat or OpenSSL for troubleshooting or monitoring network connections. If these activities are routine and verified, exclude them by specifying the administrator's user ID or the specific command patterns used. +- Security tools or monitoring solutions that simulate attack scenarios for testing purposes can also trigger this rule. Ensure these tools are recognized and excluded by their process names or associated network activities. +- Custom scripts that use shell commands to interact with remote systems for maintenance tasks may appear suspicious. Review these scripts and exclude them by their unique process arguments or parent process names. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, particularly those involving scripting languages or utilities like Python, Perl, or Netcat. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized user accounts or modified system files. +- Review and reset credentials for any accounts that may have been accessed or compromised during the incident. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Monitor network traffic for any signs of further suspicious activity, focusing on outbound connections from the affected host. +- Escalate the incident to the security operations center (SOC) or relevant security team for further investigation and to ensure comprehensive remediation efforts.""" [[rule.threat]] diff --git a/rules/linux/execution_shell_via_meterpreter_linux.toml b/rules/linux/execution_shell_via_meterpreter_linux.toml index c279ac88981..b0c80532b4d 100644 --- a/rules/linux/execution_shell_via_meterpreter_linux.toml +++ b/rules/linux/execution_shell_via_meterpreter_linux.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/10" integration = ["auditd_manager"] maturity = "production" -updated_date = "2024/09/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -79,6 +79,40 @@ sample by host.id, process.pid, user.id [file where host.os.type == "linux" and auditd.data.syscall == "open" and auditd.data.a2 == "1b6" and file.path == "/proc/net/ipv6_route"] [file where host.os.type == "linux" and auditd.data.syscall == "open" and auditd.data.a2 == "1b6" and file.path == "/proc/net/if_inet6"] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Meterpreter Reverse Shell + +Meterpreter is a sophisticated payload within the Metasploit framework, enabling attackers to execute commands and scripts on compromised systems. Adversaries exploit it to perform system reconnaissance and data exfiltration. The detection rule identifies suspicious file access patterns typical of Meterpreter's system fingerprinting activities, such as reading key system files, indicating a potential reverse shell connection. + +### Possible investigation steps + +- Review the process associated with the alert by examining the process ID (process.pid) and user ID (user.id) to determine if the process is legitimate or potentially malicious. +- Check the host ID (host.id) to identify the specific system where the suspicious activity was detected and assess if it is a high-value target or has been previously compromised. +- Investigate the command history and running processes on the affected host to identify any unusual or unauthorized activities that may indicate a Meterpreter session. +- Analyze network connections from the host to detect any suspicious outbound connections that could suggest a reverse shell communication. +- Examine the file access patterns, particularly the access to files like /etc/machine-id, /etc/passwd, /proc/net/route, /proc/net/ipv6_route, and /proc/net/if_inet6, to understand the context and purpose of these reads and whether they align with normal system operations. +- Correlate the alert with other security events or logs from the same timeframe to identify any additional indicators of compromise or related malicious activities. + +### False positive analysis + +- System administration scripts or tools that perform regular checks on system files like /etc/machine-id or /etc/passwd may trigger this rule. To manage this, identify and whitelist these legitimate processes by their process ID or user ID. +- Backup or monitoring software that accesses network configuration files such as /proc/net/route or /proc/net/ipv6_route can cause false positives. Exclude these applications by adding exceptions for their specific file access patterns. +- Security tools that perform network diagnostics or inventory checks might read files like /proc/net/if_inet6. Review these tools and exclude their known benign activities from triggering the rule. +- Custom scripts used for system health checks or inventory management that access the flagged files should be reviewed. If deemed safe, add them to an exception list based on their host ID or user ID. + +### Response and remediation + +- Isolate the affected system from the network immediately to prevent further data exfiltration or lateral movement by the attacker. +- Terminate any suspicious processes identified by the detection rule, particularly those associated with the process IDs flagged in the alert. +- Conduct a thorough review of the affected system's logs and file access history to identify any additional unauthorized access or data exfiltration attempts. +- Change all credentials and keys that may have been exposed or compromised on the affected system, especially those related to user accounts identified in the alert. +- Restore the affected system from a known good backup to ensure any malicious changes are removed, and verify the integrity of the restored system. +- Implement network segmentation to limit the potential impact of future attacks and enhance monitoring of critical systems for similar suspicious activities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/linux/execution_shell_via_suspicious_binary.toml b/rules/linux/execution_shell_via_suspicious_binary.toml index 3e79f5cfac4..eb806766a74 100644 --- a/rules/linux/execution_shell_via_suspicious_binary.toml +++ b/rules/linux/execution_shell_via_suspicious_binary.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/05" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -77,6 +77,41 @@ sequence by host.id, process.entity_id with maxspan=1s process.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.parent.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") ] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Reverse Shell via Suspicious Binary + +Reverse shells are a common technique used by attackers to gain persistent access to a compromised system. They exploit legitimate shell environments to execute commands remotely. Adversaries often deploy binaries in unusual directories to evade detection. The detection rule identifies suspicious binaries executed in these locations, followed by network activity and shell spawning, indicating potential reverse shell activity. This approach helps in identifying unauthorized access attempts on Linux systems. + +### Possible investigation steps + +- Review the process execution details to identify the suspicious binary's path and name, focusing on the directories specified in the query such as /tmp, /var/tmp, and /dev/shm. +- Examine the parent process of the suspicious binary to determine if it was spawned by a legitimate shell process like bash or sh, as indicated in the query. +- Analyze the network activity associated with the suspicious binary, paying attention to the destination IP address to identify any external connections that are not local (i.e., not 127.0.0.1 or ::1). +- Check the process tree to see if a new shell was spawned following the network activity, which could indicate a reverse shell attempt. +- Investigate the user account under which the suspicious process was executed to assess if it aligns with expected behavior or if it might be compromised. +- Correlate the event timestamps to understand the sequence of actions and verify if they align with typical reverse shell behavior patterns. + +### False positive analysis + +- Legitimate administrative scripts or binaries may be executed from directories like /tmp or /var/tmp during maintenance tasks. To handle this, create exceptions for known scripts or binaries used by trusted administrators. +- Automated deployment tools might temporarily use directories such as /dev/shm or /run for staging files. Identify these tools and exclude their processes from triggering the rule. +- Custom monitoring or backup scripts could initiate network connections from non-standard directories. Review these scripts and whitelist their activities if they are verified as safe. +- Development or testing environments might involve executing binaries from unusual locations. Ensure these environments are well-documented and exclude their processes from the detection rule. +- Some legitimate applications may spawn shells as part of their normal operation. Identify these applications and add them to an exception list to prevent false alerts. + +### Response and remediation + +- Isolate the affected system from the network immediately to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, especially those originating from unusual directories or involving shell spawning. +- Conduct a thorough review of the system's scheduled tasks, startup scripts, and cron jobs to identify and remove any unauthorized entries that may have been added by the attacker. +- Analyze network logs to identify any external IP addresses involved in the suspicious network activity and block these IPs at the firewall to prevent further connections. +- Restore the affected system from a known good backup to ensure that any malicious changes are reverted. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] diff --git a/rules/linux/execution_shell_via_tcp_cli_utility_linux.toml b/rules/linux/execution_shell_via_tcp_cli_utility_linux.toml index 56c51e0f506..1ff31372e2e 100644 --- a/rules/linux/execution_shell_via_tcp_cli_utility_linux.toml +++ b/rules/linux/execution_shell_via_tcp_cli_utility_linux.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/04" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -67,6 +67,41 @@ sequence by host.id with maxspan=5s (process.args : ("-i", "-l")) or (process.parent.name == "socat" and process.parent.args : "*exec*") )] by process.parent.entity_id ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Reverse Shell + +Reverse shells are tools that adversaries use to gain remote access to a system by initiating a connection from the target back to the attacker. This detection rule identifies such activity by monitoring for network events followed by shell process creation on Linux systems. It flags suspicious patterns, such as shell processes with interactive flags or spawned by tools like socat, indicating potential unauthorized access attempts. + +### Possible investigation steps + +- Review the network event details to identify the source and destination IP addresses involved in the connection attempt or acceptance. Pay special attention to any external IP addresses that are not part of the internal network ranges. +- Examine the process tree to understand the parent-child relationship, focusing on the shell process creation following the network event. Verify if the shell process was spawned by a known tool like socat. +- Check the process arguments for interactive flags such as "-i" or "-l" to determine if the shell was intended to be interactive, which could indicate malicious intent. +- Investigate the user account associated with the process to determine if it is a legitimate user or if there are signs of compromise, such as unusual login times or locations. +- Correlate the event with other security logs or alerts to identify any additional suspicious activities or patterns that might indicate a broader attack campaign. +- Assess the risk and impact of the potential reverse shell by determining if any sensitive data or critical systems could have been accessed or compromised. + +### False positive analysis + +- Legitimate administrative tasks using interactive shells may trigger this rule. System administrators often use shells with interactive flags for maintenance. To mitigate, create exceptions for known administrator accounts or specific IP addresses. +- Automated scripts or cron jobs that use shell commands with interactive flags can be mistaken for reverse shells. Review and whitelist these scripts by process name or parent process ID to prevent false alerts. +- Tools like socat are used in legitimate network troubleshooting and testing. If socat is frequently used in your environment, consider excluding specific command patterns or user accounts associated with its legitimate use. +- Development environments may spawn shell processes as part of testing or deployment workflows. Identify and exclude these environments by host ID or process name to reduce noise. +- Internal network connections that match the rule's criteria but are part of normal operations can be excluded by specifying internal IP ranges or known service accounts. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious shell processes identified by the detection rule, especially those initiated by socat or with interactive flags. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized user accounts or modified files. +- Review and secure network configurations to ensure that only authorized IP addresses can initiate connections to critical systems. +- Update and patch the affected system and any related software to close vulnerabilities that may have been exploited. +- Implement enhanced monitoring and logging on the affected host and network to detect any further attempts at reverse shell activity. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist.""" [[rule.threat]] diff --git a/rules/linux/execution_shell_via_udp_cli_utility_linux.toml b/rules/linux/execution_shell_via_udp_cli_utility_linux.toml index e4c42a2a178..832d4bf4277 100644 --- a/rules/linux/execution_shell_via_udp_cli_utility_linux.toml +++ b/rules/linux/execution_shell_via_udp_cli_utility_linux.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/04" integration = ["auditd_manager"] maturity = "production" -updated_date = "2024/09/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -87,6 +87,41 @@ sample by host.id, process.pid, process.parent.pid ) and network.direction == "egress" and destination.ip != null and not cidrmatch(destination.ip, "127.0.0.0/8", "169.254.0.0/16", "224.0.0.0/4", "::1")] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Reverse Shell via UDP + +Reverse shells over UDP can be exploited by attackers to bypass firewalls and gain unauthorized access to systems. This technique leverages UDP's connectionless nature, making it harder to detect. Adversaries may use scripting languages or network tools to initiate these connections. The detection rule identifies suspicious processes executing network-related syscalls and egress connections, flagging potential reverse shell activity. + +### Possible investigation steps + +- Review the process details such as process.pid, process.parent.pid, and process.name to identify the specific process that triggered the alert and its parent process. +- Examine the command line arguments and environment variables associated with the suspicious process to understand its intended function and origin. +- Check the network connection details, including destination.ip and network.direction, to determine the external entity the process attempted to connect to and assess if it is a known malicious IP or domain. +- Investigate the user account associated with the process to determine if it has been compromised or if there are any signs of unauthorized access. +- Analyze historical logs for any previous instances of similar process executions or network connections to identify patterns or repeated attempts. +- Correlate the alert with other security events or alerts from the same host.id to gather additional context and assess the scope of potential compromise. + +### False positive analysis + +- Legitimate administrative scripts or tools may trigger the rule if they use UDP for valid network operations. Users can create exceptions for specific scripts or processes that are known to perform routine administrative tasks. +- Automated monitoring or network management tools that use UDP for health checks or status updates might be flagged. Identify these tools and exclude their process names or network patterns from the rule. +- Development or testing environments where developers frequently use scripting languages or network tools for legitimate purposes can cause false positives. Consider excluding specific host IDs or process names associated with these environments. +- Custom applications that use UDP for communication, especially if they are developed in-house, may be mistakenly identified. Review these applications and whitelist their process names or network behaviors if they are verified as safe. +- Network scanning or diagnostic tools that use UDP for troubleshooting can be misinterpreted as malicious. Ensure these tools are recognized and excluded from the detection rule if they are part of regular network maintenance activities. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, particularly those associated with known reverse shell tools or scripting languages. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized user accounts or modified system files. +- Review and update firewall rules to block outbound UDP traffic from unauthorized applications or processes, ensuring legitimate traffic is not disrupted. +- Reset credentials for any accounts accessed from the affected host, especially if they have administrative privileges. +- 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 enhanced monitoring and logging for similar suspicious activities, focusing on the execution of network-related syscalls and egress connections from scripting languages or network tools.""" [[rule.threat]] diff --git a/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml b/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml index 5ad64dc7846..58d138fcefb 100644 --- a/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml +++ b/rules/linux/execution_sus_extraction_or_decrompression_via_funzip.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/08" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -67,6 +67,40 @@ not process.args : "/var/log/messages" and not process.parent.executable : ("/usr/bin/dracut", "/sbin/dracut", "/usr/bin/xargs") and not (process.parent.name in ("sh", "sudo") and process.parent.command_line : "*nessus_su*") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Content Extracted or Decompressed via Funzip + +Funzip is a utility used to decompress files directly from a stream, often employed in legitimate data processing tasks. However, adversaries can exploit this by combining it with the 'tail' command to extract and execute malicious payloads stealthily. The detection rule identifies this misuse by monitoring specific command sequences and excluding benign processes, thus flagging potential threats for further investigation. + +### Possible investigation steps + +- Review the process details to confirm the presence of the 'tail' and 'funzip' command sequence, focusing on the specific arguments used, such as "-c", to understand the context of the command execution. +- Examine the parent process information to determine if the process was initiated by any known benign executables or scripts, specifically checking against the exclusion list like "/usr/bin/dracut" or "/sbin/dracut". +- Investigate the command line history and execution context of the parent process, especially if it involves "sh" or "sudo", to identify any suspicious patterns or unauthorized script executions. +- Check the file path and content being accessed by the 'tail' command to ensure it is not targeting sensitive or unexpected files, excluding known benign paths like "/var/log/messages". +- Correlate the event with other security alerts or logs from the same host to identify any related suspicious activities or patterns that might indicate a broader compromise. +- Assess the risk and impact by determining if the decompressed content was executed or if it led to any subsequent suspicious processes or network connections. + +### False positive analysis + +- Legitimate system maintenance tasks may trigger this rule if they involve decompressing logs or data files using funzip. To manage this, identify and exclude specific maintenance scripts or processes that are known to use funzip in a non-threatening manner. +- Automated backup or data processing operations might use funzip in combination with tail for legitimate purposes. Review these operations and add exceptions for known benign processes or scripts that match this pattern. +- Security tools or monitoring solutions like Nessus may inadvertently trigger this rule if they use similar command sequences for scanning or data collection. Exclude these tools by adding exceptions for their specific command lines or parent processes. +- Custom scripts developed in-house for data analysis or processing might use funzip and tail together. Document these scripts and exclude them from the rule to prevent false positives, ensuring they are reviewed and approved by security teams. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further spread of the potential malware. +- Terminate any suspicious processes identified by the detection rule, specifically those involving the 'tail' and 'funzip' command sequence. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious payloads. +- Review and analyze system logs and command history to identify any unauthorized access or additional malicious activities that may have occurred. +- Restore any compromised files or systems from known good backups to ensure integrity and availability of data. +- Implement application whitelisting to prevent unauthorized execution of utilities like 'funzip' and 'tail' by non-administrative users. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures.""" [[rule.threat]] diff --git a/rules/linux/execution_suspicious_executable_running_system_commands.toml b/rules/linux/execution_suspicious_executable_running_system_commands.toml index 799dfcc7778..8f1506333dc 100644 --- a/rules/linux/execution_suspicious_executable_running_system_commands.toml +++ b/rules/linux/execution_suspicious_executable_running_system_commands.toml @@ -2,7 +2,7 @@ creation_date = "2023/06/14" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -75,6 +75,41 @@ process.parent.executable:( process.executable:(/run/containerd/* or /srv/snp/docker/* or /tmp/.criu*) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious System Commands Executed by Previously Unknown Executable + +In Linux environments, system commands are essential for managing processes and configurations. Adversaries exploit this by executing commands via unknown executables in vulnerable directories, aiming to run unauthorized code. The detection rule identifies such anomalies by monitoring command executions from unfamiliar sources, excluding known safe processes, thus highlighting potential threats for further investigation. + +### Possible investigation steps + +- Review the process.executable path to determine if it is located in a commonly abused directory such as /tmp, /dev/shm, or /var/tmp, which may indicate malicious intent. +- Examine the process.args to identify which specific system command was executed (e.g., hostname, id, ifconfig) and assess whether its execution is typical for the system's normal operations. +- Check the process.parent.executable to understand the parent process that initiated the suspicious command execution, ensuring it is not a known safe process or a legitimate system service. +- Investigate the user account associated with the process 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 patterns or additional suspicious activities that may indicate a broader compromise. +- Assess the risk score and severity in the context of the environment to prioritize the investigation and response efforts accordingly. + +### False positive analysis + +- System maintenance scripts or automated tasks may trigger alerts if they execute common system commands from directories like /tmp or /var/tmp. To handle this, identify these scripts and add their executables to the exclusion list. +- Custom user scripts that perform routine checks using commands like ls or ps might be flagged. Review these scripts and consider adding their paths to the known safe processes to prevent unnecessary alerts. +- Development or testing environments often use temporary executables in directories such as /dev/shm. If these are known and non-threatening, include their paths in the exception list to reduce false positives. +- Some monitoring tools or agents might execute commands like uptime or whoami from non-standard locations. Verify these tools and update the exclusion criteria to include their executables or parent processes. +- In environments with containerized applications, processes running from /run/containerd or similar paths might be incorrectly flagged. Ensure these paths are accounted for in the exclusion settings if they are part of legitimate operations. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified by the alert, especially those originating from unknown executables in commonly abused directories. +- Conduct a thorough review of the affected directories (e.g., /tmp, /var/tmp, /dev/shm) to identify and remove any unauthorized or malicious files or executables. +- Restore any altered system configurations or files from a known good backup to ensure system integrity. +- Implement stricter access controls and permissions on the directories identified in the alert to prevent unauthorized executable placement. +- Monitor the system for any signs of persistence mechanisms, such as cron jobs or startup scripts, and remove any that are unauthorized. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be compromised.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/execution_suspicious_mining_process_creation_events.toml b/rules/linux/execution_suspicious_mining_process_creation_events.toml index 98437b758b5..1c301462255 100644 --- a/rules/linux/execution_suspicious_mining_process_creation_events.toml +++ b/rules/linux/execution_suspicious_mining_process_creation_events.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/06" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -62,6 +62,40 @@ query = ''' file where host.os.type == "linux" and event.type == "creation" and event.action : ("creation", "file_create_event") and file.name : ("aliyun.service", "moneroocean_miner.service", "c3pool_miner.service", "pnsd.service", "apache4.service", "pastebin.service", "xvf.service") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Mining Process Creation Event + +Cryptomining exploits system resources to mine cryptocurrency, often without user consent, impacting performance and security. Adversaries may deploy mining services on Linux systems, disguising them as legitimate processes. The detection rule identifies the creation of known mining service files, signaling potential unauthorized mining activity. By monitoring these specific file creation events, security teams can swiftly respond to and mitigate cryptomining threats. + +### Possible investigation steps + +- Review the alert details to identify which specific mining service file was created, focusing on the file names listed in the query such as "aliyun.service" or "moneroocean_miner.service". +- Check the creation timestamp of the suspicious file to determine when the potential unauthorized mining activity began. +- Investigate the process that created the file by examining system logs or using process monitoring tools to identify the parent process and any associated command-line arguments. +- Analyze the system for additional indicators of compromise, such as unexpected network connections or high CPU usage, which may suggest active cryptomining. +- Verify the legitimacy of the file by comparing it against known hashes of legitimate services or using threat intelligence sources to identify known malicious files. +- Assess the system for any other suspicious activities or anomalies that may indicate further compromise or persistence mechanisms. + +### False positive analysis + +- Legitimate administrative scripts or services may create files with names similar to known mining services. Verify the origin and purpose of such files before taking action. +- System administrators might deploy custom monitoring or management services that inadvertently match the file names in the detection rule. Review and whitelist these services if they are confirmed to be non-threatening. +- Automated deployment tools or scripts could create service files as part of routine operations. Ensure these tools are properly documented and exclude them from the detection rule if they are verified as safe. +- Some legitimate software installations might use generic service names that overlap with those flagged by the rule. Cross-check with software documentation and exclude these from alerts if they are confirmed to be benign. + +### Response and remediation + +- Isolate the affected Linux system from the network to prevent further unauthorized mining activity and potential lateral movement by the adversary. +- Terminate any suspicious processes associated with the identified mining services, such as aliyun.service, moneroocean_miner.service, or others listed in the detection query. +- Remove the malicious service files from the system to prevent them from being restarted or reused by the attacker. +- 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. +- Review and update system and application patches to close any vulnerabilities that may have been exploited to deploy the mining services. +- Monitor network traffic for unusual outbound connections that may indicate communication with mining pools or command and control servers, and block these connections if detected. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] diff --git a/rules/linux/execution_tc_bpf_filter.toml b/rules/linux/execution_tc_bpf_filter.toml index fbd2b0989e1..334b24c3239 100644 --- a/rules/linux/execution_tc_bpf_filter.toml +++ b/rules/linux/execution_tc_bpf_filter.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/08" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -69,6 +69,40 @@ process where host.os.type == "linux" and event.type != "end" and process.execut process.args == "filter" and process.args == "add" and process.args == "bpf" and not process.parent.executable == "/usr/sbin/libvirtd" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 BPF filter applied using TC + +BPF (Berkeley Packet Filter) is a powerful tool for network traffic analysis and control, often used with the `tc` command to manage traffic on Linux systems. Adversaries may exploit this by setting BPF filters to manipulate or monitor network traffic covertly. The detection rule identifies suspicious use of `tc` to apply BPF filters, flagging potential misuse by checking for specific command patterns and excluding legitimate processes. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of the `/usr/sbin/tc` command with arguments "filter", "add", and "bpf" to ensure the alert is not a false positive. +- Investigate the parent process of the `tc` command to determine if it is a known legitimate process or if it appears suspicious, especially since the rule excludes `/usr/sbin/libvirtd`. +- Check the user account associated with the process execution to assess if it is a privileged account and whether the activity aligns with the user's typical behavior. +- Analyze network traffic logs around the time of the alert to identify any unusual patterns or connections that may indicate malicious activity. +- Correlate this event with other security alerts or logs to identify if this is part of a broader attack pattern or campaign, such as the use of the TripleCross threat. +- Review system logs for any other suspicious activities or anomalies that occurred before or after the alert to gather additional context. + +### False positive analysis + +- Legitimate use of tc by virtualization software like libvirtd can trigger the rule. To handle this, exclude processes where the parent executable is /usr/sbin/libvirtd, as indicated in the rule. +- Network administrators may use tc with BPF filters for legitimate traffic management tasks. Identify and document these use cases, then create exceptions for specific command patterns or user accounts involved in these activities. +- Automated scripts or system management tools that configure network interfaces might use tc with BPF filters. Review these scripts and tools, and if they are verified as safe, exclude their process signatures from triggering the rule. +- Regular audits of network configurations can help distinguish between legitimate and suspicious use of BPF filters. Implement a process to regularly review and update exceptions based on these audits to minimize false positives. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further manipulation or monitoring of network traffic by the adversary. +- Terminate the suspicious `tc` process to stop any ongoing malicious activity related to the BPF filter application. +- Conduct a thorough review of network traffic logs to identify any unauthorized data exfiltration or communication with known malicious IP addresses. +- Restore the affected system from a known good backup to ensure that no malicious configurations or software persist. +- Implement network segmentation to limit the potential impact of similar threats in the future, ensuring critical systems are isolated from less secure areas. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are compromised. +- Update and enhance endpoint detection and response (EDR) solutions to improve monitoring and alerting for similar suspicious activities involving `tc` and BPF filters.""" [[rule.threat]] diff --git a/rules/linux/execution_unix_socket_communication.toml b/rules/linux/execution_unix_socket_communication.toml index 561bf0c43b6..cc20572a207 100644 --- a/rules/linux/execution_unix_socket_communication.toml +++ b/rules/linux/execution_unix_socket_communication.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_ maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/08" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -46,6 +46,41 @@ process where host.os.type == "linux" and event.type == "start" and ) and not process.args == "/var/run/libvirt/libvirt-sock" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Unix Socket Connection + +Unix sockets facilitate efficient inter-process communication (IPC) on the same host, crucial for system operations. However, adversaries can exploit them to probe applications, identify weaknesses, or establish covert channels. The detection rule identifies suspicious use of tools like netcat and socat with specific arguments, signaling potential misuse of Unix sockets for unauthorized communication or privilege escalation attempts. + +### Possible investigation steps + +- Review the process details to confirm the execution of netcat or socat with the specified arguments, focusing on the process name and arguments fields to verify the suspicious activity. +- Investigate the source and destination of the Unix socket connection by examining the process.args field to determine if the connection is legitimate or potentially malicious. +- Check the user context under which the process was executed to assess if there is any indication of privilege escalation attempts. +- Correlate the event with other logs or alerts from the same host to identify any patterns or additional suspicious activities that might indicate a broader attack. +- Examine the process lineage to understand the parent process and any child processes spawned, which might provide insights into how the suspicious process was initiated. +- Verify if the process is part of any known legitimate application or service by cross-referencing with system documentation or application inventories. + +### False positive analysis + +- Legitimate administrative tasks using netcat or socat for system maintenance or monitoring can trigger alerts. To manage this, identify and whitelist specific scripts or commands used regularly by system administrators. +- Automated backup or monitoring tools that use Unix sockets for communication may be flagged. Review these tools and add them to an exception list if they are verified as safe and necessary for operations. +- Certain applications may use Unix sockets for legitimate inter-process communication, such as database services or web servers. Monitor these applications and exclude their typical behavior from the rule to prevent unnecessary alerts. +- Development environments where developers frequently use netcat or socat for testing purposes can generate false positives. Establish a policy to differentiate between development and production environments and apply exceptions accordingly. +- System services like libvirt, which are known to use Unix sockets, should be excluded from the rule as indicated by the exception for /var/run/libvirt/libvirt-sock. Regularly update this list to include other known benign services. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent potential lateral movement or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, specifically those involving netcat or socat with the flagged arguments. +- Conduct a thorough review of the affected system's logs to identify any unauthorized access or data manipulation that may have occurred. +- Reset credentials and review permissions for any accounts that may have been compromised or used in the attack. +- Apply patches or configuration changes to address any vulnerabilities or misconfigurations identified during the investigation. +- Monitor the affected system and network for any signs of recurring suspicious activity, focusing on Unix socket connections. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/execution_unknown_rwx_mem_region_binary_executed.toml b/rules/linux/execution_unknown_rwx_mem_region_binary_executed.toml index 72ddcdf21c0..0894eb6a47c 100644 --- a/rules/linux/execution_unknown_rwx_mem_region_binary_executed.toml +++ b/rules/linux/execution_unknown_rwx_mem_region_binary_executed.toml @@ -2,7 +2,7 @@ creation_date = "2024/03/13" integration = ["auditd_manager"] maturity = "production" -updated_date = "2024/09/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -60,6 +60,41 @@ event.category:process and host.os.type:linux and auditd.data.syscall:mprotect a process.name:httpd ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Unknown Execution of Binary with RWX Memory Region + +In Linux environments, the `mprotect()` system call is crucial for managing memory permissions, allowing processes to modify access rights of memory pages. Adversaries exploit this by granting read, write, and execute (RWX) permissions to inject and execute malicious code. The detection rule identifies suspicious RWX memory allocations by monitoring `mprotect()` calls, excluding known safe binaries, thus highlighting potential threats. + +### Possible investigation steps + +- Review the process details associated with the alert, focusing on the process.executable and process.name fields to identify the binary that triggered the alert. +- Investigate the command line arguments and parent process of the suspicious binary to understand its origin and purpose. +- Check the process's hash against known threat intelligence databases to determine if it is associated with any known malicious activity. +- Analyze the network activity of the process to identify any suspicious connections or data exfiltration attempts. +- Examine the user account under which the process is running to assess if it has been compromised or is being used for unauthorized activities. +- Review recent system logs and audit records for any other anomalies or related suspicious activities around the time of the alert. + +### False positive analysis + +- Known safe binaries like Node.js, Java, and Apache may trigger the rule due to their legitimate use of RWX memory regions. These are already excluded in the rule, but additional similar applications might need to be added to the exclusion list. +- Custom or in-house developed applications that require RWX permissions for legitimate functionality can also cause false positives. Identify these applications and add them to the exclusion list to prevent unnecessary alerts. +- Development environments or testing frameworks that dynamically generate and execute code might be flagged. Consider excluding these environments if they are known and trusted within your organization. +- Security tools or monitoring software that perform memory analysis or manipulation could be mistakenly identified. Verify their behavior and exclude them if they are part of your security infrastructure. +- Regularly review and update the exclusion list to ensure it reflects the current environment and any new applications that are introduced. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the malicious code. +- Terminate the suspicious process identified by the detection rule to halt any ongoing malicious activity. +- Conduct a forensic analysis of the affected system to identify the source and scope of the compromise, focusing on the unknown binary and its origin. +- Remove any malicious binaries or scripts identified during the forensic analysis to prevent further execution. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Restore the system from a known good backup if the integrity of the system is in question and ensure all security patches are applied post-restoration. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/linux/exfiltration_potential_data_splitting_for_exfiltration.toml b/rules/linux/exfiltration_potential_data_splitting_for_exfiltration.toml index e227515767a..f82e1c70c48 100644 --- a/rules/linux/exfiltration_potential_data_splitting_for_exfiltration.toml +++ b/rules/linux/exfiltration_potential_data_splitting_for_exfiltration.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/08" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -79,6 +79,41 @@ process where host.os.type == "linux" and event.type == "start" and ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Data Splitting Detected + +Data splitting utilities on Linux, such as `dd` and `split`, are typically used for managing large files by dividing them into smaller, more manageable parts. Adversaries exploit these tools to covertly exfiltrate data by splitting it into inconspicuous segments. The detection rule identifies suspicious use of these utilities by monitoring specific command-line arguments and excluding benign processes, thereby flagging potential exfiltration activities. + +### Possible investigation steps + +- Review the process details to confirm the use of data splitting utilities like 'dd', 'split', or 'rsplit' with suspicious arguments such as 'bs=*', 'if=*', '-b', or '--bytes*'. +- Examine the parent process name to ensure it is not a benign process like 'apport' or 'overlayroot', which are excluded in the rule. +- Investigate the source and destination paths specified in the process arguments to determine if they involve sensitive or unusual locations, excluding paths like '/tmp/nvim*', '/boot/*', or '/dev/urandom'. +- Check the user account associated with the process to assess if it has a history of legitimate use of these utilities or if it might be compromised. +- Analyze recent network activity from the host to identify any potential data exfiltration attempts, especially if the process involves external connections. +- Correlate this alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise. + +### False positive analysis + +- Processes related to system maintenance or updates, such as those initiated by the 'apport' or 'overlayroot' processes, may trigger false positives. Users can mitigate this by ensuring these parent processes are included in the exclusion list. +- Backup operations that use 'dd' or 'split' for legitimate data management tasks can be mistaken for exfiltration attempts. Exclude specific backup scripts or processes by adding their unique identifiers or arguments to the exclusion criteria. +- Development or testing environments where 'dd' or 'split' are used for creating test data or simulating data transfer can generate false alerts. Identify and exclude these environments by specifying their process names or argument patterns. +- Automated scripts that use 'dd' or 'split' for routine data processing tasks should be reviewed and, if benign, added to the exclusion list to prevent unnecessary alerts. +- Regular system operations involving '/dev/random', '/dev/urandom', or similar sources should be excluded, as these are common in non-malicious contexts and are already partially covered by the rule's exclusions. + +### Response and remediation + +- Immediately isolate the affected Linux system from the network to prevent further data exfiltration. +- Terminate any suspicious processes identified by the detection rule, specifically those involving the `dd`, `split`, or `rsplit` utilities with the flagged arguments. +- Conduct a thorough review of recent file access and modification logs to identify any unauthorized data handling or exfiltration attempts. +- Restore any potentially compromised data from secure backups, ensuring that the restored data is free from any malicious alterations. +- Implement stricter access controls and monitoring on sensitive data directories to prevent unauthorized access and manipulation. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are affected. +- Enhance monitoring and alerting for similar suspicious activities by integrating additional threat intelligence sources and refining detection capabilities.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/impact_data_encrypted_via_openssl.toml b/rules/linux/impact_data_encrypted_via_openssl.toml index 2e7a762d6bc..48107a6d53b 100644 --- a/rules/linux/impact_data_encrypted_via_openssl.toml +++ b/rules/linux/impact_data_encrypted_via_openssl.toml @@ -2,7 +2,7 @@ creation_date = "2023/06/26" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -66,6 +66,40 @@ sequence by host.id, user.name, process.parent.entity_id with maxspan=5s /* excluding base64 encoding options and including encryption password or key params */ not process.args in ("-d", "-a", "-A", "-base64", "-none", "-nosalt") ] with runs=10 ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Data Encryption via OpenSSL Utility + +OpenSSL is a widely-used command-line tool for secure data encryption and decryption. Adversaries may exploit OpenSSL to encrypt files rapidly across systems, aiming to disrupt data availability or demand ransom. The detection rule identifies suspicious OpenSSL usage by monitoring rapid file encryption activities, focusing on specific command patterns and excluding benign operations, thus highlighting potential malicious behavior. + +### Possible investigation steps + +- Review the process execution details on the host identified by host.id to confirm the presence of the openssl command and its associated arguments, ensuring they match the suspicious pattern specified in the query. +- Examine the user.name associated with the process to determine if the activity aligns with expected behavior for that user or if it indicates potential unauthorized access. +- Investigate the parent process identified by process.parent.entity_id to understand the context in which the openssl command was executed, checking for any unusual or unexpected parent processes. +- Check for any recent file modifications or creations on the host that coincide with the time window of the alert to assess the impact of the encryption activity. +- Look for additional related alerts or logs from the same host or user within a similar timeframe to identify any patterns or further suspicious activities that could indicate a broader attack. + +### False positive analysis + +- Legitimate batch encryption operations by system administrators or automated scripts may trigger the rule. To handle this, identify and whitelist specific scripts or user accounts that perform regular encryption tasks. +- Backup processes that use OpenSSL for encrypting data before storage can be mistaken for malicious activity. Exclude known backup processes by specifying their parent process names or paths. +- Developers or security teams testing encryption functionalities might inadvertently match the rule's criteria. Create exceptions for development environments or specific user accounts involved in testing. +- Automated data transfer services that encrypt files for secure transmission could be flagged. Identify these services and exclude their associated processes or user accounts from the rule. +- Regularly review and update the exclusion list to ensure it reflects current operational practices and does not inadvertently allow malicious activities. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further spread of the encryption activity and potential lateral movement by the adversary. +- Terminate any suspicious OpenSSL processes identified on the host to halt ongoing encryption activities. +- Conduct a forensic analysis of the affected host to identify the scope of the encryption, including which files were encrypted and any potential data exfiltration. +- Restore encrypted files from the most recent clean backup to ensure data availability and integrity, ensuring that the backup is free from any malicious alterations. +- Change all credentials and keys that may have been exposed or used on the affected host to prevent unauthorized access. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Implement enhanced monitoring and logging for OpenSSL usage across the network to detect and respond to similar threats more effectively in the future.""" [[rule.threat]] diff --git a/rules/linux/impact_esxi_process_kill.toml b/rules/linux/impact_esxi_process_kill.toml index bc58c8a9c8c..3145071f6a1 100644 --- a/rules/linux/impact_esxi_process_kill.toml +++ b/rules/linux/impact_esxi_process_kill.toml @@ -2,7 +2,7 @@ creation_date = "2023/04/11" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -63,6 +63,40 @@ query = ''' process where host.os.type == "linux" and event.type == "end" and process.name in ("vmware-vmx", "vmx") and process.parent.name == "kill" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Termination of ESXI Process + +VMware ESXi is a hypervisor used to create and manage virtual machines on a host system. Adversaries may target ESXi processes like "vmware-vmx" to disrupt virtual environments, often using the "kill" command to terminate these processes. The detection rule identifies such terminations by monitoring for specific process events, helping to uncover potential threats to virtualized infrastructures. + +### Possible investigation steps + +- Review the alert details to confirm the process name is either "vmware-vmx" or "vmx" and that the parent process is "kill" on a Linux host. +- Check the timeline of events leading up to the termination to identify any preceding suspicious activities or commands executed by the same user or process. +- Investigate the user account associated with the "kill" command to determine if it is authorized to manage VMware processes and if there are any signs of compromise. +- Examine system logs and audit trails for any unauthorized access attempts or anomalies around the time of the process termination. +- Assess the impact on the virtual environment by verifying the status of affected virtual machines and any potential service disruptions. +- Correlate this event with other security alerts or incidents to identify if it is part of a larger attack pattern targeting the virtual infrastructure. + +### False positive analysis + +- Routine maintenance or administrative tasks may involve terminating VMware processes using the kill command. To manage this, create exceptions for known maintenance scripts or administrative user accounts that regularly perform these actions. +- Automated scripts or monitoring tools might inadvertently terminate VMware processes as part of their operations. Identify and exclude these tools from the detection rule by specifying their process names or user accounts. +- System updates or patches could lead to the termination of VMware processes as part of the update procedure. Exclude these events by correlating them with known update schedules or specific update-related process names. +- Testing environments where VMware processes are frequently started and stopped for development purposes can trigger false positives. Implement exclusions for these environments by using hostnames or IP addresses associated with test systems. + +### Response and remediation + +- Immediately isolate the affected host system from the network to prevent further malicious activity and potential spread to other systems. +- Terminate any unauthorized or suspicious processes that are still running on the affected host, especially those related to VMware ESXi, to halt any ongoing disruption. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise or persistence mechanisms that may have been deployed by the threat actor. +- Restore any terminated VMware processes from a known good backup to ensure the virtual environment is returned to its operational state. +- Review and update access controls and permissions on the affected host to ensure that only authorized personnel can execute critical commands like "kill" on VMware processes. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign. +- Implement enhanced monitoring and alerting for similar suspicious activities across the virtualized infrastructure to detect and respond to future threats more effectively.""" [[rule.threat]] diff --git a/rules/linux/impact_memory_swap_modification.toml b/rules/linux/impact_memory_swap_modification.toml index 7b01fd5d3c7..ab83bbb439c 100644 --- a/rules/linux/impact_memory_swap_modification.toml +++ b/rules/linux/impact_memory_swap_modification.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/08" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -73,6 +73,41 @@ process.name in ("swapon", "swapoff") or ( ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Memory Swap Modification + +Memory swap in Linux systems manages RAM by moving inactive pages to disk, freeing up memory for active processes. Adversaries exploit this by altering swap settings to degrade performance or deploy resource-intensive malware like cryptominers. The detection rule identifies suspicious activities by monitoring processes that modify swap settings or execute related commands, flagging potential misuse for further investigation. + +### Possible investigation steps + +- Review the process details to identify the parent process using the field process.parent.executable. This can help determine if the swap modification was initiated by a legitimate or suspicious parent process. +- Examine the command line arguments captured in process.command_line to understand the specific changes made to swap settings, such as modifications to vm.swappiness. +- Check the user account associated with the process to determine if the action was performed by a privileged or unauthorized user. +- Investigate any recent system performance issues or anomalies that could be linked to swap modifications, such as increased CPU or memory usage. +- Correlate the event with other security alerts or logs to identify if this activity is part of a larger pattern of suspicious behavior, such as the presence of cryptomining software like XMRig. +- Assess the system for any unauthorized software installations or configurations that could indicate a compromise, focusing on resource-intensive applications. + +### False positive analysis + +- System administrators may frequently modify swap settings during routine maintenance or performance tuning. To handle this, create exceptions for known administrator accounts or specific maintenance scripts. +- Automated configuration management tools like Ansible or Puppet might execute commands that alter swap settings. Identify these tools and exclude their processes from triggering alerts. +- Some legitimate applications may adjust swap settings to optimize their performance. Monitor and whitelist these applications to prevent unnecessary alerts. +- Development environments often experiment with system settings, including swap configurations. Consider excluding processes from known development environments or specific user accounts associated with development activities. +- Scheduled tasks or cron jobs might include swap modification commands for system optimization. Review and whitelist these tasks if they are verified as non-threatening. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further spread or impact of the potential malware. +- Terminate any suspicious processes identified by the detection rule, such as those involving "swapon", "swapoff", or unauthorized modifications to "vm.swappiness". +- Conduct a thorough scan of the isolated system using updated antivirus or anti-malware tools to identify and remove any malicious software, particularly cryptominers like XMRig. +- Review and restore swap settings to their default or secure configurations to ensure system stability and performance. +- Implement monitoring for any further unauthorized changes to swap settings or related processes to detect and respond to similar threats promptly. +- Escalate the incident to the security operations team for a detailed forensic analysis to understand the scope and origin of the attack. +- Update system and security patches to close any vulnerabilities that may have been exploited by the adversary.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/impact_potential_linux_ransomware_note_detected.toml b/rules/linux/impact_potential_linux_ransomware_note_detected.toml index 73956314421..8cd905eeed3 100644 --- a/rules/linux/impact_potential_linux_ransomware_note_detected.toml +++ b/rules/linux/impact_potential_linux_ransomware_note_detected.toml @@ -2,7 +2,7 @@ creation_date = "2023/03/20" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -71,6 +71,42 @@ sequence by process.entity_id, host.id with maxspan=1s file.name : ("*restore*", "*lock*", "*recovery*", "*read*", "*instruction*", "*how_to*", "*ransom*") ] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Linux Ransomware Note Creation Detected + +Ransomware encrypts files, demanding payment for decryption. Adversaries exploit Linux systems by executing mass file renaming and creating ransom notes. This detection rule identifies such behavior by monitoring rapid file changes and the creation of text files with ransom-related keywords, indicating potential ransomware activity. It focuses on unusual file operations in critical directories, excluding benign processes, to flag suspicious activities. + +### Possible investigation steps + +- Review the process.entity_id and host.id to identify the specific process and host involved in the alert. This will help in understanding the scope and potential impact of the activity. +- Examine the process.executable path to determine if the executable is located in a suspicious directory such as /tmp, /var/tmp, or /dev/shm, which are commonly used by adversaries for malicious activities. +- Analyze the file paths involved in the rename events to assess if critical directories like /home/*/Documents, /root, or /var/www are affected, indicating a higher risk of data compromise. +- Check the process.name against the list of excluded benign processes to ensure the activity is not a false positive caused by legitimate software updates or installations. +- Investigate the content and metadata of the created .txt files with names containing keywords like *restore*, *lock*, or *ransom* to confirm if they contain ransom notes or instructions, which would indicate a ransomware attack. +- Correlate the timing of the file rename and creation events to verify if they occurred within the 1-second timespan, supporting the hypothesis of a rapid mass encryption event typical of ransomware behavior. +- Assess the risk score and severity level to prioritize the response and determine if immediate containment actions are necessary to prevent further damage. + +### False positive analysis + +- Frequent software updates or installations can trigger the rule due to mass file renaming in critical directories. Exclude processes like dpkg, yum, dnf, and rpm if they are part of regular system maintenance. +- Development activities involving compilers or interpreters such as go, java, python, and node may cause false positives. Consider excluding these processes if they are part of routine development work. +- Automated backup or logging processes might create files with names similar to ransom notes. Exclude directories or processes associated with legitimate backup or logging activities to reduce false alerts. +- System administration tasks using tools like ansible-galaxy or semodule can mimic ransomware behavior. Exclude these processes if they are part of scheduled or known administrative operations. +- Web server operations in directories like /var/www/* might involve file creation and renaming. Exclude specific web server processes if they are identified as non-threatening and part of regular operations. + +### Response and remediation + +- Isolate the affected Linux system from the network immediately to prevent further spread of the ransomware and protect other systems. +- Identify and terminate the malicious process responsible for the mass file renaming and ransom note creation using the process.entity_id and host.id from the alert. +- Backup any unencrypted files and critical data from the affected system to a secure location to prevent data loss. +- Conduct a forensic analysis of the affected system to determine the entry point and scope of the ransomware attack, focusing on the directories and processes identified in the alert. +- Restore the affected system from a known good backup prior to the ransomware attack to ensure system integrity and data recovery. +- Apply security patches and updates to the affected system and any other vulnerable systems to close any exploited vulnerabilities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to enhance detection capabilities for similar threats in the future.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/lateral_movement_ssh_it_worm_download.toml b/rules/linux/lateral_movement_ssh_it_worm_download.toml index b356618ce41..8e88a53a6af 100644 --- a/rules/linux/lateral_movement_ssh_it_worm_download.toml +++ b/rules/linux/lateral_movement_ssh_it_worm_download.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_ maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/08" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -69,6 +69,40 @@ process where host.os.type == "linux" and event.type == "start" and "https://thc.org/ssh-it/bs", "http://nossl.segfault.net/bs" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 SSH-IT SSH Worm Downloaded + +SSH-IT is an autonomous worm that exploits SSH connections to propagate across networks. It hijacks outgoing SSH sessions, allowing adversaries to move laterally within a compromised environment. Attackers often use tools like curl or wget to download the worm from specific URLs. The detection rule identifies these download attempts by monitoring process activities on Linux systems, focusing on command-line arguments that match known malicious URLs, thereby alerting security teams to potential threats. + +### Possible investigation steps + +- Review the alert details to identify the specific process name (either curl or wget) and the URL involved in the download attempt to confirm it matches one of the known malicious URLs listed in the query. +- Check the process execution context, including the user account under which the process was executed, to determine if it was initiated by a legitimate user or potentially compromised account. +- Investigate the source IP address and hostname of the affected Linux system to understand its role within the network and assess the potential impact of lateral movement. +- Examine the system's SSH logs to identify any unusual or unauthorized SSH connections that may indicate further compromise or lateral movement attempts. +- Analyze the network traffic logs for any outbound connections to the identified malicious URLs to confirm whether the download attempt was successful and if any additional payloads were retrieved. +- Review historical alerts and logs for any previous similar activities on the same host or user account to identify patterns or repeated attempts that may indicate a persistent threat. + +### False positive analysis + +- Legitimate administrative tasks using curl or wget to download files from the internet may trigger the rule. To manage this, security teams can create exceptions for specific URLs or IP addresses known to be safe and frequently accessed by administrators. +- Automated scripts or cron jobs that use curl or wget to download updates or configuration files from trusted internal or external sources might be flagged. Users can whitelist these scripts or the specific URLs they access to prevent unnecessary alerts. +- Development or testing environments where developers frequently download open-source tools or libraries using curl or wget could generate false positives. Implementing a policy to exclude these environments from the rule or setting up a separate monitoring profile for them can help reduce noise. +- Security tools or monitoring solutions that use curl or wget for health checks or data collection might be mistakenly identified. Identifying these tools and excluding their known benign activities from the rule can help maintain focus on genuine threats. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further lateral movement by the SSH-IT worm. +- Terminate any suspicious processes identified as using curl or wget with the malicious URLs to stop the download and execution of the worm. +- Conduct a thorough scan of the isolated host using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any instances of the SSH-IT worm. +- Review and reset credentials for any SSH accounts that may have been compromised, ensuring the use of strong, unique passwords and considering the implementation of multi-factor authentication (MFA). +- Analyze network logs and SSH access logs to identify any lateral movement or unauthorized access attempts, and take steps to secure any other potentially compromised systems. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Update firewall and intrusion detection/prevention system (IDS/IPS) rules to block the known malicious URLs and monitor for any future attempts to access them.""" [[rule.threat]] diff --git a/rules/linux/lateral_movement_telnet_network_activity_external.toml b/rules/linux/lateral_movement_telnet_network_activity_external.toml index 4e1372c9e34..b155af91730 100644 --- a/rules/linux/lateral_movement_telnet_network_activity_external.toml +++ b/rules/linux/lateral_movement_telnet_network_activity_external.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/06" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -88,6 +88,40 @@ sequence by process.entity_id ) ] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Connection to External Network via Telnet + +Telnet is a protocol offering a command-line interface for remote communication, often used for device management. However, its lack of encryption makes it vulnerable to interception, allowing adversaries to exploit it for unauthorized access or data exfiltration. The detection rule identifies Telnet connections to external IPs, flagging potential lateral movement by excluding known internal and reserved IP ranges. + +### Possible investigation steps + +- Review the alert details to identify the specific process.entity_id and destination IP address involved in the Telnet connection. +- Verify the legitimacy of the destination IP address by checking if it belongs to a known or trusted external entity, using threat intelligence sources or IP reputation services. +- Investigate the process details associated with the process.entity_id to determine the user account and command line arguments used during the Telnet session. +- Check the system logs and user activity on the host to identify any unusual behavior or unauthorized access attempts around the time of the Telnet connection. +- Assess whether the Telnet connection aligns with expected business operations or if it indicates potential lateral movement or data exfiltration attempts. + +### False positive analysis + +- Internal device management using Telnet may trigger false positives if the destination IPs are not included in the known internal ranges. Users should verify and update the list of internal IP ranges to include any additional internal networks used for legitimate Telnet connections. +- Automated scripts or monitoring tools that use Telnet for legitimate purposes can cause false positives. Identify these scripts and consider creating exceptions for their specific IP addresses or process names to prevent unnecessary alerts. +- Testing environments that simulate external connections for development purposes might be flagged. Ensure that IP addresses used in these environments are documented and excluded from the detection rule to avoid false positives. +- Legacy systems that rely on Telnet for communication with external partners or services may be mistakenly flagged. Review these systems and, if deemed secure, add their IP addresses to an exception list to reduce false alerts. +- Misconfigured network devices that inadvertently use Telnet for external communication can trigger alerts. Regularly audit network configurations and update the detection rule to exclude known benign IPs associated with these devices. + +### Response and remediation + +- Immediately isolate the affected Linux host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any active Telnet sessions on the affected host to stop ongoing malicious activity. +- Conduct a thorough review of the affected system's logs and processes to identify any unauthorized changes or additional compromised accounts. +- Change all passwords associated with the affected system and any other systems that may have been accessed using Telnet. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Implement network segmentation to limit Telnet access to only necessary internal systems and block Telnet traffic to external networks. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/linux/lateral_movement_telnet_network_activity_internal.toml b/rules/linux/lateral_movement_telnet_network_activity_internal.toml index 2f57dba3856..cd1412d6b2b 100644 --- a/rules/linux/lateral_movement_telnet_network_activity_internal.toml +++ b/rules/linux/lateral_movement_telnet_network_activity_internal.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/06" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -88,6 +88,41 @@ sequence by process.entity_id ) ] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Connection to Internal Network via Telnet + +Telnet is a protocol offering a command-line interface for remote device management, often used in network environments. Adversaries may exploit Telnet to move laterally within a network, accessing non-public IPs to execute commands or exfiltrate data. The detection rule identifies Telnet connections to internal IP ranges, flagging potential unauthorized access attempts, thus aiding in early threat detection and response. + +### Possible investigation steps + +- Review the process details to confirm the Telnet connection initiation by examining the process.entity_id and process.name fields to ensure the process is indeed Telnet. +- Analyze the destination IP address to determine if it falls within the specified non-public IP ranges, indicating an internal network connection attempt. +- Check the event.type field to verify that the Telnet process event is of type "start", confirming the initiation of a connection. +- Investigate the source host by reviewing host.os.type and other relevant host details to understand the context and legitimacy of the connection attempt. +- Correlate the Telnet activity with any other suspicious network or process activities on the same host to identify potential lateral movement or data exfiltration attempts. +- Consult historical logs and alerts to determine if there have been previous similar Telnet connection attempts from the same source, which might indicate a pattern or ongoing threat. + +### False positive analysis + +- Routine administrative tasks using Telnet within internal networks can trigger false positives. To manage this, create exceptions for known IP addresses or specific user accounts that regularly perform these tasks. +- Automated scripts or monitoring tools that use Telnet for legitimate purposes may be flagged. Identify these scripts and whitelist their associated processes or IP addresses to prevent unnecessary alerts. +- Internal testing environments often simulate network activities, including Telnet connections. Exclude IP ranges associated with these environments to reduce false positives. +- Legacy systems that rely on Telnet for communication might generate alerts. Document these systems and apply exceptions based on their IP addresses or hostnames to avoid repeated false positives. +- Regularly review and update the list of excluded IPs and processes to ensure that only legitimate activities are exempted, maintaining the effectiveness of the detection rule. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further lateral movement or data exfiltration. +- Terminate any active Telnet sessions on the affected host to stop unauthorized access. +- Conduct a thorough review of the affected host's system logs and Telnet session logs to identify any unauthorized commands executed or data accessed. +- Change all credentials that may have been exposed or used during the unauthorized Telnet sessions to prevent further unauthorized access. +- Apply security patches and updates to the affected host and any other systems that may be vulnerable to similar exploitation. +- Implement network segmentation to limit Telnet access to only necessary systems and ensure that Telnet is disabled on systems where it is not required. +- 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.""" [[rule.threat]] diff --git a/rules/linux/persistence_apt_package_manager_execution.toml b/rules/linux/persistence_apt_package_manager_execution.toml index 89411c0d829..ccdb27615e9 100644 --- a/rules/linux/persistence_apt_package_manager_execution.toml +++ b/rules/linux/persistence_apt_package_manager_execution.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/08" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -75,6 +75,41 @@ sequence by host.id with maxspan=5s ) ] by process.parent.entity_id ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious APT Package Manager Execution + +The APT package manager is a vital tool for managing software on Debian-based Linux systems, handling tasks like installation and updates. Adversaries may exploit APT by embedding malicious scripts to maintain persistence and control. The detection rule identifies unusual shell or script executions initiated by APT, signaling potential backdoor activities, thus aiding in early threat detection and response. + +### Possible investigation steps + +- Review the process execution details to identify the specific shell or script that was executed with APT as the parent process. Pay attention to the process names and arguments, such as "bash", "dash", "sh", etc., and the presence of the "-c" argument. +- Examine the command-line arguments and scripts executed by the suspicious process to determine if they contain any malicious or unexpected commands. +- Check the parent process details, specifically the APT process, to understand the context in which the shell or script was executed. This includes reviewing any recent package installations or updates that might have triggered the execution. +- Investigate the user account under which the suspicious process was executed to assess if it has been compromised or if it has elevated privileges that could be exploited. +- Correlate the event with other security logs or alerts from the same host to identify any additional indicators of compromise or related suspicious activities. +- Review the system's package management logs to identify any recent changes or anomalies in package installations or updates that could be linked to the suspicious execution. + +### False positive analysis + +- Legitimate administrative scripts executed by system administrators using APT may trigger the rule. To handle this, identify and document routine administrative tasks and create exceptions for these specific scripts or commands. +- Automated system maintenance scripts that use APT for updates or installations can be mistaken for suspicious activity. Review and whitelist these scripts by their specific command patterns or script names. +- Custom software deployment processes that involve APT and shell scripts might be flagged. Analyze these processes and exclude them by defining clear criteria for legitimate deployment activities. +- Security tools or monitoring solutions that interact with APT for scanning or auditing purposes may cause false positives. Verify these tools' operations and exclude their known benign processes from triggering the rule. +- Development environments where developers frequently use APT and shell scripts for testing and building software can lead to alerts. Establish a baseline of normal development activities and exclude these from the detection rule. + +### Response and remediation + +- Isolate the affected host immediately to prevent further unauthorized access or lateral movement within the network. +- Terminate any suspicious processes identified in the alert, particularly those initiated by the APT package manager that match the query criteria. +- Conduct a thorough review of the APT configuration files and scripts to identify and remove any injected malicious code or unauthorized modifications. +- Restore the affected system from a known good backup if malicious modifications are extensive or if the integrity of the system cannot be assured. +- Update all system packages and apply security patches to mitigate vulnerabilities that may have been exploited by the adversary. +- Monitor the affected host and network for any signs of re-infection or further suspicious activity, focusing on the execution of shell scripts and unauthorized network connections. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.""" [[rule.threat]] diff --git a/rules/linux/persistence_apt_package_manager_file_creation.toml b/rules/linux/persistence_apt_package_manager_file_creation.toml index a9d7f872d29..4585a2e22ed 100644 --- a/rules/linux/persistence_apt_package_manager_file_creation.toml +++ b/rules/linux/persistence_apt_package_manager_file_creation.toml @@ -2,7 +2,7 @@ creation_date = "2024/06/03" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -88,6 +88,41 @@ file.path : "/etc/apt/apt.conf.d/*" and not ( (process.name == "perl" and file.name : "e2scrub_all.tmp*") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 APT Package Manager Configuration File Creation + +APT is a crucial tool for managing software on Debian-based Linux systems, handling tasks like installation and updates. Adversaries may exploit APT by inserting malicious scripts into its configuration files, ensuring persistent access. The detection rule monitors for unauthorized file creation or renaming in APT's configuration directory, excluding legitimate processes, to identify potential tampering. + +### Possible investigation steps + +- Review the file creation or renaming event details, focusing on the file path to confirm it is within the APT configuration directory (/etc/apt/apt.conf.d/). +- Identify the process responsible for the file creation or renaming by examining the process.executable field, ensuring it is not one of the legitimate processes listed in the query. +- Investigate the origin and purpose of the newly created or renamed file by checking its contents for any suspicious or unauthorized scripts or configurations. +- Correlate the event with recent system activity to determine if there are any other related alerts or anomalies, such as unusual user logins or network connections, that could indicate a broader attack. +- Check the file's metadata, such as timestamps and ownership, to identify any discrepancies or signs of tampering that could suggest malicious activity. +- If the process responsible for the event is unknown or suspicious, conduct a deeper analysis of the process, including its parent process, command-line arguments, and any associated network activity. + +### False positive analysis + +- Legitimate package management operations by system tools like dpkg or apt-get can trigger alerts. To manage this, ensure these processes are included in the exclusion list within the detection rule. +- Temporary files created during package updates or installations, such as those with extensions like swp or dpkg-new, may cause false positives. Exclude these file extensions from triggering alerts. +- Automated system maintenance scripts or tools like puppet or chef-client might modify APT configuration files as part of their normal operations. Add these processes to the exclusion list to prevent unnecessary alerts. +- Custom scripts or administrative tasks that involve renaming or creating files in the APT configuration directory should be reviewed. If deemed safe, add these specific scripts or processes to the exclusion criteria. +- Processes running from directories like /nix/store or /var/lib/dpkg may be part of legitimate system operations. Consider excluding these paths if they are verified as non-threatening. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary. +- Conduct a thorough review of the newly created or renamed files in the /etc/apt/apt.conf.d/ directory to identify any malicious scripts or unauthorized changes. +- Remove any identified malicious files or scripts from the APT configuration directory to eliminate the persistence mechanism. +- Restore any legitimate configuration files from a known good backup to ensure the integrity of the APT configuration. +- Perform a comprehensive scan of the system using updated antivirus or endpoint detection tools to identify and remove any additional malware or unauthorized changes. +- 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 enhanced monitoring and logging for the APT configuration directory and related processes to detect similar threats in the future.""" [[rule.threat]] diff --git a/rules/linux/persistence_apt_package_manager_netcon.toml b/rules/linux/persistence_apt_package_manager_netcon.toml index 4fbac8005de..9e6715bb68f 100644 --- a/rules/linux/persistence_apt_package_manager_netcon.toml +++ b/rules/linux/persistence_apt_package_manager_netcon.toml @@ -2,7 +2,7 @@ creation_date = "2024/02/01" integration = ["endpoint"] maturity = "production" -updated_date = "2024/09/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -77,6 +77,41 @@ sequence by host.id with maxspan=5s ) and not process.executable == "/usr/bin/apt-listbugs" ] by process.parent.entity_id ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious APT Package Manager Network Connection + +The APT package manager is crucial for managing software on Debian-based Linux systems. Adversaries may exploit APT by injecting malicious scripts, gaining persistence and control. The detection rule identifies suspicious APT-triggered shell executions followed by unusual network connections, flagging potential backdoor activities and unauthorized access attempts. + +### Possible investigation steps + +- Review the process details to confirm the parent process is indeed 'apt' and check the command-line arguments for any unusual or unauthorized scripts being executed. +- Investigate the network connection details, focusing on the destination IP address to determine if it is known to be malicious or associated with suspicious activity. Cross-reference with threat intelligence sources. +- Examine the process tree to identify any child processes spawned by the suspicious shell execution, which may provide further insight into the attacker's actions or intentions. +- Check the system logs for any other recent unusual activities or alerts that might correlate with the suspicious APT activity, such as unauthorized user logins or file modifications. +- Assess the system for any signs of persistence mechanisms that may have been established, such as cron jobs or modified startup scripts, which could indicate a backdoor installation. +- If possible, capture and analyze network traffic to and from the destination IP to understand the nature of the communication and identify any data exfiltration or command and control activities. + +### False positive analysis + +- Legitimate administrative scripts executed by APT may trigger the rule if they involve shell commands followed by network connections. Users can create exceptions for known scripts by specifying their paths or hashes. +- Automated system updates or package installations that involve network connections might be flagged. Users should monitor and whitelist these routine operations by identifying the specific processes and network destinations involved. +- Network connections to internal or trusted IP addresses not covered by the existing CIDR exclusions could be mistakenly flagged. Users can expand the CIDR list to include additional trusted IP ranges specific to their environment. +- Use of alternative shell environments or custom scripts that invoke APT with network operations may cause false positives. Users should document and exclude these specific use cases by process name or command-line arguments. +- Non-standard APT configurations or third-party tools that interact with APT and initiate network connections might be misidentified. Users should review and whitelist these tools by their executable paths or process names. + +### Response and remediation + +- Isolate the affected host immediately to prevent further unauthorized network connections and potential lateral movement within the network. +- Terminate any suspicious processes identified as being executed by the APT package manager, especially those involving shell executions. +- Conduct a thorough review of the APT configuration files and scripts to identify and remove any injected malicious code or unauthorized modifications. +- Revert any unauthorized changes to the system or software packages by restoring from a known good backup, ensuring the integrity of the system. +- Update all system packages and apply security patches to close any vulnerabilities that may have been exploited by the attacker. +- Monitor network traffic for any further suspicious connections or activities originating from the affected host, using enhanced logging and alerting mechanisms. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised, ensuring a comprehensive response.""" [[rule.threat]] diff --git a/rules/linux/persistence_at_job_creation.toml b/rules/linux/persistence_at_job_creation.toml index cebef39e692..1989bb05cc7 100644 --- a/rules/linux/persistence_at_job_creation.toml +++ b/rules/linux/persistence_at_job_creation.toml @@ -2,7 +2,7 @@ creation_date = "2024/05/31" integration = ["endpoint"] maturity = "production" -updated_date = "2024/09/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -79,6 +79,41 @@ event.action in ("rename", "creation") and file.path : "/var/spool/cron/atjobs/* (process.name == "perl" and file.name : "e2scrub_all.tmp*") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 At Job Created or Modified + +The 'at' command in Linux schedules tasks for future execution, aiding system admins in automating routine jobs. However, attackers can exploit this for persistence, privilege escalation, or executing unauthorized commands. The detection rule identifies suspicious 'at' job creations or modifications by monitoring specific file paths and excluding benign processes, helping to flag potential malicious activities. + +### Possible investigation steps + +- Review the file path of the created or modified 'at' job to confirm it is within the monitored directory: /var/spool/cron/atjobs/*. Determine if the file path is expected or unusual for the system's typical operations. +- Identify the process that triggered the alert by examining the process.executable field. Check if the process is known and expected in the context of the system's normal operations. +- Investigate the user account associated with the process that created or modified the 'at' job. Determine if the account has legitimate reasons to schedule tasks or if it might be compromised. +- Check the contents of the 'at' job file to understand the commands or scripts scheduled for execution. Look for any suspicious or unauthorized commands that could indicate malicious intent. +- Correlate the event with other recent alerts or logs from the same host to identify any patterns or additional indicators of compromise, such as privilege escalation attempts or unauthorized access. +- Verify if there are any known vulnerabilities or exploits associated with the processes or commands involved in the alert, which could provide further context on the potential threat. + +### False positive analysis + +- System package managers like dpkg, rpm, and yum can trigger false positives when they create or modify at jobs during software installations or updates. To manage this, ensure these processes are included in the exclusion list within the detection rule. +- Automated system management tools such as Puppet and Chef may also create or modify at jobs as part of their routine operations. Add these tools to the exclusion list to prevent unnecessary alerts. +- Temporary files with extensions like swp or dpkg-remove can be mistakenly flagged. Exclude these file extensions from the rule to reduce false positives. +- Processes running from directories like /nix/store or /snap can be benign and should be considered for exclusion if they are part of regular system operations. +- If the process executable is null, it might indicate a benign system process that lacks a defined executable path. Consider reviewing these cases to determine if they are legitimate and adjust the rule accordingly. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious tasks. +- Terminate any suspicious processes associated with the creation or modification of 'at' jobs that are not part of the excluded benign processes. +- Review and remove any unauthorized 'at' jobs found in the /var/spool/cron/atjobs/ directory to eliminate persistence mechanisms. +- Conduct a thorough examination of the system for additional indicators of compromise, such as unauthorized user accounts or unexpected network connections. +- Restore the system 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 analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for 'at' job activities to detect similar threats in the future, ensuring that alerts are promptly reviewed and acted upon.""" [[rule.threat]] diff --git a/rules/linux/persistence_dnf_package_manager_plugin_file_creation.toml b/rules/linux/persistence_dnf_package_manager_plugin_file_creation.toml index 8ebf2a224c5..880d9d8a8bc 100644 --- a/rules/linux/persistence_dnf_package_manager_plugin_file_creation.toml +++ b/rules/linux/persistence_dnf_package_manager_plugin_file_creation.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/08" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -88,6 +88,42 @@ file.path : ("/usr/lib/python*/site-packages/dnf-plugins/*", "/etc/dnf/plugins/* (process.name == "perl" and file.name : "e2scrub_all.tmp*") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 DNF Package Manager Plugin File Creation + +DNF, a package manager for Fedora-based Linux systems, manages software installations and updates. It uses plugins to extend functionality, which can be targeted by attackers to insert malicious code, ensuring persistence and evasion. The detection rule monitors file creation in plugin directories, excluding legitimate processes, to identify unauthorized modifications indicative of potential backdoor activities. + +### Possible investigation steps + +- Review the file creation event details, focusing on the file path to confirm if it matches the monitored plugin directories: "/usr/lib/python*/site-packages/dnf-plugins/*" or "/etc/dnf/plugins/*". +- Identify the process responsible for the file creation by examining the process.executable field, ensuring it is not one of the legitimate processes listed in the exclusion criteria. +- Check the file extension of the newly created file to ensure it is not one of the excluded extensions like "swp", "swpx", or "swx". +- Investigate the origin and legitimacy of the process by reviewing its parent process and command line arguments to determine if it aligns with expected behavior. +- Correlate the event with any recent changes or updates in the system that might explain the file creation, such as package installations or system updates. +- Search for any additional suspicious activity or anomalies in the system logs around the time of the alert to identify potential indicators of compromise. +- If the file creation is deemed suspicious, consider isolating the affected system and conducting a deeper forensic analysis to assess the scope and impact of the potential threat. + +### False positive analysis + +- Legitimate software updates or installations may trigger file creation events in the DNF plugin directories. Users can mitigate this by ensuring that the processes involved in these updates are included in the exclusion list of the detection rule. +- System maintenance scripts or automated tasks that modify or create files in the plugin directories can be mistaken for malicious activity. To handle this, identify these scripts and add their executables to the exclusion list. +- Temporary files created by text editors or system processes, such as those with extensions like "swp", "swpx", or "swx", can be excluded by ensuring these extensions are part of the rule's exclusion criteria. +- Custom scripts or tools that interact with DNF plugins for legitimate purposes should be reviewed and, if deemed safe, their executables should be added to the exclusion list to prevent false positives. +- Processes running from directories like "/nix/store/*" or "/var/lib/dpkg/*" may be part of legitimate package management activities. Users should verify these processes and include them in the exclusion list if they are non-threatening. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. +- Conduct a thorough review of the newly created or modified files in the DNF plugin directories to identify any malicious code or unauthorized changes. +- Remove any identified malicious files or code from the DNF plugin directories to eliminate the backdoor and restore the integrity of the package manager. +- Revert any unauthorized changes to the system configuration or software settings to their original state using verified backups or system snapshots. +- Update all system packages and plugins to the latest versions to patch any vulnerabilities that may have been exploited by the attacker. +- Monitor the affected system and network for any signs of continued unauthorized access or suspicious activity, using enhanced logging and alerting mechanisms. +- Escalate the incident to the appropriate internal security team or external cybersecurity experts for further investigation and to ensure comprehensive remediation.""" [[rule.threat]] diff --git a/rules/linux/persistence_dpkg_package_installation_from_unusual_parent.toml b/rules/linux/persistence_dpkg_package_installation_from_unusual_parent.toml index b55731cca6e..72a34f4a85d 100644 --- a/rules/linux/persistence_dpkg_package_installation_from_unusual_parent.toml +++ b/rules/linux/persistence_dpkg_package_installation_from_unusual_parent.toml @@ -2,7 +2,7 @@ creation_date = "2024/07/09" integration = ["endpoint"] maturity = "production" -updated_date = "2024/11/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -59,6 +59,41 @@ query = ''' host.os.type:linux and event.category:process and event.type:start and event.action:exec and process.name:dpkg and process.args:("-i" or "--install") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 DPKG Package Installed by Unusual Parent Process + +DPKG is a core utility for managing Debian packages on Linux systems, crucial for software installation and maintenance. Adversaries may exploit DPKG to install malicious packages, leveraging unusual parent processes to evade detection. The detection rule identifies such anomalies by monitoring DPKG executions initiated by atypical parent processes, signaling potential unauthorized package installations. + +### Possible investigation steps + +- Review the process tree to identify the parent process of the dpkg execution. Determine if the parent process is legitimate or unusual for package installations. +- Examine the command-line arguments used with the dpkg command, specifically looking for the "-i" or "--install" flags, to understand what package was being installed. +- Check the source and integrity of the package being installed to ensure it is from a trusted repository or source. +- Investigate the user account under which the dpkg command 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 around the same timeframe to identify any related suspicious activities or patterns. +- Assess the system for any signs of compromise or unauthorized changes following the package installation. + +### False positive analysis + +- System updates or maintenance scripts may trigger the rule when legitimate administrative tools or scripts use dpkg to install updates. To handle this, identify and whitelist known maintenance scripts or processes that regularly perform package installations. +- Automated deployment tools like Ansible or Puppet might use dpkg for software deployment, leading to false positives. Exclude these tools by adding their process names to an exception list if they are part of your standard operations. +- Custom internal applications or scripts that manage software installations could also cause alerts. Review these applications and, if verified as safe, configure exceptions for their parent processes. +- Developers or system administrators using dpkg for testing or development purposes might inadvertently trigger the rule. Establish a policy for such activities and exclude known development environments or user accounts from triggering alerts. +- Backup or recovery operations that reinstall packages as part of their process can be mistaken for malicious activity. Identify these operations and exclude their associated processes from the rule. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized package installations or lateral movement by the adversary. +- Terminate the dpkg process if it is still running to stop any ongoing malicious package installation. +- Identify and remove any suspicious or unauthorized packages installed by the dpkg command using the package management tools available on the system. +- Conduct a thorough review of the system's package installation logs and history to identify any other potentially malicious packages or unusual installation activities. +- Restore the system from a known good backup if malicious packages have altered critical system components or configurations. +- Implement stricter access controls and monitoring on systems to prevent unauthorized use of package management utilities by non-administrative users or processes. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected, ensuring a coordinated response to the threat.""" [[rule.threat]] diff --git a/rules/linux/persistence_dpkg_unusual_execution.toml b/rules/linux/persistence_dpkg_unusual_execution.toml index 63beaf41029..9a96c8bd1b7 100644 --- a/rules/linux/persistence_dpkg_unusual_execution.toml +++ b/rules/linux/persistence_dpkg_unusual_execution.toml @@ -2,7 +2,7 @@ creation_date = "2024/07/09" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -64,6 +64,39 @@ process.group_leader.name != null and not ( process.parent.executable in ("/usr/share/debconf/frontend", "/usr/bin/unattended-upgrade") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 DPKG Execution + +DPKG is a core utility in Debian-based Linux systems for managing software packages. While essential for legitimate software management, adversaries can exploit DPKG to install or manipulate packages for malicious purposes, potentially gaining persistence or executing unauthorized code. The detection rule identifies anomalies by flagging DPKG executions initiated by unexpected processes, which may indicate unauthorized package management activities. + +### Possible investigation steps + +- Review the process details to identify the unexpected process that initiated the DPKG execution. Pay attention to the process.executable field to understand which script or binary was executed. +- Examine the process.parent.name and process.parent.executable fields to determine the parent process that launched the DPKG command. This can provide insights into whether the execution was part of a legitimate process chain or potentially malicious. +- Investigate the process.session_leader.name and process.group_leader.name fields to understand the broader context of the session and group leaders involved in the execution. This can help identify if the execution was part of a larger, coordinated activity. +- Check the system logs and any available audit logs around the time of the alert to gather additional context on the activities occurring on the system. Look for any other suspicious or related events. +- Assess the system for any unauthorized or unexpected package installations or modifications that may have occurred as a result of the DPKG execution. This can help determine if the system has been compromised. + +### False positive analysis + +- System maintenance scripts may trigger the rule if they execute DPKG commands outside of typical package management processes. To handle this, identify and whitelist these scripts by adding their parent process names or executables to the exception list. +- Automated software update tools, other than the ones specified in the rule, might cause false positives. Review the tools used in your environment and consider adding their executables to the exclusion criteria if they are verified as safe. +- Custom administrative scripts that manage packages could be flagged. Ensure these scripts are reviewed for legitimacy and then exclude their process names or paths from the rule to prevent unnecessary alerts. +- Development or testing environments where package manipulation is frequent might generate alerts. In such cases, consider creating environment-specific exceptions to reduce noise while maintaining security in production systems. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized package installations or potential lateral movement by the adversary. +- Terminate any suspicious processes identified as executing the DPKG command from unexpected sources to halt any ongoing malicious activities. +- Conduct a thorough review of recently installed or modified packages on the affected system to identify and remove any unauthorized or malicious software. +- Restore the system from a known good backup if malicious packages have been installed and cannot be safely removed without compromising system integrity. +- Update and patch the affected system to ensure all software is up-to-date, reducing the risk of exploitation through known vulnerabilities. +- Implement stricter access controls and monitoring on package management utilities to prevent unauthorized use, ensuring only trusted processes can execute DPKG commands. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_git_hook_execution.toml b/rules/linux/persistence_git_hook_execution.toml index 02a845525d1..19784470d1a 100644 --- a/rules/linux/persistence_git_hook_execution.toml +++ b/rules/linux/persistence_git_hook_execution.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/08" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -71,6 +71,41 @@ sequence by host.id with maxspan=3s [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")] by process.parent.entity_id ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Git Hook Command Execution + +Git hooks are scripts that automate tasks by executing before or after Git events like commits or pushes. While useful for developers, adversaries can exploit them to run malicious commands, gaining persistence or evading defenses. The detection rule identifies suspicious processes initiated by Git hooks, focusing on shell executions, to flag potential abuse on Linux systems. + +### Possible investigation steps + +- Review the alert details to identify the specific Git hook script path and the suspicious process name that was executed, as indicated by the process.args and process.name fields. +- Examine the process tree to understand the parent-child relationship, focusing on the process.parent.name and process.entity_id fields, to determine how the suspicious process was initiated. +- Check the Git repository's history and recent changes to the .git/hooks directory to identify any unauthorized modifications or additions to the hook scripts. +- Investigate the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it indicates potential compromise. +- Analyze the command-line arguments and environment variables of the suspicious process to gather more context on the nature of the executed command. +- Correlate this event with other security alerts or logs from the same host.id to identify any patterns or additional indicators of compromise. +- If possible, isolate the affected system and conduct a deeper forensic analysis to uncover any further malicious activity or persistence mechanisms. + +### False positive analysis + +- Developers using Git hooks for legitimate automation tasks may trigger this rule. To manage this, identify and document common scripts used in your development environment and create exceptions for these known benign processes. +- Continuous integration and deployment (CI/CD) systems often utilize Git hooks to automate workflows. Review the processes initiated by these systems and exclude them from detection if they are verified as non-malicious. +- Custom scripts executed via Git hooks for project-specific tasks can also cause false positives. Collaborate with development teams to catalog these scripts and adjust the detection rule to exclude them. +- Frequent updates or changes in Git repositories might lead to repeated triggering of the rule. Monitor these activities and, if consistent and verified as safe, consider adding them to an allowlist to reduce noise. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified as being executed from Git hooks, especially those involving shell executions. +- Conduct a thorough review of the .git/hooks directory on the affected system to identify and remove any unauthorized or malicious scripts. +- Restore any modified or deleted files from a known good backup to ensure system integrity. +- Implement monitoring for any future modifications to the .git/hooks directory to detect unauthorized changes promptly. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Review and update access controls and permissions for Git repositories to limit the ability to modify hooks to trusted users only.""" [[rule.threat]] diff --git a/rules/linux/persistence_git_hook_file_creation.toml b/rules/linux/persistence_git_hook_file_creation.toml index 240262b8807..8a11a5b3597 100644 --- a/rules/linux/persistence_git_hook_file_creation.toml +++ b/rules/linux/persistence_git_hook_file_creation.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/06" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -84,6 +84,41 @@ file.extension == null and process.executable != null and not ( (process.name == "perl" and file.name : "e2scrub_all.tmp*") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Git Hook Created or Modified + +Git hooks are scripts that automate tasks by executing before or after Git events like commits or pushes. While beneficial for developers, adversaries can exploit them to execute malicious code, maintaining persistence on a system. The detection rule identifies suspicious creation or modification of Git hooks on Linux, excluding benign processes, to flag potential abuse. + +### Possible investigation steps + +- Review the file path to confirm the location of the modified or created Git hook file and determine if it aligns with known repositories or projects on the system. +- Identify the process executable responsible for the creation or modification of the Git hook file and verify if it is a known and legitimate process, excluding those listed in the query. +- Check the timestamp of the event to correlate with any known user activities or scheduled tasks that might explain the modification or creation of the Git hook. +- Investigate the user account associated with the process that triggered the alert to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Examine the contents of the modified or newly created Git hook file to identify any potentially malicious code or unexpected changes. +- Cross-reference the event with other security logs or alerts to identify any related suspicious activities or patterns that might indicate a broader attack or compromise. + +### False positive analysis + +- System package managers like dpkg, rpm, and yum can trigger false positives when they create or modify Git hooks during package installations or updates. To manage this, ensure these executables are included in the exclusion list within the detection rule. +- Automated deployment tools such as Puppet and Chef may modify Git hooks as part of their configuration management processes. Exclude these tools by adding their executables to the exception list to prevent false alerts. +- Continuous integration and deployment systems like Jenkins or GitLab runners might modify Git hooks as part of their build processes. Identify and exclude these processes by adding their specific executables or paths to the exclusion criteria. +- Custom scripts or internal tools that are known to modify Git hooks for legitimate purposes should be identified and their executables added to the exclusion list to avoid unnecessary alerts. +- Consider excluding specific directories or paths that are known to be used by trusted applications or processes for Git hook modifications, ensuring these are not flagged as suspicious. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement or further execution of malicious code. +- Terminate any suspicious processes associated with the creation or modification of Git hooks that are not part of the known benign processes listed in the detection rule. +- Conduct a thorough review of the modified or newly created Git hook scripts to identify and remove any malicious code or unauthorized changes. +- Restore any affected Git repositories from a known good backup to ensure integrity and remove any persistence mechanisms. +- Implement file integrity monitoring on the .git/hooks directory to detect unauthorized changes in the future. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Review and update access controls and permissions for Git repositories to limit the ability to modify hook scripts to only trusted users.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_git_hook_netcon.toml b/rules/linux/persistence_git_hook_netcon.toml index 9e7e71207fd..f74e5ac390b 100644 --- a/rules/linux/persistence_git_hook_netcon.toml +++ b/rules/linux/persistence_git_hook_netcon.toml @@ -2,7 +2,7 @@ creation_date = "2024/07/15" integration = ["endpoint"] maturity = "production" -updated_date = "2024/09/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -76,6 +76,42 @@ sequence by host.id with maxspan=3s ) ] by process.parent.entity_id ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Git Hook Egress Network Connection + +Git hooks are scripts that automate tasks during Git operations like commits or pushes. Adversaries can exploit these hooks to execute unauthorized commands, maintain persistence, or initiate network connections for data exfiltration. The detection rule identifies suspicious network activities by monitoring script executions from Git hooks and subsequent egress connections to non-local IPs, flagging potential misuse. + +### Possible investigation steps + +- Review the process execution details to identify the specific Git hook script that triggered the alert. Check the process.args field for the exact script path within the .git/hooks directory. +- Investigate the parent process details to confirm the legitimacy of the Git operation. Verify the process.parent.name is "git" and assess whether the Git activity aligns with expected user or system behavior. +- Analyze the destination IP address involved in the network connection attempt. Use the destination.ip field to determine if the IP is known, trusted, or associated with any malicious activity. +- Check for any additional network connections from the same host around the time of the alert to identify potential patterns or additional suspicious activity. +- Correlate the alert with any recent changes in the repository or system that might explain the execution of the Git hook, such as recent commits or updates. +- Review user activity logs to determine if the Git operation was performed by an authorized user and if their actions align with their typical behavior. +- If suspicious activity is confirmed, isolate the affected system to prevent further unauthorized access or data exfiltration and initiate a deeper forensic analysis. + +### False positive analysis + +- Legitimate automated scripts or CI/CD pipelines may trigger Git hooks to perform network operations. Review the source and purpose of these scripts and consider excluding them if they are verified as non-threatening. +- Development environments often use Git hooks for tasks like fetching dependencies or updating remote services. Identify these common operations and create exceptions for known safe IP addresses or domains. +- Internal tools or services that rely on Git hooks for communication with other internal systems might be flagged. Ensure these tools are documented and whitelist their network activities if they are deemed secure. +- Frequent updates or deployments that involve Git hooks could lead to repeated alerts. Monitor the frequency and context of these alerts to determine if they are part of regular operations and adjust the rule to reduce noise. +- Consider the context of the network connection, such as the destination IP or domain. If the destination is a known and trusted entity, it may be appropriate to exclude it from triggering alerts. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized egress connections and potential data exfiltration. +- Terminate any suspicious processes identified as originating from Git hooks, particularly those executing shell scripts like bash, dash, or zsh. +- Conduct a thorough review of the .git/hooks directory on the affected system to identify and remove any unauthorized or malicious scripts. +- Reset credentials and access tokens associated with the affected Git repository to prevent further unauthorized access. +- Restore any modified or deleted files from a known good backup to ensure system integrity. +- Implement network monitoring to detect and block any future unauthorized egress connections from Git hooks or similar scripts. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems or repositories.""" [[rule.threat]] diff --git a/rules/linux/persistence_git_hook_process_execution.toml b/rules/linux/persistence_git_hook_process_execution.toml index ca62a6fc067..21f2c8c1fd1 100644 --- a/rules/linux/persistence_git_hook_process_execution.toml +++ b/rules/linux/persistence_git_hook_process_execution.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/08" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -85,6 +85,41 @@ process where host.os.type == "linux" and event.type == "start" and ) and not process.name in ("git", "dirname") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Git Hook Child Process + +Git hooks are scripts that automate tasks during Git operations like commits or pushes. Adversaries may exploit these hooks to execute unauthorized commands, masking malicious activities under legitimate processes. The detection rule identifies unusual child processes spawned by Git hooks, focusing on atypical scripts or executables in suspicious directories, signaling potential misuse. + +### Possible investigation steps + +- Review the process tree to understand the parent-child relationship, focusing on the parent process names listed in the query, such as "pre-commit" or "post-update", to determine the context of the spawned child process. +- Examine the command line arguments and environment variables of the suspicious child process to identify any potentially malicious or unauthorized commands being executed. +- Check the file paths of the executables involved, especially those in unusual directories like "/tmp/*" or "/var/tmp/*", to assess if they are legitimate or potentially harmful. +- Investigate the user account under which the suspicious process is running to determine if it has been compromised or is being used in an unauthorized manner. +- Correlate the event with other security logs or alerts from the same host to identify any patterns or additional indicators of compromise. +- Review recent Git activity on the repository to identify any unauthorized changes or suspicious commits that might indicate tampering with Git hooks. + +### False positive analysis + +- Legitimate development scripts: Developers may use scripts in directories like /tmp or /var/tmp for testing purposes. To handle this, create exceptions for known scripts or directories used by trusted developers. +- Custom shell usage: Developers might use shells like bash or zsh for legitimate automation tasks. Identify and whitelist these specific shell scripts if they are part of regular development workflows. +- Temporary file execution: Some applications may temporarily execute files from directories like /dev/shm or /run. Monitor these applications and exclude them if they are verified as non-threatening. +- Non-standard interpreters: Developers might use interpreters like php or perl for legitimate tasks. Review and whitelist these processes if they are part of approved development activities. +- System maintenance scripts: Scheduled tasks or maintenance scripts might run from /etc/cron.* or /etc/init.d. Verify these scripts and exclude them if they are part of routine system operations. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious commands. +- Terminate any suspicious processes identified by the detection rule, especially those originating from unusual directories or involving unexpected scripts or executables. +- Conduct a thorough review of the Git hooks on the affected system to identify and remove any unauthorized or malicious scripts. +- Restore any modified or deleted files from a known good backup to ensure system integrity and continuity of operations. +- Implement stricter access controls and permissions for Git repositories and associated directories to prevent unauthorized modifications to Git hooks. +- Monitor the affected system and related network activity closely for any signs of persistence or further compromise, using enhanced logging and alerting mechanisms. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been affected.""" [[rule.threat]] diff --git a/rules/linux/persistence_kernel_driver_load.toml b/rules/linux/persistence_kernel_driver_load.toml index 97ba74fa43d..aa11744f286 100644 --- a/rules/linux/persistence_kernel_driver_load.toml +++ b/rules/linux/persistence_kernel_driver_load.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/26" integration = ["auditd_manager"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -56,6 +56,41 @@ query = ''' driver where host.os.type == "linux" and event.action == "loaded-kernel-module" and auditd.data.syscall in ("init_module", "finit_module") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Kernel Driver Load + +Kernel modules extend the functionality of the Linux kernel, allowing dynamic loading of drivers and other components. Adversaries exploit this by loading malicious modules, or rootkits, to gain stealthy control over systems. The 'Kernel Driver Load' detection rule leverages auditd to monitor system calls like `init_module`, identifying unauthorized module loads indicative of potential rootkit activity, thus enhancing threat detection and system integrity. + +### Possible investigation steps + +- Review the alert details to identify the specific host where the kernel module was loaded, focusing on the host.os.type field to confirm it is a Linux system. +- Examine the event.action field to verify that the action was indeed "loaded-kernel-module" and check the auditd.data.syscall field for the specific system call used, either "init_module" or "finit_module". +- Investigate the timeline of events on the affected host around the time of the alert to identify any suspicious activities or changes, such as new user accounts, unexpected network connections, or file modifications. +- Check the system logs and audit logs on the affected host for any additional context or anomalies that coincide with the module load event. +- Identify the source and legitimacy of the loaded kernel module by examining the module's file path, signature, and associated metadata, if available. +- Assess the potential impact and scope of the incident by determining if similar alerts have been triggered on other hosts within the environment, indicating a broader campaign or attack. + +### False positive analysis + +- Legitimate kernel module updates or installations can trigger alerts. Regularly scheduled updates or installations by trusted administrators should be documented and excluded from monitoring to reduce noise. +- System utilities that load kernel modules as part of their normal operation may cause false positives. Identify these utilities and create exceptions for their expected behavior. +- Automated configuration management tools that deploy or update kernel modules can generate alerts. Ensure these tools are recognized and their activities are whitelisted. +- Development environments where kernel modules are frequently compiled and tested may lead to frequent alerts. Exclude specific development hosts or processes from monitoring to avoid unnecessary alerts. +- Security software that loads kernel modules for protection purposes might be flagged. Verify and exclude these modules if they are from trusted vendors. + +### Response and remediation + +- Isolate the affected system from the network immediately to prevent further malicious activity and lateral movement. +- Verify the legitimacy of the loaded kernel module by checking its source and integrity. If the module is unauthorized or suspicious, unload it using appropriate system commands. +- Conduct a thorough scan of the system using updated antivirus or anti-malware tools to identify and remove any additional malicious components or rootkits. +- Review and analyze system logs, especially those related to auditd, to identify any unauthorized access or changes made by the adversary. This can help in understanding the scope of the compromise. +- Restore the system from a known good backup if the integrity of the system is in question and if the malicious activity cannot be fully remediated. +- Implement stricter access controls and monitoring on kernel module loading activities to prevent unauthorized actions in the future. This may include restricting module loading to trusted users or processes. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/linux/persistence_kernel_driver_load_by_non_root.toml b/rules/linux/persistence_kernel_driver_load_by_non_root.toml index 216b6be53ed..dc31b699233 100644 --- a/rules/linux/persistence_kernel_driver_load_by_non_root.toml +++ b/rules/linux/persistence_kernel_driver_load_by_non_root.toml @@ -2,7 +2,7 @@ creation_date = "2024/01/10" integration = ["auditd_manager"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -62,6 +62,41 @@ query = ''' driver where host.os.type == "linux" and event.action == "loaded-kernel-module" and auditd.data.syscall in ("init_module", "finit_module") and user.id != "0" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Kernel Driver Load by non-root User + +Kernel modules extend the functionality of the Linux kernel, allowing dynamic loading of drivers or features. Typically, only root users can load these modules due to their potential to alter system behavior. Adversaries may exploit this by loading malicious modules, such as rootkits, to gain control and evade detection. The detection rule identifies non-root users attempting to load modules, signaling potential unauthorized activity. + +### Possible investigation steps + +- Review the alert details to identify the non-root user (user.id) involved in the kernel module loading attempt. +- Check the system logs and audit logs for any additional context around the time of the event, focusing on the specific system calls (init_module, finit_module) used. +- Investigate the source and legitimacy of the kernel module being loaded by examining the module's file path and associated metadata. +- Assess the user's recent activity and permissions to determine if there are any signs of privilege escalation or unauthorized access. +- Correlate this event with other security alerts or anomalies on the same host to identify potential patterns of malicious behavior. +- Verify the integrity and security posture of the affected system by running a comprehensive malware and rootkit scan. + +### False positive analysis + +- Legitimate software or system utilities may occasionally load kernel modules as part of their normal operation. Identify these applications and verify their behavior to ensure they are not malicious. +- Development environments or testing scenarios might involve non-root users loading kernel modules for legitimate purposes. Consider creating exceptions for these specific users or processes after thorough validation. +- Some system management tools or scripts executed by non-root users might trigger this rule. Review these tools and, if deemed safe, add them to an exception list to prevent unnecessary alerts. +- In environments where non-root users are granted specific permissions to load kernel modules, ensure these permissions are documented and monitored. Adjust the rule to exclude these known and authorized activities. +- Regularly review and update the list of exceptions to ensure that only verified and non-threatening behaviors are excluded, maintaining the integrity of the detection rule. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the adversary. +- Terminate any suspicious processes associated with the non-root user attempting to load the kernel module to halt any ongoing malicious activity. +- Conduct a thorough review of the loaded kernel modules on the affected system to identify and remove any unauthorized or malicious modules. +- Reset credentials and review permissions for the non-root user involved in the alert to prevent further unauthorized actions. +- Escalate the incident to the security operations team for a deeper forensic analysis to determine the scope of the compromise and identify any additional affected systems. +- Implement enhanced monitoring and logging for kernel module loading activities across all systems to detect similar threats in the future. +- Review and update security policies to ensure that only authorized users have the necessary permissions to load kernel modules, reducing the risk of unauthorized access.""" [[rule.threat]] diff --git a/rules/linux/persistence_kernel_object_file_creation.toml b/rules/linux/persistence_kernel_object_file_creation.toml index 4d95f4e8f37..495da198dd3 100644 --- a/rules/linux/persistence_kernel_object_file_creation.toml +++ b/rules/linux/persistence_kernel_object_file_creation.toml @@ -2,7 +2,7 @@ creation_date = "2024/12/19" integration = ["endpoint"] maturity = "production" -updated_date = "2024/12/19" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -59,6 +59,41 @@ event.category:file and host.os.type:linux and event.type:creation and file.exte file.path:/var/tmp/mkinitramfs_* or process.executable:/snap/* or process.name:cpio ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Kernel Object File Creation + +Kernel object files (.ko) are loadable modules that extend the functionality of the Linux kernel, often used for adding drivers or system features. Adversaries exploit this by loading malicious modules, such as rootkits, to gain control and evade detection. The detection rule identifies suspicious .ko file creation, excluding benign paths, to flag potential threats while minimizing false positives. + +### Possible investigation steps + +- Review the file path of the created .ko file to determine if it is located in a suspicious or unusual directory that is not excluded by the rule, such as /var/tmp or /usr/local. +- Examine the process that created the .ko file by checking the process.executable and process.name fields to identify if it is a known legitimate process or potentially malicious. +- Investigate the parent process of the process that created the .ko file to understand the context of how the file was created and if it was initiated by a legitimate user action or a script. +- Check for any recent system changes or anomalies around the time of the .ko file creation, such as new user accounts, changes in system configurations, or other suspicious file activities. +- Look for any associated network activity from the host around the time of the .ko file creation to identify potential command and control communications or data exfiltration attempts. +- Correlate the alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise that may suggest a broader attack campaign. + +### False positive analysis + +- Kernel updates and system maintenance activities can generate .ko files in legitimate scenarios. Users should monitor for these activities and consider excluding paths related to official update processes. +- Custom kernel module development by developers or system administrators may trigger this rule. Establish a process to whitelist known development environments or specific user accounts involved in module creation. +- Automated system recovery tools, such as those using mkinitramfs, may create .ko files. Ensure these paths are excluded as indicated in the rule to prevent unnecessary alerts. +- Snap package installations might involve .ko file creation. Exclude the /snap/ directory to avoid false positives from legitimate package installations. +- Backup and restoration processes using tools like cpio can lead to .ko file creation. Verify these processes and exclude them if they are part of routine system operations. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Terminate any suspicious processes associated with the creation of the .ko file, especially those not originating from known benign paths. +- Remove the suspicious .ko file from the system to prevent it from being loaded into the kernel. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious components. +- Review system logs and audit trails to identify any unauthorized access or changes made around the time of the .ko file creation. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign. +- Implement additional monitoring and alerting for similar activities, ensuring that any future attempts to create or load unauthorized .ko files are promptly detected and addressed.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_lkm_configuration_file_creation.toml b/rules/linux/persistence_lkm_configuration_file_creation.toml index ba7808de531..b1ca34adf35 100644 --- a/rules/linux/persistence_lkm_configuration_file_creation.toml +++ b/rules/linux/persistence_lkm_configuration_file_creation.toml @@ -2,7 +2,7 @@ creation_date = "2024/12/17" integration = ["endpoint"] maturity = "production" -updated_date = "2024/12/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -61,6 +61,42 @@ file.path like~ ( (process.name == "perl" and file.name : "e2scrub_all.tmp*") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Loadable Kernel Module Configuration File Creation + +Loadable Kernel Modules (LKMs) are components that can be dynamically loaded into the Linux kernel to extend its functionality without rebooting. Adversaries exploit this by creating or altering LKM configuration files to ensure their malicious modules load at startup, achieving persistence. The detection rule identifies suspicious file creation or renaming activities in key directories, excluding benign processes, to flag potential threats. + +### Possible investigation steps + +- Review the file path and name to determine if it matches any known or expected LKM configuration files, focusing on paths like /etc/modules, /etc/modprobe.d/*, and others specified in the query. +- Examine the process executable responsible for the file creation or renaming to identify if it is a known or trusted application, especially if it is not in the list of excluded executables. +- Check the process name and executable path for any anomalies or signs of masquerading, particularly if they are not in the list of excluded names or paths. +- Investigate the user account associated with the process to determine if it has legitimate access or if it might be compromised. +- Correlate the event with other recent system activities to identify any patterns or additional suspicious behavior, such as other file modifications or network connections. +- Review system logs for any related entries that might provide additional context or evidence of malicious activity. +- Assess the risk and impact of the detected activity on the system's security posture and determine if further containment or remediation actions are necessary. + +### False positive analysis + +- System package managers like dpkg, rpm, and yum may trigger false positives when they update or install legitimate kernel modules. To handle this, exclude these processes by adding them to the exception list in the detection rule. +- Automated system management tools such as Puppet, Chef, and Ansible can create or modify LKM configuration files during routine operations. Exclude these processes by specifying their executables in the exception criteria. +- Temporary files created by text editors or system processes, such as those with extensions like swp or swx, can be mistaken for suspicious activity. Exclude these file extensions to reduce false positives. +- Processes running from specific directories like /nix/store or /snap may be part of legitimate software installations. Add these paths to the exclusion list to prevent unnecessary alerts. +- Scheduled tasks or cron jobs that involve file operations in the monitored directories might be flagged. Identify and exclude these processes by their names or paths to minimize false positives. + +### Response and remediation + +- Isolate the affected system from the network to prevent further propagation of the malicious loadable kernel module. +- Terminate any suspicious processes identified in the alert that are associated with the creation or modification of LKM configuration files. +- Remove or revert any unauthorized changes to LKM configuration files in the specified directories to prevent the malicious module from loading on reboot. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious components. +- Review system logs and the history of executed commands to identify the initial vector of compromise and any other affected systems. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Implement additional monitoring and alerting for similar suspicious activities to enhance detection and response capabilities for future incidents.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_pluggable_authentication_module_creation.toml b/rules/linux/persistence_pluggable_authentication_module_creation.toml index fd3e0bb6fd6..6e3b3b33a1a 100644 --- a/rules/linux/persistence_pluggable_authentication_module_creation.toml +++ b/rules/linux/persistence_pluggable_authentication_module_creation.toml @@ -2,7 +2,7 @@ creation_date = "2024/03/06" integration = ["endpoint"] maturity = "production" -updated_date = "2024/12/16" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -71,6 +71,41 @@ process.executable != null and ( (process.name == "perl" and file.name like~ "e2scrub_all.tmp*") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Creation or Modification of Pluggable Authentication Module or Configuration + +Pluggable Authentication Modules (PAM) are integral to Linux systems, managing authentication tasks. Adversaries may exploit PAM by creating or altering its modules or configurations to gain persistence or capture credentials. The detection rule identifies suspicious activities by monitoring file operations in PAM directories, excluding legitimate processes, thus highlighting potential unauthorized modifications. + +### Possible investigation steps + +- Review the file path and extension to determine if the modified or created file is a PAM shared object or configuration file, focusing on paths like "/lib/security/*", "/etc/pam.d/*", and "/etc/security/pam_*". +- Identify the process executable responsible for the file operation and verify if it is listed as an excluded legitimate process, such as "/bin/dpkg" or "/usr/bin/yum". If not, investigate the process further. +- Check the process execution history and command line arguments to understand the context of the file operation and assess if it aligns with typical system administration tasks. +- Investigate the user account associated with the process to determine if it has legitimate access and permissions to modify PAM files, and check for any signs of compromise or misuse. +- Examine recent system logs and security alerts for any related suspicious activities or anomalies that might indicate a broader attack or compromise. +- If the file operation is deemed suspicious, consider restoring the original PAM configuration from a known good backup and monitor the system for any further unauthorized changes. + +### False positive analysis + +- Package management operations: Legitimate package managers like dpkg, rpm, and yum may trigger the rule during software updates or installations. To handle this, exclude these processes by adding them to the exception list in the rule configuration. +- System updates and maintenance: Processes such as pam-auth-update and systemd may modify PAM configurations during routine system updates. Exclude these processes to prevent false positives. +- Temporary files: Files with extensions like swp, swpx, and swx are often temporary and not indicative of malicious activity. Exclude these extensions to reduce noise. +- Development environments: Paths like /nix/store/* and /snap/* may be used in development or containerized environments. Consider excluding these paths if they are part of a known and secure setup. +- Automated scripts: Scripts using tools like sed or perl may create temporary files that match the rule's criteria. Exclude these specific patterns if they are part of regular, non-malicious operations. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Review the specific PAM module or configuration file that was created or modified to understand the changes made and assess the potential impact on system security. +- Restore the affected PAM files from a known good backup to ensure the integrity of the authentication process and remove any malicious modifications. +- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to identify and remove any additional malicious software that may have been introduced. +- Monitor the system and network for any signs of continued unauthorized access or suspicious activity, focusing on the indicators of compromise related to PAM manipulation. +- 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 PAM-related activities to enhance detection capabilities and prevent similar threats in the future.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_pluggable_authentication_module_creation_in_unusual_dir.toml b/rules/linux/persistence_pluggable_authentication_module_creation_in_unusual_dir.toml index be09d78657f..8490fb0ed03 100644 --- a/rules/linux/persistence_pluggable_authentication_module_creation_in_unusual_dir.toml +++ b/rules/linux/persistence_pluggable_authentication_module_creation_in_unusual_dir.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/06" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -58,6 +58,41 @@ file where host.os.type == "linux" and event.type == "creation" and file.name li ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Pluggable Authentication Module (PAM) Creation in Unusual Directory + +Pluggable Authentication Modules (PAM) are integral to Linux systems, managing authentication tasks. Adversaries may exploit PAM by creating malicious modules in non-standard directories, aiming to gain persistence or capture credentials. The detection rule identifies such anomalies by monitoring the creation of PAM files outside typical system paths, excluding benign processes and known directories, thus highlighting potential threats. + +### Possible investigation steps + +- Review the file creation event details, focusing on the file path and name to determine the exact location and nature of the PAM shared object file created. +- Investigate the process that created the file by examining the process name and its parent process to understand the context and legitimacy of the file creation. +- Check the user account associated with the process that created the file to assess if it has the necessary permissions and if the activity aligns with typical user behavior. +- Analyze recent system logs and command history for any suspicious activities or commands that might indicate an attempt to compile or move PAM modules. +- Correlate the event with other security alerts or anomalies on the system to identify potential patterns or coordinated actions that could indicate a broader compromise. +- If possible, retrieve and analyze the contents of the PAM shared object file to identify any malicious code or indicators of compromise. + +### False positive analysis + +- Development and testing environments may compile PAM modules in temporary directories. To manage this, exclude paths commonly used for development, such as "/tmp/dev/*" or "/var/tmp/test/*". +- Containerized applications might create PAM modules in non-standard directories. Exclude processes like "dockerd" and "containerd" to prevent false positives from container operations. +- Package managers or system update tools may temporarily store PAM modules in unusual directories during updates. Exclude paths like "/var/cache/pacman/pkg/*" or "/var/lib/dpkg/tmp.ci/*" to avoid alerts during legitimate system updates. +- Custom scripts or automation tools might generate PAM modules in user-specific directories. Identify and exclude these specific scripts or paths if they are known to be safe and necessary for operations. +- Temporary backup or recovery operations might involve copying PAM modules to non-standard locations. Exclude paths used for backups, such as "/backup/*" or "/recovery/*", if these operations are verified as secure. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Conduct a thorough review of the unusual directory where the PAM file was created to identify any other suspicious files or activities, and remove any malicious files found. +- Analyze the process that created the PAM file to determine if it was initiated by a legitimate user or process, and terminate any malicious processes. +- Reset credentials for any accounts that may have been compromised, focusing on those with elevated privileges or access to sensitive systems. +- Restore the affected system from a known good backup to ensure that no malicious modifications persist. +- Implement additional monitoring on the affected system and similar systems to detect any further attempts to create PAM files in unusual directories. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_pluggable_authentication_module_source_download.toml b/rules/linux/persistence_pluggable_authentication_module_source_download.toml index c80244fef6e..afd726f6743 100644 --- a/rules/linux/persistence_pluggable_authentication_module_source_download.toml +++ b/rules/linux/persistence_pluggable_authentication_module_source_download.toml @@ -2,7 +2,7 @@ creation_date = "2024/12/16" integration = ["endpoint"] maturity = "production" -updated_date = "2024/12/16" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -44,6 +44,40 @@ process where host.os.type == "linux" and event.type == "start" and event.action process.name in ("curl", "wget") and process.args like~ "https://github.com/linux-pam/linux-pam/releases/download/v*/Linux-PAM-*.tar.xz" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Pluggable Authentication Module (PAM) Source Download + +Pluggable Authentication Modules (PAM) are integral to Linux systems, managing authentication tasks. Adversaries may exploit PAM by downloading its source code to insert backdoors, compromising authentication. The detection rule identifies suspicious downloads of PAM source files using tools like `curl` or `wget`, flagging potential threats to system integrity and user credentials. + +### Possible investigation steps + +- Review the process details to confirm the use of `curl` or `wget` for downloading the PAM source file, focusing on the `process.name` and `process.args` fields to verify the URL pattern matches the suspicious download. +- Check the user account associated with the process execution to determine if the activity was initiated by a legitimate user or a potential adversary. +- Investigate the system's command history and logs to identify any preceding or subsequent commands that might indicate further malicious activity or attempts to compile and install the downloaded PAM source. +- Examine network logs for any unusual outbound connections or data exfiltration attempts following the download, which could suggest further compromise. +- Assess the integrity of existing PAM modules on the system to ensure no unauthorized modifications or backdoors have been introduced. +- Correlate this event with other alerts or anomalies on the same host to identify patterns or a broader attack campaign. + +### False positive analysis + +- Legitimate system administrators or developers may download PAM source files for testing or development purposes. To handle this, create exceptions for known user accounts or IP addresses that regularly perform such downloads. +- Automated scripts or configuration management tools might use `curl` or `wget` to download PAM source files as part of routine updates or system setups. Identify these scripts and whitelist their activities to prevent false positives. +- Security researchers or auditors may download PAM source files to conduct security assessments. Establish a process to verify and approve these activities, allowing exceptions for recognized research teams or individuals. +- Educational institutions or training environments might download PAM source files for instructional purposes. Implement a policy to exclude these environments from triggering alerts, ensuring they are recognized as non-threatening. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any active `curl` or `wget` processes identified in the alert to stop the download of potentially malicious PAM source files. +- Conduct a thorough review of PAM configuration files and shared object files on the affected system to identify and remove any unauthorized modifications or backdoors. +- Restore the affected system from a known good backup if unauthorized changes to PAM files are detected and cannot be easily reversed. +- Implement stricter access controls and monitoring on systems handling PAM configurations to prevent unauthorized downloads or modifications in the future. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network. +- Update detection mechanisms to monitor for similar download attempts and unauthorized modifications to critical authentication components.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_potential_persistence_script_executable_bit_set.toml b/rules/linux/persistence_potential_persistence_script_executable_bit_set.toml index 20152cf97b1..9281e909bcd 100644 --- a/rules/linux/persistence_potential_persistence_script_executable_bit_set.toml +++ b/rules/linux/persistence_potential_persistence_script_executable_bit_set.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/08" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -85,6 +85,40 @@ process.args : ( (process.name == "install" and process.args : "-m*" and process.args : ("7*", "5*", "3*", "1*")) ) and not process.parent.executable : "/var/lib/dpkg/*" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Executable Bit Set for Potential Persistence Script + +In Linux environments, scripts with executable permissions can be used to automate tasks, including system start-up processes. Adversaries exploit this by setting executable bits on scripts in directories typically used for persistence, allowing malicious code to run automatically. The detection rule identifies such activities by monitoring for changes in executable permissions in these directories, signaling potential unauthorized persistence attempts. + +### Possible investigation steps + +- Review the process details to identify the specific script or file that had its executable bit set, focusing on the process.args field to determine the exact file path. +- Examine the process.parent.executable field to understand the parent process that initiated the permission change, which can provide context on whether the action was part of a legitimate process or potentially malicious activity. +- Check the user account associated with the process to determine if the action was performed by a legitimate user or a compromised account. +- Investigate the history of the file in question, including recent modifications and the creation date, to assess if it aligns with known system changes or updates. +- Analyze the contents of the script or file to identify any suspicious or unauthorized code that could indicate malicious intent. +- Correlate this event with other recent alerts or logs from the same host to identify patterns or additional indicators of compromise that may suggest a broader persistence mechanism. + +### False positive analysis + +- System administrators or automated scripts may legitimately change executable permissions in directories like /etc/init.d or /etc/cron* for maintenance or updates. To handle these, create exceptions for known administrative scripts or processes that regularly perform these actions. +- Software installations or updates might trigger this rule when they modify startup scripts or configuration files. Users can mitigate this by excluding processes originating from trusted package managers or installation paths, such as /var/lib/dpkg. +- Custom user scripts in home directories, especially in /home/*/.config/autostart, may be flagged if users set them to run at startup. To reduce false positives, maintain a whitelist of user scripts that are known and approved for startup execution. +- Security tools or monitoring solutions might adjust permissions as part of their operations. Identify these tools and exclude their processes from triggering the rule to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes identified in the alert that are associated with unauthorized script execution. +- Remove or disable the executable permissions on the identified scripts to prevent further unauthorized execution. +- Conduct a thorough review of the affected directories to identify and remove any additional unauthorized scripts or files. +- Restore any modified system files or configurations from a known good backup to ensure system integrity. +- Monitor the system for any signs of re-infection or further unauthorized changes, focusing on the directories and processes highlighted in the alert. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/linux/persistence_process_capability_set_via_setcap.toml b/rules/linux/persistence_process_capability_set_via_setcap.toml index b7312ca0f94..3b4231f225d 100644 --- a/rules/linux/persistence_process_capability_set_via_setcap.toml +++ b/rules/linux/persistence_process_capability_set_via_setcap.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/08" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -68,6 +68,39 @@ process.name == "setcap" and not ( process.parent.name in ("jem", "vzctl") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Process Capability Set via setcap Utility + +The `setcap` utility in Linux assigns specific capabilities to executables, allowing them to perform privileged tasks without full root access. While beneficial for security, adversaries can exploit this to maintain persistence or escalate privileges by misconfiguring capabilities. The detection rule identifies suspicious `setcap` usage by monitoring process execution patterns, excluding benign parent processes, to flag potential misuse. + +### Possible investigation steps + +- Review the process execution details to confirm the use of the setcap utility, focusing on the process name and event action fields to ensure the alert is not a false positive. +- Investigate the parent process executable and name to determine if the setcap command was executed by a potentially malicious or unexpected process, especially if it is not among the excluded benign parent processes. +- Check the capabilities that were set by the setcap command to assess if they could allow privilege escalation or persistence, and determine if they align with normal operational requirements. +- Examine the timeline of events around the setcap execution to identify any preceding or subsequent suspicious activities that might indicate a broader attack or compromise. +- Correlate the alert with other security events or logs from the same host to identify any patterns or additional indicators of compromise that could suggest a coordinated attack. + +### False positive analysis + +- Legitimate software installations or updates may trigger the rule when package managers like dpkg or Docker set capabilities during their processes. To handle this, exclude paths such as /var/lib/dpkg/* and /var/lib/docker/* from the detection rule. +- Development environments or containerized applications might use setcap for testing purposes. Exclude processes originating from /tmp/newroot/* and /var/tmp/newroot/* to reduce noise from these environments. +- Custom scripts or administrative tools that use setcap for legitimate configuration tasks can be excluded by identifying their parent process names and adding them to the exclusion list, similar to the existing exclusions for jem and vzctl. +- Regular audits of the exclusion list should be conducted to ensure that no malicious processes are inadvertently whitelisted, maintaining a balance between reducing false positives and ensuring security. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker. +- Terminate any suspicious processes associated with the `setcap` utility that are not part of legitimate administrative tasks. +- Review and remove any unnecessary capabilities set on executables using the `setcap` utility to prevent privilege escalation. +- Conduct a thorough audit of the system to identify any backdoors or unauthorized changes made by the attacker, and remove them. +- Restore affected systems from a known good backup if unauthorized changes or persistent threats are detected. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised. +- Implement enhanced monitoring and logging for `setcap` usage and similar privilege escalation attempts to improve future detection capabilities.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_rc_local_error_via_syslog.toml b/rules/linux/persistence_rc_local_error_via_syslog.toml index 6a62b00b786..e85ddb3e683 100644 --- a/rules/linux/persistence_rc_local_error_via_syslog.toml +++ b/rules/linux/persistence_rc_local_error_via_syslog.toml @@ -2,7 +2,7 @@ creation_date = "2024/06/21" integration = ["system"] maturity = "production" -updated_date = "2024/09/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -56,6 +56,39 @@ query = ''' host.os.type:linux and event.dataset:system.syslog and process.name:rc.local and message:("Connection refused" or "No such file or directory" or "command not found") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious rc.local Error Message + +The rc.local script is crucial in Linux systems, executing commands at boot. Adversaries may exploit this by inserting malicious scripts to gain persistence. The detection rule monitors syslog for specific error messages linked to rc.local, such as "Connection refused," indicating potential tampering. This proactive monitoring helps identify unauthorized modifications, mitigating persistent threats. + +### Possible investigation steps + +- Review the syslog entries for the specific error messages "Connection refused," "No such file or directory," or "command not found" associated with the rc.local process to understand the context and frequency of these errors. +- Check the rc.local file for any recent modifications or unusual entries that could indicate tampering or unauthorized changes. +- Investigate the source of the error messages by identifying any related processes or network connections that might have triggered the "Connection refused" error. +- Examine the system's boot logs and startup scripts to identify any anomalies or unauthorized scripts that may have been introduced. +- Cross-reference the timestamps of the error messages with other system logs to identify any correlated suspicious activities or changes in the system. + +### False positive analysis + +- Legitimate software updates or installations may modify the rc.local file, triggering error messages. Users can create exceptions for known update processes by identifying the specific software and excluding its related syslog entries. +- Custom scripts or administrative tasks that intentionally modify rc.local for legitimate purposes might cause false alerts. Document these scripts and add them to an exclusion list to prevent unnecessary alerts. +- Network configuration changes can lead to temporary "Connection refused" errors. If these changes are expected, users should temporarily adjust the monitoring rule to ignore these specific messages during the maintenance window. +- System misconfigurations or missing dependencies might result in "No such file or directory" or "command not found" errors. Regularly audit system configurations and ensure all necessary files and commands are correctly installed to minimize these false positives. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or spread of potential malware. +- Review the rc.local file for unauthorized modifications and restore it from a known good backup if tampering is confirmed. +- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to identify and remove any malicious scripts or software. +- Check for additional persistence mechanisms by reviewing other boot or logon initialization scripts and scheduled tasks. +- Escalate the incident to the security operations team for further investigation and to determine if other systems are affected. +- Implement enhanced monitoring on the affected system and similar systems to detect any future unauthorized changes to boot scripts. +- Review and update access controls and permissions to ensure that only authorized personnel can modify critical system files like rc.local.""" [[rule.threat]] diff --git a/rules/linux/persistence_rc_local_service_already_running.toml b/rules/linux/persistence_rc_local_service_already_running.toml index 0027fc21226..54ee65cd6ff 100644 --- a/rules/linux/persistence_rc_local_service_already_running.toml +++ b/rules/linux/persistence_rc_local_service_already_running.toml @@ -2,7 +2,7 @@ creation_date = "2024/06/21" integration = ["endpoint"] maturity = "production" -updated_date = "2024/09/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -68,6 +68,39 @@ query = ''' process where host.os.type == "linux" and event.type == "info" and event.action == "already_running" and process.parent.args == "/etc/rc.local" and process.parent.args == "start" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Execution of rc.local Script + +The `/etc/rc.local` script is a legacy Linux initialization script executed at the end of the boot process. While not enabled by default, attackers can exploit it to persistently run malicious commands upon system reboot. The detection rule identifies potential misuse by monitoring for the `already_running` event action linked to `rc-local.service`, indicating the script's execution, thus alerting to possible persistence tactics. + +### Possible investigation steps + +- Review the system logs to identify any recent changes or modifications to the /etc/rc.local file, focusing on timestamps and user accounts involved in the changes. +- Examine the contents of the /etc/rc.local file to identify any suspicious or unauthorized commands or scripts that may have been added. +- Investigate the process tree and parent processes associated with the rc-local.service to determine if there are any unusual or unexpected parent processes that could indicate compromise. +- Check for any other persistence mechanisms or indicators of compromise on the system, such as unauthorized user accounts or scheduled tasks, to assess the broader impact of the potential threat. +- Correlate the event with other security alerts or logs from the same host to identify any patterns or related activities that could provide additional context or evidence of malicious behavior. + +### False positive analysis + +- System maintenance scripts: Some Linux distributions or administrators may use the rc.local script for legitimate system maintenance tasks. Review the script's content to verify its purpose and consider excluding these known benign scripts from triggering alerts. +- Custom startup configurations: Organizations might have custom startup configurations that utilize rc.local for non-malicious purposes. Document these configurations and create exceptions in the detection rule to prevent unnecessary alerts. +- Legacy applications: Certain legacy applications might rely on rc.local for initialization. Identify these applications and assess their necessity. If deemed safe, exclude their execution from the rule to reduce false positives. +- Testing environments: In testing or development environments, rc.local might be used for various non-threatening experiments. Clearly label these environments and adjust the rule to ignore alerts originating from them. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further execution of potentially malicious scripts and limit the attacker's access. +- Review the contents of the `/etc/rc.local` file on the affected system to identify any unauthorized or suspicious commands or scripts. Remove any malicious entries found. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection tools to identify and remove any additional malware or persistence mechanisms. +- Restore the system from a known good backup if the integrity of the system is in question and if malicious activity is confirmed. +- Implement monitoring for changes to the `/etc/rc.local` file and other critical system files to detect unauthorized modifications in the future. +- Escalate the incident to the security operations team for further investigation and to determine if other systems may be affected. +- Review and update security policies and configurations to disable the execution of the `/etc/rc.local` script by default on all systems, unless explicitly required for legitimate purposes.""" [[rule.threat]] diff --git a/rules/linux/persistence_rpm_package_installation_from_unusual_parent.toml b/rules/linux/persistence_rpm_package_installation_from_unusual_parent.toml index ae85b369470..7af8ea3ef22 100644 --- a/rules/linux/persistence_rpm_package_installation_from_unusual_parent.toml +++ b/rules/linux/persistence_rpm_package_installation_from_unusual_parent.toml @@ -2,7 +2,7 @@ creation_date = "2024/07/10" integration = ["endpoint"] maturity = "production" -updated_date = "2024/11/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -54,6 +54,40 @@ query = ''' host.os.type:linux and event.category:process and event.type:start and event.action:exec and process.name:rpm and process.args:("-i" or "--install") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 RPM Package Installed by Unusual Parent Process + +RPM is a package management system crucial for managing software on Linux distributions like Red Hat and CentOS. Adversaries may exploit RPM by installing backdoored or malicious packages to gain persistence or initial access. The detection rule identifies anomalies by flagging RPM installations initiated by atypical parent processes, which could indicate unauthorized or suspicious activity. This helps in early detection of potential threats by monitoring process execution patterns. + +### Possible investigation steps + +- Review the parent process of the RPM installation to determine if it is a known and legitimate process. Investigate any unusual or unexpected parent processes that initiated the RPM command. +- Examine the command-line arguments used with the RPM process, specifically looking for the "-i" or "--install" flags, to confirm the installation action and gather more context about the package being installed. +- Check the timestamp of the event to correlate it with other activities on the system, such as user logins or other process executions, to identify any suspicious patterns or anomalies. +- Investigate the user account under which the RPM installation was executed to determine if it aligns with expected administrative activities or if it indicates potential unauthorized access. +- Analyze the network activity around the time of the RPM installation to identify any external connections that could suggest data exfiltration or communication with a command and control server. +- Review system logs and other security alerts from the same timeframe to identify any additional indicators of compromise or related suspicious activities. + +### False positive analysis + +- System administrators or automated scripts may frequently install RPM packages as part of routine maintenance or updates. To manage this, create exceptions for known administrative accounts or specific scripts that regularly perform these actions. +- Some legitimate software deployment tools might use non-standard parent processes to install RPM packages. Identify and whitelist these tools to prevent unnecessary alerts. +- Development environments might trigger RPM installations through unusual parent processes during testing or software builds. Exclude these environments or specific processes from the rule to reduce false positives. +- Custom or third-party management tools that are not widely recognized might also cause alerts. Review and whitelist these tools if they are verified as safe and necessary for operations. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement or further compromise. +- Terminate any suspicious processes related to the RPM installation that were initiated by unusual parent processes. +- Conduct a thorough review of the installed RPM packages to identify and remove any unauthorized or malicious software. +- Restore the system from a known good backup if malicious packages have been confirmed and system integrity is compromised. +- Update and patch the system to ensure all software is up-to-date, reducing the risk of exploitation through known vulnerabilities. +- Implement stricter access controls and monitoring on systems to prevent unauthorized RPM installations, focusing on unusual parent processes. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/linux/persistence_shadow_file_modification.toml b/rules/linux/persistence_shadow_file_modification.toml index ae90763ce34..ef0246a60ce 100644 --- a/rules/linux/persistence_shadow_file_modification.toml +++ b/rules/linux/persistence_shadow_file_modification.toml @@ -2,7 +2,7 @@ creation_date = "2024/07/05" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -60,6 +60,40 @@ query = ''' file where host.os.type == "linux" and event.type == "change" and event.action == "rename" and file.path == "/etc/shadow" and file.Ext.original.path != null ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Shadow File Modification + +The Linux shadow file is crucial for storing hashed user passwords, ensuring system security. Adversaries may exploit this by altering the file to add users or change passwords, thus gaining unauthorized access or maintaining persistence. The detection rule identifies suspicious modifications by monitoring changes and renames of the shadow file, flagging potential unauthorized access attempts for further investigation. + +### Possible investigation steps + +- Review the alert details to confirm the event type is "change" and the action is "rename" for the file path "/etc/shadow". +- Check the file.Ext.original.path to identify the original location of the shadow file before the rename event. +- Investigate recent user account changes or additions by examining system logs and user management commands executed around the time of the alert. +- Analyze the history of commands executed by users with elevated privileges to identify any unauthorized or suspicious activities. +- Correlate the event with other security alerts or logs to determine if there are additional indicators of compromise or persistence tactics being employed. +- Verify the integrity of the shadow file by comparing its current state with a known good backup to detect unauthorized modifications. + +### False positive analysis + +- System updates or package installations may trigger legitimate changes to the shadow file. Users can create exceptions for known update processes or package managers to prevent these from being flagged. +- Administrative tasks performed by authorized personnel, such as password changes or user management, can also result in shadow file modifications. Implementing a whitelist for specific user accounts or processes that are known to perform these tasks can reduce false positives. +- Backup or restoration processes that involve the shadow file might cause rename events. Users should identify and exclude these processes if they are part of regular system maintenance. +- Automated scripts or configuration management tools that manage user accounts could lead to expected changes in the shadow file. Users should ensure these tools are recognized and excluded from triggering alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Verify the integrity of the /etc/shadow file by comparing it with a known good backup to identify unauthorized changes or additions. +- Reset passwords for all user accounts on the affected system, ensuring the use of strong, unique passwords to mitigate the risk of compromised credentials. +- Review and remove any unauthorized user accounts that may have been added to the system, ensuring that only legitimate users have access. +- Conduct a thorough audit of system logs and user activity to identify any additional signs of compromise or persistence mechanisms employed by the threat actor. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. +- Implement enhanced monitoring and alerting for future modifications to the /etc/shadow file to quickly detect and respond to similar threats.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_shell_configuration_modification.toml b/rules/linux/persistence_shell_configuration_modification.toml index 95de3e6a32b..f6285354aca 100644 --- a/rules/linux/persistence_shell_configuration_modification.toml +++ b/rules/linux/persistence_shell_configuration_modification.toml @@ -2,7 +2,7 @@ creation_date = "2024/04/30" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -98,6 +98,41 @@ file where host.os.type == "linux" and event.action in ("rename", "creation") an (process.name == "perl" and file.name : "e2scrub_all.tmp*") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Shell Configuration Creation or Modification + +Shell configuration files in Unix-like systems are crucial for setting up user environments by defining variables, aliases, and startup scripts. Adversaries exploit these files to execute malicious code persistently. The detection rule identifies suspicious creation or modification of these files, excluding benign processes, to flag potential threats, aligning with tactics like persistence and event-triggered execution. + +### Possible investigation steps + +- Review the specific file path involved in the alert to determine if it is a system-wide or user-specific shell configuration file, as listed in the query. +- Identify the process executable that triggered the alert and verify if it is part of the excluded benign processes. If not, investigate the process's origin and purpose. +- Check the modification or creation timestamp of the file to correlate with any known user activities or scheduled tasks that might explain the change. +- Examine the contents of the modified or newly created shell configuration file for any suspicious or unauthorized entries, such as unexpected scripts or commands. +- Investigate the user account associated with the file modification to determine if the activity aligns with their typical behavior or if the account may have been compromised. +- Cross-reference the alert with other security logs or alerts to identify any related suspicious activities or patterns that could indicate a broader attack campaign. + +### False positive analysis + +- System package managers like dpkg, rpm, and yum often modify shell configuration files during software installations or updates. To handle these, exclude processes with executables such as /bin/dpkg or /usr/bin/rpm from triggering alerts. +- Automated system management tools like Puppet and Chef may alter shell configuration files as part of their routine operations. Exclude these processes by adding exceptions for executables like /opt/puppetlabs/puppet/bin/puppet or /usr/bin/chef-client. +- User account management activities, such as adding new users, can lead to shell configuration file modifications. Exclude processes like /usr/sbin/adduser or /sbin/useradd to prevent false positives in these scenarios. +- Temporary files created by text editors (e.g., .swp files) during editing sessions can trigger alerts. Exclude file extensions such as swp, swpx, and swx to avoid these false positives. +- Virtualization and containerization tools like Docker and Podman may modify shell configuration files as part of their operations. Exclude executables like /usr/bin/dockerd or /usr/bin/podman to manage these cases. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Review the modified or newly created shell configuration files to identify and remove any unauthorized or malicious code. +- Restore the affected shell configuration files from a known good backup to ensure the system's environment is clean and secure. +- 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 re-infection or related suspicious activity, focusing on the indicators of compromise (IOCs) associated with the Kaiji malware family. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement additional monitoring and alerting for changes to shell configuration files to enhance detection of similar threats in the future.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_simple_web_server_connection_accepted.toml b/rules/linux/persistence_simple_web_server_connection_accepted.toml index 47c99c850ca..88b39906e10 100644 --- a/rules/linux/persistence_simple_web_server_connection_accepted.toml +++ b/rules/linux/persistence_simple_web_server_connection_accepted.toml @@ -2,7 +2,7 @@ creation_date = "2024/12/17" integration = ["endpoint"] maturity = "production" -updated_date = "2024/12/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -62,6 +62,41 @@ network where host.os.type == "linux" and event.type == "start" and event.action (process.name like "python*" and process.command_line like ("*--cgi*", "*CGIHTTPServer*")) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Simple HTTP Web Server Connection + +Simple HTTP servers in Python and PHP are often used for development and testing, providing a quick way to serve web content. However, attackers can exploit these servers to maintain access on compromised Linux systems by deploying backdoors or executing commands remotely. The detection rule identifies suspicious server activity by monitoring for specific process patterns and command-line arguments indicative of these lightweight servers, flagging potential misuse for further investigation. + +### Possible investigation steps + +- Review the process details, including the process name and command line arguments, to confirm if the server was started using Python or PHP, as indicated by the query fields. +- Check the network connection details associated with the event, such as the source and destination IP addresses and ports, to identify any suspicious or unexpected connections. +- Investigate the user account under which the process was initiated to determine if it aligns with expected behavior or if it indicates potential unauthorized access. +- Examine the system logs and any related events around the time of the alert to identify any additional suspicious activities or anomalies. +- Assess the server's web root directory for any unauthorized files or scripts that could indicate a backdoor or malicious payload. +- Correlate this event with other alerts or indicators of compromise on the system to evaluate if this is part of a larger attack campaign. + +### False positive analysis + +- Development and testing environments may frequently trigger this rule when developers use Python or PHP's built-in HTTP servers for legitimate purposes. To manage this, consider excluding specific user accounts or IP addresses associated with development activities from the rule. +- Automated scripts or cron jobs that start simple HTTP servers for routine tasks can also generate false positives. Identify these scripts and add their process names or command-line patterns to an exception list. +- Educational or training environments where students are learning web development might cause alerts. In such cases, exclude the network segments or user groups associated with these activities. +- Internal tools or services that rely on lightweight HTTP servers for functionality might be flagged. Review these tools and whitelist their specific process names or command-line arguments to prevent unnecessary alerts. +- Temporary testing servers spun up for short-term projects can be mistaken for malicious activity. Document these instances and apply temporary exceptions during the project duration. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious Python or PHP processes identified by the detection rule to stop the potential backdoor or unauthorized server activity. +- Conduct a thorough review of the system's file system, focusing on the web root directory, to identify and remove any unauthorized scripts or payloads that may have been uploaded. +- Change all credentials associated with the compromised system, including SSH keys and passwords, to prevent attackers from regaining access. +- Restore the system from a known good backup if any unauthorized changes or persistent threats are detected that cannot be easily remediated. +- Implement network monitoring to detect any future unauthorized HTTP server activity, focusing on unusual process patterns and command-line arguments. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_simple_web_server_creation.toml b/rules/linux/persistence_simple_web_server_creation.toml index 34d6e9c307b..c7478e060ef 100644 --- a/rules/linux/persistence_simple_web_server_creation.toml +++ b/rules/linux/persistence_simple_web_server_creation.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "crowdstrike", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/08" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -68,6 +68,41 @@ process where host.os.type == "linux" and event.type == "start" and (process.name like "python*" and process.args in ("--cgi", "CGIHTTPServer")) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Simple HTTP Web Server Creation + +Simple HTTP web servers, often created using PHP or Python, are lightweight and easy to deploy, making them ideal for quick file sharing or testing. However, adversaries exploit this simplicity to establish persistence on compromised Linux systems. By deploying a web server, they can upload malicious payloads, such as reverse shells, to maintain remote access. The detection rule identifies suspicious server creation by monitoring process executions that match specific patterns, such as PHP or Python commands indicative of server setup, thereby alerting analysts to potential threats. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of PHP or Python commands with arguments matching the patterns specified in the query, such as PHP with the "-S" argument or Python with "--cgi" or "CGIHTTPServer". +- Identify the user account under which the suspicious process was executed to determine if it aligns with expected behavior or if it indicates potential compromise. +- Examine the network activity associated with the process to identify any unusual connections or data transfers that could suggest malicious intent or data exfiltration. +- Check the file system for any newly created or modified files in the web server's root directory that could contain malicious payloads, such as reverse shells. +- Investigate the parent process of the suspicious server creation to understand how the process was initiated and whether it was triggered by another potentially malicious activity. +- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related suspicious activities. + +### False positive analysis + +- Development and testing environments often use simple HTTP servers for legitimate purposes such as serving static files or testing web applications. To manage this, create exceptions for known development directories or user accounts frequently involved in these activities. +- Automated scripts or cron jobs may start simple HTTP servers for routine tasks like file distribution or internal data sharing. Identify these scripts and exclude their execution paths or associated user accounts from triggering alerts. +- Educational or training sessions might involve setting up simple HTTP servers as part of learning exercises. Exclude specific IP ranges or user groups associated with training environments to prevent false positives. +- System administrators might use simple HTTP servers for quick troubleshooting or system maintenance tasks. Document these activities and create exceptions based on the administrator's user accounts or specific server names. +- Continuous integration and deployment pipelines may temporarily start HTTP servers during build or deployment processes. Identify these pipelines and exclude their associated processes or execution contexts from the detection rule. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious PHP or Python processes identified by the detection rule to halt the operation of the unauthorized web server. +- Conduct a thorough examination of the web server's root directory to identify and remove any malicious payloads, such as reverse shells or unauthorized scripts. +- Review system logs and network traffic to identify any additional indicators of compromise or lateral movement attempts by the adversary. +- Restore the system from a known good backup if any critical system files or configurations have been altered by the adversary. +- Implement stricter access controls and monitoring on the affected system to prevent similar unauthorized server setups in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_ssh_key_generation.toml b/rules/linux/persistence_ssh_key_generation.toml index e391a1b9c89..2745eef79ff 100644 --- a/rules/linux/persistence_ssh_key_generation.toml +++ b/rules/linux/persistence_ssh_key_generation.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/06" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -41,6 +41,41 @@ file where host.os.type == "linux" and event.action in ("creation", "file_create process.executable == "/usr/bin/ssh-keygen" and file.path : ("/home/*/.ssh/*", "/root/.ssh/*", "/etc/ssh/*") and not file.name : "known_hosts.*" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Key Generated via ssh-keygen + +SSH keys, created using the ssh-keygen tool, are essential for secure authentication in Linux environments. While typically used for legitimate access to remote systems, adversaries can exploit this by generating unauthorized keys, enabling lateral movement or persistence. The detection rule identifies suspicious key creation by monitoring specific directories and actions, helping to flag potential misuse by threat actors. + +### Possible investigation steps + +- Review the alert details to identify the specific file path and name where the SSH key was created, focusing on directories like "/home/*/.ssh/*", "/root/.ssh/*", and "/etc/ssh/*". +- Check the user account associated with the SSH key creation event to determine if the action aligns with expected behavior for that user. +- Investigate the process execution context by examining the process tree and parent processes of "/usr/bin/ssh-keygen" to identify any potentially suspicious activity leading to the key generation. +- Analyze recent login and access logs for the user and system involved to detect any unusual or unauthorized access patterns. +- Correlate the event with other security alerts or logs to identify if there are signs of lateral movement or persistence tactics being employed by a threat actor. +- Verify the legitimacy of the SSH key by consulting with the system owner or user to confirm if the key creation was authorized and necessary. + +### False positive analysis + +- Routine administrative tasks may trigger the rule when system administrators generate SSH keys for legitimate purposes. To manage this, create exceptions for specific user accounts or directories known to be used by trusted administrators. +- Automated scripts or configuration management tools that regularly generate SSH keys for system provisioning or maintenance can cause false positives. Identify these scripts and exclude their associated processes or file paths from the rule. +- Development environments where developers frequently create SSH keys for testing or deployment purposes might be flagged. Consider excluding directories or user accounts associated with these environments to reduce noise. +- Backup or recovery processes that involve SSH key generation can also trigger alerts. Review these processes and exclude relevant file paths or processes to prevent unnecessary alerts. +- Security tools or monitoring solutions that simulate SSH key generation for testing or validation purposes may be mistakenly flagged. Identify these tools and add exceptions for their activities to avoid false positives. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Revoke any unauthorized SSH keys found in the monitored directories (/home/*/.ssh/*, /root/.ssh/*, /etc/ssh/*) to cut off access for threat actors. +- Conduct a thorough review of user accounts and SSH key pairs on the affected system to identify and remove any unauthorized accounts or keys. +- Reset passwords and regenerate SSH keys for legitimate users to ensure that compromised credentials are not reused. +- Monitor network traffic and system logs for any signs of further unauthorized access attempts or suspicious activity related to SSH. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach. +- Implement additional monitoring and alerting for SSH key generation activities across the network to enhance detection of similar threats in the future.""" [[rule.threat]] diff --git a/rules/linux/persistence_ssh_netcon.toml b/rules/linux/persistence_ssh_netcon.toml index 44b2a2d4a20..2cbd286a171 100644 --- a/rules/linux/persistence_ssh_netcon.toml +++ b/rules/linux/persistence_ssh_netcon.toml @@ -2,7 +2,7 @@ creation_date = "2024/06/06" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -47,6 +47,39 @@ sequence by host.id with maxspan=1s ) ] by process.parent.entity_id ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Network Connection Initiated by SSHD Child Process + +The SSH Daemon (SSHD) facilitates secure remote logins and command execution on Linux systems. Adversaries may exploit SSHD by modifying shell configurations or backdooring the daemon to establish unauthorized connections, often for persistence or data exfiltration. The detection rule identifies suspicious outbound connections initiated by SSHD child processes, excluding benign processes and internal IP ranges, to flag potential malicious activity. + +### Possible investigation steps + +- Review the process details of the SSHD child process that initiated the network connection, focusing on the process.entity_id and process.parent.entity_id to understand the process hierarchy and parent-child relationship. +- Examine the destination IP address of the network connection attempt to determine if it is associated with known malicious activity or suspicious external entities, especially since it is not within the excluded internal IP ranges. +- Investigate the executable path of the process that initiated the connection to ensure it is not a known benign process like "/bin/yum" or "/usr/bin/yum", and verify if the process name is not among the excluded ones such as "login_duo", "ssh", "sshd", or "sshd-session". +- Check the timing and frequency of the SSHD child process executions and network connection attempts to identify any patterns or anomalies that could indicate unauthorized or persistent access attempts. +- Correlate the alert with other security events or logs from the same host.id to gather additional context and determine if there are other indicators of compromise or related suspicious activities. + +### False positive analysis + +- Internal administrative scripts or tools that initiate network connections upon SSH login can trigger false positives. To manage this, identify and whitelist these specific scripts or tools by their process names or executable paths. +- Automated software updates or package management processes like yum may occasionally initiate network connections. Exclude these processes by adding them to the exception list using their executable paths. +- Security tools such as login_duo or other authentication mechanisms that establish network connections during SSH sessions can be mistaken for malicious activity. Exclude these tools by specifying their process names in the exception list. +- Custom monitoring or logging solutions that connect to external servers for data aggregation might be flagged. Identify these processes and exclude them by their executable paths or process names to prevent false alerts. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified as child processes of SSHD that are attempting unauthorized network connections. +- Conduct a thorough review of SSHD configuration files and shell configuration files for unauthorized modifications or backdoors, and restore them from a known good backup if necessary. +- Change all credentials associated with the affected system, especially those that may have been exposed or used during the unauthorized SSH sessions. +- Apply security patches and updates to the SSH daemon and related software to mitigate known vulnerabilities that could be exploited for persistence or unauthorized access. +- Monitor network traffic for any further suspicious outbound connections from other systems, indicating potential lateral movement or additional compromised hosts. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the compromise.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_ssh_via_backdoored_system_user.toml b/rules/linux/persistence_ssh_via_backdoored_system_user.toml index 9be325eed2b..ae091309e82 100644 --- a/rules/linux/persistence_ssh_via_backdoored_system_user.toml +++ b/rules/linux/persistence_ssh_via_backdoored_system_user.toml @@ -2,7 +2,7 @@ creation_date = "2025/01/07" integration = ["system"] maturity = "production" -updated_date = "2025/01/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -61,6 +61,41 @@ user.name in ( "avahi", "sshd", "dnsmasq" ) and event.outcome == "success" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Login via Unusual System User + +In Linux environments, system users typically have restricted login capabilities to prevent unauthorized access. These accounts, often set with `nologin`, are not meant for interactive sessions. Adversaries may exploit these accounts by altering their configurations to enable SSH access, thus bypassing standard security measures. The detection rule identifies successful logins by these uncommon system users, flagging potential unauthorized access attempts for further investigation. + +### Possible investigation steps + +- Review the login event details to identify the specific system user account involved in the successful login, focusing on the user.name field. +- Check the system logs for any recent changes to the user account's configuration, particularly modifications that might have enabled SSH access for accounts typically set with nologin. +- Investigate the source IP address associated with the login event to determine if it is known or suspicious, and assess whether it aligns with expected access patterns. +- Examine the timeline of events leading up to and following the login to identify any unusual activities or patterns that could indicate malicious behavior. +- Verify if there are any other successful login attempts from the same source IP or involving other system user accounts, which could suggest a broader compromise. +- Consult with system administrators to confirm whether any legitimate changes were made to the system user account's login capabilities and document any authorized modifications. + +### False positive analysis + +- System maintenance tasks may require temporary login access for system users. Verify if the login corresponds with scheduled maintenance and consider excluding these events during known maintenance windows. +- Automated scripts or services might use system accounts for legitimate purposes. Identify these scripts and whitelist their associated activities to prevent false alerts. +- Some system users might be configured for specific applications that require login capabilities. Review application requirements and exclude these users if their access is deemed necessary and secure. +- In environments with custom configurations, certain system users might be intentionally modified for operational needs. Document these changes and adjust the detection rule to exclude these known modifications. +- Regularly review and update the list of system users in the detection rule to ensure it reflects the current environment and operational requirements, minimizing unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any active sessions associated with the unusual system user accounts identified in the alert to disrupt ongoing unauthorized access. +- Review and revert any unauthorized changes to the system user accounts, such as modifications to the shell configuration that enabled login capabilities. +- Conduct a thorough audit of the system for any additional unauthorized changes or backdoors, focusing on SSH configurations and user account settings. +- Reset passwords and update authentication mechanisms for all system user accounts to prevent further exploitation. +- Implement additional monitoring and alerting for any future login attempts by system users, ensuring rapid detection and response to similar threats. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_suspicious_file_opened_through_editor.toml b/rules/linux/persistence_suspicious_file_opened_through_editor.toml index fecb6235a8a..7203330663a 100644 --- a/rules/linux/persistence_suspicious_file_opened_through_editor.toml +++ b/rules/linux/persistence_suspicious_file_opened_through_editor.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/06" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -58,6 +58,41 @@ file.path : ( "/root/*.zshrc.swp", "/root/*.zlogin.swp", "/root/*.tcshrc.swp", "/root/*.kshrc.swp", "/root/*.config.fish.swp" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious File Edit + +In Linux environments, text editors create temporary swap files (.swp) during file editing. Adversaries exploit this by editing critical system files to maintain persistence or escalate privileges. The detection rule identifies the creation of .swp files in sensitive directories, signaling potential unauthorized file edits, thus alerting analysts to investigate further. + +### Possible investigation steps + +- Review the alert details to identify the specific file path and name of the .swp file that triggered the alert, focusing on the directories and files listed in the query. +- Check the system logs and recent user activity to determine if there was any legitimate reason for editing the file, such as a scheduled maintenance or update. +- Investigate the user account associated with the file creation event to verify if the user has the necessary permissions and if their activity aligns with their role. +- Examine the contents of the original file (if accessible) and compare it with known baselines or backups to identify any unauthorized changes or anomalies. +- Look for other suspicious activities on the host, such as unusual login attempts, privilege escalation events, or the presence of other temporary files in sensitive directories. +- Assess the system for signs of persistence mechanisms or privilege escalation attempts, especially if the .swp file is associated with critical system files like /etc/shadow or /etc/passwd. + +### False positive analysis + +- Editing non-sensitive files in monitored directories can trigger alerts. Users can create exceptions for specific directories or files that are frequently edited by authorized personnel. +- System administrators performing routine maintenance or updates may inadvertently create .swp files in sensitive directories. Implementing a whitelist for known maintenance activities can reduce false positives. +- Automated scripts or applications that open files in monitored directories for legitimate purposes can cause alerts. Identifying and excluding these processes from monitoring can help manage false positives. +- Developers working on configuration files in their home directories might trigger alerts. Excluding specific user directories or known development environments can mitigate these occurrences. +- Regular system updates or package installations might create temporary .swp files. Monitoring these activities and correlating them with update schedules can help distinguish between legitimate and suspicious activities. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes associated with the creation of the .swp files in sensitive directories to halt any ongoing malicious activity. +- Restore the affected files from a known good backup to ensure system integrity and remove any unauthorized changes. +- Conduct a thorough review of user accounts and permissions, especially those with elevated privileges, to identify and revoke any unauthorized access. +- Implement additional monitoring on the affected system and similar environments to detect any further attempts to edit critical files. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Review and update system hardening measures, such as file permissions and access controls, to prevent similar incidents in the future.""" [[rule.threat]] diff --git a/rules/linux/persistence_suspicious_ssh_execution_xzbackdoor.toml b/rules/linux/persistence_suspicious_ssh_execution_xzbackdoor.toml index 5590ed91078..00dd46c4b65 100644 --- a/rules/linux/persistence_suspicious_ssh_execution_xzbackdoor.toml +++ b/rules/linux/persistence_suspicious_ssh_execution_xzbackdoor.toml @@ -2,7 +2,7 @@ creation_date = "2024/04/01" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -48,6 +48,40 @@ sequence by host.id, user.id with maxspan=1s [process where host.os.type == "linux" and event.action == "end" and process.name == "sshd" and process.exit_code != 0] by process.pid, process.entity_id [network where host.os.type == "linux" and event.type == "end" and event.action == "disconnect_received" and process.name == "sshd"] by process.pid, process.entity_id ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Execution via XZBackdoor + +The XZBackdoor leverages SSH, a secure protocol for remote access, to execute malicious commands stealthily. Adversaries exploit SSH by initiating sessions that mimic legitimate activity, then abruptly terminate them post-execution to evade detection. The detection rule identifies anomalies by tracking SSH processes that start and end unexpectedly, especially when non-standard executables are invoked, signaling potential backdoor activity. + +### Possible investigation steps + +- Review the SSH session logs on the affected host to identify any unusual or unauthorized access attempts, focusing on sessions that match the process.pid and process.entity_id from the alert. +- Examine the command history and executed commands for the user associated with the user.id in the alert to identify any suspicious or unexpected activities. +- Investigate the non-standard executables invoked by the SSH session by checking the process.executable field to determine if they are legitimate or potentially malicious. +- Analyze the network activity associated with the SSH session, particularly any disconnect_received events, to identify any unusual patterns or connections to suspicious IP addresses. +- Check the exit codes of the SSH processes, especially those with a non-zero process.exit_code, to understand the reason for the abrupt termination and whether it aligns with typical error codes or indicates malicious activity. + +### False positive analysis + +- Legitimate administrative SSH sessions may trigger the rule if they involve non-standard executables. To manage this, create exceptions for known administrative scripts or tools that are frequently used in your environment. +- Automated processes or scripts that use SSH for routine tasks might mimic the behavior of the XZBackdoor. Identify these processes and exclude them by specifying their executable paths or command-line patterns in the rule exceptions. +- Security tools or monitoring solutions that perform SSH-based checks could be mistaken for malicious activity. Review these tools and add their signatures to the exclusion list to prevent false alerts. +- Custom applications that use SSH for communication might be flagged. Document these applications and adjust the rule to recognize their specific execution patterns as non-threatening. +- Temporary network issues causing abrupt SSH session terminations could be misinterpreted as suspicious behavior. Monitor network stability and consider excluding known transient disconnections from triggering alerts. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious SSH sessions identified by the detection rule to stop ongoing malicious activity. +- Conduct a thorough review of the affected host's SSH configuration and logs to identify unauthorized changes or access patterns. +- Reset credentials for any user accounts involved in the suspicious SSH activity to prevent further unauthorized access. +- Restore the affected system from a known good backup if any unauthorized changes or malware are detected. +- Implement network segmentation to limit SSH access to critical systems and reduce the attack surface. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are compromised.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_systemd_generator_creation.toml b/rules/linux/persistence_systemd_generator_creation.toml index ac5ff2677bd..1f1ec52c970 100644 --- a/rules/linux/persistence_systemd_generator_creation.toml +++ b/rules/linux/persistence_systemd_generator_creation.toml @@ -2,7 +2,7 @@ creation_date = "2024/06/19" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -83,6 +83,40 @@ file where host.os.type == "linux" and event.action in ("rename", "creation") an process.executable == null ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Systemd Generator Created + +Systemd generators are scripts that systemd runs at boot or during configuration reloads to convert non-native configurations into unit files. Adversaries can exploit this by creating malicious generators to execute arbitrary code, ensuring persistence or escalating privileges. The detection rule identifies suspicious generator file creations or renames, excluding benign processes and file types, to flag potential abuse. + +### Possible investigation steps + +- Review the file path where the generator was created or renamed to determine if it is located in a standard systemd generator directory, such as /run/systemd/system-generators/ or /etc/systemd/user-generators/. +- Identify the process that created or renamed the generator file by examining the process.executable field, and determine if it is a known benign process or potentially malicious. +- Check the file extension and original extension fields to ensure the file is not a temporary or expected system file, such as those with extensions like "swp" or "dpkg-new". +- Investigate the history and behavior of the process that created the generator file, including any associated network connections or file modifications, to assess if it exhibits signs of malicious activity. +- Correlate the event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise that might suggest persistence or privilege escalation attempts. + +### False positive analysis + +- Package managers like dpkg, rpm, and yum can trigger false positives when they create or rename files in systemd generator directories during software installations or updates. To handle these, exclude processes associated with these package managers as specified in the rule. +- Automated system management tools such as Puppet and Chef may also create or modify generator files as part of their configuration management tasks. Exclude these processes by adding them to the exception list if they are part of your environment. +- Temporary files with extensions like swp, swpx, and swx, often created by text editors, can be mistakenly flagged. Ensure these extensions are included in the exclusion list to prevent unnecessary alerts. +- System updates or maintenance scripts that run as part of regular operations might create or modify generator files. Identify these scripts and add their executables to the exclusion list to reduce false positives. +- Custom scripts or tools that are part of legitimate administrative tasks may also trigger alerts. Review these scripts and consider excluding their executables if they are verified as non-malicious. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further execution of potentially malicious code and lateral movement. +- Terminate any suspicious processes associated with the creation or modification of systemd generator files to halt any ongoing malicious activity. +- Conduct a thorough review of the systemd generator directories to identify and remove any unauthorized or suspicious generator files. +- Restore any modified or deleted legitimate systemd generator files from a known good backup to ensure system integrity. +- Implement file integrity monitoring on systemd generator directories to detect unauthorized changes in the future. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Review and update access controls and permissions for systemd generator directories to limit the ability to create or modify files to authorized users only.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_systemd_netcon.toml b/rules/linux/persistence_systemd_netcon.toml index ca08b619167..641a6a506f5 100644 --- a/rules/linux/persistence_systemd_netcon.toml +++ b/rules/linux/persistence_systemd_netcon.toml @@ -2,7 +2,7 @@ creation_date = "2024/02/01" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -67,6 +67,41 @@ sequence by host.id with maxspan=5s [network where host.os.type == "linux" and event.action == "connection_attempted" and event.type == "start" and not process.executable == "/tmp/newroot/bin/curl"] by process.parent.entity_id ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Network Connection via systemd + +Systemd is a critical component in Linux, managing system processes and services. Adversaries exploit it by altering unit files or replacing binaries to ensure malicious scripts run at startup, achieving persistence. The detection rule identifies unusual network activities initiated by systemd, flagging potential backdoor usage by monitoring specific processes and network attempts, thus aiding in early threat detection. + +### Possible investigation steps + +- Review the process details to identify the specific script or command executed by systemd, focusing on the process names such as "python*", "php*", "perl", "ruby", "lua*", "openssl", "nc", "netcat", "ncat", "telnet", "awk". +- Examine the parent process information to confirm that the suspicious process was indeed initiated by systemd, ensuring the parent process name is "systemd". +- Investigate the network connection attempt details, including the destination IP address and port, to determine if the connection is to a known malicious or suspicious endpoint. +- Check the process executable path to ensure it is not a known legitimate path, especially looking for unusual paths that might indicate a compromised binary, excluding "/tmp/newroot/bin/curl". +- Analyze the systemd unit files on the host to identify any unauthorized modifications or additions that could indicate persistence mechanisms. +- Correlate the event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise. +- Consult threat intelligence sources to gather more context on the IP addresses or domains involved in the network connection attempt. + +### False positive analysis + +- Legitimate administrative scripts or maintenance tasks that use scripting languages like Python, PHP, or Perl may trigger the rule. To handle this, identify and document these scripts, then create exceptions for their specific process names or paths. +- Automated system monitoring tools that perform network checks using utilities like netcat or telnet might be flagged. Review these tools and whitelist their process names or executable paths to prevent false alerts. +- Custom applications or services that are legitimately started by systemd and initiate network connections could be misidentified. Verify these applications and add them to an allowlist based on their process names or parent entity IDs. +- Development or testing environments where developers frequently use scripting languages for network operations may cause false positives. Consider excluding these environments from monitoring or creating specific rules that account for their unique behaviors. + +### Response and remediation + +- Isolate the affected host immediately from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified in the alert, particularly those initiated by systemd that match the specified process names (e.g., python, php, perl). +- Review and restore any modified or suspicious systemd unit files to their original state, ensuring no unauthorized scripts or commands are set to execute at startup. +- Conduct a thorough scan of the affected system for additional indicators of compromise, focusing on persistence mechanisms and unauthorized network connections. +- Reinstall or verify the integrity of systemd binaries to ensure they have not been replaced or tampered with by malicious actors. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for systemd-related activities and network connections to detect similar threats in the future.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_tainted_kernel_module_load.toml b/rules/linux/persistence_tainted_kernel_module_load.toml index 6cabc894a4d..e07ec7f9272 100644 --- a/rules/linux/persistence_tainted_kernel_module_load.toml +++ b/rules/linux/persistence_tainted_kernel_module_load.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/23" integration = ["system"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -55,6 +55,40 @@ query = ''' host.os.type:linux and event.dataset:"system.syslog" and process.name:kernel and message:"module verification failed: signature and/or required key missing - tainting kernel" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Tainted Kernel Module Load + +Kernel modules extend the functionality of the Linux kernel, allowing dynamic loading of code. While beneficial, they can be exploited by adversaries to introduce malicious code, bypassing security measures. Attackers may load unsigned or improperly signed modules, leading to a "tainted" kernel state. The detection rule identifies such events by monitoring syslog for specific error messages, signaling potential unauthorized module loads, thus aiding in early threat detection and system integrity maintenance. + +### Possible investigation steps + +- Review the syslog entries around the time of the alert to gather additional context and identify any other suspicious activities or related events. +- Investigate the specific kernel module mentioned in the syslog message to determine its origin, legitimacy, and whether it is expected on the system. +- Check the system for any recent changes or installations that could have introduced the unsigned or improperly signed module, including software updates or new applications. +- Analyze the system for signs of compromise, such as unexpected network connections, unusual process activity, or unauthorized user accounts, which may indicate a broader security incident. +- Consult with system administrators or relevant personnel to verify if the module load was authorized or part of a legitimate operation, and document any findings or justifications provided. + +### False positive analysis + +- Custom kernel modules: Organizations often use custom or proprietary kernel modules that may not be signed. These can trigger false positives. To manage this, maintain a list of known, trusted custom modules and create exceptions for them in the monitoring system. +- Outdated or unsupported hardware drivers: Some older hardware drivers may not have signed modules, leading to false positives. Regularly update drivers and, if necessary, exclude specific drivers that are known to be safe but unsigned. +- Development and testing environments: In environments where kernel module development occurs, unsigned modules may be loaded frequently. Implement separate monitoring rules or exceptions for these environments to avoid unnecessary alerts. +- Vendor-provided modules: Certain vendors may provide modules that are not signed. Verify the legitimacy of these modules with the vendor and consider excluding them if they are confirmed to be safe. +- Temporary testing modules: During troubleshooting or testing, temporary modules might be loaded without proper signing. Ensure these are removed after testing and consider temporary exceptions during the testing phase. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the attacker. +- Verify the integrity of the kernel and loaded modules by comparing them against known good versions or using a trusted baseline. +- Unload the suspicious kernel module if possible, and replace it with a verified, signed version to restore system integrity. +- Conduct a thorough forensic analysis of the affected system to identify any additional signs of compromise 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 are affected. +- Implement enhanced monitoring and logging for kernel module loads and other critical system activities to detect similar threats in the future. +- Review and update system and network access controls to ensure only authorized personnel can load kernel modules, reducing the risk of unauthorized changes.""" [[rule.threat]] diff --git a/rules/linux/persistence_tainted_kernel_module_out_of_tree_load.toml b/rules/linux/persistence_tainted_kernel_module_out_of_tree_load.toml index 57ff1986c23..ab0d59ff5c9 100644 --- a/rules/linux/persistence_tainted_kernel_module_out_of_tree_load.toml +++ b/rules/linux/persistence_tainted_kernel_module_out_of_tree_load.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/26" integration = ["system"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -55,6 +55,41 @@ query = ''' host.os.type:linux and event.dataset:"system.syslog" and process.name:kernel and message:"loading out-of-tree module taints kernel." ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Tainted Out-Of-Tree Kernel Module Load + +Kernel modules extend the functionality of the Linux kernel without rebooting the system. While beneficial, out-of-tree modules, not included in the official kernel source, can taint the kernel, posing security risks. Adversaries exploit this by loading malicious modules to evade detection and maintain persistence. The detection rule monitors syslog for specific messages indicating such module loads, helping identify potential threats early. + +### Possible investigation steps + +- Review the syslog entries around the time of the alert to gather additional context about the module load event, focusing on messages with "loading out-of-tree module taints kernel." +- Identify the specific out-of-tree kernel module that was loaded by examining the syslog message details and cross-reference with known legitimate modules. +- Check the system for any recent changes or installations that might have introduced the out-of-tree module, such as software updates or new applications. +- Investigate the source and integrity of the module by verifying its origin and comparing its hash against known good or malicious hashes. +- Assess the system for any signs of compromise or unauthorized access, focusing on persistence mechanisms and defense evasion tactics, as indicated by the MITRE ATT&CK framework references. +- Consult with system administrators or relevant stakeholders to determine if the module load was authorized or expected as part of normal operations. + +### False positive analysis + +- Legitimate third-party drivers or hardware support modules may trigger alerts when loaded as out-of-tree modules. Users should verify the source and purpose of these modules to ensure they are not malicious. +- Custom-built modules for specific applications or hardware optimizations can also cause false positives. Users can create exceptions for these modules by adding them to an allowlist if they are verified as safe and necessary for system operations. +- Development and testing environments often load experimental or custom modules that are not part of the official kernel. In such cases, users should document these modules and exclude them from alerts to avoid unnecessary noise. +- Regularly updated or patched modules from trusted vendors might not be immediately recognized as safe. Users should maintain a list of trusted vendors and update their exception lists accordingly to prevent false positives. +- Some security tools or monitoring solutions may use out-of-tree modules for enhanced functionality. Users should ensure these tools are from reputable sources and exclude their modules from detection rules if they are confirmed to be secure. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Identify and unload the suspicious out-of-tree kernel module using the `rmmod` command to remove it from the kernel. +- Conduct a thorough review of the system's kernel module load history and verify the legitimacy of all loaded modules. +- Perform a comprehensive malware scan on the affected system to detect and remove any additional malicious software. +- Restore the system from a known good backup if the integrity of the system cannot be assured after module removal. +- Implement stricter access controls and monitoring for kernel module loading to prevent unauthorized module loads in the future. +- Escalate the incident to the security operations team for further investigation and to assess the need for broader organizational response measures.""" [[rule.threat]] diff --git a/rules/linux/persistence_udev_rule_creation.toml b/rules/linux/persistence_udev_rule_creation.toml index aa3b26fe2c2..dd4c053842e 100644 --- a/rules/linux/persistence_udev_rule_creation.toml +++ b/rules/linux/persistence_udev_rule_creation.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/26" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -83,6 +83,42 @@ file.path : ( (process.name == "perl" and file.name : "e2scrub_all.tmp*") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Systemd-udevd Rule File Creation + +Systemd-udevd manages device nodes and handles kernel device events in Linux, using rule files to automate responses to hardware changes. Adversaries can exploit this by creating malicious rules that execute commands when specific devices are connected. The detection rule monitors the creation of these rule files, excluding legitimate processes, to identify potential abuse and ensure system integrity. + +### Possible investigation steps + +- Review the file path and name to determine if the rule file is located in a directory commonly used for udev rules, such as /etc/udev/rules.d/ or /lib/udev/. +- Examine the process executable that created or renamed the rule file to identify if it is a known legitimate process or an unexpected one, as specified in the query. +- Check the file extension and ensure it is .rules, confirming it is intended for udev rule configuration. +- Investigate the process name and path to determine if it matches any of the excluded legitimate processes or paths, which could indicate a false positive. +- Analyze the contents of the newly created or modified rule file to identify any suspicious or malicious commands that could be executed when a device is connected. +- Correlate the event with other system logs to identify any related activities or anomalies around the time of the rule file creation or modification. +- Assess the risk and impact of the rule file creation by considering the context of the system and any potential persistence mechanisms it might enable for an adversary. + +### False positive analysis + +- System updates and package installations can trigger rule file creations. Exclude processes like dpkg, rpm, and yum by adding them to the exception list to prevent false positives during legitimate system maintenance. +- Container management tools such as Docker and Podman may create or modify udev rules. Exclude these processes to avoid alerts when containers are being managed. +- Automated system configuration tools like Puppet and Chef can modify udev rules as part of their operations. Add these tools to the exception list to reduce noise from routine configuration changes. +- Snap package installations and updates can lead to rule file changes. Exclude snapd and related processes to prevent false positives during snap operations. +- Netplan and systemd processes may generate or modify udev rules as part of network configuration or system initialization. Exclude these processes to avoid unnecessary alerts during legitimate system activities. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further execution of malicious udev rules and potential lateral movement. +- Identify and review the newly created or modified udev rule files in the specified directories to determine if they contain malicious commands or payloads. +- Remove any unauthorized or malicious udev rule files to prevent them from executing on device connection events. +- Restore any affected system configurations or files from a known good backup to ensure system integrity. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection tools to identify and remove any additional malware or persistence mechanisms. +- Monitor the system for any further suspicious activity or attempts to recreate malicious udev rules, adjusting detection mechanisms as necessary. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected, ensuring comprehensive threat containment and remediation.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_unusual_pam_grantor.toml b/rules/linux/persistence_unusual_pam_grantor.toml index 2fee0dc96ad..4b0461200e5 100644 --- a/rules/linux/persistence_unusual_pam_grantor.toml +++ b/rules/linux/persistence_unusual_pam_grantor.toml @@ -2,7 +2,7 @@ creation_date = "2024/03/06" integration = ["auditd_manager"] maturity = "production" -updated_date = "2024/07/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -46,6 +46,40 @@ query = ''' event.category:authentication and host.os.type:linux and event.action:authenticated and event.outcome:success and auditd.data.grantors:(* and not (pam_rootok or *pam_cap* or *pam_permit*)) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Authentication via Unusual PAM Grantor + +Pluggable Authentication Modules (PAM) are integral to Linux systems, managing authentication tasks. Adversaries may exploit uncommon PAM grantors to escalate privileges or maintain persistence by altering default configurations. The detection rule identifies successful authentications using atypical PAM grantors, signaling potential unauthorized access or configuration tampering. + +### Possible investigation steps + +- Review the specific PAM grantor involved in the authentication event to determine if it is known or expected in your environment. +- Check the user account associated with the authentication event for any signs of compromise or unusual activity, such as recent changes in permissions or unexpected login times. +- Investigate the source IP address and hostname of the authentication event to verify if it is a recognized and authorized system within your network. +- Examine recent changes to the PAM configuration files on the affected host to identify any unauthorized modifications or additions. +- Correlate this event with other security alerts or logs from the same host or user to identify potential patterns of malicious activity. +- Consult with system administrators or relevant personnel to confirm if the use of the unusual PAM grantor was part of a legitimate change or update. + +### False positive analysis + +- Custom PAM modules: Organizations may use custom PAM modules for specific applications or security policies. Review these modules to ensure they are legitimate and add them to an exception list if they are frequently triggering alerts. +- Administrative scripts: Some administrative scripts might use non-standard PAM grantors for automation purposes. Verify the scripts' legitimacy and consider excluding them from the rule if they are part of routine operations. +- Third-party software: Certain third-party software may install or use uncommon PAM grantors as part of their authentication process. Validate the software's authenticity and add its grantors to an exception list if they are known to be safe. +- Development environments: In development or testing environments, developers might experiment with different PAM configurations. Ensure these environments are properly isolated and consider excluding them from the rule to avoid unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Review the PAM configuration files on the affected system to identify and revert any unauthorized changes to the grantors. Ensure only legitimate PAM modules are in use. +- Terminate any suspicious or unauthorized processes that may have been initiated by the attacker to maintain persistence or escalate privileges. +- Conduct a thorough review of user accounts and privileges on the affected system to identify any unauthorized changes or newly created accounts. Revoke any unauthorized access. +- Restore the affected system from a known good backup if unauthorized changes cannot be easily reverted or if the system's integrity is in question. +- 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 enhanced monitoring and logging for PAM-related activities across the network to detect similar threats in the future, ensuring that alerts are promptly reviewed and acted upon.""" [[rule.threat]] diff --git a/rules/linux/persistence_unusual_sshd_child_process.toml b/rules/linux/persistence_unusual_sshd_child_process.toml index 83eae707d3b..941a739b76b 100644 --- a/rules/linux/persistence_unusual_sshd_child_process.toml +++ b/rules/linux/persistence_unusual_sshd_child_process.toml @@ -2,7 +2,7 @@ creation_date = "2024/12/16" integration = ["endpoint"] maturity = "production" -updated_date = "2024/12/16" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -34,6 +34,39 @@ event.category:process and host.os.type:linux and event.type:start and event.act process.parent.name:(ssh or sshd) and process.args_count:2 and not process.command_line:(-bash or -zsh or -sh) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 SSHD Child Process + +Secure Shell (SSH) is a protocol used to securely access remote systems. Adversaries may exploit SSH to maintain persistence or create backdoors by spawning unexpected child processes. The detection rule identifies anomalies by monitoring process creation events where SSH or SSHD is the parent, focusing on atypical command-line arguments, which may indicate malicious activity. + +### Possible investigation steps + +- Review the process command line arguments for the unusual SSHD child process to identify any suspicious or unexpected commands that could indicate malicious activity. +- Check the user account associated with the SSHD child process to determine if it is a legitimate user or if there are signs of compromise, such as unusual login times or locations. +- Investigate the parent process (SSH or SSHD) to understand the context of the connection, including the source IP address and any associated user activity, to assess if it aligns with expected behavior. +- Examine the process tree to identify any subsequent processes spawned by the unusual SSHD child process, which may provide further insight into the attacker's actions or objectives. +- Correlate the event with other security logs and alerts from the same host or network segment to identify any related suspicious activities or patterns that could indicate a broader attack campaign. + +### False positive analysis + +- Legitimate administrative scripts or automation tools may trigger this rule if they execute commands with SSH or SSHD as the parent process. To handle this, identify and document these scripts, then create exceptions for their specific command-line patterns. +- System maintenance tasks or updates that involve SSH connections might appear as unusual child processes. Regularly review and whitelist these known maintenance activities to prevent unnecessary alerts. +- Custom user environments or shell configurations that deviate from standard shells like bash, zsh, or sh could be flagged. Analyze these configurations and exclude them if they are verified as non-threatening. +- Monitoring tools or security solutions that interact with SSH sessions for logging or auditing purposes might generate alerts. Verify these tools' behavior and exclude their processes if they are part of legitimate monitoring activities. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious SSHD child processes identified by the alert to halt potential malicious activities. +- Conduct a thorough review of SSH configuration files and access logs to identify unauthorized changes or access patterns, and revert any unauthorized modifications. +- Change all SSH keys and credentials associated with the compromised system to prevent further unauthorized access. +- Implement additional monitoring on the affected system and related network segments to detect any further suspicious activities or attempts to re-establish persistence. +- 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. +- Review and update firewall rules and access controls to restrict SSH access to only trusted IP addresses and users, reducing the attack surface for future incidents.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/persistence_user_or_group_creation_or_modification.toml b/rules/linux/persistence_user_or_group_creation_or_modification.toml index 3c1f2b7696b..a41d35802fc 100644 --- a/rules/linux/persistence_user_or_group_creation_or_modification.toml +++ b/rules/linux/persistence_user_or_group_creation_or_modification.toml @@ -2,7 +2,7 @@ creation_date = "2024/06/20" integration = ["auditd_manager"] maturity = "production" -updated_date = "2024/09/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -72,6 +72,40 @@ query = ''' iam where host.os.type == "linux" and event.type in ("creation", "change") and auditd.result == "success" and event.action in ("changed-password", "added-user-account", "added-group-account-to") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating User or Group Creation/Modification + +In Linux environments, user and group management is crucial for access control and system administration. Adversaries may exploit this by creating or modifying accounts to maintain unauthorized access. The detection rule utilizes audit logs to monitor successful user or group changes, flagging potential persistence tactics by correlating specific actions with known threat behaviors. + +### Possible investigation steps + +- Review the audit logs to identify the specific user or group account that was created or modified, focusing on the event.action field values such as "changed-password", "added-user-account", or "added-group-account-to". +- Check the timestamp of the event to determine when the account change occurred and correlate it with any other suspicious activities or alerts around the same time. +- Investigate the source of the event by examining the host information, particularly the host.os.type field, to understand which system the changes were made on. +- Identify the user or process that initiated the account change by reviewing the associated user information in the audit logs, which may provide insights into whether the action was authorized or potentially malicious. +- Cross-reference the identified user or group changes with known threat actor behaviors or recent incidents to assess if the activity aligns with any known persistence tactics. + +### False positive analysis + +- Routine administrative tasks may trigger alerts when system administrators create or modify user or group accounts as part of regular maintenance. To manage this, consider creating exceptions for known administrative accounts or scheduled maintenance windows. +- Automated scripts or configuration management tools that manage user accounts can generate false positives. Identify these tools and exclude their actions from triggering alerts by whitelisting their processes or user accounts. +- System updates or software installations that require user or group modifications might be flagged. Review the context of these changes and exclude specific update processes or installation scripts from the rule. +- Temporary user accounts created for short-term projects or testing purposes can be mistaken for unauthorized access attempts. Implement a naming convention for temporary accounts and exclude them from the rule to reduce noise. +- Changes made by trusted third-party services or applications that integrate with the system may appear suspicious. Verify these services and add them to an exception list to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Review the audit logs to identify the specific user or group accounts that were created or modified, and disable or remove any unauthorized accounts. +- Reset passwords for any compromised or suspicious accounts to prevent further unauthorized access. +- Conduct a thorough review of system and application logs to identify any additional unauthorized changes or suspicious activities that may have occurred. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised. +- Implement additional monitoring on the affected system and similar systems to detect any further unauthorized account activities. +- Review and update access control policies and procedures to prevent similar incidents in the future, ensuring that only authorized personnel have the ability to create or modify user and group accounts.""" [[rule.threat]] diff --git a/rules/linux/persistence_xdg_autostart_netcon.toml b/rules/linux/persistence_xdg_autostart_netcon.toml index f9a8948444a..43530e9dd43 100644 --- a/rules/linux/persistence_xdg_autostart_netcon.toml +++ b/rules/linux/persistence_xdg_autostart_netcon.toml @@ -2,7 +2,7 @@ creation_date = "2024/06/03" integration = ["endpoint"] maturity = "production" -updated_date = "2024/09/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -97,6 +97,40 @@ sequence by host.id, process.entity_id with maxspan=1s ) ] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Network Connections Initiated Through XDG Autostart Entry + +XDG Autostart entries are used in GNOME and XFCE Linux environments to automatically execute scripts or applications upon user login, facilitating user convenience. However, adversaries can exploit this feature to maintain persistence by modifying these entries to initiate unauthorized network connections. The detection rule identifies such malicious activity by monitoring processes linked to XDG autostart and subsequent suspicious network connections, excluding known benign processes and internal IP ranges. + +### Possible investigation steps + +- Review the process details from the alert, focusing on the process.entity_id and process.executable fields to identify the specific application or script that was executed through the XDG autostart entry. +- Examine the parent process information, particularly the process.parent.executable field, to confirm if the process was initiated by a legitimate session manager like /usr/bin/xfce4-session. +- Investigate the network connection details, paying attention to the destination.ip field to determine if the connection was attempted to an external or suspicious IP address not covered by the internal IP ranges specified in the query. +- Check the process.args field for any unusual or unexpected command-line arguments that might indicate malicious intent or unauthorized modifications to the autostart entry. +- Correlate the alert with other security events or logs from the same host.id to identify any additional suspicious activities or patterns that might suggest a broader compromise or persistence mechanism. +- Validate the legitimacy of the process.executable by comparing it against known benign applications listed in the query, such as /usr/lib64/firefox/firefox, to rule out false positives. + +### False positive analysis + +- Network connections from legitimate applications like Firefox or FortiClient may trigger false positives. To handle this, add these applications to the exclusion list in the detection rule. +- Internal network traffic within known safe IP ranges can be mistakenly flagged. Ensure these IP ranges are included in the exclusion criteria to prevent unnecessary alerts. +- Custom scripts or applications that are part of the user's normal login process might be misidentified. Review and whitelist these processes if they are verified as non-threatening. +- Regular updates or maintenance tasks that initiate network connections during login can cause false alerts. Identify these tasks and adjust the rule to exclude them if they are part of routine operations. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized network connections and potential lateral movement. +- Terminate any suspicious processes identified as being initiated through XDG autostart entries to halt any ongoing malicious activity. +- Review and remove any unauthorized or suspicious XDG autostart entries to eliminate persistence mechanisms established by the attacker. +- Conduct a thorough scan of the affected system for additional indicators of compromise, such as unauthorized user accounts or modified system files, to ensure comprehensive remediation. +- Restore any altered system configurations or files from a known good backup to ensure system integrity and functionality. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected. +- Implement enhanced monitoring and logging for XDG autostart entries and network connections to detect similar threats in the future and improve overall security posture.""" [[rule.threat]] diff --git a/rules/linux/persistence_yum_package_manager_plugin_file_creation.toml b/rules/linux/persistence_yum_package_manager_plugin_file_creation.toml index d382a433ebc..3b68e2dcebf 100644 --- a/rules/linux/persistence_yum_package_manager_plugin_file_creation.toml +++ b/rules/linux/persistence_yum_package_manager_plugin_file_creation.toml @@ -2,7 +2,7 @@ creation_date = "2024/06/25" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -85,6 +85,41 @@ file.path : ("/usr/lib/yum-plugins/*", "/etc/yum/pluginconf.d/*") and not ( (process.name == "perl" and file.name : "e2scrub_all.tmp*") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Yum Package Manager Plugin File Creation + +The Yum package manager is integral to managing software on Fedora-based Linux systems, utilizing plugins to extend its functionality. Adversaries may exploit this by inserting malicious code into these plugins, ensuring persistent access whenever Yum is executed. The detection rule identifies suspicious file creation in plugin directories, excluding legitimate processes and temporary files, to flag potential unauthorized modifications. + +### Possible investigation steps + +- Review the file creation event details, focusing on the file path to confirm if it matches the plugin directories "/usr/lib/yum-plugins/*" or "/etc/yum/pluginconf.d/*". +- Identify the process responsible for the file creation by examining the process.executable field, ensuring it is not one of the legitimate processes listed in the exclusion criteria. +- Check the file extension and name to ensure it is not a temporary or excluded file type, such as those with extensions "swp", "swpx", "swx", or names starting with ".ansible". +- Investigate the origin and legitimacy of the process by correlating with other system logs or using threat intelligence to determine if the process is known to be associated with malicious activity. +- Assess the file content for any signs of malicious code or unauthorized modifications, especially if the file is a script or configuration file. +- Determine if there have been any recent changes or updates to the system that could explain the file creation, such as legitimate software installations or updates. + +### False positive analysis + +- Legitimate software updates or installations may trigger file creation events in Yum plugin directories. To handle these, users can create exceptions for known package management processes like rpm, dnf, and yum, which are already included in the rule's exclusion list. +- Temporary files created by text editors or system processes, such as those with extensions like swp, swpx, or swx, can be safely excluded as they are typically non-threatening. Ensure these extensions are part of the exclusion criteria. +- Automation tools like Ansible may generate temporary files in the plugin directories. Users can exclude file names starting with .ansible or .ansible_tmp to prevent false positives from these operations. +- Processes running from specific directories like /nix/store or /var/lib/dpkg are often part of legitimate system operations. Users should verify these paths and include them in the exclusion list if they are part of regular system behavior. +- System maintenance scripts or tools like sed and perl may create temporary files during their execution. Users can exclude these specific process names and file patterns to reduce false alerts. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes that may be running as a result of the malicious plugin modification to halt any ongoing malicious activity. +- Restore the compromised plugin files from a known good backup to ensure the integrity of the Yum package manager's functionality. +- Conduct a thorough review of user accounts and permissions on the affected system to identify and remove any unauthorized access or privilege escalations. +- Implement file integrity monitoring on the Yum plugin directories to detect any future unauthorized modifications promptly. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. +- Update and patch the system to the latest security standards to mitigate any vulnerabilities that may have been exploited by the adversary.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/privilege_escalation_chown_chmod_unauthorized_file_read.toml b/rules/linux/privilege_escalation_chown_chmod_unauthorized_file_read.toml index 4937bae0038..637e0c26c33 100644 --- a/rules/linux/privilege_escalation_chown_chmod_unauthorized_file_read.toml +++ b/rules/linux/privilege_escalation_chown_chmod_unauthorized_file_read.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_ maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/08" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -68,6 +68,40 @@ process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and process.name in ("chown", "chmod") and process.args == "-R" and process.args : "--reference=*" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Unauthorized Access via Wildcard Injection Detected + +In Linux environments, commands like `chown` and `chmod` are used to change file ownership and permissions. Adversaries may exploit wildcard characters in these commands to escalate privileges or access sensitive data by executing unintended operations. The detection rule identifies suspicious use of these commands with recursive flags and wildcard references, signaling potential misuse aimed at privilege escalation or unauthorized data access. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of the "chown" or "chmod" command with the "-R" flag and wildcard usage in the arguments, as indicated by the query fields process.name, process.args, and event.action. +- Examine the user account associated with the process execution to determine if it has the necessary permissions to perform such operations and assess if the account has been compromised. +- Check the command execution history and related logs to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern or unauthorized access attempts. +- Investigate the source and destination of the command execution by analyzing network logs and connections to determine if the activity originated from a known or unknown IP address or host. +- Correlate this event with other alerts or anomalies in the system to identify potential patterns or coordinated attacks, focusing on privilege escalation or credential access attempts as suggested by the rule's tags and threat information. + +### False positive analysis + +- Routine administrative tasks using chown or chmod with recursive flags may trigger the rule. To manage this, identify and whitelist specific scripts or users that regularly perform these tasks without security risks. +- Automated system maintenance processes that involve changing file permissions or ownership across directories can be mistaken for malicious activity. Exclude these processes by specifying their command patterns or associated user accounts in the monitoring system. +- Backup operations that involve copying and setting permissions on large sets of files might be flagged. To prevent this, configure exceptions for known backup tools or scripts that use these commands in a controlled manner. +- Development environments where developers frequently change file permissions for testing purposes can generate false positives. Implement user-based exceptions for development teams to reduce unnecessary alerts. +- System updates or package installations that modify file permissions as part of their normal operation may be detected. Create exceptions for trusted package managers or update processes to avoid false alarms. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified as running the `chown` or `chmod` commands with wildcard injections to halt potential privilege escalation activities. +- Conduct a thorough review of system logs and command histories to identify any unauthorized changes made to file permissions or ownership and revert them to their original state. +- Reset credentials and review access permissions for users on the affected system to ensure no unauthorized access persists. +- Implement file integrity monitoring to detect unauthorized changes to critical files and directories in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Update and patch the affected system to address any vulnerabilities that may have been exploited during the attack, ensuring all security updates are applied.""" [[rule.threat]] diff --git a/rules/linux/privilege_escalation_container_util_misconfiguration.toml b/rules/linux/privilege_escalation_container_util_misconfiguration.toml index b5167a53e88..caab0b19d49 100644 --- a/rules/linux/privilege_escalation_container_util_misconfiguration.toml +++ b/rules/linux/privilege_escalation_container_util_misconfiguration.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/31" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -77,6 +77,39 @@ process where host.os.type == "linux" and event.type == "start" and event.action ) and not user.Ext.real.id == "0" and not group.Ext.real.id == "0" and process.interactive == true and process.parent.interactive == true ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Privilege Escalation via Container Misconfiguration + +Containers, managed by tools like runc and ctr, isolate applications for security and efficiency. Misconfigurations can allow attackers to exploit these tools, running containers with elevated privileges or accessing sensitive host resources. The detection rule identifies suspicious use of these utilities by non-root users in interactive sessions, flagging potential privilege escalation attempts. + +### Possible investigation steps + +- Review the alert details to identify the specific non-root user and group involved in the suspicious activity, as indicated by the user.Ext.real.id and group.Ext.real.id fields. +- Examine the process tree to understand the parent-child relationship of the processes, focusing on the interactive nature of both the process and its parent, as indicated by process.interactive and process.parent.interactive fields. +- Investigate the command-line arguments used with the runc or ctr utilities, particularly looking for the use of "run" and any potentially dangerous flags like "--privileged" or "--mount" that could indicate an attempt to escalate privileges. +- Check the system logs and audit logs for any additional context around the time of the alert, focusing on any other suspicious activities or anomalies involving the same user or process. +- Assess the configuration and access controls of the container management tools on the host to identify any misconfigurations or vulnerabilities that could have been exploited. + +### False positive analysis + +- Non-root users in development environments may frequently use runc or ctr for legitimate container management tasks. To mitigate this, consider creating exceptions for specific user IDs or groups known to perform these actions regularly. +- Automated scripts or CI/CD pipelines might execute container commands interactively without root permissions. Identify these scripts and exclude their associated user accounts or process names from triggering the rule. +- Some system administrators may operate with non-root accounts for security reasons but still require access to container management tools. Document these users and adjust the rule to exclude their activities by user ID or group ID. +- Training or testing environments where users are encouraged to experiment with container configurations might trigger false positives. Implement a separate monitoring policy for these environments to reduce noise in production alerts. + +### Response and remediation + +- Immediately isolate the affected container to prevent further unauthorized access or potential lateral movement within the host system. +- Terminate any suspicious container processes identified by the detection rule to halt any ongoing privilege escalation attempts. +- Conduct a thorough review of container configurations and permissions, specifically focusing on the use of runc and ctr utilities, to identify and rectify any misconfigurations that allow non-root users to execute privileged operations. +- Implement strict access controls and enforce the principle of least privilege for container management utilities to ensure only authorized users can execute privileged commands. +- Monitor for any additional signs of compromise or unusual activity on the host system, particularly focusing on processes initiated by non-root users with elevated privileges. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on the broader environment. +- Update and enhance detection capabilities to include additional indicators of compromise related to container misconfigurations and privilege escalation attempts, ensuring timely alerts for similar threats in the future.""" [[rule.threat]] diff --git a/rules/linux/privilege_escalation_dac_permissions.toml b/rules/linux/privilege_escalation_dac_permissions.toml index 3cf2729319a..ba4a168dd39 100644 --- a/rules/linux/privilege_escalation_dac_permissions.toml +++ b/rules/linux/privilege_escalation_dac_permissions.toml @@ -2,7 +2,7 @@ creation_date = "2024/01/08" integration = ["endpoint"] maturity = "production" -updated_date = "2024/11/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -71,6 +71,41 @@ process.command_line:(*sudoers* or *passwd* or *shadow* or */root/*) and not ( ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Privilege Escalation via Linux DAC permissions + +Linux Discretionary Access Control (DAC) allows file owners to set permissions, potentially leading to privilege escalation if misconfigured. Adversaries exploit DAC by using processes with capabilities like CAP_DAC_OVERRIDE to bypass permission checks. The detection rule identifies suspicious processes accessing sensitive files, excluding benign activities, to flag potential misuse of DAC permissions. + +### Possible investigation steps + +- Review the process command line to identify the specific command executed and determine if it involves sensitive files like sudoers, passwd, shadow, or directories under /root/. +- Check the user ID associated with the process to verify if it is a non-root user attempting to access or modify sensitive files. +- Investigate the process name and executable path to ensure it is not part of the excluded benign processes or paths, such as tar, getent, or /usr/lib/*/lxc/rootfs/*. +- Analyze the parent process name to determine if it is a known benign parent like dpkg or gnome-shell, which might indicate a legitimate operation. +- Examine the process thread capabilities, specifically CAP_DAC_OVERRIDE or CAP_DAC_READ_SEARCH, to understand the level of access the process has and assess if it aligns with expected behavior for the user or application. +- Correlate the event with other logs or alerts to identify any patterns or sequences of activities that might indicate a broader attack or misconfiguration issue. + +### False positive analysis + +- Processes like "tar", "getent", "su", and others listed in the rule are known to perform legitimate operations on sensitive files. Exclude these processes from triggering alerts by adding them to the exception list in the detection rule. +- System management tools such as "dpkg" and "podman" may access sensitive files during routine operations. Consider excluding these tools if they are part of regular system maintenance activities. +- Processes running under user ID "0" (root) are often legitimate and necessary for system operations. Ensure that these are excluded from alerts to avoid unnecessary noise. +- Executables located in paths like /usr/lib/*/lxc/rootfs/* are typically part of containerized environments and may not pose a threat. Exclude these paths if they are part of your standard infrastructure. +- Parent processes such as "java" or those with names ending in "postinst" may be involved in legitimate software installations or updates. Review and exclude these if they are part of expected system behavior. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, especially those with CAP_DAC_OVERRIDE or CAP_DAC_READ_SEARCH capabilities accessing sensitive files. +- Conduct a thorough review of the affected system's user accounts and permissions to identify and revoke any unauthorized privilege escalations. +- Restore any modified or compromised sensitive files, such as /etc/passwd or /etc/shadow, from a known good backup. +- Implement additional monitoring on the affected system to detect any further attempts at privilege escalation or unauthorized access. +- Escalate the incident to the security operations team for a comprehensive investigation to determine the root cause and potential impact. +- Apply security patches and updates to the affected system to mitigate any known vulnerabilities that could be exploited for privilege escalation.""" [[rule.threat]] diff --git a/rules/linux/privilege_escalation_docker_escape_via_nsenter.toml b/rules/linux/privilege_escalation_docker_escape_via_nsenter.toml index ea2de502b4b..1b74bc06fb3 100644 --- a/rules/linux/privilege_escalation_docker_escape_via_nsenter.toml +++ b/rules/linux/privilege_escalation_docker_escape_via_nsenter.toml @@ -2,7 +2,7 @@ creation_date = "2024/07/10" integration = ["endpoint"] maturity = "production" -updated_date = "2024/07/10" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -35,6 +35,41 @@ process where host.os.type == "linux" and event.type == "change" and event.actio process.entry_leader.entry_meta.type == "container" and process.args == "nsenter" and process.args in ("-t", "--target") and process.args_count >= 4 ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Escape via Nsenter + +Docker containers use namespaces to isolate processes, ensuring they operate independently from the host system. The `nsenter` command allows users to access these namespaces, which is essential for managing containerized environments. However, adversaries can exploit `nsenter` to break out of a container, gaining unauthorized access to the host system. The detection rule identifies suspicious UID changes involving `nsenter`, signaling potential container escapes and privilege escalation attempts. + +### Possible investigation steps + +- Review the alert details to confirm the presence of a UID change event involving the nsenter command, as indicated by the query fields. +- Identify the container from which the nsenter command was executed by examining the process.entry_leader.entry_meta.type field. +- Investigate the process arguments to verify the use of nsenter with the -t or --target options, ensuring the process.args_count is 4 or more, which may indicate an attempt to target a specific namespace. +- Check the user and process context before and after the UID change to understand the potential impact and scope of the privilege escalation. +- Analyze the container's logs and any associated host logs around the time of the event to gather additional context and identify any suspicious activities or patterns. +- Assess the container's configuration and security settings to determine if there are any vulnerabilities or misconfigurations that could have been exploited. +- If unauthorized access is confirmed, initiate incident response procedures to contain and remediate the threat, including reviewing other containers and systems for similar activities. + +### False positive analysis + +- Routine administrative tasks using nsenter can trigger false positives, especially when system administrators use it for legitimate container management. To mitigate this, create exceptions for known administrative scripts or processes that frequently use nsenter. +- Automated monitoring tools or scripts that perform health checks or maintenance on containers might use nsenter, leading to false alerts. Identify these tools and whitelist their specific processes or user accounts to reduce noise. +- Development environments where developers frequently enter containers for debugging purposes can cause false positives. Consider excluding specific development user accounts or container IDs from the rule to prevent unnecessary alerts. +- Continuous integration and deployment pipelines that interact with containers might use nsenter as part of their operations. Review these pipelines and exclude their associated processes or user accounts to avoid false detections. + +### Response and remediation + +- Immediately isolate the affected container to prevent further unauthorized access to the host system. This can be done by stopping the container or disconnecting it from the network. +- Conduct a thorough review of the container's logs and processes to identify any unauthorized changes or suspicious activities that occurred before and after the UID change event. +- Revoke any unauthorized access or credentials that may have been compromised during the container escape attempt. Ensure that all access keys and passwords are rotated. +- Patch and update the container image and host system to address any vulnerabilities that may have been exploited. Ensure that the latest security updates are applied. +- Implement stricter namespace and capability restrictions for containers to minimize the risk of privilege escalation. Consider using security tools like AppArmor or SELinux to enforce these restrictions. +- Monitor for any further suspicious activity on the host system and other containers, focusing on similar UID change events or unauthorized use of `nsenter`. +- Escalate the incident to the security operations team for a comprehensive investigation and to assess the potential impact on the broader network and systems.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/privilege_escalation_docker_mount_chroot_container_escape.toml b/rules/linux/privilege_escalation_docker_mount_chroot_container_escape.toml index fac9264d2f0..3f263b94bf4 100644 --- a/rules/linux/privilege_escalation_docker_mount_chroot_container_escape.toml +++ b/rules/linux/privilege_escalation_docker_mount_chroot_container_escape.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/08" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -78,6 +78,41 @@ sequence by host.id, process.parent.entity_id with maxspan=5m [process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "start") and process.name == "chroot"] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Chroot Container Escape via Mount + +Chroot and mount are Linux utilities that can isolate processes and manage file systems, respectively. Adversaries may exploit these to escape containerized environments by mounting the host's root file system and using chroot to change the root directory, gaining unauthorized access. The detection rule identifies this rare sequence by monitoring for mount and chroot executions within a short timeframe, signaling potential privilege escalation attempts. + +### Possible investigation steps + +- Review the alert details to identify the specific host.id and process.parent.entity_id associated with the alert to understand which system and parent process are involved. +- Examine the process execution timeline to confirm the sequence of the mount and chroot commands, ensuring they occurred within the specified maxspan of 5 minutes. +- Investigate the process.args field for the mount command to determine the specific device or file system being targeted, especially focusing on any /dev/sd* entries that suggest attempts to access physical disks. +- Check the user permissions and roles associated with the process.parent.name (e.g., bash, dash, sh) to assess if the user had sufficient privileges to perform such operations. +- Analyze the broader context of the host.os.type to identify any recent changes or anomalies in the Linux environment that could have facilitated this behavior. +- Correlate with other security logs or alerts from the same host to identify any additional suspicious activities or patterns that might indicate a broader attack or compromise. + +### False positive analysis + +- System maintenance scripts may trigger the rule if they involve mounting and chroot operations. Review scheduled tasks and scripts to identify legitimate use and consider excluding these specific processes from the rule. +- Backup or recovery operations that require mounting file systems and changing root directories can also cause false positives. Identify these operations and create exceptions for the associated processes or users. +- Development or testing environments where users frequently perform mount and chroot operations for legitimate purposes may trigger alerts. Evaluate the necessity of these actions and exclude known safe processes or users. +- Automated deployment tools that use mount and chroot as part of their setup routines can be mistaken for malicious activity. Verify the tools and their processes, then add them to an exclusion list if they are deemed safe. +- Custom scripts executed by trusted users that involve mount and chroot should be reviewed. If these scripts are part of regular operations, consider excluding them from the detection rule. + +### Response and remediation + +- Immediately isolate the affected container to prevent further unauthorized access or potential lateral movement within the host system. +- Terminate any suspicious processes identified as executing the mount or chroot commands within the container to halt any ongoing escape attempts. +- Conduct a thorough review of the container's permissions and configurations to ensure that only necessary privileges are granted, reducing the risk of similar exploits. +- Inspect the host system for any signs of compromise or unauthorized access, focusing on logs and system changes around the time of the detected activity. +- Restore the container from a known good backup if any unauthorized changes or compromises are detected, ensuring the environment is clean and secure. +- Update and patch the container and host systems to address any known vulnerabilities that could be exploited for privilege escalation or container escape. +- Escalate the incident to the security operations team for further analysis and to determine if additional monitoring or security measures are required to prevent future occurrences.""" [[rule.threat]] diff --git a/rules/linux/privilege_escalation_enlightenment_window_manager.toml b/rules/linux/privilege_escalation_enlightenment_window_manager.toml index facebb25242..b9bd1974e83 100644 --- a/rules/linux/privilege_escalation_enlightenment_window_manager.toml +++ b/rules/linux/privilege_escalation_enlightenment_window_manager.toml @@ -2,7 +2,7 @@ creation_date = "2024/01/05" integration = ["endpoint"] maturity = "production" -updated_date = "2024/11/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -62,6 +62,41 @@ sequence by host.id, process.parent.entity_id with maxspan=5s process.name == "enlightenment_sys" and process.args in ("/bin/mount/", "-o","noexec","nosuid","nodev","uid=*") ] [process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and user.id == "0"] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Privilege Escalation via Enlightenment + +Enlightenment, a Linux window manager, can be exploited for privilege escalation due to a flaw in its setuid root configuration. Attackers may exploit this by manipulating pathnames, gaining unauthorized root access. The detection rule identifies suspicious execution of 'enlightenment_sys' with specific arguments and subsequent UID changes to root, flagging potential exploitation attempts. + +### Possible investigation steps + +- Review the alert details to confirm the presence of the process "enlightenment_sys" with the specified arguments ("/bin/mount/", "-o", "noexec", "nosuid", "nodev", "uid=*") on a Linux host. +- Check the process execution timeline to verify if the suspicious "enlightenment_sys" execution was followed by a UID change to root (user.id == "0") within a 5-second window. +- Investigate the host.id and process.parent.entity_id to identify the parent process and determine if it was initiated by a legitimate user or service. +- Examine the system logs around the time of the alert to identify any other unusual activities or related processes that might indicate a broader attack or exploitation attempt. +- Assess the affected system for any unauthorized changes or signs of compromise, focusing on privilege escalation indicators and potential persistence mechanisms. +- Review user access logs and permissions to determine if the user associated with the process had legitimate reasons to execute "enlightenment_sys" with elevated privileges. +- Consider isolating the affected system to prevent further exploitation and begin remediation steps, such as applying patches or configuration changes to mitigate the vulnerability. + +### False positive analysis + +- Legitimate administrative tasks using enlightenment_sys may trigger the rule. Review the context of the execution, such as the user and the specific arguments used, to determine if the activity is authorized. +- Automated scripts or system maintenance processes that involve enlightenment_sys with similar arguments might be flagged. Identify these scripts and consider excluding them by specifying their process hashes or paths in the detection rule. +- System updates or package installations that temporarily change UID to root could be misinterpreted as exploitation attempts. Monitor these activities and whitelist known update processes to prevent false alerts. +- Custom user applications that interact with enlightenment_sys for legitimate purposes may cause false positives. Evaluate these applications and, if deemed safe, add them to an exception list based on their unique identifiers. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes related to 'enlightenment_sys' that are running with elevated privileges to stop ongoing exploitation. +- Conduct a thorough review of system logs to identify any unauthorized changes or access patterns, focusing on UID changes to root. +- Revoke any unauthorized access or privileges granted during the exploitation, ensuring that only legitimate users have root access. +- Apply the latest security patches and updates to the Enlightenment package, specifically upgrading to version 0.25.4 or later to mitigate the vulnerability. +- Implement file integrity monitoring to detect unauthorized changes to critical system files and configurations in the future. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] diff --git a/rules/linux/privilege_escalation_gdb_sys_ptrace_elevation.toml b/rules/linux/privilege_escalation_gdb_sys_ptrace_elevation.toml index 10697c46f3a..0c7533b9bd6 100644 --- a/rules/linux/privilege_escalation_gdb_sys_ptrace_elevation.toml +++ b/rules/linux/privilege_escalation_gdb_sys_ptrace_elevation.toml @@ -2,7 +2,7 @@ creation_date = "2024/01/09" integration = ["endpoint"] maturity = "production" -updated_date = "2024/11/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -64,6 +64,41 @@ sequence by host.id, process.entry_leader.entity_id with maxspan=1m [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.name != null and user.id == "0"] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Privilege Escalation via GDB CAP_SYS_PTRACE + +The CAP_SYS_PTRACE capability in Linux allows processes to trace and control other processes, a feature primarily used for debugging. Adversaries can exploit this by using GDB with this capability to inject code into processes running as root, thereby escalating privileges. The detection rule identifies such abuse by monitoring sequences where GDB is executed with CAP_SYS_PTRACE, followed by a process running as root, indicating potential privilege escalation. + +### Possible investigation steps + +- Review the alert details to identify the specific host and process entity ID where the GDB execution with CAP_SYS_PTRACE was detected. +- Examine the process tree on the affected host to determine the parent process of GDB and any child processes it may have spawned, focusing on any processes running as root. +- Check the user account associated with the GDB execution to verify if it is a legitimate user and assess if there are any indications of compromise or misuse. +- Investigate the timeline of events around the alert to identify any preceding or subsequent suspicious activities, such as unauthorized access attempts or changes in user privileges. +- Analyze system logs and audit records for any signs of unauthorized access or privilege escalation attempts, particularly focusing on the time window specified by the maxspan of 1 minute in the query. +- Correlate the findings with other security alerts or incidents on the same host to determine if this event is part of a larger attack campaign. + +### False positive analysis + +- Development environments where GDB is frequently used for legitimate debugging purposes may trigger false positives. To mitigate this, consider excluding specific user accounts or processes that are known to use GDB regularly for debugging. +- Automated testing systems that utilize GDB for testing applications with elevated privileges might be flagged. Implement exceptions for these systems by identifying and excluding their specific process names or user IDs. +- Security tools or monitoring solutions that use GDB with CAP_SYS_PTRACE for legitimate monitoring or analysis tasks can cause false alerts. Review and whitelist these tools by their process names or associated user accounts. +- System administrators or developers who have legitimate reasons to use GDB with elevated capabilities should be identified, and their activities should be excluded from the rule to prevent unnecessary alerts. +- Scheduled maintenance scripts that involve GDB for system diagnostics or performance tuning may be misinterpreted as malicious. Exclude these scripts by their execution schedule or specific identifiers. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified as running with elevated privileges, especially those involving GDB with CAP_SYS_PTRACE. +- Revoke CAP_SYS_PTRACE capability from non-essential users and processes to limit potential abuse. +- Conduct a thorough review of user accounts and permissions on the affected system to ensure no unauthorized privilege escalations have occurred. +- Restore the affected system from a known good backup if any unauthorized changes or code injections are detected. +- Monitor the affected and related systems for any signs of persistence mechanisms or further malicious activity. +- Report the incident to the appropriate internal security team or authority for further investigation and potential escalation if necessary.""" [[rule.threat]] diff --git a/rules/linux/privilege_escalation_gdb_sys_ptrace_netcon.toml b/rules/linux/privilege_escalation_gdb_sys_ptrace_netcon.toml index 68dcaefd123..e747f01af6f 100644 --- a/rules/linux/privilege_escalation_gdb_sys_ptrace_netcon.toml +++ b/rules/linux/privilege_escalation_gdb_sys_ptrace_netcon.toml @@ -2,7 +2,7 @@ creation_date = "2024/01/09" integration = ["endpoint"] maturity = "production" -updated_date = "2024/11/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -66,6 +66,41 @@ sequence by host.id, process.entry_leader.entity_id with maxspan=30s [network where host.os.type == "linux" and event.action == "connection_attempted" and event.type == "start" and process.name != null and user.id == "0"] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Root Network Connection via GDB CAP_SYS_PTRACE + +GDB, a debugger, can be granted the CAP_SYS_PTRACE capability, allowing it to trace and control processes, a feature often exploited by attackers. By injecting code into root processes, adversaries can execute malicious payloads, such as reverse shells. The detection rule identifies suspicious sequences where GDB is used with this capability, followed by a root-initiated network connection, signaling potential privilege escalation or command and control activities. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of GDB with CAP_SYS_PTRACE capability by examining the process name, capabilities, and user ID fields in the alert. +- Investigate the network connection attempt by analyzing the process name and user ID fields to determine if the connection was initiated by a root process. +- Check the timeline of events to ensure the sequence of GDB execution followed by a network connection attempt occurred within the specified maxspan of 30 seconds. +- Identify the destination IP address and port of the network connection to assess if it is known for malicious activity or associated with command and control servers. +- Examine the host system for any signs of compromise or unauthorized changes, focusing on processes and files that may have been affected by the potential privilege escalation. +- Correlate the alert with other security events or logs from the same host to identify any additional suspicious activities or patterns that may indicate a broader attack. + +### False positive analysis + +- Development environments may trigger this rule when developers use GDB with CAP_SYS_PTRACE for legitimate debugging purposes. To mitigate, create exceptions for specific user IDs or processes known to be involved in development activities. +- Automated testing frameworks that utilize GDB for testing applications with root privileges can cause false positives. Identify and exclude these processes or testing environments from the rule. +- System maintenance scripts that require debugging of root processes might inadvertently match the rule criteria. Review and whitelist these scripts or the specific time frames they run to prevent unnecessary alerts. +- Security tools that perform legitimate process tracing as part of their monitoring activities could be mistaken for malicious behavior. Ensure these tools are recognized and excluded from the detection rule. +- Custom administrative scripts that use GDB for process management under root privileges should be documented and excluded to avoid false alarms. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further malicious activity and potential lateral movement. +- Terminate any suspicious processes associated with GDB that have been granted the CAP_SYS_PTRACE capability, especially those initiated by non-root users. +- Conduct a thorough review of the affected system's logs to identify any unauthorized changes or additional malicious activities that may have occurred. +- Reset credentials and review permissions for any accounts that may have been compromised, particularly those with elevated privileges. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Implement network monitoring to detect and block any further unauthorized outbound connections from root processes. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] diff --git a/rules/linux/privilege_escalation_kworker_uid_elevation.toml b/rules/linux/privilege_escalation_kworker_uid_elevation.toml index f17fb467fd1..0fcddb3fbe2 100644 --- a/rules/linux/privilege_escalation_kworker_uid_elevation.toml +++ b/rules/linux/privilege_escalation_kworker_uid_elevation.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/26" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -64,6 +64,39 @@ query = ''' process where host.os.type == "linux" and event.action == "session_id_change" and process.name : "kworker*" and user.id == "0" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Kworker UID Elevation + +Kworker processes are integral to Linux, handling tasks like interrupts and background activities within the kernel. Adversaries may exploit these processes by disguising malicious activities as legitimate kernel operations, often using rootkits to hijack execution flow and gain root access. The detection rule identifies anomalies by monitoring for kworker processes that unexpectedly change session IDs and elevate privileges to root, signaling potential misuse. + +### Possible investigation steps + +- Review the process details for the kworker process with a session ID change and user ID of 0 to confirm the legitimacy of the process and its parent process. +- Check the system logs around the time of the session ID change event for any unusual activities or errors that might indicate tampering or exploitation attempts. +- Investigate any recent changes to the system, such as new software installations or updates, that could have introduced vulnerabilities or unauthorized modifications. +- Analyze the system for signs of rootkit presence, such as hidden files or processes, by using rootkit detection tools or manual inspection techniques. +- Correlate the event with other security alerts or anomalies in the network to determine if this is part of a broader attack campaign or isolated incident. + +### False positive analysis + +- Regular system updates or maintenance activities may trigger session ID changes in kworker processes. Users can monitor scheduled maintenance windows and exclude these time frames from triggering alerts. +- Custom kernel modules or legitimate software that interacts with kernel processes might cause kworker to change session IDs. Identify and whitelist these known modules or software to prevent false positives. +- Automated scripts or tools that require elevated privileges for legitimate tasks could inadvertently cause kworker processes to appear suspicious. Review and document these scripts, then create exceptions for their expected behavior. +- Certain system configurations or optimizations might lead to benign kworker session ID changes. Conduct a baseline analysis of normal system behavior and adjust the detection rule to accommodate these patterns without compromising security. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. +- Terminate the suspicious kworker process identified in the alert to stop any ongoing malicious activity. +- Conduct a thorough review of system logs and process trees to identify any additional compromised processes or indicators of rootkit installation. +- Restore the system from a known good backup if rootkit presence is confirmed, as rootkits can deeply embed themselves into the system. +- Change all credentials and keys that may have been exposed or used on the compromised system to prevent unauthorized access using stolen credentials. +- Implement enhanced monitoring and logging for kworker processes and session ID changes to detect similar activities in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems.""" [[rule.threat]] diff --git a/rules/linux/privilege_escalation_ld_preload_shared_object_modif.toml b/rules/linux/privilege_escalation_ld_preload_shared_object_modif.toml index c1188e26d75..91ca9f05d23 100644 --- a/rules/linux/privilege_escalation_ld_preload_shared_object_modif.toml +++ b/rules/linux/privilege_escalation_ld_preload_shared_object_modif.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/27" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -73,6 +73,41 @@ query = ''' host.os.type:linux and event.category:file and event.action:(updated or renamed or rename or file_rename_event) and not event.type:deletion and file.path:/etc/ld.so.preload and not process.name:(wine or oneagentinstallaction) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Modification of Dynamic Linker Preload Shared Object + +The dynamic linker preload mechanism in Linux, via `/etc/ld.so.preload`, allows preloading of shared libraries, influencing how executables load dependencies. Adversaries exploit this by inserting malicious libraries, hijacking execution flow for privilege escalation. The detection rule monitors changes to this file, excluding benign processes, to identify unauthorized modifications indicative of such abuse. + +### Possible investigation steps + +- Review the alert details to confirm the file path involved is /etc/ld.so.preload and verify the event action is one of the specified actions: updated, renamed, or file_rename_event. +- Identify the process responsible for the modification by examining the process.name field, ensuring it is not one of the excluded processes (wine or oneagentinstallaction). +- Investigate the process that triggered the alert by gathering additional context such as process ID, command line arguments, and parent process to understand its origin and purpose. +- Check the modification timestamp and correlate it with other system events or logs to identify any suspicious activity or patterns around the time of the modification. +- Analyze the contents of /etc/ld.so.preload to determine if any unauthorized or suspicious libraries have been added, and assess their potential impact on the system. +- Review user accounts and permissions associated with the process to determine if there has been any unauthorized access or privilege escalation attempt. +- If malicious activity is confirmed, isolate the affected system and follow incident response procedures to mitigate the threat and prevent further exploitation. + +### False positive analysis + +- Legitimate software installations or updates may modify /etc/ld.so.preload. To handle this, monitor the process names associated with these activities and consider adding them to the exclusion list if they are verified as benign. +- System management tools like configuration management software might update /etc/ld.so.preload as part of routine operations. Identify these tools and exclude their process names from the detection rule to prevent false alerts. +- Custom scripts or administrative tasks executed by trusted users could inadvertently trigger the rule. Review these scripts and, if necessary, exclude their process names or user accounts from the detection criteria. +- Security agents or monitoring tools that interact with system files might cause false positives. Verify these tools' activities and exclude their process names if they are known to be safe and necessary for system operations. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary. +- Terminate any suspicious processes that are not part of the baseline or known benign applications, especially those related to the modification of `/etc/ld.so.preload`. +- Restore the `/etc/ld.so.preload` file from a known good backup to ensure no malicious libraries are preloaded. +- Conduct a thorough review of recent system changes and installed packages to identify any unauthorized software or modifications that may have facilitated the attack. +- Escalate the incident to the security operations team for a deeper forensic analysis to determine the scope of the compromise and identify any additional affected systems. +- Implement additional monitoring on the affected system and similar environments to detect any further attempts to modify the dynamic linker preload file. +- Review and enhance access controls and permissions on critical system files like `/etc/ld.so.preload` to prevent unauthorized modifications in the future.""" [[rule.threat]] diff --git a/rules/linux/privilege_escalation_linux_suspicious_symbolic_link.toml b/rules/linux/privilege_escalation_linux_suspicious_symbolic_link.toml index f1192e1a86d..a2a5a3ec4f0 100644 --- a/rules/linux/privilege_escalation_linux_suspicious_symbolic_link.toml +++ b/rules/linux/privilege_escalation_linux_suspicious_symbolic_link.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/27" integration = ["endpoint"] maturity = "production" -updated_date = "2024/07/30" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -77,6 +77,41 @@ process.name == "ln" and process.args in ("-s", "-sf") and process.parent.name in ("bash", "dash", "ash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and not user.Ext.real.id == "0" and not group.Ext.real.id == "0" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Symbolic Link Created + +Symbolic links in Linux are shortcuts that point to files or directories, facilitating easy access. Adversaries may exploit these links to redirect privileged processes to sensitive files, potentially escalating privileges or accessing restricted data. The detection rule identifies suspicious link creation by monitoring the execution of the 'ln' command with specific arguments and targets, especially when initiated by non-root users, indicating potential misuse. + +### Possible investigation steps + +- Review the process details to confirm the execution of the 'ln' command with suspicious arguments such as "-s" or "-sf" and verify the target files or directories listed in the query, like "/etc/shadow" or "/bin/bash". +- Check the user and group IDs associated with the process to ensure they are not root (ID "0"), as the rule specifically targets non-root users. +- Investigate the parent process name to determine if it is one of the shell processes listed in the query, such as "bash" or "zsh", which might indicate a user-initiated action. +- Examine the working directory and arguments to identify if the symbolic link creation is targeting sensitive locations like "/etc/cron.d/*" or "/home/*/.ssh/*". +- Analyze the user's recent activity and command history to understand the context and intent behind the symbolic link creation. +- Correlate this event with other security alerts or logs to identify any patterns or additional suspicious activities involving the same user or system. + +### False positive analysis + +- Non-root users creating symbolic links for legitimate administrative tasks may trigger the rule. To manage this, identify and whitelist specific users or groups who regularly perform these tasks without malicious intent. +- Automated scripts or applications that use symbolic links for configuration management or software deployment might be flagged. Review these processes and exclude them by specifying the script or application names in the detection rule. +- Development environments where symbolic links are used to manage dependencies or version control can cause false positives. Exclude directories or processes associated with these environments to prevent unnecessary alerts. +- Backup or synchronization tools that create symbolic links as part of their operation may be mistakenly identified. Identify these tools and add exceptions for their typical execution patterns. +- System maintenance activities that involve symbolic link creation, such as linking to shared libraries or binaries, should be reviewed and excluded if they are part of routine operations. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the attacker. +- Terminate any suspicious processes related to the 'ln' command that are identified in the alert to stop any ongoing malicious activity. +- Conduct a thorough review of the symbolic links created, especially those pointing to sensitive files or directories, and remove any unauthorized or suspicious links. +- Reset credentials and review access permissions for any accounts that may have been compromised or used in the attack, focusing on those with elevated privileges. +- Restore any altered or compromised files from a known good backup to ensure system integrity and prevent further exploitation. +- Implement additional monitoring and logging for symbolic link creation and other related activities to detect similar threats in the future. +- Escalate the incident to the security operations team for further investigation and to assess the need for broader organizational response measures.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/privilege_escalation_linux_uid_int_max_bug.toml b/rules/linux/privilege_escalation_linux_uid_int_max_bug.toml index d628bd94d5b..2eb616dc5c8 100644 --- a/rules/linux/privilege_escalation_linux_uid_int_max_bug.toml +++ b/rules/linux/privilege_escalation_linux_uid_int_max_bug.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/27" integration = ["endpoint", "crowdstrike"] maturity = "production" -updated_date = "2025/01/08" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -66,6 +66,40 @@ process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "ProcessRollup2") and process.name == "systemd-run" and process.args == "-t" and process.args_count >= 3 and user.id >= "1000000000" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Privilege Escalation via UID INT_MAX Bug Detected + +In certain Linux environments, systemd-run is a utility that allows users to create and start a transient service or scope unit. A bug in older Linux versions permits users with a UID exceeding INT_MAX to exploit this utility for privilege escalation, potentially gaining unauthorized access. The detection rule identifies suspicious executions of systemd-run by monitoring for processes initiated by users with unusually high UIDs, signaling potential exploitation attempts. + +### Possible investigation steps + +- Review the alert details to confirm the presence of a user with a UID greater than INT_MAX, as indicated by the user.id field in the query. +- Examine the process execution context, including the process.args and process.args_count fields, to verify the use of systemd-run with the specified arguments, which may indicate an exploitation attempt. +- Check the system logs for any other suspicious activities or anomalies around the time of the alert, focusing on processes initiated by the same user or related to systemd-run. +- Investigate the history and purpose of the user account with the high UID to determine if it was intentionally created or if it appears to be an anomaly. +- Assess the affected system's Linux version to determine if it is one of the older versions known to be vulnerable to this bug, and consider updating or patching if necessary. +- Look for any additional indicators of compromise or privilege escalation attempts on the system, such as unauthorized access to sensitive files or changes in user permissions. + +### False positive analysis + +- High UID service accounts: Some legitimate service accounts may have UIDs exceeding INT_MAX for specific operational purposes. Review these accounts and, if verified as non-threatening, add them to an exception list to prevent unnecessary alerts. +- Custom scripts or automation tools: Organizations may use scripts or tools that invoke systemd-run with high UID accounts for legitimate tasks. Identify these scripts and whitelist their execution paths or specific user IDs to reduce false positives. +- Testing environments: In testing or development environments, users might intentionally create accounts with high UIDs to test system behavior. Ensure these environments are isolated and consider excluding them from monitoring to avoid false alerts. +- Legacy systems: Older systems might have configurations that inadvertently trigger this rule. Conduct a thorough review of these systems and apply exceptions where the behavior is deemed safe and necessary for operational continuity. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes initiated by users with UIDs exceeding INT_MAX, especially those involving systemd-run, to halt potential privilege escalation. +- Conduct a thorough review of user accounts on the affected system to identify and disable any accounts with UIDs greater than INT_MAX. +- Apply available patches or updates to the Linux operating system to address the specific bug related to UID handling in systemd-run. +- Review and adjust user account creation policies to ensure no new accounts are created with UIDs exceeding the standard range. +- Monitor for any further attempts to exploit this vulnerability by setting up alerts for similar suspicious activities, focusing on high UID values and systemd-run usage. +- Report the incident to the appropriate internal security team or external authorities if necessary, providing details of the exploit and actions taken.""" [[rule.threat]] diff --git a/rules/linux/privilege_escalation_load_and_unload_of_kernel_via_kexec.toml b/rules/linux/privilege_escalation_load_and_unload_of_kernel_via_kexec.toml index 57cab49ea6a..825eaad5774 100644 --- a/rules/linux/privilege_escalation_load_and_unload_of_kernel_via_kexec.toml +++ b/rules/linux/privilege_escalation_load_and_unload_of_kernel_via_kexec.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_ maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/08" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -74,6 +74,41 @@ process where host.os.type == "linux" and event.type == "start" and process.name == "kexec" and process.args in ("--exec", "-e", "--load", "-l", "--unload", "-u") and not process.parent.name in ("kdumpctl", "unload.sh") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Kernel Load or Unload via Kexec Detected + +Kexec is a Linux feature allowing a new kernel to load without rebooting, streamlining updates and recovery. However, attackers can exploit kexec to bypass security, escalate privileges, or hide activities by loading malicious kernels. The detection rule identifies suspicious kexec usage by monitoring process actions and arguments, excluding benign parent processes, to flag potential threats. + +### Possible investigation steps + +- Review the process details to confirm the presence of the kexec command with suspicious arguments such as "--exec", "-e", "--load", "-l", "--unload", or "-u". +- Investigate the parent process of the kexec command to ensure it is not a benign process like "kdumpctl" or "unload.sh", which are excluded from the detection rule. +- Check the user account associated with the kexec process to determine if it has the necessary privileges and if the activity aligns with their typical behavior. +- Analyze recent system logs and security events for any signs of privilege escalation or unauthorized kernel modifications around the time the kexec command was executed. +- Examine the system for any signs of persistence mechanisms or other indicators of compromise that may suggest a broader attack campaign. +- Correlate this event with other alerts or anomalies in the environment to assess if this is part of a larger attack pattern or isolated incident. + +### False positive analysis + +- Kdump operations may trigger false positives as kdumpctl is a benign parent process for kexec. Ensure kdumpctl is included in the exclusion list to prevent unnecessary alerts. +- Custom scripts for kernel unloading, such as unload.sh, can cause false positives. Verify these scripts are legitimate and add them to the exclusion list if they are frequently used in your environment. +- Routine administrative tasks involving kernel updates or testing may involve kexec. Confirm these activities are authorized and consider excluding specific administrative accounts or processes from detection. +- Automated system recovery processes that utilize kexec might be flagged. Identify these processes and exclude them if they are part of a known and secure recovery mechanism. +- Security tools or monitoring solutions that use kexec for legitimate purposes should be reviewed and excluded to avoid false alerts, ensuring they are recognized as trusted applications. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the attacker. +- Terminate any suspicious kexec processes identified by the detection rule to halt any ongoing malicious kernel loading activities. +- Conduct a thorough review of system logs and process histories to identify any unauthorized kernel loads or modifications, and revert to a known good state if necessary. +- Restore the system from a clean backup taken before the suspicious activity was detected to ensure system integrity and remove any potential backdoors or malicious kernels. +- Update and patch the system to the latest security standards to mitigate any vulnerabilities that could be exploited by similar attacks in the future. +- Implement strict access controls and monitoring on systems with kexec capabilities to prevent unauthorized usage and ensure only trusted personnel can perform kernel operations. +- Escalate the incident to the security operations center (SOC) or relevant incident response team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/privilege_escalation_looney_tunables_cve_2023_4911.toml b/rules/linux/privilege_escalation_looney_tunables_cve_2023_4911.toml index 75d12aa5a97..21c1ee0eebb 100644 --- a/rules/linux/privilege_escalation_looney_tunables_cve_2023_4911.toml +++ b/rules/linux/privilege_escalation_looney_tunables_cve_2023_4911.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/05" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -74,6 +74,41 @@ sequence by host.id, process.parent.entity_id, process.executable with maxspan=5 [process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and process.env_vars : "*GLIBC_TUNABLES=glibc.*=glibc.*=*"] with runs=5 ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Privilege Escalation via CVE-2023-4911 + +CVE-2023-4911 exploits a buffer overflow in the GNU C Library's dynamic loader, specifically targeting the GLIBC_TUNABLES environment variable. Adversaries can manipulate this to gain elevated privileges on Linux systems. The detection rule identifies suspicious activity by monitoring processes with specific environment variables, flagging repeated execution attempts within a short timeframe, indicating potential exploitation efforts. + +### Possible investigation steps + +- Review the alert details to identify the specific host.id and process.parent.entity_id associated with the suspicious activity. +- Examine the process.executable path to determine if it is a legitimate application or potentially malicious. +- Check the process.env_vars for any unusual or unexpected GLIBC_TUNABLES values that could indicate manipulation attempts. +- Investigate the host's recent process execution history to identify any patterns or anomalies, focusing on processes with the GLIBC_TUNABLES environment variable set. +- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related suspicious activities. +- Assess the system for any signs of privilege escalation or unauthorized access, such as new user accounts or changes in user privileges. + +### False positive analysis + +- Frequent legitimate use of GLIBC_TUNABLES environment variable by system administrators or automated scripts can trigger false positives. Users should identify and whitelist these known benign processes to prevent unnecessary alerts. +- Some Linux distributions or specific applications may use GLIBC_TUNABLES for performance tuning or compatibility reasons. Review and document these cases, and create exceptions for these processes to avoid false alarms. +- Development environments where GLIBC_TUNABLES is used for testing purposes might also cause false positives. Implement a policy to exclude these environments from monitoring or adjust the rule to account for these specific use cases. +- Scheduled tasks or cron jobs that utilize GLIBC_TUNABLES for legitimate purposes can be mistaken for exploitation attempts. Ensure these tasks are recognized and excluded from the rule's scope to reduce noise. +- If a particular user or group frequently triggers the rule due to their role or activities, consider creating a user-based exception to minimize false positives while maintaining security oversight. + +### Response and remediation + +- Immediately isolate the affected Linux system from the network to prevent further exploitation or lateral movement by the adversary. +- Terminate any suspicious processes identified with the GLIBC_TUNABLES environment variable to halt ongoing exploitation attempts. +- Apply the latest security patches and updates to the GNU C Library on all affected systems to remediate the buffer overflow vulnerability. +- Conduct a thorough review of system logs and process execution history to identify any unauthorized changes or additional indicators of compromise. +- Restore affected systems from a known good backup taken before the exploitation attempt, ensuring that the backup is free from any malicious modifications. +- Implement enhanced monitoring and alerting for unusual process executions and environment variable manipulations 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 assess the potential impact on other systems within the network.""" [[rule.threat]] diff --git a/rules/linux/privilege_escalation_netcon_via_sudo_binary.toml b/rules/linux/privilege_escalation_netcon_via_sudo_binary.toml index 19d9e7e5aa4..ad16310ddfe 100644 --- a/rules/linux/privilege_escalation_netcon_via_sudo_binary.toml +++ b/rules/linux/privilege_escalation_netcon_via_sudo_binary.toml @@ -2,7 +2,7 @@ creation_date = "2024/01/15" integration = ["endpoint"] maturity = "production" -updated_date = "2024/07/18" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -67,6 +67,39 @@ event.action in ("connection_attempted", "ipv4_connection_attempt_event") and pr ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Network Connection via Sudo Binary + +The 'sudo' command in Linux allows users to execute commands with elevated privileges, typically as the root user. Adversaries may exploit this by injecting malicious shellcode into processes running with these privileges, potentially establishing unauthorized network connections. The detection rule identifies unusual network activity initiated by 'sudo', excluding common internal IP ranges, to flag potential privilege escalation attempts. + +### Possible investigation steps + +- Review the alert details to identify the specific destination IP address involved in the network connection attempt. Cross-reference this IP with known malicious IP databases or threat intelligence sources to assess potential risk. +- Examine the process tree and command line arguments associated with the 'sudo' process to determine if there are any unusual or unexpected commands being executed that could indicate malicious activity. +- Check the user account that initiated the 'sudo' command to verify if it is a legitimate user and if there have been any recent changes to user permissions or roles that could explain the activity. +- Investigate any recent login attempts or authentication logs for the user account involved to identify any suspicious access patterns or failed login attempts that could suggest a compromised account. +- Analyze network traffic logs around the time of the alert to identify any other unusual outbound connections or data exfiltration attempts that may correlate with the 'sudo' network connection event. + +### False positive analysis + +- Internal network monitoring tools may trigger this rule if they use the sudo command to initiate legitimate network connections. To handle this, identify the specific tools and processes involved and create exceptions for their known IP addresses. +- Automated scripts or cron jobs running with elevated privileges might occasionally establish network connections for updates or data transfers. Review these scripts and whitelist their expected behavior to prevent false positives. +- System administrators using sudo for remote management tasks could inadvertently trigger the rule. Document and exclude the IP addresses and processes associated with routine administrative tasks. +- Security software or agents that require elevated permissions to perform network diagnostics or reporting may cause alerts. Verify these applications and add them to an exception list if they are deemed safe and necessary for operations. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes associated with the 'sudo' command that are attempting to establish network connections. +- Conduct a thorough review of system logs and network traffic to identify any additional indicators of compromise or lateral movement attempts. +- Reset credentials for any accounts that may have been compromised, particularly those with elevated privileges. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/privilege_escalation_overlayfs_local_privesc.toml b/rules/linux/privilege_escalation_overlayfs_local_privesc.toml index a62129ec619..6a3b3f4f2e0 100644 --- a/rules/linux/privilege_escalation_overlayfs_local_privesc.toml +++ b/rules/linux/privilege_escalation_overlayfs_local_privesc.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/28" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -65,6 +65,41 @@ sequence by process.parent.entity_id, host.id with maxspan=5s [process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and user.id == "0"] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Privilege Escalation via OverlayFS + +OverlayFS is a union filesystem used in Linux environments to overlay one filesystem on top of another, allowing for efficient file management and updates. Adversaries exploit vulnerabilities in Ubuntu's OverlayFS modifications to execute crafted executables that escalate privileges to root. The detection rule identifies suspicious sequences involving the 'unshare' command with specific arguments and subsequent UID changes to root, indicating potential exploitation attempts. + +### Possible investigation steps + +- Review the alert details to confirm the presence of the 'unshare' command with the specific arguments '-r', '-rm', 'm', and '*cap_setuid*' as indicated in the query. This will help verify if the command execution aligns with the known exploitation pattern. +- Check the process tree and parent process information using the process.parent.entity_id to understand the context in which the 'unshare' command was executed. This can provide insights into whether the command was part of a legitimate operation or a potential attack. +- Investigate the user account associated with the process execution (user.id != "0") to determine if the account has a history of suspicious activity or if it has been compromised. +- Examine the host.id and host.os.type fields to identify the specific Linux host involved and assess its vulnerability status regarding CVE-2023-2640 and CVE-2023-32629. This can help determine if the host is susceptible to the exploitation attempt. +- Analyze any subsequent UID changes to root (user.id == "0") to confirm if the privilege escalation was successful and identify any unauthorized access or actions taken by the elevated process. +- Review system logs and other security alerts around the time of the event to identify any additional indicators of compromise or related suspicious activities that might corroborate the exploitation attempt. + +### False positive analysis + +- Legitimate administrative tasks using the 'unshare' command with similar arguments may trigger the rule. Review the context of the command execution and verify if it aligns with routine system maintenance or configuration changes. +- Automated scripts or system management tools that utilize 'unshare' for containerization or namespace isolation might cause false positives. Identify these scripts and consider excluding their specific process names or paths from the rule. +- Development environments where developers frequently test applications with elevated privileges could inadvertently match the rule criteria. Implement user-based exceptions for known developer accounts to reduce noise. +- Security tools or monitoring solutions that simulate privilege escalation scenarios for testing purposes may be flagged. Whitelist these tools by their process hash or signature to prevent unnecessary alerts. +- Custom applications that require temporary privilege elevation for legitimate operations should be reviewed. If deemed safe, add these applications to an exception list based on their unique identifiers. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further exploitation or lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, particularly those involving the 'unshare' command with the specified arguments. +- Conduct a thorough review of user accounts and privileges on the affected system to ensure no unauthorized changes have been made, especially focusing on accounts with root access. +- Apply the latest security patches and updates to the affected system, specifically addressing CVE-2023-2640 and CVE-2023-32629, to mitigate the vulnerability in OverlayFS. +- Monitor for any further attempts to exploit the vulnerability by setting up alerts for similar sequences of commands and UID changes. +- Escalate the incident to the security operations team for a detailed forensic analysis to understand the scope and impact of the exploitation attempt. +- Implement additional security measures, such as enhanced logging and monitoring, to detect and respond to privilege escalation attempts more effectively in the future.""" [[rule.threat]] diff --git a/rules/linux/privilege_escalation_pkexec_envar_hijack.toml b/rules/linux/privilege_escalation_pkexec_envar_hijack.toml index 6b29e1b8b63..3435ff3037b 100644 --- a/rules/linux/privilege_escalation_pkexec_envar_hijack.toml +++ b/rules/linux/privilege_escalation_pkexec_envar_hijack.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/06" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -62,6 +62,41 @@ type = "eql" query = ''' file where host.os.type == "linux" and file.path : "/*GCONV_PATH*" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Privilege Escalation via PKEXEC + +Polkit's pkexec is a command-line utility that allows an authorized user to execute commands as another user, typically root, in Linux environments. Adversaries exploit vulnerabilities like CVE-2021-4034 by injecting unsecure environment variables, enabling unauthorized privilege escalation. The detection rule identifies suspicious file paths indicative of such exploitation attempts, focusing on environment variable manipulation to preemptively flag potential threats. + +### Possible investigation steps + +- Review the alert details to confirm the presence of the file path pattern "/*GCONV_PATH*" on a Linux host, as this is indicative of the potential exploitation attempt. +- Examine the process execution history on the affected host to identify any instances of pkexec being executed around the time of the alert. Look for unusual or unauthorized command executions. +- Check the environment variables set during the pkexec execution to identify any suspicious or unauthorized modifications that could indicate an exploitation attempt. +- Investigate the user account associated with the alert to determine if it has a history of privilege escalation attempts or other suspicious activities. +- Analyze system logs and security events for any additional indicators of compromise or related suspicious activities that occurred before or after the alert. +- Assess the patch status of the affected system to determine if it is vulnerable to CVE-2021-4034 and ensure that appropriate security updates have been applied. + +### False positive analysis + +- Routine administrative tasks involving pkexec may trigger alerts if they involve environment variable manipulation. Review the context of the command execution to determine if it aligns with expected administrative behavior. +- Custom scripts or applications that legitimately use environment variables in their execution paths might be flagged. Identify these scripts and consider adding them to an exception list if they are verified as non-threatening. +- Automated system management tools that modify environment variables for legitimate purposes could cause false positives. Monitor these tools and exclude their known safe operations from the detection rule. +- Development environments where developers frequently test applications with varying environment variables might generate alerts. Establish a baseline of normal activity and exclude these patterns if they are consistent and verified as safe. +- Scheduled tasks or cron jobs that involve environment variable changes should be reviewed. If they are part of regular system maintenance, document and exclude them from triggering alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the attacker. +- Terminate any suspicious processes associated with pkexec or unauthorized privilege escalation attempts to halt ongoing exploitation. +- Conduct a thorough review of system logs and file access records to identify any unauthorized changes or access patterns, focusing on the presence of GCONV_PATH in file paths. +- Revert any unauthorized changes made by the attacker, such as modifications to critical system files or configurations, to restore system integrity. +- Apply the latest security patches and updates to the polkit package to address CVE-2021-4034 and prevent future exploitation. +- Implement enhanced monitoring and alerting for similar privilege escalation attempts, ensuring that any future attempts are detected and responded to promptly. +- Report the incident to relevant internal security teams and, if necessary, escalate to external authorities or cybersecurity partners for further investigation and support.""" [[rule.threat]] diff --git a/rules/linux/privilege_escalation_potential_bufferoverflow_attack.toml b/rules/linux/privilege_escalation_potential_bufferoverflow_attack.toml index d0bdbf799f4..022e3639240 100644 --- a/rules/linux/privilege_escalation_potential_bufferoverflow_attack.toml +++ b/rules/linux/privilege_escalation_potential_bufferoverflow_attack.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2023/12/11" maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -42,6 +42,42 @@ type = "threshold" query = ''' kibana.alert.rule.rule_id:"5c81fc9d-1eae-437f-ba07-268472967013" and host.os.type:linux and event.kind:signal ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Buffer Overflow Attack Detected + +Buffer overflow attacks exploit vulnerabilities in software to execute arbitrary code, often leading to privilege escalation. Adversaries may trigger numerous segmentation faults (segfaults) on Linux systems as they attempt to exploit these vulnerabilities. The detection rule identifies potential attacks by monitoring for a surge in segfault alerts, indicating possible exploitation attempts, and correlates them with known threat tactics. + +### Possible investigation steps + +- Review the alert details to confirm the presence of a surge in segfault alerts, focusing on the host.os.type:linux field to ensure the affected systems are Linux-based. +- Correlate the timestamps of the segfault alerts to identify any patterns or specific timeframes when the surge occurred, which might indicate the start of an exploitation attempt. +- Investigate the affected host(s) by examining system logs and application logs around the time of the segfault alerts to identify any suspicious activities or anomalies. +- Check for any recent changes or updates to the software running on the affected host(s) that might have introduced vulnerabilities. +- Look for any known vulnerabilities or exploits associated with the software or services running on the affected host(s) that could be targeted by a buffer overflow attack. +- Assess the network traffic to and from the affected host(s) during the time of the alerts to identify any unusual or unauthorized connections that could indicate an attack vector. +- Consult threat intelligence sources to determine if there are any ongoing campaigns or known threat actors targeting similar vulnerabilities or systems. + +### False positive analysis + +- High-volume legitimate application crashes can trigger false positives, especially during software testing or development phases. Users should identify and exclude these applications from the rule by creating exceptions for specific processes known to cause frequent segfaults without malicious intent. +- System updates or patches may cause temporary spikes in segfault alerts as applications restart or reconfigure. Users can mitigate this by setting a temporary exception during scheduled maintenance windows. +- Custom scripts or automated tasks that interact with system memory in non-standard ways might generate segfaults. Review these scripts and, if verified as safe, exclude them from the rule to prevent false alerts. +- Certain security tools or monitoring software may intentionally cause segfaults as part of their operation. Identify these tools and add them to the exception list to avoid unnecessary alerts. +- Legacy applications with known stability issues might frequently cause segfaults. Consider updating or replacing these applications, or create exceptions if updates are not feasible. + +### Response and remediation + +- Isolate the affected Linux host immediately to prevent further exploitation and lateral movement within the network. +- Terminate any suspicious processes identified on the affected host that are associated with the segfault alerts to halt potential malicious activity. +- Conduct a thorough analysis of the affected application or service to identify and patch the specific vulnerability being exploited, ensuring all software is updated to the latest secure versions. +- Review and enhance system and application logging to capture detailed information on segfault occurrences and related activities for future analysis and detection. +- Implement additional security controls such as application whitelisting and memory protection mechanisms (e.g., DEP, ASLR) to mitigate the risk of buffer overflow attacks. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Document the incident, including all actions taken and findings, to improve future response efforts and update incident response plans accordingly.""" [[rule.threat]] diff --git a/rules/linux/privilege_escalation_potential_suid_sgid_exploitation.toml b/rules/linux/privilege_escalation_potential_suid_sgid_exploitation.toml index c5e85063fdc..6e684157679 100644 --- a/rules/linux/privilege_escalation_potential_suid_sgid_exploitation.toml +++ b/rules/linux/privilege_escalation_potential_suid_sgid_exploitation.toml @@ -4,7 +4,7 @@ integration = ["endpoint"] maturity = "production" min_stack_version = "8.16.0" min_stack_comments = "Breaking change at 8.16.0 for the Endpoint Integration with respect to ecs field process.group.id" -updated_date = "2024/12/10" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -95,6 +95,41 @@ process where host.os.type == "linux" and event.type == "start" and event.action ) ) and not process.parent.name == "spine" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Privilege Escalation via SUID/SGID + +SUID/SGID are Unix/Linux permissions that allow users to execute files with the file owner's or group's privileges, often root. Adversaries exploit misconfigured SUID/SGID binaries to gain elevated access or persistence. The detection rule identifies processes running with root privileges but initiated by non-root users, flagging potential misuse of SUID/SGID permissions. + +### Possible investigation steps + +- Review the process details, including process.name and process.args, to understand the nature of the executed command and its intended function. +- Check the process.real_user.id and process.real_group.id to identify the non-root user or group that initiated the process, and assess whether this user should have access to execute such commands. +- Investigate the parent process (process.parent.name) to determine the origin of the execution and whether it aligns with expected behavior or indicates potential compromise. +- Examine the system logs and user activity around the time of the alert to identify any suspicious actions or patterns that could suggest privilege escalation attempts. +- Verify the SUID/SGID permissions of the flagged binary to ensure they are correctly configured and assess whether they have been altered or misconfigured. +- Cross-reference the process with known vulnerabilities or exploits associated with the specific binary or command to determine if it is being targeted for privilege escalation. + +### False positive analysis + +- Processes initiated by legitimate system maintenance tasks or scripts may trigger the rule. Review scheduled tasks and scripts to identify benign activities and consider excluding them from the rule. +- Some system utilities or applications may inherently require SUID/SGID permissions for normal operation. Verify the necessity of these permissions and exclude known safe applications from the rule. +- Development or testing environments often run processes with elevated privileges for debugging purposes. Identify these environments and apply exceptions to avoid false positives. +- Administrative tools or scripts executed by system administrators might appear as privilege escalation attempts. Ensure these are documented and excluded if they are part of routine administrative tasks. +- Processes with the parent name "spine" are already excluded, indicating a known benign pattern. Review similar patterns in your environment and apply similar exclusions where applicable. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. +- Terminate any suspicious processes identified by the detection rule that are running with elevated privileges but were initiated by non-root users. +- Conduct a thorough review of the SUID/SGID binaries on the affected system to identify and remove any unnecessary or misconfigured binaries that could be exploited for privilege escalation. +- Reset credentials and review access permissions for any accounts that may have been compromised or used in the attack to ensure they do not retain unauthorized elevated privileges. +- Apply security patches and updates to the operating system and all installed software to mitigate known vulnerabilities that could be exploited for privilege escalation. +- Implement enhanced monitoring and logging for SUID/SGID execution and privilege escalation attempts to detect and respond to similar threats in the future. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/privilege_escalation_potential_wildcard_shell_spawn.toml b/rules/linux/privilege_escalation_potential_wildcard_shell_spawn.toml index 656f678d771..520a966e8bb 100644 --- a/rules/linux/privilege_escalation_potential_wildcard_shell_spawn.toml +++ b/rules/linux/privilege_escalation_potential_wildcard_shell_spawn.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/08" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -72,6 +72,41 @@ sequence by host.id with maxspan=1s process.name : ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") ] by process.parent.entity_id ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Shell via Wildcard Injection Detected + +Wildcard injection exploits vulnerabilities in Linux command-line utilities by manipulating wildcard characters to execute unauthorized commands. Adversaries leverage this to escalate privileges or execute arbitrary code. The detection rule identifies suspicious use of vulnerable binaries like `tar`, `rsync`, and `zip` followed by shell execution, indicating potential exploitation attempts. + +### Possible investigation steps + +- Review the process details to identify the specific command executed, focusing on the process name and arguments, especially those involving `tar`, `rsync`, or `zip` with suspicious flags like `--checkpoint=*`, `-e*`, or `--unzip-command`. +- Examine the parent process information to determine if a shell process (e.g., `bash`, `sh`, `zsh`) was spawned, indicating potential exploitation. +- Check the process execution path to ensure it does not match the exclusion pattern `/tmp/newroot/*`, which might indicate a benign operation. +- Investigate the host's recent activity logs to identify any other suspicious or related events that might indicate a broader attack or compromise. +- Correlate the alert with any other security events or alerts from the same host to assess if this is part of a larger attack pattern or campaign. +- Assess the user account associated with the process execution to determine if it has the necessary privileges and if the activity aligns with expected behavior for that account. + +### False positive analysis + +- Legitimate use of tar, rsync, or zip with wildcard-related flags in automated scripts or backup processes can trigger false positives. Review the context of these processes and consider excluding specific scripts or directories from monitoring if they are verified as safe. +- System administrators or maintenance scripts may use shell commands following tar, rsync, or zip for legitimate purposes. Identify these routine operations and create exceptions for known safe parent processes or specific command patterns. +- Development environments or testing scenarios might involve intentional use of wildcard characters for testing purposes. Exclude these environments from the rule or adjust the rule to ignore specific user accounts or process paths associated with development activities. +- Scheduled tasks or cron jobs that involve the use of these binaries with wildcard flags can be mistaken for malicious activity. Verify the legitimacy of these tasks and exclude them based on their schedule or specific command line arguments. +- Security tools or monitoring solutions that simulate attacks for testing or validation purposes might trigger this rule. Ensure these tools are recognized and excluded from monitoring to prevent unnecessary 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, particularly those involving the execution of shell commands following the use of `tar`, `rsync`, or `zip`. +- Conduct a thorough review of the affected system's logs to identify any additional indicators of compromise or unauthorized access attempts. +- Restore the affected system from a known good backup if any unauthorized changes or malicious activities are confirmed. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Implement file integrity monitoring on critical systems to detect unauthorized changes to system binaries or configuration files. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/privilege_escalation_sda_disk_mount_non_root.toml b/rules/linux/privilege_escalation_sda_disk_mount_non_root.toml index 1ed28663043..db1ee3aa243 100644 --- a/rules/linux/privilege_escalation_sda_disk_mount_non_root.toml +++ b/rules/linux/privilege_escalation_sda_disk_mount_non_root.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/30" integration = ["endpoint"] maturity = "production" -updated_date = "2024/07/30" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -64,6 +64,40 @@ process where host.os.type == "linux" and event.type == "start" and event.action process.name == "debugfs" and process.args : "/dev/sd*" and not process.args == "-R" and not user.Ext.real.id == "0" and not group.Ext.real.id == "0" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious DebugFS Root Device Access + +DebugFS is a Linux utility that provides a low-level interface to access and manipulate file systems, typically used for debugging purposes. It can be exploited by adversaries with "disk" group privileges to access sensitive files without root permissions, potentially leading to privilege escalation. The detection rule identifies non-root users executing DebugFS on disk devices, flagging potential unauthorized access attempts. + +### Possible investigation steps + +- Review the process execution details to identify the non-root user and group involved in the DebugFS execution by examining the user.Ext.real.id and group.Ext.real.id fields. +- Check the command-line arguments (process.args) to determine which specific disk device was accessed and assess if the access was legitimate or necessary for the user's role. +- Investigate the user's recent activity and login history to identify any unusual patterns or unauthorized access attempts that might indicate malicious intent. +- Verify the user's group memberships, particularly focusing on the "disk" group, to understand if the user should have such privileges and if any recent changes were made to their group assignments. +- Examine system logs and other security alerts around the time of the DebugFS execution to identify any correlated suspicious activities or potential indicators of compromise. +- Assess the system for any unauthorized changes or access to sensitive files, such as the shadow file or root SSH keys, which could indicate privilege escalation attempts. + +### False positive analysis + +- Non-root system administrators or maintenance scripts may use DebugFS for legitimate disk diagnostics or recovery tasks. To handle this, identify and whitelist specific users or scripts that are known to perform these tasks regularly. +- Automated backup or monitoring tools might invoke DebugFS as part of their operations. Review and exclude these tools by adding their process identifiers or user accounts to an exception list. +- Developers or testers with disk group privileges might use DebugFS during development or testing phases. Establish a policy to document and approve such activities, and exclude these users from triggering alerts. +- Educational or training environments where DebugFS is used for learning purposes can generate false positives. Create exceptions for these environments by specifying the associated user accounts or groups. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Revoke "disk" group privileges from non-essential users to limit access to disk devices and prevent misuse of DebugFS. +- Conduct a thorough review of user accounts and group memberships to ensure only authorized personnel have "disk" group privileges. +- Check for unauthorized access to sensitive files such as the shadow file or root SSH private keys and reset credentials if necessary. +- Monitor for any additional suspicious activity on the affected system and related systems, focusing on privilege escalation attempts. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are compromised. +- Implement enhanced logging and monitoring for DebugFS usage and access to disk devices to detect similar threats in the future.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/privilege_escalation_shadow_file_read.toml b/rules/linux/privilege_escalation_shadow_file_read.toml index 327e52480d6..57159b1cce3 100644 --- a/rules/linux/privilege_escalation_shadow_file_read.toml +++ b/rules/linux/privilege_escalation_shadow_file_read.toml @@ -2,7 +2,7 @@ creation_date = "2022/09/01" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -65,6 +65,40 @@ host.os.type : "linux" and event.category : "process" and event.action : ("exec" process.parent.name:(gen_passwd_sets or scc_* or wazuh-modulesd) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Shadow File Read via Command Line Utilities + +In Linux environments, the `/etc/shadow` file stores hashed passwords, making it a prime target for attackers seeking credential access. Adversaries with elevated privileges may exploit command-line utilities to read this file, aiming to extract credentials for lateral movement. The detection rule identifies suspicious access attempts by monitoring process activities related to the file, excluding legitimate operations, thus highlighting potential unauthorized access attempts. + +### Possible investigation steps + +- Review the process details to identify the executable and arguments used, focusing on the process.args field to confirm access attempts to /etc/shadow. +- Check the process.parent.name field to determine the parent process and assess if it is associated with known legitimate activities or suspicious behavior. +- Investigate the user context under which the process was executed to verify if the user had legitimate reasons to access the /etc/shadow file. +- Examine the host's recent activity logs for any privilege escalation events that might have preceded the access attempt, indicating potential unauthorized privilege elevation. +- Correlate the event with other alerts or logs from the same host to identify patterns or sequences of actions that suggest lateral movement or further credential access attempts. +- Assess the environment for any recent changes or deployments that might explain the access attempt, such as updates or configuration changes involving user management. + +### False positive analysis + +- System maintenance tasks may trigger alerts when legitimate processes like chown or chmod access the /etc/shadow file. To handle these, consider excluding these specific processes when they are executed by trusted system administrators during scheduled maintenance. +- Containerized environments might generate false positives if processes within containers access the /etc/shadow file. Exclude paths such as /var/lib/docker/* or /run/containerd/* to reduce noise from container operations. +- Security tools like wazuh-modulesd or custom scripts (e.g., gen_passwd_sets) that legitimately interact with the /etc/shadow file for monitoring or compliance checks can be excluded by adding them to the process.parent.name exclusion list. +- Automated scripts or cron jobs that perform routine checks or updates on system files, including /etc/shadow, should be reviewed and, if deemed safe, excluded from triggering alerts by specifying their process names or paths in the exclusion criteria. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified in the alert that are attempting to access the /etc/shadow file. +- Conduct a thorough review of user accounts and privileges on the affected system to identify any unauthorized privilege escalations or account creations. +- Change all passwords for accounts on the affected system, especially those with elevated privileges, to mitigate the risk of credential compromise. +- Review and update access controls and permissions for sensitive files like /etc/shadow to ensure they are restricted to only necessary users and processes. +- Monitor for any further attempts to access the /etc/shadow file across the network, using enhanced logging and alerting mechanisms to detect similar threats. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/privilege_escalation_sudo_cve_2019_14287.toml b/rules/linux/privilege_escalation_sudo_cve_2019_14287.toml index 005178403d9..b413bea81c5 100644 --- a/rules/linux/privilege_escalation_sudo_cve_2019_14287.toml +++ b/rules/linux/privilege_escalation_sudo_cve_2019_14287.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "auditd_manager", "crowdstrike", "sentinel_one_cloud_ maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/08" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -68,6 +68,41 @@ process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "exec_event", "start", "ProcessRollup2", "executed", "process_started") and process.name == "sudo" and process.args == "-u#-1" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Sudo Privilege Escalation via CVE-2019-14287 + +CVE-2019-14287 exploits a flaw in certain sudo versions, allowing users to execute commands as root by bypassing user ID verification. Attackers can misuse this to gain unauthorized root access, posing significant security risks. The detection rule identifies suspicious sudo commands indicative of this exploit, focusing on specific command patterns that translate to root execution, thereby alerting security teams to potential privilege escalation attempts. + +### Possible investigation steps + +- Review the alert details to confirm the presence of the suspicious command pattern "sudo -u#-1" in the process arguments, as this is indicative of the CVE-2019-14287 exploit attempt. +- Identify the user account associated with the process execution to determine if the user should have legitimate access to execute commands with elevated privileges. +- Examine the process execution timeline to identify any preceding or subsequent suspicious activities that might indicate a broader attack or compromise. +- Check the version of sudo installed on the affected system to verify if it is vulnerable to CVE-2019-14287, specifically versions prior to v1.28. +- Investigate the source IP address and hostname of the affected system to assess if it is part of a larger attack pattern or if there are other systems potentially compromised. +- Review system logs and audit trails for any additional unauthorized access attempts or privilege escalation activities around the time of the alert. +- If possible, isolate the affected system to prevent further unauthorized access while conducting a more thorough forensic analysis. + +### False positive analysis + +- Legitimate administrative tasks using sudo with unconventional user ID arguments may trigger the rule. Review the context of the command execution to determine if it aligns with expected administrative activities. +- Automated scripts or maintenance tools that use sudo with arbitrary user IDs for testing or configuration purposes might be flagged. Identify and document these scripts, then create exceptions in the monitoring system to exclude them from alerts. +- Development environments where developers have elevated privileges for testing purposes could generate false positives. Ensure that such environments are well-documented and consider excluding them from this specific rule if they consistently trigger alerts. +- Security tools or monitoring systems that simulate attacks for testing detection capabilities may inadvertently trigger this rule. Coordinate with security teams to whitelist these tools or adjust their configurations to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. +- Terminate any suspicious processes identified with the command pattern "sudo -u#-1" to halt any ongoing unauthorized activities. +- Conduct a thorough review of system logs and sudo logs to identify any additional unauthorized access attempts or successful privilege escalations. +- Reset passwords and review user accounts on the affected system to ensure no unauthorized accounts have been created or existing accounts have been compromised. +- Apply patches or upgrade sudo to a version later than v1.28 to mitigate the vulnerability exploited by CVE-2019-14287. +- Monitor the network for any signs of data exfiltration or further exploitation attempts, using enhanced logging and alerting mechanisms. +- Report the incident to the appropriate internal security team or external authorities if required, providing them with detailed findings and actions taken.""" [[rule.threat]] diff --git a/rules/linux/privilege_escalation_sudo_hijacking.toml b/rules/linux/privilege_escalation_sudo_hijacking.toml index c188f2396b4..6b06eaaadf6 100644 --- a/rules/linux/privilege_escalation_sudo_hijacking.toml +++ b/rules/linux/privilege_escalation_sudo_hijacking.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/26" integration = ["endpoint"] maturity = "production" -updated_date = "2024/09/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -79,6 +79,41 @@ file.path in ("/usr/bin/sudo", "/bin/sudo") and not ( (process.name == "sed" and file.name : "sed*") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Sudo Hijacking + +Sudo is a critical utility in Linux environments, allowing users to execute commands with elevated privileges. Adversaries may exploit this by replacing the sudo binary with a malicious version to capture passwords or maintain persistence. The detection rule identifies suspicious creation or renaming of the sudo binary, excluding legitimate package management processes, to flag potential hijacking attempts. + +### Possible investigation steps + +- Review the file creation or rename event details to confirm the file path is either /usr/bin/sudo or /bin/sudo, as these are critical locations for the sudo binary. +- Check the process executable that triggered the event to ensure it is not part of the legitimate package management processes listed in the query, such as /bin/dpkg or /usr/bin/yum. +- Investigate the user account associated with the event to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Examine the system logs around the time of the event for any unusual activity or errors that might indicate tampering or unauthorized access. +- Verify the integrity of the current sudo binary by comparing its hash with a known good version to detect any unauthorized modifications. +- Assess the system for any additional signs of compromise, such as unexpected network connections or new user accounts, which may indicate broader malicious activity. + +### False positive analysis + +- Package management processes can trigger false positives when legitimate updates or installations occur. To handle this, ensure that processes like dpkg, rpm, yum, and apt are included in the exclusion list as they are common package managers. +- Custom scripts or automation tools that modify the sudo binary for legitimate reasons may cause alerts. Review these scripts and consider adding their paths to the exclusion list if they are verified as safe. +- Temporary files or directories used during legitimate software installations or updates, such as those in /var/lib/dpkg or /tmp, can lead to false positives. Exclude these paths if they are part of a known and safe process. +- Development or testing environments where sudo binaries are frequently modified for testing purposes might trigger alerts. In such cases, consider excluding these environments from monitoring or adding specific exclusions for known safe modifications. +- Ensure that any process or executable that is known to interact with the sudo binary in a non-malicious way is 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 lateral movement by the attacker. +- Verify the integrity of the sudo binary by comparing its hash with a known good version from a trusted source. If compromised, replace it with the legitimate binary. +- Conduct a thorough review of system logs and the process execution history to identify any unauthorized changes or suspicious activities related to the sudo binary. +- Reset passwords for all user accounts on the affected system, especially those with elevated privileges, to mitigate potential credential theft. +- Implement additional monitoring on the affected system and similar environments to detect any further attempts to modify critical binaries or escalate privileges. +- Escalate the incident to the security operations team for a comprehensive investigation and to determine if other systems may be affected. +- Review and update access controls and permissions to ensure that only authorized personnel can modify critical system binaries.""" [[rule.threat]] diff --git a/rules/linux/privilege_escalation_sudo_token_via_process_injection.toml b/rules/linux/privilege_escalation_sudo_token_via_process_injection.toml index ce6f74cdf9b..2c6a878801c 100644 --- a/rules/linux/privilege_escalation_sudo_token_via_process_injection.toml +++ b/rules/linux/privilege_escalation_sudo_token_via_process_injection.toml @@ -4,7 +4,7 @@ integration = ["endpoint"] maturity = "production" min_stack_version = "8.16.0" min_stack_comments = "Breaking change at 8.16.0 for the Endpoint Integration with respect to ecs field process.group.id" -updated_date = "2024/12/10" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -65,6 +65,41 @@ sequence by host.id, process.session_leader.entity_id with maxspan=15s [ process where host.os.type == "linux" and event.action == "uid_change" and event.type == "change" and process.name == "sudo" and process.user.id == "0" and process.group.id == "0" ] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Sudo Token Manipulation via Process Injection + +In Linux environments, process injection can be exploited by adversaries to manipulate sudo tokens, allowing unauthorized privilege escalation. Attackers may use debugging tools like gdb to inject code into processes with valid sudo tokens, leveraging ptrace capabilities. The detection rule identifies this threat by monitoring for gdb execution followed by a uid change in the sudo process, indicating potential token manipulation. + +### Possible investigation steps + +- Review the alert details to identify the specific host and process session leader entity ID involved in the potential sudo token manipulation. +- Examine the process tree on the affected host to trace the parent and child processes of the gdb execution, focusing on any unusual or unauthorized processes. +- Check the system logs for any recent sudo commands executed by the user associated with the gdb process to determine if there were any unauthorized privilege escalations. +- Investigate the user account associated with the gdb process to verify if it has legitimate reasons to use debugging tools and if it has been compromised. +- Analyze the timing and context of the uid change event in the sudo process to assess if it aligns with legitimate administrative activities or if it appears suspicious. +- Review the system's ptrace settings to ensure they are configured securely and assess if there have been any recent changes that could have enabled this attack vector. + +### False positive analysis + +- Debugging activities by developers or system administrators using gdb for legitimate purposes can trigger this rule. To manage this, create exceptions for specific user IDs or groups known to perform regular debugging tasks. +- Automated scripts or maintenance tools that utilize gdb for process analysis might cause false positives. Identify these scripts and exclude their associated process names or paths from the rule. +- System monitoring or security tools that perform uid changes as part of their normal operation could be mistaken for malicious activity. Review and whitelist these tools by their process names or specific user IDs. +- Training or testing environments where sudo and gdb are used frequently for educational purposes may generate alerts. Consider excluding these environments by host ID or network segment to reduce noise. +- Scheduled tasks or cron jobs that involve gdb and sudo processes might inadvertently match the rule criteria. Analyze these tasks and exclude them based on their execution times or specific process attributes. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or privilege escalation. +- Terminate any suspicious gdb and sudo processes identified in the alert to stop ongoing process injection attempts. +- Conduct a thorough review of the affected system's process and user activity logs to identify any unauthorized changes or access patterns. +- Reset credentials and sudo tokens for all users on the affected system to prevent further exploitation using compromised tokens. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Re-enable ptrace restrictions if they were previously disabled, to limit the ability of attackers to perform process injection. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] diff --git a/rules/linux/privilege_escalation_suspicious_cap_setuid_python_execution.toml b/rules/linux/privilege_escalation_suspicious_cap_setuid_python_execution.toml index 099c3d7462e..47da076e06d 100644 --- a/rules/linux/privilege_escalation_suspicious_cap_setuid_python_execution.toml +++ b/rules/linux/privilege_escalation_suspicious_cap_setuid_python_execution.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/05" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -63,6 +63,41 @@ sequence by host.id, process.entity_id with maxspan=1s [process where host.os.type == "linux" and event.action in ("uid_change", "gid_change") and event.type == "change" and (user.id == "0" or group.id == "0")] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Privilege Escalation via Python cap_setuid + +In Unix-like systems, setuid and setgid allow processes to execute with elevated privileges, often exploited by adversaries to gain unauthorized root access. Attackers may use Python scripts to invoke system commands with these capabilities, followed by changing user or group IDs to root. The detection rule identifies this sequence by monitoring Python processes executing system commands with setuid/setgid, followed by a root user or group ID change, signaling potential privilege escalation attempts. + +### Possible investigation steps + +- Review the process details, including process.entity_id and process.args, to confirm the execution of a Python script with setuid or setgid capabilities. +- Check the user.id and group.id fields to verify if there was an unauthorized change to root (user.id == "0" or group.id == "0"). +- Investigate the host.id to determine if other suspicious activities or alerts have been associated with the same host. +- Examine the timeline of events to see if the uid_change or gid_change occurred immediately after the Python process execution, indicating a potential privilege escalation attempt. +- Look into the source of the Python script or command executed to identify if it was a known or unknown script, and assess its legitimacy. +- Analyze any related network activity or connections from the host around the time of the alert to identify potential lateral movement or data exfiltration attempts. + +### False positive analysis + +- Development and testing environments may trigger this rule when developers use Python scripts to test setuid or setgid functionalities. To manage this, exclude specific user accounts or host IDs associated with development activities. +- Automated scripts or maintenance tasks that require temporary privilege escalation might be flagged. Identify and whitelist these scripts by their process names or paths to prevent false positives. +- System administrators using Python scripts for legitimate administrative tasks could inadvertently trigger the rule. Consider excluding known administrator accounts or specific scripts used for routine maintenance. +- Security tools or monitoring solutions that simulate attacks for testing purposes may cause alerts. Exclude these tools by their process signatures or host IDs to avoid unnecessary alerts. +- Custom applications that use Python for legitimate privilege management should be reviewed and, if safe, added to an exception list based on their unique process identifiers or execution paths. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious Python processes identified by the detection rule to halt potential privilege escalation activities. +- Review and revoke any unauthorized setuid or setgid permissions on binaries or scripts to prevent exploitation. +- Conduct a thorough investigation of the affected system to identify any additional signs of compromise or persistence mechanisms. +- Reset credentials and review access permissions for any accounts that may have been affected or used in the attack. +- Apply security patches and updates to the operating system and installed software to mitigate known vulnerabilities. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/linux/privilege_escalation_suspicious_chown_fowner_elevation.toml b/rules/linux/privilege_escalation_suspicious_chown_fowner_elevation.toml index 438d47ec204..0a59d73c983 100644 --- a/rules/linux/privilege_escalation_suspicious_chown_fowner_elevation.toml +++ b/rules/linux/privilege_escalation_suspicious_chown_fowner_elevation.toml @@ -2,7 +2,7 @@ creation_date = "2024/01/08" integration = ["endpoint", "auditd_manager"] maturity = "production" -updated_date = "2024/11/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -70,6 +70,40 @@ sequence by host.id, process.pid with maxspan=1s ) and user.id != "0" ] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Privilege Escalation via CAP_CHOWN/CAP_FOWNER Capabilities + +In Linux, CAP_CHOWN and CAP_FOWNER are capabilities that allow processes to change file ownership and bypass file permission checks, respectively. Adversaries exploit these to gain unauthorized access to sensitive files, such as password or configuration files. The detection rule identifies suspicious processes with these capabilities that alter ownership of critical files, signaling potential privilege escalation attempts. + +### Possible investigation steps + +- Review the process details, including process.name and process.command_line, to understand the context of the executed process and its intended function. +- Check the user.id associated with the process to determine if the process was executed by a non-root user, which could indicate unauthorized privilege escalation attempts. +- Investigate the file.path that had its ownership changed to assess the potential impact, focusing on critical files like /etc/passwd, /etc/shadow, /etc/sudoers, and /root/.ssh/*. +- Analyze the sequence of events by examining the host.id and process.pid to identify any related processes or activities that occurred within the maxspan=1s timeframe. +- Correlate the event with other logs or alerts from the same host to identify any patterns or additional suspicious activities that might indicate a broader attack or compromise. + +### False positive analysis + +- System administration scripts or automated processes may legitimately use CAP_CHOWN or CAP_FOWNER capabilities to manage file permissions or ownership. Review and whitelist these processes if they are verified as non-malicious. +- Backup or restoration operations often require changing file ownership and permissions. Identify and exclude these operations from triggering alerts by specifying known backup tools or scripts. +- Software installation or update processes might alter file ownership as part of their normal operation. Monitor and exclude these processes if they are part of a trusted software management system. +- Development or testing environments may have scripts that modify file ownership for testing purposes. Ensure these environments are properly segmented and exclude known development scripts from detection. +- Custom user scripts that require elevated permissions for legitimate tasks should be reviewed and, if deemed safe, added to an exception list to prevent false positives. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified with CAP_CHOWN or CAP_FOWNER capabilities that are altering file ownership, especially those targeting critical files like /etc/passwd or /etc/shadow. +- Revert any unauthorized changes to file ownership or permissions on critical files to their original state to restore system integrity. +- Conduct a thorough review of user accounts and privileges on the affected system to identify and disable any unauthorized accounts or privilege escalations. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Implement additional monitoring on the affected host and similar systems to detect any further attempts to exploit CAP_CHOWN or CAP_FOWNER capabilities. +- Review and update security policies and configurations to restrict the assignment of CAP_CHOWN and CAP_FOWNER capabilities to only trusted and necessary processes.""" [[rule.threat]] diff --git a/rules/linux/privilege_escalation_suspicious_passwd_file_write.toml b/rules/linux/privilege_escalation_suspicious_passwd_file_write.toml index 0b8d920fccf..582adc7bff4 100644 --- a/rules/linux/privilege_escalation_suspicious_passwd_file_write.toml +++ b/rules/linux/privilege_escalation_suspicious_passwd_file_write.toml @@ -2,7 +2,7 @@ creation_date = "2024/01/22" integration = ["endpoint", "auditd_manager"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -85,6 +85,40 @@ sequence by host.id, process.parent.pid with maxspan=1m [file where host.os.type == "linux" and file.path == "/etc/passwd" and process.parent.pid != 1 and not auditd.data.a2 == "80000" and event.outcome == "success" and user.id != "0"] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Passwd File Event Action + +In Linux environments, the `/etc/passwd` file is crucial for managing user accounts. Adversaries may exploit vulnerabilities or misconfigurations to add unauthorized entries, potentially gaining root access. The detection rule monitors for the use of `openssl` to generate password entries and subsequent unauthorized modifications to the `/etc/passwd` file, flagging potential privilege escalation attempts. + +### Possible investigation steps + +- Review the process execution details to confirm the use of 'openssl' with the 'passwd' argument by a non-root user (user.id != "0"). This can help identify the user attempting to generate a password entry. +- Examine the process tree to understand the parent process of the 'openssl' command and determine if it was initiated by a legitimate or suspicious process. +- Check the file modification event on '/etc/passwd' to verify if the file was altered by a non-root user (user.id != "0") and ensure the process.parent.pid is not 1, indicating it wasn't initiated by the init process. +- Investigate the context of the file write event by reviewing recent logs and system changes to identify any unauthorized modifications or anomalies in user account management. +- Correlate the event with other security alerts or logs to determine if there are additional indicators of compromise or related suspicious activities on the host. + +### False positive analysis + +- System administrators or automated scripts may use openssl to manage user passwords without malicious intent. To handle this, identify and whitelist known administrative scripts or processes that perform legitimate password management tasks. +- Some legitimate software installations or updates might temporarily modify the /etc/passwd file. Monitor and document these activities to distinguish them from unauthorized changes, and consider creating exceptions for known software processes. +- Developers or testers might use openssl for password generation in non-production environments. Establish a policy to differentiate between production and non-production systems, and apply the rule more strictly in production environments. +- Scheduled maintenance tasks might involve legitimate modifications to the /etc/passwd file. Coordinate with IT teams to schedule these tasks and temporarily adjust monitoring rules during these periods to prevent false positives. +- In environments with multiple administrators, ensure that all legitimate administrative actions are logged and reviewed. Implement a process for administrators to report their activities, allowing for the creation of exceptions for known, non-threatening actions. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or privilege escalation attempts. +- Terminate any suspicious processes related to `openssl` or unauthorized modifications to the `/etc/passwd` file to halt ongoing malicious activities. +- Conduct a thorough review of the `/etc/passwd` file to identify and remove any unauthorized entries, especially those with root privileges. +- Reset passwords for all user accounts on the affected system to ensure no compromised credentials are used for further attacks. +- Restore the `/etc/passwd` file from a known good backup if unauthorized changes are detected and cannot be manually rectified. +- Escalate the incident to the security operations team for a comprehensive investigation into potential system vulnerabilities or misconfigurations that allowed the attack. +- Implement enhanced monitoring and alerting for similar activities, focusing on unauthorized use of `openssl` and modifications to critical system files like `/etc/passwd`.""" [[rule.threat]] diff --git a/rules/linux/privilege_escalation_suspicious_uid_guid_elevation.toml b/rules/linux/privilege_escalation_suspicious_uid_guid_elevation.toml index 81d2c3ef6c1..cb8416751ae 100644 --- a/rules/linux/privilege_escalation_suspicious_uid_guid_elevation.toml +++ b/rules/linux/privilege_escalation_suspicious_uid_guid_elevation.toml @@ -2,7 +2,7 @@ creation_date = "2024/01/08" integration = ["endpoint"] maturity = "production" -updated_date = "2024/11/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -79,6 +79,41 @@ sequence by host.id, process.entity_id with maxspan=1s (process.thread.capabilities.effective : "CAP_SET?ID" or process.thread.capabilities.permitted : "CAP_SET?ID") and user.id == "0"] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Privilege Escalation via CAP_SETUID/SETGID Capabilities + +In Linux, CAP_SETUID and CAP_SETGID capabilities allow processes to change user and group IDs, crucial for identity management. Adversaries exploit misconfigurations to gain root access. The detection rule identifies processes with these capabilities that elevate privileges to root, excluding benign scenarios, to flag potential misuse. + +### Possible investigation steps + +- Review the process details such as process.name and process.executable to identify the specific application or script that triggered the alert. This can help determine if the process is expected or potentially malicious. +- Examine the process.parent.executable and process.parent.name fields to understand the parent process that initiated the suspicious process. This can provide context on whether the parent process is legitimate or part of a known attack vector. +- Check the user.id field to confirm the user context under which the process was executed. If the user is not expected to have elevated privileges, this could indicate a potential compromise. +- Investigate the process.command_line to analyze the command executed. Look for any unusual or unexpected command patterns that could suggest malicious intent. +- Correlate the alert with other security events or logs from the same host.id to identify any related suspicious activities or patterns that could indicate a broader attack. +- Assess the environment for any recent changes or misconfigurations that could have inadvertently granted CAP_SETUID or CAP_SETGID capabilities to unauthorized processes. + +### False positive analysis + +- Processes related to system management tools like VMware, SolarWinds, and language tools may trigger false positives. Exclude these by adding their executables to the exception list. +- Scheduled tasks or system updates that involve processes like update-notifier or dbus-daemon can cause false alerts. Consider excluding these parent process names from the detection rule. +- Automation tools such as Ansible or scripts executed by Python may inadvertently match the rule. Exclude command lines that match known automation patterns. +- Legitimate use of sudo or pkexec for administrative tasks can be misinterpreted as privilege escalation. Exclude these executables if they are part of regular administrative operations. +- Monitoring tools like osqueryd or saposcol might trigger the rule during normal operations. Add these process names to the exception list to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified with CAP_SETUID or CAP_SETGID capabilities that have escalated privileges to root, ensuring no further exploitation occurs. +- Conduct a thorough review of the affected system's user and group configurations to identify and correct any misconfigurations that allowed the privilege escalation. +- Revoke unnecessary CAP_SETUID and CAP_SETGID capabilities from processes and users that do not require them, reducing the attack surface for future exploitation. +- Restore the affected system from a known good backup if unauthorized changes or persistent threats are detected, ensuring the system is returned to a secure state. +- Monitor the system and network for any signs of continued or attempted exploitation, using enhanced logging and alerting to detect similar threats in the future. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] diff --git a/rules/linux/privilege_escalation_uid_change_post_compilation.toml b/rules/linux/privilege_escalation_uid_change_post_compilation.toml index 64e954706a1..347a870770c 100644 --- a/rules/linux/privilege_escalation_uid_change_post_compilation.toml +++ b/rules/linux/privilege_escalation_uid_change_post_compilation.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/28" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -65,6 +65,42 @@ sequence by host.id with maxspan=1m [process where host.os.type == "linux" and event.action in ("uid_change", "guid_change") and event.type == "change" and user.id == "0"] by process.name ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Privilege Escalation via Recently Compiled Executable + +In Linux environments, compiling and executing programs is a routine operation. However, adversaries can exploit this by compiling malicious code to escalate privileges. This detection rule identifies suspicious sequences where a non-root user compiles and executes a program, followed by a UID change to root, indicating potential privilege escalation attempts. By monitoring these patterns, the rule helps in identifying and mitigating exploitation risks. + +### Possible investigation steps + +- Review the alert details to identify the specific non-root user involved in the compilation and execution sequence. Check the user.id field to gather more information about the user's activities and permissions. +- Examine the process.args field from the initial compilation event to understand the source code or script being compiled. This can provide insights into whether the code has malicious intent. +- Investigate the file.name field associated with the creation event to determine the nature of the executable file created. Check its location and any associated metadata for anomalies. +- Analyze the process.name field from the execution event to identify the program that was run. Cross-reference this with known malicious binaries or scripts. +- Check the process.name field in the UID change event to identify the process responsible for the privilege escalation. Determine if this process is known to exploit vulnerabilities for privilege escalation. +- Review system logs and other security tools for any additional suspicious activities or anomalies around the time of the alert to gather more context on the potential threat. +- Assess the system for any signs of compromise or unauthorized changes, such as new user accounts, altered configurations, or unexpected network connections, to evaluate the impact and scope of the incident. + +### False positive analysis + +- Development activities by legitimate users can trigger this rule when compiling and testing new software. To manage this, consider creating exceptions for specific users or groups known to perform regular development tasks. +- Automated build systems or continuous integration pipelines may compile and execute code as part of their normal operation. Exclude these systems by identifying their user accounts or host identifiers. +- System administrators performing maintenance or updates might compile and execute programs, leading to false positives. Implement exceptions for these users or specific maintenance windows. +- Educational environments where students frequently compile and execute code for learning purposes can generate alerts. Exclude these activities by setting up exceptions for student user accounts or specific lab environments. +- Security testing and research activities that involve compiling and executing exploit code in a controlled manner can be mistaken for malicious behavior. Exclude these activities by identifying the user accounts or systems involved in such testing. + +### 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, especially those associated with the compiled executable and any processes running with elevated privileges. +- Revert any unauthorized changes to user permissions, particularly any UID changes to root, to restore the system to its secure state. +- Conduct a thorough review of the affected system for additional indicators of compromise, such as unauthorized file modifications or new user accounts, and remove any malicious artifacts. +- Apply relevant security patches and updates to the system to address any vulnerabilities that may have been exploited for privilege escalation. +- Monitor the affected system and network for any signs of recurring or related suspicious activity, using enhanced logging and alerting mechanisms. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected, ensuring comprehensive remediation across the environment.""" [[rule.threat]] diff --git a/rules/linux/privilege_escalation_uid_elevation_from_unknown_executable.toml b/rules/linux/privilege_escalation_uid_elevation_from_unknown_executable.toml index 6d8b2ad4a2c..f606057e0ba 100644 --- a/rules/linux/privilege_escalation_uid_elevation_from_unknown_executable.toml +++ b/rules/linux/privilege_escalation_uid_elevation_from_unknown_executable.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/26" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -74,6 +74,42 @@ and process.parent.name:("bash" or "dash" or "sh" or "tcsh" or "csh" or "zsh" or process.args:/usr/bin/python* ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 UID Elevation from Previously Unknown Executable + +In Linux environments, UID elevation is a process where a user's permissions are increased, often to root level, allowing full system control. Adversaries exploit this by using unknown executables to hijack execution flow, often via rootkits, to gain unauthorized root access. The detection rule identifies such activities by monitoring for UID changes initiated by non-standard executables, excluding known safe paths and processes, thus highlighting potential privilege escalation attempts. + +### Possible investigation steps + +- Review the process details to identify the unknown executable that triggered the alert, focusing on the process.executable field to determine its path and origin. +- Examine the parent process information using process.parent.name to understand the context in which the unknown executable was launched, checking for any unusual or unexpected shell activity. +- Investigate the user account associated with the UID change by analyzing the user.id field to determine if the account has a history of privilege escalation attempts or if it has been compromised. +- Check the system logs for any recent changes or installations that might have introduced the unknown executable, focusing on the time frame around the event.action:"uid_change". +- Assess the network activity around the time of the alert to identify any potential external connections or data exfiltration attempts that might correlate with the privilege escalation. +- Cross-reference the executable path and name against known threat intelligence databases to determine if it is associated with any known malicious activity or rootkits. +- If possible, perform a forensic analysis of the executable to understand its behavior and potential impact on the system, looking for signs of function or syscall hooking as indicated in the rule description. + +### False positive analysis + +- Executables in custom directories may trigger false positives if they are legitimate but not included in the known safe paths. Users can mitigate this by adding these directories to the exclusion list in the detection rule. +- Scripts or binaries executed by system administrators from non-standard locations for maintenance or deployment purposes might be flagged. To handle this, users should document and exclude these specific processes or paths if they are verified as safe. +- Development or testing environments where new executables are frequently introduced can cause alerts. Users should consider creating exceptions for these environments or paths to reduce noise while ensuring they are monitored separately for any unusual activity. +- Automated scripts or tools that perform legitimate UID changes but are not part of the standard system paths can be excluded by adding their specific executable paths or names to the rule's exception list. +- Temporary or ephemeral processes that are part of containerized applications might be flagged. Users should review and exclude these processes if they are confirmed to be part of normal operations. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule that are not part of the known safe paths or processes. +- Conduct a thorough review of the affected system's logs to identify any additional indicators of compromise or related suspicious activities. +- Remove any unauthorized or unknown executables found on the system, especially those involved in the UID elevation attempt. +- Restore the system from a known good backup if any rootkits or persistent threats are detected that cannot be easily removed. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/linux/privilege_escalation_unshare_namespace_manipulation.toml b/rules/linux/privilege_escalation_unshare_namespace_manipulation.toml index bb29544825f..885b6f42f07 100644 --- a/rules/linux/privilege_escalation_unshare_namespace_manipulation.toml +++ b/rules/linux/privilege_escalation_unshare_namespace_manipulation.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." -updated_date = "2025/01/08" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -80,6 +80,39 @@ process.executable: "/usr/bin/unshare" and not process.parent.executable: ("/usr/bin/udevadm", "*/lib/systemd/systemd-udevd", "/usr/bin/unshare") and not process.args == "/usr/bin/snap" and not process.parent.name in ("zz-proxmox-boot", "java") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Namespace Manipulation Using Unshare + +The `unshare` command in Linux is used to create new namespaces, isolating processes from the rest of the system. This isolation is crucial for containerization and security. However, attackers can exploit `unshare` to break out of containers or elevate privileges by creating namespaces that bypass security controls. The detection rule identifies suspicious `unshare` executions by monitoring process starts, filtering out benign parent processes, and focusing on unusual usage patterns, thus highlighting potential misuse. + +### Possible investigation steps + +- Review the process tree to understand the context of the unshare execution, focusing on the parent process and any child processes spawned by unshare. +- Investigate the user account associated with the unshare execution to determine if it is a legitimate user or potentially compromised. +- Examine the command-line arguments used with unshare to identify any unusual or suspicious options that may indicate an attempt to bypass security controls. +- Check for any recent changes or anomalies in the system logs around the time of the unshare execution to identify potential indicators of compromise or privilege escalation attempts. +- Correlate the unshare event with other security alerts or logs to determine if it is part of a larger attack pattern or campaign. + +### False positive analysis + +- System management tools like udevadm and systemd-udevd may invoke unshare as part of their normal operations. These should be excluded by ensuring the rule filters out processes with these as parent executables. +- Snap package management can trigger unshare during its operations. Exclude processes where the arguments include /usr/bin/snap to prevent unnecessary alerts. +- Java applications might occasionally use unshare for legitimate purposes. Exclude processes with java as the parent name to reduce false positives. +- Custom scripts or administrative tasks that use unshare for legitimate namespace management should be reviewed and, if deemed safe, added to the exclusion list to prevent repeated alerts. + +### Response and remediation + +- Immediately isolate the affected system to prevent further unauthorized access or lateral movement within the network. +- Terminate any suspicious processes associated with the `unshare` command that do not have legitimate parent processes or arguments, as identified in the detection query. +- Conduct a thorough review of system logs and process trees to identify any additional unauthorized or suspicious activities that may have occurred in conjunction with the `unshare` execution. +- Revoke any unauthorized access or privileges that may have been granted as a result of the namespace manipulation, ensuring that all user and process permissions are appropriately restricted. +- Restore the affected system from a known good backup if any unauthorized changes or damage to the system integrity are detected. +- Implement additional monitoring and alerting for unusual `unshare` usage patterns to enhance detection capabilities and prevent future occurrences. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been compromised.""" [[rule.threat]] diff --git a/rules/linux/privilege_escalation_writable_docker_socket.toml b/rules/linux/privilege_escalation_writable_docker_socket.toml index be6a9360a51..d91ea4df4dd 100644 --- a/rules/linux/privilege_escalation_writable_docker_socket.toml +++ b/rules/linux/privilege_escalation_writable_docker_socket.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/25" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -67,6 +67,40 @@ process where host.os.type == "linux" and event.type == "start" and event.action (process.name == "socat" and process.args : ("UNIX-CONNECT:*/docker.sock", "UNIX-CONNECT:*/dockershim.sock")) ) and not user.Ext.real.id : "0" and not group.Ext.real.id : "0" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Privilege Escalation through Writable Docker Socket + +Docker sockets facilitate communication between the Docker client and daemon, typically restricted to root or specific groups. Adversaries with write access can exploit these sockets to execute containers with elevated privileges, potentially accessing the host system. The detection rule identifies suspicious activities by monitoring processes like Docker and Socat for unauthorized socket interactions, focusing on non-root users attempting to execute commands, thus flagging potential privilege escalation attempts. + +### Possible investigation steps + +- Review the alert details to identify the specific process name (either "docker" or "socat") and the associated arguments that triggered the alert, focusing on the use of "unix://*/docker.sock" or "unix://*/dockershim.sock". +- Check the user and group IDs associated with the process to confirm they are non-root, as indicated by the exclusion of user.Ext.real.id and group.Ext.real.id being "0". +- Investigate the user account involved in the alert to determine if they should have access to Docker sockets and whether their permissions have been misconfigured or compromised. +- Examine the system logs and Docker daemon logs for any additional context or anomalies around the time of the alert to identify any unauthorized or suspicious activities. +- Assess the current state of the system for any unauthorized containers that may have been started, and inspect their configurations and running processes for signs of privilege escalation attempts. +- Verify the integrity and permissions of the Docker socket files to ensure they have not been altered to allow unauthorized access. + +### False positive analysis + +- Legitimate administrative tasks by non-root users with elevated permissions can trigger the rule. To manage this, identify trusted users or groups who regularly perform such tasks and create exceptions for their activities. +- Automated scripts or services that require Docker socket access for legitimate operations may be flagged. Review these scripts or services and whitelist their specific process names or arguments to prevent false positives. +- Development environments where developers frequently use Docker for testing might cause alerts. Consider creating a separate monitoring policy for development environments or exclude known development user accounts from this rule. +- Continuous integration/continuous deployment (CI/CD) pipelines that interact with Docker sockets can be mistakenly identified as threats. Ensure that these pipelines are running under specific service accounts and exclude these accounts from the rule. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or lateral movement. +- Terminate any unauthorized Docker containers that were started by non-root users, especially those interacting with Docker sockets. +- Review and revoke any unnecessary write permissions to Docker sockets for non-root users and groups, ensuring only trusted users have access. +- Conduct a thorough audit of user accounts and group memberships on the affected system to identify and remove any unauthorized or suspicious accounts. +- Restore the system from a known good backup if unauthorized changes or access to sensitive data are detected. +- Implement monitoring and alerting for any future unauthorized access attempts to Docker sockets, focusing on non-root user activities. +- Escalate the incident to the security operations team for further investigation and to assess potential impacts on other systems within the network.""" [[rule.threat]] diff --git a/rules/macos/credential_access_credentials_keychains.toml b/rules/macos/credential_access_credentials_keychains.toml index 10a16206576..c4cceff5fdb 100644 --- a/rules/macos/credential_access_credentials_keychains.toml +++ b/rules/macos/credential_access_credentials_keychains.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/14" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -94,6 +94,39 @@ process where host.os.type == "macos" and event.type in ("start", "process_start "/usr/local/jamf/bin/jamf", "/Applications/Microsoft Defender.app/Contents/MacOS/wdavdaemon") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Access to Keychain Credentials Directories + +macOS keychains securely store user credentials, such as passwords and certificates, essential for system and application authentication. Adversaries may target these directories to extract sensitive information, potentially compromising user accounts and system integrity. The detection rule identifies suspicious access attempts by monitoring process activities related to keychain directories, excluding known legitimate processes and actions, thus highlighting potential unauthorized access attempts. + +### Possible investigation steps + +- Review the process details that triggered the alert, focusing on the process.args field to identify the specific keychain directory accessed and the nature of the access attempt. +- Examine the process.parent.executable and process.executable fields to determine the origin of the process and assess whether it is a known or potentially malicious application. +- Investigate the process.Ext.effective_parent.executable field to trace the parent process chain and identify any unusual or unauthorized parent processes that may have initiated the access. +- Check for any recent changes or installations on the system that could explain the access attempt, such as new software or updates that might interact with keychain directories. +- Correlate the alert with other security events or logs from the same host to identify any patterns or additional suspicious activities that could indicate a broader compromise. + +### False positive analysis + +- Processes related to legitimate security applications like Microsoft Defender, JumpCloud Agent, and Rapid7 IR Agent may trigger false positives. Users can mitigate this by ensuring these applications are included in the exclusion list for process executables and effective parent executables. +- Routine administrative tasks involving keychain management, such as setting keychain settings or importing certificates, might be flagged. To handle this, users should add these specific actions to the exclusion list for process arguments. +- Applications like OpenVPN Connect and JAMF management tools that interact with keychain directories for legitimate purposes can cause false alerts. Users should verify these applications are part of the exclusion list for parent executables to prevent unnecessary alerts. +- Regular system maintenance or updates that involve keychain access might be misinterpreted as suspicious. Users should monitor these activities and adjust the exclusion criteria as needed to accommodate known maintenance processes. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule that are attempting to access keychain directories without legitimate reasons. +- Conduct a thorough review of the system's keychain access logs to identify any unauthorized access or modifications to keychain files. +- Change all passwords and credentials stored in the keychain on the affected system to prevent potential misuse of compromised credentials. +- Restore the system from a known good backup if unauthorized access has led to system integrity issues or data corruption. +- Implement additional monitoring on the affected system to detect any further unauthorized access attempts, focusing on the keychain directories and related processes. +- Escalate the incident to the security operations team for further investigation and to determine if the threat is part of a larger attack campaign.""" [[rule.threat]] diff --git a/rules/macos/credential_access_dumping_hashes_bi_cmds.toml b/rules/macos/credential_access_dumping_hashes_bi_cmds.toml index 4eea3dcd5ff..1cd6d1b1e40 100644 --- a/rules/macos/credential_access_dumping_hashes_bi_cmds.toml +++ b/rules/macos/credential_access_dumping_hashes_bi_cmds.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/25" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -62,6 +62,39 @@ query = ''' event.category:process and host.os.type:macos and event.type:start and process.name:(defaults or mkpassdb) and process.args:(ShadowHashData or "-dump") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Dumping Account Hashes via Built-In Commands + +In macOS environments, built-in commands like `defaults` and `mkpassdb` can be exploited by adversaries to extract user account hashes, which are crucial for credential access. These hashes, once obtained, can be cracked to reveal passwords or used for lateral movement within a network. The detection rule identifies suspicious process executions involving these commands and specific arguments, signaling potential credential dumping activities. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of the `defaults` or `mkpassdb` commands with arguments like `ShadowHashData` or `-dump`, as these are indicative of credential dumping attempts. +- Identify the user account associated with the process execution to determine if the activity aligns with expected behavior for that user or if it appears suspicious. +- Check the historical activity of the involved user account and the host to identify any patterns or anomalies that could suggest unauthorized access or lateral movement. +- Investigate any network connections or subsequent processes initiated by the suspicious process to assess potential data exfiltration or further malicious actions. +- Correlate the event with other security alerts or logs from the same host or user account to build a comprehensive timeline of the activity and assess the scope of the potential compromise. + +### False positive analysis + +- System administrators or security tools may legitimately use the `defaults` or `mkpassdb` commands for system maintenance or auditing purposes. To manage these, create exceptions for known administrative accounts or tools that regularly execute these commands. +- Automated scripts or management software might invoke these commands as part of routine operations. Identify and whitelist these scripts or software to prevent unnecessary alerts. +- Developers or IT personnel might use these commands during testing or development phases. Establish a process to temporarily exclude these activities by setting up time-bound exceptions for specific user accounts or devices. +- Security assessments or penetration tests could trigger this rule. Coordinate with security teams to schedule and document these activities, allowing for temporary rule adjustments during the testing period. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent further lateral movement or data exfiltration. +- Terminate any suspicious processes identified as using the `defaults` or `mkpassdb` commands with the specified arguments to halt ongoing credential dumping activities. +- Conduct a thorough review of user accounts on the affected system to identify any unauthorized access or changes, focusing on accounts with elevated privileges. +- Reset passwords for all potentially compromised accounts, especially those with administrative access, and enforce strong password policies. +- Analyze system logs and network traffic to identify any additional systems that may have been accessed using the compromised credentials, and apply similar containment measures. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the full scope of the breach. +- Implement enhanced monitoring and alerting for similar suspicious activities across the network to detect and respond to future attempts promptly.""" [[rule.threat]] diff --git a/rules/macos/credential_access_dumping_keychain_security.toml b/rules/macos/credential_access_dumping_keychain_security.toml index e9e879c94a9..cae91ee2ae2 100644 --- a/rules/macos/credential_access_dumping_keychain_security.toml +++ b/rules/macos/credential_access_dumping_keychain_security.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/04" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -58,6 +58,40 @@ type = "eql" query = ''' process where host.os.type == "macos" and event.type in ("start", "process_started") and process.args : "dump-keychain" and process.args : "-d" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Dumping of Keychain Content via Security Command + +Keychains in macOS securely store user credentials, including passwords and certificates. Adversaries exploit this by using commands to extract keychain data, aiming to access sensitive information. The detection rule identifies suspicious activity by monitoring processes that initiate keychain dumps, specifically looking for command-line arguments associated with this malicious behavior, thus alerting analysts to potential credential theft attempts. + +### Possible investigation steps + +- Review the process details to identify the parent process and determine if the keychain dump was initiated by a legitimate application or user. +- Examine the user account associated with the process to verify if the activity aligns with their typical behavior or if the account may be compromised. +- Check the timestamp of the event to correlate with any other suspicious activities or anomalies on the system around the same time. +- Investigate the command-line arguments used in the process to confirm if they match known patterns of malicious keychain dumping attempts. +- Analyze any network connections or data transfers initiated by the process to identify potential exfiltration of the dumped keychain data. +- Look for additional alerts or logs from the same host or user to assess if this is part of a broader attack campaign. + +### False positive analysis + +- Legitimate administrative tasks or system maintenance activities may trigger the rule if they involve keychain access. Users should review the context of the process initiation to determine if it aligns with routine administrative operations. +- Security or IT tools that perform regular audits or backups of keychain data might be flagged. Users can create exceptions for these tools by identifying their specific process names or paths and excluding them from the rule. +- Developers or advanced users testing applications that require keychain access might inadvertently trigger the rule. Users should document these activities and consider temporary exclusions during development phases. +- Automated scripts or workflows that interact with keychain data for legitimate purposes could be mistaken for malicious activity. Users should ensure these scripts are well-documented and consider adding them to an allowlist if they are frequently used. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, specifically those involving the "dump-keychain" command, to halt ongoing credential theft attempts. +- Conduct a thorough review of the system's keychain access logs to identify any unauthorized access or export of credentials and determine the scope of the compromise. +- Change all credentials stored in the keychain, including passwords for Wi-Fi, websites, and any other services, to mitigate the risk of unauthorized access using stolen credentials. +- Restore the system from a known good backup if any unauthorized changes or malware are detected, ensuring that the backup predates the compromise. +- Escalate the incident to the security operations team for further investigation and to assess whether additional systems may be affected. +- Implement enhanced monitoring and alerting for similar suspicious activities, focusing on keychain access and command-line arguments related to credential dumping, to prevent future incidents.""" [[rule.threat]] diff --git a/rules/macos/credential_access_kerberosdump_kcc.toml b/rules/macos/credential_access_kerberosdump_kcc.toml index ef37c8198c4..324d23880f3 100644 --- a/rules/macos/credential_access_kerberosdump_kcc.toml +++ b/rules/macos/credential_access_kerberosdump_kcc.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/14" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -62,6 +62,40 @@ event.category:process and host.os.type:macos and event.type:(start or process_s process.name:kcc and process.args:copy_cred_cache ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Kerberos Cached Credentials Dumping + +Kerberos is a network authentication protocol designed to provide secure identity verification for users and services. It uses tickets to allow nodes to prove their identity in a secure manner. Adversaries may exploit tools like the Kerberos credential cache utility to extract these tickets, enabling unauthorized access and lateral movement within a network. The detection rule identifies suspicious activity by monitoring for specific processes and arguments on macOS systems, flagging potential credential dumping attempts. + +### Possible investigation steps + +- Review the alert details to confirm the presence of the process name 'kcc' and the argument 'copy_cred_cache' in the process execution logs on macOS systems. +- Identify the user account associated with the process execution to determine if the activity aligns with expected behavior or if it indicates potential unauthorized access. +- Examine the timeline of the process execution to identify any preceding or subsequent suspicious activities, such as unusual login attempts or lateral movement within the network. +- Check for any other alerts or logs related to the same host or user account to assess if this is part of a broader attack pattern. +- Investigate the source and destination of any network connections made by the process to identify potential data exfiltration or communication with known malicious IP addresses. +- Consult with the user or system owner to verify if the use of the 'kcc' utility was legitimate or if it requires further investigation. + +### False positive analysis + +- Routine administrative tasks using the kcc utility may trigger the rule. Identify and document these tasks to create exceptions for known benign activities. +- Automated scripts or maintenance processes that involve copying Kerberos credential caches can be mistaken for malicious activity. Review and whitelist these scripts if they are verified as safe. +- Developers or IT personnel testing Kerberos configurations might use the kcc utility in a non-malicious context. Establish a process to log and approve such activities to prevent false alarms. +- Security tools or monitoring solutions that interact with Kerberos tickets for legitimate purposes may inadvertently trigger the rule. Coordinate with security teams to ensure these tools are recognized and excluded from detection. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement. +- Terminate the suspicious process identified as 'kcc' with the argument 'copy_cred_cache' to stop any ongoing credential dumping activity. +- Conduct a thorough review of the system's Kerberos ticket cache to identify any unauthorized access or anomalies, and invalidate any compromised tickets. +- Reset passwords and regenerate Kerberos tickets for any accounts that may have been affected to prevent further unauthorized access. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach. +- Implement additional monitoring on the affected system and similar endpoints to detect any recurrence of the credential dumping activity. +- Review and update access controls and Kerberos configurations to enhance security and reduce the risk of similar attacks in the future.""" [[rule.threat]] diff --git a/rules/macos/credential_access_keychain_pwd_retrieval_security_cmd.toml b/rules/macos/credential_access_keychain_pwd_retrieval_security_cmd.toml index fc4b71083a3..c7d8b30169b 100644 --- a/rules/macos/credential_access_keychain_pwd_retrieval_security_cmd.toml +++ b/rules/macos/credential_access_keychain_pwd_retrieval_security_cmd.toml @@ -2,7 +2,7 @@ creation_date = "2020/01/06" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -68,6 +68,40 @@ process where host.os.type == "macos" and event.action == "exec" and process.command_line : ("*Chrome*", "*Chromium*", "*Opera*", "*Safari*", "*Brave*", "*Microsoft Edge*", "*Firefox*") and not process.parent.executable : "/Applications/Keeper Password Manager.app/Contents/Frameworks/Keeper Password Manager Helper*/Contents/MacOS/Keeper Password Manager Helper*" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Keychain Password Retrieval via Command Line + +Keychain is macOS's secure storage system for managing user credentials, including passwords and certificates. Adversaries may exploit command-line tools to extract sensitive data from Keychain, targeting browsers like Chrome and Safari. The detection rule identifies suspicious command executions involving Keychain access, focusing on specific arguments and excluding legitimate applications, to flag potential credential theft attempts. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of the 'security' command with arguments '-wa' or '-ga' and 'find-generic-password' or 'find-internet-password', as these indicate attempts to access Keychain data. +- Examine the command line for references to browsers such as Chrome, Safari, or others specified in the rule to determine if the target was browser-related credentials. +- Investigate the parent process of the suspicious command to ensure it is not a legitimate application, specifically checking that it is not the Keeper Password Manager, as this is excluded in the rule. +- Check the user account associated with the process execution to determine if the activity aligns with expected behavior for that user or if it suggests unauthorized access. +- Review recent login and access logs for the system to identify any unusual or unauthorized access patterns that could correlate with the suspicious Keychain access attempt. +- Assess the system for any additional indicators of compromise or related suspicious activities that might suggest a broader security incident. + +### False positive analysis + +- Legitimate password managers like Keeper Password Manager may trigger the rule due to their access to Keychain for managing user credentials. To handle this, ensure that the process parent executable path for such applications is added to the exclusion list. +- System maintenance or administrative scripts that access Keychain for legitimate purposes might be flagged. Review these scripts and, if verified as safe, add their specific command patterns to the exception list. +- Development or testing tools that interact with browsers and require Keychain access could cause false positives. Identify these tools and exclude their specific process names or command-line arguments if they are part of regular operations. +- Automated backup or synchronization services that access browser credentials stored in Keychain may be mistakenly identified. Confirm these services' legitimacy and exclude their associated processes from the detection rule. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, particularly those involving the 'security' command with the specified arguments targeting browsers. +- Conduct a thorough review of the system's keychain access logs to identify any unauthorized access attempts and determine the scope of the compromise. +- Change all potentially compromised credentials stored in the keychain, including browser passwords and Wi-Fi credentials, and ensure they are updated across all relevant services. +- Implement additional monitoring on the affected system and similar endpoints to detect any further attempts to access keychain data using command-line tools. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures. +- Review and update endpoint security configurations to restrict unauthorized access to keychain data and enhance logging for keychain-related activities.""" [[rule.threat]] diff --git a/rules/macos/credential_access_mitm_localhost_webproxy.toml b/rules/macos/credential_access_mitm_localhost_webproxy.toml index 6e915a16c92..8351ac8e2ac 100644 --- a/rules/macos/credential_access_mitm_localhost_webproxy.toml +++ b/rules/macos/credential_access_mitm_localhost_webproxy.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/05" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -66,6 +66,41 @@ event.category:process and host.os.type:macos and event.type:start and "/usr/libexec/xpcproxy") and not process.Ext.effective_parent.executable : ("/Applications/Proxyman.app/Contents/MacOS/Proxyman" or "/Applications/Incoggo.app/Contents/MacOS/Incoggo.app") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 WebProxy Settings Modification + +Web proxy settings in macOS manage how web traffic is routed, often used to enhance security or manage network traffic. Adversaries may exploit these settings to redirect or intercept web traffic, potentially capturing sensitive data like credentials. The detection rule identifies suspicious use of the `networksetup` command to alter proxy settings, excluding known legitimate applications, thus highlighting potential unauthorized modifications indicative of malicious activity. + +### Possible investigation steps + +- Review the process details to confirm the use of the networksetup command with arguments like -setwebproxy, -setsecurewebproxy, or -setautoproxyurl, which indicate an attempt to modify web proxy settings. +- Check the parent process information to ensure it is not one of the known legitimate applications such as /Library/PrivilegedHelperTools/com.80pct.FreedomHelper or /Applications/Fiddler Everywhere.app/Contents/Resources/app/out/WebServer/Fiddler.WebUi. +- Investigate the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Examine recent network traffic logs for unusual patterns or connections that could suggest traffic redirection or interception. +- Look for any additional alerts or logs related to the same host or user that might indicate a broader pattern of suspicious activity. +- Assess the system for any signs of compromise or unauthorized access, such as unexpected user accounts or changes to system configurations. + +### False positive analysis + +- Legitimate applications like FreedomHelper, Fiddler Everywhere, and xpcproxy may trigger the rule when they modify proxy settings. To prevent these from being flagged, ensure they are included in the exclusion list of known applications. +- Network management tools such as Proxyman and Incoggo might also be detected. Add these to the exclusion list to avoid unnecessary alerts. +- Regular system updates or configurations by IT administrators can sometimes involve proxy setting changes. Coordinate with IT to identify these activities and consider adding them to the exclusion criteria if they are routine and verified as safe. +- Automated scripts or maintenance tasks that adjust proxy settings for legitimate reasons should be reviewed and, if deemed non-threatening, excluded from detection to reduce false positives. +- Monitor for any new applications or processes that may need to be added to the exclusion list as part of ongoing security management to ensure the rule remains effective without generating excessive false alerts. + +### Response and remediation + +- Immediately isolate the affected macOS device from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes related to the `networksetup` command that are not associated with known legitimate applications. +- Review and reset the web proxy settings on the affected device to their default or intended configuration to ensure no malicious redirection is in place. +- Conduct a thorough scan of the affected system using updated security tools to identify and remove any malware or unauthorized software that may have been installed. +- Analyze logs and network traffic to identify any data that may have been intercepted or exfiltrated, focusing on sensitive information such as credentials. +- Escalate the incident to the security operations team for further investigation and to determine if other systems may be affected. +- Implement enhanced monitoring and alerting for similar activities across the network to detect and respond to future attempts promptly.""" [[rule.threat]] diff --git a/rules/macos/credential_access_potential_macos_ssh_bruteforce.toml b/rules/macos/credential_access_potential_macos_ssh_bruteforce.toml index 40b3b2d181e..983de60efa6 100644 --- a/rules/macos/credential_access_potential_macos_ssh_bruteforce.toml +++ b/rules/macos/credential_access_potential_macos_ssh_bruteforce.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/16" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -57,6 +57,41 @@ type = "threshold" query = ''' event.category:process and host.os.type:macos and event.type:start and process.name:"sshd-keygen-wrapper" and process.parent.name:launchd ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 macOS SSH Brute Force Detected + +SSH (Secure Shell) is a protocol used to securely access remote systems. On macOS, the `sshd-keygen-wrapper` process is involved in SSH key generation. Adversaries may exploit this by repeatedly attempting to generate keys to gain unauthorized access, a tactic known as brute force. The detection rule identifies unusual activity by monitoring for excessive executions of this process, indicating potential brute force attempts. + +### Possible investigation steps + +- Review the alert details to confirm the host and process information, specifically checking for the host.os.type as macos and the process.name as sshd-keygen-wrapper. +- Examine the frequency and timing of the sshd-keygen-wrapper process executions to determine if they align with normal user activity or if they suggest an automated brute force attempt. +- Investigate the parent process, launchd, to ensure it is legitimate and not being used maliciously to spawn the sshd-keygen-wrapper process. +- Check for any recent successful or failed login attempts on the affected host to identify potential unauthorized access. +- Correlate the activity with any other alerts or logs from the same host to identify patterns or additional indicators of compromise. +- Review user account activity on the host to determine if any accounts have been accessed or modified unexpectedly. + +### False positive analysis + +- Legitimate administrative tasks may trigger the rule if an administrator is performing routine maintenance or updates that involve generating SSH keys. To handle this, create an exception for known administrative accounts or scheduled maintenance windows. +- Automated scripts or applications that require frequent SSH key generation for legitimate purposes can cause false positives. Identify these scripts or applications and exclude their associated processes or hosts from the detection rule. +- Development environments where SSH keys are frequently generated for testing purposes might trigger the rule. Consider excluding specific development machines or user accounts from the rule to prevent unnecessary alerts. +- Continuous integration/continuous deployment (CI/CD) systems that automate SSH key generation as part of their workflow can be a source of false positives. Exclude these systems or their specific processes from the detection rule to avoid disruption. +- If a known security tool or monitoring system is configured to test SSH key generation as part of its checks, it may trigger the rule. Verify the tool's activity and exclude its processes if deemed non-threatening. + +### Response and remediation + +- Immediately isolate the affected macOS host from the network to prevent further unauthorized access attempts. +- Terminate any suspicious or unauthorized `sshd-keygen-wrapper` processes running on the affected host to halt ongoing brute force attempts. +- Review and reset SSH credentials for all user accounts on the affected host to ensure no unauthorized access has been achieved. +- Implement IP blocking or rate limiting on the SSH service to prevent further brute force attempts from the same source. +- Conduct a thorough review of the affected host's SSH configuration and logs to identify any unauthorized changes or access. +- Escalate the incident to the security operations team for further investigation and to determine if additional hosts are affected. +- Enhance monitoring and alerting for similar SSH brute force patterns across the network to improve early detection and response capabilities.""" [[rule.threat]] diff --git a/rules/macos/credential_access_promt_for_pwd_via_osascript.toml b/rules/macos/credential_access_promt_for_pwd_via_osascript.toml index ac83ec10af5..4d362912e8f 100644 --- a/rules/macos/credential_access_promt_for_pwd_via_osascript.toml +++ b/rules/macos/credential_access_promt_for_pwd_via_osascript.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/16" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -68,6 +68,41 @@ process where event.action == "exec" and host.os.type == "macos" and "/Library/Application Support/JAMF/Jamf.app/Contents/MacOS/JamfDaemon.app/Contents/MacOS/JamfDaemon", "/Library/Application Support/JAMF/Jamf.app/Contents/MacOS/JamfManagementService.app/Contents/MacOS/JamfManagementService") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Prompt for Credentials with OSASCRIPT + +OSASCRIPT is a macOS utility that allows the execution of AppleScript and other OSA language scripts. Adversaries may exploit it to display deceptive dialogs prompting users for credentials, mimicking legitimate requests. The detection rule identifies suspicious OSASCRIPT usage by monitoring specific command patterns and excluding known legitimate processes, thereby flagging potential credential theft attempts. + +### Possible investigation steps + +- Review the process command line to confirm if the osascript command includes suspicious patterns like "display dialog" with "password" or "passphrase" to determine if it is attempting to prompt for credentials. +- Check the parent process executable to see if it matches any known legitimate applications or services, such as those listed in the exclusion criteria, to rule out false positives. +- Investigate the user account associated with the process to determine if it is a privileged account or if there is any unusual activity associated with it. +- Examine the process execution context, including the effective parent executable, to identify if the osascript was executed by a legitimate management tool or script. +- Look for any other related alerts or logs around the same timeframe to identify if this is part of a broader attack or isolated incident. +- Assess the risk and impact by determining if any credentials were potentially compromised and if further containment or remediation actions are necessary. + +### False positive analysis + +- Legitimate administrative scripts using osascript may trigger alerts if they include dialog prompts for passwords or passphrases. To manage this, identify and exclude these scripts by adding their specific command lines or parent executables to the exception list. +- Processes initiated by trusted applications like JAMF or Karabiner-Elements can be mistakenly flagged. Ensure these applications are included in the exclusion list to prevent unnecessary alerts. +- Scheduled maintenance tasks that use osascript for legitimate purposes might be misidentified. Review and exclude these tasks by specifying their user IDs or command line patterns in the detection rule exceptions. +- Custom scripts executed by system administrators for routine operations may appear suspicious. Document these scripts and add them to the exclusion criteria to avoid false positives. +- Terminal-based automation tools that interact with osascript could be incorrectly flagged. Verify these tools and include their paths in the exclusion list to reduce false alerts. + +### Response and remediation + +- Immediately isolate the affected macOS device from the network to prevent further unauthorized access or data exfiltration. +- Terminate the suspicious osascript process identified by the alert to stop any ongoing credential theft attempts. +- Conduct a thorough review of the affected system's recent activity logs to identify any unauthorized access or changes made during the incident. +- Reset credentials for any accounts that may have been compromised, ensuring that new passwords are strong and unique. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. +- Implement additional monitoring on the affected system and similar endpoints to detect any recurrence of the threat. +- Review and update endpoint security configurations to block unauthorized script execution and enhance detection capabilities for similar threats in the future.""" [[rule.threat]] diff --git a/rules/macos/credential_access_suspicious_web_browser_sensitive_file_access.toml b/rules/macos/credential_access_suspicious_web_browser_sensitive_file_access.toml index 6bbf5dbfbe9..3bea0df0a6b 100644 --- a/rules/macos/credential_access_suspicious_web_browser_sensitive_file_access.toml +++ b/rules/macos/credential_access_suspicious_web_browser_sensitive_file_access.toml @@ -2,7 +2,7 @@ creation_date = "2020/01/04" integration = ["endpoint"] maturity = "production" -updated_date = "2024/11/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -66,6 +66,40 @@ file where event.action == "open" and host.os.type == "macos" and process.execut not process.code_signature.signing_id : "org.mozilla.firefox" and not Effective_process.executable : "/Library/Elastic/Endpoint/elastic-endpoint.app/Contents/MacOS/elastic-endpoint" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Web Browser Sensitive File Access + +Web browsers store sensitive data like cookies and login credentials in specific files. Adversaries exploit this by accessing these files using untrusted or unsigned processes, potentially stealing credentials. The detection rule identifies such unauthorized access on macOS by monitoring file access events, focusing on untrusted processes or scripts, and excluding known safe executables, thus flagging potential credential theft attempts. + +### Possible investigation steps + +- Review the process executable path and name to determine if it is a known legitimate application or script, focusing on those not signed by trusted entities or identified as osascript. +- Check the process code signature details to verify if the process is unsigned or untrusted, which could indicate malicious activity. +- Investigate the user account associated with the process to determine if there is any unusual or unauthorized activity, such as unexpected logins or privilege escalations. +- Examine the file access event details, including the specific sensitive file accessed (e.g., cookies.sqlite, logins.json), to assess the potential impact on credential security. +- Correlate the event with other security alerts or logs from the same host or user to identify any patterns or additional suspicious activities that might indicate a broader compromise. +- Verify if the process executable path matches any known safe paths, such as the excluded path for the Elastic Endpoint, to rule out false positives. + +### False positive analysis + +- Access by legitimate applications: Some legitimate applications may access browser files for valid reasons, such as backup or synchronization tools. Users can create exceptions for these applications by adding their code signatures to the exclusion list. +- Developer or testing scripts: Developers might use scripts like osascript for testing purposes, which could trigger the rule. To manage this, users can whitelist specific scripts or processes used in development environments. +- Security software interactions: Security tools might access browser files as part of their scanning or monitoring activities. Users should verify the legitimacy of these tools and add them to the exclusion list if they are trusted. +- System maintenance tasks: Automated system maintenance tasks might access browser files. Users can identify these tasks and exclude them if they are part of routine system operations and deemed safe. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any untrusted or unsigned processes identified in the alert, especially those accessing sensitive browser files. +- Conduct a thorough review of the affected system's recent activity logs to identify any additional suspicious behavior or potential lateral movement. +- Change all potentially compromised credentials, focusing on those stored in the affected web browsers, and enforce multi-factor authentication where possible. +- Restore any altered or deleted sensitive files from a known good backup to ensure data integrity. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Update endpoint protection and monitoring tools to enhance detection capabilities for similar unauthorized access attempts in the future.""" [[rule.threat]] diff --git a/rules/macos/credential_access_systemkey_dumping.toml b/rules/macos/credential_access_systemkey_dumping.toml index 01434aa4c83..64cf3ac5134 100644 --- a/rules/macos/credential_access_systemkey_dumping.toml +++ b/rules/macos/credential_access_systemkey_dumping.toml @@ -2,7 +2,7 @@ creation_date = "2020/01/07" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -60,6 +60,40 @@ event.category:process and host.os.type:macos and event.type:(start or process_s process.args:("/private/var/db/SystemKey" or "/var/db/SystemKey") and not process.Ext.effective_parent.executable : "/Library/Elastic/Endpoint/elastic-endpoint.app/Contents/MacOS/elastic-endpoint" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 SystemKey Access via Command Line + +macOS keychains securely store user credentials, including passwords and certificates. Adversaries may exploit command-line access to extract keychain data, gaining unauthorized credentials. The detection rule identifies suspicious process activities targeting SystemKey paths, excluding legitimate security processes, to flag potential credential theft attempts. + +### Possible investigation steps + +- Review the process details to identify the executable that attempted to access the SystemKey paths, focusing on the process.args field to confirm the presence of "/private/var/db/SystemKey" or "/var/db/SystemKey". +- Investigate the parent process using process.Ext.effective_parent.executable to determine if the process chain is suspicious or if it might be a legitimate process that was not excluded by the rule. +- Check the timestamp of the event to correlate with other system activities or user actions that might explain the access attempt. +- Analyze the user account associated with the process to determine if it aligns with expected behavior or if it might indicate a compromised account. +- Review recent system logs and security alerts for any other unusual activities or patterns that might suggest a broader compromise or targeted attack. +- If possible, conduct a forensic analysis of the system to identify any unauthorized changes or additional indicators of compromise related to credential theft. + +### False positive analysis + +- Security software updates or scans may trigger the rule by accessing SystemKey paths. Users can create exceptions for known security applications that frequently access these paths, ensuring they are not flagged as threats. +- System maintenance scripts or backup processes might access SystemKey paths as part of routine operations. Identify these processes and add them to an exclusion list to prevent false alerts. +- Administrative tools used by IT departments for legitimate credential management could be mistakenly flagged. Verify these tools and configure the rule to exclude them from detection. +- Custom scripts developed for internal use that interact with keychain data should be reviewed and, if deemed safe, added to the list of exceptions to avoid unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule that are accessing the SystemKey paths, ensuring no further credential extraction occurs. +- Conduct a thorough review of the system's keychain access logs to identify any unauthorized access attempts and determine the scope of the compromise. +- Change all credentials stored in the keychain that may have been accessed, including Wi-Fi passwords, website credentials, and any other sensitive information. +- Restore the system from a known good backup if unauthorized changes or persistent threats are detected, ensuring the system is free from compromise. +- Implement additional monitoring on the affected system and similar endpoints to detect any further attempts to access keychain data, using enhanced logging and alerting mechanisms. +- Escalate the incident to the security operations team for further investigation and to assess the need for broader organizational response measures, such as notifying affected users or stakeholders.""" [[rule.threat]] diff --git a/rules/macos/defense_evasion_apple_softupdates_modification.toml b/rules/macos/defense_evasion_apple_softupdates_modification.toml index 44a47192117..914473c3efa 100644 --- a/rules/macos/defense_evasion_apple_softupdates_modification.toml +++ b/rules/macos/defense_evasion_apple_softupdates_modification.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/15" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -60,6 +60,40 @@ event.category:process and host.os.type:macos and event.type:(start or process_s process.name:defaults and process.args:(write and "-bool" and (com.apple.SoftwareUpdate or /Library/Preferences/com.apple.SoftwareUpdate.plist) and not (TRUE or true)) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 SoftwareUpdate Preferences Modification + +In macOS environments, the SoftwareUpdate preferences manage system updates, crucial for maintaining security. Adversaries may exploit the 'defaults' command to alter these settings, potentially disabling updates to evade defenses. The detection rule identifies such modifications by monitoring specific command executions that attempt to change update preferences without enabling them, signaling potential malicious activity. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of the 'defaults' command with arguments attempting to modify SoftwareUpdate preferences, specifically looking for 'write', '-bool', and the targeted preferences file paths. +- Check the user account associated with the process execution to determine if it aligns with expected administrative activity or if it might be indicative of unauthorized access. +- Investigate the host's recent activity for any other suspicious processes or commands that may suggest a broader attempt to impair system defenses or evade detection. +- Examine system logs and security alerts around the time of the detected event to identify any correlated activities or anomalies that could provide additional context or evidence of malicious intent. +- Assess the current state of the SoftwareUpdate preferences on the affected host to verify if updates have been disabled or altered, and take corrective actions if necessary. + +### False positive analysis + +- System administrators may use the defaults command to configure SoftwareUpdate settings during routine maintenance. To handle this, create exceptions for known administrative scripts or processes that frequently execute these commands. +- Automated configuration management tools might alter SoftwareUpdate preferences as part of their standard operations. Identify these tools and exclude their process identifiers from triggering the rule. +- Some legitimate applications may require specific update settings and modify preferences accordingly. Monitor and whitelist these applications to prevent unnecessary alerts. +- User-initiated changes to update settings for personal preferences can trigger false positives. Educate users on the implications of such changes and consider excluding user-specific processes if they are consistently non-threatening. +- During system setup or reconfiguration, defaults commands may be used to establish baseline settings. Temporarily disable the rule or set up a temporary exception during these periods to avoid false alerts. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent potential spread or further unauthorized changes. +- Review the process execution logs to confirm the unauthorized use of the 'defaults' command and identify any associated user accounts or processes. +- Revert any unauthorized changes to the SoftwareUpdate preferences by resetting them to their default state using the 'defaults' command with appropriate parameters. +- Conduct a thorough scan of the affected system for additional signs of compromise, such as malware or unauthorized access attempts, using endpoint security tools. +- Change passwords and review permissions for any user accounts involved in the incident to prevent further unauthorized access. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected. +- Implement enhanced monitoring for similar command executions across the network to detect and respond to future attempts promptly.""" [[rule.threat]] diff --git a/rules/macos/defense_evasion_attempt_del_quarantine_attrib.toml b/rules/macos/defense_evasion_attempt_del_quarantine_attrib.toml index 651cb2eae28..cb04d29b5e0 100644 --- a/rules/macos/defense_evasion_attempt_del_quarantine_attrib.toml +++ b/rules/macos/defense_evasion_attempt_del_quarantine_attrib.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/14" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -68,6 +68,40 @@ process.executable : ("/usr/bin/xattr", "/Applications/.com.bomgar.scc.*/Remote Support Customer Client.app/Contents/MacOS/sdcust") and not file.path : "/private/var/folders/*" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Quarantine Attrib Removed by Unsigned or Untrusted Process + +In macOS, files downloaded from the internet are tagged with a quarantine attribute, which is checked by Gatekeeper to ensure safety before execution. Adversaries may remove this attribute to bypass security checks, allowing potentially harmful applications to run unchecked. The detection rule identifies such actions by monitoring for the removal of this attribute by processes that are either unsigned or untrusted, flagging unusual activity that deviates from expected behavior. + +### Possible investigation steps + +- Review the process executable path that triggered the alert to determine if it is a known or expected application on the system. Check if it matches any legitimate software that might not be properly signed. +- Investigate the parent process of the flagged executable to understand the context of its execution. This can help identify if the process was spawned by a legitimate application or a potentially malicious one. +- Examine the file path from which the quarantine attribute was removed to assess if it is a common location for downloaded files or if it appears suspicious. +- Check the system for any recent downloads or installations that might correlate with the time of the alert to identify potential sources of the file. +- Look into the user account under which the process was executed to determine if it aligns with expected user behavior or if it might indicate unauthorized access. +- Search for any other alerts or logs related to the same process or file path to identify patterns or repeated attempts to bypass security measures. + +### False positive analysis + +- System processes or legitimate applications may occasionally remove the quarantine attribute as part of their normal operation. Users can create exceptions for known safe processes by adding them to the exclusion list in the detection rule. +- Software updates or installations from trusted vendors might trigger the rule if they are not properly signed. Verify the legitimacy of the software and consider adding the specific executable path to the exclusion list if it is deemed safe. +- Custom scripts or automation tools used within an organization might remove the quarantine attribute as part of their workflow. Review these scripts to ensure they are secure and add their paths to the exclusion list to prevent false positives. +- Temporary files or directories, such as those in /private/var/folders, are already excluded to reduce noise. Ensure that any additional temporary paths used by trusted applications are similarly excluded if they are known to cause false positives. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or further compromise. +- Terminate any untrusted or unsigned processes identified in the alert that are responsible for removing the quarantine attribute. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious software. +- Restore any affected files from a known good backup if they have been altered or compromised. +- Review system logs and the specific file paths involved in the alert to identify any additional unauthorized changes or suspicious activity. +- 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 similar activities on other macOS systems to enhance detection and response capabilities.""" [[rule.threat]] diff --git a/rules/macos/defense_evasion_attempt_to_disable_gatekeeper.toml b/rules/macos/defense_evasion_attempt_to_disable_gatekeeper.toml index 9cf185bb72a..aa9061e92dc 100644 --- a/rules/macos/defense_evasion_attempt_to_disable_gatekeeper.toml +++ b/rules/macos/defense_evasion_attempt_to_disable_gatekeeper.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/11" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -61,6 +61,41 @@ query = ''' event.category:process and host.os.type:macos and event.type:(start or process_started) and process.args:(spctl and "--master-disable") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Attempt to Disable Gatekeeper + +Gatekeeper is a macOS security feature that ensures only trusted software runs by verifying app signatures. Adversaries may attempt to disable it to execute unauthorized code, bypassing security checks. The detection rule identifies such attempts by monitoring process events for specific commands used to disable Gatekeeper, flagging potential defense evasion activities. + +### Possible investigation steps + +- Review the process event details to confirm the presence of the command `spctl --master-disable` in the `process.args` field, which indicates an attempt to disable Gatekeeper. +- Identify the user account associated with the process event to determine if the action was initiated by a legitimate user or an unauthorized actor. +- Check the `event.category` and `event.type` fields to ensure the event is categorized as a process start, which aligns with the rule's detection criteria. +- Investigate the parent process of the flagged event to understand the context in which the Gatekeeper disabling attempt was made, looking for any suspicious or unexpected parent processes. +- Examine recent process events on the same host to identify any subsequent or preceding suspicious activities that might indicate a broader attack or compromise. +- Review system logs and other security alerts on the host for additional indicators of compromise or related malicious activities. +- Assess the risk and impact of the event by considering the host's role, the sensitivity of data it handles, and any potential exposure resulting from the attempted Gatekeeper disablement. + +### False positive analysis + +- System administrators or IT personnel may intentionally disable Gatekeeper for legitimate software installations or troubleshooting. To manage this, create exceptions for known administrative accounts or specific maintenance windows. +- Some legitimate applications may require Gatekeeper to be disabled temporarily for installation. Identify these applications and whitelist their installation processes to prevent false alerts. +- Development environments on macOS might disable Gatekeeper to test unsigned applications. Consider excluding processes initiated by development tools or specific user accounts associated with development activities. +- Automated scripts or management tools that configure macOS settings might trigger this rule. Review and adjust these scripts to ensure they are recognized as non-threatening, or exclude them from monitoring if they are verified as safe. + +### Response and remediation + +- Immediately isolate the affected macOS device from the network to prevent potential lateral movement or further execution of unauthorized code. +- Terminate any suspicious processes associated with the attempt to disable Gatekeeper, specifically those involving the 'spctl --master-disable' command. +- Conduct a thorough review of recent system changes and installed applications on the affected device to identify and remove any unauthorized or malicious software. +- Restore Gatekeeper settings to their default state to ensure that only trusted software can be executed on the device. +- Escalate the incident to the security operations team for further analysis and to determine if additional devices or systems may be affected. +- Implement additional monitoring on the affected device and similar systems to detect any further attempts to disable Gatekeeper or other security features. +- Review and update endpoint security policies to enhance protection against similar threats, ensuring that all macOS devices are configured to prevent unauthorized changes to security settings.""" [[rule.threat]] diff --git a/rules/macos/defense_evasion_install_root_certificate.toml b/rules/macos/defense_evasion_install_root_certificate.toml index c4d2d688080..126239ed7b4 100644 --- a/rules/macos/defense_evasion_install_root_certificate.toml +++ b/rules/macos/defense_evasion_install_root_certificate.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/13" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -63,6 +63,39 @@ event.category:process and host.os.type:macos and event.type:(start or process_s not process.parent.executable:("/Library/Bitdefender/AVP/product/bin/BDCoreIssues" or "/Applications/Bitdefender/SecurityNetworkInstallerApp.app/Contents/MacOS/SecurityNetworkInstallerApp" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Attempt to Install Root Certificate + +Root certificates are pivotal in establishing trust within public key infrastructures, enabling secure communications by verifying the authenticity of digital certificates. Adversaries exploit this by installing unauthorized root certificates on compromised macOS systems, thereby bypassing security warnings and facilitating covert command and control communications. The detection rule identifies such activities by monitoring specific process executions related to certificate management, excluding known legitimate applications, thus highlighting potential malicious attempts to subvert trust controls. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of the "security" process with the "add-trusted-cert" argument, as this indicates an attempt to add a root certificate. +- Check the parent process of the suspicious activity to ensure it is not one of the known legitimate applications, such as Bitdefender, as specified in the exclusion list. +- Investigate the user account associated with the process execution to determine if it is a legitimate user or potentially compromised. +- Examine recent system logs and network activity for any signs of unauthorized access or communication with known malicious command and control servers. +- Assess the system for any other indicators of compromise or unusual behavior that may suggest further malicious activity beyond the root certificate installation attempt. + +### False positive analysis + +- Security software installations or updates may trigger the rule as they often involve legitimate root certificate installations. Users can handle this by adding exceptions for known security software paths, such as Bitdefender, to prevent unnecessary alerts. +- System administrators performing routine maintenance or updates might install root certificates as part of their tasks. To mitigate this, create exceptions for processes executed by trusted admin accounts or during scheduled maintenance windows. +- Some enterprise applications may require the installation of root certificates for internal communications. Identify these applications and exclude their processes from the rule to avoid false positives. +- Development environments on macOS systems might involve testing with self-signed certificates, which could trigger the rule. Developers can be instructed to use designated test environments or have their processes excluded during development phases. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized communications and potential data exfiltration. +- Revoke any unauthorized root certificates installed on the system by accessing the Keychain Access application and removing the suspicious certificates from the System Roots keychain. +- Conduct a thorough review of system logs and process execution history to identify any additional unauthorized changes or suspicious activities that may have occurred alongside the root certificate installation. +- Restore the system to a known good state using backups or system snapshots taken prior to the compromise, ensuring that any malicious changes are reverted. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems in the network may be affected. +- Implement enhanced monitoring and alerting for similar activities by refining detection capabilities to include additional indicators of compromise (IOCs) related to unauthorized certificate installations. +- Review and update security policies and configurations to prevent unauthorized certificate installations, such as enforcing stricter access controls and requiring administrative approval for certificate management actions.""" [[rule.threat]] diff --git a/rules/macos/defense_evasion_modify_environment_launchctl.toml b/rules/macos/defense_evasion_modify_environment_launchctl.toml index 4cd4dfee4f8..5df2a7a4be7 100644 --- a/rules/macos/defense_evasion_modify_environment_launchctl.toml +++ b/rules/macos/defense_evasion_modify_environment_launchctl.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/14" integration = ["endpoint"] maturity = "production" -updated_date = "2024/11/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -74,6 +74,40 @@ event.category:process and host.os.type:macos and event.type:start and /Applications/NoMachine.app/Contents/Frameworks/bin/nxserver.bin or /usr/local/bin/kr) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Modification of Environment Variable via Unsigned or Untrusted Parent + +Environment variables in macOS are crucial for configuring system and application behavior. Adversaries may exploit these by using the `launchctl` command to alter variables, enabling malicious payload execution or bypassing restrictions. The detection rule identifies suspicious modifications initiated by untrusted or unsigned parent processes, focusing on atypical environment variables and excluding known safe executables, thus highlighting potential threats. + +### Possible investigation steps + +- Review the process tree to identify the parent process of the `launchctl` command, focusing on whether the parent process is unsigned or untrusted, as indicated by the absence or lack of trust in the `process.parent.code_signature`. +- Examine the command-line arguments used with `launchctl`, specifically looking for the `setenv` command and any unusual or suspicious environment variables that are not part of the known safe list (e.g., ANT_HOME, DBUS_LAUNCHD_SESSION_BUS_SOCKET). +- Check the execution path of the parent process to determine if it matches any known safe executables, such as those listed in the exclusion criteria (e.g., /Applications/IntelliJ IDEA CE.app/Contents/jbr/Contents/Home/lib/jspawnhelper). +- Investigate the user account under which the `launchctl` command was executed to determine if it aligns with expected behavior or if it might indicate a compromised account. +- Correlate this event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise that might suggest a broader attack or intrusion attempt. + +### False positive analysis + +- Development tools like IntelliJ IDEA may trigger false positives when using the jspawnhelper executable. To mitigate this, add the executable path to the exclusion list if it is a known and trusted application in your environment. +- NoMachine software can cause false positives due to its use of nxserver.bin. If this software is regularly used and trusted, consider excluding its executable path from the detection rule. +- The kr tool located at /usr/local/bin/kr might be flagged as a false positive. If this tool is part of your standard operations, ensure its path is excluded to prevent unnecessary alerts. +- Review any other unsigned or untrusted parent processes that are part of legitimate software installations or operations. If they are verified as safe, add them to the exclusion list to reduce false positives. +- Regularly update the list of known safe executables and environment variables to reflect changes in your software inventory, ensuring that legitimate processes are not mistakenly flagged. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or further exploitation. +- Terminate any suspicious processes associated with the untrusted or unsigned parent process that initiated the `launchctl` command to halt any ongoing malicious activity. +- Conduct a thorough review of the environment variables modified by the `launchctl` command to identify any unauthorized changes and revert them to their original state. +- Analyze the parent process that triggered the alert to determine its origin and purpose, and remove any malicious or unauthorized software identified during this analysis. +- Restore the system from a known good backup if any critical system components or configurations have been compromised. +- Implement additional monitoring and logging for `launchctl` usage and environment variable modifications to detect similar threats in the future. +- Escalate the incident to the security operations team for further investigation and to assess the need for broader organizational response measures.""" [[rule.threat]] diff --git a/rules/macos/defense_evasion_privacy_controls_tcc_database_modification.toml b/rules/macos/defense_evasion_privacy_controls_tcc_database_modification.toml index 044d6b27ab3..6db47ecdccb 100644 --- a/rules/macos/defense_evasion_privacy_controls_tcc_database_modification.toml +++ b/rules/macos/defense_evasion_privacy_controls_tcc_database_modification.toml @@ -2,7 +2,7 @@ creation_date = "2020/12/23" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -64,6 +64,41 @@ process where host.os.type == "macos" and event.type in ("start", "process_start process.args : "/*/Application Support/com.apple.TCC/TCC.db" and not process.parent.executable : "/Library/Bitdefender/AVP/product/bin/*" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Privacy Control Bypass via TCCDB Modification + +The Transparency, Consent, and Control (TCC) database in macOS manages app permissions for accessing sensitive resources. Adversaries may exploit this by using tools like sqlite3 to alter the TCC database, bypassing privacy controls. The detection rule identifies such attempts by monitoring for suspicious sqlite3 activity targeting the TCC database, excluding legitimate processes, to flag potential privacy control bypasses. + +### Possible investigation steps + +- Review the process details to confirm the use of sqlite3, focusing on the process name and arguments to ensure they match the pattern "sqlite*" and include the path "/*/Application Support/com.apple.TCC/TCC.db". +- Investigate the parent process of the sqlite3 activity to determine if it is a known legitimate process or if it appears suspicious, especially if it is not from "/Library/Bitdefender/AVP/product/bin/*". +- Check the timestamp of the sqlite3 activity to correlate it with any other unusual system behavior or alerts that occurred around the same time. +- Examine the user account associated with the process to determine if it has a history of legitimate administrative actions or if it might be compromised. +- Look for any recent changes or anomalies in the TCC database permissions that could indicate unauthorized modifications. +- Assess the system for other signs of compromise, such as unexpected network connections or additional unauthorized processes running, to determine if the sqlite3 activity is part of a larger attack. + +### False positive analysis + +- Security software like Bitdefender may legitimately access the TCC database for scanning purposes. To prevent these from being flagged, ensure that the process parent executable path for such software is added to the exclusion list. +- System maintenance tools that perform regular checks or backups might access the TCC database. Identify these tools and add their process paths to the exclusion list to avoid false alerts. +- Developer tools used for testing applications may interact with the TCC database. If these tools are frequently used in your environment, consider excluding their process paths to reduce noise. +- Administrative scripts that automate system configurations might modify the TCC database. Review these scripts and, if deemed safe, exclude their process paths from the detection rule. +- Regular system updates or patches could trigger access to the TCC database. Monitor these events and, if consistent with update schedules, adjust the rule to exclude these specific update processes. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious sqlite3 processes identified in the alert to stop ongoing unauthorized modifications to the TCC database. +- Restore the TCC database from a known good backup to ensure that all privacy settings are reverted to their legitimate state. +- Conduct a thorough review of recent changes to the TCC database to identify any unauthorized access or modifications to sensitive resources. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement additional monitoring on the affected system to detect any further attempts to modify the TCC database or other unauthorized activities. +- Review and update access controls and permissions for the TCC database to ensure only authorized processes can make changes, reducing the risk of future bypass attempts.""" [[rule.threat]] diff --git a/rules/macos/defense_evasion_privilege_escalation_privacy_pref_sshd_fulldiskaccess.toml b/rules/macos/defense_evasion_privilege_escalation_privacy_pref_sshd_fulldiskaccess.toml index 0e9e1000b8e..4c65154d179 100644 --- a/rules/macos/defense_evasion_privilege_escalation_privacy_pref_sshd_fulldiskaccess.toml +++ b/rules/macos/defense_evasion_privilege_escalation_privacy_pref_sshd_fulldiskaccess.toml @@ -2,7 +2,7 @@ creation_date = "2020/01/11" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -65,6 +65,41 @@ process where host.os.type == "macos" and event.type in ("start", "process_start process.command_line:("scp *localhost:/*", "scp *127.0.0.1:/*") and not process.args:"vagrant@*127.0.0.1*" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Privacy Control Bypass via Localhost Secure Copy + +Secure Copy Protocol (SCP) is used for secure file transfers over SSH. On macOS, SSH daemon inclusion in the Full Disk Access list can be exploited to bypass privacy controls. Adversaries may misuse SCP to locally copy files, evading security measures. The detection rule identifies such activity by monitoring SCP commands targeting localhost, excluding benign uses like Vagrant, to flag potential privacy control bypass attempts. + +### Possible investigation steps + +- Review the process details to confirm the presence of SCP commands targeting localhost or 127.0.0.1, as indicated by the process.command_line field. +- Check the process.args field for the presence of "StrictHostKeyChecking=no" to verify if the SCP command was executed with potentially insecure settings. +- Investigate the user account associated with the SCP command to determine if it is a legitimate user or potentially compromised. +- Examine the timing and frequency of the SCP command execution to identify any unusual patterns or repeated attempts that may indicate malicious activity. +- Cross-reference the alert with other security logs or alerts to identify any related suspicious activities or anomalies around the same timeframe. +- Assess the system for any unauthorized changes or access to sensitive files that may have occurred as a result of the SCP command execution. + +### False positive analysis + +- Vagrant usage can trigger false positives due to its legitimate use of SCP for local file transfers. To mitigate this, ensure that Vagrant-related SCP commands are excluded by refining the detection rule to ignore processes with arguments containing "vagrant@*127.0.0.1*". +- Development and testing environments may frequently use SCP to localhost for legitimate purposes. Consider creating exceptions for known development tools or scripts that regularly perform these actions to reduce noise. +- Automated backup solutions might use SCP to copy files locally as part of their routine operations. Identify and whitelist these processes to prevent them from being flagged as potential threats. +- System administrators may use SCP for local file management tasks. Establish a list of trusted administrator accounts or specific command patterns that can be safely excluded from triggering alerts. +- Continuous integration and deployment pipelines might involve SCP commands to localhost. Review and exclude these processes if they are part of a controlled and secure workflow. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious SCP processes identified in the alert to halt ongoing unauthorized file transfers. +- Conduct a thorough review of the system's Full Disk Access list to identify and remove any unauthorized applications, including the SSH daemon if it was added without proper authorization. +- Analyze the system's SSH configuration and logs to identify any unauthorized changes or access patterns, and revert any suspicious modifications. +- Reset credentials for any accounts that may have been compromised, focusing on those with SSH access, and enforce the use of strong, unique passwords. +- Implement network monitoring to detect and alert on any future SCP commands targeting localhost, especially those bypassing host key checks. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on sensitive data, ensuring compliance with organizational incident response protocols.""" [[rule.threat]] diff --git a/rules/macos/defense_evasion_safari_config_change.toml b/rules/macos/defense_evasion_safari_config_change.toml index 599eef17f93..1a588fb6a96 100644 --- a/rules/macos/defense_evasion_safari_config_change.toml +++ b/rules/macos/defense_evasion_safari_config_change.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/14" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -68,6 +68,40 @@ event.category:process and host.os.type:macos and event.type:start and ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Modification of Safari Settings via Defaults Command + +The 'defaults' command in macOS is a utility that allows users to read, write, and manage macOS application preferences, including Safari settings. Adversaries may exploit this command to alter Safari configurations, potentially enabling harmful features like JavaScript from Apple Events, which can facilitate browser hijacking. The detection rule monitors for suspicious 'defaults' command usage targeting Safari settings, excluding benign preference changes, to identify potential defense evasion attempts. + +### Possible investigation steps + +- Review the process execution details to confirm the use of the 'defaults' command with arguments targeting Safari settings, specifically looking for any suspicious or unauthorized changes. +- Check the user account associated with the process execution to determine if the action was performed by a legitimate user or an unauthorized entity. +- Investigate the system's recent activity logs to identify any other unusual or suspicious behavior around the time the 'defaults' command was executed. +- Examine the Safari settings before and after the change to assess the impact and identify any potentially harmful configurations, such as enabling JavaScript from Apple Events. +- Correlate the event with other security alerts or incidents to determine if this action is part of a broader attack or compromise attempt. + +### False positive analysis + +- Changes to Safari settings for legitimate user preferences can trigger alerts, such as enabling or disabling search suggestions. Users can create exceptions for these specific settings by excluding them from the detection rule. +- System administrators may use the defaults command to configure Safari settings across multiple devices for compliance or user experience improvements. These actions can be whitelisted by identifying the specific process arguments used in these administrative tasks. +- Automated scripts or management tools that adjust Safari settings as part of routine maintenance or updates may cause false positives. Users should identify these scripts and exclude their specific process arguments from the detection rule. +- Developers testing Safari configurations might frequently change settings using the defaults command. Excluding known developer machines or user accounts from the rule can help reduce false positives. +- Educational or training environments where users are instructed to modify Safari settings for learning purposes can lead to alerts. Identifying and excluding these environments or sessions can mitigate unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected macOS device from the network to prevent further malicious activity or data exfiltration. +- Terminate any suspicious processes related to the 'defaults' command that are currently running on the affected device. +- Revert any unauthorized changes made to Safari settings by restoring them to their default or previously known safe state. +- Conduct a thorough scan of the affected device using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or malicious scripts. +- Review and update the device's security settings to prevent unauthorized changes, including disabling unnecessary Apple Events and restricting the use of the 'defaults' command to authorized personnel only. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other devices in the network are affected. +- Implement enhanced monitoring and alerting for similar 'defaults' command usage across the network to detect and respond to future attempts promptly.""" [[rule.threat]] diff --git a/rules/macos/defense_evasion_sandboxed_office_app_suspicious_zip_file.toml b/rules/macos/defense_evasion_sandboxed_office_app_suspicious_zip_file.toml index 0c821e217e4..a3072ad7fef 100644 --- a/rules/macos/defense_evasion_sandboxed_office_app_suspicious_zip_file.toml +++ b/rules/macos/defense_evasion_sandboxed_office_app_suspicious_zip_file.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/11" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -62,6 +62,40 @@ type = "query" query = ''' event.category:file and host.os.type:(macos and macos) and not event.type:deletion and file.name:~$*.zip ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Microsoft Office Sandbox Evasion + +Microsoft Office applications on macOS operate within a sandbox to limit potential damage from malicious files. However, adversaries can exploit this by creating zip files with special character prefixes, bypassing sandbox restrictions. The detection rule identifies such files, focusing on non-deletion events with specific naming patterns, to flag potential evasion attempts and mitigate risks. + +### Possible investigation steps + +- Review the file creation event details to confirm the presence of a zip file with a name starting with special characters, as indicated by the file.name field. +- Examine the file path and location to determine if it aligns with known AutoStart locations, which could indicate an attempt to achieve persistence. +- Investigate the user account associated with the event to assess if the activity is expected or if the account may have been compromised. +- Check for any related events or activities on the same host around the time of the alert, such as other file creations or modifications, to identify potential patterns or additional suspicious behavior. +- Analyze the host's recent network activity to detect any unusual outbound connections that might suggest data exfiltration or communication with a command and control server. +- Correlate the event with other alerts or logs from the same host or user to build a comprehensive timeline of activities and assess the broader impact or intent. + +### False positive analysis + +- Files with special character prefixes created by legitimate applications or processes, such as temporary files generated by Microsoft Office during normal operations, may trigger the rule. Users can create exceptions for known benign applications that frequently generate such files. +- Automated backup or synchronization tools that compress files into zip archives with special character prefixes might be flagged. Identify these tools and exclude their file creation events from the rule. +- Development or testing environments where zip files with special character prefixes are used for legitimate purposes can cause false positives. Implement exclusions for these environments to prevent unnecessary alerts. +- User-generated zip files with special character prefixes for personal organization or naming conventions may be mistakenly identified. Educate users on naming conventions and adjust the rule to exclude specific user directories if needed. + +### Response and remediation + +- Isolate the affected macOS system from the network to prevent further potential spread or data exfiltration. +- Quarantine the suspicious zip file to prevent execution and further analysis. +- Conduct a thorough scan of the system using updated antivirus and endpoint detection tools to identify and remove any additional malicious files or processes. +- Review and secure AutoStart locations on the affected system to prevent unauthorized applications from executing at startup. +- Restore any affected files from a known good backup to ensure system integrity and continuity. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if other systems may be affected. +- Update security policies and endpoint protection configurations to block the creation and execution of files with suspicious naming patterns, enhancing future detection and prevention capabilities.""" [[rule.threat]] diff --git a/rules/macos/defense_evasion_tcc_bypass_mounted_apfs_access.toml b/rules/macos/defense_evasion_tcc_bypass_mounted_apfs_access.toml index 8accc83b579..5dae1f3e625 100644 --- a/rules/macos/defense_evasion_tcc_bypass_mounted_apfs_access.toml +++ b/rules/macos/defense_evasion_tcc_bypass_mounted_apfs_access.toml @@ -2,7 +2,7 @@ creation_date = "2020/01/04" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -60,6 +60,39 @@ query = ''' event.category:process and host.os.type:macos and event.type:(start or process_started) and process.name:mount_apfs and process.args:(/System/Volumes/Data and noowners) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 TCC Bypass via Mounted APFS Snapshot Access + +Apple's TCC framework safeguards user data by controlling app access to sensitive files. Adversaries exploit APFS snapshots, mounting them with specific flags to bypass these controls, gaining unauthorized access to protected data. The detection rule identifies this misuse by monitoring the execution of the `mount_apfs` command with parameters indicative of such bypass attempts, flagging potential security breaches. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of the `mount_apfs` command with the specific arguments `/System/Volumes/Data` and `noowners` to verify the alert's accuracy. +- Investigate the user account associated with the process execution to determine if the activity aligns with expected behavior or if it indicates potential unauthorized access. +- Examine the timeline of events leading up to and following the alert to identify any related suspicious activities or processes that may indicate a broader attack or compromise. +- Check for any recent changes or anomalies in system configurations or user permissions that could have facilitated the bypass attempt. +- Correlate the alert with other security logs or alerts to assess if this is part of a larger pattern of malicious behavior or an isolated incident. + +### False positive analysis + +- System maintenance tools or backup software may legitimately use the mount_apfs command with the noowners flag for routine operations. Users can create exceptions for these specific tools by identifying their process names or paths and excluding them from the detection rule. +- Developers or IT administrators might use the mount_apfs command during testing or troubleshooting. To prevent these activities from triggering false positives, users can whitelist specific user accounts or IP addresses associated with these roles. +- Automated scripts or scheduled tasks that require access to APFS snapshots for legitimate purposes might trigger the rule. Users should review these scripts and, if deemed safe, add them to an exclusion list based on their unique identifiers or execution context. +- Security software or monitoring tools that perform regular checks on file system integrity might inadvertently match the rule's criteria. Users can mitigate this by identifying these tools and excluding their specific process signatures from the detection parameters. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes related to the `mount_apfs` command to halt ongoing unauthorized access attempts. +- Conduct a thorough review of system logs and user activity to identify any data accessed or exfiltrated during the breach. +- Restore any compromised files from a known good backup to ensure data integrity and security. +- Update macOS and all installed applications to the latest versions to patch any vulnerabilities that may have been exploited. +- Implement stricter access controls and monitoring for APFS snapshot usage to prevent similar bypass attempts in the future. +- Escalate the incident to the security operations center (SOC) or relevant IT security team for further investigation and to assess the need for additional security measures.""" [[rule.threat]] diff --git a/rules/macos/defense_evasion_unload_endpointsecurity_kext.toml b/rules/macos/defense_evasion_unload_endpointsecurity_kext.toml index 332860d1f4b..e5436e0a571 100644 --- a/rules/macos/defense_evasion_unload_endpointsecurity_kext.toml +++ b/rules/macos/defense_evasion_unload_endpointsecurity_kext.toml @@ -2,7 +2,7 @@ creation_date = "2020/01/05" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -54,6 +54,40 @@ query = ''' event.category:process and host.os.type:macos and event.type:(start or process_started) and process.name:kextunload and process.args:("/System/Library/Extensions/EndpointSecurity.kext" or "EndpointSecurity.kext") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Attempt to Unload Elastic Endpoint Security Kernel Extension + +Elastic Endpoint Security's kernel extension is crucial for monitoring and protecting macOS systems by intercepting and analyzing system-level events. Adversaries may attempt to unload this extension using the `kextunload` command to evade detection and impair defenses. The detection rule identifies such attempts by monitoring process events related to the `kextunload` command targeting the security extension, flagging potential defense evasion activities. + +### Possible investigation steps + +- Review the process event details to confirm the presence of the `kextunload` command targeting "EndpointSecurity.kext" in the process arguments. +- Identify the user account associated with the process event to determine if the action was initiated by an authorized or suspicious user. +- Check the host's recent activity logs for any other unusual or unauthorized actions that might indicate a broader attack or compromise. +- Investigate the source of the command execution by examining the parent process and any related processes to understand how the `kextunload` command was initiated. +- Assess the system for any signs of tampering or additional indicators of compromise, such as unauthorized file modifications or unexpected network connections. +- Correlate this event with other alerts or logs from the same host or user to identify potential patterns or coordinated activities. + +### False positive analysis + +- System administrators performing routine maintenance may trigger the rule when testing or updating kernel extensions. To manage this, create exceptions for known maintenance activities by whitelisting specific user accounts or processes during scheduled maintenance windows. +- Legitimate software updates or installations that require unloading the kernel extension might be flagged. To handle this, monitor and document regular update schedules and create exceptions for these activities, ensuring they align with expected update patterns. +- Security testing or audits conducted by authorized personnel could also trigger the rule. Implement a process to temporarily disable the rule or whitelist specific testing tools and accounts during these audits to prevent false positives. +- Development environments where kernel extensions are frequently loaded and unloaded for testing purposes may generate alerts. Consider setting up a separate monitoring profile for development systems with adjusted thresholds or exceptions to accommodate these activities. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized actions or potential lateral movement by the adversary. +- Terminate any unauthorized processes related to the `kextunload` command to stop the attempt to unload the Elastic Endpoint Security kernel extension. +- Conduct a thorough review of system logs and process execution history to identify any additional suspicious activities or indicators of compromise associated with the adversary's attempt. +- Restore the Elastic Endpoint Security kernel extension if it was successfully unloaded, ensuring that the system's protective measures are fully operational. +- Update and patch the macOS system and all security software to the latest versions to mitigate any known vulnerabilities that could be exploited by adversaries. +- Implement additional monitoring and alerting for any future attempts to execute the `kextunload` command, particularly targeting security-related kernel extensions. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational defenses need to be adjusted.""" [[rule.threat]] diff --git a/rules/macos/discovery_users_domain_built_in_commands.toml b/rules/macos/discovery_users_domain_built_in_commands.toml index bc38d1d3874..4e494cdbc57 100644 --- a/rules/macos/discovery_users_domain_built_in_commands.toml +++ b/rules/macos/discovery_users_domain_built_in_commands.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/12" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -75,6 +75,41 @@ process where host.os.type == "macos" and event.type in ("start", "process_start "/Applications/NoMAD.app/Contents/MacOS/NoMAD", "/Applications/ESET Management Agent.app/Contents/MacOS/ERAAgent") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Enumeration of Users or Groups via Built-in Commands + +Built-in macOS commands like `ldapsearch`, `dsmemberutil`, and `dscl` are essential for managing and querying user and group information. Adversaries exploit these to gather insights into system accounts and groups, aiding in lateral movement or privilege escalation. The detection rule identifies suspicious use of these commands, especially when executed from non-standard parent processes, excluding known legitimate applications, to flag potential misuse. + +### Possible investigation steps + +- Review the process details to identify the specific command executed, focusing on the process name and arguments, such as "ldapsearch", "dsmemberutil", or "dscl" with specific arguments like "read", "list", or "search". +- Examine the parent process information, including the executable path and name, to determine if the command was launched from a non-standard or suspicious parent process. +- Check the exclusion list of known legitimate applications to ensure the alert was not triggered by a benign process, such as those from QualysCloudAgent, Kaspersky, or ESET. +- Investigate the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates potential compromise or misuse. +- Correlate the event with other logs or alerts to identify any patterns of suspicious activity, such as repeated enumeration attempts or other discovery tactics. +- Assess the system's recent activity for signs of lateral movement or privilege escalation attempts that may follow the enumeration of users or groups. + +### False positive analysis + +- Security and management tools like QualysCloudAgent, Kaspersky Anti-Virus, and ESET Endpoint Security may trigger false positives due to their legitimate use of built-in commands for system monitoring. To mitigate this, add these applications to the exclusion list in the detection rule. +- Development environments such as Xcode might execute these commands during normal operations. If Xcode is frequently triggering alerts, consider excluding its executable path from the rule. +- VPN and network management applications like NordVPN and Zscaler may use these commands for network configuration and user management. Exclude these applications if they are known to be safe and frequently used in your environment. +- Parallels Desktop and similar virtualization software might access user and group information as part of their functionality. If these applications are trusted, add their executable paths to the exclusion list. +- Regular administrative tasks performed by IT personnel using NoMAD or similar tools can also cause false positives. Ensure these tools are excluded if they are part of routine operations. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, specifically those involving `ldapsearch`, `dsmemberutil`, or `dscl` commands executed from non-standard parent processes. +- Conduct a thorough review of user and group accounts on the affected system to identify any unauthorized changes or additions, and revert any suspicious modifications. +- Reset passwords for all user accounts on the affected system, prioritizing those with administrative privileges, to mitigate potential unauthorized access. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised. +- Implement additional monitoring on the affected system and network to detect any further unauthorized enumeration attempts or related suspicious activities. +- Review and update endpoint security configurations to ensure that legitimate applications are properly whitelisted and that unauthorized applications are blocked from executing enumeration commands.""" [[rule.threat]] diff --git a/rules/macos/execution_defense_evasion_electron_app_childproc_node_js.toml b/rules/macos/execution_defense_evasion_electron_app_childproc_node_js.toml index 37396801ec4..4da73c928c5 100644 --- a/rules/macos/execution_defense_evasion_electron_app_childproc_node_js.toml +++ b/rules/macos/execution_defense_evasion_electron_app_childproc_node_js.toml @@ -2,7 +2,7 @@ creation_date = "2020/01/07" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -62,6 +62,41 @@ type = "query" query = ''' event.category:process and host.os.type:macos and event.type:(start or process_started) and process.args:("-e" and const*require*child_process*) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Execution via Electron Child Process Node.js Module + +Electron applications, built on Node.js, can execute child processes using the `child_process` module, inheriting parent process permissions. Adversaries exploit this to execute unauthorized commands, bypassing security controls. The detection rule identifies suspicious process starts on macOS, focusing on command-line arguments indicative of such abuse, aiding in threat detection and mitigation. + +### Possible investigation steps + +- Review the process arguments captured in the alert to confirm the presence of suspicious patterns, such as the use of "-e" and the inclusion of "require('child_process')". +- Identify the parent Electron application process to determine if it is a legitimate application or potentially malicious. +- Check the user account associated with the process to assess if it has elevated privileges that could be exploited. +- Investigate the command executed by the child process to understand its purpose and potential impact on the system. +- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or patterns. +- Examine the network activity of the host around the time of the alert to detect any unauthorized data exfiltration or communication with known malicious IPs. + +### False positive analysis + +- Legitimate Electron applications may use the child_process module for valid operations, such as launching helper scripts or tools. Users should identify and whitelist these known applications to prevent unnecessary alerts. +- Development environments often execute scripts using child_process during testing or debugging. Exclude processes originating from development directories or environments to reduce false positives. +- Automated build or deployment tools running on macOS might invoke child processes as part of their workflow. Recognize and exclude these tools by their process names or paths. +- Some Electron-based applications might use command-line arguments that match the detection pattern for legitimate reasons. Review and adjust the detection rule to exclude these specific argument patterns when associated with trusted applications. +- Regularly review and update the exclusion list to accommodate new legitimate use cases as they arise, ensuring that the detection rule remains effective without generating excessive false positives. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized command execution and potential lateral movement. +- Terminate any suspicious child processes identified as being spawned by the Electron application to halt any ongoing malicious activity. +- Conduct a thorough review of the Electron application's code and configuration to identify and remove any unauthorized or malicious scripts or modules, particularly those involving the `child_process` module. +- Revoke and reset any credentials or tokens that may have been exposed or compromised due to the unauthorized execution, ensuring that new credentials are distributed securely. +- Apply security patches and updates to the Electron application and underlying Node.js environment to mitigate any known vulnerabilities that could be exploited in a similar manner. +- Enhance monitoring and logging on the affected system and similar environments to detect any future attempts to exploit the `child_process` module, focusing on command-line arguments and process creation events. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or data have been impacted, ensuring a comprehensive response to the threat.""" [[rule.threat]] diff --git a/rules/macos/execution_initial_access_suspicious_browser_childproc.toml b/rules/macos/execution_initial_access_suspicious_browser_childproc.toml index a0c384dc8ef..637fd295c85 100644 --- a/rules/macos/execution_initial_access_suspicious_browser_childproc.toml +++ b/rules/macos/execution_initial_access_suspicious_browser_childproc.toml @@ -2,7 +2,7 @@ creation_date = "2020/12/23" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -82,6 +82,41 @@ process where host.os.type == "macos" and event.type in ("start", "process_start "/usr/local/*brew*" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Browser Child Process + +Web browsers are integral to user interaction with the internet, often serving as gateways for adversaries to exploit vulnerabilities. Attackers may execute malicious scripts or commands by spawning child processes from browsers, leveraging scripting languages or command-line tools. The detection rule identifies unusual child processes initiated by browsers on macOS, filtering out known benign activities to highlight potential threats, thus aiding in early threat detection and response. + +### Possible investigation steps + +- Review the process command line to understand the context of the execution and identify any potentially malicious scripts or commands. +- Check the parent process name to confirm it is one of the specified browsers (e.g., Google Chrome, Safari) and verify if the browser was expected to be running at the time of the alert. +- Investigate the user account associated with the process to determine if the activity aligns with their typical behavior or if the account may have been compromised. +- Examine the network activity around the time of the alert to identify any suspicious connections or data transfers that may indicate further malicious activity. +- Look for any related alerts or logs that might provide additional context or evidence of a broader attack or compromise. +- Assess the risk and impact of the detected activity by considering the severity and risk score provided, and determine if immediate response actions are necessary. + +### False positive analysis + +- Legitimate software updates or installations may trigger the rule if they use shell scripts or command-line tools. Users can create exceptions for known update paths, such as those related to Microsoft AutoUpdate or Google Chrome installations, to prevent these from being flagged. +- Development or testing activities involving scripting languages like Python or shell scripts may be mistakenly identified as threats. Users should consider excluding specific development directories or command patterns that are frequently used in their workflows. +- Automated scripts or tools that interact with web browsers for legitimate purposes, such as web scraping or data collection, might be detected. Users can whitelist these processes by specifying their command-line arguments or paths to avoid false positives. +- System administration tasks that involve remote management or configuration changes via command-line tools could be misinterpreted as suspicious. Users should identify and exclude these routine administrative commands to reduce unnecessary alerts. +- Browser extensions or plugins that execute scripts for enhanced functionality might trigger the rule. Users should review and whitelist trusted extensions that are known to execute benign scripts. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent further malicious activity or lateral movement by the adversary. +- Terminate the suspicious child process identified in the alert to halt any ongoing malicious execution. +- Conduct a thorough review of the browser's recent activity and history to identify any potentially malicious websites or downloads that may have triggered the alert. +- Remove any malicious files or scripts that were executed by the suspicious child process to prevent further exploitation. +- Apply the latest security patches and updates to the affected browser and macOS system to mitigate known vulnerabilities that could be exploited. +- Monitor the system for any signs of persistence mechanisms or additional suspicious activity, ensuring that no backdoors or unauthorized access points remain. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected, ensuring a coordinated response.""" [[rule.threat]] diff --git a/rules/macos/execution_installer_package_spawned_network_event.toml b/rules/macos/execution_installer_package_spawned_network_event.toml index 2e53cc22289..d80066cf445 100644 --- a/rules/macos/execution_installer_package_spawned_network_event.toml +++ b/rules/macos/execution_installer_package_spawned_network_event.toml @@ -2,7 +2,7 @@ creation_date = "2021/02/23" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -72,6 +72,41 @@ sequence by host.id with maxspan=15s [process where host.os.type == "macos" and event.type == "start" and event.action == "exec" and process.parent.name : ("installer", "package_script_service") and process.name : ("bash", "sh", "zsh", "python", "osascript", "tclsh*")] by process.entity_id [network where host.os.type == "macos" and event.type == "start" and process.name : ("curl", "osascript", "wget", "python", "java", "ruby", "node")] by process.parent.entity_id ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 MacOS Installer Package Spawns Network Event + +MacOS installer packages, often with a .pkg extension, are used to distribute software. Adversaries exploit this by embedding scripts to execute additional commands or download malicious payloads. The detection rule identifies suspicious behavior by monitoring for installer packages spawning shell processes followed by network activity, indicating potential malicious activity. + +### Possible investigation steps + +- Review the process details to identify the parent process name and entity ID, focusing on processes like "installer" or "package_script_service" that initiated the suspicious activity. +- Examine the child process that was spawned, such as "bash", "sh", or "python", to determine the commands executed and assess if they align with typical installation behavior or appear malicious. +- Investigate the network activity associated with the suspicious process, particularly looking at processes like "curl" or "wget", to identify any external connections made and the destination IP addresses or domains. +- Check the timestamp and sequence of events to confirm if the network activity closely followed the process execution, indicating a potential download or data exfiltration attempt. +- Analyze any downloaded files or payloads for malicious content using threat intelligence tools or sandbox environments to determine their intent and potential impact. +- Correlate the findings with known threat actor tactics or campaigns, leveraging threat intelligence sources to assess if the activity matches any known patterns or indicators of compromise. + +### False positive analysis + +- Legitimate software installations may trigger this rule if they use scripts to configure network settings or download updates. Users can create exceptions for known safe software by whitelisting specific installer package names or hashes. +- System administrators often use scripts to automate software deployment and updates, which might involve network activity. To reduce false positives, exclude processes initiated by trusted administrative tools or scripts. +- Development environments on macOS might execute scripts that connect to the internet for dependencies or updates. Users can mitigate this by excluding processes associated with known development tools or environments. +- Some security tools or monitoring software may use scripts to perform network checks or updates. Identify and exclude these processes if they are verified as non-threatening. +- Frequent updates from trusted software vendors might trigger this rule. Users should maintain an updated list of trusted vendors and exclude their processes from triggering alerts. + +### Response and remediation + +- Isolate the affected MacOS system from the network immediately to prevent further malicious activity or data exfiltration. +- Terminate any suspicious processes identified in the alert, such as those initiated by the installer package, to halt ongoing malicious actions. +- Conduct a thorough review of the installed applications and remove any unauthorized or suspicious software, especially those with a .pkg extension. +- Restore the system from a known good backup if available, ensuring that the backup predates the installation of the malicious package. +- Update and patch the MacOS system and all installed applications to the latest versions to mitigate vulnerabilities that could be exploited by similar threats. +- Monitor network traffic for any signs of command and control communication or data exfiltration attempts, using the indicators identified in the alert. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] diff --git a/rules/macos/execution_script_via_automator_workflows.toml b/rules/macos/execution_script_via_automator_workflows.toml index 55faccc4136..d9b13b3205c 100644 --- a/rules/macos/execution_script_via_automator_workflows.toml +++ b/rules/macos/execution_script_via_automator_workflows.toml @@ -2,7 +2,7 @@ creation_date = "2020/12/23" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -59,6 +59,39 @@ sequence by host.id with maxspan=30s [process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name == "automator"] [network where host.os.type == "macos" and process.name:"com.apple.automator.runner"] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Automator Workflows Execution + +Automator, a macOS utility, allows users to automate repetitive tasks through workflows. Adversaries can exploit this by embedding malicious JavaScript for Automation (JXA) in custom workflows, executing harmful scripts. The detection rule identifies this threat by monitoring the Automator process and subsequent network activity, flagging potential misuse when these actions occur in quick succession. + +### Possible investigation steps + +- Review the process execution details for the Automator process on the affected host, focusing on the timestamp and user context to determine if the execution was expected or authorized. +- Examine the network activity associated with the com.apple.automator.runner process to identify any unusual or suspicious external connections, including destination IP addresses and domains. +- Check for any recent changes or additions to Automator workflows on the host, especially those containing JavaScript for Automation (JXA) code, to identify potential malicious modifications. +- Investigate the user account associated with the Automator process execution to determine if there are any signs of compromise or unauthorized access. +- Correlate the alert with other security events or logs from the same host around the same timeframe to identify any additional indicators of compromise or related suspicious activities. + +### False positive analysis + +- Legitimate Automator workflows: Users may have legitimate workflows that trigger network connections, such as automated data uploads or API calls. To handle these, identify and document known safe workflows and create exceptions for them in the detection rule. +- Frequent developer activity: Developers using Automator for testing or development purposes might frequently trigger this rule. Consider excluding specific user accounts or development environments from the rule to reduce noise. +- System maintenance tasks: Some system maintenance or administrative tasks might use Automator workflows that connect to the network. Review and whitelist these tasks if they are verified as non-threatening. +- Third-party applications: Certain third-party applications may use Automator workflows as part of their normal operation. Identify these applications and exclude their processes from the rule if they are deemed safe. + +### Response and remediation + +- Immediately isolate the affected macOS host from the network to prevent further malicious activity and potential lateral movement. +- Terminate the Automator process and any associated XPC services, such as "com.apple.automator.runner," to stop the execution of the malicious workflow. +- Conduct a thorough review of the affected system to identify and remove any malicious JavaScript for Automation (JXA) scripts or custom workflow templates that may have been dropped by the adversary. +- Restore the system from a known good backup if any unauthorized changes or persistent threats are detected that cannot be easily remediated. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected. +- Implement additional monitoring on the affected host and similar systems to detect any recurrence of suspicious Automator activity, focusing on process and network activity patterns. +- Update endpoint protection and intrusion detection systems to recognize and block similar threats in the future, leveraging the MITRE ATT&CK framework details for enhanced detection capabilities.""" [[rule.threat]] diff --git a/rules/macos/execution_scripting_osascript_exec_followed_by_netcon.toml b/rules/macos/execution_scripting_osascript_exec_followed_by_netcon.toml index d643bd904f1..798da4ac8b2 100644 --- a/rules/macos/execution_scripting_osascript_exec_followed_by_netcon.toml +++ b/rules/macos/execution_scripting_osascript_exec_followed_by_netcon.toml @@ -2,7 +2,7 @@ creation_date = "2020/12/07" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -67,6 +67,41 @@ sequence by host.id, process.entity_id with maxspan=30s "192.52.193.0/24", "192.168.0.0/16", "192.88.99.0/24", "224.0.0.0/4", "100.64.0.0/10", "192.175.48.0/24", "198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", "FF00::/8")] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Apple Script Execution followed by Network Connection + +AppleScript, a scripting language for macOS, automates tasks by controlling applications and system functions. Adversaries exploit it to execute scripts that establish unauthorized network connections, facilitating command and control activities. The detection rule identifies such abuse by monitoring the osascript process for script execution followed by network activity, excluding local and private IP ranges, within a short timeframe. + +### Possible investigation steps + +- Review the process details for the osascript execution event, focusing on the process.entity_id and host.id to understand the context of the script execution. +- Examine the network connection details associated with the osascript process, particularly the destination IP address, to determine if it is known or suspicious, and check if it falls outside the excluded IP ranges. +- Investigate the script content or command line arguments used in the osascript execution to identify any potentially malicious or unexpected behavior. +- Check the timeline of events to see if there are any other related or suspicious activities occurring on the same host around the time of the osascript execution and network connection. +- Correlate the osascript activity with any other alerts or logs from the same host to identify patterns or additional indicators of compromise. +- Assess the user account associated with the osascript process to determine if it is a legitimate user or if there are signs of account compromise. + +### False positive analysis + +- Legitimate automation scripts may trigger the rule if they execute osascript and establish network connections. Review the script's purpose and source to determine if it is authorized. +- System management tools that use AppleScript for remote administration can cause false positives. Identify these tools and consider creating exceptions for their known processes. +- Software updates or applications that use AppleScript for network communication might be flagged. Verify the application's legitimacy and update the rule to exclude these specific processes or IP addresses. +- Development environments that utilize AppleScript for testing or deployment may inadvertently match the rule. Ensure these environments are recognized and excluded from monitoring if they are trusted. +- Regularly review and update the list of excluded IP ranges and processes to ensure they reflect the current network and application landscape, minimizing unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected macOS host from the network to prevent further unauthorized access or data exfiltration. +- Terminate the osascript process identified in the alert to stop any ongoing malicious activity. +- Conduct a thorough review of the executed AppleScript to identify any malicious commands or payloads and remove any associated files or scripts from the system. +- Reset credentials for any accounts that were accessed or could have been compromised during the incident. +- Apply security patches and updates to the macOS system to address any vulnerabilities that may have been exploited. +- Monitor network traffic for any further suspicious activity originating from the affected host or similar patterns across other systems. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.""" [[rule.threat]] diff --git a/rules/macos/execution_shell_execution_via_apple_scripting.toml b/rules/macos/execution_shell_execution_via_apple_scripting.toml index c0c517e9ea0..fdb677c6d47 100644 --- a/rules/macos/execution_shell_execution_via_apple_scripting.toml +++ b/rules/macos/execution_shell_execution_via_apple_scripting.toml @@ -2,7 +2,7 @@ creation_date = "2020/12/07" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -61,6 +61,41 @@ sequence by host.id with maxspan=5s [process where host.os.type == "macos" and event.type in ("start", "process_started", "info") and process.name == "osascript" and process.args : "-e"] by process.entity_id [process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name : ("sh", "bash", "zsh") and process.args == "-c" and process.args : ("*curl*", "*pbcopy*", "*http*", "*chmod*")] by process.parent.entity_id ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Shell Execution via Apple Scripting + +AppleScript and JXA are scripting languages used in macOS to automate tasks and control applications. Adversaries exploit these by executing shell commands through functions like `doShellScript`, enabling unauthorized actions such as data exfiltration or system modification. The detection rule identifies suspicious shell processes initiated by AppleScript, focusing on specific command patterns and rapid sequence execution, indicating potential misuse. + +### Possible investigation steps + +- Review the alert details to identify the specific host.id and process.entity_id involved in the suspicious activity. +- Examine the process arguments for osascript to determine the exact AppleScript command executed, focusing on the presence of the "-e" flag which indicates script execution. +- Investigate the parent process of the shell (sh, bash, zsh) to understand the context in which the shell command was executed, using process.parent.entity_id for correlation. +- Analyze the shell command arguments, particularly looking for potentially malicious patterns such as "*curl*", "*pbcopy*", "*http*", or "*chmod*", which may indicate data exfiltration or system modification attempts. +- Check the sequence and timing of the processes to assess if the execution pattern aligns with typical user behavior or if it suggests automated or rapid execution indicative of a script. +- Correlate the findings with any other security alerts or logs from the same host to identify if this activity is part of a broader attack or isolated incident. +- If necessary, escalate the investigation by capturing additional forensic data from the affected host, such as network traffic or file system changes, to further understand the impact and scope of the activity. + +### False positive analysis + +- Routine administrative scripts may trigger the rule if they use AppleScript or JXA to automate tasks involving shell commands. To manage this, identify and whitelist these scripts by their specific command patterns or execution context. +- Software updates or legitimate application installations might execute shell commands through AppleScript, appearing suspicious. Monitor and document these activities, and create exceptions for known update processes. +- Development tools and environments that rely on scripting for building or testing applications can generate false positives. Exclude these processes by verifying their source and ensuring they align with expected development activities. +- User-initiated automation tasks, such as custom scripts for personal productivity, may be flagged. Educate users on safe scripting practices and establish a process for reviewing and approving such scripts to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected macOS host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious shell processes identified by the detection rule, specifically those initiated by `osascript` executing shell commands. +- Conduct a thorough review of the affected system's logs and process history to identify any additional unauthorized activities or persistence mechanisms. +- Remove any unauthorized scripts or files that were executed or created as part of the malicious activity. +- Reset credentials and review permissions for any accounts that may have been compromised or used in the attack. +- 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 similar patterns of behavior, focusing on the use of `osascript` and shell command execution, to prevent recurrence.""" [[rule.threat]] diff --git a/rules/macos/initial_access_suspicious_mac_ms_office_child_process.toml b/rules/macos/initial_access_suspicious_mac_ms_office_child_process.toml index c6fe7a360a3..f64f88d5407 100644 --- a/rules/macos/initial_access_suspicious_mac_ms_office_child_process.toml +++ b/rules/macos/initial_access_suspicious_mac_ms_office_child_process.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/04" integration = ["endpoint"] maturity = "production" -updated_date = "2024/11/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -124,6 +124,41 @@ process where event.action == "exec" and host.os.type == "macos" and "/usr/sbin/networksetup" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious macOS MS Office Child Process + +Microsoft Office applications on macOS can be exploited by adversaries to execute malicious child processes, often through malicious macros or document exploits. These child processes may include scripting languages or utilities that can be leveraged for unauthorized actions. The detection rule identifies such suspicious activity by monitoring for unexpected child processes spawned by Office apps, while filtering out known benign behaviors and false positives, thus helping to pinpoint potential threats. + +### Possible investigation steps + +- Review the parent process name and executable path to confirm if the Office application is legitimate and expected on the host. +- Examine the child process name and command line arguments to identify any potentially malicious or unexpected behavior, such as the use of scripting languages or network utilities like curl or nscurl. +- Check the process arguments for any indicators of compromise or suspicious patterns that are not filtered out by the rule, such as unexpected network connections or file modifications. +- Investigate the effective parent executable path to ensure it is not associated with known benign applications or services that are excluded by the rule. +- Correlate the alert with any recent phishing attempts or suspicious email activity that might have led to the execution of malicious macros or document exploits. +- Analyze the host's recent activity and system logs to identify any other anomalies or related alerts that could provide additional context or evidence of compromise. + +### False positive analysis + +- Product version discovery commands can trigger false positives. Exclude processes with arguments like "ProductVersion" and "ProductBuildVersion" to reduce noise. +- Office error reporting may cause alerts. Exclude paths related to Microsoft Error Reporting to prevent unnecessary alerts. +- Network setup and management tools such as "/usr/sbin/networksetup" can be benign. Exclude these executables if they are part of regular system operations. +- Third-party applications like ToDesk and JumpCloud Agent might be flagged. Exclude their executables if they are verified as safe and part of normal operations. +- Zotero integration can cause false positives with shell processes. Exclude specific command lines involving "$CFFIXED_USER_HOME/.zoteroIntegrationPipe" to avoid these alerts. + +### Response and remediation + +- Immediately isolate the affected macOS device from the network to prevent further malicious activity or lateral movement. +- Terminate any suspicious child processes identified by the alert, such as those involving scripting languages or utilities like curl, bash, or osascript. +- Conduct a thorough review of the parent Microsoft Office application and associated documents to identify and remove any malicious macros or document exploits. +- Restore the affected system from a known good backup if malicious activity has compromised system integrity or data. +- Update all Microsoft Office applications to the latest version to patch any known vulnerabilities that could be exploited by similar threats. +- Implement application whitelisting to restrict the execution of unauthorized scripts and utilities, reducing the risk of exploitation through Office applications. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] diff --git a/rules/macos/lateral_movement_credential_access_kerberos_bifrostconsole.toml b/rules/macos/lateral_movement_credential_access_kerberos_bifrostconsole.toml index 9013d41a7ab..fb586259560 100644 --- a/rules/macos/lateral_movement_credential_access_kerberos_bifrostconsole.toml +++ b/rules/macos/lateral_movement_credential_access_kerberos_bifrostconsole.toml @@ -2,7 +2,7 @@ creation_date = "2020/01/12" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -59,6 +59,40 @@ query = ''' event.category:process and host.os.type:macos and event.type:start and process.args:("-action" and ("-kerberoast" or askhash or asktgs or asktgt or s4u or ("-ticket" and ptt) or (dump and (tickets or keytab)))) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Kerberos Attack via Bifrost + +Kerberos is a network authentication protocol designed to provide secure identity verification for users and services. Adversaries exploit tools like Bifrost on macOS to extract Kerberos tickets or perform unauthorized authentications, such as pass-the-ticket attacks. The detection rule identifies suspicious process activities linked to Bifrost's known attack methods, focusing on specific command-line arguments indicative of credential access and lateral movement attempts. + +### Possible investigation steps + +- Review the process start event details to identify the specific command-line arguments used, focusing on those that match the suspicious patterns such as "-action", "-kerberoast", "askhash", "asktgs", "asktgt", "s4u", "-ticket ptt", or "dump tickets/keytab". +- Correlate the process execution with user activity logs to determine if the process was initiated by a legitimate user or an unauthorized account. +- Check for any recent changes in user permissions or group memberships that could indicate privilege escalation attempts. +- Investigate the source and destination of any network connections made by the process to identify potential lateral movement or data exfiltration. +- Analyze historical data for similar process executions or patterns to assess if this is an isolated incident or part of a broader attack campaign. +- Review endpoint security logs for any additional indicators of compromise or related suspicious activities around the time of the alert. + +### False positive analysis + +- Legitimate administrative tasks on macOS systems may trigger the rule if they involve Kerberos ticket management. To handle this, identify and document routine administrative processes that use similar command-line arguments and create exceptions for these specific activities. +- Security tools or scripts designed for Kerberos ticket management or testing may mimic Bifrost's behavior. Review and whitelist these tools if they are part of authorized security assessments or IT operations. +- Automated system processes that interact with Kerberos for legitimate authentication purposes might be flagged. Monitor these processes and exclude them from the rule if they are verified as non-threatening and essential for system operations. +- Developers or IT personnel testing Kerberos configurations in a controlled environment could inadvertently trigger the rule. Ensure that such environments are well-documented and excluded from monitoring to prevent false positives. + +### Response and remediation + +- Immediately isolate the affected macOS host from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified by the detection rule, particularly those involving Bifrost command-line arguments. +- Conduct a thorough review of Kerberos ticket logs and authentication attempts to identify any unauthorized access or anomalies. +- Revoke and reissue Kerberos tickets for affected users and services to ensure no compromised tickets are in use. +- Update and patch the macOS system and any related software to mitigate vulnerabilities that may have been exploited. +- Implement enhanced monitoring for Kerberos-related activities, focusing on unusual patterns or command-line arguments similar to those used by Bifrost. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.""" [[rule.threat]] diff --git a/rules/macos/lateral_movement_mounting_smb_share.toml b/rules/macos/lateral_movement_mounting_smb_share.toml index 567c47b2457..f2f6e0a55dc 100644 --- a/rules/macos/lateral_movement_mounting_smb_share.toml +++ b/rules/macos/lateral_movement_mounting_smb_share.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/25" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -64,6 +64,40 @@ process where host.os.type == "macos" and event.type in ("start", "process_start ) and not process.parent.executable : "/Applications/Google Drive.app/Contents/MacOS/Google Drive" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Attempt to Mount SMB Share via Command Line + +SMB (Server Message Block) is a protocol used for network file sharing, allowing applications to read and write to files and request services from server programs in a computer network. Adversaries exploit SMB to move laterally within a network by accessing shared resources using valid credentials. The detection rule identifies suspicious command-line activities on macOS, such as using built-in commands to mount SMB shares, which may indicate unauthorized access attempts. It filters out benign processes, like those from Google Drive, to reduce false positives, focusing on potential threats. + +### Possible investigation steps + +- Review the process details to confirm the execution of commands like "mount_smbfs", "open", "mount", or "osascript" with arguments indicating an attempt to mount an SMB share. +- Check the user account associated with the process to determine if it is a valid and authorized user for accessing SMB shares. +- Investigate the source and destination IP addresses involved in the SMB connection attempt to identify if they are known and trusted within the network. +- Examine the parent process of the suspicious activity to understand the context and origin of the command execution, ensuring it is not a benign process like Google Drive. +- Look for any other related alerts or logs that might indicate lateral movement or unauthorized access attempts within the network. +- Assess the risk and impact of the activity by correlating it with other security events or incidents involving the same user or system. + +### False positive analysis + +- Google Drive operations can trigger this rule due to its use of SMB for file synchronization. To manage this, exclude processes originating from the Google Drive application by using the provided exception for its executable path. +- Legitimate user activities involving manual mounting of SMB shares for accessing network resources may be flagged. To handle this, identify and whitelist specific user accounts or devices that regularly perform these actions as part of their normal workflow. +- Automated backup solutions that utilize SMB for network storage access might be detected. Review and exclude these processes by identifying their specific command-line patterns or parent processes. +- Development or testing environments where SMB shares are frequently mounted for application testing can cause alerts. Implement exceptions for these environments by specifying known IP addresses or hostnames associated with the test servers. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent further lateral movement by the adversary. +- Verify the credentials used in the SMB mount attempt to determine if they have been compromised. Reset passwords and revoke access if necessary. +- Conduct a thorough review of recent login activities and access logs on the affected system and any connected SMB shares to identify unauthorized access or data exfiltration. +- Remove any unauthorized SMB mounts and ensure that no persistent connections remain active. +- Update and patch the macOS system and any related software to mitigate known vulnerabilities that could be exploited for lateral movement. +- Enhance monitoring and logging on the network to detect future unauthorized SMB mount attempts, focusing on the specific command-line patterns identified in the alert. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on the broader network infrastructure.""" [[rule.threat]] diff --git a/rules/macos/lateral_movement_remote_ssh_login_enabled.toml b/rules/macos/lateral_movement_remote_ssh_login_enabled.toml index c312d9699ad..d9dbf21089b 100644 --- a/rules/macos/lateral_movement_remote_ssh_login_enabled.toml +++ b/rules/macos/lateral_movement_remote_ssh_login_enabled.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/18" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -61,6 +61,39 @@ event.category:process and host.os.type:macos and event.type:(start or process_s process.args:("-setremotelogin" and on) and not process.parent.executable : /usr/local/jamf/bin/jamf ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 SSH Login Enabled via systemsetup Command + +The `systemsetup` command in macOS is a utility that allows administrators to configure system settings, including enabling remote SSH login, which facilitates remote management and access. Adversaries may exploit this to gain unauthorized access and move laterally within a network. The detection rule identifies suspicious use of `systemsetup` to enable SSH, excluding legitimate administrative tools, by monitoring process execution patterns and arguments. + +### Possible investigation steps + +- Review the process execution details to confirm the use of the systemsetup command with the arguments "-setremotelogin" and "on" to ensure the alert is not a false positive. +- Check the parent process of the systemsetup command to identify if it was executed by a known administrative tool or script, excluding /usr/local/jamf/bin/jamf as per the rule. +- Investigate the user account associated with the process execution to determine if it is a legitimate administrator or a potentially compromised account. +- Examine recent login events and SSH access logs on the host to identify any unauthorized access attempts or successful logins following the enabling of remote SSH login. +- Correlate this event with other security alerts or logs from the same host or network segment to identify potential lateral movement or further malicious activity. + +### False positive analysis + +- Legitimate administrative tools like Jamf may trigger this rule when enabling SSH for authorized management purposes. To handle this, ensure that the process parent executable path for Jamf is correctly excluded in the detection rule. +- Automated scripts used for system configuration and maintenance might enable SSH as part of their routine operations. Review these scripts and, if verified as safe, add their parent process paths to the exclusion list. +- IT support activities that require temporary SSH access for troubleshooting can also cause false positives. Document these activities and consider scheduling them during known maintenance windows to reduce alerts. +- Security software or management tools that periodically check or modify system settings could inadvertently trigger this rule. Identify these tools and exclude their specific process paths if they are confirmed to be non-threatening. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious or unauthorized SSH sessions that are currently active on the affected system. +- Review and revoke any unauthorized SSH keys or credentials that may have been added to the system. +- Conduct a thorough examination of the system logs to identify any additional unauthorized activities or changes made by the adversary. +- Restore the system to a known good state from a backup taken before the unauthorized SSH access was enabled, if possible. +- Implement network segmentation to limit SSH access to only trusted administrative systems and users. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.""" [[rule.threat]] diff --git a/rules/macos/lateral_movement_vpn_connection_attempt.toml b/rules/macos/lateral_movement_vpn_connection_attempt.toml index 6388074a40d..70d1cff6132 100644 --- a/rules/macos/lateral_movement_vpn_connection_attempt.toml +++ b/rules/macos/lateral_movement_vpn_connection_attempt.toml @@ -2,7 +2,7 @@ creation_date = "2020/01/25" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -66,6 +66,40 @@ process where host.os.type == "macos" and event.type in ("start", "process_start (process.name : "osascript" and process.command_line : "osascript*set VPN to service*") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Virtual Private Network Connection Attempt + +Virtual Private Networks (VPNs) are used to securely connect to remote networks, encrypting data and masking IP addresses. Adversaries may exploit VPNs to move laterally within a network, gaining unauthorized access to systems. The detection rule identifies suspicious VPN connection attempts on macOS by monitoring specific command executions, helping to flag potential misuse for further investigation. + +### Possible investigation steps + +- Review the process details to confirm the legitimacy of the VPN connection attempt by examining the process name and arguments, such as "networksetup" with "-connectpppoeservice", "scutil" with "--nc start", or "osascript" with "osascript*set VPN to service*". +- Check the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Investigate the source IP address and destination network to assess if the connection is to a known and trusted network or if it is unusual for the environment. +- Analyze historical data for similar VPN connection attempts from the same user or device to identify patterns or repeated unauthorized access attempts. +- Correlate the VPN connection attempt with other security events or alerts to identify potential lateral movement or further malicious activity within the network. + +### False positive analysis + +- Legitimate VPN usage by IT staff or network administrators may trigger the rule. To manage this, create exceptions for known user accounts or specific times when VPN maintenance is scheduled. +- Automated scripts or applications that use macOS built-in commands for VPN connections can cause false positives. Identify these scripts and whitelist their process names or command lines. +- Frequent VPN connections from trusted devices or IP addresses might be flagged. Exclude these devices or IPs from the rule to reduce noise. +- Users who frequently travel and connect to corporate networks via VPN may trigger alerts. Consider excluding these users or implementing a separate monitoring strategy for their activities. +- Regularly review and update the exclusion list to ensure it reflects current network policies and user behaviors, minimizing unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected macOS device from the network to prevent further lateral movement by the adversary. +- Terminate any suspicious VPN connections identified by the detection rule to cut off unauthorized access. +- Conduct a thorough review of the affected system's VPN configuration and logs to identify any unauthorized changes or connections. +- Reset credentials and update authentication methods for VPN access to ensure that compromised credentials are not reused. +- Escalate the incident to the security operations center (SOC) for further analysis and to determine if other systems have been affected. +- Implement additional monitoring on the network for unusual VPN connection attempts or related suspicious activities to enhance detection capabilities. +- Review and update VPN access policies to ensure they align with current security best practices and limit access to only necessary users and systems.""" [[rule.threat]] diff --git a/rules/macos/persistence_account_creation_hide_at_logon.toml b/rules/macos/persistence_account_creation_hide_at_logon.toml index 88551bdc5f7..02aa30b4b6e 100644 --- a/rules/macos/persistence_account_creation_hide_at_logon.toml +++ b/rules/macos/persistence_account_creation_hide_at_logon.toml @@ -2,7 +2,7 @@ creation_date = "2020/01/05" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -58,6 +58,40 @@ query = ''' event.category:process and host.os.type:macos and event.type:(start or process_started) and process.name:dscl and process.args:(IsHidden and create and (true or 1 or yes)) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Hidden Local User Account Creation + +In macOS environments, the `dscl` command-line utility manages directory services, including user accounts. Adversaries may exploit this to create hidden local accounts, evading detection while maintaining persistence. The detection rule monitors for `dscl` processes attempting to set accounts as hidden, flagging suspicious activity indicative of potential misuse. + +### Possible investigation steps + +- Review the process details to confirm the presence of the `dscl` command with arguments related to account creation and hiding, specifically checking for `IsHidden`, `create`, and values like `true`, `1`, or `yes`. +- Identify the user account under which the `dscl` command was executed to determine if it was initiated by an authorized user or a potential adversary. +- Check the system logs for any additional suspicious activity around the time the `dscl` command was executed, such as other unauthorized account modifications or unusual login attempts. +- Investigate the newly created account details, if available, to assess its purpose and legitimacy, including checking for any associated files or processes that might indicate malicious intent. +- Correlate the event with other security alerts or anomalies on the host to determine if this activity is part of a broader attack pattern or isolated incident. + +### False positive analysis + +- System administrators may use the dscl command to create hidden accounts for legitimate purposes such as maintenance or automated tasks. To manage this, create exceptions for known administrator accounts or scripts that regularly perform these actions. +- Some third-party applications or management tools might use hidden accounts for functionality or security purposes. Identify these applications and whitelist their processes to prevent unnecessary alerts. +- During system setup or configuration, hidden accounts might be created as part of the initial setup process. Exclude these initial setup activities by correlating them with known installation or configuration events. +- Regular audits of user accounts and their creation processes can help distinguish between legitimate and suspicious account creation activities, allowing for more informed exception handling. +- If a specific user or group frequently triggers this rule due to their role, consider creating a role-based exception to reduce noise while maintaining security oversight. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or data exfiltration by the adversary. +- Use administrative privileges to review and remove any unauthorized hidden user accounts created using the `dscl` command. Ensure that legitimate accounts are not affected. +- Change passwords for all local accounts on the affected system to prevent unauthorized access using potentially compromised credentials. +- Conduct a thorough review of system logs and security alerts to identify any additional suspicious activities or indicators of compromise related to the hidden account creation. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign. +- Implement enhanced monitoring for `dscl` command usage across all macOS systems in the environment to detect and respond to similar threats promptly. +- Update and reinforce endpoint security measures, such as ensuring all systems have the latest security patches and antivirus definitions, to prevent exploitation of known vulnerabilities.""" [[rule.threat]] diff --git a/rules/macos/persistence_creation_change_launch_agents_file.toml b/rules/macos/persistence_creation_change_launch_agents_file.toml index 043c9618c04..04cf4141e09 100644 --- a/rules/macos/persistence_creation_change_launch_agents_file.toml +++ b/rules/macos/persistence_creation_change_launch_agents_file.toml @@ -2,7 +2,7 @@ creation_date = "2020/12/07" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -63,6 +63,40 @@ sequence by host.id with maxspan=1m ] [process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name == "launchctl" and process.args == "load"] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Launch Agent Creation or Modification and Immediate Loading + +Launch Agents in macOS are used to execute scripts or applications automatically at user login, providing a mechanism for persistence. Adversaries exploit this by creating or modifying Launch Agents to execute malicious payloads. The detection rule identifies such activities by monitoring file changes in Launch Agent directories and subsequent immediate loading via `launchctl`, indicating potential unauthorized persistence attempts. + +### Possible investigation steps + +- Review the file path where the modification or creation of the Launch Agent occurred to determine if it is in a system directory (e.g., /System/Library/LaunchAgents/) or a user directory (e.g., /Users/*/Library/LaunchAgents/). This can help assess the potential impact and scope of the change. +- Examine the contents of the newly created or modified plist file to identify the script or application it is configured to execute. Look for any suspicious or unexpected entries that could indicate malicious activity. +- Check the timestamp of the file modification event to correlate it with any known user activities or other system events that might explain the change. +- Investigate the process execution details of the launchctl command, including the user account under which it was executed and any associated parent processes, to determine if it aligns with legitimate administrative actions or if it appears suspicious. +- Search for any additional related alerts or logs around the same timeframe that might indicate further malicious behavior or corroborate the persistence attempt, such as other process executions or network connections initiated by the suspicious process. + +### False positive analysis + +- System or application updates may create or modify Launch Agents as part of their installation or update process. Users can create exceptions for known and trusted applications by whitelisting their specific file paths or process names. +- User-installed applications that require background processes might use Launch Agents for legitimate purposes. Identify these applications and exclude their associated Launch Agent paths from monitoring. +- Administrative scripts or tools used by IT departments for system management might trigger this rule. Coordinate with IT to document these scripts and exclude their activities from detection. +- Development tools or environments that automatically configure Launch Agents for testing purposes can cause false positives. Developers should be aware of these activities and can exclude their specific development directories. +- Backup or synchronization software that uses Launch Agents to schedule tasks may be flagged. Verify these applications and exclude their Launch Agent paths if they are deemed safe. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent further malicious activity or lateral movement. +- Terminate any suspicious processes associated with the unauthorized Launch Agent using Activity Monitor or the `kill` command in Terminal. +- Remove the malicious Launch Agent plist file from the affected directories: `/System/Library/LaunchAgents/`, `/Library/LaunchAgents/`, or `/Users/*/Library/LaunchAgents/`. +- Review and restore any system or application settings that may have been altered by the malicious Launch Agent. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes. +- Monitor the system for any signs of re-infection or further unauthorized changes to Launch Agents, ensuring that logging and alerting are configured to detect similar activities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/macos/persistence_creation_hidden_login_item_osascript.toml b/rules/macos/persistence_creation_hidden_login_item_osascript.toml index 1b48ca3d708..a7b73e789bc 100644 --- a/rules/macos/persistence_creation_hidden_login_item_osascript.toml +++ b/rules/macos/persistence_creation_hidden_login_item_osascript.toml @@ -2,7 +2,7 @@ creation_date = "2020/01/05" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -58,6 +58,40 @@ query = ''' process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name : "osascript" and process.command_line : "osascript*login item*hidden:true*" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Creation of Hidden Login Item via Apple Script + +AppleScript is a scripting language for automating tasks on macOS, including managing login items. Adversaries exploit this by creating hidden login items to maintain persistence without detection. The detection rule identifies suspicious use of `osascript` to create such items, focusing on command patterns that specify hidden attributes, thus flagging potential stealthy persistence attempts. + +### Possible investigation steps + +- Review the process details to confirm the presence of 'osascript' in the command line, specifically looking for patterns like "login item" and "hidden:true" to verify the alert's accuracy. +- Investigate the parent process of the 'osascript' execution to determine if it was initiated by a legitimate application or a potentially malicious source. +- Check the user account associated with the process to assess whether the activity aligns with typical user behavior or if it suggests unauthorized access. +- Examine recent login items and system logs to identify any new or unusual entries that could indicate persistence mechanisms being established. +- Correlate the event with other security alerts or logs from the same host to identify any related suspicious activities or patterns. +- If possible, retrieve and analyze the AppleScript code executed to understand its purpose and potential impact on the system. + +### False positive analysis + +- Legitimate applications or scripts that automate login item management may trigger this rule. Review the process command line details to verify if the application is trusted. +- System administrators or IT management tools might use AppleScript for legitimate configuration tasks. Confirm if the activity aligns with scheduled maintenance or deployment activities. +- Users with advanced scripting knowledge might create custom scripts for personal use. Check if the script is part of a known user workflow and consider excluding it if verified as non-threatening. +- Frequent triggers from the same source could indicate a benign automation process. Implement exceptions for specific scripts or processes after thorough validation to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or data exfiltration. +- Terminate the suspicious osascript process identified in the alert to halt any ongoing malicious activity. +- Remove the hidden login item created by the osascript to eliminate the persistence mechanism. This can be done by accessing the user's login items and deleting any unauthorized entries. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes. +- Review system logs and the user's recent activity to identify any other signs of compromise or related suspicious behavior. +- 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 enhanced monitoring for osascript usage and login item modifications across the network to detect similar threats in the future.""" [[rule.threat]] diff --git a/rules/macos/persistence_creation_modif_launch_deamon_sequence.toml b/rules/macos/persistence_creation_modif_launch_deamon_sequence.toml index 0c3009d0cc4..d85e84512f1 100644 --- a/rules/macos/persistence_creation_modif_launch_deamon_sequence.toml +++ b/rules/macos/persistence_creation_modif_launch_deamon_sequence.toml @@ -2,7 +2,7 @@ creation_date = "2020/12/07" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -61,6 +61,41 @@ sequence by host.id with maxspan=1m [file where host.os.type == "macos" and event.type != "deletion" and file.path : ("/System/Library/LaunchDaemons/*", "/Library/LaunchDaemons/*")] [process where host.os.type == "macos" and event.type in ("start", "process_started") and process.name == "launchctl" and process.args == "load"] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 LaunchDaemon Creation or Modification and Immediate Loading + +LaunchDaemons in macOS are system-level services that start at boot and run in the background, often used for legitimate system tasks. However, adversaries can exploit this by creating or modifying LaunchDaemons to ensure persistent execution of malicious payloads. The detection rule identifies such activities by monitoring for new or altered LaunchDaemon files followed by their immediate loading using `launchctl`, indicating potential misuse for persistence. + +### Possible investigation steps + +- Review the file path of the newly created or modified LaunchDaemon to determine if it is located in a legitimate system directory such as /System/Library/LaunchDaemons/ or /Library/LaunchDaemons/. +- Examine the contents of the LaunchDaemon file to identify any suspicious or unexpected configurations or scripts that may indicate malicious intent. +- Investigate the process execution details of the launchctl command, including the user account that initiated it, to assess whether it aligns with expected administrative activities. +- Check the timestamp of the LaunchDaemon file creation or modification against known system updates or legitimate software installations to rule out false positives. +- Correlate the event with other security alerts or logs from the same host to identify any additional indicators of compromise or related malicious activities. +- Consult threat intelligence sources to determine if the identified LaunchDaemon or associated scripts are known to be used by specific threat actors or malware campaigns. + +### False positive analysis + +- System updates or software installations may create or modify LaunchDaemons as part of legitimate processes. Users can monitor the timing of these activities and correlate them with known update schedules to identify benign occurrences. +- Some third-party applications may use LaunchDaemons for legitimate background tasks. Users should maintain a list of trusted applications and their associated LaunchDaemons to quickly identify and exclude these from alerts. +- Administrative scripts or IT management tools might use launchctl to load LaunchDaemons for system management purposes. Users can create exceptions for known management tools by specifying their process names or paths in the monitoring system. +- Regular system maintenance tasks might involve the creation or modification of LaunchDaemons. Users should document routine maintenance activities and adjust monitoring rules to exclude these known tasks. +- Users can implement a baseline of normal LaunchDaemon activity on their systems to distinguish between expected and unexpected changes, allowing for more accurate identification of false positives. + +### Response and remediation + +- Immediately isolate the affected macOS host from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes associated with the newly created or modified LaunchDaemon using the `launchctl` command to unload the daemon. +- Review and remove any unauthorized or suspicious LaunchDaemon files from the directories `/System/Library/LaunchDaemons/` and `/Library/LaunchDaemons/`. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious payloads. +- Restore any altered system files or configurations from a known good backup to ensure system integrity. +- 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 enhanced monitoring and logging for LaunchDaemon activities and `launchctl` usage to detect similar threats in the future.""" [[rule.threat]] diff --git a/rules/macos/persistence_credential_access_authorization_plugin_creation.toml b/rules/macos/persistence_credential_access_authorization_plugin_creation.toml index 86b2ab22a1b..077c52f5f3b 100644 --- a/rules/macos/persistence_credential_access_authorization_plugin_creation.toml +++ b/rules/macos/persistence_credential_access_authorization_plugin_creation.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/13" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -64,6 +64,40 @@ event.category:file and host.os.type:macos and not event.type:deletion and not (/Library/Security/SecurityAgentPlugins/KandjiPassport.bundle/* or /Library/Security/SecurityAgentPlugins/TeamViewerAuthPlugin.bundle/*)) and not (process.name:shove and process.code_signature.trusted:true) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Authorization Plugin Modification + +Authorization plugins in macOS extend authentication capabilities, enabling features like third-party multi-factor authentication. Adversaries may exploit these plugins to maintain persistence or capture credentials by modifying or adding unauthorized plugins. The detection rule identifies suspicious modifications by monitoring changes in specific plugin directories, excluding known legitimate plugins and trusted processes, thus highlighting potential unauthorized activities. + +### Possible investigation steps + +- Review the file path of the modified plugin to determine if it is located in the /Library/Security/SecurityAgentPlugins/ directory and verify if it is not among the known legitimate plugins like KandjiPassport.bundle or TeamViewerAuthPlugin.bundle. +- Examine the process name associated with the modification event to ensure it is not 'shove' with a trusted code signature, as these are excluded from the detection rule. +- Investigate the history of the modified plugin file to identify when it was created or last modified and by which user or process, to assess if the change aligns with expected administrative activities. +- Check for any recent user logon events that might correlate with the timing of the plugin modification to identify potential unauthorized access attempts. +- Analyze any associated network activity or connections from the host around the time of the modification to detect possible data exfiltration or communication with external command and control servers. +- Review system logs for any other suspicious activities or anomalies that occurred around the same time as the plugin modification to gather additional context on the potential threat. + +### False positive analysis + +- Known legitimate plugins such as KandjiPassport.bundle and TeamViewerAuthPlugin.bundle may trigger alerts if they are updated or modified. Users can handle these by ensuring these plugins are included in the exclusion list within the detection rule. +- Trusted processes like those signed by a verified code signature, such as the process named 'shove', might be flagged if they interact with the plugin directories. Users should verify the code signature and add these processes to the trusted list to prevent false positives. +- System updates or legitimate software installations may cause temporary changes in the plugin directories. Users should monitor for these events and temporarily adjust the detection rule to exclude these known activities during the update period. +- Custom or in-house developed plugins that are not widely recognized may be flagged. Users should ensure these plugins are properly documented and added to the exclusion list if they are verified as safe and necessary for business operations. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or further unauthorized access. +- Review and terminate any suspicious processes associated with unauthorized plugins, especially those not signed by a trusted code signature. +- Remove any unauthorized or suspicious plugins from the /Library/Security/SecurityAgentPlugins/ directory to eliminate persistence mechanisms. +- Conduct a thorough credential audit for any accounts that may have been compromised, and enforce a password reset for affected users. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement additional monitoring on the affected system and similar endpoints to detect any further unauthorized plugin modifications. +- Review and update security policies to ensure only authorized personnel can modify or add authorization plugins, and consider implementing stricter access controls.""" [[rule.threat]] diff --git a/rules/macos/persistence_crontab_creation.toml b/rules/macos/persistence_crontab_creation.toml index b8396765b58..25ef125f347 100644 --- a/rules/macos/persistence_crontab_creation.toml +++ b/rules/macos/persistence_crontab_creation.toml @@ -2,7 +2,7 @@ creation_date = "2022/04/25" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -61,6 +61,40 @@ query = ''' file where host.os.type == "macos" and event.type != "deletion" and process.name != null and file.path : "/private/var/at/tabs/*" and not process.executable == "/usr/bin/crontab" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious CronTab Creation or Modification + +Cron is a time-based job scheduler in Unix-like operating systems, including macOS, used to automate repetitive tasks. Adversaries may exploit cron to maintain persistence by scheduling malicious scripts or commands. The detection rule identifies unusual crontab modifications by non-standard processes, flagging potential misuse by threat actors seeking to establish persistence. + +### Possible investigation steps + +- Review the process name and executable path that triggered the alert to determine if it is a known legitimate application or a potentially malicious one. +- Examine the file path "/private/var/at/tabs/*" to identify any recent changes or additions to crontab entries that could indicate unauthorized scheduling of tasks. +- Investigate the user account associated with the process to determine if it has a history of legitimate crontab modifications or if it might be compromised. +- Check for any related alerts or logs around the same timeframe that might indicate additional suspicious activity or corroborate the use of cron for persistence. +- Analyze the command or script scheduled in the crontab entry to assess its purpose and potential impact on the system, looking for signs of malicious intent. + +### False positive analysis + +- System maintenance scripts or legitimate administrative tools may modify crontabs using non-standard processes. Review the process name and executable path to determine if the activity is part of routine maintenance. +- Development or testing environments might use scripts or automation tools that modify crontabs for legitimate purposes. Identify and document these processes to create exceptions in the detection rule. +- Some third-party applications may use cron jobs for updates or scheduled tasks. Verify the legitimacy of these applications and consider excluding their processes if they are known and trusted. +- User-initiated scripts that automate personal tasks could trigger this rule. Educate users on the implications of using cron for personal automation and establish a process for approving such scripts. +- Regularly review and update the list of excluded processes to ensure that only verified and non-threatening activities are exempt from detection. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or further execution of malicious tasks. +- Terminate any suspicious processes identified as modifying the crontab, especially those not typically associated with crontab modifications, such as python or osascript. +- Review and remove any unauthorized or suspicious entries in the crontab file located at /private/var/at/tabs/* to eliminate persistence mechanisms established by the threat actor. +- 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 malicious scripts. +- Restore the system from a known good backup if the integrity of the system is in question and ensure all security patches and updates are applied. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for crontab modifications and related processes to detect and respond to similar threats in the future.""" [[rule.threat]] diff --git a/rules/macos/persistence_defense_evasion_hidden_launch_agent_deamon_logonitem_process.toml b/rules/macos/persistence_defense_evasion_hidden_launch_agent_deamon_logonitem_process.toml index 66941650995..aea47236444 100644 --- a/rules/macos/persistence_defense_evasion_hidden_launch_agent_deamon_logonitem_process.toml +++ b/rules/macos/persistence_defense_evasion_hidden_launch_agent_deamon_logonitem_process.toml @@ -2,7 +2,7 @@ creation_date = "2020/01/07" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -63,6 +63,41 @@ query = ''' event.category:process and host.os.type:macos and event.type:(start or process_started) and process.name:.* and process.parent.executable:/sbin/launchd ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Hidden Child Process of Launchd + +Launchd is a key macOS system process responsible for managing system and user services. Adversaries may exploit it by creating hidden child processes to maintain persistence or evade defenses. The detection rule identifies unusual child processes of launchd, focusing on hidden files, which are often indicative of malicious activity. By monitoring process initiation events, it helps uncover potential threats linked to persistence and defense evasion tactics. + +### Possible investigation steps + +- Review the process details to identify the hidden child process, focusing on the process.name field to determine if it matches known malicious patterns or unusual names. +- Examine the process.parent.executable field to confirm that the parent process is indeed /sbin/launchd, ensuring the alert is not a false positive. +- Investigate the file path and attributes of the hidden file associated with the child process to determine its origin and legitimacy. +- Check the user account associated with the process initiation event to assess if it aligns with expected user behavior or if it indicates potential compromise. +- Correlate the event with other recent process initiation events on the same host to identify any patterns or additional suspicious activities. +- Review system logs and other security alerts for the host to gather more context on the potential threat and assess the scope of the activity. + +### False positive analysis + +- System updates or legitimate software installations may trigger hidden child processes of launchd. Users can create exceptions for known update processes or trusted software installations to prevent unnecessary alerts. +- Some legitimate applications may use hidden files for configuration or temporary data storage, which could be misidentified as suspicious. Users should identify these applications and whitelist their processes to reduce false positives. +- Development tools or scripts that run as background processes might appear as hidden child processes. Developers can exclude these tools by specifying their process names or paths in the detection rule exceptions. +- Automated backup or synchronization services might create hidden files as part of their normal operation. Users should verify these services and add them to an exclusion list if they are deemed safe. +- Custom scripts or automation tasks scheduled to run at login could be flagged. Users should review these scripts and, if legitimate, configure the rule to ignore these specific processes. + +### Response and remediation + +- Isolate the affected macOS system from the network to prevent further spread or communication with potential command and control servers. +- Terminate the suspicious hidden child process of launchd to stop any ongoing malicious activity. +- Conduct a thorough review of all launch agents, daemons, and logon items on the affected system to identify and remove any unauthorized or malicious entries. +- Restore the system from a known good backup if available, ensuring that the backup predates the initial compromise. +- Update the macOS system and all installed applications to the latest versions to patch any vulnerabilities that may have been exploited. +- Monitor the system for any signs of re-infection or further suspicious activity, focusing on process initiation events and hidden files. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected.""" [[rule.threat]] diff --git a/rules/macos/persistence_directory_services_plugins_modification.toml b/rules/macos/persistence_directory_services_plugins_modification.toml index 6212dfc742d..1fc57c0777b 100644 --- a/rules/macos/persistence_directory_services_plugins_modification.toml +++ b/rules/macos/persistence_directory_services_plugins_modification.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/13" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -59,6 +59,40 @@ query = ''' event.category:file and host.os.type:macos and not event.type:deletion and file.path:/Library/DirectoryServices/PlugIns/*.dsplug ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Persistence via DirectoryService Plugin Modification + +DirectoryService PlugIns on macOS are integral for managing directory-based services, automatically executing on system boot. Adversaries exploit this by modifying or creating malicious plugins to ensure persistent access. The detection rule identifies suspicious activity by monitoring non-deletion events involving dsplug files in the PlugIns directory, flagging potential unauthorized modifications indicative of persistence tactics. + +### Possible investigation steps + +- Review the alert details to confirm the file path matches /Library/DirectoryServices/PlugIns/*.dsplug, indicating a potential unauthorized modification or creation of a DirectoryService plugin. +- Check the file creation or modification timestamp to determine when the suspicious activity occurred and correlate it with other system events or user activities around that time. +- Investigate the file's origin by examining the file's metadata, such as the creator or modifying user, and cross-reference with known user accounts and their typical behavior. +- Analyze the contents of the modified or newly created dsplug file to identify any malicious code or unusual configurations that could indicate adversarial activity. +- Review system logs and other security alerts around the time of the event to identify any related suspicious activities or patterns that could suggest a broader compromise. +- Assess the risk and impact of the modification by determining if the plugin is actively being used for persistence or if it has been executed by the DirectoryService daemon. + +### False positive analysis + +- Routine system updates or legitimate software installations may modify dsplug files, triggering alerts. Users can create exceptions for known update processes or trusted software installations to reduce noise. +- Administrative tasks performed by IT personnel, such as configuring directory services, might involve legitimate modifications to dsplug files. Implementing a whitelist for actions performed by verified IT accounts can help minimize false positives. +- Security software or system management tools that interact with directory services might cause benign modifications. Identifying and excluding these tools from monitoring can prevent unnecessary alerts. +- Automated scripts or maintenance tasks that regularly check or update directory service configurations could be flagged. Documenting and excluding these scripts from detection can help maintain focus on genuine threats. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Conduct a thorough review of the identified dsplug file(s) in the /Library/DirectoryServices/PlugIns/ directory to confirm unauthorized modifications or creations. Compare against known good configurations or backups. +- Remove any unauthorized or malicious dsplug files and restore legitimate versions from a trusted backup if available. +- Restart the DirectoryService daemon to ensure it is running only legitimate plugins. This can be done by executing `sudo launchctl stop com.apple.DirectoryServices` followed by `sudo launchctl start com.apple.DirectoryServices`. +- Perform a comprehensive scan of the system using updated security tools to identify any additional malicious files or indicators of compromise. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring on the DirectoryServices PlugIns directory to detect future unauthorized changes promptly, ensuring alerts are configured to notify the security team immediately.""" [[rule.threat]] diff --git a/rules/macos/persistence_docker_shortcuts_plist_modification.toml b/rules/macos/persistence_docker_shortcuts_plist_modification.toml index 25ac05e33e9..74d1f6b4e10 100644 --- a/rules/macos/persistence_docker_shortcuts_plist_modification.toml +++ b/rules/macos/persistence_docker_shortcuts_plist_modification.toml @@ -2,7 +2,7 @@ creation_date = "2020/12/18" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -62,6 +62,41 @@ event.category:file and host.os.type:macos and event.action:modification and not process.name:(xpcproxy or cfprefsd or plutil or jamf or PlistBuddy or InstallerRemotePluginService) and not process.executable:(/Library/Addigy/download-cache/* or "/Library/Kandji/Kandji Agent.app/Contents/MacOS/kandji-library-manager") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Persistence via Docker Shortcut Modification + +Docker shortcuts on macOS are managed through dock property lists, which define application launch behaviors. Adversaries may exploit this by altering these lists to redirect shortcuts to malicious applications, thus achieving persistence. The detection rule identifies unauthorized modifications to these property lists, excluding legitimate processes, to flag potential threats. This approach helps in pinpointing suspicious activities that could indicate persistence mechanisms being established by attackers. + +### Possible investigation steps + +- Review the alert details to identify the specific file path and process name involved in the modification of the com.apple.dock.plist file. +- Examine the process that triggered the alert by checking its parent process, command line arguments, and execution history to determine if it is associated with known malicious activity. +- Investigate the user account associated with the file modification to determine if there are any signs of compromise or unauthorized access. +- Check for any recent changes or anomalies in the user's environment, such as new applications installed or unexpected network connections, that could indicate further malicious activity. +- Correlate the event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise. +- If possible, restore the original com.apple.dock.plist file from a backup to ensure the system's integrity and prevent the execution of any malicious applications. + +### False positive analysis + +- Legitimate software updates or installations may modify the dock property list. Users can create exceptions for known update processes like software management tools to prevent false alerts. +- System maintenance tasks performed by macOS utilities might trigger the rule. Exclude processes such as cfprefsd and plutil, which are involved in regular system operations, to reduce noise. +- Custom scripts or automation tools that modify user preferences could be flagged. Identify and whitelist these scripts if they are part of routine administrative tasks. +- Security or IT management tools like Jamf or Kandji may interact with dock property lists. Ensure these tools are included in the exclusion list to avoid unnecessary alerts. +- User-initiated changes to dock settings can also be mistaken for malicious activity. Educate users on the implications of modifying dock settings and monitor for patterns that deviate from normal behavior. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent further malicious activity or lateral movement. +- Terminate any suspicious processes identified as modifying the dock property list, especially those not matching legitimate process names or executables. +- Restore the original com.apple.dock.plist file from a known good backup to ensure the dock shortcuts are not redirecting to malicious applications. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection tools to identify and remove any additional malicious software. +- Review and audit user accounts and permissions on the affected system to ensure no unauthorized access or privilege escalation has occurred. +- Implement monitoring for any future unauthorized modifications to dock property lists, ensuring alerts are configured for quick response. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected.""" [[rule.threat]] diff --git a/rules/macos/persistence_emond_rules_file_creation.toml b/rules/macos/persistence_emond_rules_file_creation.toml index e6bbcdc0bd2..b29aef9323c 100644 --- a/rules/macos/persistence_emond_rules_file_creation.toml +++ b/rules/macos/persistence_emond_rules_file_creation.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/11" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -61,6 +61,39 @@ query = ''' file where host.os.type == "macos" and event.type != "deletion" and file.path : ("/private/etc/emond.d/rules/*.plist", "/etc/emon.d/rules/*.plist", "/private/var/db/emondClients/*") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Emond Rules Creation or Modification + +The Event Monitor Daemon (emond) on macOS is a service that executes commands based on specific system events. Adversaries can exploit this by crafting rules to trigger malicious actions during events like startup or login. The detection rule monitors for new or altered emond rule files, signaling potential unauthorized modifications that could indicate persistence tactics. + +### Possible investigation steps + +- Review the file path of the modified or newly created emond rule to determine if it matches known legitimate configurations or if it appears suspicious, focusing on paths like "/private/etc/emond.d/rules/*.plist" and "/private/var/db/emondClients/*". +- Check the timestamp of the file creation or modification to correlate with any known user activity or scheduled tasks that could explain the change. +- Analyze the contents of the modified or newly created plist file to identify any commands or scripts that are set to execute, looking for signs of malicious intent or unauthorized actions. +- Investigate the user account associated with the file modification event to determine if the activity aligns with their typical behavior or if it suggests potential compromise. +- Cross-reference the event with other security alerts or logs from the same timeframe to identify any related suspicious activities or patterns that could indicate a broader attack. + +### False positive analysis + +- System or application updates may modify emond rule files as part of legitimate maintenance activities. Users can create exceptions for known update processes by identifying the associated process names or hashes and excluding them from alerts. +- Administrative tasks performed by IT personnel, such as configuring new system policies or settings, might involve legitimate changes to emond rules. To handle these, maintain a list of authorized personnel and their activities, and exclude these from triggering alerts. +- Security software or management tools that automate system configurations could also modify emond rules. Identify these tools and their expected behaviors, and configure exceptions based on their typical file paths or process identifiers. +- Scheduled maintenance scripts that interact with emond rules for system health checks or optimizations should be documented. Exclude these scripts by verifying their signatures or paths to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or further execution of malicious rules. +- Review and back up the current emond rule files located in the specified directories to understand the scope of modifications and preserve evidence for further analysis. +- Remove or revert any unauthorized or suspicious emond rule files to their original state to stop any malicious actions triggered by these rules. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection tools to identify and remove any additional malware or persistence mechanisms. +- Restore the system from a known good backup if the integrity of the system is in question and unauthorized changes cannot be fully reversed. +- Escalate the incident to the security operations team for further investigation and to determine if other systems may be affected by similar unauthorized emond rule modifications. +- Implement enhanced monitoring and alerting for changes to emond rule files to quickly detect and respond to future unauthorized modifications.""" [[rule.threat]] diff --git a/rules/macos/persistence_emond_rules_process_execution.toml b/rules/macos/persistence_emond_rules_process_execution.toml index ba4a84be2bd..24576b9df2a 100644 --- a/rules/macos/persistence_emond_rules_process_execution.toml +++ b/rules/macos/persistence_emond_rules_process_execution.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/11" integration = ["endpoint"] maturity = "production" -updated_date = "2024/09/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -85,6 +85,41 @@ process where host.os.type == "macos" and event.type in ("start", "process_start "base64", "launchctl") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Emond Child Process + +The Event Monitor Daemon (emond) on macOS is a service that executes commands based on system events, like startup or user login. Adversaries exploit emond by crafting rules that trigger malicious scripts or commands during these events, enabling persistence. The detection rule identifies unusual child processes spawned by emond, such as shell scripts or command-line utilities, which are indicative of potential abuse. + +### Possible investigation steps + +- Review the process details to confirm the parent process is indeed emond and check the specific child process name against the list of suspicious processes such as bash, python, or curl. +- Investigate the command line arguments used by the suspicious child process to identify any potentially malicious commands or scripts being executed. +- Check the timing of the event to see if it coincides with known system events like startup or user login, which could indicate an attempt to establish persistence. +- Examine the user account associated with the process to determine if it is a legitimate user or potentially compromised account. +- Look for any recent changes to emond rules or configuration files that could have been modified to trigger the suspicious process execution. +- Correlate this event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise. + +### False positive analysis + +- System maintenance scripts may trigger the rule if they use shell scripts or command-line utilities. Review scheduled tasks or maintenance scripts and exclude them if they are verified as non-threatening. +- Legitimate software installations or updates might spawn processes like bash or curl. Monitor installation logs and exclude these processes if they align with known software updates. +- User-initiated scripts for automation or customization can cause alerts. Verify the user's intent and exclude these processes if they are part of regular user activity. +- Administrative tasks performed by IT staff, such as using launchctl for service management, may trigger the rule. Confirm these activities with IT staff and exclude them if they are part of routine administration. +- Development environments on macOS might use interpreters like Python or Perl. Validate the development activities and exclude these processes if they are consistent with the developer's workflow. + +### Response and remediation + +- Isolate the affected macOS system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious child processes spawned by emond, such as shell scripts or command-line utilities, to halt ongoing malicious actions. +- Review and remove any unauthorized or suspicious emond rules that may have been added to execute malicious commands during system events. +- 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. +- Restore any altered or deleted system files from a known good backup to ensure system integrity. +- 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 enhanced monitoring and logging for emond and related processes to detect similar threats in the future, ensuring alerts are configured for unusual child processes.""" [[rule.threat]] diff --git a/rules/macos/persistence_enable_root_account.toml b/rules/macos/persistence_enable_root_account.toml index 47a4bdcfee6..b5a0359fc54 100644 --- a/rules/macos/persistence_enable_root_account.toml +++ b/rules/macos/persistence_enable_root_account.toml @@ -2,7 +2,7 @@ creation_date = "2020/01/04" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -58,6 +58,39 @@ query = ''' event.category:process and host.os.type:macos and event.type:(start or process_started) and process.name:dsenableroot and not process.args:"-d" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Attempt to Enable the Root Account + +In macOS environments, the root account is typically disabled to enhance security. However, adversaries may attempt to enable it using the `dsenableroot` command to gain persistent, elevated access. The detection rule identifies such attempts by monitoring process events for the execution of `dsenableroot` without the disable flag, indicating potential misuse for persistence. + +### Possible investigation steps + +- Review the process event logs to confirm the execution of the dsenableroot command without the disable flag, as indicated by the absence of process.args:"-d". +- Identify the user account associated with the process event to determine if the action was initiated by a legitimate user or a potential adversary. +- Check for any recent changes in user account permissions or configurations that might indicate unauthorized access or privilege escalation. +- Investigate any other suspicious activities or process executions around the same time as the dsenableroot command to identify potential lateral movement or further persistence mechanisms. +- Correlate the event with other security alerts or logs from the same host to assess if this is part of a broader attack campaign. + +### False positive analysis + +- System administrators may legitimately enable the root account for maintenance or troubleshooting. To handle this, create exceptions for known administrator accounts or specific maintenance windows. +- Automated scripts or management tools might use the dsenableroot command as part of their operations. Identify these tools and exclude their process signatures from triggering alerts. +- Educational or testing environments may require enabling the root account for instructional purposes. Implement exclusions for these environments by tagging relevant systems or user accounts. +- Ensure that any exclusion rules are regularly reviewed and updated to reflect changes in administrative practices or tool usage to maintain security integrity. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent any potential lateral movement by the adversary. +- Terminate any unauthorized processes associated with the `dsenableroot` command to halt further misuse of elevated privileges. +- Review system logs and user activity to identify any unauthorized changes or access that occurred after the root account was enabled. +- Reset the root account password and disable the root account to prevent further unauthorized access. +- Conduct a thorough scan of the system for any additional signs of compromise or persistence mechanisms that may have been installed. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Implement additional monitoring and alerting for any future attempts to enable the root account, ensuring rapid detection and response.""" [[rule.threat]] diff --git a/rules/macos/persistence_evasion_hidden_launch_agent_deamon_creation.toml b/rules/macos/persistence_evasion_hidden_launch_agent_deamon_creation.toml index 0b84f1c374e..072dad48df0 100644 --- a/rules/macos/persistence_evasion_hidden_launch_agent_deamon_creation.toml +++ b/rules/macos/persistence_evasion_hidden_launch_agent_deamon_creation.toml @@ -2,7 +2,7 @@ creation_date = "2020/01/05" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -68,6 +68,41 @@ file where host.os.type == "macos" and event.type != "deletion" and "/Library/LaunchDaemons/.*.plist" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Creation of Hidden Launch Agent or Daemon + +Launch agents and daemons in macOS are background services that start at login or system boot, respectively, to perform various tasks. Adversaries exploit this by creating hidden agents or daemons to maintain persistence and evade defenses. The detection rule identifies suspicious creation of these services by monitoring specific system paths for new entries, alerting analysts to potential unauthorized persistence mechanisms. + +### Possible investigation steps + +- Review the file path of the newly created launch agent or daemon to determine if it matches any known legitimate software installations or updates. +- Check the file creation timestamp to correlate with any recent user activities or system changes that might explain the creation of the file. +- Investigate the contents of the .plist file to identify the program or script it is set to execute, and assess whether it is a known or potentially malicious application. +- Examine the user account associated with the file path, especially if it is located in a user's Library directory, to determine if the user has a history of installing unauthorized software. +- Cross-reference the file path and associated executable with threat intelligence sources to identify any known indicators of compromise or malicious behavior. +- Look for any other recent file modifications or creations in the same directory that might indicate additional persistence mechanisms or related malicious activity. + +### False positive analysis + +- System or application updates may create or modify launch agents or daemons as part of legitimate processes. Users can monitor update schedules and correlate alerts with known update activities to verify legitimacy. +- Some third-party applications install launch agents or daemons to provide background services or updates. Users should maintain an inventory of installed applications and their expected behaviors to identify benign entries. +- User-created scripts or automation tools might use launch agents or daemons for personal productivity tasks. Users can document and exclude these known scripts from monitoring to reduce noise. +- Administrative tools or security software might create temporary launch agents or daemons during scans or system maintenance. Users should verify the source and purpose of these entries and consider excluding them if they are part of routine operations. +- Regularly review and update exclusion lists to ensure they reflect current system configurations and software installations, minimizing the risk of overlooking new threats. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or data exfiltration by the adversary. +- Identify and terminate any suspicious processes associated with the newly created launch agent or daemon using Activity Monitor or command-line tools like `launchctl`. +- Remove the unauthorized launch agent or daemon by deleting the corresponding `.plist` file from the identified path. Ensure the file is not recreated by monitoring the directory for changes. +- Conduct a thorough review of user accounts and permissions on the affected system to ensure no unauthorized accounts or privilege escalations have occurred. +- Restore the system from a known good backup if the integrity of the system is in question and further compromise is suspected. +- Escalate the incident to the security operations team for a deeper forensic analysis to determine the root cause and scope of the intrusion. +- Update and enhance endpoint detection and response (EDR) solutions to improve monitoring and alerting for similar persistence mechanisms in the future.""" [[rule.threat]] diff --git a/rules/macos/persistence_finder_sync_plugin_pluginkit.toml b/rules/macos/persistence_finder_sync_plugin_pluginkit.toml index 9d39f3a9d97..ea48a5b6337 100644 --- a/rules/macos/persistence_finder_sync_plugin_pluginkit.toml +++ b/rules/macos/persistence_finder_sync_plugin_pluginkit.toml @@ -2,7 +2,7 @@ creation_date = "2020/12/18" integration = ["endpoint"] maturity = "production" -updated_date = "2024/11/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -78,6 +78,41 @@ process where host.os.type == "macos" and event.type in ("start", "process_start "/Library/Application Support/Checkpoint/Endpoint Security/AMFinderExtensions.app/Contents/MacOS/AMFinderExtensions", "/Applications/pCloud Drive.app/Contents/MacOS/pCloud Drive") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Finder Sync Plugin Registered and Enabled + +Finder Sync plugins enhance macOS Finder by allowing third-party applications to integrate and modify its interface. While beneficial for legitimate software, adversaries can exploit this feature to maintain persistence by registering malicious plugins. The detection rule identifies suspicious plugin registrations by monitoring the `pluginkit` process, filtering out known safe applications, and flagging unusual activity, thus helping analysts spot potential threats. + +### Possible investigation steps + +- Review the process details to confirm the execution of the `pluginkit` process with the specific arguments `-e`, `use`, and `-i`, which indicate the registration of a Finder Sync plugin. +- Cross-reference the plugin identifier found in the process arguments against the list of known safe applications to determine if it is potentially malicious. +- Investigate the parent process of the `pluginkit` execution to identify any unusual or unauthorized parent processes that might suggest malicious activity. +- Check the system for any recent installations or updates of applications that might have introduced the suspicious Finder Sync plugin. +- Analyze the behavior and origin of the executable associated with the suspicious plugin to assess its legitimacy and potential threat level. +- Review system logs and other security alerts around the time of the plugin registration to identify any correlated suspicious activities or anomalies. + +### False positive analysis + +- Known safe applications like Google Drive, Boxcryptor, Adobe, Microsoft OneDrive, Insync, and Box are already excluded from triggering false positives. Ensure these applications are up-to-date to maintain their exclusion status. +- If a legitimate application not listed in the exclusions is causing false positives, consider adding its specific Finder Sync plugin identifier to the exclusion list after verifying its safety. +- Monitor the parent process paths of legitimate applications. If a trusted application frequently triggers alerts, add its executable path to the exclusion list to prevent unnecessary alerts. +- Regularly review and update the exclusion list to accommodate new versions or additional legitimate applications that may introduce Finder Sync plugins. +- Educate users on the importance of installing applications from trusted sources to minimize the risk of false positives and ensure that only legitimate plugins are registered. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or data exfiltration by the malicious Finder Sync plugin. +- Terminate the suspicious `pluginkit` process to stop the execution of the rogue Finder Sync plugin and prevent further persistence. +- Remove the malicious Finder Sync plugin by unregistering it using the `pluginkit` command with appropriate flags to ensure it cannot be re-enabled. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious payloads or artifacts. +- Review system logs and the Finder Sync plugin registration history to identify any unauthorized changes or additional compromised systems. +- 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 enhanced monitoring for `pluginkit` activity and similar persistence mechanisms to detect and respond to future attempts promptly.""" [[rule.threat]] diff --git a/rules/macos/persistence_folder_action_scripts_runtime.toml b/rules/macos/persistence_folder_action_scripts_runtime.toml index 18b114cfaf4..fa26986610a 100644 --- a/rules/macos/persistence_folder_action_scripts_runtime.toml +++ b/rules/macos/persistence_folder_action_scripts_runtime.toml @@ -2,7 +2,7 @@ creation_date = "2020/12/07" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -60,6 +60,40 @@ query = ''' process where host.os.type == "macos" and event.type : "start" and process.name in ("osascript", "python", "tcl", "node", "perl", "ruby", "php", "bash", "csh", "zsh", "sh") and process.parent.name == "com.apple.foundation.UserScriptService" and not process.args : ("/Users/*/Library/Application Support/iTerm2/Scripts/AutoLaunch/*.scpt", "/Users/*/Library/Application Scripts/com.microsoft.*/FoxitUtils.applescript") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Persistence via Folder Action Script + +Folder Action scripts on macOS automate tasks by executing scripts when folder contents change. Adversaries exploit this by attaching malicious scripts to folders, ensuring execution upon folder events, thus achieving persistence. The detection rule identifies suspicious script executions by monitoring specific processes initiated by the UserScriptService, excluding known benign scripts, to flag potential threats. + +### Possible investigation steps + +- Review the process details to confirm the execution of a script by checking the process name and arguments, ensuring it matches the suspicious criteria outlined in the detection rule. +- Investigate the parent process, com.apple.foundation.UserScriptService, to understand the context of the script execution and identify any unusual behavior or anomalies. +- Examine the specific folder associated with the Folder Action script to determine if it has been modified recently or contains any unauthorized or unexpected scripts. +- Check the user account associated with the script execution to verify if the activity aligns with normal user behavior or if it indicates potential compromise. +- Look for any additional related alerts or logs that might provide further context or evidence of malicious activity, such as other script executions or file modifications around the same time. + +### False positive analysis + +- Scripts associated with legitimate applications like iTerm2 and Microsoft Office may trigger alerts. These are known benign scripts and can be excluded by adding their paths to the exception list in the detection rule. +- Custom user scripts that automate routine tasks might be flagged. Users should review these scripts and, if verified as safe, add their specific paths to the exclusion criteria. +- Development environments that frequently execute scripts for testing purposes can cause false positives. Developers should ensure that these scripts are executed in a controlled environment and consider excluding their paths if they are consistently flagged. +- System maintenance scripts that are scheduled to run during folder events might be detected. Users should verify these scripts' legitimacy and exclude them if they are part of regular system operations. +- Backup or synchronization tools that use scripts to manage file changes in folders could be mistakenly identified. Confirm these tools' activities and exclude their script paths if they are part of trusted operations. + +### Response and remediation + +- Isolate the affected system from the network to prevent further execution of the malicious script and potential lateral movement. +- Terminate any suspicious processes identified by the detection rule, particularly those initiated by the UserScriptService that match the query criteria. +- Remove or disable the malicious Folder Action script from the affected folder to prevent future execution. +- Conduct a thorough review of the affected system's folder action scripts to identify and remove any additional unauthorized or suspicious scripts. +- Restore any affected files or system components from a known good backup to ensure system integrity. +- Monitor the system for any signs of re-infection or further suspicious activity, focusing on processes and scripts similar to those identified in the alert. +- Escalate the incident to the security team for further investigation and to determine if additional systems are affected, ensuring a comprehensive response to the threat.""" [[rule.threat]] diff --git a/rules/macos/persistence_login_logout_hooks_defaults.toml b/rules/macos/persistence_login_logout_hooks_defaults.toml index b0ef9cdda7d..69654c92891 100644 --- a/rules/macos/persistence_login_logout_hooks_defaults.toml +++ b/rules/macos/persistence_login_logout_hooks_defaults.toml @@ -2,7 +2,7 @@ creation_date = "2020/12/07" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -68,6 +68,41 @@ process where host.os.type == "macos" and event.type == "start" and "/Library/Application Support/JAMF/ManagementFrameworkScripts/loginhook.sh" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Persistence via Login or Logout Hook + +In macOS environments, login and logout hooks are scripts executed automatically during user login or logout, often used for system management tasks. Adversaries exploit this by inserting malicious scripts to maintain persistence. The detection rule identifies suspicious use of the `defaults` command to set these hooks, excluding known legitimate scripts, thus highlighting potential unauthorized persistence attempts. + +### Possible investigation steps + +- Review the process execution details to confirm the use of the "defaults" command with "write" arguments targeting "LoginHook" or "LogoutHook". +- Check the process execution history for the user account associated with the alert to identify any unusual or unauthorized activity. +- Investigate the source and content of the script specified in the "defaults" command to determine if it contains malicious or unauthorized code. +- Cross-reference the script path against known legitimate scripts to ensure it is not mistakenly flagged. +- Analyze recent system changes or installations that might have introduced the suspicious script or process. +- Review system logs around the time of the alert for any additional indicators of compromise or related suspicious activity. + +### False positive analysis + +- Known false positives include legitimate scripts used by system management tools like JAMF, which are often set as login or logout hooks. +- To handle these, users can create exceptions for known legitimate scripts by adding their paths to the exclusion list in the detection rule. +- Regularly review and update the exclusion list to ensure it includes all authorized scripts used in your environment. +- Monitor for any changes in the behavior of these scripts to ensure they remain non-threatening and authorized. +- Collaborate with IT and security teams to identify any new legitimate scripts that should be excluded from detection. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or data exfiltration by the adversary. +- Terminate any suspicious processes associated with the unauthorized login or logout hooks to halt any ongoing malicious activity. +- Remove the unauthorized login or logout hooks by using the `defaults delete` command to ensure the persistence mechanism is dismantled. +- Conduct a thorough review of system logs and recent changes to identify any additional unauthorized modifications or indicators of compromise. +- Restore any affected system files or configurations from a known good backup to ensure system integrity and functionality. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and alerting for similar unauthorized use of the `defaults` command to improve detection and response capabilities.""" [[rule.threat]] diff --git a/rules/macos/persistence_modification_sublime_app_plugin_or_script.toml b/rules/macos/persistence_modification_sublime_app_plugin_or_script.toml index 4023d557e1d..e043648e2e8 100644 --- a/rules/macos/persistence_modification_sublime_app_plugin_or_script.toml +++ b/rules/macos/persistence_modification_sublime_app_plugin_or_script.toml @@ -2,7 +2,7 @@ creation_date = "2020/12/23" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/31" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -70,6 +70,41 @@ file where host.os.type == "macos" and event.type in ("change", "creation") and "/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/Resources/DesktopServicesHelper" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Sublime Plugin or Application Script Modification + +Sublime Text, a popular text editor, supports plugins and scripts written in Python to enhance functionality. Adversaries may exploit this by altering these scripts to execute malicious code whenever the application launches, achieving persistence. The detection rule identifies suspicious modifications or creations of Python files in specific Sublime directories on macOS, excluding legitimate processes, to flag potential threats. + +### Possible investigation steps + +- Review the file path and name of the modified or created Python file to determine if it aligns with known Sublime Text plugin directories, specifically checking paths like "/Users/*/Library/Application Support/Sublime Text*/Packages/*.py" and "/Applications/Sublime Text.app/Contents/MacOS/sublime.py". +- Examine the process that triggered the file change or creation event, ensuring it is not one of the excluded legitimate processes such as those from "/Applications/Sublime Text*.app/Contents/*" or "/usr/local/Cellar/git/*/bin/git". +- Analyze the contents of the modified or newly created Python file for any suspicious or unauthorized code, focusing on scripts that may execute commands or connect to external networks. +- Check the modification or creation timestamp of the file to correlate with any known user activity or other security events that occurred around the same time. +- Investigate the user account associated with the file modification to determine if the activity aligns with their typical behavior or if it might indicate compromised credentials. +- Look for any additional indicators of compromise on the host, such as unusual network connections or other file modifications, to assess the broader impact of the potential threat. + +### False positive analysis + +- Legitimate Sublime Text updates or installations may trigger the rule by modifying or creating Python files in the specified directories. Users can mitigate this by temporarily disabling the rule during known update periods or by verifying the update source. +- Development activities involving Sublime Text plugins or scripts can cause false positives. Developers should consider excluding their specific user paths or processes from the rule to prevent unnecessary alerts. +- Automated backup or synchronization tools that modify Sublime Text configuration files might be flagged. Users can exclude these tools' processes from the rule to avoid false positives. +- System maintenance or cleanup scripts that interact with Sublime Text directories could trigger alerts. Identifying and excluding these scripts from the rule can help manage false positives. +- Version control operations, such as those involving git, may modify files in the monitored directories. Users should ensure that legitimate git processes are included in the exclusion list to prevent false alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further spread of any potential malicious activity. +- Terminate any suspicious processes related to Sublime Text that are not part of the legitimate process list provided in the detection rule. +- Restore the modified or newly created Python files in the specified Sublime directories from a known good backup to ensure no malicious code persists. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection tools to identify and remove any additional malicious payloads. +- Review system logs and the history of file changes to identify any unauthorized access or modifications, and document findings for further analysis. +- Escalate the incident to the security operations team for a deeper investigation into potential compromise vectors and to assess the need for broader organizational response. +- Implement additional monitoring on the affected system and similar environments to detect any recurrence of the threat, ensuring enhanced logging for the specified directories and processes.""" [[rule.threat]] diff --git a/rules/macos/persistence_periodic_tasks_file_mdofiy.toml b/rules/macos/persistence_periodic_tasks_file_mdofiy.toml index fda11158c76..1e8be3c147b 100644 --- a/rules/macos/persistence_periodic_tasks_file_mdofiy.toml +++ b/rules/macos/persistence_periodic_tasks_file_mdofiy.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/21" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -62,6 +62,40 @@ query = ''' event.category:file and host.os.type:macos and not event.type:"deletion" and file.path:(/private/etc/periodic/* or /private/etc/defaults/periodic.conf or /private/etc/periodic.conf) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Persistence via Periodic Tasks + +Periodic tasks in macOS are scheduled operations that automate system maintenance and other routine activities. Adversaries may exploit these tasks to execute unauthorized code or maintain persistence by altering task configurations. The detection rule identifies suspicious file activities related to periodic task configurations, excluding deletions, to flag potential misuse. This helps in early detection of persistence mechanisms employed by attackers. + +### Possible investigation steps + +- Review the file path specified in the alert to determine which configuration file was created or modified. Focus on paths like /private/etc/periodic/*, /private/etc/defaults/periodic.conf, or /private/etc/periodic.conf. +- Examine the contents of the modified or newly created configuration file to identify any unauthorized or suspicious entries that could indicate malicious activity. +- Check the timestamp of the file modification or creation to correlate with any known suspicious activities or other alerts in the same timeframe. +- Investigate the user account and process responsible for the file modification to determine if it aligns with expected behavior or if it indicates potential compromise. +- Look for any related events in the system logs that might provide additional context or evidence of unauthorized access or persistence attempts. +- Assess the risk and impact of the changes by determining if the modified periodic task could execute malicious code or provide persistence for an attacker. + +### False positive analysis + +- Routine system updates or maintenance scripts may trigger alerts when they modify periodic task configurations. Users can create exceptions for known update processes by identifying their specific file paths or process names. +- Administrative tools or scripts used by IT departments for legitimate system management might alter periodic task settings. To mitigate this, users should whitelist these tools by verifying their source and ensuring they are part of authorized IT operations. +- Custom user scripts for personal automation tasks could be flagged if they modify periodic task configurations. Users should document and exclude these scripts by adding them to an exception list, ensuring they are reviewed and approved for legitimate use. +- Security software or monitoring tools that adjust system settings for protection purposes might inadvertently trigger the rule. Users should verify these tools' activities and exclude them if they are confirmed to be part of the security infrastructure. + +### Response and remediation + +- Isolate the affected macOS system from the network to prevent potential lateral movement or further execution of unauthorized code. +- Review the identified periodic task configuration files for unauthorized modifications or additions. Restore any altered files to their original state using known good backups. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious code that may have been executed through the periodic tasks. +- Check for any additional persistence mechanisms that may have been established by the adversary, such as other scheduled tasks or startup items, and remove them. +- Monitor the system and network for any signs of continued unauthorized activity or attempts to re-establish persistence. +- Escalate the incident to the security operations team for further investigation and to determine if other systems may be affected. +- Implement enhanced monitoring and alerting for changes to periodic task configurations to quickly detect similar threats in the future.""" [[rule.threat]] diff --git a/rules/macos/persistence_suspicious_calendar_modification.toml b/rules/macos/persistence_suspicious_calendar_modification.toml index d9e648f11f1..a3ae669c25c 100644 --- a/rules/macos/persistence_suspicious_calendar_modification.toml +++ b/rules/macos/persistence_suspicious_calendar_modification.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/19" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -74,6 +74,39 @@ event.category:file and host.os.type:macos and event.action:modification and ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Calendar File Modification + +Calendar files on macOS can be manipulated to trigger events, potentially allowing adversaries to execute malicious programs at set intervals, thus achieving persistence. This detection rule identifies unusual processes modifying calendar files, excluding known legitimate applications. By focusing on unexpected executables altering these files, it helps uncover potential threats exploiting calendar notifications for malicious purposes. + +### Possible investigation steps + +- Review the process executable path that triggered the alert to determine if it is a known or unknown application, focusing on paths not excluded by the rule. +- Examine the modification timestamp of the calendar file to correlate with any known user activity or scheduled tasks that might explain the change. +- Check the user account associated with the file modification to assess if the activity aligns with typical user behavior or if it suggests unauthorized access. +- Investigate any recent installations or updates of applications on the system that might have introduced new or unexpected executables. +- Look for additional indicators of compromise on the host, such as unusual network connections or other file modifications, to assess if the calendar file change is part of a broader attack. + +### False positive analysis + +- Legitimate third-party calendar applications may modify calendar files as part of their normal operation. Users can create exceptions for these known applications by adding their executable paths to the exclusion list. +- Automated backup or synchronization tools might access and modify calendar files. Identify these tools and exclude their processes to prevent false alerts. +- User scripts or automation workflows that interact with calendar files for personal productivity purposes can trigger this rule. Review and whitelist these scripts if they are verified as non-malicious. +- System updates or maintenance tasks occasionally modify calendar files. Monitor the timing of such events and correlate them with known update schedules to differentiate between legitimate and suspicious activities. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent potential lateral movement or further execution of malicious programs. +- Terminate any suspicious processes identified as modifying calendar files that are not part of the known legitimate applications list. +- Restore the calendar files from a known good backup to ensure no malicious events are scheduled. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious software. +- Review and audit user accounts and permissions on the affected system to ensure no unauthorized access or privilege escalation has occurred. +- 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 unusual calendar file modifications across the network to enhance detection of similar threats in the future.""" [[rule.threat]] diff --git a/rules/macos/persistence_via_atom_init_file_modification.toml b/rules/macos/persistence_via_atom_init_file_modification.toml index f281678818e..16a3f109e70 100644 --- a/rules/macos/persistence_via_atom_init_file_modification.toml +++ b/rules/macos/persistence_via_atom_init_file_modification.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/21" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -61,6 +61,40 @@ query = ''' event.category:file and host.os.type:macos and not event.type:"deletion" and file.path:/Users/*/.atom/init.coffee and not process.name:(Atom or xpcproxy) and not user.name:root ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Persistence via Atom Init Script Modification + +Atom, a popular text editor, allows customization via the `init.coffee` script, which executes JavaScript upon startup. Adversaries exploit this by embedding malicious code, ensuring persistence each time Atom launches. The detection rule identifies suspicious modifications to this script on macOS, excluding benign processes and root user actions, thus highlighting potential unauthorized persistence attempts. + +### Possible investigation steps + +- Review the file modification details for /Users/*/.atom/init.coffee to identify the exact changes made to the script. +- Investigate the process that modified the init.coffee file by examining the process name and user associated with the modification, ensuring it is not Atom, xpcproxy, or the root user. +- Check the user account involved in the modification for any unusual activity or recent changes, such as new software installations or privilege escalations. +- Analyze the content of the modified init.coffee file for any suspicious or unfamiliar JavaScript code that could indicate malicious intent. +- Correlate the modification event with other security alerts or logs from the same host to identify any related suspicious activities or patterns. +- If malicious code is found, isolate the affected system and conduct a deeper forensic analysis to determine the scope and impact of the potential compromise. + +### False positive analysis + +- Frequent legitimate updates to the init.coffee file by developers or power users can trigger alerts. To manage this, create exceptions for specific user accounts known to regularly modify this file for legitimate purposes. +- Automated scripts or tools that modify the init.coffee file as part of a legitimate configuration management process may cause false positives. Identify these processes and exclude them from the rule by adding their process names to the exception list. +- Non-malicious third-party Atom packages that require modifications to the init.coffee file for functionality can be mistaken for threats. Review and whitelist these packages if they are verified as safe and necessary for user workflows. +- System maintenance or administrative tasks performed by non-root users that involve changes to the init.coffee file might be flagged. Consider adding exceptions for these specific maintenance activities if they are routine and verified as non-threatening. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further execution of potentially malicious code. +- Review the contents of the `init.coffee` file to identify and document any unauthorized or suspicious code modifications. +- Remove any malicious code found in the `init.coffee` file and restore it to a known good state, either by reverting to a backup or by manually cleaning the file. +- 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. +- Change the credentials of the user account associated with the modified `init.coffee` file to prevent unauthorized access. +- 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 monitoring for future unauthorized changes to the `init.coffee` file and similar persistence mechanisms, enhancing detection capabilities to quickly identify and respond to similar threats.""" [[rule.threat]] diff --git a/rules/macos/privilege_escalation_applescript_with_admin_privs.toml b/rules/macos/privilege_escalation_applescript_with_admin_privs.toml index b47455ab7a1..eb8b45f415a 100644 --- a/rules/macos/privilege_escalation_applescript_with_admin_privs.toml +++ b/rules/macos/privilege_escalation_applescript_with_admin_privs.toml @@ -2,7 +2,7 @@ creation_date = "2020/12/27" integration = ["endpoint"] maturity = "production" -updated_date = "2024/11/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -62,6 +62,40 @@ process where host.os.type == "macos" and event.type in ("start", "process_start not process.Ext.effective_parent.executable : ("/Applications/Visual Studio Code.app/Contents/MacOS/Electron", "/Applications/OpenVPN Connect/Uninstall OpenVPN Connect.app/Contents/MacOS/uninstaller") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Apple Scripting Execution with Administrator Privileges + +AppleScript, a scripting language for macOS, automates tasks by controlling applications and system functions. Adversaries may exploit it to execute scripts with elevated privileges, bypassing password prompts, to gain unauthorized access or escalate privileges. The detection rule identifies such misuse by monitoring the execution of AppleScript with admin rights, excluding benign parent processes like Electron, to flag potential threats. + +### Possible investigation steps + +- Review the process details to confirm the execution of 'osascript' with administrator privileges, focusing on the command line arguments to understand the script's intent. +- Investigate the parent process of 'osascript' to determine if it is a known and trusted application, ensuring it is not 'Electron' or any other excluded parent processes. +- Check the user account associated with the 'osascript' execution to verify if it is a legitimate account and assess if there are any signs of compromise or unauthorized access. +- Analyze recent system logs and user activity to identify any unusual behavior or patterns that coincide with the time of the alert. +- Correlate this event with other security alerts or incidents to determine if it is part of a broader attack or isolated incident. + +### False positive analysis + +- Known false positives may arise from legitimate applications that use AppleScript with administrator privileges for valid operations, such as software installers or system management tools. +- Exclude processes with benign parent applications like Electron, as specified in the rule, to reduce false positives from common development environments. +- Consider adding exceptions for other trusted applications that frequently use AppleScript with elevated privileges, ensuring they are verified and necessary for business operations. +- Regularly review and update the list of excluded applications to adapt to changes in software usage and maintain effective threat detection. +- Monitor the frequency and context of alerts to identify patterns that may indicate false positives, adjusting the detection rule as needed to minimize unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious osascript processes running with administrator privileges that were not initiated by known, legitimate applications. +- Review system logs and process execution history to identify any unauthorized changes or access that occurred during the incident. +- Revoke any compromised credentials or accounts that may have been used to execute the AppleScript with elevated privileges. +- Restore the system to a known good state from a backup taken before the unauthorized script execution, if necessary. +- Implement application whitelisting to prevent unauthorized scripts from executing with elevated privileges in the future. +- Escalate the incident to the security operations team for further investigation and to assess the need for additional security controls or monitoring enhancements.""" [[rule.threat]] diff --git a/rules/macos/privilege_escalation_explicit_creds_via_scripting.toml b/rules/macos/privilege_escalation_explicit_creds_via_scripting.toml index b05b7f04238..11354d8bf3c 100644 --- a/rules/macos/privilege_escalation_explicit_creds_via_scripting.toml +++ b/rules/macos/privilege_escalation_explicit_creds_via_scripting.toml @@ -2,7 +2,7 @@ creation_date = "2020/12/07" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -64,6 +64,41 @@ event.category:process and host.os.type:macos and event.type:(start or process_s process.name:"security_authtrampoline" and process.parent.name:(osascript or com.apple.automator.runner or sh or bash or dash or zsh or python* or Python or perl* or php* or ruby or pwsh) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Execution with Explicit Credentials via Scripting + +In macOS environments, the `security_authtrampoline` process is used to execute programs with elevated privileges via scripting interpreters. Adversaries may exploit this by using explicit credentials to run unauthorized scripts, gaining root access. The detection rule identifies such activities by monitoring the initiation of `security_authtrampoline` through common scripting languages, flagging potential privilege escalation attempts. + +### Possible investigation steps + +- Review the process details to confirm the parent process name matches one of the specified scripting interpreters (e.g., osascript, bash, python) to verify the context of the alert. +- Examine the command line arguments of the security_authtrampoline process to identify the script or program being executed and assess its legitimacy. +- Investigate the user account associated with the process to determine if the credentials used are valid and expected for executing such scripts. +- Check the historical activity of the involved user account and associated processes to identify any patterns of unusual or unauthorized behavior. +- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related suspicious activities. +- Assess the system for any signs of compromise or unauthorized changes, such as unexpected new files, altered configurations, or additional unauthorized processes running. + +### False positive analysis + +- Legitimate administrative tasks using scripting languages may trigger this rule. Users should review the context of the script execution to determine if it aligns with expected administrative activities. +- Automated scripts or scheduled tasks that require elevated privileges might be flagged. Consider creating exceptions for known scripts by specifying their hash or path in the monitoring system. +- Development or testing environments where developers frequently use scripting languages to test applications with elevated privileges can cause false positives. Implement a policy to exclude these environments from the rule or adjust the risk score to reflect the lower threat level. +- Security tools or software updates that use scripting interpreters to perform legitimate actions with elevated privileges may be mistakenly identified. Verify the source and purpose of such processes and whitelist them if they are deemed safe. +- User-initiated scripts for personal productivity that require elevated access could be misinterpreted as threats. Educate users on safe scripting practices and establish a process for them to report and document legitimate use cases for exclusion. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement. +- Terminate the `security_authtrampoline` process if it is still running to stop any ongoing unauthorized activities. +- Review and revoke any compromised credentials used in the execution of the unauthorized script to prevent further misuse. +- Conduct a thorough examination of the system for any additional unauthorized scripts or malware that may have been deployed using the compromised credentials. +- Restore the system from a known good backup if any unauthorized changes or persistent threats are detected. +- Implement stricter access controls and monitoring for the use of scripting interpreters and the `security_authtrampoline` process to prevent similar privilege escalation attempts. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] diff --git a/rules/macos/privilege_escalation_exploit_adobe_acrobat_updater.toml b/rules/macos/privilege_escalation_exploit_adobe_acrobat_updater.toml index 2fbd033a24f..21e1494c56e 100644 --- a/rules/macos/privilege_escalation_exploit_adobe_acrobat_updater.toml +++ b/rules/macos/privilege_escalation_exploit_adobe_acrobat_updater.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/19" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -73,6 +73,40 @@ event.category:process and host.os.type:macos and event.type:(start or process_s /usr/sbin/installer or /usr/bin/csrutil) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Child Process of Adobe Acrobat Reader Update Service + +Adobe Acrobat Reader's update service on macOS uses a privileged helper tool to manage updates, running with elevated permissions. Adversaries may exploit vulnerabilities in this service to escalate privileges by spawning unauthorized child processes. The detection rule identifies such anomalies by monitoring for unexpected child processes initiated by the update service, especially those not matching known legitimate executables, thus flagging potential exploitation attempts. + +### Possible investigation steps + +- Review the alert details to confirm the parent process is com.adobe.ARMDC.SMJobBlessHelper and the user is root, as these are key indicators of potential exploitation. +- Identify the child process executable that triggered the alert and determine if it is known or expected in the context of Adobe Acrobat Reader updates. +- Check the system for any recent updates or patches related to Adobe Acrobat Reader to ensure they are up to date, particularly concerning CVE-2020-9615, CVE-2020-9614, and CVE-2020-9613. +- Investigate the process tree to understand the sequence of events leading to the suspicious child process, looking for any unusual or unauthorized activities. +- Examine system logs and other security tools for additional indicators of compromise or related suspicious activities around the time of the alert. +- Assess the system for any signs of privilege escalation or unauthorized access, focusing on changes made by the suspicious process. + +### False positive analysis + +- Legitimate software updates or installations may trigger the rule if they spawn child processes not listed in the known legitimate executables. Users can mitigate this by monitoring update schedules and temporarily excluding these processes during known update windows. +- Custom scripts or administrative tools executed by system administrators with root privileges might be flagged. To handle this, users can create exceptions for these specific scripts or tools if they are verified as safe and necessary for operations. +- Security or system management tools that perform integrity checks or system modifications could be misidentified as suspicious. Users should review these tools and, if deemed safe, add them to the exclusion list to prevent false alerts. +- Development or testing environments where new or experimental software is frequently run may generate false positives. In such cases, users can establish a separate monitoring profile with adjusted rules to accommodate the unique activities of these environments. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious child processes identified by the detection rule that do not match known legitimate executables, ensuring that no unauthorized processes are running. +- Conduct a thorough review of system logs and process execution history to identify any additional indicators of compromise or unauthorized changes made by the suspicious process. +- Apply the latest security patches and updates to Adobe Acrobat Reader and the macOS system to address vulnerabilities CVE-2020-9615, CVE-2020-9614, and CVE-2020-9613, ensuring the system is not susceptible to known exploits. +- Restore any affected files or system configurations from a known good backup to ensure system integrity and remove any potential backdoors or malicious modifications. +- Enhance monitoring and logging on the affected system to detect any future unauthorized process executions or privilege escalation attempts, ensuring quick detection and response. +- Report the incident to the appropriate internal security team or external authorities if required, providing detailed information about the threat and actions taken for further investigation and compliance.""" [[rule.threat]] diff --git a/rules/macos/privilege_escalation_local_user_added_to_admin.toml b/rules/macos/privilege_escalation_local_user_added_to_admin.toml index 8e00d539268..b7076cfbe18 100644 --- a/rules/macos/privilege_escalation_local_user_added_to_admin.toml +++ b/rules/macos/privilege_escalation_local_user_added_to_admin.toml @@ -2,7 +2,7 @@ creation_date = "2020/01/05" integration = ["endpoint"] maturity = "production" -updated_date = "2024/11/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -62,6 +62,40 @@ event.category:process and host.os.type:macos and event.type:(start or process_s "/opt/jc/bin/jumpcloud-agent" or "/Library/Addigy/go-agent") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Admin Group Account Addition + +In macOS environments, tools like `dscl` and `dseditgroup` manage user group memberships, including admin groups. Adversaries may exploit these tools to escalate privileges by adding accounts to admin groups, gaining unauthorized access. The detection rule identifies such attempts by monitoring process activities related to these tools, excluding legitimate management services, to flag potential privilege escalation. + +### Possible investigation steps + +- Review the process details to confirm the use of `dscl` or `dseditgroup` with arguments indicating an attempt to add an account to the admin group, such as "/Groups/admin" and "-a" or "-append". +- Check the process's parent executable path to ensure it is not one of the legitimate management services excluded in the query, such as JamfDaemon, JamfManagementService, jumpcloud-agent, or Addigy go-agent. +- Investigate the user account associated with the process to determine if it has a history of legitimate administrative actions or if it appears suspicious. +- Examine recent login events and user activity on the host to identify any unusual patterns or unauthorized access attempts. +- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or potential indicators of compromise. +- Assess the risk and impact of the account addition by determining if the account has been successfully added to the admin group and if any unauthorized changes have been made. + +### False positive analysis + +- Legitimate management services like JAMF and JumpCloud may trigger false positives when they manage user group memberships. These services are already excluded in the rule, but ensure any additional management tools used in your environment are similarly excluded. +- Automated scripts or maintenance tasks that require temporary admin access might be flagged. Review these scripts and consider adding them to the exclusion list if they are verified as safe. +- System updates or software installations that modify group memberships could be misidentified. Monitor these activities and adjust the rule to exclude known update processes if they are consistently flagged. +- User-initiated actions that are part of normal IT operations, such as adding a new admin for legitimate purposes, may appear as false positives. Ensure that such actions are documented and communicated to avoid unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected macOS system from the network to prevent further unauthorized access or privilege escalation. +- Review the process execution logs to confirm unauthorized use of `dscl` or `dseditgroup` for adding accounts to the admin group, ensuring the activity is not part of legitimate administrative tasks. +- Remove any unauthorized accounts from the admin group to restore proper access controls and prevent further misuse of elevated privileges. +- Conduct a thorough review of all admin group memberships on the affected system to ensure no other unauthorized accounts have been added. +- Reset passwords for any accounts that were added to the admin group without authorization to prevent further unauthorized access. +- 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 similar activities across the network to detect and respond to future privilege escalation attempts promptly.""" [[rule.threat]] diff --git a/rules/macos/privilege_escalation_root_crontab_filemod.toml b/rules/macos/privilege_escalation_root_crontab_filemod.toml index 3e51714cdd2..86405b2e937 100644 --- a/rules/macos/privilege_escalation_root_crontab_filemod.toml +++ b/rules/macos/privilege_escalation_root_crontab_filemod.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/27" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -61,6 +61,40 @@ query = ''' event.category:file and host.os.type:macos and not event.type:deletion and file.path:/private/var/at/tabs/root and not process.executable:/usr/bin/crontab ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Privilege Escalation via Root Crontab File Modification + +Crontab files in macOS are used to schedule tasks, often requiring elevated privileges for execution. Adversaries exploit this by modifying the root crontab file, enabling unauthorized code execution with root access. The detection rule identifies suspicious modifications to this file, excluding legitimate crontab processes, to flag potential privilege escalation attempts. + +### Possible investigation steps + +- Review the alert details to confirm the file path involved is /private/var/at/tabs/root, as this is the specific file path targeted by the rule. +- Examine the process that modified the root crontab file by checking the process executable path. Ensure it is not /usr/bin/crontab, which is excluded as a legitimate process. +- Investigate the user account associated with the process that made the modification to determine if it has legitimate access or if it might be compromised. +- Check for any recent changes or anomalies in user account activity or permissions that could indicate unauthorized access or privilege escalation attempts. +- Correlate this event with other security alerts or logs from the same host to identify any patterns or additional suspicious activities that might suggest a broader attack campaign. +- Assess the risk and impact of the modification by determining if any unauthorized or malicious tasks have been scheduled in the crontab file. + +### False positive analysis + +- System maintenance tasks or updates may modify the root crontab file. To handle these, users can create exceptions for known maintenance processes that are verified as safe. +- Administrative scripts that require scheduled tasks might trigger this rule. Users should document and exclude these scripts if they are part of regular, authorized operations. +- Backup or monitoring software that interacts with crontab files could cause false positives. Verify these applications and exclude their processes if they are legitimate and necessary for system operations. +- Custom automation tools used by IT departments might modify crontab files. Ensure these tools are reviewed and whitelisted if they are part of approved workflows. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious tasks. +- Review the modified root crontab file to identify any unauthorized or suspicious entries and remove them to stop any malicious scheduled tasks. +- Conduct a thorough investigation to determine how the crontab file was modified, focusing on identifying any exploited vulnerabilities or unauthorized access points. +- Reset credentials and review permissions for any accounts that may have been compromised or used in the attack to prevent further unauthorized access. +- Apply security patches and updates to the operating system and any vulnerable applications to close exploited vulnerabilities. +- Monitor the system and network for any signs of continued unauthorized activity or attempts to modify crontab files, using enhanced logging and alerting mechanisms. +- Escalate the incident to the appropriate internal security team or external cybersecurity experts if the threat persists or if there is evidence of a broader compromise.""" [[rule.threat]] diff --git a/rules/ml/command_and_control_ml_packetbeat_dns_tunneling.toml b/rules/ml/command_and_control_ml_packetbeat_dns_tunneling.toml index debaac79b06..dbc28783f8a 100644 --- a/rules/ml/command_and_control_ml_packetbeat_dns_tunneling.toml +++ b/rules/ml/command_and_control_ml_packetbeat_dns_tunneling.toml @@ -2,7 +2,7 @@ creation_date = "2020/03/25" integration = ["endpoint", "network_traffic"] maturity = "production" -updated_date = "2024/06/18" +updated_date = "2025/01/10" [rule] anomaly_threshold = 50 @@ -79,6 +79,40 @@ tags = [ "Tactic: Command and Control", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 DNS Tunneling + +DNS tunneling exploits the DNS protocol to covertly transmit data between a compromised system and an attacker-controlled server. Adversaries use it for stealthy command-and-control, persistence, or data exfiltration by embedding data within DNS queries. The detection rule leverages machine learning to identify anomalies, such as an unusually high volume of DNS queries to a single domain, indicating potential tunneling activity. + +### Possible investigation steps + +- Review the DNS query logs to identify the specific top-level domain generating the unusually high volume of queries. This can help pinpoint the potential source of tunneling activity. +- Analyze the source IP addresses associated with the DNS queries to determine if they originate from known or suspicious hosts within the network. +- Check for any recent changes or anomalies in the network traffic patterns related to the identified domain, which might indicate tunneling or exfiltration attempts. +- Investigate the history of the identified domain to assess its reputation and any known associations with malicious activities or threat actors. +- Correlate the DNS query activity with other security events or alerts in the network to identify any related suspicious behavior or indicators of compromise. + +### False positive analysis + +- High volume of DNS queries from legitimate software updates or patch management systems can trigger false positives. Users should identify and whitelist domains associated with trusted update services. +- Content delivery networks (CDNs) often generate numerous DNS queries due to their distributed nature. Exclude known CDN domains from the analysis to reduce false positives. +- Internal network monitoring tools that rely on DNS for service discovery may cause an increase in DNS queries. Consider excluding these internal domains if they are verified as non-threatening. +- Some cloud services use DNS for load balancing and may result in high query volumes. Users should review and whitelist these domains if they are confirmed to be safe. +- Automated scripts or applications that frequently query DNS for legitimate purposes can be excluded by identifying their specific patterns and adding them to an exception list. + +### Response and remediation + +- Isolate the affected system from the network to prevent further data exfiltration or command-and-control communication. +- Conduct a thorough analysis of DNS logs to identify the specific domain involved in the tunneling activity and block it at the network perimeter. +- Review and terminate any suspicious processes or services running on the compromised system that may be associated with the tunneling activity. +- Reset credentials and review access permissions for accounts that were active on the compromised system to prevent unauthorized access. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring for DNS traffic to detect similar tunneling activities in the future, focusing on high-frequency queries to single domains. +- Coordinate with IT and security teams to apply necessary patches and updates to the affected system to close any vulnerabilities exploited by the attacker.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/ml/command_and_control_ml_packetbeat_rare_dns_question.toml b/rules/ml/command_and_control_ml_packetbeat_rare_dns_question.toml index 57cef36eac2..86494e4517b 100644 --- a/rules/ml/command_and_control_ml_packetbeat_rare_dns_question.toml +++ b/rules/ml/command_and_control_ml_packetbeat_rare_dns_question.toml @@ -2,7 +2,7 @@ creation_date = "2020/03/25" integration = ["endpoint", "network_traffic"] maturity = "production" -updated_date = "2024/06/18" +updated_date = "2025/01/10" [rule] anomaly_threshold = 50 @@ -82,6 +82,40 @@ tags = [ "Tactic: Command and Control", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 DNS Activity +DNS is crucial for translating domain names into IP addresses, enabling network communication. Adversaries exploit DNS by using rare domains for malicious activities like phishing or command-and-control. The 'Unusual DNS Activity' detection rule leverages machine learning to identify atypical DNS queries, signaling potential threats such as unauthorized access or data exfiltration. + +### Possible investigation steps + +- Review the DNS query logs to identify the specific rare domain that triggered the alert and determine its reputation using threat intelligence sources. +- Analyze the source IP address associated with the unusual DNS query to identify the device or user responsible for the activity. +- Check for any recent changes or anomalies in the network activity of the identified device or user, such as unusual login times or access to sensitive data. +- Investigate any related alerts or logs that might indicate a broader pattern of suspicious activity, such as multiple rare domain queries or connections to known malicious IP addresses. +- Examine endpoint security logs on the affected device for signs of malware or unauthorized software that could be responsible for the unusual DNS activity. +- Assess whether the unusual DNS activity aligns with known tactics, techniques, and procedures (TTPs) associated with command-and-control or data exfiltration, referencing the MITRE ATT&CK framework for guidance. + +### False positive analysis + +- Legitimate software updates may trigger unusual DNS queries as they contact uncommon domains for downloading updates. Users can create exceptions for known update servers to reduce false positives. +- Internal applications using dynamic DNS services might generate rare DNS queries. Identifying and whitelisting these services can help in minimizing false alerts. +- Third-party security tools or monitoring solutions may use unique DNS queries for their operations. Verify and exclude these tools from the detection rule to prevent unnecessary alerts. +- Cloud services often use diverse and uncommon domains for legitimate operations. Regularly review and update the list of trusted cloud service domains to avoid false positives. +- New or infrequently accessed legitimate websites may appear as unusual. Users should monitor and whitelist these domains if they are confirmed to be safe and necessary for business operations. + +### Response and remediation + +- Isolate the affected system from the network to prevent further communication with the suspicious DNS domain and potential data exfiltration. +- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious software. +- Review and block the identified unusual DNS domain at the network perimeter to prevent other systems from communicating with it. +- Analyze logs and network traffic to identify any other systems that may have communicated with the same unusual DNS domain and apply similar containment measures. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Restore the affected system from a known good backup if malware removal is not possible or if system integrity is in question. +- Update and enhance DNS monitoring rules to detect similar unusual DNS activity in the future, ensuring rapid identification and response to potential threats.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/ml/command_and_control_ml_packetbeat_rare_urls.toml b/rules/ml/command_and_control_ml_packetbeat_rare_urls.toml index 7e7f50eccfe..82e617c6c58 100644 --- a/rules/ml/command_and_control_ml_packetbeat_rare_urls.toml +++ b/rules/ml/command_and_control_ml_packetbeat_rare_urls.toml @@ -2,7 +2,7 @@ creation_date = "2020/03/25" integration = ["endpoint", "network_traffic"] maturity = "production" -updated_date = "2024/06/18" +updated_date = "2025/01/10" [rule] anomaly_threshold = 50 @@ -85,6 +85,41 @@ tags = [ "Tactic: Command and Control", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Web Request +The 'Unusual Web Request' detection leverages machine learning to identify rare URLs that deviate from typical web activity, potentially signaling malicious actions like initial access or data exfiltration. Adversaries exploit trusted sites by embedding uncommon URLs for payload delivery or command-and-control. This rule flags such anomalies, aiding in early threat detection and response. + +### Possible investigation steps + +- Review the alert details to identify the specific rare URL that triggered the detection and note any associated IP addresses or domains. +- Check historical logs to determine if the rare URL has been accessed previously and identify any patterns or trends in its usage. +- Investigate the source of the request by examining the user agent, referrer, and originating IP address to assess whether it aligns with known legitimate traffic or appears suspicious. +- Analyze the destination of the URL to determine if it is associated with known malicious activity or if it has been flagged in threat intelligence databases. +- Correlate the unusual web request with other security events or alerts to identify potential connections to broader attack campaigns or ongoing threats. +- Assess the impacted systems or users to determine if there are any signs of compromise, such as unexpected processes, network connections, or data exfiltration attempts. +- Consider reaching out to the user or system owner to verify if the access to the rare URL was intentional and legitimate, providing additional context for the investigation. + +### False positive analysis + +- Web scraping tools and bots can trigger false positives by making requests to uncommon URLs as part of routine internet background traffic. +- Legitimate web scanning or enumeration activities by security teams may be flagged; these should be reviewed and whitelisted if verified as non-threatening. +- Automated processes or scripts that access rare URLs for legitimate business purposes can be excluded by identifying and documenting these activities. +- Frequent access to uncommon URLs by trusted internal applications or services should be monitored and added to exception lists to prevent unnecessary alerts. +- Regularly review and update the list of excluded URLs to ensure it reflects current legitimate activities and does not inadvertently allow malicious traffic. + +### Response and remediation + +- Isolate the affected system from the network to prevent further communication with the suspicious URL and potential data exfiltration. +- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious payloads or software. +- Review and block the identified unusual URL at the network perimeter to prevent other systems from accessing it. +- Analyze network logs to identify any other systems that may have communicated with the suspicious URL and apply similar containment measures. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign. +- Implement enhanced monitoring for similar unusual web requests across the network to detect and respond to potential threats more quickly in the future. +- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to better detect and block uncommon URLs associated with command-and-control activities.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/ml/command_and_control_ml_packetbeat_rare_user_agent.toml b/rules/ml/command_and_control_ml_packetbeat_rare_user_agent.toml index 92fe092fe32..1ec179e39c8 100644 --- a/rules/ml/command_and_control_ml_packetbeat_rare_user_agent.toml +++ b/rules/ml/command_and_control_ml_packetbeat_rare_user_agent.toml @@ -2,7 +2,7 @@ creation_date = "2020/03/25" integration = ["endpoint", "network_traffic"] maturity = "production" -updated_date = "2024/06/18" +updated_date = "2025/01/10" [rule] anomaly_threshold = 50 @@ -83,6 +83,41 @@ tags = [ "Tactic: Command and Control", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Web User Agent + +User agents identify applications interacting with web servers, typically browsers. Adversaries exploit this by using non-standard user agents for malicious activities like data exfiltration or command-and-control. The 'Unusual Web User Agent' detection rule leverages machine learning to identify rare user agents, flagging potential threats from atypical processes, thus aiding in early threat detection. + +### Possible investigation steps + +- Review the specific user agent string that triggered the alert to determine if it matches known malicious patterns or tools like Burp or SQLmap. +- Identify the source and destination IP addresses involved in the alert to assess whether they are associated with known malicious activity or unusual geographic locations. +- Check the process that generated the unusual user agent to determine if it is a legitimate application or potentially malicious software. +- Analyze network traffic logs for additional context around the time of the alert to identify any related suspicious activities or patterns. +- Investigate any recent changes or installations on the system that could explain the presence of the unusual user agent, such as new software or updates. +- Correlate the alert with other security events or logs to see if there are any related indicators of compromise or ongoing threats. + +### False positive analysis + +- Non-malicious applications like weather monitoring or stock-trading programs may use uncommon user agents. Regularly review and whitelist these applications to prevent them from triggering false positives. +- Automated tools such as web scrapers or bots can generate unusual user agents. Identify and document these tools if they are part of legitimate business operations, and create exceptions for them in the detection rule. +- Internal scanners or monitoring tools might use non-standard user agents. Ensure these tools are recognized and excluded from alerts by updating the rule's exception list. +- Regularly update the list of known benign user agents to reflect changes in legitimate software and tools used within the organization, reducing unnecessary alerts. +- Collaborate with IT and security teams to maintain an up-to-date inventory of authorized applications and their user agents, ensuring that only truly suspicious activities are flagged. + +### Response and remediation + +- Isolate the affected system from the network to prevent further data exfiltration or command-and-control communication. +- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious software. +- Review and analyze the logs of the affected system and network traffic to identify the source and scope of the unusual user agent activity. +- Block the identified malicious IP addresses or domains associated with the unusual user agent in the firewall and intrusion prevention systems. +- Update and patch all software and systems to close any vulnerabilities that may have been exploited by the adversary. +- Restore the affected system from a clean backup if malware removal is not feasible or if the system integrity is compromised. +- Report the incident to the appropriate internal teams and, if necessary, escalate to external cybersecurity authorities or partners for further investigation and support.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/ml/credential_access_ml_auth_spike_in_logon_events.toml b/rules/ml/credential_access_ml_auth_spike_in_logon_events.toml index 7c9569ca0b5..6e0b05c6e0f 100644 --- a/rules/ml/credential_access_ml_auth_spike_in_logon_events.toml +++ b/rules/ml/credential_access_ml_auth_spike_in_logon_events.toml @@ -2,7 +2,7 @@ creation_date = "2021/06/10" integration = ["auditd_manager", "endpoint", "system"] maturity = "production" -updated_date = "2024/06/18" +updated_date = "2025/01/10" [rule] anomaly_threshold = 75 @@ -98,6 +98,40 @@ tags = [ "Tactic: Credential Access", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Spike in Logon Events +The 'Spike in Logon Events' detection leverages machine learning to identify anomalies in authentication patterns, signaling potential threats like password spraying or brute force attacks. Adversaries exploit these methods to gain unauthorized access by overwhelming systems with login attempts. This rule detects unusual surges in successful logins, indicating possible credential access tactics, and aids in preemptive threat mitigation. + +### Possible investigation steps + +- Review the timestamp and source of the spike in logon events to determine the time frame and systems affected. +- Analyze the user accounts involved in the spike to identify any patterns or anomalies, such as accounts with multiple logins from different locations or IP addresses. +- Check for any recent changes in user permissions or roles that could explain the increase in logon events. +- Investigate the IP addresses associated with the logon events to identify any known malicious sources or unusual geographic locations. +- Correlate the logon events with other security alerts or logs, such as failed login attempts, to identify potential password spraying or brute force activities. +- Assess whether there are any concurrent alerts or indicators of compromise that could suggest a broader attack campaign. + +### False positive analysis + +- High-volume legitimate logins from automated systems or scripts can trigger false positives. Identify and whitelist these systems to prevent unnecessary alerts. +- Scheduled batch processes or system maintenance activities may cause spikes in logon events. Exclude these known activities by setting up exceptions based on time and source. +- Users with roles that require frequent logins, such as IT administrators or customer support agents, might be flagged. Create user-based exceptions for these roles to reduce false positives. +- Integration with third-party services that authenticate frequently can lead to detection triggers. Review and exclude these services from the rule to avoid misclassification. +- Consider adjusting the sensitivity of the machine learning model if certain patterns are consistently flagged as anomalies but are verified as legitimate. + +### Response and remediation + +- Immediately isolate the affected user accounts to prevent further unauthorized access. This can be done by disabling the accounts or resetting passwords. +- Conduct a thorough review of recent authentication logs to identify any other accounts that may have been compromised or targeted. +- Implement multi-factor authentication (MFA) for all user accounts to add an additional layer of security against unauthorized access. +- Notify the security operations team to monitor for any further suspicious logon activities and to ensure that the threat is contained. +- Escalate the incident to the incident response team if there is evidence of a broader attack or if sensitive data may have been accessed. +- Review and update access controls and permissions to ensure that users have the minimum necessary access to perform their roles. +- Enhance monitoring and alerting mechanisms to detect similar spikes in logon events in the future, ensuring rapid response to potential threats.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/ml/credential_access_ml_linux_anomalous_metadata_process.toml b/rules/ml/credential_access_ml_linux_anomalous_metadata_process.toml index 25165dddda5..b74e9c8a20a 100644 --- a/rules/ml/credential_access_ml_linux_anomalous_metadata_process.toml +++ b/rules/ml/credential_access_ml_linux_anomalous_metadata_process.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/22" integration = ["auditd_manager", "endpoint"] maturity = "production" -updated_date = "2024/06/18" +updated_date = "2025/01/10" [rule] anomaly_threshold = 50 @@ -84,6 +84,41 @@ tags = [ "Tactic: Credential Access", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Linux Process Calling the Metadata Service + +In cloud environments, the metadata service provides essential instance-specific data, including credentials and configuration scripts. Adversaries may exploit this service by using atypical processes to access sensitive information, potentially leading to credential theft. The detection rule leverages machine learning to identify anomalous process behavior, flagging unusual access patterns indicative of malicious intent. + +### Possible investigation steps + +- Review the process name and command line arguments associated with the alert to identify any unusual or suspicious activity. +- Check the user account under which the process is running to determine if it has legitimate access to the metadata service. +- Investigate the process's parent process to understand the context of how it was initiated and whether it aligns with expected behavior. +- Analyze network logs to verify if the process made any outbound connections to the metadata service and assess the volume and frequency of these requests. +- Cross-reference the process and user information with recent changes or deployments in the environment to rule out any legitimate use cases. +- Examine system logs for any other suspicious activities or anomalies around the time the alert was triggered, such as unauthorized access attempts or privilege escalations. + +### False positive analysis + +- Routine system updates or maintenance scripts may access the metadata service, triggering false positives. Users can create exceptions for known update processes to prevent unnecessary alerts. +- Automated backup or monitoring tools might interact with the metadata service as part of their normal operations. Identify these tools and whitelist their processes to reduce false alarms. +- Custom scripts developed in-house for configuration management might access the metadata service. Review these scripts and add them to an exception list if they are verified as non-threatening. +- Cloud management agents provided by the cloud service provider may access the metadata service for legitimate purposes. Verify these agents and exclude them from the detection rule to avoid false positives. +- Development or testing environments often have processes that mimic production behavior, including metadata service access. Ensure these environments are accounted for in the rule configuration to minimize false alerts. + +### Response and remediation + +- Isolate the affected instance immediately to prevent further unauthorized access to the metadata service and potential lateral movement within the network. +- Terminate the unusual process accessing the metadata service to stop any ongoing data exfiltration or credential harvesting. +- Conduct a thorough review of access logs and process execution history on the affected instance to identify any additional unauthorized activities or compromised credentials. +- Rotate all credentials and secrets that may have been exposed through the metadata service to mitigate the risk of credential theft and unauthorized access. +- Implement network segmentation and access controls to restrict access to the metadata service, ensuring only authorized processes and users can interact with it. +- Escalate the incident to the security operations team for further investigation and to determine if additional instances or services have been compromised. +- Update and enhance monitoring rules to detect similar anomalous behaviors in the future, focusing on unusual process activities and access patterns to the metadata service.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/ml/credential_access_ml_linux_anomalous_metadata_user.toml b/rules/ml/credential_access_ml_linux_anomalous_metadata_user.toml index 1e960dc1f49..3277fec81e1 100644 --- a/rules/ml/credential_access_ml_linux_anomalous_metadata_user.toml +++ b/rules/ml/credential_access_ml_linux_anomalous_metadata_user.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/22" integration = ["auditd_manager", "endpoint"] maturity = "production" -updated_date = "2024/06/18" +updated_date = "2025/01/10" [rule] anomaly_threshold = 75 @@ -84,6 +84,42 @@ tags = [ "Tactic: Credential Access", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Linux User Calling the Metadata Service + +Cloud platforms provide a metadata service that allows instances to access configuration data, including credentials. Adversaries may exploit this by using unusual Linux users to query the service, aiming to extract sensitive information. The detection rule leverages machine learning to identify anomalous access patterns, focusing on credential access tactics, thus alerting analysts to potential threats. + +### Possible investigation steps + +- Review the alert details to identify the specific Linux user account that accessed the metadata service and the timestamp of the activity. +- Check the user's login history and recent activity on the system to determine if the access pattern is consistent with their normal behavior or if it appears suspicious. +- Investigate the source IP address and geolocation associated with the metadata service access to identify any anomalies or unexpected locations. +- Examine system logs and audit trails for any additional unauthorized or unusual access attempts around the same time frame. +- Verify if the user account has legitimate reasons to access the metadata service, such as running specific applications or scripts that require metadata information. +- Assess whether there have been any recent changes to user permissions or roles that could explain the access, and ensure that these changes were authorized. +- If suspicious activity is confirmed, consider isolating the affected instance and user account to prevent further unauthorized access while conducting a deeper investigation. + +### False positive analysis + +- Routine administrative scripts may access the metadata service for legitimate configuration purposes. To handle this, identify and whitelist these scripts to prevent unnecessary alerts. +- Automated backup or monitoring tools might query the metadata service as part of their normal operations. Exclude these tools by adding them to an exception list based on their user accounts or process identifiers. +- Scheduled tasks or cron jobs that require metadata access for updates or maintenance can trigger false positives. Review and document these tasks, then configure the rule to ignore these specific access patterns. +- Development or testing environments often simulate metadata service access to mimic production scenarios. Ensure these environments are recognized and excluded from the rule to avoid false alerts. +- Temporary user accounts created for specific projects or tasks may access the metadata service. Regularly audit these accounts and adjust the rule to exclude them if their access is deemed non-threatening. + +### Response and remediation + +- Immediately isolate the affected Linux instance from the network to prevent further unauthorized access or data exfiltration. +- Revoke any credentials or tokens that may have been exposed or accessed through the metadata service to prevent misuse. +- Conduct a thorough review of the instance's user accounts and permissions, removing any unauthorized or suspicious accounts and tightening access controls. +- Analyze system logs and metadata service access logs to identify the source and scope of the breach, focusing on the unusual user activity. +- Restore the affected instance from a known good backup if any unauthorized changes or malware are detected. +- Implement additional monitoring and alerting for metadata service access, particularly for unusual user accounts, to detect similar threats in the future. +- Escalate the incident to the security operations team for further investigation and to determine if additional instances or services are affected.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/ml/credential_access_ml_suspicious_login_activity.toml b/rules/ml/credential_access_ml_suspicious_login_activity.toml index ee7a91db756..fa4ca3023ec 100644 --- a/rules/ml/credential_access_ml_suspicious_login_activity.toml +++ b/rules/ml/credential_access_ml_suspicious_login_activity.toml @@ -2,7 +2,7 @@ creation_date = "2020/03/25" integration = ["auditd_manager", "endpoint", "system"] maturity = "production" -updated_date = "2024/06/18" +updated_date = "2025/01/10" [rule] anomaly_threshold = 50 @@ -95,6 +95,40 @@ tags = [ "Tactic: Credential Access", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Login Activity +The 'Unusual Login Activity' detection leverages machine learning to identify anomalies in authentication patterns, flagging potential brute force attacks. Adversaries exploit credential access by attempting numerous logins to gain unauthorized entry. This rule assesses login frequency and patterns, alerting analysts to deviations indicative of credential abuse, thus enhancing threat detection and identity audit processes. + +### Possible investigation steps + +- Review the source IP addresses associated with the unusual login attempts to determine if they are known or suspicious. +- Check the user accounts involved in the alert for any recent changes or unusual activity, such as password resets or privilege escalations. +- Analyze the timestamps of the login attempts to identify patterns or timeframes that may indicate automated or scripted attacks. +- Correlate the login attempts with other security events or logs to identify any concurrent suspicious activities, such as failed login attempts or access to sensitive resources. +- Investigate the geographic locations of the login attempts to see if they align with the user's typical login behavior or if they suggest potential compromise. +- Assess the risk score and severity of the alert in the context of the organization's security posture and any ongoing threats or incidents. + +### False positive analysis + +- High login activity from automated scripts or scheduled tasks can trigger false positives. Identify and whitelist these known scripts to prevent unnecessary alerts. +- Employees using shared accounts may cause an increase in login attempts. Implement user-specific accounts and monitor shared account usage to reduce false positives. +- Frequent logins from IT personnel conducting routine maintenance can be misinterpreted as unusual activity. Exclude these users or adjust thresholds for specific roles to minimize false alerts. +- Users with legitimate reasons for high login frequency, such as customer support staff, should be identified and their activity patterns analyzed to adjust detection parameters accordingly. +- Remote workers using VPNs or accessing systems from multiple locations might trigger alerts. Consider location-based exceptions for known remote access points to avoid false positives. + +### Response and remediation + +- Immediately isolate the affected user accounts to prevent further unauthorized access and contain the threat. +- Reset passwords for the compromised accounts and enforce multi-factor authentication (MFA) to enhance security. +- Conduct a thorough review of recent login activity and access logs to identify any unauthorized access or data exfiltration. +- Notify the security operations team to monitor for any further suspicious activity and ensure continuous surveillance of the affected systems. +- Escalate the incident to the incident response team if there is evidence of data compromise or if the attack persists despite initial containment efforts. +- Implement additional monitoring rules to detect similar brute force attempts in the future, focusing on login frequency and patterns. +- Review and update access controls and authentication policies to prevent recurrence, ensuring they align with best practices for credential security.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/ml/credential_access_ml_windows_anomalous_metadata_process.toml b/rules/ml/credential_access_ml_windows_anomalous_metadata_process.toml index 33d8ed7590e..2338c7c899c 100644 --- a/rules/ml/credential_access_ml_windows_anomalous_metadata_process.toml +++ b/rules/ml/credential_access_ml_windows_anomalous_metadata_process.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/22" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -80,6 +80,40 @@ tags = [ "Tactic: Credential Access", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Windows Process Calling the Metadata Service + +In cloud environments, the metadata service provides essential instance information, including credentials and configuration data. Adversaries may exploit this by using atypical Windows processes to access the service, aiming to extract sensitive information. The detection rule leverages machine learning to identify anomalies in process behavior, flagging potential credential access attempts by unusual processes. + +### Possible investigation steps + +- Review the process name and command line arguments associated with the alert to identify any unusual or suspicious activity. +- Check the parent process of the flagged process to understand the context of how it was initiated and assess if it aligns with expected behavior. +- Investigate the user account under which the process was executed to determine if it has legitimate access to the metadata service or if it has been compromised. +- Analyze network logs to identify any outbound connections to the metadata service from the flagged process, noting any unusual patterns or destinations. +- Cross-reference the process and user activity with recent changes or deployments in the environment to rule out false positives related to legitimate administrative actions. +- Consult threat intelligence sources to see if the process or command line arguments have been associated with known malicious activity or campaigns. + +### False positive analysis + +- Routine system updates or maintenance scripts may trigger the rule. Review the process details and verify if they align with scheduled maintenance activities. If confirmed, consider adding these processes to an exception list. +- Legitimate software or security tools that access the metadata service for configuration purposes might be flagged. Identify these tools and create exceptions for their known processes to prevent future alerts. +- Automated backup or monitoring solutions that interact with the metadata service could be misidentified as threats. Validate these processes and exclude them if they are part of authorized operations. +- Custom scripts developed in-house for cloud management tasks may access the metadata service. Ensure these scripts are documented and, if safe, add them to the list of exceptions to reduce false positives. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate the unusual process accessing the metadata service to stop any ongoing credential harvesting attempts. +- Conduct a thorough review of the system's event logs and process history to identify any additional indicators of compromise or related malicious activity. +- Change all credentials that may have been exposed or accessed through the metadata service to mitigate the risk of unauthorized access. +- Implement network segmentation to limit access to the metadata service, ensuring only authorized processes and users can interact with it. +- Escalate the incident to the security operations center (SOC) for further analysis and to determine if the threat is part of a larger attack campaign. +- Update and enhance endpoint detection and response (EDR) solutions to improve monitoring and alerting for similar anomalous process behaviors in the future.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/ml/credential_access_ml_windows_anomalous_metadata_user.toml b/rules/ml/credential_access_ml_windows_anomalous_metadata_user.toml index 2e6b058293f..fb921e5d0a6 100644 --- a/rules/ml/credential_access_ml_windows_anomalous_metadata_user.toml +++ b/rules/ml/credential_access_ml_windows_anomalous_metadata_user.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/22" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -80,6 +80,42 @@ tags = [ "Tactic: Credential Access", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Windows User Calling the Metadata Service + +Cloud platforms provide a metadata service that allows instances to access configuration data, including credentials. Adversaries may exploit this by using compromised Windows accounts to query the service, aiming to harvest sensitive information. The detection rule leverages machine learning to identify atypical access patterns by Windows users, flagging potential credential access attempts. + +### Possible investigation steps + +- Review the alert details to identify the specific Windows user account involved in the unusual access to the metadata service. +- Check the timestamp of the access attempt to correlate with any known scheduled tasks or legitimate user activities. +- Investigate the source IP address and device from which the metadata service was accessed to determine if it aligns with expected user behavior or known assets. +- Examine recent login and access logs for the identified user account to detect any other suspicious activities or anomalies. +- Assess whether there have been any recent changes to the user's permissions or roles that could explain the access attempt. +- Look for any other alerts or incidents involving the same user account or device to identify potential patterns of malicious behavior. +- Consult with the user or their manager to verify if the access was legitimate or if the account may have been compromised. + +### False positive analysis + +- Routine administrative tasks by IT personnel may trigger alerts. Review access logs to confirm legitimate administrative actions and consider whitelisting specific user accounts or IP addresses. +- Automated scripts or scheduled tasks that query the metadata service for configuration updates can be mistaken for suspicious activity. Identify these scripts and exclude them from the rule by adding them to an exception list. +- Cloud management tools that regularly access the metadata service for monitoring or configuration purposes might be flagged. Verify these tools and create exceptions for their known access patterns. +- Instances where legitimate software updates or patch management processes access the metadata service should be reviewed. Document these processes and exclude them from triggering alerts. +- Temporary access by third-party vendors or consultants may appear unusual. Ensure their access is documented and create temporary exceptions during their engagement period. + +### Response and remediation + +- Immediately isolate the affected Windows system from the network to prevent further unauthorized access to the metadata service. +- Revoke any potentially compromised credentials identified during the investigation and issue new credentials to affected users. +- Conduct a thorough review of access logs to identify any unauthorized data access or exfiltration attempts from the metadata service. +- Implement additional monitoring on the affected system and similar systems to detect any further anomalous access attempts. +- Escalate the incident to the security operations center (SOC) for a deeper investigation into potential lateral movement or other compromised systems. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Review and enhance access controls and permissions for the metadata service to ensure only authorized users can access sensitive information.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/ml/discovery_ml_linux_system_information_discovery.toml b/rules/ml/discovery_ml_linux_system_information_discovery.toml index 2e06a27dba8..c19ac969748 100644 --- a/rules/ml/discovery_ml_linux_system_information_discovery.toml +++ b/rules/ml/discovery_ml_linux_system_information_discovery.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/03" integration = ["auditd_manager", "endpoint"] maturity = "production" -updated_date = "2024/06/18" +updated_date = "2025/01/10" [rule] anomaly_threshold = 75 @@ -86,6 +86,41 @@ tags = [ "Tactic: Discovery", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Linux System Information Discovery Activity + +In Linux environments, system information discovery involves commands that reveal details about system configuration and software versions. While typically used for legitimate troubleshooting, adversaries exploit this to gather intelligence for further attacks, such as privilege escalation. The detection rule leverages machine learning to identify atypical usage patterns, flagging potential misuse by compromised accounts. + +### Possible investigation steps + +- Review the alert details to identify the specific user account and the command executed that triggered the alert. Focus on any unusual or unexpected user context. +- Check the user's activity history to determine if this type of command execution is typical for the user or if it deviates from their normal behavior. +- Investigate the source IP address and hostname associated with the alert to verify if they are consistent with the user's usual access patterns or if they indicate potential unauthorized access. +- Examine system logs for any additional suspicious activities or anomalies around the time of the alert, such as failed login attempts or other unusual commands executed. +- Assess whether the command executed could be part of a legitimate troubleshooting process or if it aligns with known tactics for privilege escalation or persistence. +- If the account is suspected to be compromised, consider resetting the user's credentials and conducting a broader investigation into potential lateral movement or data exfiltration activities. + +### False positive analysis + +- Routine administrative tasks by system administrators may trigger alerts. To manage this, create exceptions for known admin accounts performing regular maintenance. +- Automated scripts for system monitoring or inventory management can be flagged. Identify and whitelist these scripts to prevent unnecessary alerts. +- Scheduled jobs or cron tasks that gather system information for legitimate purposes might be detected. Review and exclude these tasks from the rule to reduce false positives. +- Development or testing environments where frequent system information queries are normal can cause alerts. Consider excluding these environments from monitoring or adjusting the sensitivity of the rule for these contexts. +- Security tools that perform regular system scans may be misidentified. Ensure these tools are recognized and excluded from triggering the rule. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified as part of the unusual system information discovery activity. +- Review and reset credentials for the potentially compromised account to prevent further misuse. +- Conduct a thorough examination of system logs and command history to identify any additional malicious activities or indicators of compromise. +- Apply security patches and updates to the affected system to mitigate any known vulnerabilities that could be exploited for privilege escalation. +- Implement enhanced monitoring on the affected system and similar environments to detect any recurrence of unusual system information discovery activities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/ml/discovery_ml_linux_system_network_configuration_discovery.toml b/rules/ml/discovery_ml_linux_system_network_configuration_discovery.toml index eae2bbef640..1a179b9740e 100644 --- a/rules/ml/discovery_ml_linux_system_network_configuration_discovery.toml +++ b/rules/ml/discovery_ml_linux_system_network_configuration_discovery.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/03" integration = ["auditd_manager", "endpoint"] maturity = "production" -updated_date = "2024/06/18" +updated_date = "2025/01/10" [rule] anomaly_threshold = 25 @@ -86,6 +86,41 @@ tags = [ "Tactic: Discovery", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Linux Network Configuration Discovery + +In Linux environments, network configuration tools are essential for managing and troubleshooting network settings. Adversaries may exploit these tools to gather network details, aiding in lateral movement or further reconnaissance. The detection rule leverages machine learning to identify atypical usage patterns of network commands by unexpected users, signaling potential account compromise or unauthorized network probing. + +### Possible investigation steps + +- Review the alert details to identify the specific network configuration commands executed and the user account involved. Focus on commands that are typically used for network discovery, such as `ifconfig`, `ip`, `netstat`, or `route`. +- Check the user's login history and session details to determine if the account activity aligns with the user's normal behavior or if there are signs of unauthorized access, such as logins from unusual IP addresses or at odd times. +- Investigate the user's role and responsibilities to assess whether they have a legitimate reason to perform network configuration discovery. This can help determine if the activity is expected or suspicious. +- Examine recent changes in user permissions or group memberships that might have allowed the execution of network configuration commands by an unexpected user. +- Correlate the alert with other security events or logs, such as authentication logs, to identify any related suspicious activities, such as failed login attempts or privilege escalation attempts. +- If the account is suspected to be compromised, initiate a password reset and review the system for any signs of further compromise or malicious activity, such as unauthorized software installations or data exfiltration attempts. + +### False positive analysis + +- Routine administrative tasks by system administrators may trigger the rule. To manage this, create exceptions for known admin accounts performing regular network configuration checks. +- Automated scripts or cron jobs that perform network diagnostics can be mistaken for unusual activity. Identify and whitelist these scripts to prevent false alerts. +- Network monitoring tools running under specific service accounts might be flagged. Ensure these service accounts are documented and excluded from the rule. +- Developers or IT staff conducting legitimate troubleshooting in non-production environments may cause alerts. Establish a process to temporarily exclude these users during known maintenance windows. +- New employees or contractors performing onboarding tasks might trigger the rule. Implement a review process to quickly assess and exclude these cases if they are verified as non-threatening. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes or sessions initiated by the unusual user to halt ongoing reconnaissance activities. +- Conduct a thorough review of the affected user's account for signs of compromise, such as unauthorized access attempts or changes in user privileges. +- Reset the credentials of the compromised account and enforce multi-factor authentication to prevent future unauthorized access. +- Analyze network logs and system activity to identify any additional systems that may have been accessed or probed by the adversary. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional containment measures are necessary. +- Update detection mechanisms to include newly identified indicators of compromise (IOCs) and enhance monitoring for similar unusual network configuration discovery activities.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/ml/discovery_ml_linux_system_network_connection_discovery.toml b/rules/ml/discovery_ml_linux_system_network_connection_discovery.toml index 83d47f0cbe2..0d47bac1398 100644 --- a/rules/ml/discovery_ml_linux_system_network_connection_discovery.toml +++ b/rules/ml/discovery_ml_linux_system_network_connection_discovery.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/03" integration = ["auditd_manager", "endpoint"] maturity = "production" -updated_date = "2024/06/18" +updated_date = "2025/01/10" [rule] anomaly_threshold = 25 @@ -86,6 +86,41 @@ tags = [ "Tactic: Discovery", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Linux Network Connection Discovery + +In Linux environments, network connection discovery tools help administrators understand system connectivity. Adversaries exploit these tools to map networks, aiding in lateral movement and further attacks. The detection rule leverages machine learning to identify atypical usage patterns by unusual users, signaling potential account compromise or unauthorized network probing activities. + +### Possible investigation steps + +- Review the alert details to identify the specific user account and the command executed that triggered the alert. +- Check the user's activity history to determine if this behavior is consistent with their normal usage patterns or if it is anomalous. +- Investigate the source IP address and hostname associated with the command execution to verify if they are known and trusted within the network. +- Examine system logs for any additional suspicious activities or commands executed by the same user account around the time of the alert. +- Assess the user's access permissions and recent changes to their account to identify any unauthorized modifications or potential compromise. +- Correlate the alert with other security events or alerts to determine if this activity is part of a larger attack pattern or campaign. + +### False positive analysis + +- Routine administrative tasks by system administrators can trigger alerts. Regularly review and whitelist known administrator accounts performing legitimate network discovery. +- Automated scripts or monitoring tools that perform network checks may be flagged. Identify and exclude these scripts from triggering alerts by adding them to an exception list. +- Uncommon troubleshooting activities by support teams might be misidentified. Document and approve these activities to prevent false positives. +- Scheduled maintenance activities involving network discovery should be accounted for. Create a schedule-based exception to avoid unnecessary alerts during these periods. +- New employees or contractors performing legitimate network discovery as part of their onboarding process can be mistaken for threats. Ensure their activities are monitored and approved by the IT department. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes or sessions initiated by the unusual user to halt ongoing network discovery activities. +- Conduct a thorough review of the affected user's account activity and permissions to identify any unauthorized changes or access patterns. +- Reset the credentials of the compromised account and enforce multi-factor authentication to prevent further unauthorized access. +- Analyze network logs and system logs to identify any additional systems that may have been accessed or probed by the threat actor. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or accounts are compromised. +- Update and enhance network monitoring and alerting rules to detect similar unauthorized network discovery activities in the future.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/ml/discovery_ml_linux_system_process_discovery.toml b/rules/ml/discovery_ml_linux_system_process_discovery.toml index 9eadd5f1c4b..693a4307405 100644 --- a/rules/ml/discovery_ml_linux_system_process_discovery.toml +++ b/rules/ml/discovery_ml_linux_system_process_discovery.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/03" integration = ["auditd_manager", "endpoint"] maturity = "production" -updated_date = "2024/06/18" +updated_date = "2025/01/10" [rule] anomaly_threshold = 50 @@ -86,6 +86,41 @@ tags = [ "Tactic: Discovery", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Linux Process Discovery Activity + +In Linux environments, process discovery commands help users and administrators understand active processes, aiding in system management and troubleshooting. However, adversaries can exploit these commands to map running applications, potentially identifying vulnerabilities for privilege escalation or persistence. The detection rule leverages machine learning to identify atypical usage patterns, flagging potential threats when process discovery occurs from unexpected user contexts, thus helping to preemptively mitigate risks associated with compromised accounts. + +### Possible investigation steps + +- Review the user context from which the process discovery command was executed to determine if the user account is expected to perform such actions. +- Check the command history for the user account to identify any other unusual or unauthorized commands executed around the same time. +- Analyze the process discovery command details, including the specific command used and its parameters, to understand the intent and scope of the activity. +- Investigate the source IP address and host from which the command was executed to verify if it aligns with known and authorized devices for the user. +- Examine recent authentication logs for the user account to identify any suspicious login attempts or anomalies in login patterns. +- Correlate the activity with any other alerts or logs that might indicate a broader attack pattern or compromise, such as privilege escalation attempts or lateral movement. + +### False positive analysis + +- System administrators performing routine maintenance or troubleshooting may trigger the rule. To manage this, create exceptions for known administrator accounts or specific maintenance windows. +- Automated scripts or monitoring tools that regularly check system processes can be mistaken for unusual activity. Identify these scripts and whitelist their execution context to prevent false alerts. +- New software installations or updates might involve process discovery commands as part of their setup. Monitor installation activities and temporarily adjust the rule sensitivity during these periods. +- Developers or power users who frequently use process discovery commands for legitimate purposes can be excluded by adding their user accounts to an exception list, ensuring their activities do not trigger false positives. +- Training or testing environments where process discovery is part of normal operations should be configured with separate rules or exceptions to avoid unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the threat actor. +- Terminate any suspicious processes identified during the investigation to halt potential malicious activity. +- Change passwords for the compromised account and any other accounts that may have been accessed using the same credentials to prevent further unauthorized access. +- Conduct a thorough review of system logs and user activity to identify any additional signs of compromise or unauthorized access attempts. +- Restore the system from a known good backup if any malicious modifications or persistence mechanisms are detected. +- Implement additional monitoring on the affected system and similar environments to detect any recurrence of unusual process discovery activity. +- Escalate the incident to the security operations team for further analysis and to determine if broader organizational impacts need to be addressed.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/ml/discovery_ml_linux_system_user_discovery.toml b/rules/ml/discovery_ml_linux_system_user_discovery.toml index c7ce566570c..1d34ad725d6 100644 --- a/rules/ml/discovery_ml_linux_system_user_discovery.toml +++ b/rules/ml/discovery_ml_linux_system_user_discovery.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/03" integration = ["auditd_manager", "endpoint"] maturity = "production" -updated_date = "2024/06/18" +updated_date = "2025/01/10" [rule] anomaly_threshold = 75 @@ -86,6 +86,40 @@ tags = [ "Tactic: Discovery", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Linux User Discovery Activity + +In Linux environments, user discovery commands help identify active users and system owners, crucial for system management. However, adversaries exploit this by executing these commands from atypical user contexts, often indicating account compromise. The detection rule leverages machine learning to identify anomalies in user discovery activities, flagging potential threats for further investigation. + +### Possible investigation steps + +- Review the alert details to identify the specific user account and the command executed that triggered the alert. +- Check the login history and session details for the identified user account to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Investigate the source IP address and hostname associated with the user session to verify if they are known and trusted within the organization. +- Examine recent changes to user permissions or group memberships for the identified account to detect any unauthorized modifications. +- Look for any additional unusual or unexpected commands executed by the same user account around the time of the alert to identify potential follow-up malicious activities. +- Correlate the alert with other security events or logs, such as authentication logs or network traffic, to gather more context and assess the scope of the potential compromise. + +### False positive analysis + +- System administrators performing routine checks may trigger the rule. To manage this, create exceptions for known admin accounts executing user discovery commands during regular maintenance windows. +- Automated scripts or monitoring tools that run user discovery commands can cause false positives. Identify these scripts and whitelist their execution paths or user accounts. +- Developers or IT staff conducting legitimate troubleshooting might be flagged. Document these activities and exclude specific user accounts or IP addresses from the rule. +- Scheduled tasks or cron jobs that include user discovery commands could be misinterpreted as threats. Review and exclude these tasks from the detection rule to prevent unnecessary alerts. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes associated with the unusual user discovery activity to halt potential malicious actions. +- Conduct a thorough review of the affected user account's recent activities and access logs to identify any unauthorized changes or access. +- Reset the credentials of the compromised account and any other accounts that may have been accessed using the compromised credentials. +- Implement additional monitoring on the affected system and user accounts to detect any further suspicious activities or attempts to regain access. +- Escalate the incident to the security operations team for a deeper investigation into potential related threats, such as credential dumping or privilege escalation attempts. +- Review and update access controls and permissions to ensure that only authorized users have access to sensitive systems and data, reducing the risk of future compromises.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/ml/execution_ml_windows_anomalous_script.toml b/rules/ml/execution_ml_windows_anomalous_script.toml index 43a98b856eb..f79b1eace2c 100644 --- a/rules/ml/execution_ml_windows_anomalous_script.toml +++ b/rules/ml/execution_ml_windows_anomalous_script.toml @@ -2,7 +2,7 @@ creation_date = "2020/03/25" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -84,6 +84,41 @@ tags = [ "Tactic: Execution", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Powershell Script + +PowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries often exploit its capabilities to execute malicious scripts, leveraging obfuscation to evade detection. The 'Suspicious Powershell Script' detection rule employs machine learning to identify unusual script characteristics, such as obfuscation, indicating potential threats. By analyzing these anomalies, the rule aids in early threat detection and mitigation. + +### Possible investigation steps + +- Review the alert details to identify the specific PowerShell script or command that triggered the detection, focusing on any obfuscated elements. +- Examine the source endpoint and user account associated with the alert to determine if the activity aligns with expected behavior or if it appears suspicious. +- Check the execution history on the affected endpoint for any other unusual or unauthorized PowerShell commands or scripts executed around the same time. +- Investigate the network activity from the source endpoint to identify any connections to known malicious IP addresses or domains. +- Correlate the alert with other security events or logs, such as antivirus alerts or firewall logs, to gather additional context and assess the potential impact. +- Consult threat intelligence sources to determine if the detected script or its components are associated with known malware or attack campaigns. + +### False positive analysis + +- Legitimate administrative scripts may trigger the rule due to obfuscation techniques used for efficiency or security. Review the script's purpose and source to determine its legitimacy. +- Automated deployment tools often use PowerShell scripts that appear obfuscated. Identify and whitelist these tools to prevent unnecessary alerts. +- Security software updates might use obfuscated scripts for protection against tampering. Verify the update source and add exceptions for known trusted vendors. +- Custom scripts developed in-house for specific tasks may use obfuscation for intellectual property protection. Document and exclude these scripts after confirming their safety. +- Regularly review and update the list of exceptions to ensure that only verified non-threatening scripts are excluded, maintaining the effectiveness of the detection rule. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity. +- Terminate any suspicious PowerShell processes identified on the affected system to halt the execution of potentially harmful scripts. +- Conduct a thorough review of the PowerShell script logs and execution history on the affected system to identify any unauthorized or malicious commands executed. +- Restore the affected system from a known good backup if any malicious activity is confirmed, ensuring that the backup is free from compromise. +- Update and patch the affected system to the latest security standards to close any vulnerabilities that may have been exploited. +- Implement enhanced monitoring for PowerShell activity across the network, focusing on detecting obfuscation and unusual script characteristics. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/ml/initial_access_ml_auth_rare_source_ip_for_a_user.toml b/rules/ml/initial_access_ml_auth_rare_source_ip_for_a_user.toml index f6b95127b55..0208ddf41a7 100644 --- a/rules/ml/initial_access_ml_auth_rare_source_ip_for_a_user.toml +++ b/rules/ml/initial_access_ml_auth_rare_source_ip_for_a_user.toml @@ -2,7 +2,7 @@ creation_date = "2021/06/10" integration = ["auditd_manager", "endpoint", "system"] maturity = "production" -updated_date = "2024/06/18" +updated_date = "2025/01/10" [rule] anomaly_threshold = 75 @@ -95,6 +95,40 @@ tags = [ "Tactic: Initial Access", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Source IP for a User to Logon from +Machine learning models analyze login patterns to identify atypical IP addresses for users, which may indicate compromised accounts or lateral movement by threat actors. Adversaries exploit valid credentials to access systems from unexpected locations. This detection rule flags such anomalies, aiding in early identification of unauthorized access attempts, thereby enhancing security posture. + +### Possible investigation steps + +- Review the login details to identify the unusual source IP address and compare it with the user's typical login locations and times. +- Check the geolocation of the unusual IP address to determine if it aligns with any known travel or business activities of the user. +- Analyze the user's recent activity logs to identify any other suspicious behavior or anomalies that might indicate account compromise. +- Investigate if there are any other users or systems that have logged in from the same unusual IP address, which could suggest lateral movement. +- Contact the user to verify if they recognize the login activity and if they have recently traveled or used a VPN that might explain the unusual IP address. +- Cross-reference the unusual IP address with threat intelligence sources to determine if it is associated with known malicious activity. + +### False positive analysis + +- Users frequently traveling or working remotely may trigger false positives due to legitimate logins from various locations. To manage this, create exceptions for known travel patterns or remote work IP ranges. +- Employees using VPNs or proxy services can appear to log in from unusual IP addresses. Identify and whitelist IP ranges associated with company-approved VPNs or proxies. +- Shared accounts used by multiple users across different locations can generate alerts. Implement stricter access controls or assign unique credentials to each user to reduce false positives. +- Automated systems or scripts that log in from different IP addresses might be flagged. Document and exclude these systems from the rule if they are verified as non-threatening. +- Regularly review and update the list of excluded IP addresses to ensure that only legitimate exceptions are maintained, reducing the risk of overlooking genuine threats. + +### Response and remediation + +- Immediately isolate the affected user account by disabling it to prevent further unauthorized access. +- Conduct a password reset for the compromised account and ensure the new password adheres to strong security policies. +- Review and terminate any active sessions associated with the unusual IP address to cut off any ongoing unauthorized access. +- Analyze logs to identify any lateral movement or additional compromised accounts and isolate those accounts as necessary. +- Notify the user of the suspicious activity and verify if they recognize the unusual IP address or if they have recently traveled. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems or accounts have been affected. +- Implement IP whitelisting or geofencing rules to restrict access from unexpected locations, enhancing future detection and prevention.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/ml/ml_high_count_network_denies.toml b/rules/ml/ml_high_count_network_denies.toml index c0f5fc17b56..bdabd7f7dd9 100644 --- a/rules/ml/ml_high_count_network_denies.toml +++ b/rules/ml/ml_high_count_network_denies.toml @@ -2,7 +2,7 @@ creation_date = "2021/04/05" integration = ["endpoint", "network_traffic"] maturity = "production" -updated_date = "2024/06/18" +updated_date = "2025/01/10" [rule] anomaly_threshold = 75 @@ -76,4 +76,38 @@ rule_id = "eaa77d63-9679-4ce3-be25-3ba8b795e5fa" severity = "low" tags = ["Use Case: Threat Detection", "Rule Type: ML", "Rule Type: Machine Learning"] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Spike in Firewall Denies + +Firewalls and ACLs are critical in controlling network traffic, blocking unauthorized access. Adversaries may exploit misconfigurations or launch attacks like reconnaissance or denial-of-service to overwhelm these defenses. The 'Spike in Firewall Denies' detection rule leverages machine learning to identify unusual surges in denied traffic, signaling potential misconfigurations or malicious activities. + +### Possible investigation steps + +- Review the time frame and source IP addresses associated with the spike in denied traffic to identify any patterns or anomalies. +- Check the firewall and ACL logs for any recent changes or misconfigurations that could have led to the increase in denied traffic. +- Investigate the destination IP addresses and ports targeted by the denied traffic to determine if they are associated with known malicious activity or if they are legitimate services. +- Analyze the volume and frequency of the denied requests to assess whether they align with typical denial-of-service attack patterns or reconnaissance activities. +- Correlate the denied traffic with other security alerts or logs to identify any related suspicious activities or potential indicators of compromise within the network. + +### False positive analysis + +- Routine network scans by security tools or IT teams may trigger spikes in denied traffic. Regularly review and whitelist known IP addresses or tools to prevent these from being flagged. +- Misconfigured applications that frequently attempt unauthorized access can cause false positives. Identify and correct these configurations to reduce unnecessary alerts. +- Legitimate but high-volume business applications might generate traffic patterns similar to reconnaissance activities. Monitor and document these applications, and create exceptions for their traffic patterns. +- Scheduled maintenance or updates can lead to temporary spikes in denied traffic. Coordinate with IT teams to anticipate these events and adjust monitoring rules accordingly. +- Internal network changes, such as new device deployments or network architecture updates, might cause unexpected traffic patterns. Ensure these changes are communicated and accounted for in the firewall rules to minimize false positives. + +### Response and remediation + +- Immediately isolate affected systems or segments of the network to prevent further unauthorized access or potential spread of malicious activity. +- Analyze the denied traffic logs to identify the source IP addresses and block them at the firewall or ACL level to prevent further attempts. +- Review and correct any misconfigurations in firewall rules or ACLs that may have contributed to the spike in denied traffic. +- Conduct a thorough investigation to determine if the spike is related to a denial-of-service attack and, if confirmed, engage with your internet service provider (ISP) for additional support and mitigation strategies. +- If malicious activity is suspected, escalate the incident to the security operations center (SOC) or incident response team for further analysis and response. +- Implement additional monitoring and alerting for similar patterns of denied traffic to enhance early detection of potential threats. +- Document the incident, including actions taken and lessons learned, to improve future response efforts and update incident response plans accordingly.""" diff --git a/rules/ml/ml_high_count_network_events.toml b/rules/ml/ml_high_count_network_events.toml index edc03f65057..12799e14053 100644 --- a/rules/ml/ml_high_count_network_events.toml +++ b/rules/ml/ml_high_count_network_events.toml @@ -2,7 +2,7 @@ creation_date = "2021/04/05" integration = ["endpoint", "network_traffic"] maturity = "production" -updated_date = "2024/06/18" +updated_date = "2025/01/10" [rule] anomaly_threshold = 75 @@ -75,4 +75,38 @@ rule_id = "b240bfb8-26b7-4e5e-924e-218144a3fa71" severity = "low" tags = ["Use Case: Threat Detection", "Rule Type: ML", "Rule Type: Machine Learning"] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Spike in Network Traffic +Machine learning models analyze network traffic patterns to identify anomalies, such as unexpected spikes. These spikes may indicate malicious activities like data exfiltration or denial-of-service attacks. Adversaries exploit network vulnerabilities to flood traffic or extract data. The 'Spike in Network Traffic' rule leverages ML to flag unusual traffic surges, aiding in early threat detection and response. + +### Possible investigation steps + +- Review the timestamp and duration of the traffic spike to determine if it correlates with any scheduled business activities or known events. +- Analyze the source and destination IP addresses involved in the traffic spike to identify any unfamiliar or suspicious entities. +- Examine the types of network protocols and services involved in the spike to assess if they align with typical network usage patterns. +- Check for any recent changes in network configurations or security policies that might explain the unusual traffic patterns. +- Investigate any associated user accounts or devices to determine if they have been compromised or are exhibiting unusual behavior. +- Cross-reference the spike with other security alerts or logs to identify potential patterns or related incidents. + +### False positive analysis + +- Business-related traffic surges: Regular spikes due to legitimate business activities, such as marketing campaigns or software updates, can trigger false positives. Users should analyze historical traffic patterns and create exceptions for known business events. +- Scheduled data backups: Routine data backups can cause significant network traffic. Users can exclude these by identifying backup schedules and configuring the rule to ignore traffic during these times. +- Software updates and patches: Large-scale updates from software vendors can lead to temporary traffic spikes. Users should maintain a list of update schedules and whitelist these events to prevent false alerts. +- Internal network scans: Regular security scans or inventory checks within the organization may cause traffic spikes. Users should document these activities and adjust the rule to recognize them as non-threatening. +- Cloud service synchronization: Synchronization activities with cloud services can generate high traffic volumes. Users should identify and exclude these regular sync patterns to reduce false positives. + +### Response and remediation + +- Immediately isolate affected systems from the network to prevent further data exfiltration or traffic flooding. +- Conduct a thorough analysis of network logs to identify the source and destination of the traffic spike, focusing on any unauthorized or suspicious IP addresses. +- Block identified malicious IP addresses and domains at the firewall and update intrusion prevention systems to prevent further access. +- If data exfiltration is suspected, perform a data integrity check to assess any potential data loss or compromise. +- Notify the incident response team to assess the situation and determine if further escalation is necessary, including potential involvement of law enforcement if data theft is confirmed. +- Review and update network access controls and permissions to ensure only authorized users and devices have access to sensitive data and systems. +- Implement enhanced monitoring and alerting for similar traffic patterns to improve early detection and response to future incidents.""" diff --git a/rules/ml/ml_linux_anomalous_network_port_activity.toml b/rules/ml/ml_linux_anomalous_network_port_activity.toml index 140a8bc735f..c1a96071828 100644 --- a/rules/ml/ml_linux_anomalous_network_port_activity.toml +++ b/rules/ml/ml_linux_anomalous_network_port_activity.toml @@ -2,7 +2,7 @@ creation_date = "2020/03/25" integration = ["auditd_manager", "endpoint"] maturity = "production" -updated_date = "2024/06/18" +updated_date = "2025/01/10" [rule] anomaly_threshold = 50 @@ -80,4 +80,40 @@ tags = [ "Rule Type: Machine Learning", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Linux Network Port Activity + +In Linux environments, network ports facilitate communication between applications and services. Adversaries may exploit rarely used ports for covert command-and-control, persistence, or data exfiltration, bypassing standard monitoring. The 'Unusual Linux Network Port Activity' detection rule leverages machine learning to identify anomalies in port usage, flagging potential unauthorized access or threat actor activity by highlighting deviations from typical network behavior. + +### Possible investigation steps + +- Review the alert details to identify the specific unusual destination port and the associated source and destination IP addresses. +- Check historical network logs to determine if the identified port has been used previously and assess the frequency and context of its usage. +- Investigate the source IP address to determine if it is associated with known internal systems or if it is an external or unexpected source. +- Analyze the destination IP address to verify if it is a legitimate endpoint within the network or an external entity that requires further scrutiny. +- Correlate the unusual port activity with any recent changes or updates in the network environment that might explain the anomaly. +- Examine any related process or application logs on the involved Linux systems to identify the application or service responsible for the network activity. +- Consider reaching out to the system owner or administrator for additional context or to verify if the activity is expected or authorized. + +### False positive analysis + +- Routine administrative tasks may trigger alerts when using non-standard ports for legitimate purposes. Users can create exceptions for known administrative tools and scripts that consistently use these ports. +- Internal applications or services might use uncommon ports for inter-service communication. Identify these applications and whitelist their port usage to prevent unnecessary alerts. +- Security tools and monitoring solutions sometimes scan or probe network ports as part of their operations. Recognize these tools and exclude their activities from the rule to avoid false positives. +- Development and testing environments often experiment with various port configurations. Establish a separate monitoring profile for these environments to reduce noise in production alerts. +- Custom or legacy applications may operate on non-standard ports due to historical configurations. Document these applications and adjust the rule to accommodate their expected behavior. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Conduct a thorough review of the system's network connections and terminate any suspicious or unauthorized connections. +- Analyze system logs to identify any malicious processes or scripts that may have been executed, and remove or quarantine any identified threats. +- Change all credentials associated with the affected system, especially if there is any indication of credential compromise. +- Restore the system from a known good backup if any unauthorized changes or malware are detected. +- Implement network segmentation to limit the exposure of critical systems to potential threats and reduce the risk of lateral movement. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" diff --git a/rules/ml/ml_packetbeat_rare_server_domain.toml b/rules/ml/ml_packetbeat_rare_server_domain.toml index 653e4cc3226..57fe994f004 100644 --- a/rules/ml/ml_packetbeat_rare_server_domain.toml +++ b/rules/ml/ml_packetbeat_rare_server_domain.toml @@ -2,7 +2,7 @@ creation_date = "2020/03/25" integration = ["auditd_manager", "endpoint"] maturity = "production" -updated_date = "2024/06/18" +updated_date = "2025/01/10" [rule] anomaly_threshold = 50 @@ -83,4 +83,38 @@ rule_id = "17e68559-b274-4948-ad0b-f8415bb31126" severity = "low" tags = ["Use Case: Threat Detection", "Rule Type: ML", "Rule Type: Machine Learning"] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Destination Domain Name + +Machine learning models analyze network traffic to identify atypical domain names, which may indicate malicious activities like phishing or malware communication. Adversaries exploit uncommon domains for initial access or command-and-control. This detection rule leverages ML to flag these anomalies, aiding analysts in identifying potential threats early. + +### Possible investigation steps + +- Review the domain name flagged by the alert to determine if it is known for malicious activity or if it is newly registered, using threat intelligence sources and domain reputation services. +- Analyze the network traffic associated with the domain to identify the source IP address and any related communication patterns, such as frequency and data volume. +- Check the user or system that initiated the connection to the unusual domain for any recent changes or suspicious activities, such as software installations or configuration changes. +- Investigate any related alerts or logs that might provide additional context, such as other unusual domain requests or failed login attempts, to identify potential patterns or correlations. +- Assess the endpoint security logs for signs of malware or unauthorized access attempts that could be linked to the unusual domain activity. + +### False positive analysis + +- Legitimate software updates or downloads from uncommon domains can trigger false positives. Users should maintain a list of known software vendors and their associated domains to exclude these from alerts. +- Internal testing or development environments may use non-standard domain names. Organizations should document these domains and configure exceptions to prevent unnecessary alerts. +- Newly registered domains for legitimate business purposes might be flagged. Regularly update the list of approved domains as new business initiatives arise. +- Third-party services or APIs that use unique domain names can cause false positives. Identify and whitelist these services to reduce noise in alerts. +- Temporary or one-time use domains for events or campaigns should be monitored and excluded as needed to avoid repeated false positives. + +### Response and remediation + +- Isolate the affected system from the network to prevent further communication with the suspicious domain and potential spread of malware. +- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove any malicious software. +- Review and analyze network logs to identify any other systems that may have communicated with the unusual domain and apply similar isolation and scanning procedures to those systems. +- Change passwords and credentials associated with the affected system and any potentially compromised accounts to prevent unauthorized access. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional containment measures are necessary. +- Implement network-level blocking of the identified unusual domain across the organization to prevent future access attempts. +- Update threat intelligence feeds and detection systems with indicators of compromise (IOCs) related to the unusual domain to enhance future detection capabilities.""" diff --git a/rules/ml/ml_rare_destination_country.toml b/rules/ml/ml_rare_destination_country.toml index 3f293cd15f6..196e8ff5677 100644 --- a/rules/ml/ml_rare_destination_country.toml +++ b/rules/ml/ml_rare_destination_country.toml @@ -2,7 +2,7 @@ creation_date = "2021/04/05" integration = ["endpoint", "network_traffic"] maturity = "production" -updated_date = "2024/06/18" +updated_date = "2025/01/10" [rule] anomaly_threshold = 75 @@ -79,4 +79,39 @@ rule_id = "35f86980-1fb1-4dff-b311-3be941549c8d" severity = "low" tags = ["Use Case: Threat Detection", "Rule Type: ML", "Rule Type: Machine Learning"] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Network Traffic to Rare Destination Country + +Machine learning models analyze network logs to identify traffic to uncommon destination countries, which may indicate malicious activities like unauthorized access or data exfiltration. Adversaries exploit this by directing traffic to servers in atypical locations, often linked to command-and-control operations. The detection rule flags such anomalies, aiding in early threat identification and response. + +### Possible investigation steps + +- Review the network logs to identify the specific destination country flagged as rare and assess its historical presence in the network traffic. +- Analyze the source IP addresses and user accounts associated with the flagged traffic to determine if they are legitimate or potentially compromised. +- Investigate the nature of the traffic, such as the protocols and ports used, to identify any unusual patterns or connections to known malicious infrastructure. +- Check for any recent phishing attempts or suspicious emails that may have led to the initiation of this traffic, focusing on links or attachments that could have been used to download malicious payloads. +- Correlate the flagged traffic with any other security alerts or incidents to identify potential patterns or coordinated attacks involving the rare destination country. +- Consult threat intelligence sources to determine if the destination country or specific IP addresses are associated with known threat actors or command-and-control servers. + +### False positive analysis + +- Legitimate business communications with partners or clients in rare destination countries may trigger alerts. Users should review and whitelist these known entities to prevent future false positives. +- Routine software updates or patches from international vendors might be flagged. Identify and exclude these update servers from the detection rule to avoid unnecessary alerts. +- Employees traveling abroad and accessing company resources can generate alerts. Implement a process to temporarily whitelist these destinations based on travel schedules. +- Cloud services with global data centers may route traffic through uncommon countries. Verify the service's IP ranges and exclude them if they are part of normal operations. +- Research or market expansion activities targeting new regions might cause alerts. Document and exclude these activities if they align with business objectives. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Conduct a thorough scan of the isolated system for malware or unauthorized software, focusing on identifying any command-and-control (C2) communication channels. +- Block network traffic to and from the identified rare destination country at the firewall or proxy level to prevent further communication with potential malicious servers. +- Review and analyze logs from the affected system and network devices to identify any additional indicators of compromise or related suspicious activities. +- If malware is detected, remove it using appropriate tools and techniques, ensuring that all persistence mechanisms are eradicated. +- Restore the affected system from a clean backup if necessary, ensuring that all security patches and updates are applied. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" diff --git a/rules/ml/persistence_ml_windows_anomalous_path_activity.toml b/rules/ml/persistence_ml_windows_anomalous_path_activity.toml index cc7adf6f4f9..6b2036b68d4 100644 --- a/rules/ml/persistence_ml_windows_anomalous_path_activity.toml +++ b/rules/ml/persistence_ml_windows_anomalous_path_activity.toml @@ -2,7 +2,7 @@ creation_date = "2020/03/25" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -85,6 +85,41 @@ tags = [ "Tactic: Execution", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Windows Path Activity + +In corporate Windows environments, software is typically managed centrally, making execution from user or temporary directories uncommon. Adversaries exploit this by running malware from these atypical paths, bypassing standard security measures. The 'Unusual Windows Path Activity' detection rule leverages machine learning to identify such anomalies, flagging potential persistence or execution tactics used by attackers. + +### Possible investigation steps + +- Review the process name and path to determine if it is a known legitimate application or a suspicious executable. +- Check the parent process to understand how the process was initiated and if it correlates with expected user behavior or known software installations. +- Investigate the user account associated with the process execution to verify if the activity aligns with their typical usage patterns or if it appears anomalous. +- Examine the file hash of the executable to see if it matches known malware signatures or if it has been flagged by any threat intelligence sources. +- Look into recent file modifications or creations in the directory from which the process was executed to identify any additional suspicious files or scripts. +- Analyze network connections initiated by the process to detect any unusual or unauthorized external communications. + +### False positive analysis + +- Software updates or installations by IT staff can trigger alerts when executed from temporary directories. To manage this, create exceptions for known IT processes or scripts that are regularly used for legitimate software deployment. +- Some legitimate applications may temporarily execute components from user directories during updates or initial setup. Identify these applications and add them to an allowlist to prevent unnecessary alerts. +- Developers or power users might run scripts or applications from non-standard directories for testing purposes. Establish a policy to document and approve such activities, and configure exceptions for these known cases. +- Automated tasks or scripts that are scheduled to run from user directories can be mistaken for malicious activity. Review and document these tasks, then configure the detection rule to exclude them from triggering alerts. +- Security tools or monitoring software might execute diagnostic or remediation scripts from temporary paths. Verify these activities and add them to an exception list to avoid false positives. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of potential malware and unauthorized access. +- Terminate any suspicious processes identified as running from atypical directories to halt malicious activity. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious files. +- Review and restore any modified system processes or configurations to their original state to ensure system integrity. +- Collect and preserve relevant logs and evidence for further analysis and potential escalation to the incident response team. +- Escalate the incident to the security operations center (SOC) or incident response team if the threat persists or if there is evidence of broader compromise. +- Implement application whitelisting to prevent unauthorized execution of software from user or temporary directories in the future.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/ml/persistence_ml_windows_anomalous_service.toml b/rules/ml/persistence_ml_windows_anomalous_service.toml index 63938309c94..0d07a56d34f 100644 --- a/rules/ml/persistence_ml_windows_anomalous_service.toml +++ b/rules/ml/persistence_ml_windows_anomalous_service.toml @@ -2,7 +2,7 @@ creation_date = "2020/03/25" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -82,6 +82,41 @@ tags = [ "Tactic: Persistence", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Windows Service + +Windows services are crucial for running background processes and applications. Adversaries exploit this by creating or modifying services to maintain persistence or execute unauthorized actions. The 'Unusual Windows Service' detection rule leverages machine learning to identify atypical services, flagging potential threats by comparing against known service patterns, thus aiding in early threat detection and response. + +### Possible investigation steps + +- Review the details of the detected unusual Windows service, including the service name, path, and any associated executables, to determine if it aligns with known legitimate services or appears suspicious. +- Check the creation and modification timestamps of the service to identify if it was recently added or altered, which could indicate unauthorized activity. +- Investigate the user account under which the service is running to assess if it has the necessary permissions and if the account has been compromised or misused. +- Cross-reference the service with known threat intelligence databases to see if it matches any known malware or persistence mechanisms. +- Analyze the network activity and connections associated with the service to identify any unusual or unauthorized communication patterns. +- Examine the host's event logs for any related entries that could provide additional context or evidence of malicious activity, such as failed login attempts or privilege escalation events. + +### False positive analysis + +- Legitimate software installations or updates may create new services that are flagged as unusual. Users should verify the source and purpose of the service before excluding it. +- Custom in-house applications often run unique services that can trigger alerts. Document these services and create exceptions to prevent future false positives. +- IT administrative tools might install services for management purposes. Confirm these tools are authorized and add them to an exception list if they are frequently flagged. +- Temporary services used for troubleshooting or testing can be mistaken for threats. Ensure these are removed after use or excluded if they are part of regular operations. +- Scheduled tasks that create services for specific operations might be flagged. Review these tasks and exclude them if they are part of normal business processes. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent potential lateral movement or data exfiltration by the unauthorized service. +- Terminate the unusual Windows service identified by the alert to stop any ongoing malicious activity. +- Conduct a thorough analysis of the service's executable and associated files to determine if they are malicious. Use endpoint detection and response (EDR) tools to assist in this analysis. +- Remove any malicious files or executables associated with the service from the system to ensure complete eradication of the threat. +- Restore the affected system from a known good backup if the service has caused significant changes or damage to the system. +- Monitor the system and network for any signs of re-infection or similar unusual service activity, using enhanced logging and alerting mechanisms. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/ml/privilege_escalation_ml_linux_anomalous_sudo_activity.toml b/rules/ml/privilege_escalation_ml_linux_anomalous_sudo_activity.toml index 6d718fc767f..6ca5a51357e 100644 --- a/rules/ml/privilege_escalation_ml_linux_anomalous_sudo_activity.toml +++ b/rules/ml/privilege_escalation_ml_linux_anomalous_sudo_activity.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/03" integration = ["auditd_manager", "endpoint"] maturity = "production" -updated_date = "2024/06/18" +updated_date = "2025/01/10" [rule] anomaly_threshold = 75 @@ -84,6 +84,41 @@ tags = [ "Tactic: Privilege Escalation", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Sudo Activity + +Sudo is a command in Unix-like systems that allows permitted users to execute commands as a superuser, providing necessary privileges for administrative tasks. Adversaries may exploit this by using compromised credentials to gain elevated access, potentially bypassing security controls. The 'Unusual Sudo Activity' detection rule leverages machine learning to identify deviations from normal sudo usage patterns, flagging potential privilege escalation attempts for further investigation. + +### Possible investigation steps + +- Review the user account associated with the unusual sudo activity to determine if it aligns with known administrative roles or if it is typically associated with non-privileged tasks. +- Check the timestamp of the sudo activity to see if it coincides with any known maintenance windows or reported troubleshooting activities. +- Analyze the command executed with sudo to assess whether it is a common administrative command or if it appears suspicious or unnecessary for the user's role. +- Investigate the source IP address or hostname from which the sudo command was executed to verify if it is a recognized and authorized device. +- Look into recent login activity for the user account to identify any unusual access patterns or locations that could indicate compromised credentials. +- Cross-reference the alert with any other security events or logs around the same time to identify potential indicators of compromise or related malicious activity. + +### False positive analysis + +- Administrative troubleshooting activities can trigger false positives. Regularly review and document legitimate administrative tasks that require sudo access to differentiate them from potential threats. +- Developers or IT staff performing routine maintenance may cause alerts. Create exceptions for known maintenance windows or specific user accounts that frequently require elevated privileges. +- Automated scripts or scheduled tasks using sudo might be flagged. Identify and whitelist these scripts or tasks if they are verified as safe and necessary for operations. +- New employees or role changes can lead to unusual sudo activity. Update user roles and permissions promptly to reflect their current responsibilities and reduce unnecessary alerts. +- Temporary access granted for specific projects can appear suspicious. Ensure that temporary access is well-documented and set to expire automatically to prevent lingering false positives. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Revoke or reset the compromised credentials to prevent further misuse and ensure that the affected user account is secured. +- Conduct a thorough review of recent sudo logs and system activity to identify any unauthorized changes or actions taken by the adversary. +- Restore any altered or deleted files from backups, ensuring that the system is returned to its last known good state. +- Apply any necessary security patches or updates to the affected system to close vulnerabilities that may have been exploited. +- Enhance monitoring and logging for sudo activities across all systems to detect similar anomalies in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/ml/privilege_escalation_ml_windows_rare_user_runas_event.toml b/rules/ml/privilege_escalation_ml_windows_rare_user_runas_event.toml index e996d8761c8..13ce443332b 100644 --- a/rules/ml/privilege_escalation_ml_windows_rare_user_runas_event.toml +++ b/rules/ml/privilege_escalation_ml_windows_rare_user_runas_event.toml @@ -2,7 +2,7 @@ creation_date = "2020/03/25" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -82,6 +82,41 @@ tags = [ "Tactic: Privilege Escalation", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Windows User Privilege Elevation Activity + +In Windows environments, privilege elevation tools like 'runas' allow users to execute programs with different user credentials, typically used by administrators. Adversaries exploit this to gain elevated access, often indicating account compromise. The detection rule leverages machine learning to identify atypical usage patterns of such tools, flagging potential unauthorized privilege escalation attempts. + +### Possible investigation steps + +- Review the specific user account involved in the alert to determine if it is a regular user or an administrator, as privilege elevation is more common among administrators. +- Check the timestamp of the alert to correlate with any known scheduled tasks or administrative activities that might explain the use of privilege elevation tools. +- Investigate the source IP address and device from which the privilege elevation attempt was made to verify if it aligns with the user's typical access patterns. +- Examine recent login activity for the user account to identify any unusual or unauthorized access attempts that could indicate account compromise. +- Look for any other security alerts or logs related to the same user or device around the time of the alert to gather additional context on potential malicious activity. +- Assess whether there have been any recent changes to user permissions or group memberships that could have facilitated the privilege elevation. + +### False positive analysis + +- Regular administrative tasks by domain or network administrators can trigger false positives. To manage this, create exceptions for known administrator accounts frequently using the runas command. +- Scheduled tasks or scripts that require privilege elevation might be flagged. Identify and exclude these tasks from monitoring if they are verified as safe and necessary for operations. +- Software updates or installations that require elevated privileges can also cause alerts. Maintain a list of approved software and update processes to exclude them from triggering the rule. +- Training or testing environments where privilege elevation is part of routine operations may generate false positives. Exclude these environments from the rule's scope to prevent unnecessary alerts. +- Third-party applications that use privilege elevation for legitimate purposes should be reviewed and, if deemed safe, added to an exception list to avoid repeated false positives. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Revoke any elevated privileges granted to the compromised account and reset its password to prevent further misuse. +- Conduct a thorough review of recent activity logs for the affected account to identify any unauthorized actions or data access. +- Notify the security team and relevant stakeholders about the incident for awareness and potential escalation. +- Restore any altered or compromised system configurations to their original state using backups or system snapshots. +- Implement additional monitoring on the affected system and account to detect any further suspicious activity. +- Review and update access controls and privilege management policies to minimize the risk of similar incidents in the future.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/ml/resource_development_ml_linux_anomalous_compiler_activity.toml b/rules/ml/resource_development_ml_linux_anomalous_compiler_activity.toml index e3878144a51..527bb6093cb 100644 --- a/rules/ml/resource_development_ml_linux_anomalous_compiler_activity.toml +++ b/rules/ml/resource_development_ml_linux_anomalous_compiler_activity.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/03" integration = ["auditd_manager", "endpoint"] maturity = "production" -updated_date = "2024/06/18" +updated_date = "2025/01/10" [rule] anomaly_threshold = 50 @@ -85,6 +85,41 @@ tags = [ "Tactic: Resource Development", ] type = "machine_learning" +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Anomalous Linux Compiler Activity + +Compilers transform source code into executable programs, a crucial step in software development. In Linux environments, unexpected compiler use by atypical users may signal unauthorized software changes or privilege escalation attempts. Adversaries exploit this by deploying malicious code or exploits. The detection rule leverages machine learning to identify unusual compiler activity, flagging potential threats by analyzing user behavior patterns and deviations from normal operations. + +### Possible investigation steps + +- Review the user account associated with the anomalous compiler activity to determine if the user typically engages in software development or has a history of using compilers. +- Check the specific compiler and version used in the activity to identify if it is a known or legitimate tool within the organization. +- Analyze the source and destination of the compiler activity, including the IP addresses and hostnames, to identify any unusual or unauthorized access patterns. +- Investigate recent changes or deployments on the system where the compiler activity was detected to identify any unauthorized software installations or modifications. +- Examine system logs and audit trails for any signs of privilege escalation attempts or other suspicious activities around the time of the compiler usage. +- Cross-reference the detected activity with known threat intelligence sources to determine if the behavior matches any known attack patterns or indicators of compromise. + +### False positive analysis + +- Development environments where multiple users compile code can trigger false positives. Regularly update the list of authorized users who are expected to use compilers to prevent unnecessary alerts. +- Automated build systems or continuous integration pipelines may be flagged. Exclude these systems from monitoring or adjust the rule to recognize their activity as normal. +- Educational or training sessions involving compilers might cause alerts. Temporarily adjust the rule settings or add exceptions for the duration of the training. +- Users compiling open-source software for personal use can be mistaken for threats. Implement a process for users to notify the security team of legitimate compiler use to preemptively adjust monitoring rules. +- System administrators performing maintenance or updates that involve compiling software may trigger alerts. Maintain a log of scheduled maintenance activities and adjust the rule to account for these periods. + +### Response and remediation + +- Isolate the affected system from the network to prevent potential lateral movement or further exploitation. +- Terminate any suspicious processes associated with the anomalous compiler activity to halt any ongoing malicious operations. +- Conduct a thorough review of recent user activity and permissions to identify unauthorized access or privilege escalation attempts. +- Remove any unauthorized or malicious software identified during the investigation to prevent further compromise. +- Restore the system from a known good backup if malicious code execution is confirmed, ensuring that the backup is free from compromise. +- Implement stricter access controls and monitoring for compiler usage, ensuring only authorized users can execute compilers. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.""" [[rule.threat]] framework = "MITRE ATT&CK" [[rule.threat.technique]] diff --git a/rules/network/command_and_control_accepted_default_telnet_port_connection.toml b/rules/network/command_and_control_accepted_default_telnet_port_connection.toml index d30f431fda5..4a6ac7d9ae5 100644 --- a/rules/network/command_and_control_accepted_default_telnet_port_connection.toml +++ b/rules/network/command_and_control_accepted_default_telnet_port_connection.toml @@ -2,7 +2,7 @@ creation_date = "2020/02/18" integration = ["network_traffic", "panw"] maturity = "production" -updated_date = "2024/09/18" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -49,6 +49,41 @@ query = ''' flow_terminated or timeout or Reject or network_flow) and destination.port:23 ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Accepted Default Telnet Port Connection + +Telnet, a protocol for remote command-line access, is often used in legacy systems. Its lack of encryption makes it vulnerable, allowing attackers to intercept credentials or use it as a backdoor. The detection rule identifies unencrypted Telnet traffic on port 23, flagging connections that bypass typical security measures, thus highlighting potential unauthorized access attempts. + +### Possible investigation steps + +- Review the network traffic logs to identify the source IP address associated with the Telnet connection on port 23. Determine if the source IP is internal or external to the organization. +- Check the destination IP address to ascertain if it belongs to a critical system or a legacy device that might still use Telnet for management purposes. +- Investigate the timeline of the connection event to see if there are any patterns or repeated attempts, which could indicate a persistent threat or automated attack. +- Analyze any associated user accounts or credentials used during the Telnet session to verify if they are legitimate and authorized for remote access. +- Correlate the Telnet connection event with other security alerts or logs to identify any related suspicious activities, such as failed login attempts or unusual data transfers. +- Assess the network segment where the Telnet traffic was detected to determine if it is appropriately segmented and secured against unauthorized access. +- Consider implementing network security measures, such as disabling Telnet on devices or replacing it with secure alternatives like SSH, to prevent future unauthorized access attempts. + +### False positive analysis + +- Legacy systems or devices that require Telnet for management may trigger alerts. To manage this, create exceptions for specific IP addresses or subnets known to host these systems. +- Internal network monitoring tools that use Telnet for legitimate purposes might be flagged. Identify these tools and exclude their traffic from the rule to prevent unnecessary alerts. +- Lab environments or test networks where Telnet is used for educational or testing purposes can cause false positives. Implement network segmentation and apply exceptions to these environments to reduce noise. +- Automated scripts or maintenance tasks that utilize Telnet for routine operations may be mistakenly identified. Document these tasks and whitelist their associated traffic patterns to avoid false alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any active Telnet sessions on the affected system to disrupt potential attacker activities. +- Conduct a thorough review of system logs and network traffic to identify any unauthorized access or data manipulation that may have occurred. +- Change all credentials that may have been exposed through Telnet traffic, prioritizing those with administrative privileges. +- Implement network segmentation to restrict Telnet access to only necessary internal systems, ensuring it is not exposed to the internet. +- Deploy encryption protocols such as SSH to replace Telnet for remote command-line access, enhancing security for remote management. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for additional security measures.""" [[rule.threat]] diff --git a/rules/network/command_and_control_cobalt_strike_beacon.toml b/rules/network/command_and_control_cobalt_strike_beacon.toml index be14096630a..a893732e175 100644 --- a/rules/network/command_and_control_cobalt_strike_beacon.toml +++ b/rules/network/command_and_control_cobalt_strike_beacon.toml @@ -2,7 +2,7 @@ creation_date = "2020/07/06" integration = ["network_traffic"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -22,7 +22,43 @@ index = ["packetbeat-*", "auditbeat-*", "filebeat-*", "logs-network_traffic.*"] language = "lucene" license = "Elastic License v2" name = "Cobalt Strike Command and Control Beacon" -note = """## Threat intel +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Cobalt Strike Command and Control Beacon + +Cobalt Strike is a penetration testing tool often repurposed by attackers for malicious activities, particularly for establishing command and control (C2) channels. Adversaries exploit its beaconing feature to communicate with compromised systems using common protocols like HTTP or TLS. The detection rule identifies suspicious network patterns, such as specific domain naming conventions, indicative of Cobalt Strike's C2 activity, helping analysts pinpoint potential threats. + +### Possible investigation steps + +- Review the alert details to identify the specific domain that triggered the rule, focusing on the pattern [a-z]{3}.stage.[0-9]{8}\\..* to determine if it matches known malicious domains. +- Analyze the network traffic logs associated with the alert, specifically looking at events categorized under network or network_traffic with types tls or http, to gather more context about the communication. +- Investigate the source IP address and destination domain involved in the alert to determine if they have been associated with previous malicious activities or are listed in threat intelligence databases. +- Examine the timeline of the network activity to identify any patterns or anomalies that could indicate a larger campaign or coordinated attack. +- Check for any related alerts or incidents in the security information and event management (SIEM) system that might provide additional context or indicate a broader compromise. +- Assess the affected endpoint for any signs of compromise, such as unusual processes or connections, to determine if further containment or remediation actions are necessary. + +### False positive analysis + +- Legitimate software updates or patch management systems may use similar domain naming conventions. Review and whitelist known update servers to prevent false alerts. +- Internal development or testing environments might mimic Cobalt Strike's domain patterns for legitimate purposes. Identify and exclude these environments from the rule. +- Automated scripts or tools that generate network traffic with similar domain structures can trigger false positives. Monitor and document these tools, then create exceptions for their activity. +- Some content delivery networks (CDNs) might use domain patterns that match the rule's criteria. Verify and exclude trusted CDNs to reduce unnecessary alerts. +- Regularly review and update the list of exceptions to ensure that only verified non-threatening behaviors are excluded, maintaining the rule's effectiveness. + +### Response and remediation + +- Isolate the affected systems immediately to prevent further communication with the Cobalt Strike C2 server. This can be done by disconnecting the network or using network segmentation techniques. +- Conduct a thorough forensic analysis of the compromised systems to identify the extent of the breach and any additional payloads or backdoors that may have been installed. +- Remove any identified Cobalt Strike beacons or related malware from the affected systems using updated antivirus or endpoint detection and response (EDR) tools. +- Change all credentials and access tokens that may have been exposed or used on the compromised systems to prevent unauthorized access. +- Monitor network traffic for any signs of re-infection or communication attempts with known Cobalt Strike C2 domains, using updated threat intelligence feeds. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or data have been compromised. +- Implement network-level controls, such as blocking known malicious domains and IP addresses associated with Cobalt Strike, to prevent future attacks. + +## Threat intel This activity has been observed in FIN7 campaigns.""" references = [ diff --git a/rules/network/command_and_control_cobalt_strike_default_teamserver_cert.toml b/rules/network/command_and_control_cobalt_strike_default_teamserver_cert.toml index 6086b36e1b0..d36c34d32d5 100644 --- a/rules/network/command_and_control_cobalt_strike_default_teamserver_cert.toml +++ b/rules/network/command_and_control_cobalt_strike_default_teamserver_cert.toml @@ -2,7 +2,7 @@ creation_date = "2020/10/05" integration = ["network_traffic"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -18,7 +18,42 @@ index = ["packetbeat-*", "auditbeat-*", "filebeat-*", "logs-network_traffic.*"] language = "kuery" license = "Elastic License v2" name = "Default Cobalt Strike Team Server Certificate" -note = """## Threat intel +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Default Cobalt Strike Team Server Certificate + +Cobalt Strike is a tool used for simulating advanced cyber threats, often employed by security teams to test defenses. However, adversaries can exploit its default server certificate to establish covert command and control channels. The detection rule identifies this misuse by monitoring network traffic for specific cryptographic hashes associated with the default certificate, flagging potential unauthorized Cobalt Strike activity. + +### Possible investigation steps + +- Review the network traffic logs to identify any connections associated with the specific cryptographic hashes: MD5 (950098276A495286EB2A2556FBAB6D83), SHA1 (6ECE5ECE4192683D2D84E25B0BA7E04F9CB7EB7C), or SHA256 (87F2085C32B6A2CC709B365F55873E207A9CAA10BFFECF2FD16D3CF9D94D390C). +- Identify the source and destination IP addresses involved in the flagged network traffic to determine the potential origin and target of the Cobalt Strike activity. +- Correlate the identified IP addresses with known assets in the network to assess if any internal systems are potentially compromised. +- Check for any other suspicious or anomalous network activities around the same time as the alert to identify potential lateral movement or additional command and control channels. +- Investigate any associated processes or user accounts on the involved systems to determine if there are signs of compromise or unauthorized access. +- Review historical data to see if there have been previous alerts or similar activities involving the same cryptographic hashes or IP addresses, which might indicate a persistent threat. + +### False positive analysis + +- Legitimate security testing activities by internal teams using Cobalt Strike may trigger the rule. Coordinate with security teams to whitelist known testing IP addresses or certificate hashes. +- Some commercial penetration testing services may use Cobalt Strike with default certificates. Verify the legitimacy of such services and exclude their traffic from detection by adding their certificate hashes to an exception list. +- Network appliances or security tools that simulate adversary behavior for training purposes might use similar certificates. Identify these tools and configure exceptions for their specific network traffic patterns. +- In environments where Cobalt Strike is used for authorized red team exercises, ensure that the default certificate is replaced with a custom one to avoid false positives. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further communication with the potential Cobalt Strike server. +- Conduct a thorough forensic analysis of the isolated system to identify any malicious payloads or additional indicators of compromise. +- Revoke any compromised credentials and enforce a password reset for affected accounts to prevent unauthorized access. +- Update and patch all systems to the latest security standards to mitigate vulnerabilities that could be exploited by similar threats. +- Implement network segmentation to limit the lateral movement of threats within the network. +- Enhance monitoring and logging to capture detailed network traffic and endpoint activity, focusing on the identified cryptographic hashes. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and coordination with external threat intelligence sources if necessary. + +## Threat intel While Cobalt Strike is intended to be used for penetration tests and IR training, it is frequently used by actual threat actors (TA) such as APT19, APT29, APT32, APT41, FIN6, DarkHydrus, CopyKittens, Cobalt Group, Leviathan, and many other unnamed criminal TAs. This rule uses high-confidence atomic indicators, so alerts should be investigated rapidly.""" references = [ diff --git a/rules/network/command_and_control_download_rar_powershell_from_internet.toml b/rules/network/command_and_control_download_rar_powershell_from_internet.toml index 353a1460eec..77756541be6 100644 --- a/rules/network/command_and_control_download_rar_powershell_from_internet.toml +++ b/rules/network/command_and_control_download_rar_powershell_from_internet.toml @@ -2,7 +2,7 @@ creation_date = "2020/07/02" integration = ["network_traffic", "panw"] maturity = "production" -updated_date = "2024/09/18" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -23,7 +23,43 @@ index = ["packetbeat-*", "auditbeat-*", "filebeat-*", "logs-network_traffic.*", language = "kuery" license = "Elastic License v2" name = "Roshal Archive (RAR) or PowerShell File Downloaded from the Internet" -note = """## Threat intel +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Roshal Archive (RAR) or PowerShell File Downloaded from the Internet + +RAR files and PowerShell scripts are powerful tools in IT environments, used for data compression and task automation, respectively. However, adversaries exploit these for malicious purposes, such as downloading encrypted tools to evade detection. The detection rule identifies unusual downloads of these files from external sources, flagging potential threats by monitoring network traffic and excluding trusted internal IP ranges. + +### Possible investigation steps + +- Review the network traffic logs to identify the internal host that initiated the download, focusing on the source IP addresses within the ranges 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. +- Examine the destination IP address of the download to determine if it is associated with known malicious activity or if it is an unusual external IP not typically accessed by the organization. +- Analyze the downloaded file's URL extension or path to confirm if it matches .ps1 or .rar, and assess whether this is expected behavior for the identified host or user. +- Check the internal host's recent activity for any signs of lateral movement or further suspicious downloads, which could indicate a broader compromise. +- Investigate the user account associated with the internal host to verify if the download aligns with their typical usage patterns and permissions. +- Utilize threat intelligence sources to gather additional context on the downloaded file or the external IP address to assess potential risks or known threats. + +### False positive analysis + +- Internal software updates or legitimate administrative scripts may trigger the rule. To manage this, create exceptions for known internal update servers or trusted administrative IP addresses. +- Automated backup processes that use RAR files for compression can be mistaken for threats. Exclude IP addresses or domains associated with these backup services from the rule. +- Development environments often download scripts for testing purposes. Identify and exclude IP ranges or specific hosts associated with development activities to prevent false positives. +- Security tools that download threat intelligence or updates in RAR format might be flagged. Whitelist the IP addresses of these security tools to avoid unnecessary alerts. +- Regularly review and update the list of trusted internal IP ranges to ensure that legitimate traffic is not incorrectly flagged as suspicious. + +### Response and remediation + +- Isolate the affected host from the network immediately to prevent further lateral movement or data exfiltration. +- Conduct a thorough scan of the isolated host using updated antivirus and anti-malware tools to identify and remove any malicious files or scripts. +- Review and analyze network logs to identify any other potentially compromised systems or unusual outbound connections that may indicate further compromise. +- Reset credentials and access tokens for the affected host and any other systems that may have been accessed using the compromised host. +- Restore the affected system from a known good backup if malware removal is not feasible or if the system's integrity is in question. +- Implement network segmentation to limit the ability of threats to move laterally within the network in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation and recovery efforts. + +## Threat intel This activity has been observed in FIN7 campaigns.""" references = [ diff --git a/rules/network/command_and_control_halfbaked_beacon.toml b/rules/network/command_and_control_halfbaked_beacon.toml index db956efc006..596e6fc33f4 100644 --- a/rules/network/command_and_control_halfbaked_beacon.toml +++ b/rules/network/command_and_control_halfbaked_beacon.toml @@ -2,7 +2,7 @@ creation_date = "2020/07/06" integration = ["network_traffic"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -21,7 +21,42 @@ index = ["packetbeat-*", "auditbeat-*", "filebeat-*", "logs-network_traffic.*"] language = "lucene" license = "Elastic License v2" name = "Halfbaked Command and Control Beacon" -note = """## Threat intel +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Halfbaked Command and Control Beacon + +Halfbaked malware exploits common network protocols to maintain persistence and facilitate command and control (C2) operations within compromised networks. Adversaries leverage HTTP and TLS protocols to disguise malicious traffic as legitimate, often targeting specific ports like 53, 80, 8080, and 443. The detection rule identifies suspicious network patterns, such as unusual URL structures and specific transport protocols, to flag potential C2 beaconing activities. + +### Possible investigation steps + +- Review the network traffic logs to identify any connections to IP addresses matching the pattern specified in the query (e.g., http://[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}/cd) and determine if these IPs are known or suspicious. +- Analyze the destination ports (53, 80, 8080, 443) used in the flagged traffic to assess if they align with typical usage patterns for the affected systems or if they indicate potential misuse. +- Examine the HTTP and TLS traffic details to identify any unusual URL structures or anomalies in the network.protocol field that could suggest malicious activity. +- Correlate the detected network activity with endpoint logs to identify any associated processes or applications that may have initiated the suspicious traffic. +- Investigate any related alerts or historical data for patterns of similar activity, which could indicate a persistent threat or ongoing compromise within the network. + +### False positive analysis + +- Legitimate software updates or patch management systems may use similar URL structures and ports, leading to false positives. Users can create exceptions for known update servers by whitelisting their IP addresses or domain names. +- Internal web applications or services that use non-standard ports like 8080 for HTTP traffic might trigger the rule. Identify these applications and exclude their traffic from the rule by specifying their IP addresses or domain names. +- Network monitoring tools or security appliances that perform regular scans or health checks over HTTP or TLS might mimic the detected patterns. Exclude these tools by adding their IP addresses to an exception list. +- Content delivery networks (CDNs) often use IP-based URLs for load balancing and might be mistaken for malicious activity. Verify the legitimacy of the CDN traffic and exclude it by whitelisting the associated IP ranges. +- Automated scripts or bots within the network that access external resources using IP-based URLs could trigger alerts. Review these scripts and, if deemed safe, exclude their traffic by specifying their source IP addresses. + +### Response and remediation + +- Isolate the affected systems from the network immediately to prevent further communication with the command and control server. +- Conduct a thorough scan of the isolated systems using updated antivirus and anti-malware tools to identify and remove the Halfbaked malware. +- Analyze network traffic logs to identify other potentially compromised systems by looking for similar suspicious network patterns and URL structures. +- Block the identified malicious IP addresses and domains at the network perimeter to prevent further communication attempts. +- Apply security patches and updates to all systems and applications to close vulnerabilities exploited by the malware. +- Restore affected systems from clean backups, ensuring that the backups are free from any signs of compromise. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the scope of the breach. + +## Threat intel This activity has been observed in FIN7 campaigns.""" references = [ diff --git a/rules/network/command_and_control_nat_traversal_port_activity.toml b/rules/network/command_and_control_nat_traversal_port_activity.toml index f61786952a2..2ef50d5c32a 100644 --- a/rules/network/command_and_control_nat_traversal_port_activity.toml +++ b/rules/network/command_and_control_nat_traversal_port_activity.toml @@ -2,7 +2,7 @@ creation_date = "2020/02/18" integration = ["network_traffic", "panw"] maturity = "production" -updated_date = "2024/09/18" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -35,6 +35,41 @@ type = "query" query = ''' (event.dataset: network_traffic.flow or (event.category: (network or network_traffic))) and network.transport:udp and destination.port:4500 ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 IPSEC NAT Traversal Port Activity + +IPSEC NAT Traversal facilitates secure VPN communication across NAT devices by encapsulating IPSEC packets in UDP, typically using port 4500. While essential for legitimate encrypted traffic, adversaries exploit this to mask malicious activities, bypassing network defenses. The detection rule identifies unusual UDP traffic on port 4500, flagging potential misuse for further investigation. + +### Possible investigation steps + +- Review the source and destination IP addresses associated with the UDP traffic on port 4500 to determine if they are known or expected within your network environment. +- Analyze the volume and frequency of the detected traffic to assess whether it aligns with typical IPSEC NAT Traversal usage or if it appears anomalous. +- Check for any associated network traffic events in the same timeframe that might indicate a pattern of suspicious activity, such as unusual data transfer volumes or connections to known malicious IP addresses. +- Investigate the endpoint or device generating the traffic to verify if it is authorized to use IPSEC NAT Traversal and if it has any history of security incidents or vulnerabilities. +- Correlate the detected activity with any recent changes in network configurations or security policies that might explain the traffic pattern. +- Consult threat intelligence sources to determine if the destination IP address or domain has been associated with known threat actors or command and control infrastructure. + +### False positive analysis + +- Legitimate VPN traffic using IPSEC NAT Traversal can trigger alerts. Regularly review and whitelist known IP addresses or subnets associated with authorized VPN connections to reduce false positives. +- Network devices or services that rely on IPSEC for secure communication may generate expected traffic on port 4500. Identify and document these devices, then create exceptions in the detection rule to prevent unnecessary alerts. +- Automated backup or synchronization services that use IPSEC for secure data transfer might be flagged. Monitor these services and exclude their traffic patterns if they are verified as non-threatening. +- Some enterprise applications may use IPSEC NAT Traversal for secure communication. Conduct an inventory of such applications and adjust the rule to exclude their traffic after confirming their legitimacy. +- Regularly update the list of known safe IP addresses and services to ensure that new legitimate sources of IPSEC NAT Traversal traffic are promptly excluded from triggering alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further potential malicious activity and lateral movement. +- Conduct a thorough analysis of the isolated system to identify any signs of compromise, such as unauthorized access or data exfiltration, focusing on logs and network traffic related to UDP port 4500. +- Block all suspicious IP addresses associated with the detected traffic on port 4500 at the network perimeter to prevent further communication with potential threat actors. +- Review and update firewall and intrusion detection/prevention system (IDS/IPS) rules to ensure they effectively block unauthorized IPSEC NAT Traversal traffic, particularly on UDP port 4500. +- Restore the affected system from a known good backup if any signs of compromise are confirmed, ensuring that all security patches and updates are applied before reconnecting to the network. +- 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 enhanced monitoring and logging for UDP traffic on port 4500 to detect and respond to any future suspicious activity promptly.""" [[rule.threat]] diff --git a/rules/network/command_and_control_port_26_activity.toml b/rules/network/command_and_control_port_26_activity.toml index 2a01401278b..efb432dd0ca 100644 --- a/rules/network/command_and_control_port_26_activity.toml +++ b/rules/network/command_and_control_port_26_activity.toml @@ -2,7 +2,7 @@ creation_date = "2020/02/18" integration = ["network_traffic", "panw"] maturity = "production" -updated_date = "2024/09/18" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -36,6 +36,40 @@ type = "query" query = ''' (event.dataset: (network_traffic.flow or zeek.smtp) or event.category:(network or network_traffic)) and network.transport:tcp and destination.port:26 ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 SMTP on Port 26/TCP + +SMTP, typically operating on port 25, is crucial for email transmission. However, port 26 is often used to avoid conflicts or restrictions on port 25. Adversaries exploit this by using port 26 for covert command and control, as seen with the BadPatch malware. The detection rule identifies suspicious SMTP activity on port 26 by analyzing network traffic patterns, helping to uncover potential threats. + +### Possible investigation steps + +- Review the network traffic logs to identify any unusual patterns or anomalies associated with TCP port 26, focusing on the event.dataset fields such as network_traffic.flow or zeek.smtp. +- Analyze the source and destination IP addresses involved in the alert to determine if they are known or associated with any previous suspicious activities. +- Check for any additional alerts or logs related to the same source or destination IP addresses to identify potential patterns or repeated attempts of communication on port 26. +- Investigate the context of the communication by examining the payload data, if available, to identify any indicators of compromise or malicious content. +- Correlate the findings with threat intelligence sources to determine if the IP addresses or domains are associated with known threat actors or malware, such as BadPatch. +- Assess the risk and impact on the affected systems by determining if any sensitive data or critical systems are involved in the communication on port 26. + +### False positive analysis + +- Legitimate mail transfer agents may use port 26 to avoid conflicts with port 25. Identify these agents and create exceptions in the detection rule to prevent unnecessary alerts. +- Some network configurations might reroute SMTP traffic to port 26 for load balancing or security reasons. Verify these configurations and whitelist known IP addresses or domains to reduce false positives. +- Internal testing or development environments might use port 26 for non-malicious purposes. Document these environments and exclude their traffic from triggering alerts. +- Certain email service providers may use port 26 as an alternative to port 25. Confirm these providers and adjust the rule to recognize their traffic as benign. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further command and control communication via port 26. +- Conduct a thorough scan of the isolated system using updated antivirus and anti-malware tools to identify and remove the BadPatch malware or any other malicious software. +- Review and analyze network logs to identify any other systems that may have communicated with the same command and control server, and isolate those systems as well. +- Change all passwords and credentials that may have been compromised or accessed by the affected system to prevent unauthorized access. +- Apply security patches and updates to the affected system and any other vulnerable systems to mitigate exploitation by similar threats. +- Monitor network traffic for any further suspicious activity on port 26 and other non-standard ports, adjusting firewall rules to block unauthorized SMTP traffic. +- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and to ensure comprehensive threat eradication.""" [[rule.threat]] diff --git a/rules/network/command_and_control_rdp_remote_desktop_protocol_from_the_internet.toml b/rules/network/command_and_control_rdp_remote_desktop_protocol_from_the_internet.toml index e9e59ab3aeb..b18ea2517f5 100644 --- a/rules/network/command_and_control_rdp_remote_desktop_protocol_from_the_internet.toml +++ b/rules/network/command_and_control_rdp_remote_desktop_protocol_from_the_internet.toml @@ -2,7 +2,7 @@ creation_date = "2020/02/18" integration = ["network_traffic", "panw"] maturity = "production" -updated_date = "2024/09/18" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -74,6 +74,40 @@ query = ''' 192.168.0.0/16 ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 RDP (Remote Desktop Protocol) from the Internet + +RDP allows administrators to remotely manage systems, but exposing it to the internet poses security risks. Adversaries exploit RDP for unauthorized access, often using it as an entry point for attacks. The detection rule identifies suspicious RDP traffic by monitoring TCP connections on port 3389 from external IPs, flagging potential threats for further investigation. + +### Possible investigation steps + +- Review the source IP address flagged in the alert to determine if it is known or associated with any previous malicious activity. Check threat intelligence sources for any reported malicious behavior. +- Analyze the destination IP address to confirm it belongs to your internal network (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) and identify the specific system targeted by the RDP connection. +- Examine network logs for any unusual or unexpected RDP traffic patterns from the source IP, such as repeated connection attempts or connections at odd hours, which may indicate brute force attempts or unauthorized access. +- Check for any recent changes or updates to firewall rules or security policies that might have inadvertently exposed RDP to the internet. +- Investigate the user accounts involved in the RDP session to ensure they are legitimate and have not been compromised. Look for any signs of unauthorized access or privilege escalation. +- Correlate the RDP traffic with other security events or alerts to identify any potential lateral movement or further malicious activity within the network. + +### False positive analysis + +- Internal testing or maintenance activities may trigger the rule if RDP is temporarily exposed to the internet. To manage this, create exceptions for known internal IP addresses or scheduled maintenance windows. +- Legitimate third-party vendors or partners accessing systems via RDP for support purposes can be mistaken for threats. Establish a list of trusted external IP addresses and exclude them from the rule. +- Misconfigured network devices or security tools might inadvertently expose RDP to the internet, leading to false positives. Regularly audit network configurations and update the rule to exclude known benign sources. +- Cloud-based services or remote work solutions that use RDP over the internet can be flagged. Identify and whitelist these services' IP ranges to prevent unnecessary alerts. + +### Response and remediation + +- Immediately block the external IP address identified in the alert from accessing the network to prevent further unauthorized RDP connections. +- Isolate the affected system from the network to contain any potential compromise and prevent lateral movement by the threat actor. +- Conduct a thorough review of the affected system for signs of compromise, such as unauthorized user accounts, changes in system configurations, or the presence of malware. +- Reset credentials for any accounts that were accessed or potentially compromised during the incident to prevent unauthorized access. +- Apply security patches and updates to the affected system and any other systems with RDP enabled to mitigate known vulnerabilities. +- Implement network segmentation to restrict RDP access to only trusted internal IP addresses and consider using a VPN for secure remote access. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/network/command_and_control_vnc_virtual_network_computing_from_the_internet.toml b/rules/network/command_and_control_vnc_virtual_network_computing_from_the_internet.toml index db915e0a059..f54e7110307 100644 --- a/rules/network/command_and_control_vnc_virtual_network_computing_from_the_internet.toml +++ b/rules/network/command_and_control_vnc_virtual_network_computing_from_the_internet.toml @@ -2,7 +2,7 @@ creation_date = "2020/02/18" integration = ["network_traffic", "panw"] maturity = "production" -updated_date = "2024/09/18" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -70,6 +70,40 @@ query = ''' 192.168.0.0/16 ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 VNC (Virtual Network Computing) from the Internet + +VNC allows remote control of systems, facilitating maintenance and resource sharing. However, when exposed to the Internet, it becomes a target for attackers seeking unauthorized access. Adversaries exploit VNC for initial access or as a backdoor. The detection rule identifies suspicious VNC traffic by monitoring specific TCP ports and filtering out trusted IP ranges, flagging potential threats for further investigation. + +### Possible investigation steps + +- Review the source IP address of the alert to determine if it is from an untrusted or suspicious location, as the rule filters out known trusted IP ranges. +- Check the destination IP address to confirm it belongs to an internal network (10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16) and verify if the system is authorized to receive VNC traffic. +- Analyze the network traffic logs for the specified TCP ports (5800-5810) to identify any unusual patterns or repeated access attempts that could indicate malicious activity. +- Investigate the context of the event by correlating it with other security alerts or logs to determine if there are signs of a broader attack or compromise. +- Assess the risk and impact of the potential threat by evaluating the criticality of the affected system and any sensitive data it may contain. + +### False positive analysis + +- Internal testing or maintenance activities may trigger the rule if VNC is used for legitimate purposes within a controlled environment. To manage this, create exceptions for known internal IP addresses that frequently use VNC for authorized tasks. +- Automated systems or scripts that utilize VNC for routine operations might be flagged. Identify these systems and exclude their IP addresses from the rule to prevent unnecessary alerts. +- Remote workers using VPNs that route traffic through public IPs could be mistakenly identified as threats. Ensure that VPN IP ranges are included in the trusted IP list to avoid false positives. +- Misconfigured network devices that inadvertently expose VNC ports to the Internet can cause alerts. Regularly audit network configurations to ensure VNC ports are not exposed and adjust the rule to exclude known safe configurations. +- Third-party service providers accessing systems via VNC for support purposes might be flagged. Establish a list of trusted IPs for these providers and update the rule to exclude them from detection. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any active VNC sessions originating from untrusted IP addresses to cut off potential attacker access. +- Conduct a thorough review of system logs and network traffic to identify any unauthorized changes or data access that may have occurred during the VNC session. +- Reset credentials for any accounts that were accessed or could have been compromised during the unauthorized VNC session. +- Apply security patches and updates to the VNC software and any other potentially vulnerable applications on the affected system. +- Implement network segmentation to ensure that VNC services are only accessible from trusted internal networks and not exposed to the Internet. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be affected.""" [[rule.threat]] diff --git a/rules/network/command_and_control_vnc_virtual_network_computing_to_the_internet.toml b/rules/network/command_and_control_vnc_virtual_network_computing_to_the_internet.toml index f7f629214dd..b090c72300a 100644 --- a/rules/network/command_and_control_vnc_virtual_network_computing_to_the_internet.toml +++ b/rules/network/command_and_control_vnc_virtual_network_computing_to_the_internet.toml @@ -2,7 +2,7 @@ creation_date = "2020/02/18" integration = ["network_traffic", "panw"] maturity = "production" -updated_date = "2024/09/18" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -70,6 +70,41 @@ query = ''' "FF00::/8" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 VNC (Virtual Network Computing) to the Internet + +VNC is a tool that allows remote control of computers, often used by administrators for maintenance. However, when exposed to the internet, it becomes a target for attackers seeking unauthorized access. Adversaries exploit VNC to establish backdoors or gain initial access. The detection rule identifies suspicious VNC traffic by monitoring specific TCP ports and filtering out internal IP addresses, flagging potential threats when VNC is accessed from external networks. + +### Possible investigation steps + +- Review the source IP address to determine if it belongs to a known internal asset or user, and verify if the access was authorized. +- Check the destination IP address to confirm if it is an external address and investigate its reputation or any known associations with malicious activity. +- Analyze the network traffic logs for the specified TCP ports (5800-5810) to identify any unusual patterns or volumes of VNC traffic. +- Correlate the VNC traffic event with other security events or logs to identify any related suspicious activities or anomalies. +- Investigate the user account associated with the VNC session to ensure it has not been compromised or misused. +- Assess the system or application logs on the destination machine for any signs of unauthorized access or changes during the time of the VNC connection. + +### False positive analysis + +- Internal maintenance activities may trigger the rule if VNC is used for legitimate remote administration. To manage this, create exceptions for known internal IP addresses that frequently use VNC for maintenance. +- Automated scripts or tools that use VNC for legitimate purposes might be flagged. Identify these tools and whitelist their IP addresses to prevent unnecessary alerts. +- Testing environments that simulate external access to VNC for security assessments can cause false positives. Exclude IP ranges associated with these environments to avoid confusion. +- Cloud-based services that use VNC for remote management might be misidentified as threats. Verify these services and add their IP addresses to an exception list if they are trusted. +- Temporary remote access setups for troubleshooting or support can be mistaken for unauthorized access. Document these instances and apply temporary exceptions to reduce false alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any active VNC sessions that are identified as originating from external networks to cut off potential attacker access. +- Conduct a thorough review of system logs and network traffic to identify any unauthorized access or data transfer that may have occurred during the VNC exposure. +- Change all passwords and credentials associated with the affected system and any other systems that may have been accessed using the same credentials. +- Apply necessary patches and updates to the VNC software and any other vulnerable applications on the affected system to mitigate known vulnerabilities. +- Implement network segmentation to ensure that VNC services are only accessible from trusted internal networks and not exposed to the internet. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be compromised.""" [[rule.threat]] diff --git a/rules/network/discovery_potential_network_sweep_detected.toml b/rules/network/discovery_potential_network_sweep_detected.toml index 1f4a3572f07..7a820bdef70 100644 --- a/rules/network/discovery_potential_network_sweep_detected.toml +++ b/rules/network/discovery_potential_network_sweep_detected.toml @@ -2,7 +2,7 @@ creation_date = "2023/05/17" integration = ["endpoint", "network_traffic", "panw"] maturity = "production" -updated_date = "2024/09/18" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -37,6 +37,47 @@ query = ''' destination.port : (21 or 22 or 23 or 25 or 139 or 445 or 3389 or 5985 or 5986) and source.ip : (10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Network Sweep Detected + +Network sweeps are reconnaissance techniques where attackers scan networks to identify active hosts and services, often targeting common ports. This activity helps adversaries map out network vulnerabilities for future exploitation. The detection rule identifies such sweeps by monitoring connection attempts from a single source to multiple destinations on key ports, flagging potential reconnaissance activities for further investigation. + +### Possible investigation steps + +- Review the source IP address to determine if it belongs to a known or trusted entity within the network, focusing on the private IP ranges specified in the query (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). +- Analyze the destination IP addresses to identify any patterns or commonalities, such as specific subnets or devices, that could indicate targeted reconnaissance. +- Check historical logs for previous connection attempts from the same source IP to see if there is a pattern of repeated scanning behavior or if this is an isolated incident. +- Investigate the specific ports targeted (21, 22, 23, 25, 139, 445, 3389, 5985, 5986) to determine if they are associated with critical services or known vulnerabilities within the network. +- Correlate the detected activity with any recent changes or incidents in the network environment that might explain the behavior, such as new device deployments or configuration changes. +- Consult threat intelligence sources to determine if the source IP or similar scanning patterns have been associated with known threat actors or campaigns. + +### False positive analysis + +- Internal network scans by IT teams can trigger the rule. Regularly scheduled scans for security assessments should be documented and their source IPs added to an exception list to prevent false alerts. +- Automated monitoring tools that check network health might cause false positives. Identify these tools and exclude their IP addresses from the rule to avoid unnecessary alerts. +- Load balancers or network devices that perform health checks across multiple hosts can be mistaken for network sweeps. Exclude these devices by adding their IPs to a whitelist. +- Development or testing environments where multiple connections are made for legitimate purposes can trigger the rule. Ensure these environments are recognized and their IP ranges are excluded from monitoring. +- Misconfigured devices that repeatedly attempt to connect to multiple hosts can appear as network sweeps. Investigate and correct the configuration, then exclude these devices if necessary. + +### Response and remediation + +- Isolate the source IP: Immediately isolate the source IP address identified in the alert from the network to prevent further reconnaissance or potential exploitation of identified vulnerabilities. + +- Block suspicious ports: Implement firewall rules to block incoming and outgoing traffic on the commonly targeted ports (21, 22, 23, 25, 139, 445, 3389, 5985, 5986) from the source IP to mitigate further scanning attempts. + +- Conduct a network-wide scan: Perform a comprehensive scan of the network to identify any unauthorized access or changes that may have occurred as a result of the network sweep. + +- Review and update access controls: Ensure that access controls and permissions are appropriately configured to limit exposure of critical services and sensitive data. + +- Monitor for recurrence: Set up enhanced monitoring and alerting for any future connection attempts from the source IP or similar patterns of network sweep activity. + +- Escalate to security operations: Notify the security operations team to conduct a deeper investigation into the source of the network sweep and assess any potential threats or breaches. + +- Document and report: Record all findings, actions taken, and lessons learned in an incident report to inform future response strategies and improve network defenses.""" [[rule.threat]] diff --git a/rules/network/discovery_potential_port_scan_detected.toml b/rules/network/discovery_potential_port_scan_detected.toml index 718b4ef6da1..d7027d60f63 100644 --- a/rules/network/discovery_potential_port_scan_detected.toml +++ b/rules/network/discovery_potential_port_scan_detected.toml @@ -2,7 +2,7 @@ creation_date = "2023/05/17" integration = ["endpoint", "network_traffic", "panw"] maturity = "production" -updated_date = "2024/09/18" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -37,6 +37,41 @@ type = "threshold" query = ''' destination.port : * and event.action : "network_flow" and source.ip : (10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Network Scan Detected + +Network scanning is a technique used to identify open ports and services on a network, often exploited by attackers to find vulnerabilities. Adversaries may use this method to map out a network's structure and identify weak points for further exploitation. The detection rule identifies suspicious activity by monitoring for multiple connection attempts from a single source to numerous destination ports, indicating a potential scan. This helps in early detection and mitigation of reconnaissance activities. + +### Possible investigation steps + +- Review the source IP address involved in the alert to determine if it belongs to a known or trusted entity within the organization. Check if the IP falls within the specified ranges: 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. +- Analyze the network flow logs to identify the specific destination ports that were targeted by the source IP. Determine if these ports are associated with critical services or known vulnerabilities. +- Correlate the detected activity with any recent changes or updates in the network infrastructure that might explain the scanning behavior, such as new devices or services being deployed. +- Investigate if there are any other alerts or logs indicating similar scanning activities from the same source IP or other IPs within the same subnet, which might suggest a coordinated scanning effort. +- Check for any historical data or past incidents involving the source IP to assess if this behavior is part of a recurring pattern or a new anomaly. +- Consult with network administrators to verify if the detected activity aligns with any scheduled network assessments or security tests that might have been conducted without prior notification. + +### False positive analysis + +- Internal network scanning tools used for legitimate security assessments can trigger this rule. To manage this, create exceptions for known IP addresses of authorized scanning tools. +- Automated network monitoring systems that check service availability across multiple ports may be flagged. Exclude these systems by identifying their IP addresses and adding them to an exception list. +- Load balancers and network devices that perform health checks on various services might cause false positives. Identify these devices and configure the rule to ignore their IP addresses. +- Development and testing environments where frequent port scanning is part of routine operations can be mistakenly flagged. Implement exceptions for these environments by specifying their IP ranges. +- Regularly scheduled vulnerability assessments conducted by internal security teams can appear as network scans. Document these activities and exclude the associated IPs from triggering the rule. + +### Response and remediation + +- Isolate the affected host: Immediately disconnect the source IP from the network to prevent further scanning or potential exploitation of identified vulnerabilities. +- Conduct a thorough investigation: Analyze the source IP's activity logs to determine if any unauthorized access or data exfiltration has occurred. This will help assess the extent of the threat. +- Update firewall rules: Implement stricter access controls to limit the number of open ports and restrict unnecessary inbound and outbound traffic from the affected IP range. +- Patch and update systems: Ensure all systems and services identified during the scan are up-to-date with the latest security patches to mitigate known vulnerabilities. +- Monitor for recurrence: Set up enhanced monitoring for the source IP and similar scanning patterns to quickly detect and respond to any future scanning attempts. +- Escalate to security operations: If the scan is part of a larger attack or if sensitive data is at risk, escalate the incident to the security operations team for further analysis and response. +- Review and enhance detection capabilities: Evaluate the effectiveness of current detection mechanisms and consider integrating additional threat intelligence sources to improve early detection of similar threats.""" [[rule.threat]] diff --git a/rules/network/discovery_potential_syn_port_scan_detected.toml b/rules/network/discovery_potential_syn_port_scan_detected.toml index 7a85fc4e8c0..769793bfc66 100644 --- a/rules/network/discovery_potential_syn_port_scan_detected.toml +++ b/rules/network/discovery_potential_syn_port_scan_detected.toml @@ -37,6 +37,41 @@ type = "threshold" query = ''' destination.port : * and network.packets <= 2 and source.ip : (10.0.0.0/8 or 172.16.0.0/12 or 192.168.0.0/16) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 SYN-Based Port Scan Detected + +SYN-based port scanning is a reconnaissance technique where attackers send SYN packets to multiple ports to identify open services. This method helps adversaries map network vulnerabilities for potential exploitation. The detection rule identifies such scans by flagging connection attempts from internal IPs to multiple ports with minimal packet exchange, indicating a low-risk reconnaissance activity. + +### Possible investigation steps + +- Review the source IP address involved in the alert to determine if it belongs to a known or authorized device within the network. Check for any recent changes or unusual activity associated with this IP. +- Analyze the destination ports targeted by the scan to identify any patterns or specific services that may be of interest to the attacker. Determine if these ports are associated with critical or vulnerable services. +- Examine historical logs to identify any previous scanning activity from the same source IP or similar patterns of behavior. This can help establish whether the activity is part of a larger reconnaissance effort. +- Correlate the alert with other security events or alerts to assess if there is a broader attack campaign underway. Look for related alerts that might indicate subsequent exploitation attempts. +- Investigate the timing and frequency of the scan attempts to understand if they coincide with other suspicious activities or known attack windows. This can provide context on the attacker's intent and urgency. +- Assess the network's current security posture and ensure that appropriate defenses, such as firewalls and intrusion detection systems, are configured to mitigate potential exploitation of identified open ports. + +### False positive analysis + +- Internal network scanning tools or scripts used by IT teams for legitimate network mapping can trigger this rule. To manage this, create exceptions for known internal IP addresses or subnets used by IT for network discovery. +- Automated monitoring systems or security appliances that perform regular port checks might be flagged. Identify these systems and exclude their IP addresses from the rule to prevent false positives. +- Software updates or patch management systems that check multiple ports for service availability can be mistaken for a SYN-based port scan. Whitelist these systems to avoid unnecessary alerts. +- Load balancers or network devices that perform health checks across multiple ports may trigger the rule. Exclude these devices from the rule to ensure accurate detection. +- Development or testing environments where multiple port scans are part of routine operations can cause false positives. Implement exceptions for these environments to maintain focus on genuine threats. + +### Response and remediation + +- Isolate the affected internal IP address to prevent further reconnaissance or potential exploitation of identified open ports. +- Conduct a thorough review of firewall and network access control lists to ensure that only necessary ports are open and accessible from internal networks. +- Implement rate limiting on SYN packets to reduce the risk of successful port scanning and reconnaissance activities. +- Monitor the network for any unusual outbound traffic from the affected IP address, which may indicate further malicious activity or data exfiltration attempts. +- Escalate the incident to the security operations team for further analysis and to determine if additional network segments or systems are affected. +- Update intrusion detection and prevention systems to enhance detection capabilities for similar SYN-based port scanning activities. +- Review and update network segmentation policies to limit the exposure of critical services and systems to internal reconnaissance activities.""" [[rule.threat]] diff --git a/rules/network/initial_access_rpc_remote_procedure_call_from_the_internet.toml b/rules/network/initial_access_rpc_remote_procedure_call_from_the_internet.toml index ddaf50fd579..15dc1128feb 100644 --- a/rules/network/initial_access_rpc_remote_procedure_call_from_the_internet.toml +++ b/rules/network/initial_access_rpc_remote_procedure_call_from_the_internet.toml @@ -2,7 +2,7 @@ creation_date = "2020/02/18" integration = ["network_traffic", "panw"] maturity = "production" -updated_date = "2024/09/18" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -62,6 +62,40 @@ query = ''' 192.168.0.0/16 ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 RPC (Remote Procedure Call) from the Internet + +RPC enables remote management and resource sharing, crucial for system administration. However, when exposed to the Internet, it becomes a target for attackers seeking initial access or backdoor entry. The detection rule identifies suspicious RPC traffic by monitoring TCP port 135 and filtering out internal IP addresses, flagging potential threats from external sources. + +### Possible investigation steps + +- Review the source IP address of the alert to determine if it is from a known malicious actor or if it has been flagged in previous incidents. +- Check the destination IP address to confirm it belongs to a critical internal system that should not be exposed to the Internet. +- Analyze network traffic logs to identify any unusual patterns or volumes of traffic associated with the source IP, focusing on TCP port 135. +- Investigate any related alerts or logs from the same source IP or destination IP to identify potential patterns or repeated attempts. +- Assess the potential impact on the affected system by determining if any unauthorized access or changes have occurred. +- Consult threat intelligence sources to gather additional context on the source IP or any related indicators of compromise. + +### False positive analysis + +- Internal testing or development environments may generate RPC traffic that appears to originate from external sources. To manage this, add the IP addresses of these environments to the exception list in the detection rule. +- Legitimate remote management activities by trusted third-party vendors could trigger the rule. Verify the IP addresses of these vendors and include them in the exception list if they are known and authorized. +- Misconfigured network devices or proxies might route internal RPC traffic through external IP addresses. Review network configurations to ensure proper routing and add any necessary exceptions for known devices. +- Cloud-based services or applications that use RPC for legitimate purposes might be flagged. Identify these services and adjust the rule to exclude their IP ranges if they are verified as non-threatening. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. +- Conduct a thorough examination of the system logs and network traffic to identify any unauthorized access or data exfiltration attempts. +- Apply the latest security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Change all administrative and user credentials on the affected system and any other systems that may have been accessed using the same credentials. +- Implement network segmentation to limit the exposure of critical systems and services, ensuring that RPC services are not accessible from the Internet. +- Monitor the network for any signs of re-infection or further suspicious activity, focusing on traffic patterns similar to those identified in the initial alert. +- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and to determine if additional systems are compromised.""" [[rule.threat]] diff --git a/rules/network/initial_access_rpc_remote_procedure_call_to_the_internet.toml b/rules/network/initial_access_rpc_remote_procedure_call_to_the_internet.toml index 765d3d433c4..c8e3273c24b 100644 --- a/rules/network/initial_access_rpc_remote_procedure_call_to_the_internet.toml +++ b/rules/network/initial_access_rpc_remote_procedure_call_to_the_internet.toml @@ -2,7 +2,7 @@ creation_date = "2020/02/18" integration = ["network_traffic", "panw"] maturity = "production" -updated_date = "2024/09/18" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -62,6 +62,40 @@ query = ''' "FF00::/8" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 RPC (Remote Procedure Call) to the Internet + +RPC enables remote management and resource sharing across networks, crucial for system administration. However, when exposed to the Internet, it becomes a target for attackers seeking initial access or backdoor entry. The detection rule identifies suspicious RPC traffic from internal IPs to external networks, flagging potential exploitation attempts by monitoring specific ports and IP ranges. + +### Possible investigation steps + +- Review the source IP address from the alert to identify the internal system initiating the RPC traffic. Check if this IP belongs to a known or authorized device within the network. +- Examine the destination IP address to determine if it is a known or suspicious external entity. Use threat intelligence sources to assess if the IP has been associated with malicious activity. +- Analyze the network traffic logs for the specific event.dataset values (network_traffic.flow or zeek.dce_rpc) to gather more context about the nature and volume of the RPC traffic. +- Investigate the destination port, specifically port 135, to confirm if the traffic is indeed RPC-related and assess if there are any legitimate reasons for this communication. +- Check for any recent changes or anomalies in the network configuration or system settings of the source IP that might explain the unexpected RPC traffic. +- Correlate this alert with other security events or logs to identify any patterns or additional indicators of compromise that might suggest a broader attack campaign. + +### False positive analysis + +- Internal testing environments may generate RPC traffic to external IPs for legitimate purposes. Identify and document these environments, then create exceptions in the detection rule to prevent unnecessary alerts. +- Cloud-based services or applications that require RPC communication for integration or management might trigger false positives. Review these services and whitelist their IP addresses if they are verified as non-threatening. +- VPN or remote access solutions that use RPC for secure connections can be mistaken for suspicious activity. Ensure that the IP ranges of these solutions are excluded from the rule to avoid false alerts. +- Automated backup or synchronization tools that use RPC to communicate with external servers could be flagged. Verify these tools and add their destination IPs to an exception list if they are part of routine operations. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Conduct a thorough analysis of the affected system to identify any unauthorized changes or installed backdoors, focusing on processes and services related to RPC. +- Revoke any compromised credentials and enforce a password reset for all accounts that may have been accessed or used during the incident. +- Apply necessary patches and updates to the affected system and any other systems with similar vulnerabilities to mitigate the risk of exploitation. +- Monitor network traffic for any signs of lateral movement or additional suspicious activity, particularly focusing on RPC-related traffic. +- 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 enhanced logging and monitoring for RPC traffic to detect and respond to similar threats more effectively in the future.""" [[rule.threat]] diff --git a/rules/network/initial_access_smb_windows_file_sharing_activity_to_the_internet.toml b/rules/network/initial_access_smb_windows_file_sharing_activity_to_the_internet.toml index ec784917be1..bbabffd04b1 100644 --- a/rules/network/initial_access_smb_windows_file_sharing_activity_to_the_internet.toml +++ b/rules/network/initial_access_smb_windows_file_sharing_activity_to_the_internet.toml @@ -2,7 +2,7 @@ creation_date = "2020/02/18" integration = ["network_traffic", "panw"] maturity = "production" -updated_date = "2024/09/18" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -62,6 +62,41 @@ query = ''' "FF00::/8" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 SMB (Windows File Sharing) Activity to the Internet + +SMB, a protocol for sharing files and resources within trusted networks, is vulnerable when exposed to the Internet. Adversaries exploit it for unauthorized access or data theft. The detection rule identifies suspicious SMB traffic from internal IPs to external networks, flagging potential threats by monitoring specific ports and excluding known safe IP ranges. + +### Possible investigation steps + +- Review the source IP address from the alert to identify the internal system initiating the SMB traffic. Check if this IP belongs to a known device or user within the organization. +- Investigate the destination IP address to determine if it is associated with any known malicious activity or if it belongs to a legitimate external service that might require SMB access. +- Analyze network logs to identify any patterns or anomalies in the SMB traffic, such as unusual data transfer volumes or repeated access attempts, which could indicate malicious activity. +- Check for any recent changes or updates on the source system that might explain the SMB traffic, such as new software installations or configuration changes. +- Correlate the alert with other security events or logs, such as authentication logs or endpoint security alerts, to gather additional context and determine if this is part of a broader attack or isolated incident. +- Consult threat intelligence sources to see if there are any known vulnerabilities or exploits related to the SMB traffic observed, which could provide insight into potential attack vectors. + +### False positive analysis + +- Internal testing environments may generate SMB traffic to external IPs for legitimate reasons. Identify and whitelist these IPs to prevent false positives. +- Cloud services or remote backup solutions might use SMB for data transfer. Verify these services and add their IP ranges to the exception list if they are trusted. +- VPN connections can sometimes appear as external traffic. Ensure that VPN IP ranges are included in the list of known safe IPs to avoid misclassification. +- Misconfigured network devices might inadvertently route SMB traffic externally. Regularly audit network configurations and update the rule exceptions to include any legitimate device IPs. +- Some third-party applications may use SMB for updates or data synchronization. Confirm the legitimacy of these applications and exclude their associated IPs from the detection rule. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Conduct a thorough review of firewall and network configurations to ensure SMB traffic is not allowed to the Internet, and block any unauthorized outbound SMB traffic on ports 139 and 445. +- Perform a comprehensive scan of the isolated system for malware or unauthorized access tools, focusing on identifying any backdoors or persistence mechanisms. +- Reset credentials and review access permissions for any accounts that may have been compromised or used in the suspicious activity. +- Notify the security operations center (SOC) and relevant stakeholders about the incident for further analysis and potential escalation. +- Implement additional monitoring and logging for SMB traffic to detect any future unauthorized attempts to access the Internet. +- Review and update security policies and procedures to prevent similar incidents, ensuring that SMB services are only accessible within trusted network segments.""" [[rule.threat]] diff --git a/rules/network/initial_access_unsecure_elasticsearch_node.toml b/rules/network/initial_access_unsecure_elasticsearch_node.toml index 8f51cb76b9c..2e9b1b4b6f2 100644 --- a/rules/network/initial_access_unsecure_elasticsearch_node.toml +++ b/rules/network/initial_access_unsecure_elasticsearch_node.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/11" integration = ["network_traffic"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -21,7 +21,42 @@ index = ["packetbeat-*", "logs-network_traffic.*"] language = "lucene" license = "Elastic License v2" name = "Inbound Connection to an Unsecure Elasticsearch Node" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Inbound Connection to an Unsecure Elasticsearch Node + +Elasticsearch is a powerful search and analytics engine often used for log and data analysis. When improperly configured without TLS or authentication, it becomes vulnerable to unauthorized access. Adversaries can exploit these weaknesses to gain initial access, exfiltrate data, or disrupt services. The detection rule identifies unsecured nodes by monitoring inbound HTTP traffic on the default port, flagging connections lacking authentication headers, thus highlighting potential exploitation attempts. + +### Possible investigation steps + +- Review the source IP address of the inbound connection to determine if it is from a known or trusted entity. Cross-reference with internal asset inventories or threat intelligence sources. +- Examine the network traffic logs for any unusual patterns or repeated access attempts from the same source IP, which might indicate a brute force or scanning activity. +- Check for any data exfiltration attempts by analyzing outbound traffic from the Elasticsearch node, focusing on large data transfers or connections to unfamiliar external IPs. +- Investigate the absence of authentication headers in the HTTP requests to confirm if the Elasticsearch node is indeed misconfigured and lacks proper security controls. +- Assess the configuration of the Elasticsearch node to ensure that TLS is enabled and authentication mechanisms are properly implemented to prevent unauthorized access. +- Look for any other alerts or logs related to the same Elasticsearch node or source IP to identify potential coordinated attack activities or previous incidents. + +### False positive analysis + +- Internal monitoring tools or scripts that regularly check Elasticsearch node status without authentication can trigger false positives. Exclude these specific IP addresses or user agents from the rule to reduce noise. +- Automated backup systems that interact with Elasticsearch nodes without using authentication headers might be flagged. Identify these systems and create exceptions based on their IP addresses or network segments. +- Development or testing environments where Elasticsearch nodes are intentionally left unsecured for testing purposes can generate alerts. Use network segmentation or specific tags to differentiate these environments and exclude them from the rule. +- Security scans or vulnerability assessments conducted by internal teams may access Elasticsearch nodes without authentication, leading to false positives. Whitelist the IP ranges used by these security tools to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected Elasticsearch node from the network to prevent further unauthorized access or data exfiltration. +- Conduct a thorough review of access logs to identify any unauthorized access or data exfiltration attempts, focusing on connections lacking authentication headers. +- Implement Transport Layer Security (TLS) and enable authentication mechanisms on the Elasticsearch node to secure communications and restrict access to authorized users only. +- Reset credentials and API keys associated with the Elasticsearch node to prevent further unauthorized access using potentially compromised credentials. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized access and steps taken to contain the threat. +- Monitor the network for any signs of continued unauthorized access attempts or related suspicious activity, adjusting detection rules as necessary to capture similar threats. +- Document the incident, including the response actions taken, and conduct a post-incident review to identify any gaps in security controls and improve future response efforts. + +## Setup This rule requires the addition of port `9200` and `send_all_headers` to the `HTTP` protocol configuration in `packetbeat.yml`. See the References section for additional configuration documentation.""" references = [ diff --git a/rules/promotions/credential_access_endgame_cred_dumping_detected.toml b/rules/promotions/credential_access_endgame_cred_dumping_detected.toml index a438cc58550..50bca42993e 100644 --- a/rules/promotions/credential_access_endgame_cred_dumping_detected.toml +++ b/rules/promotions/credential_access_endgame_cred_dumping_detected.toml @@ -2,7 +2,7 @@ creation_date = "2020/02/18" maturity = "production" promotion = true -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -36,6 +36,42 @@ type = "query" query = ''' event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:cred_theft_event or endgame.event_subtype_full:cred_theft_event) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Credential Dumping - Detected - Elastic Endgame + +Elastic Endgame is a security solution that monitors and detects suspicious activities, such as credential dumping, which is a technique used by adversaries to extract sensitive authentication data. Attackers exploit this to gain unauthorized access to systems. The detection rule identifies such threats by analyzing alerts and specific event actions related to credential theft, ensuring timely threat detection and response. + +### Possible investigation steps + +- Review the alert details to confirm the presence of event.kind:alert and event.module:endgame, ensuring the alert is related to the Elastic Endgame detection. +- Examine the event.action and endgame.event_subtype_full fields for the value cred_theft_event to understand the specific credential theft activity detected. +- Check the associated host and user information to identify the potentially compromised system and user accounts. +- Investigate the timeline of events leading up to and following the alert to identify any suspicious activities or patterns that may indicate further compromise. +- Correlate the alert with other security events or logs to determine if this is part of a larger attack or isolated incident. +- Assess the risk score and severity to prioritize the response and determine if immediate action is required to contain the threat. +- Consult the MITRE ATT&CK framework for additional context on the T1003 technique to understand potential attacker methods and improve defensive measures. + +### False positive analysis + +- Routine administrative tasks that involve legitimate credential access tools may trigger alerts. Users can create exceptions for known administrative accounts or tools that are frequently used in these tasks. +- Security software updates or scans that access credential stores might be flagged. Exclude these processes by identifying their specific event actions and adding them to the exception list. +- Automated scripts for system maintenance that require credential access could be misidentified. Review and whitelist these scripts by their unique identifiers or execution paths. +- Legitimate software installations that require elevated privileges may cause alerts. Monitor and exclude these installation processes by verifying their source and purpose. +- Regularly scheduled backups that access credential data might be detected. Ensure these backup processes are recognized and excluded by specifying their event actions in the rule configuration. + +### Response and remediation + +- Isolate the affected system immediately to prevent further unauthorized access and lateral movement within the network. +- Terminate any suspicious processes identified as part of the credential dumping activity to halt ongoing malicious actions. +- Change all potentially compromised credentials, prioritizing those with elevated privileges, to mitigate unauthorized access risks. +- Conduct a thorough review of access logs and system events to identify any additional compromised accounts or systems. +- Restore affected systems from a known good backup to ensure the integrity of the system and data. +- Implement enhanced monitoring on the affected systems and accounts to detect any signs of recurring or related malicious activity. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional containment or remediation actions are necessary.""" [[rule.threat]] diff --git a/rules/promotions/credential_access_endgame_cred_dumping_prevented.toml b/rules/promotions/credential_access_endgame_cred_dumping_prevented.toml index 54622033143..5e548712540 100644 --- a/rules/promotions/credential_access_endgame_cred_dumping_prevented.toml +++ b/rules/promotions/credential_access_endgame_cred_dumping_prevented.toml @@ -2,7 +2,7 @@ creation_date = "2020/02/18" maturity = "production" promotion = true -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -36,6 +36,41 @@ type = "query" query = ''' event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:cred_theft_event or endgame.event_subtype_full:cred_theft_event) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Credential Dumping - Prevented - Elastic Endgame + +Elastic Endgame is a security solution that proactively prevents credential dumping, a technique where attackers extract sensitive authentication data from systems. Adversaries exploit this to gain unauthorized access to networks. The detection rule identifies prevention alerts by monitoring specific event actions and metadata, signaling attempts to steal credentials, thus enabling timely threat mitigation. + +### Possible investigation steps + +- Review the alert details to confirm the presence of event.kind:alert and event.module:endgame, ensuring the alert is related to Elastic Endgame's prevention of credential dumping. +- Examine the event.action and endgame.event_subtype_full fields for the value cred_theft_event to understand the specific credential theft attempt that was prevented. +- Investigate the source and destination systems involved in the alert to identify potential points of compromise or targeted systems. +- Check for any related alerts or events in the same timeframe that might indicate a coordinated attack or further attempts at credential access. +- Assess the user accounts involved in the alert to determine if they have been compromised or if there are any unauthorized access attempts. +- Review the risk score and severity to prioritize the investigation and response actions based on the potential impact on the organization. + +### False positive analysis + +- Routine administrative tools or scripts that access credential stores may trigger alerts. Review and whitelist these tools if they are verified as non-threatening. +- Security software performing legitimate credential checks can be mistaken for credential dumping. Identify and exclude these processes from alert generation. +- Automated backup systems accessing credential data for legitimate purposes might be flagged. Ensure these systems are recognized and excluded from the rule. +- Regular system maintenance activities that involve credential verification could cause false positives. Document and exclude these activities if they are part of standard operations. +- User behavior analytics might misinterpret legitimate user actions as credential theft. Implement user behavior baselines to reduce such false positives. + +### Response and remediation + +- Isolate the affected system immediately to prevent further unauthorized access or lateral movement within the network. +- Terminate any suspicious processes identified as part of the credential dumping attempt to halt ongoing malicious activities. +- Change all potentially compromised credentials, especially those with elevated privileges, to prevent unauthorized access using stolen credentials. +- Conduct a thorough review of access logs and event data to identify any additional systems that may have been targeted or compromised. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation. +- Implement additional monitoring on the affected system and related network segments to detect any further suspicious activities or attempts at credential theft. +- Review and update endpoint protection configurations to ensure that similar threats are detected and prevented in the future, leveraging insights from the MITRE ATT&CK framework.""" [[rule.threat]] diff --git a/rules/promotions/endgame_adversary_behavior_detected.toml b/rules/promotions/endgame_adversary_behavior_detected.toml index 37dae90c425..1fb53f5e198 100644 --- a/rules/promotions/endgame_adversary_behavior_detected.toml +++ b/rules/promotions/endgame_adversary_behavior_detected.toml @@ -2,7 +2,7 @@ creation_date = "2020/02/18" maturity = "production" promotion = true -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -36,4 +36,39 @@ type = "query" query = ''' event.kind:alert and event.module:endgame and (event.action:behavior_protection_event or endgame.event_subtype_full:behavior_protection_event) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Adversary Behavior - Detected - Elastic Endgame + +Elastic Endgame is a security solution designed to detect and prevent adversarial actions by monitoring system behaviors. Adversaries may exploit system vulnerabilities or execute unauthorized actions to compromise environments. This detection rule identifies suspicious behavior by analyzing alerts and specific event actions, flagging potential threats for further investigation. The rule's medium severity and risk score highlight its importance in maintaining security posture. + +### Possible investigation steps + +- Review the alert details in the Elastic Endgame console by clicking the Elastic Endgame icon in the event.module column or the link in the rule.reference column to gather more context about the detected behavior. +- Analyze the event.action and endgame.event_subtype_full fields to understand the specific behavior protection event that triggered the alert. +- Correlate the alert with other recent alerts or logs from the same host or user to identify any patterns or additional suspicious activities. +- Investigate the affected system for any signs of compromise or unauthorized changes, focusing on the timeframe around the alert. +- Check for any known vulnerabilities or misconfigurations in the affected system that could have been exploited by the adversary. +- Consult with the IT or security team to determine if any recent changes or updates could have triggered the alert as a false positive. + +### False positive analysis + +- Routine software updates or installations may trigger alerts due to behavior resembling adversarial actions. Users can create exceptions for known update processes to reduce false positives. +- Legitimate administrative tasks, such as system configuration changes, might be flagged. Identifying and excluding these tasks from monitoring can help minimize unnecessary alerts. +- Security tools or scripts that perform regular scans or maintenance can mimic adversary behavior. Whitelisting these tools in the detection rule settings can prevent them from being flagged. +- Automated backup processes that access multiple files or systems simultaneously may be misinterpreted as suspicious. Users should ensure these processes are recognized and excluded from triggering alerts. +- Custom applications with unique behaviors might be incorrectly identified as threats. Users should document and exclude these behaviors if they are verified as non-threatening. + +### Response and remediation + +- Isolate the affected system immediately to prevent further unauthorized actions or potential lateral movement by the adversary. +- Review the specific event.action and endgame.event_subtype_full fields to understand the nature of the detected behavior and identify any compromised accounts or processes. +- Terminate any unauthorized processes or sessions identified during the investigation to halt adversary activities. +- Apply security patches or updates to address any exploited vulnerabilities that may have been used by the adversary. +- Conduct a thorough scan of the affected system and network to identify and remove any malicious artifacts or backdoors left by the adversary. +- Restore affected systems from a known good backup if necessary, ensuring that the backup is free from compromise. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.""" diff --git a/rules/promotions/endgame_malware_detected.toml b/rules/promotions/endgame_malware_detected.toml index cbf07ce6b21..516eb518a45 100644 --- a/rules/promotions/endgame_malware_detected.toml +++ b/rules/promotions/endgame_malware_detected.toml @@ -2,7 +2,7 @@ creation_date = "2020/02/18" maturity = "production" promotion = true -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -36,4 +36,39 @@ type = "query" query = ''' event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:file_classification_event or endgame.event_subtype_full:file_classification_event) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Malware - Detected - Elastic Endgame + +Elastic Endgame is a security solution that provides endpoint protection by monitoring and analyzing system activities to detect malicious behavior. Adversaries may exploit this technology by attempting to bypass its detection capabilities or by executing malware that mimics legitimate processes. The detection rule identifies suspicious file classification events, flagging potential malware activities with a high-risk score, thus enabling swift investigation and response. + +### Possible investigation steps + +- Review the alert details in the Elastic Endgame console by clicking the Elastic Endgame icon in the event.module column or the link in the rule.reference column to gather more context about the detected malware. +- Examine the specific file classification event by checking the event.action or endgame.event_subtype_full fields to understand the nature of the suspicious file activity. +- Analyze the endpoint's recent activity logs to identify any unusual behavior or patterns that coincide with the time of the alert. +- Investigate the source and destination of the file involved in the alert to determine if it is part of a known legitimate process or if it has been flagged in previous incidents. +- Check for any additional alerts or related events from the same endpoint or user to assess if this is part of a broader attack or isolated incident. +- Consult threat intelligence sources to see if the file or behavior matches known malware signatures or tactics, techniques, and procedures (TTPs). + +### False positive analysis + +- Legitimate software updates or installations may trigger file classification events. Users can create exceptions for known update processes to prevent these from being flagged as malware. +- System maintenance tasks, such as disk cleanup or defragmentation, might mimic suspicious file activities. Exclude these routine tasks by identifying their specific processes and adding them to the exception list. +- Security tools or antivirus software performing scans can generate alerts. Identify these tools and configure the rule to ignore their activities to reduce false positives. +- Custom scripts or automation tools used within the organization may be misclassified. Review these scripts and whitelist them if they are verified as safe and necessary for business operations. +- Frequent alerts from specific directories known to store temporary or cache files can be excluded by specifying these directories in the rule settings. + +### Response and remediation + +- Isolate the affected endpoint immediately to prevent further spread of the detected malware across the network. +- Terminate any suspicious processes identified by Elastic Endgame that are associated with the file classification event. +- Quarantine the suspicious files flagged by the detection rule to prevent execution and further analysis. +- Conduct a thorough scan of the isolated endpoint using updated antivirus and anti-malware tools to identify and remove any additional threats. +- Restore the affected system from a known good backup if malware removal is not feasible or if system integrity is compromised. +- Review and update endpoint protection policies to ensure they are configured 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 additional systems are affected.""" diff --git a/rules/promotions/endgame_malware_prevented.toml b/rules/promotions/endgame_malware_prevented.toml index d00be854558..c2758e826b3 100644 --- a/rules/promotions/endgame_malware_prevented.toml +++ b/rules/promotions/endgame_malware_prevented.toml @@ -2,7 +2,7 @@ creation_date = "2020/02/18" maturity = "production" promotion = true -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -36,4 +36,40 @@ type = "query" query = ''' event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:file_classification_event or endgame.event_subtype_full:file_classification_event) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Malware - Prevented - Elastic Endgame + +Elastic Endgame is a security solution designed to prevent malware by analyzing and classifying files in real-time. Adversaries may attempt to bypass such defenses by disguising malicious files to evade detection. The detection rule identifies prevention events where Elastic Endgame has successfully blocked a file classified as malware, focusing on alerts generated by file classification activities. This helps security analysts quickly respond to and investigate potential threats. + +### Possible investigation steps + +- Review the alert details to confirm the event.kind is 'alert' and event.module is 'endgame', ensuring the alert is relevant to the Elastic Endgame prevention mechanism. +- Examine the endgame.metadata.type field to verify it is 'prevention', indicating that the alert pertains to a successfully blocked malware attempt. +- Investigate the event.action or endgame.event_subtype_full fields to understand the specific file classification event that triggered the alert. +- Gather additional context by checking the file path, hash, and any associated metadata to identify the potentially malicious file and its origin. +- Cross-reference the alert with other security logs and alerts to determine if there are related events or patterns that could indicate a broader attack campaign. +- Assess the risk score and severity to prioritize the investigation and response efforts, considering the high severity and risk score of 73. +- Utilize the Elastic Endgame interface or provided links for further information and context about the specific prevention event and any recommended remediation actions. + +### False positive analysis + +- Legitimate software updates or installations may trigger the rule if they involve file classification activities. To manage this, create exceptions for known and trusted software update processes. +- Security tools or system processes that perform file scanning or classification might be flagged. Identify these processes and add them to an exception list to prevent unnecessary alerts. +- Custom scripts or applications developed in-house that perform file operations similar to malware can be mistaken for threats. Review these scripts and whitelist them if they are verified as safe. +- Frequent alerts from specific directories known to contain non-malicious files, such as temporary or backup folders, can be excluded by specifying these paths in the rule exceptions. +- If certain file types are consistently misclassified as threats, consider adjusting the rule to exclude these file types after confirming they are not harmful. + +### Response and remediation + +- Isolate the affected system immediately to prevent the spread of malware to other parts of the network. Disconnect the system from the network and any shared drives. +- Verify the alert by cross-referencing the blocked file details with known malware signatures or threat intelligence sources to confirm the threat. +- Remove the malicious file from the system using a trusted antivirus or endpoint protection tool. Ensure that the file is quarantined or deleted to prevent re-execution. +- Conduct a thorough scan of the affected system and any connected devices to identify and remove any additional malicious files or remnants. +- Restore any affected files or systems from a clean backup, ensuring that the backup is free from malware before restoration. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems may be compromised. +- Review and update security policies and endpoint protection configurations to enhance detection and prevention capabilities against similar threats in the future.""" diff --git a/rules/promotions/endgame_ransomware_detected.toml b/rules/promotions/endgame_ransomware_detected.toml index 917f0ab088b..379a8492e7d 100644 --- a/rules/promotions/endgame_ransomware_detected.toml +++ b/rules/promotions/endgame_ransomware_detected.toml @@ -2,7 +2,7 @@ creation_date = "2020/02/18" maturity = "production" promotion = true -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -36,4 +36,38 @@ type = "query" query = ''' event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:ransomware_event or endgame.event_subtype_full:ransomware_event) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Ransomware - Detected - Elastic Endgame + +Elastic Endgame is a security solution designed to detect and respond to threats like ransomware by analyzing system events and behaviors. Adversaries exploit vulnerabilities to deploy ransomware, encrypting files and demanding payment. The detection rule identifies ransomware activity by monitoring specific alert types and event actions, flagging critical threats for immediate investigation. + +### Possible investigation steps + +- Review the alert details in Elastic Endgame by clicking the icon in the event.module column or the link in the rule.reference column to gather more context about the detected ransomware event. +- Analyze the event.kind:alert and event.module:endgame fields to confirm the alert's origin and ensure it aligns with known ransomware activity. +- Examine the event.action:ransomware_event and endgame.event_subtype_full:ransomware_event fields to identify the specific actions or behaviors that triggered the alert. +- Investigate the affected systems and endpoints to determine the scope of the ransomware impact, focusing on any encrypted files or unusual system behaviors. +- Check for any additional alerts or related events in the Elastic Endgame logs that might indicate lateral movement or further malicious activity associated with the ransomware. + +### False positive analysis + +- Routine backup operations can sometimes mimic ransomware behavior by accessing and modifying large numbers of files. Users should review backup schedules and processes to ensure they are not triggering alerts. +- Legitimate software updates or installations may be flagged as ransomware events due to their file modification activities. Users can create exceptions for trusted software update processes to prevent false positives. +- Automated file encryption tools used for legitimate purposes, such as data protection, might trigger ransomware alerts. Users should whitelist these tools if they are verified and necessary for business operations. +- Security testing or penetration testing activities that simulate ransomware attacks can be mistaken for real threats. Ensure that these activities are coordinated with the security team and excluded from detection rules during testing periods. +- Frequent alerts from specific non-critical systems or applications that are known to exhibit similar behaviors should be reviewed and, if deemed safe, added to an exception list to reduce noise. + +### Response and remediation + +- Isolate the affected systems immediately to prevent the spread of ransomware to other networked devices. Disconnect them from the network and any shared storage. +- Identify and terminate any malicious processes associated with the ransomware event using endpoint detection and response tools. +- Restore encrypted files from the most recent clean backup. Ensure backups are scanned for malware before restoration to avoid reinfection. +- Conduct a thorough forensic analysis to determine the initial point of entry and the scope of the compromise. This will help in understanding how the ransomware was deployed. +- Apply security patches to address any vulnerabilities exploited by the ransomware. Ensure all systems are updated to prevent similar attacks. +- Enhance monitoring and detection capabilities by configuring alerts for similar event patterns and behaviors identified in the query fields. +- Report the incident to relevant authorities and stakeholders as per organizational policy and legal requirements, ensuring compliance with any regulatory obligations.""" diff --git a/rules/promotions/endgame_ransomware_prevented.toml b/rules/promotions/endgame_ransomware_prevented.toml index d6e5e4b7667..fe30012c226 100644 --- a/rules/promotions/endgame_ransomware_prevented.toml +++ b/rules/promotions/endgame_ransomware_prevented.toml @@ -2,7 +2,7 @@ creation_date = "2020/02/18" maturity = "production" promotion = true -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -36,4 +36,39 @@ type = "query" query = ''' event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:ransomware_event or endgame.event_subtype_full:ransomware_event) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Ransomware - Prevented - Elastic Endgame + +Elastic Endgame is a security solution designed to prevent ransomware by monitoring and analyzing system events. Adversaries exploit vulnerabilities to deploy ransomware, encrypting files and demanding payment. The detection rule identifies ransomware activities by analyzing alerts and prevention events, focusing on specific actions and event types, thus enabling timely intervention and threat mitigation. + +### Possible investigation steps + +- Review the alert details in the Elastic Endgame console by clicking the Elastic Endgame icon in the event.module column or the link in the rule.reference column to gather more context about the specific prevention event. +- Examine the event.kind field to confirm that the alert is indeed an alert type and verify the event.module is set to endgame, ensuring the alert is generated by the Elastic Endgame module. +- Check the endgame.metadata.type field to ensure it is marked as prevention, indicating that the ransomware activity was successfully blocked. +- Investigate the event.action and endgame.event_subtype_full fields to identify the specific ransomware event that triggered the alert, which can provide insights into the type of ransomware activity that was attempted. +- Correlate the alert with other security events and logs from the same timeframe to identify any related activities or anomalies that might indicate a broader attack attempt or compromise. +- Assess the affected system(s) for any signs of compromise or residual malicious activity, ensuring that the ransomware prevention was comprehensive and no other threats remain. + +### False positive analysis + +- Routine software updates or installations may trigger alerts as they can mimic ransomware behavior. Users should review these events and create exceptions for trusted software update processes. +- Backup operations that involve large-scale file modifications or encryptions might be misidentified as ransomware activities. Exclude known backup software and processes from triggering alerts. +- Security testing tools or scripts designed to simulate ransomware for training or assessment purposes can cause false positives. Ensure these tools are whitelisted and their activities are documented. +- Automated file encryption services used for legitimate purposes, such as data protection, may be flagged. Identify and exclude these services from the rule to prevent unnecessary alerts. +- Frequent alerts from specific applications or processes that are known to be safe should be analyzed, and exceptions should be created to reduce noise and focus on genuine threats. + +### Response and remediation + +- Isolate the affected system immediately to prevent further spread of the ransomware. Disconnect it from the network and any shared drives. +- Use Elastic Endgame to identify and terminate any malicious processes associated with the ransomware event to halt encryption activities. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to remove any remaining malicious files or components. +- Restore encrypted files from the most recent clean backup to ensure data integrity and minimize data loss. +- Review and update endpoint protection settings and policies in Elastic Endgame to enhance detection and prevention capabilities against similar ransomware threats. +- Notify the IT security team and relevant stakeholders about the incident for awareness and further investigation into potential vulnerabilities exploited. +- Document the incident details, including the response actions taken, to improve future incident response strategies and facilitate any necessary reporting or compliance requirements.""" diff --git a/rules/promotions/execution_endgame_exploit_detected.toml b/rules/promotions/execution_endgame_exploit_detected.toml index 891c48a3e07..ceddf21428d 100644 --- a/rules/promotions/execution_endgame_exploit_detected.toml +++ b/rules/promotions/execution_endgame_exploit_detected.toml @@ -2,7 +2,7 @@ creation_date = "2020/02/18" maturity = "production" promotion = true -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -41,6 +41,40 @@ type = "query" query = ''' event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:exploit_event or endgame.event_subtype_full:exploit_event) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Exploit - Detected - Elastic Endgame + +Elastic Endgame is a security solution that monitors and detects exploit attempts within an environment. Adversaries exploit vulnerabilities to execute unauthorized code or escalate privileges. The detection rule identifies alerts from the Endgame module, focusing on exploit-related events. It leverages metadata and event actions to flag high-risk activities, aiding in swift threat detection and response. + +### Possible investigation steps + +- Review the alert details to confirm the presence of event.kind:alert and event.module:endgame, ensuring the alert is relevant to the Elastic Endgame detection. +- Examine the event.action and endgame.event_subtype_full fields to determine the specific exploit event type, which can provide insight into the nature of the exploit attempt. +- Investigate the endgame.metadata.type field to gather additional context about the detection, such as the source and target of the exploit attempt. +- Check the associated risk score and severity level to prioritize the investigation and response efforts, focusing on high-risk activities. +- Correlate the alert with other related events in the environment to identify potential patterns or additional indicators of compromise. +- Consult the MITRE ATT&CK framework for the Execution tactic (TA0002) to understand potential techniques that might have been used and to guide further investigation steps. + +### False positive analysis + +- Routine software updates or patches may trigger exploit detection alerts. Users can create exceptions for known update processes by identifying their unique metadata or event actions. +- Legitimate administrative tools that perform actions similar to exploits might be flagged. Users should whitelist these tools by specifying their event.module or event.action attributes. +- Automated scripts used for system maintenance could mimic exploit behavior. To prevent false positives, users can exclude these scripts by defining their specific endgame.event_subtype_full. +- Security testing activities, such as penetration tests, may generate alerts. Users can manage these by setting temporary exceptions during the testing period, based on the event.kind or event.module. + +### Response and remediation + +- Isolate the affected system immediately to prevent further exploitation or lateral movement within the network. +- Terminate any unauthorized processes identified as part of the exploit event to halt malicious activity. +- Apply relevant security patches or updates to the affected system to address the exploited vulnerability and prevent recurrence. +- Conduct a thorough forensic analysis of the affected system to identify any additional indicators of compromise or secondary payloads. +- Restore the system from a known good backup if necessary, ensuring that the backup is free from any malicious artifacts. +- Monitor the network for any signs of similar exploit attempts, using enhanced logging and alerting based on the identified threat indicators. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation.""" [[rule.threat]] diff --git a/rules/promotions/execution_endgame_exploit_prevented.toml b/rules/promotions/execution_endgame_exploit_prevented.toml index 8d924b7e725..e7c52fc16f1 100644 --- a/rules/promotions/execution_endgame_exploit_prevented.toml +++ b/rules/promotions/execution_endgame_exploit_prevented.toml @@ -2,7 +2,7 @@ creation_date = "2020/02/18" maturity = "production" promotion = true -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -41,6 +41,42 @@ type = "query" query = ''' event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:exploit_event or endgame.event_subtype_full:exploit_event) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Exploit - Prevented - Elastic Endgame + +Elastic Endgame is a security solution designed to prevent exploits by monitoring and analyzing system behaviors. Adversaries often exploit vulnerabilities to execute unauthorized code or escalate privileges. This detection rule identifies prevention events where an exploit attempt was blocked, focusing on alerts from the Endgame module. By analyzing specific event actions and metadata, it helps security analysts quickly identify and respond to potential threats, ensuring system integrity and security. + +### Possible investigation steps + +- Review the alert details to confirm the event.kind is 'alert' and event.module is 'endgame', ensuring the alert is relevant to the Elastic Endgame module. +- Examine the endgame.metadata.type field to verify it is marked as 'prevention', indicating that the exploit attempt was successfully blocked. +- Analyze the event.action and endgame.event_subtype_full fields to determine the specific type of exploit event that was attempted, such as 'exploit_event'. +- Investigate the source and destination IP addresses, user accounts, and hostnames involved in the alert to identify potential points of compromise or targets. +- Check for any related alerts or logs within the same timeframe to identify patterns or additional indicators of compromise that may suggest a broader attack campaign. +- Assess the risk score and severity level to prioritize the investigation and determine if immediate action is required to mitigate potential threats. +- Document findings and any actions taken in response to the alert to maintain a comprehensive record for future reference and analysis. + +### False positive analysis + +- Routine software updates or patches may trigger prevention alerts as they modify system files or configurations. Review the update schedule and correlate alerts with known maintenance windows to verify legitimacy. +- Legitimate administrative tools or scripts that perform actions similar to exploit techniques can be flagged. Identify these tools and create exceptions for their known behaviors to reduce noise. +- Security testing or vulnerability scanning activities might mimic exploit attempts. Coordinate with IT and security teams to whitelist these activities during scheduled assessments. +- Custom applications with unique behaviors may be misidentified as threats. Work with development teams to understand these behaviors and adjust detection rules or create exceptions accordingly. +- Frequent alerts from specific systems or users could indicate a misconfiguration. Investigate these patterns and adjust system settings or user permissions to align with security policies. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary. +- Verify the integrity of critical system files and applications on the affected system to ensure no unauthorized changes have been made. +- Apply the latest security patches and updates to the affected system to address any known vulnerabilities that may have been targeted. +- Conduct a thorough review of user accounts and privileges on the affected system to identify and revoke any unauthorized access or privilege escalation. +- Restore the affected system from a known good backup if any unauthorized changes or exploit attempts have compromised system integrity. +- Monitor the network and system logs for any signs of similar exploit attempts or related suspicious activities to ensure no further threats are present. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be at risk.""" [[rule.threat]] diff --git a/rules/promotions/external_alerts.toml b/rules/promotions/external_alerts.toml index 1eb2d1a0d7d..87fd3f60609 100644 --- a/rules/promotions/external_alerts.toml +++ b/rules/promotions/external_alerts.toml @@ -2,7 +2,7 @@ creation_date = "2020/07/08" maturity = "production" promotion = true -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -43,6 +43,41 @@ type = "query" query = ''' event.kind:alert and not event.module:(endgame or endpoint or cloud_defend) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 External Alerts + +External alerts are crucial for identifying potential threats across diverse environments like Windows, macOS, and Linux. These alerts are generated from various sources, excluding specific modules like endpoint or cloud defend, to focus on broader threat landscapes. Adversaries may exploit vulnerabilities in these systems to execute unauthorized actions. The 'External Alerts' detection rule filters and highlights such activities by focusing on alert events, enabling analysts to swiftly investigate and mitigate risks. + +### Possible investigation steps + +- Review the alert details to identify the specific event.kind:alert that triggered the detection, ensuring it is not associated with the excluded modules (endgame, endpoint, or cloud_defend). +- Examine the source and context of the alert by checking the associated tags, such as 'OS: Windows', 'OS: macOS', or 'OS: Linux', to understand the environment affected. +- Gather additional context by correlating the alert with other logs or events from the same time frame or system to identify any related suspicious activities. +- Assess the risk score and severity level to prioritize the investigation and determine the potential impact on the organization. +- Investigate the origin of the alert by identifying the source IP, user account, or process involved, and check for any known vulnerabilities or exploits associated with them. +- Consult threat intelligence sources to determine if the alert corresponds to any known threat actors or campaigns targeting similar environments. + +### False positive analysis + +- Alerts from benign third-party applications may trigger false positives. Review and identify these applications, then create exceptions to exclude them from future alerts. +- Routine system updates or patches can generate alerts. Monitor update schedules and create exceptions for known update activities to reduce noise. +- Network monitoring tools might produce alerts due to their scanning activities. Verify these tools and exclude their activities if deemed non-threatening. +- Alerts from internal security testing or penetration testing exercises can be mistaken for threats. Coordinate with security teams to whitelist these activities during scheduled tests. +- Certain administrative scripts or automation tasks may trigger alerts. Evaluate these scripts and exclude them if they are part of regular operations and pose no risk. + +### Response and remediation + +- Isolate affected systems immediately to prevent further unauthorized actions and contain the threat. +- Conduct a thorough review of the alert details to identify any specific vulnerabilities or exploits used by the adversary. +- Apply relevant patches or updates to the affected systems to remediate any identified vulnerabilities. +- Restore systems from a known good backup if unauthorized changes or actions have been detected. +- Monitor network traffic and system logs closely for any signs of further suspicious activity or attempts to exploit similar vulnerabilities. +- Escalate the incident to the appropriate security team or management if the threat appears to be part of a larger attack campaign or if additional resources are needed for remediation. +- Enhance detection capabilities by updating security tools and configurations to better identify similar threats in the future.""" [[rule.risk_score_mapping]] diff --git a/rules/promotions/privilege_escalation_endgame_cred_manipulation_detected.toml b/rules/promotions/privilege_escalation_endgame_cred_manipulation_detected.toml index 8155bb2f92e..85c5e0d063b 100644 --- a/rules/promotions/privilege_escalation_endgame_cred_manipulation_detected.toml +++ b/rules/promotions/privilege_escalation_endgame_cred_manipulation_detected.toml @@ -2,7 +2,7 @@ creation_date = "2020/02/18" maturity = "production" promotion = true -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -36,6 +36,41 @@ type = "query" query = ''' event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:token_manipulation_event or endgame.event_subtype_full:token_manipulation_event) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Credential Manipulation - Detected - Elastic Endgame + +Elastic Endgame is a security solution that monitors and detects suspicious activities, such as credential manipulation, which adversaries exploit to escalate privileges by altering access tokens. This detection rule identifies such threats by analyzing alerts for token manipulation events, leveraging its high-risk score and severity to prioritize investigation. The rule aligns with MITRE ATT&CK's framework, focusing on privilege escalation tactics. + +### Possible investigation steps + +- Review the alert details to confirm the presence of event.kind:alert and event.module:endgame, ensuring the alert is relevant to Elastic Endgame's detection capabilities. +- Examine the event.action and endgame.event_subtype_full fields for token_manipulation_event to understand the specific type of credential manipulation detected. +- Check the associated user account and system involved in the alert to determine if the activity aligns with expected behavior or if it indicates potential unauthorized access. +- Investigate the timeline of events leading up to and following the token manipulation event to identify any additional suspicious activities or patterns. +- Correlate the alert with other security events or logs to assess if this incident is part of a broader attack or isolated. +- Evaluate the risk score and severity to prioritize the response and determine if immediate action is required to mitigate potential threats. + +### False positive analysis + +- Routine administrative tasks involving token manipulation can trigger alerts. Review the context of the event to determine if it aligns with expected administrative behavior. +- Automated scripts or software updates that require token changes might be flagged. Identify and whitelist these processes if they are verified as safe and necessary for operations. +- Security tools or monitoring solutions that interact with access tokens for legitimate purposes may cause false positives. Ensure these tools are recognized and excluded from triggering alerts. +- User behavior analytics might misinterpret legitimate user actions as suspicious. Regularly update user profiles and behavior baselines to minimize these occurrences. +- Scheduled maintenance activities that involve access token modifications should be documented and excluded from detection rules during their execution time. + +### Response and remediation + +- Isolate the affected system immediately to prevent further unauthorized access or lateral movement within the network. +- Revoke and reset any compromised credentials or access tokens identified in the alert to prevent further misuse. +- Conduct a thorough review of recent access logs and token usage to identify any unauthorized access or actions taken by the adversary. +- Apply security patches and updates to the affected system and any related systems to close vulnerabilities that may have been exploited. +- Implement enhanced monitoring on the affected system and related accounts to detect any further suspicious activity or attempts at credential manipulation. +- Notify the security team and relevant stakeholders about the incident, providing details of the threat and actions taken, and escalate to higher management if the threat level increases. +- Review and update access control policies and token management practices to prevent similar incidents in the future, ensuring that least privilege principles are enforced.""" [[rule.threat]] diff --git a/rules/promotions/privilege_escalation_endgame_cred_manipulation_prevented.toml b/rules/promotions/privilege_escalation_endgame_cred_manipulation_prevented.toml index 3d28513a582..0473c9c728b 100644 --- a/rules/promotions/privilege_escalation_endgame_cred_manipulation_prevented.toml +++ b/rules/promotions/privilege_escalation_endgame_cred_manipulation_prevented.toml @@ -2,7 +2,7 @@ creation_date = "2020/02/18" maturity = "production" promotion = true -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -36,6 +36,41 @@ type = "query" query = ''' event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:token_manipulation_event or endgame.event_subtype_full:token_manipulation_event) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Credential Manipulation - Prevented - Elastic Endgame + +Elastic Endgame is a security solution that prevents unauthorized credential manipulation, a tactic often used by adversaries to escalate privileges by altering access tokens. Attackers exploit this to gain elevated access within a system. The detection rule identifies such attempts by monitoring alerts for token manipulation events, leveraging Elastic Endgame's prevention capabilities to thwart these threats effectively. + +### Possible investigation steps + +- Review the alert details to confirm the presence of event.kind:alert and event.module:endgame, ensuring the alert is related to Elastic Endgame's prevention capabilities. +- Examine the event.action and endgame.event_subtype_full fields to identify the specific type of token manipulation event that was prevented. +- Investigate the source and destination of the alert by analyzing associated IP addresses, user accounts, and hostnames to determine if the attempt was internal or external. +- Check for any related alerts or logs around the same timeframe to identify potential patterns or coordinated attempts at credential manipulation. +- Assess the impacted system's current security posture and review recent changes or anomalies in user behavior that might have led to the attempted manipulation. +- Consult the MITRE ATT&CK framework for additional context on Access Token Manipulation (T1134) to understand potential adversary techniques and improve defensive measures. + +### False positive analysis + +- Routine administrative tasks involving legitimate token manipulation can trigger alerts. Review the context of the event to determine if it aligns with expected administrative activities. +- Automated scripts or software updates that modify access tokens as part of their normal operation may cause false positives. Identify these processes and consider adding them to an exception list if they are verified as non-threatening. +- Security tools or monitoring solutions that interact with access tokens for legitimate purposes might be flagged. Validate these tools and exclude them from the rule if they are confirmed to be safe. +- User behavior that involves frequent token changes, such as developers testing applications, can lead to false positives. Monitor these activities and create exceptions for known users or groups performing these tasks regularly. +- Ensure that the rule is not overly broad by refining the query to focus on specific actions or contexts that are more indicative of malicious behavior, reducing the likelihood of false positives. + +### Response and remediation + +- Immediately isolate the affected system to prevent further unauthorized access or lateral movement within the network. +- Revoke and reset any potentially compromised credentials associated with the affected system to mitigate unauthorized access. +- Conduct a thorough review of access logs and token usage to identify any unauthorized access or privilege escalation attempts. +- Restore the affected system from a known good backup to ensure the integrity of the system and its credentials. +- Implement additional monitoring on the affected system and related accounts to detect any further suspicious activity. +- Escalate the incident to the security operations team for a detailed investigation and to assess the potential impact on other systems. +- Review and update access control policies to ensure that only necessary permissions are granted, reducing the risk of privilege escalation.""" [[rule.threat]] diff --git a/rules/promotions/privilege_escalation_endgame_permission_theft_detected.toml b/rules/promotions/privilege_escalation_endgame_permission_theft_detected.toml index 2e8870a4bed..3313a4fe13d 100644 --- a/rules/promotions/privilege_escalation_endgame_permission_theft_detected.toml +++ b/rules/promotions/privilege_escalation_endgame_permission_theft_detected.toml @@ -2,7 +2,7 @@ creation_date = "2020/02/18" maturity = "production" promotion = true -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -36,6 +36,41 @@ type = "query" query = ''' event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:token_protection_event or endgame.event_subtype_full:token_protection_event) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Permission Theft - Detected - Elastic Endgame + +Elastic Endgame is a security solution that monitors and detects unauthorized access attempts, focusing on privilege escalation tactics like access token manipulation. Adversaries exploit this by stealing or forging tokens to gain elevated permissions. The detection rule identifies suspicious token-related events, flagging high-risk activities indicative of permission theft, thus enabling timely threat response. + +### Possible investigation steps + +- Review the alert details to confirm the presence of event.kind:alert and event.module:endgame, ensuring the alert is related to Elastic Endgame's detection capabilities. +- Examine the event.action and endgame.event_subtype_full fields for token_protection_event to identify the specific token manipulation activity that triggered the alert. +- Investigate the source and destination user accounts involved in the alert to determine if there are any unauthorized access attempts or privilege escalations. +- Check for any recent changes or anomalies in the permissions or roles associated with the affected accounts to assess potential impact. +- Correlate the alert with other security events or logs to identify any patterns or additional indicators of compromise that may suggest a broader attack campaign. +- Consult the MITRE ATT&CK framework for additional context on the Access Token Manipulation technique (T1134) to understand potential adversary behaviors and mitigation strategies. + +### False positive analysis + +- Routine administrative tasks involving token management can trigger alerts. Review and document these tasks to create exceptions for known safe activities. +- Automated scripts or services that frequently access tokens for legitimate purposes may be flagged. Identify these scripts and whitelist them to prevent unnecessary alerts. +- Software updates or installations that require elevated permissions might be detected as suspicious. Monitor these events and adjust detection rules to accommodate regular update schedules. +- Internal security tools that perform token manipulation for testing or monitoring purposes can cause false positives. Ensure these tools are recognized and excluded from detection rules. +- User behavior analytics might misinterpret legitimate user actions as threats. Regularly update user profiles and behavior baselines to minimize false alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Revoke any compromised or suspicious access tokens identified in the alert to prevent further misuse of elevated permissions. +- Conduct a thorough review of recent account activities associated with the compromised tokens to identify any unauthorized actions or changes. +- Reset passwords and enforce multi-factor authentication for accounts involved in the incident to enhance security and prevent future unauthorized access. +- Restore any altered or deleted data from backups, ensuring that the restored data is free from any malicious modifications. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or accounts have been affected. +- Implement enhanced monitoring and logging for token-related activities to detect and respond to similar threats more effectively in the future.""" [[rule.threat]] diff --git a/rules/promotions/privilege_escalation_endgame_permission_theft_prevented.toml b/rules/promotions/privilege_escalation_endgame_permission_theft_prevented.toml index 24e914d7863..8348b3462d7 100644 --- a/rules/promotions/privilege_escalation_endgame_permission_theft_prevented.toml +++ b/rules/promotions/privilege_escalation_endgame_permission_theft_prevented.toml @@ -2,7 +2,7 @@ creation_date = "2020/02/18" maturity = "production" promotion = true -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -36,6 +36,41 @@ type = "query" query = ''' event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:token_protection_event or endgame.event_subtype_full:token_protection_event) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Permission Theft - Prevented - Elastic Endgame + +Elastic Endgame is a security solution that prevents unauthorized access by monitoring and blocking attempts to manipulate access tokens, a common privilege escalation tactic. Adversaries exploit token manipulation to gain elevated permissions without detection. The detection rule identifies and alerts on prevention events related to token protection, leveraging specific event types and actions to flag suspicious activities, thus mitigating potential threats. + +### Possible investigation steps + +- Review the alert details to confirm the event.kind is 'alert' and event.module is 'endgame', ensuring the alert is relevant to Elastic Endgame's token protection. +- Examine the event.action and endgame.event_subtype_full fields to determine if the alert was triggered by a 'token_protection_event', which indicates an attempt to manipulate access tokens. +- Investigate the source and destination of the alert by analyzing associated IP addresses, user accounts, and hostnames to identify potential unauthorized access attempts. +- Check the endgame.metadata.type field to verify that the event type is 'prevention', confirming that the attempted permission theft was successfully blocked. +- Correlate the alert with other recent alerts or logs to identify patterns or repeated attempts that might indicate a persistent threat actor. +- Assess the risk score and severity level to prioritize the investigation and determine if immediate action is required to mitigate potential threats. + +### False positive analysis + +- Routine administrative tasks involving legitimate token manipulation may trigger alerts. Review the context of the event to determine if it aligns with expected administrative activities. +- Scheduled scripts or automated processes that require token access might be flagged. Identify these processes and consider creating exceptions for known, safe operations. +- Software updates or installations that involve token changes can generate alerts. Verify the source and purpose of the update to ensure it is authorized, and exclude these events if they are part of regular maintenance. +- Security tools or monitoring solutions that interact with tokens for legitimate purposes may cause false positives. Cross-reference with known tool activities and whitelist these actions if they are verified as non-threatening. +- User behavior analytics might misinterpret legitimate user actions as suspicious. Analyze user activity patterns and adjust the detection thresholds or rules to better align with normal user behavior. + +### Response and remediation + +- Immediately isolate the affected system to prevent further unauthorized access or privilege escalation attempts. +- Revoke any potentially compromised access tokens and force re-authentication for affected accounts to ensure that only legitimate users regain access. +- Conduct a thorough review of recent access logs and token usage to identify any unauthorized access or actions taken by the adversary. +- Apply patches or updates to the affected systems and applications to address any vulnerabilities that may have been exploited for token manipulation. +- Implement enhanced monitoring on the affected systems to detect any further attempts at access token manipulation or privilege escalation. +- Notify the security team and relevant stakeholders about the incident, providing details of the threat and actions taken, and escalate to higher management if the threat level increases. +- Review and update access control policies and token management practices to prevent similar incidents in the future, ensuring that only necessary permissions are granted and regularly audited.""" [[rule.threat]] diff --git a/rules/promotions/privilege_escalation_endgame_process_injection_detected.toml b/rules/promotions/privilege_escalation_endgame_process_injection_detected.toml index 1eea20d6f70..e63e54f280a 100644 --- a/rules/promotions/privilege_escalation_endgame_process_injection_detected.toml +++ b/rules/promotions/privilege_escalation_endgame_process_injection_detected.toml @@ -2,7 +2,7 @@ creation_date = "2020/02/18" maturity = "production" promotion = true -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -36,6 +36,42 @@ type = "query" query = ''' event.kind:alert and event.module:endgame and endgame.metadata.type:detection and (event.action:kernel_shellcode_event or endgame.event_subtype_full:kernel_shellcode_event) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Process Injection - Detected - Elastic Endgame + +Elastic Endgame is a security solution that monitors and detects suspicious activities like process injection, a technique often used by adversaries to execute malicious code within the address space of another process, thereby evading detection. This detection rule identifies such threats by analyzing alerts and specific event actions related to kernel shellcode, indicating potential privilege escalation attempts. By leveraging MITRE ATT&CK frameworks, it effectively flags high-risk activities, aiding analysts in mitigating threats. + +### Possible investigation steps + +- Review the alert details in the Elastic Endgame console by clicking the Elastic Endgame icon in the event.module column or the link in the rule.reference column to gather more context about the detected process injection. +- Examine the specific event.action and endgame.event_subtype_full fields to confirm the presence of kernel_shellcode_event, which indicates potential malicious activity. +- Analyze the process tree and parent-child relationships of the affected process to identify any unusual or unauthorized processes that may have initiated the injection. +- Check for any recent privilege escalation attempts or suspicious activities associated with the affected process by correlating with other alerts or logs in the system. +- Investigate the source and destination IP addresses, if available, to determine if there is any external communication that could suggest a command and control connection. +- Assess the risk and impact of the detected activity by considering the risk score and severity level, and prioritize response actions accordingly. +- If necessary, isolate the affected system to prevent further malicious activity and begin remediation efforts based on the findings. + +### False positive analysis + +- Legitimate software updates or patches may trigger process injection alerts. Users can create exceptions for known update processes by identifying their unique process names or hashes. +- Security tools or monitoring software that use process injection for legitimate purposes might be flagged. Users should whitelist these tools by specifying their process identifiers or paths. +- Custom scripts or automation tasks that interact with system processes could be misidentified as threats. Users can exclude these scripts by defining their execution context or command-line arguments. +- Debugging or development activities involving process manipulation might cause false positives. Users should consider excluding these activities during known development periods or within specific environments. +- Virtualization or sandboxing solutions that mimic process injection techniques for isolation purposes may be detected. Users can create exceptions for these solutions by recognizing their specific signatures or behaviors. + +### Response and remediation + +- Isolate the affected system immediately to prevent further spread of the malicious code. Disconnect it from the network and any shared resources. +- Terminate the malicious process identified by the alert to stop the execution of injected code. Use process management tools to safely end the process. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional threats or remnants of the attack. +- Review and analyze system logs and the specific event details from the alert to understand the scope of the intrusion and identify any other potentially compromised systems. +- Apply security patches and updates to the operating system and all software applications on the affected system to close any vulnerabilities exploited by the attacker. +- Restore the system from a known good backup taken before the incident occurred, ensuring that the backup is free from any malicious code. +- Report the incident to the appropriate internal security team or external authorities if required, providing them with detailed information about the attack and the steps taken for remediation.""" [[rule.threat]] diff --git a/rules/promotions/privilege_escalation_endgame_process_injection_prevented.toml b/rules/promotions/privilege_escalation_endgame_process_injection_prevented.toml index 8b96514519b..e2a0b0b86ca 100644 --- a/rules/promotions/privilege_escalation_endgame_process_injection_prevented.toml +++ b/rules/promotions/privilege_escalation_endgame_process_injection_prevented.toml @@ -2,7 +2,7 @@ creation_date = "2020/02/18" maturity = "production" promotion = true -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -36,6 +36,41 @@ type = "query" query = ''' event.kind:alert and event.module:endgame and endgame.metadata.type:prevention and (event.action:kernel_shellcode_event or endgame.event_subtype_full:kernel_shellcode_event) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Process Injection - Prevented - Elastic Endgame + +Elastic Endgame is a security solution that prevents malicious activities like process injection, a technique often used by adversaries to execute code within the address space of another process, enabling privilege escalation. This detection rule identifies attempts by monitoring alerts for specific kernel shellcode events, indicating potential injection attempts, and helps mitigate threats by leveraging prevention capabilities. + +### Possible investigation steps + +- Review the alert details to confirm the presence of event.kind:alert and event.module:endgame, ensuring the alert is related to Elastic Endgame's prevention capabilities. +- Examine the event.action and endgame.event_subtype_full fields for kernel_shellcode_event to identify the specific type of process injection attempt. +- Investigate the source process and target process involved in the injection attempt to understand the context and potential impact on the system. +- Check for any associated alerts or logs around the same timeframe to identify if this is part of a larger attack pattern or isolated incident. +- Assess the risk score and severity to prioritize the investigation and determine if immediate action is required to mitigate potential threats. +- Consult the MITRE ATT&CK framework for additional context on the T1055 Process Injection technique to understand common methods and potential mitigations. + +### False positive analysis + +- Legitimate software updates or installations may trigger kernel shellcode events. Users can create exceptions for known update processes by identifying their unique process identifiers or paths. +- Security tools or monitoring software that perform deep system scans might mimic process injection behavior. Exclude these tools by specifying their executable names or hashes in the exception list. +- Custom scripts or automation tools that interact with system processes could be flagged. Review these scripts and whitelist them if they are verified as safe and necessary for operations. +- Development environments or debugging tools that inject code for testing purposes may cause alerts. Establish exceptions for these environments by defining rules based on the development tools' signatures or process names. +- Virtualization software that uses process injection techniques for managing virtual machines can be mistakenly identified. Add these applications to the exclusion list by recognizing their specific process attributes. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified by the alert, particularly those associated with the kernel shellcode event, to halt ongoing malicious actions. +- Conduct a thorough analysis of the affected system to identify any additional indicators of compromise or secondary payloads that may have been deployed. +- Restore the affected system from a known good backup to ensure any injected code or malicious modifications are removed. +- Apply security patches and updates to the operating system and all installed software to close any vulnerabilities that may have been exploited. +- Monitor the network and systems for any signs of similar process injection attempts, using enhanced logging and alerting based on the identified threat indicators. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/threat_intel/threat_intel_indicator_match_address.toml b/rules/threat_intel/threat_intel_indicator_match_address.toml index 6026f6f265d..b371aa40afd 100644 --- a/rules/threat_intel/threat_intel_indicator_match_address.toml +++ b/rules/threat_intel/threat_intel_indicator_match_address.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2023/05/22" maturity = "production" -updated_date = "2024/06/10" +updated_date = "2025/01/10" [transform] [[transform.osquery]] @@ -41,7 +41,7 @@ interval = "1h" language = "kuery" license = "Elastic License v2" name = "Threat Intel IP Address Indicator Match" -note = """## Triage and Analysis +note = """## Triage and analysis ### Investigating Threat Intel IP Address Indicator Match diff --git a/rules/threat_intel/threat_intel_indicator_match_hash.toml b/rules/threat_intel/threat_intel_indicator_match_hash.toml index 236fb01db80..cb02712e3b2 100644 --- a/rules/threat_intel/threat_intel_indicator_match_hash.toml +++ b/rules/threat_intel/threat_intel_indicator_match_hash.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2023/05/22" maturity = "production" -updated_date = "2024/06/10" +updated_date = "2025/01/10" [transform] [[transform.osquery]] @@ -41,7 +41,7 @@ interval = "1h" language = "kuery" license = "Elastic License v2" name = "Threat Intel Hash Indicator Match" -note = """## Triage and Analysis +note = """## Triage and analysis ### Investigating Threat Intel Hash Indicator Match diff --git a/rules/threat_intel/threat_intel_indicator_match_registry.toml b/rules/threat_intel/threat_intel_indicator_match_registry.toml index 5612c34e435..6406191a8fb 100644 --- a/rules/threat_intel/threat_intel_indicator_match_registry.toml +++ b/rules/threat_intel/threat_intel_indicator_match_registry.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2023/05/22" maturity = "production" -updated_date = "2024/06/10" +updated_date = "2025/01/10" [transform] [[transform.osquery]] @@ -41,7 +41,7 @@ interval = "1h" language = "kuery" license = "Elastic License v2" name = "Threat Intel Windows Registry Indicator Match" -note = """## Triage and Analysis +note = """## Triage and analysis ### Investigating Threat Intel Windows Registry Indicator Match diff --git a/rules/threat_intel/threat_intel_indicator_match_url.toml b/rules/threat_intel/threat_intel_indicator_match_url.toml index 1f829b8c28c..7a16b72ecf2 100644 --- a/rules/threat_intel/threat_intel_indicator_match_url.toml +++ b/rules/threat_intel/threat_intel_indicator_match_url.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2023/05/22" maturity = "production" -updated_date = "2024/06/10" +updated_date = "2025/01/10" [transform] [[transform.osquery]] @@ -41,7 +41,7 @@ interval = "1h" language = "kuery" license = "Elastic License v2" name = "Threat Intel URL Indicator Match" -note = """## Triage and Analysis +note = """## Triage and analysis ### Investigating Threat Intel URL Indicator Match diff --git a/rules/threat_intel/threat_intel_rapid7_threat_command.toml b/rules/threat_intel/threat_intel_rapid7_threat_command.toml index 28bd096da4b..bab9e900435 100644 --- a/rules/threat_intel/threat_intel_rapid7_threat_command.toml +++ b/rules/threat_intel/threat_intel_rapid7_threat_command.toml @@ -4,7 +4,7 @@ integration = ["ti_rapid7_threat_command"] maturity = "production" min_stack_comments = "Breaking change at 8.13.0 for Rapid7 Threat Command Integration" min_stack_version = "8.13.0" -updated_date = "2024/08/06" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -19,7 +19,7 @@ language = "kuery" license = "Elastic License v2" max_signals = 10000 name = "Rapid7 Threat Command CVEs Correlation" -note = """## Triage and Analysis +note = """## Triage and analysis ### Investigating Rapid7 Threat Command CVEs Correlation diff --git a/rules/windows/collection_email_outlook_mailbox_via_com.toml b/rules/windows/collection_email_outlook_mailbox_via_com.toml index feb34e149a7..4d304d8e496 100644 --- a/rules/windows/collection_email_outlook_mailbox_via_com.toml +++ b/rules/windows/collection_email_outlook_mailbox_via_com.toml @@ -2,7 +2,7 @@ creation_date = "2023/01/11" integration = ["endpoint"] maturity = "production" -updated_date = "2024/06/20" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -47,6 +47,41 @@ sequence with maxspan=1m [process where host.os.type == "windows" and event.action == "start" and process.name : "OUTLOOK.EXE" and process.Ext.effective_parent.name != null] by process.Ext.effective_parent.entity_id ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Inter-Process Communication via Outlook + +Outlook's integration with the Component Object Model (COM) allows processes to automate tasks like sending emails. Adversaries exploit this by using unusual processes to interact with Outlook, potentially to exfiltrate data or send unauthorized emails. The detection rule identifies such anomalies by monitoring for unexpected processes initiating communication with Outlook, especially those lacking trusted signatures or recently modified, indicating potential malicious activity. + +### Possible investigation steps + +- Review the process entity ID to identify the specific process that initiated communication with Outlook and determine if it is one of the unusual processes listed, such as rundll32.exe, mshta.exe, or powershell.exe. +- Check the code signature status of the initiating process. If the process is unsigned or has an untrusted signature, investigate the source and legitimacy of the executable. +- Analyze the relative file creation and modification times of the initiating process. If the process was created or modified recently (within 500 seconds), it may indicate a newly introduced or altered executable, warranting further scrutiny. +- Investigate the effective parent process of OUTLOOK.EXE to understand the context of how Outlook was launched. Determine if the parent process is expected or if it is an unusual or suspicious process. +- Correlate the alert with any recent user activity or changes on the host to identify potential user actions or system changes that could explain the process behavior. +- Examine any network activity associated with the initiating process to identify potential data exfiltration or unauthorized email sending attempts. +- Review any additional alerts or logs related to the host or user account to identify patterns or additional indicators of compromise. + +### False positive analysis + +- Legitimate administrative scripts or tools may trigger the rule if they use processes like PowerShell or cmd.exe to automate tasks involving Outlook. To manage this, identify and whitelist these scripts or tools by their specific file paths or hashes. +- Software updates or installations might cause processes to appear as recently modified, leading to false positives. Regularly update the list of trusted software and exclude these known update processes from triggering alerts. +- Custom in-house applications that interact with Outlook for business purposes may be flagged. Ensure these applications are signed with a trusted certificate or add them to an exception list based on their unique identifiers. +- Security tools or monitoring software that perform regular checks on Outlook might be misidentified. Verify these tools and exclude them by their process names or signatures to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified in the alert, particularly those interacting with Outlook, such as rundll32.exe, mshta.exe, or powershell.exe. +- Conduct a thorough review of the email account associated with the affected Outlook process to identify any unauthorized access or email activity. Reset the account credentials if necessary. +- Analyze the process code signatures and file modification times to determine if any legitimate applications have been compromised. Reinstall or update these applications as needed. +- 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 on the affected system and similar endpoints to detect any recurrence of the suspicious activity. +- Review and update endpoint protection policies to ensure that similar threats are detected and blocked in the future, leveraging the MITRE ATT&CK framework for guidance on email collection techniques.""" [[rule.threat]] diff --git a/rules/windows/collection_posh_webcam_video_capture.toml b/rules/windows/collection_posh_webcam_video_capture.toml index a0006542832..cd4c2eed179 100644 --- a/rules/windows/collection_posh_webcam_video_capture.toml +++ b/rules/windows/collection_posh_webcam_video_capture.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/18" integration = ["windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -67,6 +67,40 @@ event.category:process and host.os.type:windows and ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 PowerShell Script with Webcam Video Capture Capabilities + +PowerShell, a powerful scripting language in Windows, can interface with system components like webcams for legitimate tasks such as video conferencing. However, adversaries exploit this by crafting scripts to covertly record video, infringing on privacy. The detection rule identifies suspicious script patterns and API calls linked to webcam access, flagging potential misuse for further investigation. + +### Possible investigation steps + +- Review the PowerShell script block text associated with the alert to identify any suspicious patterns or API calls, such as "NewFrameEventHandler" or "VideoCaptureDevice". +- Check the process execution details, including the parent process, to determine how the PowerShell script was initiated and if it was part of a legitimate application or task. +- Investigate the user account under which the PowerShell script was executed to assess if the account has a history of suspicious activity or if it has been compromised. +- Examine the host's recent activity logs for any other unusual behavior or alerts that might correlate with the webcam access attempt, such as unauthorized access attempts or data exfiltration. +- Verify if the host has any legitimate applications that might use webcam access, and cross-reference with the script's behavior to rule out false positives. + +### False positive analysis + +- Legitimate video conferencing applications may trigger the detection rule due to their use of similar API calls and script patterns. Users can create exceptions for known and trusted applications by whitelisting their process names or script signatures. +- Security testing tools that simulate webcam access for vulnerability assessments might be flagged. To handle this, users should exclude these tools from monitoring during scheduled testing periods. +- System diagnostics or maintenance scripts that access webcam components for hardware checks can be mistaken for malicious activity. Users should document and exclude these scripts if they are part of routine system operations. +- Educational or training software that uses webcam access for interactive sessions may be incorrectly identified. Users can mitigate this by adding these applications to an allowlist after verifying their legitimacy. +- Custom scripts developed in-house for specific business needs that involve webcam access should be reviewed and, if deemed safe, excluded from the detection rule to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious PowerShell processes identified by the detection rule to stop ongoing webcam recording activities. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious scripts or software. +- Review and revoke any unauthorized access permissions or credentials that may have been compromised during the incident. +- Restore the system from a known good backup if any critical system files or configurations have been altered by the malicious script. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for PowerShell activities across the network to detect and respond to similar threats more effectively in the future.""" [[rule.threat]] diff --git a/rules/windows/command_and_control_encrypted_channel_freesslcert.toml b/rules/windows/command_and_control_encrypted_channel_freesslcert.toml index 915c09f4456..213e3703679 100644 --- a/rules/windows/command_and_control_encrypted_channel_freesslcert.toml +++ b/rules/windows/command_and_control_encrypted_channel_freesslcert.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/04" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -55,6 +55,40 @@ network where host.os.type == "windows" and network.protocol == "dns" and /* Insert noisy false positives here */ not process.name : ("svchost.exe", "MicrosoftEdge*.exe", "msedge.exe") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Connection to Commonly Abused Free SSL Certificate Providers + +Free SSL certificates, like those from Let's Encrypt, enable secure web traffic encryption. Adversaries exploit these to mask malicious command and control (C2) communications. The detection rule identifies unusual Windows processes accessing domains with such certificates, excluding common false positives, to flag potential misuse of encrypted channels for C2 activities. + +### Possible investigation steps + +- Review the process executable path to confirm if it is a native Windows process and assess the legitimacy of its network activity. Focus on paths like "C:\\Windows\\System32\\*.exe" and "C:\\Windows\\SysWOW64\\*.exe". +- Investigate the specific domain accessed by the process, such as those ending in "*.letsencrypt.org" or "*.sslforfree.com", to determine if it is associated with known malicious activity or if it is a legitimate service. +- Check the process name against the list of excluded false positives, ensuring it is not "svchost.exe", "MicrosoftEdge*.exe", or "msedge.exe", which are common and typically benign. +- Analyze the network traffic associated with the process to identify any unusual patterns or anomalies that could indicate command and control activity. +- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related suspicious activities. + +### False positive analysis + +- Windows system processes like svchost.exe and MicrosoftEdge.exe are common false positives due to their legitimate network activities. These can be excluded from the detection rule to reduce noise. +- Regularly update the list of excluded processes to include any new system processes that are verified to have legitimate reasons for accessing domains with free SSL certificates. +- Monitor and analyze network traffic patterns to identify any additional processes that consistently generate false positives, and consider adding them to the exclusion list if they are deemed non-threatening. +- Use process whitelisting to allow known safe applications that frequently access these domains, ensuring they do not trigger alerts unnecessarily. +- Implement a review process to periodically reassess the exclusion list, ensuring it remains relevant and does not inadvertently allow malicious activities to go undetected. + +### Response and remediation + +- Isolate the affected system from the network to prevent further malicious communication and potential lateral movement. +- Terminate any suspicious processes identified in the alert that are not typically associated with network activity, such as those running from unusual paths or with unexpected network connections. +- Conduct a thorough review of the system's recent activity logs to identify any unauthorized changes or additional indicators of compromise. +- Remove any malicious files or executables found on the system, ensuring that all remnants of the threat are eradicated. +- Restore the system from a known good backup if any critical system files or configurations have been altered. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/command_and_control_iexplore_via_com.toml b/rules/windows/command_and_control_iexplore_via_com.toml index 79424244132..9bafb1266ca 100644 --- a/rules/windows/command_and_control_iexplore_via_com.toml +++ b/rules/windows/command_and_control_iexplore_via_com.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/28" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -49,6 +49,41 @@ sequence by host.id, user.name with maxspan = 5s ) ] /* with runs=5 */ ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Command and Control via Internet Explorer + +Internet Explorer can be manipulated via the Component Object Model (COM) to initiate network connections, potentially bypassing security measures. Adversaries exploit this by embedding IE in processes like rundll32.exe, making it appear benign. The detection rule identifies unusual DNS queries from IE, excluding common Microsoft domains, to flag suspicious activity indicative of command and control attempts. + +### Possible investigation steps + +- Review the alert details to identify the specific host and user associated with the suspicious activity, focusing on the host.id and user.name fields. +- Examine the process tree on the affected host to confirm if Internet Explorer (iexplore.exe) was indeed started via COM, specifically looking for the parent process rundll32.exe or regsvr32.exe with IEProxy.dll loaded. +- Analyze the DNS queries made by Internet Explorer to identify any unusual or suspicious domains that are not part of the common Microsoft or OCSP-related domains listed in the exclusion list. +- Check the network connections initiated by Internet Explorer to determine if there are any unexpected or unauthorized external IP addresses or domains being contacted. +- Investigate the context and timing of the alert by correlating it with other security events or logs from the same host or user to identify any patterns or additional indicators of compromise. +- Assess the risk and potential impact of the detected activity by considering the severity of the alert and any additional findings from the investigation steps above. + +### False positive analysis + +- Internet Explorer may make legitimate DNS queries to domains not listed in the exclusion list, such as those related to third-party services or internal company resources. Users should monitor and identify these domains and consider adding them to the exclusion list if they are verified as non-threatening. +- Some enterprise environments may use custom applications that leverage Internet Explorer via COM for legitimate purposes. In such cases, users should identify these applications and create exceptions for their associated processes to prevent false positives. +- Regular updates or patches from non-Microsoft sources might trigger alerts if they use Internet Explorer for network connections. Users should verify the legitimacy of these updates and adjust the exclusion list accordingly. +- Internal network monitoring tools or scripts that use Internet Explorer for testing or monitoring purposes could be flagged. Users should document these tools and exclude their associated network activities from the detection rule. +- If a specific user or department frequently triggers alerts due to legitimate use of Internet Explorer, consider creating user or department-specific exceptions to reduce noise while maintaining security oversight. + +### Response and remediation + +- Isolate the affected host from the network immediately to prevent further command and control communication and potential data exfiltration. +- Terminate the Internet Explorer process (iexplore.exe) and any associated processes like rundll32.exe or regsvr32.exe that are identified as suspicious. +- Conduct a thorough scan of the isolated host using updated antivirus and anti-malware tools to identify and remove any malicious software or scripts. +- Review and analyze the DNS query logs to identify any other potentially compromised hosts within the network that may have communicated with the same suspicious domains. +- Restore the affected system from a known good backup if malware is confirmed and cannot be fully removed, ensuring that the backup is free from compromise. +- Implement network-level controls to block the identified suspicious domains and IP addresses to prevent future communication attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/command_and_control_outlook_home_page.toml b/rules/windows/command_and_control_outlook_home_page.toml index e91e82eb0d6..8524784e187 100644 --- a/rules/windows/command_and_control_outlook_home_page.toml +++ b/rules/windows/command_and_control_outlook_home_page.toml @@ -2,7 +2,7 @@ creation_date = "2024/08/01" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -49,6 +49,40 @@ registry where host.os.type == "windows" and event.action != "deletion" and regi "USER\\*\\SOFTWARE\\Microsoft\\Office\\*\\Outlook\\Webview\\Inbox\\URL" ) and registry.data.strings : "*http*" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Outlook Home Page Registry Modification + +The Outlook Home Page feature allows users to set a webpage as the default view for folders, leveraging registry keys to store URL configurations. Adversaries exploit this by modifying these keys to redirect to malicious sites, enabling command and control or persistence. The detection rule identifies suspicious registry changes, focusing on URL entries within specific paths, flagging potential misuse for further investigation. + +### Possible investigation steps + +- Review the registry path and value to confirm the presence of a suspicious URL entry in the specified registry paths, such as "HKCU\\\\*\\\\SOFTWARE\\\\Microsoft\\\\Office\\\\*\\\\Outlook\\\\Webview\\\\Inbox\\\\URL". +- Investigate the URL found in the registry data strings to determine if it is known to be malicious or associated with suspicious activity. +- Check the modification history of the registry key to identify when the change occurred and which user or process made the modification. +- Correlate the registry modification event with other security events on the host, such as network connections or process executions, to identify potential malicious activity. +- Assess the affected system for signs of compromise, including unusual network traffic or unauthorized access attempts, to determine the scope of the incident. +- Consult threat intelligence sources to see if the URL or related indicators are associated with known threat actors or campaigns. + +### False positive analysis + +- Legitimate software updates or installations may modify the registry keys associated with Outlook's Home Page feature. Users can create exceptions for known software update processes to prevent unnecessary alerts. +- Custom scripts or administrative tools used by IT departments to configure Outlook settings across multiple machines might trigger this rule. Identifying and excluding these trusted scripts or tools can reduce false positives. +- Some third-party Outlook add-ins or plugins may alter the registry keys for legitimate purposes. Users should verify the legitimacy of these add-ins and whitelist them if they are deemed safe. +- Automated backup or recovery solutions that restore Outlook settings might cause registry changes. Users can exclude these processes if they are part of a regular and secure backup routine. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further communication with potentially malicious sites. +- Use endpoint detection and response (EDR) tools to terminate any suspicious processes associated with the modified registry keys. +- Restore the modified registry keys to their default values to remove the malicious URL configuration. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional threats. +- Review and analyze network logs to identify any outbound connections to suspicious domains or IP addresses, and block these at the firewall. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if other systems are affected. +- Implement additional monitoring on the affected system and similar endpoints to detect any recurrence of the threat, focusing on registry changes and network activity.""" [[rule.threat]] diff --git a/rules/windows/command_and_control_screenconnect_childproc.toml b/rules/windows/command_and_control_screenconnect_childproc.toml index 890ac2e7d0f..078062cd8f7 100644 --- a/rules/windows/command_and_control_screenconnect_childproc.toml +++ b/rules/windows/command_and_control_screenconnect_childproc.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende maturity = "production" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." min_stack_version = "8.14.0" -updated_date = "2024/10/31" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -59,6 +59,41 @@ process where host.os.type == "windows" and event.type == "start" and "ssh.exe", "scp.exe", "wevtutil.exe", "wget.exe", "wmic.exe") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious ScreenConnect Client Child Process + +ScreenConnect, a remote access tool, facilitates legitimate remote support but can be exploited by adversaries to execute unauthorized commands. Malicious actors may spawn processes like PowerShell or cmd.exe via ScreenConnect to perform harmful activities. The detection rule identifies such suspicious child processes, focusing on unusual arguments and process names, indicating potential abuse of remote access capabilities. + +### Possible investigation steps + +- Review the parent process name to confirm it is one of the ScreenConnect client processes listed in the query, such as ScreenConnect.ClientService.exe or ScreenConnect.WindowsClient.exe, to verify the source of the suspicious activity. +- Examine the child process name and arguments, such as powershell.exe with encoded commands or cmd.exe with /c, to identify potentially malicious actions or commands being executed. +- Check the network activity associated with the suspicious process, especially if the process arguments include network-related terms like *http* or *downloadstring*, to determine if there is any unauthorized data exfiltration or command and control communication. +- Investigate the user account under which the suspicious process was executed to assess if the account has been compromised or is being misused. +- Correlate the event with other security alerts or logs from data sources like Elastic Defend or Microsoft Defender for Endpoint to gather additional context and identify any related malicious activities. +- Review the system's recent activity and changes, such as new scheduled tasks or services created by schtasks.exe or sc.exe, to identify any persistence mechanisms that may have been established by the attacker. + +### False positive analysis + +- Legitimate IT support activities using ScreenConnect may trigger the rule when executing scripts or commands for maintenance. To manage this, identify and whitelist specific IT support accounts or IP addresses that regularly perform these actions. +- Automated scripts or scheduled tasks that use ScreenConnect for routine operations might be flagged. Review and document these scripts, then create exceptions for known benign processes and arguments. +- Software updates or installations initiated through ScreenConnect can appear suspicious. Maintain a list of approved software and update processes, and exclude these from the rule. +- Internal security tools or monitoring solutions that leverage ScreenConnect for legitimate purposes may be detected. Verify these tools and add them to an exclusion list to prevent false positives. +- Training sessions or demonstrations using ScreenConnect to showcase command-line tools could be misinterpreted as threats. Ensure these sessions are logged and recognized as non-threatening, and adjust the rule to accommodate these scenarios. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. +- Terminate any suspicious processes identified in the alert, such as PowerShell, cmd.exe, or other flagged executables, to halt any ongoing malicious activity. +- Review and revoke any unauthorized user accounts or privileges that may have been created or modified using tools like net.exe or schtasks.exe. +- Conduct a thorough scan of the affected system using endpoint protection tools to identify and remove any malware or unauthorized software installed by the attacker. +- Restore the system from a known good backup if any critical system files or configurations have been altered or compromised. +- 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 enhanced monitoring and logging for ScreenConnect and other remote access tools to detect similar activities in the future, ensuring that alerts are promptly reviewed and acted upon.""" [[rule.threat]] diff --git a/rules/windows/command_and_control_tunnel_vscode.toml b/rules/windows/command_and_control_tunnel_vscode.toml index d40001f8bc6..e2e6141f8a4 100644 --- a/rules/windows/command_and_control_tunnel_vscode.toml +++ b/rules/windows/command_and_control_tunnel_vscode.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende maturity = "production" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." min_stack_version = "8.14.0" -updated_date = "2024/10/31" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -45,6 +45,41 @@ process where host.os.type == "windows" and event.type == "start" and process.args : "tunnel" and (process.args : "--accept-server-license-terms" or process.name : "code*.exe") and not (process.name == "code-tunnel.exe" and process.args == "status" and process.parent.name == "Code.exe") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Attempt to Establish VScode Remote Tunnel + +Visual Studio Code (VScode) offers a remote tunnel feature enabling developers to connect to remote environments seamlessly. While beneficial for legitimate remote development, adversaries can exploit this to establish unauthorized access or control over systems. The detection rule identifies suspicious use of VScode's tunnel command, focusing on specific command-line arguments and process behaviors, to flag potential misuse indicative of command and control activities. + +### Possible investigation steps + +- Review the process details to confirm the presence of the "tunnel" argument in the command line, which indicates an attempt to establish a remote tunnel session. +- Check the parent process name to ensure it is not "Code.exe" when the process name is "code-tunnel.exe" with the "status" argument, as this is an exception in the rule. +- Investigate the origin of the process by examining the user account and machine from which the process was initiated to determine if it aligns with expected usage patterns. +- Analyze network logs to identify any unusual or unauthorized connections to GitHub or remote VScode instances that may suggest malicious activity. +- Correlate the event with other security alerts or logs from data sources like Elastic Endgame, Sysmon, or Microsoft Defender for Endpoint to gather additional context on the activity. +- Assess the risk and impact by determining if the system or user account has been involved in previous suspicious activities or if there are any indicators of compromise. + +### False positive analysis + +- Legitimate remote development activities using VScode's tunnel feature may trigger the rule. Users can create exceptions for known developer machines or specific user accounts frequently using this feature for authorized purposes. +- Automated scripts or deployment tools that utilize VScode's remote tunnel for legitimate operations might be flagged. Consider excluding these processes by identifying their unique command-line arguments or parent processes. +- Scheduled tasks or system maintenance activities that involve VScode's remote capabilities could be misidentified as threats. Review and whitelist these tasks by their specific execution times or associated service accounts. +- Development environments that frequently update or test VScode extensions might inadvertently match the rule's criteria. Exclude these environments by setting up exceptions based on their network segments or IP addresses. +- Training or demonstration sessions using VScode's remote features for educational purposes can be mistaken for suspicious activity. Implement exclusions for these sessions by tagging them with specific event identifiers or user roles. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious VScode processes identified by the detection rule to halt potential command and control activities. +- Conduct a thorough review of system logs and process histories to identify any additional indicators of compromise or lateral movement attempts. +- Reset credentials and access tokens associated with the affected system and any connected services to mitigate unauthorized access. +- Restore the system from a known good backup if any unauthorized changes or malware are detected. +- Implement network segmentation to limit the ability of similar threats to spread across the environment. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/credential_access_adidns_wildcard.toml b/rules/windows/credential_access_adidns_wildcard.toml index 7b42d66d267..246b3c1e8fc 100644 --- a/rules/windows/credential_access_adidns_wildcard.toml +++ b/rules/windows/credential_access_adidns_wildcard.toml @@ -2,7 +2,7 @@ creation_date = "2024/03/26" integration = ["system", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -66,6 +66,41 @@ query = ''' any where host.os.type == "windows" and event.action in ("Directory Service Changes", "directory-service-object-modified") and event.code == "5137" and startsWith(winlog.event_data.ObjectDN, "DC=*,") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 ADIDNS Poisoning via Wildcard Record Creation + +Active Directory Integrated DNS (ADIDNS) is crucial for maintaining domain consistency by storing DNS zones as AD objects. However, its default permissions allow authenticated users to create DNS records, which adversaries can exploit by adding wildcard records. This enables them to redirect traffic and perform Man-in-the-Middle attacks. The detection rule identifies such abuse by monitoring specific directory service changes indicative of wildcard record creation. + +### Possible investigation steps + +- Review the event logs on the affected Windows host to confirm the presence of event code 5137, which indicates a directory service object modification. +- Examine the ObjectDN field in the event data to identify the specific DNS zone where the wildcard record was created, ensuring it starts with "DC=*," to confirm the wildcard nature. +- Check the user account associated with the event to determine if it is a legitimate account or potentially compromised, focusing on any unusual or unauthorized activity. +- Investigate recent changes in the DNS zone to identify any other suspicious modifications or patterns that could indicate further malicious activity. +- Correlate the event with network traffic logs to detect any unusual or redirected traffic patterns that could suggest a Man-in-the-Middle attack. +- Assess the permissions and access controls on the DNS zones to ensure they are appropriately configured and restrict unnecessary modifications by authenticated users. + +### False positive analysis + +- Routine administrative changes to DNS records by IT staff can trigger alerts. To manage this, create exceptions for known administrative accounts or specific ObjectDN patterns that correspond to legitimate changes. +- Automated systems or scripts that update DNS records as part of regular maintenance may cause false positives. Identify these systems and exclude their activity from triggering alerts by filtering based on their unique identifiers or event sources. +- Software installations or updates that modify DNS settings might be flagged. Monitor and document these activities, and consider excluding them if they are part of a recognized and secure process. +- Changes made by trusted third-party services that integrate with ADIDNS could be misinterpreted as threats. Verify these services and whitelist their actions to prevent unnecessary alerts. +- Temporary testing environments that mimic production settings might generate alerts. Ensure these environments are clearly documented and excluded from monitoring if they are known to perform non-threatening wildcard record creations. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further exploitation or data exfiltration. +- Revoke any potentially compromised credentials associated with the affected system or user accounts involved in the alert. +- Conduct a thorough review of DNS records in the affected zone to identify and remove any unauthorized wildcard entries. +- Implement stricter access controls on DNS record creation, limiting permissions to only necessary administrative accounts. +- Monitor network traffic for signs of Man-in-the-Middle activity, focusing on unusual DNS queries or redirections. +- Escalate the incident to the security operations center (SOC) for further investigation and to assess the potential impact on other systems. +- Update detection mechanisms to include additional indicators of compromise related to ADIDNS abuse, enhancing future threat detection capabilities.""" [[rule.threat]] diff --git a/rules/windows/credential_access_adidns_wpad_record.toml b/rules/windows/credential_access_adidns_wpad_record.toml index 94388242ee5..891d1c9a237 100644 --- a/rules/windows/credential_access_adidns_wpad_record.toml +++ b/rules/windows/credential_access_adidns_wpad_record.toml @@ -2,7 +2,7 @@ creation_date = "2024/06/03" integration = ["system", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -63,6 +63,41 @@ query = ''' any where host.os.type == "windows" and event.action in ("Directory Service Changes", "directory-service-object-modified") and event.code == "5137" and winlog.event_data.ObjectDN : "DC=wpad,*" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 WPAD Spoofing via DNS Record Creation + +Web Proxy Auto-Discovery (WPAD) helps devices automatically detect proxy settings, crucial for network efficiency. However, attackers can exploit WPAD by creating malicious DNS records, tricking systems into using rogue proxies for data interception. The detection rule identifies suspicious DNS record changes, specifically targeting WPAD entries, to flag potential spoofing attempts, aiding in early threat detection and mitigation. + +### Possible investigation steps + +- Review the event logs for the specific event code "5137" to identify the creation or modification of the "wpad" DNS record. Focus on the details provided in the winlog.event_data.ObjectDN field to confirm the presence of "DC=wpad,*". +- Check the Active Directory change history to determine who made the changes to the DNS records and whether these changes were authorized. +- Investigate the user account associated with the directory service change event to assess if it has been compromised or if there are any signs of unauthorized access. +- Analyze network traffic to and from the "wpad" DNS record to identify any suspicious activity or connections to rogue proxy servers. +- Verify the configuration of the Global Query Block List (GQBL) to ensure it has not been disabled or altered, which could allow unauthorized WPAD entries. +- Cross-reference the alert with other security logs and alerts to identify any related suspicious activities or patterns that could indicate a broader attack campaign. + +### False positive analysis + +- Legitimate network changes may trigger alerts if a new WPAD DNS record is created intentionally for network configuration. Verify with network administrators if such changes were planned. +- Automated scripts or software updates that modify DNS records can cause false positives. Review the source of the change and consider excluding known benign scripts or update processes. +- Test environments often simulate DNS changes, including WPAD entries, for development purposes. Exclude these environments from monitoring if they are known to generate non-threatening alerts. +- Some organizations may have legacy systems that rely on WPAD configurations. Document these systems and create exceptions for their DNS changes to avoid unnecessary alerts. +- Regular audits of the Global Query Block List settings can help identify and exclude expected changes, reducing false positives related to WPAD record creation. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further data interception or lateral movement by the rogue proxy. +- Verify and restore the integrity of the DNS records by removing any unauthorized "wpad" entries and re-enabling the Global Query Block List (GQBL) if it was disabled. +- Conduct a thorough review of Active Directory logs to identify any unauthorized changes or suspicious activities related to directory service modifications. +- Reset credentials for any accounts that may have been compromised or accessed during the incident to prevent unauthorized access. +- Implement network segmentation to limit the exposure of critical systems to potential WPAD spoofing attacks. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems or data were affected. +- Update and enhance monitoring rules to detect similar WPAD spoofing attempts in the future, ensuring timely alerts and responses.""" [[rule.threat]] diff --git a/rules/windows/credential_access_dcsync_user_backdoor.toml b/rules/windows/credential_access_dcsync_user_backdoor.toml index 409b70d352e..34eb9d57106 100644 --- a/rules/windows/credential_access_dcsync_user_backdoor.toml +++ b/rules/windows/credential_access_dcsync_user_backdoor.toml @@ -2,7 +2,7 @@ creation_date = "2024/07/10" integration = ["system", "windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -17,7 +17,43 @@ index = ["winlogbeat-*", "logs-system.security*", "logs-windows.forwarded*"] language = "kuery" license = "Elastic License v2" name = "Potential Active Directory Replication Account Backdoor" -note = """## Setup +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Active Directory Replication Account Backdoor + +Active Directory (AD) is a critical component in many enterprise environments, managing user and computer accounts. Adversaries may exploit AD by modifying security descriptors to gain replication rights, allowing them to extract sensitive credential data. The detection rule identifies suspicious changes to security descriptors, specifically targeting attributes that grant replication capabilities, which could indicate an attempt to establish a backdoor for credential access. + +### Possible investigation steps + +- Review the event logs for the specific event code 5136 to identify the exact changes made to the nTSecurityDescriptor attribute and the account involved. +- Examine the winlog.event_data.AttributeValue to determine if the changes include the specific GUIDs (*1131f6ad-9c07-11d1-f79f-00c04fc2dcd2, *1131f6aa-9c07-11d1-f79f-00c04fc2dcd2, *89e95b76-444d-4c62-991a-0facbeda640c) that indicate replication rights were granted. +- Identify the user or computer account (S-1-5-21-*) that was granted these rights and assess whether this account should have such permissions. +- Check the account's recent activity and login history to identify any unusual or unauthorized access patterns. +- Investigate any recent changes or anomalies in the directory service that could correlate with the suspicious modification event. +- Consult with the Active Directory administrators to verify if the changes were authorized and part of any legitimate administrative tasks. + +### False positive analysis + +- Changes made by authorized administrators during legitimate security audits or system maintenance can trigger the rule. To manage this, create exceptions for known administrative accounts performing regular audits. +- Automated scripts or tools used for Active Directory management might modify security descriptors as part of their normal operation. Identify these scripts and exclude their associated accounts from triggering alerts. +- Scheduled tasks or system processes that require replication rights for synchronization purposes may also cause false positives. Review and whitelist these processes if they are verified as non-threatening. +- Third-party applications with legitimate replication needs might alter security descriptors. Ensure these applications are documented and their actions are excluded from the rule. +- Temporary changes during system migrations or upgrades can be mistaken for suspicious activity. Monitor these events closely and apply temporary exceptions as needed. + +### Response and remediation + +- Immediately isolate the affected user or computer account from the network to prevent further unauthorized access or data exfiltration. +- Revoke any unauthorized permissions or changes made to the nTSecurityDescriptor attribute for the affected account to remove replication rights. +- Conduct a thorough review of recent changes to the AD environment, focusing on accounts with elevated privileges, to identify any other unauthorized modifications. +- Reset passwords for all accounts that may have been compromised, prioritizing those with administrative or sensitive access. +- Implement additional monitoring on the affected account and related systems to detect any further suspicious activity. +- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the full scope of the breach. +- Review and update access control policies and security descriptors in Active Directory to prevent similar unauthorized changes in the future. + +## Setup The 'Audit Directory Service Changes' logging policy must be configured for (Success, Failure). Steps to implement the logging policy with Advanced Audit Configuration: diff --git a/rules/windows/credential_access_dnsnode_creation.toml b/rules/windows/credential_access_dnsnode_creation.toml index 912a7da74cc..4befb35a940 100644 --- a/rules/windows/credential_access_dnsnode_creation.toml +++ b/rules/windows/credential_access_dnsnode_creation.toml @@ -2,7 +2,7 @@ creation_date = "2024/03/26" integration = ["system", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -67,6 +67,41 @@ any where host.os.type == "windows" and event.action in ("Directory Service Chan event.code == "5137" and winlog.event_data.ObjectClass == "dnsNode" and not winlog.event_data.SubjectUserName : "*$" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Creation of a DNS-Named Record + +Active Directory Integrated DNS (ADIDNS) is crucial for maintaining domain consistency by storing DNS zones as AD objects. However, its default permissions can be exploited by attackers to create DNS records for spoofing attacks, targeting services like WPAD. The detection rule identifies such abuse by monitoring specific Windows events related to DNS record creation, filtering out legitimate system accounts to highlight potential threats. + +### Possible investigation steps + +- Review the event logs for event code 5137 to identify the specific DNS-named record that was created and the associated timestamp. +- Examine the winlog.event_data.SubjectUserName field to determine the user account that initiated the DNS record creation, ensuring it is not a system account. +- Investigate the context around the winlog.event_data.ObjectClass field to confirm the object class is "dnsNode" and assess if the DNS record creation aligns with expected administrative activities. +- Check for any recent LLMNR/NBT-NS requests or network traffic that might indicate an attempt to exploit the newly created DNS record for spoofing purposes. +- Correlate the alert with other security events or logs to identify any patterns or anomalies that might suggest malicious intent or unauthorized access attempts. +- Assess the risk and impact of the DNS record creation by determining if it targets critical services like WPAD or other sensitive systems within the network. + +### False positive analysis + +- Legitimate administrative actions may trigger the rule when DNS records are created or modified by IT staff. To manage this, create exceptions for known administrative accounts that regularly perform these tasks. +- Automated system processes or scripts that update DNS records can also cause false positives. Identify these processes and exclude their associated accounts from the rule to prevent unnecessary alerts. +- Service accounts used by legitimate applications to dynamically update DNS records might be flagged. Review these accounts and add them to an exception list if they are verified as non-threatening. +- Temporary network changes or testing environments where DNS records are frequently modified can lead to false positives. Consider excluding these environments or specific IP ranges from the rule to reduce noise. +- Regularly review and update the exception list to ensure it reflects current network and administrative practices, minimizing the risk of overlooking genuine threats. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious DNS record creation and potential spoofing attacks. +- Review and remove any unauthorized DNS records created by non-system accounts, focusing on those targeting services like WPAD. +- Reset credentials for any accounts that were potentially compromised or used in the attack to prevent further unauthorized access. +- Implement stricter access controls on DNS record creation within Active Directory to limit permissions to only necessary and trusted accounts. +- Monitor for any further suspicious DNS record creation events, particularly those involving non-system accounts, to detect and respond to potential follow-up attacks. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or services were affected. +- Conduct a post-incident review to identify gaps in detection and response, and update security policies and procedures to prevent similar incidents in the future.""" [[rule.threat]] diff --git a/rules/windows/credential_access_dollar_account_relay.toml b/rules/windows/credential_access_dollar_account_relay.toml index 38245c9dbb2..e6ee0d8a771 100644 --- a/rules/windows/credential_access_dollar_account_relay.toml +++ b/rules/windows/credential_access_dollar_account_relay.toml @@ -2,7 +2,7 @@ creation_date = "2024/07/24" integration = ["system", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -50,6 +50,41 @@ authentication where host.os.type == "windows" and event.code in ("4624", "4625" not endswith(string(source.ip), string(host.ip)) and source.ip != null and source.ip != "::1" and source.ip != "127.0.0.1" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Relay Attack against a Domain Controller + +Domain Controllers (DCs) are critical in managing authentication within Windows environments. Adversaries exploit this by capturing and relaying DC credentials, often using NTLM authentication, to gain unauthorized access. The detection rule identifies anomalies in authentication events, such as machine accounts logging in from unexpected hosts, indicating potential relay attacks. By analyzing network logon types and mismatched IP addresses, it flags suspicious activities, aiding in early threat detection. + +### Possible investigation steps + +- Review the authentication events with event codes 4624 and 4625 to identify any anomalies in logon attempts, focusing on those using NTLM authentication. +- Examine the source IP addresses of the suspicious authentication events to determine if they are external or unexpected within the network environment. +- Verify the machine account names that end with a dollar sign ($) to ensure they match the expected hostnames, and investigate any discrepancies. +- Check the network logon types to confirm if they align with typical usage patterns for the identified machine accounts. +- Investigate the context of the source IP addresses that do not match the host IP, looking for any signs of unauthorized access or unusual network activity. +- Correlate the findings with other security logs and alerts to identify any patterns or additional indicators of compromise related to the potential relay attack. + +### False positive analysis + +- Machine accounts performing legitimate network logons from different IP addresses can trigger false positives. To manage this, identify and whitelist known IP addresses associated with legitimate administrative tasks or automated processes. +- Scheduled tasks or automated scripts that use machine accounts for network operations may be flagged. Review and document these tasks, then create exceptions for their associated IP addresses and hostnames. +- Load balancers or proxy servers that alter the source IP address of legitimate authentication requests can cause false alerts. Ensure these devices are accounted for in the network architecture and exclude their IP addresses from the rule. +- Temporary network reconfigurations or migrations might result in machine accounts appearing to log in from unexpected hosts. During such events, temporarily adjust the rule parameters or disable the rule to prevent unnecessary alerts. +- Regularly review and update the list of exceptions to ensure they reflect current network configurations and operational practices, minimizing the risk of overlooking genuine threats. + +### Response and remediation + +- Immediately isolate the affected domain controller from the network to prevent further unauthorized access and potential lateral movement by the attacker. +- Conduct a password reset for the domain controller's machine account and any other accounts that may have been compromised or are at risk, ensuring the use of strong, unique passwords. +- Review and analyze recent authentication logs and network traffic to identify any other potentially compromised systems or accounts, focusing on the source IP addresses flagged in the alert. +- Implement network segmentation to limit the ability of attackers to relay credentials between systems, particularly between domain controllers and other critical infrastructure. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the full scope of the breach. +- Deploy additional monitoring and detection mechanisms to identify similar relay attack patterns in the future, enhancing the detection capabilities for NTLM relay attacks. +- Conduct a post-incident review to identify any gaps in security controls and update policies or procedures to prevent recurrence, ensuring lessons learned are applied to improve overall security posture.""" [[rule.threat]] diff --git a/rules/windows/credential_access_generic_localdumps.toml b/rules/windows/credential_access_generic_localdumps.toml index ec951d94d75..fab82cacb2f 100644 --- a/rules/windows/credential_access_generic_localdumps.toml +++ b/rules/windows/credential_access_generic_localdumps.toml @@ -2,7 +2,7 @@ creation_date = "2022/08/28" integration = ["endpoint", "windows", "m365_defender"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -50,6 +50,40 @@ registry where host.os.type == "windows" and registry.data.strings : ("2", "0x00000002") and not (process.executable : "?:\\Windows\\system32\\svchost.exe" and user.id : ("S-1-5-18", "S-1-5-19", "S-1-5-20")) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Full User-Mode Dumps Enabled System-Wide + +Full user-mode dumps are a diagnostic feature in Windows that captures detailed information about application crashes, aiding in troubleshooting. However, attackers can exploit this by triggering dumps of sensitive processes like LSASS to extract credentials. The detection rule identifies registry changes enabling this feature system-wide, flagging potential misuse by excluding legitimate system processes, thus alerting analysts to suspicious activity. + +### Possible investigation steps + +- Review the registry path HKLM\\SOFTWARE\\Microsoft\\Windows\\Windows Error Reporting\\LocalDumps\\DumpType to confirm if the value is set to "2" or "0x00000002", indicating full user-mode dumps are enabled. +- Check for any recent changes to the registry key by examining the modification timestamps and identifying the user or process responsible for the change. +- Investigate the context of the alert by reviewing recent process execution logs to identify any suspicious processes that may have triggered the dump, especially those not matching the legitimate svchost.exe process with user IDs S-1-5-18, S-1-5-19, or S-1-5-20. +- Analyze any generated dump files for sensitive information, such as credentials, and determine if they were accessed or exfiltrated by unauthorized users or processes. +- Correlate the alert with other security events or logs, such as Sysmon or Microsoft Defender for Endpoint, to identify any related suspicious activities or patterns that could indicate a broader attack. + +### False positive analysis + +- Legitimate system processes like svchost.exe may trigger the rule if they are not properly excluded. Ensure that the exclusion for svchost.exe is correctly configured by verifying the process executable path and user IDs. +- Custom applications that require full user-mode dumps for legitimate debugging purposes might be flagged. Identify these applications and create specific registry subkey exclusions to prevent false positives. +- System administrators performing routine maintenance or diagnostics might enable full user-mode dumps temporarily. Document these activities and consider creating temporary exceptions during maintenance windows. +- Security tools or monitoring software that simulate crash scenarios for testing purposes could trigger the rule. Verify the legitimacy of these tools and add them to an exclusion list if they are part of regular security operations. +- Updates or patches from software vendors that modify registry settings for error reporting might be misinterpreted as suspicious. Monitor update schedules and correlate any rule triggers with known update activities to avoid unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further credential access or lateral movement by the attacker. +- Terminate any unauthorized processes that are generating full user-mode dumps, especially those related to LSASS, to stop further credential dumping. +- Conduct a thorough review of the registry settings on the affected system to ensure that the full user-mode dumps feature is disabled unless explicitly required for legitimate purposes. +- Change all credentials that may have been exposed, particularly those associated with high-privilege accounts, to mitigate the risk of unauthorized access. +- 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 enhanced monitoring and alerting for similar registry changes across the network to detect and respond to future attempts promptly. +- Review and update endpoint protection configurations to ensure they are capable of detecting and blocking similar credential dumping techniques.""" [[rule.threat]] diff --git a/rules/windows/credential_access_iis_connectionstrings_dumping.toml b/rules/windows/credential_access_iis_connectionstrings_dumping.toml index 127e86d766f..0dd24585fda 100644 --- a/rules/windows/credential_access_iis_connectionstrings_dumping.toml +++ b/rules/windows/credential_access_iis_connectionstrings_dumping.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/18" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2024/11/02" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -57,6 +57,41 @@ process where host.os.type == "windows" and event.type == "start" and (process.name : "aspnet_regiis.exe" or ?process.pe.original_file_name == "aspnet_regiis.exe") and process.args : "connectionStrings" and process.args : "-pdf" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft IIS Connection Strings Decryption + +Microsoft IIS often stores sensitive connection strings in encrypted form to secure database credentials. The `aspnet_regiis` tool can decrypt these strings, a feature intended for legitimate administrative tasks. However, attackers with access to the IIS server, possibly via a webshell, can exploit this to extract credentials. The detection rule identifies suspicious use of `aspnet_regiis` by monitoring process execution with specific arguments, flagging potential credential access attempts. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of aspnet_regiis.exe with the specific arguments "connectionStrings" and "-pdf" to ensure the alert is not a false positive. +- Check the user account associated with the process execution to determine if it is a legitimate administrative account or a potentially compromised one. +- Investigate the source of the process initiation by examining the parent process and any related processes to identify if a webshell or unauthorized script triggered the execution. +- Analyze recent login activities and access logs on the IIS server to identify any unusual or unauthorized access patterns that could indicate a compromise. +- Review the server's security logs and any available network traffic data to detect any signs of data exfiltration or further malicious activity following the decryption attempt. +- Assess the integrity and security of the IIS server by checking for any unauthorized changes or suspicious files that may have been introduced by an attacker. + +### False positive analysis + +- Routine administrative tasks using aspnet_regiis for legitimate configuration changes can trigger the rule. To manage this, create exceptions for known maintenance windows or specific administrator accounts performing these tasks. +- Automated deployment scripts that include aspnet_regiis for setting up or updating IIS configurations may cause false positives. Exclude these scripts by identifying their unique process arguments or execution paths. +- Scheduled tasks or services that periodically run aspnet_regiis for configuration validation or updates might be flagged. Document these tasks and exclude them based on their scheduled times or associated service accounts. +- Development environments where developers frequently use aspnet_regiis for testing purposes can generate alerts. Consider excluding specific development servers or user accounts from the rule to reduce noise. +- Security tools or monitoring solutions that simulate attacks for testing purposes may inadvertently trigger the rule. Coordinate with security teams to whitelist these tools or their specific test scenarios. + +### Response and remediation + +- Immediately isolate the affected IIS server from the network to prevent further unauthorized access and potential data exfiltration. +- Terminate any suspicious processes related to aspnet_regiis.exe to halt any ongoing decryption attempts. +- Conduct a thorough review of IIS server logs and webshell activity to identify the source of the compromise and any other affected systems. +- Change all credentials associated with the decrypted connection strings, including database passwords and service account credentials, to prevent unauthorized access. +- Restore the IIS server from a known good backup taken before the compromise, ensuring that any webshells or malicious scripts are removed. +- Implement enhanced monitoring and alerting for any future unauthorized use of aspnet_regiis.exe, focusing on the specific arguments used in the detection query. +- Escalate the incident to the security operations center (SOC) or relevant incident response team for further investigation and to assess the broader impact on the organization.""" [[rule.threat]] diff --git a/rules/windows/credential_access_imageload_azureadconnectauthsvc.toml b/rules/windows/credential_access_imageload_azureadconnectauthsvc.toml index b1bcc5351d1..548a4e17b7b 100644 --- a/rules/windows/credential_access_imageload_azureadconnectauthsvc.toml +++ b/rules/windows/credential_access_imageload_azureadconnectauthsvc.toml @@ -2,7 +2,7 @@ creation_date = "2024/10/14" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -54,6 +54,41 @@ not (?dll.code_signature.trusted == true or file.code_signature.status == "Valid "?:\\Windows\\System32\\DriverStore\\FileRepository\\*") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Untrusted DLL Loaded by Azure AD Sync Service + +Azure AD Sync Service facilitates identity synchronization between on-premises directories and Azure AD, crucial for seamless authentication. Adversaries may exploit this by loading malicious DLLs to intercept credentials. The detection rule identifies untrusted DLLs loaded by the Azure AD Sync process, focusing on those lacking valid signatures and excluding known safe paths, thus highlighting potential credential access threats. + +### Possible investigation steps + +- Review the process details for AzureADConnectAuthenticationAgentService.exe to confirm its legitimacy and check for any unusual behavior or anomalies. +- Examine the specific DLL file path that triggered the alert to determine if it is located in an unexpected or suspicious directory. +- Investigate the code signature status of the DLL to understand why it is untrusted, and verify if the DLL should have a valid signature. +- Check the system for any recent changes or installations that could have introduced the untrusted DLL, focusing on the timeframe around the alert. +- Analyze the event logs for any other suspicious activities or related alerts that might indicate a broader compromise or attack pattern. +- Correlate the alert with other security tools or logs to gather additional context and determine if this is part of a larger attack campaign. + +### False positive analysis + +- DLLs from legitimate software updates or installations may trigger alerts if they are not yet recognized as trusted. Users can monitor these occurrences and verify the legitimacy of the software source before adding exceptions. +- Custom or in-house developed applications might load DLLs that lack valid signatures. Users should ensure these applications are from a trusted source and consider signing them or adding their paths to the exclusion list. +- DLLs located in non-standard directories that are part of legitimate software operations can be flagged. Users should verify the software's legitimacy and update the exclusion list with these specific paths if necessary. +- Temporary files or DLLs created during software installation or updates might be flagged. Users should confirm the installation process and temporarily exclude these paths during the update period. +- Security or monitoring tools that dynamically load DLLs for legitimate purposes may be misidentified. Users should verify the tool's activity and add it to the exclusion list if it is deemed safe. + +### Response and remediation + +- Immediately isolate the affected Azure AD Sync server from the network to prevent further unauthorized access or data exfiltration. +- Terminate the AzureADConnectAuthenticationAgentService.exe process to stop the execution of the untrusted DLL and prevent potential credential dumping. +- Conduct a thorough review of the loaded DLLs on the affected server to identify and remove any malicious or unauthorized files. +- Restore the server from a known good backup taken before the incident to ensure the system is free from compromise. +- Change all credentials that may have been exposed or compromised, focusing on those related to Azure AD and on-premises directory services. +- Implement application whitelisting to prevent unauthorized DLLs from being loaded by critical processes like Azure AD Sync. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/credential_access_kirbi_file.toml b/rules/windows/credential_access_kirbi_file.toml index 15cc4ea836a..d1d1abc06c9 100644 --- a/rules/windows/credential_access_kirbi_file.toml +++ b/rules/windows/credential_access_kirbi_file.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende maturity = "production" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." min_stack_version = "8.14.0" -updated_date = "2024/10/31" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -28,6 +28,41 @@ type = "eql" query = ''' file where host.os.type == "windows" and event.type == "creation" and file.extension : "kirbi" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Kirbi File Creation + +Kirbi files are associated with Kerberos, a network authentication protocol used in Windows environments to verify user identities. Adversaries exploit this by using tools like Mimikatz to extract Kerberos tickets, enabling unauthorized access through techniques like Pass-The-Ticket. The detection rule identifies the creation of these files, signaling potential credential dumping activities, by monitoring file creation events with a specific extension on Windows systems. + +### Possible investigation steps + +- Review the alert details to identify the specific host where the .kirbi file was created, focusing on the host.os.type field to confirm it is a Windows system. +- Examine the file creation event logs to determine the exact timestamp of the .kirbi file creation and correlate it with other security events around the same time. +- Investigate the user account associated with the file creation event to determine if it is a legitimate user or potentially compromised, using the event data to identify the user. +- Check for any recent logins or authentication attempts on the affected host that may indicate unauthorized access, focusing on unusual or unexpected activity. +- Analyze the process tree and parent processes related to the file creation event to identify any suspicious or unauthorized processes that may have led to the creation of the .kirbi file. +- Look for additional indicators of compromise on the host, such as other suspicious file creations, modifications, or network connections, to assess the scope of the potential breach. +- Consult threat intelligence sources or internal threat databases to determine if the detected activity matches known attack patterns or threat actor behaviors associated with Kerberos ticket dumping. + +### False positive analysis + +- Legitimate administrative tools or scripts that manage Kerberos tickets may create .kirbi files as part of their normal operations. Review the context of the file creation event to determine if it aligns with expected administrative activities. +- Scheduled tasks or automated processes that involve Kerberos ticket management might trigger this rule. Identify and document these processes, and consider creating exceptions for known, benign activities. +- Security software or monitoring tools that interact with Kerberos tickets for auditing or compliance purposes could generate .kirbi files. Verify the source of the file creation and whitelist trusted applications or processes. +- Development or testing environments where Kerberos authentication is being simulated or tested may produce .kirbi files. Ensure these environments are well-documented and apply exclusions where necessary to avoid false alerts. + +### Response and remediation + +- Isolate the affected system from the network immediately to prevent further unauthorized access or lateral movement by the attacker. +- Terminate any suspicious processes associated with Mimikatz or other credential dumping tools to halt ongoing malicious activities. +- Conduct a thorough review of recent authentication logs and Kerberos ticket activity to identify any unauthorized access or ticket usage. +- Reset passwords for all potentially compromised accounts, prioritizing those with elevated privileges, to mitigate the risk of further exploitation. +- Revoke all active Kerberos tickets and force re-authentication for all users to ensure that any stolen tickets are rendered useless. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the full scope of the breach. +- Implement enhanced monitoring and logging for Kerberos-related activities to detect and respond to similar threats more effectively in the future.""" [[rule.threat]] diff --git a/rules/windows/credential_access_ldap_attributes.toml b/rules/windows/credential_access_ldap_attributes.toml index 0715a53733a..0b6cb2794cc 100644 --- a/rules/windows/credential_access_ldap_attributes.toml +++ b/rules/windows/credential_access_ldap_attributes.toml @@ -2,7 +2,7 @@ creation_date = "2022/11/09" integration = ["system", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -80,6 +80,41 @@ any where event.action in ("Directory Service Access", "object-operation-perform */ not winlog.event_data.AccessMask in ("0x0", "0x100") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Access to a Sensitive LDAP Attribute + +LDAP (Lightweight Directory Access Protocol) is crucial for accessing and managing directory information in Active Directory environments. Adversaries may exploit LDAP to access sensitive attributes like passwords and decryption keys, facilitating credential theft or privilege escalation. The detection rule identifies unauthorized access attempts by monitoring specific event codes and attribute identifiers, excluding benign activities to reduce noise, thus highlighting potential security threats. + +### Possible investigation steps + +- Review the event logs for event code 4662 to identify the specific user or process attempting to access the sensitive LDAP attributes. +- Check the winlog.event_data.SubjectUserSid to determine the identity of the user or service account involved in the access attempt, excluding the well-known SID S-1-5-18 (Local System). +- Analyze the winlog.event_data.Properties field to confirm which sensitive attribute was accessed, such as unixUserPassword, ms-PKI-AccountCredentials, or msPKI-CredentialRoamingTokens. +- Investigate the context of the access attempt by correlating the event with other logs or alerts around the same timestamp to identify any suspicious patterns or activities. +- Verify the legitimacy of the access by checking if the user or process has a valid reason or permission to access the sensitive attributes, considering the organization's access control policies. +- Assess the potential impact of the access attempt on the organization's security posture, focusing on credential theft or privilege escalation risks. +- Document findings and, if necessary, escalate the incident to the appropriate security team for further action or remediation. + +### False positive analysis + +- Access by legitimate administrative accounts: Regular access by system administrators to sensitive LDAP attributes can trigger alerts. To manage this, create exceptions for known administrative accounts by excluding their SIDs from the detection rule. +- Scheduled system processes: Automated tasks or system processes that require access to certain LDAP attributes may cause false positives. Identify these processes and exclude their specific event codes or AccessMasks if they are consistently benign. +- Service accounts: Service accounts that perform routine directory operations might access sensitive attributes as part of their normal function. Exclude these accounts by adding their SIDs to the exception list to prevent unnecessary alerts. +- Monitoring tools: Security or monitoring tools that scan directory attributes for compliance or auditing purposes can generate false positives. Whitelist these tools by excluding their event sources or specific actions from the detection criteria. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Conduct a thorough review of the access logs to identify any unauthorized users or systems that accessed the sensitive LDAP attributes. +- Reset passwords and revoke any potentially compromised credentials associated with the affected accounts, focusing on those with access to sensitive attributes. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach. +- Implement additional monitoring on the affected systems and accounts to detect any further suspicious activities or attempts to access sensitive LDAP attributes. +- Review and update access controls and permissions for sensitive LDAP attributes to ensure they are restricted to only necessary personnel. +- Conduct a post-incident analysis to identify any gaps in security controls and update policies or procedures to prevent similar incidents in the future.""" [[rule.threat]] diff --git a/rules/windows/credential_access_lsass_handle_via_malseclogon.toml b/rules/windows/credential_access_lsass_handle_via_malseclogon.toml index d2b3ebffb78..075d2a89f4b 100644 --- a/rules/windows/credential_access_lsass_handle_via_malseclogon.toml +++ b/rules/windows/credential_access_lsass_handle_via_malseclogon.toml @@ -2,7 +2,7 @@ creation_date = "2022/06/29" integration = ["windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -50,6 +50,40 @@ process where host.os.type == "windows" and event.code == "10" and /* PROCESS_CREATE_PROCESS & PROCESS_DUP_HANDLE & PROCESS_QUERY_INFORMATION */ winlog.event_data.GrantedAccess == "0x14c0" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious LSASS Access via MalSecLogon + +The Local Security Authority Subsystem Service (LSASS) is crucial for managing security policies and user authentication in Windows environments. Adversaries may exploit the Secondary Logon service to gain unauthorized access to LSASS, aiming to extract sensitive credentials. The detection rule identifies this threat by monitoring for unusual access patterns involving LSASS, specifically when the seclogon.dll is involved, indicating potential credential dumping activities. + +### Possible investigation steps + +- Review the event logs for the specific event code "10" to gather more details about the process that triggered the alert, focusing on the time of occurrence and any associated user accounts. +- Examine the process details for "svchost.exe" to determine if it is running under an expected service or if there are any anomalies in its execution context, such as unusual parent processes or command-line arguments. +- Investigate the call trace involving "seclogon.dll" to understand the sequence of events leading to the LSASS access, and check for any other suspicious modules or DLLs loaded in the process. +- Analyze the granted access value "0x14c0" to confirm if it aligns with typical access patterns for legitimate processes interacting with LSASS, and identify any deviations that could indicate malicious intent. +- Correlate the alert with other security events or logs from the same host or user account to identify any patterns or additional indicators of compromise, such as failed login attempts or other suspicious process activities. +- Check for any recent changes or updates to the system that might explain the unusual behavior, such as software installations, patches, or configuration changes that could affect the Secondary Logon service or LSASS. + +### False positive analysis + +- Legitimate administrative tools or scripts that require access to LSASS for system management tasks may trigger this rule. Users can create exceptions for known tools by excluding specific process names or paths that are verified as safe. +- Security software or endpoint protection solutions that perform regular scans and require access to LSASS might be flagged. Coordinate with security vendors to identify these processes and exclude them from the rule. +- System updates or patches that involve the Secondary Logon service could cause temporary access patterns that mimic suspicious behavior. Monitor update schedules and temporarily adjust the rule to prevent false alerts during these periods. +- Custom enterprise applications that utilize the Secondary Logon service for legitimate purposes may inadvertently match the rule criteria. Work with application developers to understand these access patterns and whitelist the associated processes. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes associated with svchost.exe that are accessing LSASS with the identified suspicious access rights. +- Conduct a thorough review of user accounts and privileges on the affected system to identify any unauthorized changes or access. +- Reset passwords for all accounts that may have been compromised, focusing on high-privilege accounts first. +- Collect and preserve relevant logs and forensic data from the affected system for further analysis and potential legal action. +- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the full scope of the breach. +- Implement additional monitoring and alerting for similar suspicious activities involving LSASS and seclogon.dll to enhance detection capabilities.""" [[rule.threat]] diff --git a/rules/windows/credential_access_lsass_loaded_susp_dll.toml b/rules/windows/credential_access_lsass_loaded_susp_dll.toml index 8516179dd5a..2dc2414c9ee 100644 --- a/rules/windows/credential_access_lsass_loaded_susp_dll.toml +++ b/rules/windows/credential_access_lsass_loaded_susp_dll.toml @@ -2,7 +2,7 @@ creation_date = "2022/12/28" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/10" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -102,6 +102,41 @@ any where event.category in ("library", "driver") and host.os.type == "windows" "4aca034d3d85a9e9127b5d7a10882c2ef4c3e0daa3329ae2ac1d0797398695fb", "86031e69914d9d33c34c2f4ac4ae523cef855254d411f88ac26684265c981d95") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Module Loaded by LSASS + +The Local Security Authority Subsystem Service (LSASS) is crucial for managing security policies and handling user authentication in Windows environments. Adversaries exploit LSASS by loading malicious or untrusted DLLs to access sensitive credentials. The detection rule identifies such threats by monitoring LSASS for unsigned or untrusted DLLs, excluding known safe signatures and hashes, thus flagging potential credential dumping activities. + +### Possible investigation steps + +- Review the process details for lsass.exe to confirm the presence of any unsigned or untrusted DLLs loaded into the process. Pay particular attention to the DLL's code signature status and hash values. +- Cross-reference the identified DLL's hash against known malicious hashes in threat intelligence databases to determine if it is associated with any known threats. +- Investigate the source and path of the suspicious DLL to understand how it was introduced into the system. This may involve checking recent file creation or modification events in the system directories. +- Analyze the system's event logs for any related activities or anomalies around the time the suspicious DLL was loaded, such as unusual user logins or privilege escalation attempts. +- Check for any recent changes in the system's security settings or policies that might have allowed the loading of untrusted DLLs into LSASS. +- If the DLL is confirmed to be malicious, isolate the affected system to prevent further credential access or lateral movement within the network. + +### False positive analysis + +- Legitimate software from trusted vendors not included in the exclusion list may trigger false positives. Users can update the exclusion list with additional trusted signatures or hashes from verified vendors to prevent these alerts. +- Custom or in-house developed DLLs used within the organization might be flagged as suspicious. Organizations should ensure these DLLs are signed with a trusted certificate and add their signatures to the exclusion list if necessary. +- Security software updates or patches from vendors not currently listed may cause false positives. Regularly review and update the exclusion list to include new trusted signatures from security software providers. +- Temporary or expired certificates for legitimate DLLs can result in false positives. Users should verify the legitimacy of these DLLs and update the exclusion list with their signatures if they are confirmed safe. +- DLLs from newly installed software that are not yet recognized as trusted may be flagged. Users should validate the software's source and add its signatures to the exclusion list if it is deemed secure. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate the LSASS process if it is confirmed to be running a malicious or untrusted DLL, ensuring that this action does not disrupt critical services. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or remnants. +- Review and reset credentials for any accounts that may have been compromised, focusing on those with elevated privileges. +- Implement application whitelisting to prevent unauthorized DLLs from being loaded into critical processes like LSASS in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Update security monitoring tools to enhance detection capabilities for similar threats, ensuring that alerts are generated for any future attempts to load untrusted DLLs into LSASS.""" [[rule.threat]] diff --git a/rules/windows/credential_access_posh_relay_tools.toml b/rules/windows/credential_access_posh_relay_tools.toml index c376b490b2d..4d8f8b6150a 100644 --- a/rules/windows/credential_access_posh_relay_tools.toml +++ b/rules/windows/credential_access_posh_relay_tools.toml @@ -2,7 +2,7 @@ creation_date = "2024/03/27" integration = ["windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -68,6 +68,41 @@ event.category:process and host.os.type:windows and ) and not file.directory : "C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Downloads" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 PowerShell Pass-the-Hash/Relay Script + +PowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit PowerShell to perform pass-the-hash attacks, where they use stolen hashed credentials to authenticate without knowing the actual password. The detection rule identifies scripts attempting to execute such attacks by monitoring for specific NTLM negotiation patterns and hex sequences indicative of credential relay activities, while excluding legitimate system processes. + +### Possible investigation steps + +- Review the PowerShell script block text associated with the alert to identify any suspicious patterns or hex sequences, such as "NTLMSSPNegotiate" or specific hex values like "4E544C4D53535000". +- Check the process execution details, including the parent process and command line arguments, to determine if the script was executed by a legitimate user or process. +- Investigate the source and destination IP addresses involved in the NTLM negotiation to identify any unusual or unauthorized network activity. +- Examine the user account associated with the process to verify if it has been compromised or if there are any signs of unauthorized access. +- Correlate the alert with other security events or logs, such as Windows Event Logs or network traffic logs, to gather additional context and identify potential lateral movement or further compromise. +- Assess the file directory from which the script was executed, ensuring it is not a known safe location like "C:\\ProgramData\\Microsoft\\Windows Defender Advanced Threat Protection\\Downloads", which is excluded in the query. + +### False positive analysis + +- Legitimate system processes may occasionally trigger the rule if they perform operations that mimic NTLM negotiation patterns. To manage this, users can create exceptions for specific processes known to be safe by excluding their file paths or hashes. +- Security tools or network monitoring solutions that perform NTLM authentication checks might generate false positives. Users should identify these tools and exclude their associated scripts or directories from the detection rule. +- Automated scripts for system administration that involve NTLM authentication could be flagged. Review these scripts and, if verified as safe, add them to an exclusion list based on their directory or script block text. +- PowerShell scripts used for legitimate penetration testing or security assessments may trigger alerts. Ensure these activities are documented and exclude the relevant scripts or directories during the testing period. +- Regular updates or patches from Microsoft might include scripts that temporarily match the detection criteria. Monitor updates and adjust exclusions as necessary to prevent false positives from these legitimate updates. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further credential relay or unauthorized access. +- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing malicious activities. +- Conduct a thorough review of recent authentication logs and network traffic from the isolated system to identify any lateral movement or additional compromised accounts. +- Reset passwords for any accounts suspected to be compromised, ensuring that new credentials are not reused or easily guessable. +- Apply patches and updates to the affected system and any other vulnerable systems to mitigate known exploits used in pass-the-hash attacks. +- Implement network segmentation to limit the spread of similar attacks in the future, focusing on restricting access to critical systems and sensitive data. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/credential_access_posh_veeam_sql.toml b/rules/windows/credential_access_posh_veeam_sql.toml index 65831163c1c..b0673ac8b0a 100644 --- a/rules/windows/credential_access_posh_veeam_sql.toml +++ b/rules/windows/credential_access_posh_veeam_sql.toml @@ -2,7 +2,7 @@ creation_date = "2024/03/14" integration = ["windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -62,6 +62,40 @@ event.category:process and host.os.type:windows and "ProtectedStorage]::GetLocalString" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 PowerShell Script with Veeam Credential Access Capabilities + +PowerShell, a powerful scripting language in Windows environments, can be exploited by attackers to access and decrypt sensitive credentials, such as those stored by Veeam in MSSQL databases. Adversaries may leverage this to compromise backup data, facilitating ransomware attacks. The detection rule identifies suspicious script activity by monitoring specific database interactions and decryption attempts, flagging potential credential access threats. + +### Possible investigation steps + +- Review the PowerShell script block text associated with the alert to identify any references to "[dbo].[Credentials]" and "Veeam" or "VeeamBackup" to confirm potential credential access attempts. +- Check the event logs for the specific host where the alert was triggered to gather additional context about the process execution, including the user account involved and the script's origin. +- Investigate any recent changes or access to the MSSQL database containing Veeam credentials to determine if there were unauthorized access attempts or modifications. +- Analyze the use of "ProtectedStorage]::GetLocalString" within the script to understand if it was used to decrypt or access sensitive information. +- Correlate the alert with other security events or logs from the same host or network segment to identify any related suspicious activities or patterns that could indicate a broader attack. + +### False positive analysis + +- Routine administrative scripts that query MSSQL databases for maintenance purposes may trigger the rule. To manage this, identify and whitelist specific scripts or processes that are known to be safe and regularly executed by trusted administrators. +- Scheduled tasks or automated backup verification processes that access Veeam credentials for legitimate reasons can be mistaken for malicious activity. Exclude these tasks by specifying their unique identifiers or execution paths in the monitoring system. +- Security audits or compliance checks that involve accessing credential information for validation purposes might be flagged. Coordinate with the audit team to document these activities and create exceptions for their scripts. +- Development or testing environments where PowerShell scripts are used to simulate credential access for testing purposes can generate false positives. Implement environment-specific exclusions to prevent these from being flagged in production monitoring. +- Third-party monitoring tools that interact with Veeam credentials for health checks or performance monitoring may inadvertently trigger alerts. Work with the tool vendors to understand their access patterns and exclude them if they are verified as non-threatening. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing credential access attempts. +- Change all Veeam-related credentials and any other potentially compromised credentials stored in the MSSQL database to prevent further unauthorized access. +- Conduct a thorough review of backup integrity and ensure that no unauthorized modifications or deletions have occurred. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring for PowerShell activity and MSSQL database access to detect similar threats in the future. +- Review and update access controls and permissions for Veeam and MSSQL databases to ensure they follow the principle of least privilege.""" [[rule.threat]] diff --git a/rules/windows/credential_access_potential_lsa_memdump_via_mirrordump.toml b/rules/windows/credential_access_potential_lsa_memdump_via_mirrordump.toml index 3b9496723a6..7ad975bb7e7 100644 --- a/rules/windows/credential_access_potential_lsa_memdump_via_mirrordump.toml +++ b/rules/windows/credential_access_potential_lsa_memdump_via_mirrordump.toml @@ -2,7 +2,7 @@ creation_date = "2021/09/27" integration = ["windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -48,6 +48,40 @@ process where host.os.type == "windows" and event.code == "10" and /* call is coming from an unknown executable region */ winlog.event_data.CallTrace : "*UNKNOWN*" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Credential Access via DuplicateHandle in LSASS + +The Local Security Authority Subsystem Service (LSASS) is crucial for enforcing security policies and managing user credentials in Windows environments. Adversaries may exploit the DuplicateHandle function to access LSASS memory, bypassing traditional API calls to avoid detection. The detection rule identifies suspicious LSASS handle access attempts from unknown modules, flagging potential credential dumping activities. + +### Possible investigation steps + +- Review the event logs for the specific event code "10" to gather more details about the suspicious activity, focusing on the process name "lsass.exe" and the granted access "0x40". +- Investigate the call trace details where the event data indicates "*UNKNOWN*" to identify any unknown or suspicious modules that may have initiated the DuplicateHandle request. +- Correlate the suspicious activity with other security events or alerts on the same host to determine if there are additional indicators of compromise or related malicious activities. +- Check the process tree and parent-child relationships of the lsass.exe process to identify any unusual or unauthorized processes that may have interacted with LSASS. +- Analyze the timeline of events to understand the sequence of actions leading up to and following the alert, which may help in identifying the adversary's objectives or next steps. +- Review recent changes or updates to the system that might have introduced the unknown module or altered the behavior of legitimate processes. + +### False positive analysis + +- Legitimate software or security tools that interact with LSASS for monitoring or protection purposes may trigger this rule. Users should identify and whitelist these trusted applications to prevent unnecessary alerts. +- System management or administrative scripts that perform legitimate operations on LSASS might be flagged. Review these scripts and, if verified as safe, add them to an exception list to reduce false positives. +- Custom in-house applications that require access to LSASS for valid reasons could be mistakenly identified. Conduct a thorough review of these applications and exclude them from the rule if they are deemed non-threatening. +- Security testing or penetration testing activities may mimic malicious behavior. Coordinate with security teams to recognize these activities and temporarily adjust the rule settings during testing periods to avoid false alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes associated with the unknown executable region accessing LSASS to halt potential credential dumping activities. +- Conduct a thorough memory analysis of the affected system to identify any malicious artifacts or indicators of compromise related to the DuplicateHandle exploitation. +- Reset credentials for all accounts that may have been accessed or compromised, prioritizing high-privilege accounts. +- Review and update endpoint protection configurations to ensure they are capable of detecting and blocking similar unauthorized access attempts in the future. +- 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 enhanced monitoring and logging for LSASS and related processes to detect any future attempts to exploit the DuplicateHandle function.""" [[rule.threat]] diff --git a/rules/windows/credential_access_relay_ntlm_auth_via_http_spoolss.toml b/rules/windows/credential_access_relay_ntlm_auth_via_http_spoolss.toml index 90adf75f13c..46a3947dd1e 100644 --- a/rules/windows/credential_access_relay_ntlm_auth_via_http_spoolss.toml +++ b/rules/windows/credential_access_relay_ntlm_auth_via_http_spoolss.toml @@ -2,7 +2,7 @@ creation_date = "2022/04/30" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2024/10/31" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -62,6 +62,41 @@ process where host.os.type == "windows" and event.type == "start" and /* Access to named pipe via http */ process.args : ("http*/print/pipe/*", "http*/pipe/spoolss", "http*/pipe/srvsvc") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Local NTLM Relay via HTTP + +NTLM, a suite of Microsoft security protocols, is often targeted by adversaries for credential theft. Attackers may exploit the Windows Printer Spooler service to coerce NTLM authentication over HTTP, potentially elevating privileges. The detection rule identifies suspicious rundll32.exe executions invoking WebDAV client DLLs with specific arguments, signaling attempts to access named pipes via HTTP, indicative of NTLM relay attacks. + +### Possible investigation steps + +- Review the process execution details for rundll32.exe, focusing on the specific arguments related to davclnt.dll and DavSetCookie, to confirm the presence of suspicious WebDAV client activity. +- Investigate the network connections initiated by the rundll32.exe process to identify any HTTP requests targeting named pipes, such as those containing "/print/pipe/", "/pipe/spoolss", or "/pipe/srvsvc". +- Check the system's event logs for any related authentication attempts or failures around the time of the alert to identify potential NTLM relay activity. +- Analyze the history of the Windows Printer Spooler service on the affected host to determine if it has been recently manipulated or exploited. +- Correlate the alert with other security events or alerts from data sources like Microsoft Defender for Endpoint or Sysmon to identify any related suspicious activities or patterns. +- Assess the user account associated with the NTLM authentication attempt to determine if it has been compromised or is being used in an unauthorized manner. + +### False positive analysis + +- Legitimate administrative tasks using rundll32.exe with WebDAV client DLLs may trigger the rule. Review the context of the execution, such as the user account and the timing, to determine if it aligns with expected administrative activities. +- Automated software deployment or update processes might use similar rundll32.exe calls. Verify if the process is part of a scheduled or known deployment task and consider excluding these specific processes from the rule. +- Some third-party applications may use WebDAV for legitimate purposes, which could mimic the behavior detected by the rule. Identify these applications and create exceptions for their known processes to prevent false alerts. +- System maintenance scripts or tools that interact with network resources via HTTP might inadvertently match the rule's criteria. Ensure these scripts are documented and exclude them if they are verified as non-threatening. +- Regularly review and update the exclusion list to accommodate changes in legitimate software behavior, ensuring that only verified false positives are excluded to maintain the rule's effectiveness. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious rundll32.exe processes identified in the alert to stop ongoing malicious activity. +- Conduct a thorough review of the affected system's event logs and network traffic to identify any additional indicators of compromise or related malicious activity. +- Reset credentials for any accounts that may have been exposed or compromised during the attack to prevent unauthorized access. +- Apply the latest security patches and updates to the Windows Printer Spooler service and related components to mitigate known vulnerabilities. +- Implement network segmentation to limit the exposure of critical services and reduce the risk of similar attacks in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts are undertaken.""" [[rule.threat]] diff --git a/rules/windows/credential_access_saved_creds_vault_winlog.toml b/rules/windows/credential_access_saved_creds_vault_winlog.toml index 385a6037a93..694a6b35566 100644 --- a/rules/windows/credential_access_saved_creds_vault_winlog.toml +++ b/rules/windows/credential_access_saved_creds_vault_winlog.toml @@ -2,7 +2,7 @@ creation_date = "2022/08/30" integration = ["system", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -51,6 +51,41 @@ sequence by winlog.computer_name, winlog.process.pid with maxspan=1s not winlog.event_data.SubjectLogonId : "0x3e7" and not winlog.event_data.Resource : "http://localhost/"] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Multiple Vault Web Credentials Read + +Windows Credential Manager stores credentials for web logins, apps, and networks, facilitating seamless user access. Adversaries exploit this by extracting stored credentials, potentially aiding lateral movement within networks. The detection rule identifies suspicious activity by flagging consecutive credential reads from the same process, excluding benign actions like localhost access, thus highlighting potential credential dumping attempts. + +### Possible investigation steps + +- Review the process associated with the flagged PID to determine if it is a legitimate application or potentially malicious. Check for known software or unusual executables. +- Investigate the source and destination of the web credentials read by examining the winlog.event_data.Resource field to identify any suspicious or unexpected URLs. +- Check the winlog.computer_name to identify the affected system and assess whether it is a high-value target or has been involved in previous suspicious activities. +- Analyze the timeline of events around the alert to identify any preceding or subsequent suspicious activities that may indicate a broader attack pattern. +- Verify the user context by examining the winlog.event_data.SubjectLogonId to ensure the activity was not performed by a privileged or administrative account without proper authorization. +- Cross-reference the event with other security logs or alerts to identify any correlated activities that might suggest a coordinated attack or compromise. + +### False positive analysis + +- Localhost access is a common false positive since the rule excludes localhost reads. Ensure that any legitimate applications accessing credentials via localhost are properly whitelisted to prevent unnecessary alerts. +- Automated scripts or applications that frequently access web credentials for legitimate purposes may trigger the rule. Identify these processes and create exceptions for them to reduce noise. +- System maintenance or updates might involve credential reads that are benign. Coordinate with IT teams to schedule these activities and temporarily adjust the rule sensitivity or add exceptions during these periods. +- Security tools or monitoring software that perform regular checks on credential integrity could be flagged. Verify these tools and add them to an exception list if they are part of the organization's security infrastructure. +- User behavior such as frequent password changes or credential updates might cause alerts. Educate users on the impact of their actions and consider adjusting the rule to accommodate expected behavior patterns. + +### Response and remediation + +- Isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate the suspicious process identified by the process ID (pid) involved in the credential reads to stop further credential access. +- Conduct a thorough review of the affected system for any additional signs of compromise, such as unauthorized user accounts or scheduled tasks. +- Change passwords for any accounts that may have been exposed, focusing on those stored in the Windows Credential Manager. +- Implement network segmentation to limit access to critical systems and data, reducing the risk of lateral movement. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach. +- Enhance monitoring and logging on the affected system and similar endpoints to detect any future attempts at credential dumping or unauthorized access.""" [[rule.threat]] diff --git a/rules/windows/credential_access_saved_creds_vaultcmd.toml b/rules/windows/credential_access_saved_creds_vaultcmd.toml index 2e9c04c2ec9..e23cf5e7953 100644 --- a/rules/windows/credential_access_saved_creds_vaultcmd.toml +++ b/rules/windows/credential_access_saved_creds_vaultcmd.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/19" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "system", "crowdstrike"] maturity = "production" -updated_date = "2024/11/02" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -57,6 +57,40 @@ process where host.os.type == "windows" and event.type == "start" and (?process.pe.original_file_name:"vaultcmd.exe" or process.name:"vaultcmd.exe") and process.args:"/list*" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Searching for Saved Credentials via VaultCmd + +Windows Credential Manager stores credentials for websites, applications, and networks. Adversaries exploit this by using VaultCmd to list or extract these credentials, aiding in lateral movement. The detection rule identifies such abuse by monitoring the execution of VaultCmd with specific arguments, flagging potential credential access attempts. This helps in early detection of unauthorized credential access activities. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of vaultcmd.exe with the /list* argument, as this indicates an attempt to list saved credentials. +- Check the user account associated with the process execution to determine if the activity aligns with expected behavior for that user or if it appears suspicious. +- Investigate the parent process of vaultcmd.exe to understand how it was initiated and whether it was triggered by a legitimate application or script. +- Examine recent login activity and network connections from the host to identify any signs of lateral movement or unauthorized access attempts. +- Correlate this event with other security alerts or logs from the same host or user to identify potential patterns of malicious behavior. +- Review endpoint security logs from tools like Microsoft Defender for Endpoint or Crowdstrike for additional context or corroborating evidence of credential access attempts. + +### False positive analysis + +- Routine administrative tasks using VaultCmd for legitimate credential management can trigger alerts. To manage this, create exceptions for known administrative accounts or scheduled tasks that regularly use VaultCmd with the /list argument. +- Security software or system management tools that perform regular audits of stored credentials might also cause false positives. Identify these tools and exclude their processes from triggering the rule. +- Automated scripts or backup processes that access Credential Manager for legitimate purposes may be flagged. Review these scripts and whitelist them if they are verified as non-threatening. +- User-initiated credential management activities, such as listing credentials for personal use, can be mistaken for malicious behavior. Educate users on the implications of using VaultCmd and consider excluding specific user accounts if necessary. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement and further credential access. +- Terminate any suspicious processes associated with VaultCmd.exe to halt unauthorized credential dumping activities. +- Conduct a thorough review of the affected system's event logs and process execution history to identify any additional malicious activities or compromised accounts. +- Reset passwords for any accounts that may have been exposed or accessed through the Credential Manager to mitigate unauthorized access. +- Implement enhanced monitoring on the affected system and similar endpoints for any further attempts to use VaultCmd.exe or other credential dumping tools. +- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the scope of the breach. +- Review and update endpoint protection configurations to ensure that similar threats are detected and blocked in the future, leveraging threat intelligence and MITRE ATT&CK framework insights.""" [[rule.threat]] diff --git a/rules/windows/credential_access_suspicious_lsass_access_generic.toml b/rules/windows/credential_access_suspicious_lsass_access_generic.toml index 3d128e0eda8..a54cf39d632 100644 --- a/rules/windows/credential_access_suspicious_lsass_access_generic.toml +++ b/rules/windows/credential_access_suspicious_lsass_access_generic.toml @@ -2,7 +2,7 @@ creation_date = "2023/01/22" integration = ["windows"] maturity = "production" -updated_date = "2024/10/21" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -73,6 +73,41 @@ process where host.os.type == "windows" and event.code == "10" and ) and not winlog.event_data.CallTrace : ("*mpengine.dll*", "*appresolver.dll*", "*sysmain.dll*") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Lsass Process Access + +The Local Security Authority Subsystem Service (LSASS) is crucial for enforcing security policies and managing user logins in Windows environments. Adversaries often target LSASS to extract credentials, enabling unauthorized access. The detection rule identifies unusual access attempts to LSASS by filtering out legitimate processes and access patterns, focusing on anomalies that suggest credential dumping activities. + +### Possible investigation steps + +- Review the process details that triggered the alert, focusing on the process name and executable path to determine if it is a known legitimate application or potentially malicious. +- Examine the GrantedAccess value in the event data to understand the level of access attempted on the LSASS process and compare it against typical access patterns. +- Investigate the parent process of the suspicious process to identify how it was spawned and assess if it is part of a legitimate workflow or an anomaly. +- Check the CallTrace field for any unusual or suspicious DLLs that might indicate malicious activity or exploitation attempts. +- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or patterns, such as network connections or file modifications. +- Verify the host's security posture, including the status of antivirus or endpoint protection solutions, to ensure they are functioning correctly and have not been tampered with. + +### False positive analysis + +- Legitimate security tools like Sysinternals Process Explorer and Process Monitor can trigger false positives. Exclude these by adding their process names to the exception list. +- Windows Defender and other antivirus software may access LSASS for legitimate scanning purposes. Exclude their executable paths from the detection rule to prevent false alerts. +- System processes such as csrss.exe, lsm.exe, and wmiprvse.exe are known to access LSASS as part of normal operations. Ensure these are included in the process executable exceptions to avoid unnecessary alerts. +- Software updates and installers, like those from Cisco AnyConnect or Oracle, may access LSASS during legitimate operations. Add these specific paths to the exclusion list to reduce false positives. +- Custom enterprise applications that interact with LSASS for authentication purposes should be identified and their paths added to the exceptions to prevent disruption in monitoring. + +### Response and remediation + +- Isolate the affected system from the network immediately to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified in the alert that are attempting to access the LSASS process, ensuring that legitimate processes are not disrupted. +- Conduct a memory dump analysis of the affected system to identify any malicious tools or scripts used for credential dumping, focusing on the LSASS process. +- Change all potentially compromised credentials, especially those with administrative privileges, to prevent unauthorized access using stolen credentials. +- Apply patches and updates to the affected system to address any vulnerabilities that may have been exploited by the adversary. +- Monitor the network for any signs of further suspicious activity or attempts to access LSASS on other systems, using enhanced logging and alerting mechanisms. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/credential_access_suspicious_lsass_access_memdump.toml b/rules/windows/credential_access_suspicious_lsass_access_memdump.toml index b4b6624514c..fbb03c918e6 100644 --- a/rules/windows/credential_access_suspicious_lsass_access_memdump.toml +++ b/rules/windows/credential_access_suspicious_lsass_access_memdump.toml @@ -2,7 +2,7 @@ creation_date = "2021/10/07" integration = ["windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -58,6 +58,41 @@ process where host.os.type == "windows" and event.code == "10" and "?:\\Windows\\System32\\WerFaultSecure.exe" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Credential Access via LSASS Memory Dump + +LSASS (Local Security Authority Subsystem Service) is crucial for managing Windows security policies and storing sensitive data like user credentials. Adversaries exploit this by using tools that leverage MiniDumpWriteDump from libraries like DBGHelp.dll to extract credentials. The detection rule identifies suspicious LSASS access by monitoring for these libraries in call traces, excluding legitimate crash handlers, thus flagging potential credential theft attempts. + +### Possible investigation steps + +- Review the process details associated with the alert, focusing on the process name, executable path, and parent process to determine if the process accessing LSASS is legitimate or suspicious. +- Examine the call trace details to confirm the presence of DBGHelp.dll or DBGCore.dll, which are indicative of potential credential dumping attempts. +- Check for any recent crash reports or legitimate use of WerFault.exe, WerFaultSecure.exe, or similar processes that might explain the LSASS access as a non-malicious event. +- Investigate the user account context under which the suspicious process is running to assess if it aligns with expected behavior or if it indicates potential compromise. +- Correlate the event with other security logs or alerts to identify any related suspicious activities, such as unauthorized access attempts or lateral movement within the network. +- Assess the risk and impact by determining if any sensitive credentials could have been exposed, and consider isolating the affected system to prevent further compromise. + +### False positive analysis + +- Legitimate crash handlers like WerFault.exe may access LSASS during system crashes. To prevent these from being flagged, ensure that the rule excludes processes such as WerFault.exe, WerFaultSecure.exe, and their SysWOW64 counterparts. +- Debugging tools used by developers or IT administrators might trigger this rule if they access LSASS for legitimate purposes. Consider creating exceptions for known and trusted debugging tools within your environment. +- Security software or endpoint protection solutions may perform similar actions as part of their normal operations. Verify with your security vendor and exclude these processes if they are confirmed to be benign. +- Automated system diagnostics or maintenance scripts that interact with LSASS for health checks could be misidentified. Review and whitelist these scripts if they are part of routine system management tasks. +- Ensure that any custom or third-party applications that require access to LSASS for legitimate reasons are documented and excluded from the rule to avoid unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further credential access or lateral movement by the adversary. +- Terminate any suspicious processes that are accessing the LSASS memory, especially those involving DBGHelp.dll or DBGCore.dll, to stop the credential dumping activity. +- Conduct a thorough review of the affected system's security logs to identify any unauthorized access or changes, focusing on event code "10" and call traces involving LSASS. +- Change passwords for all accounts that were active on the affected system, prioritizing high-privilege accounts, to mitigate the risk of compromised credentials being used. +- Restore the affected system from a known good backup to ensure that any malicious changes or tools are removed. +- 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 enhanced monitoring and alerting for similar suspicious activities, focusing on LSASS access and the use of MiniDumpWriteDump, to improve detection and response capabilities.""" [[rule.threat]] diff --git a/rules/windows/credential_access_suspicious_lsass_access_via_snapshot.toml b/rules/windows/credential_access_suspicious_lsass_access_via_snapshot.toml index 157283aefb3..948c585db92 100644 --- a/rules/windows/credential_access_suspicious_lsass_access_via_snapshot.toml +++ b/rules/windows/credential_access_suspicious_lsass_access_via_snapshot.toml @@ -2,7 +2,7 @@ creation_date = "2021/10/14" integration = ["windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -46,6 +46,40 @@ event.category:process and host.os.type:windows and event.code:10 and "c:\\Windows\\system32\\lsass.exe" or "c:\\Windows\\System32\\lsass.exe") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 LSASS Memory Dump via PssCaptureSnapShot + +PssCaptureSnapShot is a Windows feature used for capturing process snapshots, aiding in diagnostics and debugging. Adversaries exploit this to access LSASS memory, aiming to extract credentials. The detection rule identifies suspicious behavior by monitoring for repeated access to LSASS by the same process, targeting different instances, which may indicate an evasion attempt to dump credentials stealthily. + +### Possible investigation steps + +- Review the event logs for the specific event code 10 to gather details about the process that accessed the LSASS handle, including the process name, process ID, and the time of access. +- Check the process execution history on the host to determine if the process accessing LSASS is legitimate or potentially malicious. Look for any unusual or unexpected processes that might have been executed around the time of the alert. +- Investigate the parent process of the suspicious process to understand how it was initiated and whether it was spawned by a legitimate application or a known malicious process. +- Analyze the network activity of the host around the time of the alert to identify any suspicious outbound connections that might indicate data exfiltration attempts. +- Correlate the alert with other security events or alerts from the same host or user account to identify any patterns or additional indicators of compromise. +- Verify the integrity and security posture of the host by checking for any unauthorized changes to system files or configurations, especially those related to security settings. + +### False positive analysis + +- Legitimate diagnostic tools or software that utilize PssCaptureSnapShot for debugging purposes may trigger this rule. Users should identify and whitelist these trusted applications to prevent false positives. +- System administrators or security tools performing regular health checks on LSASS might access LSASS memory in a non-malicious manner. Exclude these known processes by creating exceptions based on their process names or hashes. +- Automated scripts or maintenance tasks that interact with LSASS for legitimate reasons could be flagged. Review and document these tasks, then configure the rule to ignore these specific activities. +- Security software updates or patches that temporarily access LSASS for validation or configuration purposes may cause alerts. Monitor update schedules and adjust the rule to accommodate these temporary accesses. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified as accessing LSASS memory using PssCaptureSnapShot to halt potential credential dumping activities. +- Conduct a thorough review of the affected system's event logs, focusing on event code 10, to identify any additional instances of suspicious LSASS access and determine the scope of the compromise. +- Change all potentially compromised credentials, especially those with administrative privileges, to mitigate the risk of unauthorized access using dumped credentials. +- Apply the latest security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Enhance monitoring and detection capabilities by ensuring that similar suspicious activities are logged and alerted on, using the specific query fields and threat indicators identified in this alert.""" [[rule.threat]] diff --git a/rules/windows/credential_access_veeam_backup_dll_imageload.toml b/rules/windows/credential_access_veeam_backup_dll_imageload.toml index c22dbdbccee..9cd0afc27bc 100644 --- a/rules/windows/credential_access_veeam_backup_dll_imageload.toml +++ b/rules/windows/credential_access_veeam_backup_dll_imageload.toml @@ -2,7 +2,7 @@ creation_date = "2024/03/14" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -38,6 +38,40 @@ library where host.os.type == "windows" and event.action == "load" and process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Veeam Backup Library Loaded by Unusual Process + +Veeam Backup software is crucial for data protection, enabling secure backup and recovery operations. However, adversaries may exploit its credential storage by loading the Veeam.Backup.Common.dll library through unauthorized processes like PowerShell, aiming to decrypt and misuse credentials. The detection rule identifies such anomalies by flagging untrusted or unsigned processes loading this library, indicating potential credential access attempts. + +### Possible investigation steps + +- Review the process details to identify the untrusted or unsigned process that loaded the Veeam.Backup.Common.dll library, focusing on the process.name field to determine if it is PowerShell or another suspicious executable. +- Check the process execution history and command line arguments to understand the context of the process activity, especially if the process.name is powershell.exe, pwsh.exe, or powershell_ise.exe. +- Investigate the source and integrity of the process by examining the process.code_signature fields to determine if the process is expected or potentially malicious. +- Analyze the timeline of events on the host to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern or lateral movement. +- Correlate the alert with other security events or logs from the same host or network to identify any related indicators of compromise or additional affected systems. + +### False positive analysis + +- Legitimate administrative scripts or automation tasks using PowerShell may trigger the rule. Review the script's purpose and source, and if verified as safe, consider adding an exception for the specific script or process. +- Scheduled tasks or maintenance operations that involve Veeam Backup operations might load the library through unsigned processes. Validate these tasks and exclude them if they are part of routine, secure operations. +- Custom or third-party backup solutions that integrate with Veeam may load the library in a non-standard way. Confirm the legitimacy of these solutions and whitelist them to prevent unnecessary alerts. +- Development or testing environments where Veeam components are frequently loaded by various processes for testing purposes can generate false positives. Implement process exclusions for these environments to reduce noise. +- Ensure that any exclusions or exceptions are documented and reviewed regularly to maintain security posture and adapt to any changes in the environment. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified as loading the Veeam.Backup.Common.dll library, especially those that are unsigned or involve PowerShell. +- Conduct a thorough review of the system's event logs and process history to identify any additional unauthorized access or actions taken by the adversary. +- Change all credentials stored within the Veeam Backup software and any other potentially compromised accounts to prevent misuse. +- Restore any affected systems or data from a known good backup to ensure integrity and availability. +- 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 enhanced monitoring and alerting for similar activities, focusing on unauthorized process executions and DLL loads, to improve early detection of future threats.""" [[rule.threat]] diff --git a/rules/windows/credential_access_veeam_commands.toml b/rules/windows/credential_access_veeam_commands.toml index 9cfdf005e9b..c78ad2b384f 100644 --- a/rules/windows/credential_access_veeam_commands.toml +++ b/rules/windows/credential_access_veeam_commands.toml @@ -2,7 +2,7 @@ creation_date = "2024/03/14" integration = ["windows", "endpoint", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2024/11/02" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -56,6 +56,41 @@ process where host.os.type == "windows" and event.type == "start" and ) and process.args : "*[VeeamBackup].[dbo].[Credentials]*" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Veeam Credential Access Command + +Veeam credentials stored in MSSQL databases are crucial for managing backup operations. Attackers may exploit tools like `sqlcmd.exe` or PowerShell commands to access and decrypt these credentials, potentially leading to data breaches or ransomware attacks. The detection rule identifies suspicious command executions targeting Veeam credentials, focusing on specific processes and arguments, to alert analysts of potential credential access attempts. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of sqlcmd.exe or PowerShell commands like Invoke-Sqlcmd, focusing on the process.name and process.args fields. +- Examine the command line arguments for any references to [VeeamBackup].[dbo].[Credentials] to determine if there was an attempt to access or decrypt Veeam credentials. +- Check the user account associated with the process execution to assess if it is a legitimate user or potentially compromised. +- Investigate the source host for any signs of unauthorized access or suspicious activity, such as unusual login times or failed login attempts. +- Correlate the alert with other security events or logs from data sources like Microsoft Defender for Endpoint or Sysmon to identify any related malicious activities or patterns. +- Assess the risk and impact by determining if any Veeam credentials were successfully accessed or exfiltrated, and evaluate the potential for data breaches or ransomware attacks. + +### False positive analysis + +- Routine database maintenance tasks may trigger the rule if they involve accessing Veeam credentials for legitimate purposes. To manage this, identify and document regular maintenance schedules and exclude these activities from triggering alerts. +- Automated scripts used for backup verification or testing might use similar commands. Review and whitelist these scripts by their process names or specific arguments to prevent unnecessary alerts. +- Internal security audits or compliance checks that involve credential access could be mistaken for malicious activity. Coordinate with audit teams to schedule these activities and create exceptions for known audit processes. +- Development or testing environments where Veeam credentials are accessed for non-production purposes can generate false positives. Implement environment-specific exclusions to differentiate between production and non-production activities. +- Legitimate use of PowerShell commands for database management by authorized personnel may be flagged. Maintain a list of authorized users and their typical command patterns to refine the detection rule and reduce false positives. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the alert, such as `sqlcmd.exe` or PowerShell commands accessing Veeam credentials. +- Change all Veeam-related credentials stored in the MSSQL database to prevent further unauthorized access using compromised credentials. +- Conduct a thorough review of recent backup operations and logs to identify any unauthorized access or modifications. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are compromised. +- Implement enhanced monitoring on systems storing Veeam credentials to detect similar suspicious activities in the future. +- Review and update access controls and permissions for MSSQL databases to ensure only authorized personnel have access to Veeam credentials.""" [[rule.threat]] diff --git a/rules/windows/credential_access_via_snapshot_lsass_clone_creation.toml b/rules/windows/credential_access_via_snapshot_lsass_clone_creation.toml index 84213f9d53c..96278b34ea3 100644 --- a/rules/windows/credential_access_via_snapshot_lsass_clone_creation.toml +++ b/rules/windows/credential_access_via_snapshot_lsass_clone_creation.toml @@ -2,7 +2,7 @@ creation_date = "2021/11/27" integration = ["windows", "system"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -50,6 +50,41 @@ process where host.os.type == "windows" and event.code:"4688" and process.executable : "?:\\Windows\\System32\\lsass.exe" and process.parent.executable : "?:\\Windows\\System32\\lsass.exe" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 LSASS Clone Creation via PssCaptureSnapShot + +PssCaptureSnapShot is a Windows API used for creating snapshots of processes, often for debugging. Adversaries exploit this to clone the LSASS process, aiming to extract credentials without detection. The detection rule identifies suspicious LSASS clones by monitoring process creation events where both the process and its parent are LSASS, signaling potential credential dumping attempts. + +### Possible investigation steps + +- Review the process creation event logs for the specific event code 4688 to confirm the creation of an LSASS process clone. Verify that both the process and its parent have the executable path "?:\\Windows\\System32\\lsass.exe". +- Check the timeline of events to determine if there are any preceding or subsequent suspicious activities related to the LSASS process, such as unusual access patterns or modifications. +- Investigate the user account and privileges associated with the process creation event to assess if the account has legitimate reasons to interact with LSASS or if it might be compromised. +- Analyze network activity from the host to identify any potential data exfiltration attempts or connections to known malicious IP addresses following the LSASS clone creation. +- Correlate this event with other security alerts or logs from the same host to identify if this is part of a broader attack pattern or isolated incident. +- Examine the host for any signs of malware or tools commonly used for credential dumping, such as Mimikatz, that might have been used in conjunction with the LSASS clone creation. + +### False positive analysis + +- Legitimate security software or system management tools may create LSASS process snapshots for monitoring or debugging purposes. Identify these tools and create exceptions for their process creation events to avoid false positives. +- System administrators or IT personnel might use authorized scripts or tools that interact with LSASS for legitimate reasons. Verify these activities and whitelist the associated processes to prevent unnecessary alerts. +- During system updates or patches, certain processes might temporarily mimic suspicious behavior. Monitor these updates and temporarily adjust detection rules to accommodate expected changes in process behavior. +- Some enterprise environments may have custom applications that interact with LSASS for performance monitoring. Document these applications and exclude their process creation events from triggering alerts. +- Regularly review and update the list of known benign processes and tools that interact with LSASS to ensure that the detection rule remains effective without generating excessive false positives. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further credential access or lateral movement by the adversary. +- Terminate any suspicious LSASS clone processes identified by the detection rule to halt ongoing credential dumping activities. +- Conduct a thorough memory analysis of the affected system to identify any additional malicious activities or tools used by the adversary. +- Change all potentially compromised credentials, especially those with administrative privileges, to mitigate the risk of unauthorized access. +- Review and enhance endpoint security configurations to ensure that LSASS process memory is protected from unauthorized access, such as enabling Credential Guard if applicable. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach. +- Implement additional monitoring and alerting for similar suspicious activities, focusing on process creation events involving LSASS, to improve early detection of future attempts.""" [[rule.threat]] diff --git a/rules/windows/credential_access_wbadmin_ntds.toml b/rules/windows/credential_access_wbadmin_ntds.toml index efc78263512..600faf981a8 100644 --- a/rules/windows/credential_access_wbadmin_ntds.toml +++ b/rules/windows/credential_access_wbadmin_ntds.toml @@ -2,7 +2,7 @@ creation_date = "2024/06/05" integration = ["windows", "endpoint", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2024/11/02" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -54,6 +54,40 @@ process where host.os.type == "windows" and event.type == "start" and (process.name : "wbadmin.exe" or ?process.pe.original_file_name : "wbadmin.exe") and process.args : "recovery" and process.command_line : "*ntds.dit*" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 NTDS Dump via Wbadmin + +Wbadmin is a Windows utility for backup and recovery, often used by administrators to safeguard critical data. However, adversaries with sufficient privileges, such as those in the Backup Operators group, can exploit it to access the NTDS.dit file on domain controllers, which contains sensitive credential information. The detection rule identifies suspicious use of wbadmin by monitoring for its execution with specific arguments related to NTDS.dit, helping to flag potential credential dumping activities. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of wbadmin.exe with the specific arguments related to NTDS.dit, as indicated by the process.command_line field. +- Check the user account associated with the process execution to determine if it belongs to a privileged group such as Backup Operators, which could indicate potential misuse of privileges. +- Investigate the source host identified by host.os.type to determine if it is a domain controller, as this would be a critical factor in assessing the risk of the activity. +- Correlate the event with other security logs or alerts from data sources like Microsoft Defender for Endpoint or Sysmon to identify any related suspicious activities or patterns. +- Examine recent changes or access attempts to the NTDS.dit file on the domain controller to identify any unauthorized access or modifications. +- Assess the risk score and severity level to prioritize the investigation and determine if immediate response actions are necessary. + +### False positive analysis + +- Scheduled backups by legitimate IT staff can trigger the rule. Verify the identity and role of the user executing wbadmin and consider excluding known backup schedules from detection. +- Automated recovery processes in disaster recovery plans might use wbadmin with similar arguments. Review and whitelist these processes if they are part of approved recovery procedures. +- Security audits or compliance checks may involve accessing NTDS.dit for validation purposes. Confirm the legitimacy of these activities and exclude them if they are part of regular audits. +- Test environments that mimic production setups might execute similar commands. Ensure these environments are properly documented and excluded from detection if they are used for testing purposes. + +### Response and remediation + +- Immediately isolate the affected domain controller from the network to prevent further unauthorized access or data exfiltration. +- Revoke any suspicious or unauthorized accounts from the Backup Operators group and review all accounts with elevated privileges for legitimacy. +- Conduct a thorough review of recent backup and recovery operations on the affected domain controller to identify any unauthorized access or data manipulation. +- Change all domain administrator and service account passwords to mitigate potential credential compromise. +- Restore the NTDS.dit file from a known good backup if any unauthorized modifications are detected. +- Implement enhanced monitoring and logging for wbadmin.exe usage across all domain controllers to detect future unauthorized access attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_cve_2020_0601.toml b/rules/windows/defense_evasion_cve_2020_0601.toml index c5462af0a0c..8b967a1007c 100644 --- a/rules/windows/defense_evasion_cve_2020_0601.toml +++ b/rules/windows/defense_evasion_cve_2020_0601.toml @@ -2,7 +2,7 @@ creation_date = "2020/03/19" integration = ["windows", "system"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -34,6 +34,40 @@ type = "query" query = ''' event.provider:"Microsoft-Windows-Audit-CVE" and message:"[CVE-2020-0601]" and host.os.type:windows ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Windows CryptoAPI Spoofing Vulnerability (CVE-2020-0601 - CurveBall) + +The Windows CryptoAPI is crucial for validating ECC certificates, ensuring secure communications and software authenticity. CVE-2020-0601, known as CurveBall, exposes a flaw where attackers can craft fake certificates, misleading systems into trusting malicious software. The detection rule identifies exploitation attempts by monitoring specific event logs and messages linked to this vulnerability, focusing on defense evasion tactics. + +### Possible investigation steps + +- Review the event logs filtered by event.provider:"Microsoft-Windows-Audit-CVE" and message:"[CVE-2020-0601]" to identify the specific instances of the vulnerability being triggered. +- Analyze the host.os.type:windows field to determine which Windows systems are affected and prioritize them based on their criticality and exposure. +- Examine the details of the spoofed certificates involved in the alert to understand the scope and potential impact of the attack. +- Investigate any associated processes or executables that were signed with the spoofed certificates to assess if malicious software was executed. +- Check for any recent changes or updates to Crypt32.dll on the affected systems to ensure they are patched against CVE-2020-0601. +- Correlate the findings with other security events or alerts to identify any patterns or additional indicators of compromise related to defense evasion tactics. + +### False positive analysis + +- Legitimate software updates or installations may trigger alerts if they use ECC certificates similar to those exploited in the vulnerability. Users can create exceptions for known trusted software vendors to reduce noise. +- Internal testing environments that simulate certificate validation processes might generate false positives. Exclude these environments from monitoring or adjust the rule to ignore specific test-related events. +- Security tools or scripts that perform certificate validation checks could inadvertently match the detection criteria. Identify and whitelist these tools to prevent unnecessary alerts. +- Regular system maintenance activities involving certificate updates might be flagged. Schedule these activities during known maintenance windows and temporarily adjust monitoring rules to avoid false positives. + +### Response and remediation + +- Immediately isolate affected systems from the network to prevent further exploitation or spread of malicious software. +- Revoke any certificates identified as spoofed or compromised and update the certificate trust list to prevent future misuse. +- Apply the latest security patches from Microsoft to all affected systems to address the CVE-2020-0601 vulnerability. +- Conduct a thorough scan of the isolated systems using updated antivirus and endpoint detection tools to identify and remove any malicious software. +- Review and update endpoint protection configurations to ensure they are set to detect and block similar spoofing attempts. +- Escalate the incident to the security operations center (SOC) for further analysis and to determine if additional systems may be affected. +- Implement enhanced monitoring for signs of defense evasion tactics, focusing on event logs and messages related to certificate validation processes.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_disable_nla.toml b/rules/windows/defense_evasion_disable_nla.toml index 817b3ffbd14..15c618a2f52 100644 --- a/rules/windows/defense_evasion_disable_nla.toml +++ b/rules/windows/defense_evasion_disable_nla.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/25" integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -48,6 +48,39 @@ registry where host.os.type == "windows" and event.action != "deletion" and regi "MACHINE\\SYSTEM\\*ControlSet*\\Control\\Terminal Server\\WinStations\\RDP-Tcp\\UserAuthentication" ) and registry.data.strings : ("0", "0x00000000") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Network-Level Authentication (NLA) Disabled + +Network-Level Authentication (NLA) enhances security for Remote Desktop Protocol (RDP) by requiring user authentication before establishing a session. Adversaries may disable NLA to exploit vulnerabilities at the Windows sign-in screen, bypassing authentication for persistence tactics. The detection rule identifies registry changes that disable NLA, signaling potential unauthorized access attempts. + +### Possible investigation steps + +- Review the registry event logs to confirm the modification of the UserAuthentication value in the specified registry paths, ensuring the change was not part of a legitimate administrative action. +- Identify the user account and process responsible for the registry modification by examining the event logs for associated user and process information. +- Check for any recent Remote Desktop Protocol (RDP) connection attempts or sessions on the affected host to determine if unauthorized access was achieved following the NLA disablement. +- Investigate the timeline of the registry change to correlate with any other suspicious activities or alerts on the host, such as the execution of unusual processes or network connections. +- Assess the host for signs of persistence mechanisms, particularly those leveraging Accessibility Features like Sticky Keys, which may have been enabled following the NLA disablement. +- Evaluate the security posture of the affected system, including patch levels and existing security controls, to identify potential vulnerabilities that could have been exploited. + +### False positive analysis + +- Administrative changes to RDP settings can trigger false positives when IT personnel intentionally modify registry settings for legitimate purposes. To handle this, create exceptions for known administrative activities by documenting and excluding these specific registry changes from alerts. +- Software updates or installations that modify RDP settings might be flagged as false positives. To mitigate this, maintain a list of trusted software and their expected registry changes, and configure the detection system to ignore these during update windows. +- Automated scripts or management tools that adjust RDP configurations for compliance or performance reasons can also cause false positives. Identify these tools and their expected behavior, then set up exclusions for their registry modifications to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Re-enable Network-Level Authentication (NLA) on the affected system by modifying the registry value back to its secure state, ensuring that "UserAuthentication" is set to "1" or "0x00000001". +- Conduct a thorough review of recent user activity and system logs to identify any unauthorized access or changes made during the period NLA was disabled. +- Reset passwords for all accounts that have accessed the affected system to mitigate potential credential compromise. +- 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 enhanced monitoring on the affected system and similar endpoints to detect any further attempts to disable NLA or other suspicious activities. +- Review and update endpoint security policies to ensure that registry changes related to NLA are monitored and alerts are generated for any unauthorized modifications.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_dns_over_https_enabled.toml b/rules/windows/defense_evasion_dns_over_https_enabled.toml index 9bb21c0aa79..6d5021af34f 100644 --- a/rules/windows/defense_evasion_dns_over_https_enabled.toml +++ b/rules/windows/defense_evasion_dns_over_https_enabled.toml @@ -2,7 +2,7 @@ creation_date = "2021/07/22" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -48,6 +48,39 @@ registry where host.os.type == "windows" and event.type == "change" and (registry.path : "*\\SOFTWARE\\Policies\\Mozilla\\Firefox\\DNSOverHTTPS" and registry.data.strings : ("1", "0x00000001")) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 DNS-over-HTTPS Enabled via Registry + +DNS-over-HTTPS (DoH) encrypts DNS queries to enhance privacy and security, preventing eavesdropping and manipulation. However, adversaries can exploit DoH to conceal malicious activities, such as data exfiltration, by bypassing traditional DNS monitoring. The detection rule identifies registry changes enabling DoH in browsers like Edge, Chrome, and Firefox, signaling potential misuse for defense evasion. + +### Possible investigation steps + +- Review the registry path and data values from the alert to determine which browser and setting were modified. Check if the change aligns with known user activity or policy. +- Investigate the user account associated with the registry change to assess if the activity is expected or if the account has a history of suspicious behavior. +- Examine recent network traffic from the host to identify any unusual or unauthorized DNS queries that could indicate data exfiltration or other malicious activities. +- Check for any other recent registry changes or system modifications on the host that might suggest further attempts at defense evasion or persistence. +- Correlate the alert with other security events or logs from the same host or user to identify patterns or additional indicators of compromise. + +### False positive analysis + +- Legitimate software updates or installations may enable DNS-over-HTTPS settings in browsers. Monitor software update schedules and correlate registry changes with known update events to identify benign changes. +- Organizational policies might require DNS-over-HTTPS for privacy compliance. Document these policies and create exceptions in the detection rule for systems where this is a known requirement. +- User-initiated privacy settings changes can trigger the rule. Educate users on the implications of enabling DNS-over-HTTPS and establish a process for them to report intentional changes, allowing for exclusion of these events. +- Security tools or privacy-focused applications may enable DNS-over-HTTPS as part of their functionality. Identify these tools within the organization and adjust the detection rule to exclude registry changes associated with their operation. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential data exfiltration or further malicious activity. +- Review and revert any unauthorized registry changes related to DNS-over-HTTPS settings in Edge, Chrome, and Firefox to restore standard DNS monitoring capabilities. +- Conduct a thorough scan of the affected system using updated antivirus and endpoint detection tools to identify and remove any malicious software or scripts. +- Analyze network traffic logs to identify any unusual or unauthorized DNS queries or data transfers that may have occurred during the period of DoH activation. +- 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 enhanced monitoring for registry changes related to DNS settings across the organization to detect similar threats in the future. +- Review and update security policies to ensure that DNS-over-HTTPS is only enabled through approved channels and for legitimate purposes, reducing the risk of misuse.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_dotnet_compiler_parent_process.toml b/rules/windows/defense_evasion_dotnet_compiler_parent_process.toml index f0b273d90e7..dc3a7a6f4c6 100644 --- a/rules/windows/defense_evasion_dotnet_compiler_parent_process.toml +++ b/rules/windows/defense_evasion_dotnet_compiler_parent_process.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/21" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2024/10/31" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -52,6 +52,41 @@ process where host.os.type == "windows" and event.type == "start" and process.name : ("csc.exe", "vbc.exe") and process.parent.name : ("wscript.exe", "mshta.exe", "cscript.exe", "wmic.exe", "svchost.exe", "rundll32.exe", "cmstp.exe", "regsvr32.exe") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious .NET Code Compilation + +.NET compilers like `csc.exe` and `vbc.exe` are integral to compiling C# and VB.NET code, respectively, in Windows environments. Adversaries exploit these compilers by executing them with unusual parent processes, such as scripting engines or system utilities, to compile malicious code stealthily. The detection rule identifies such anomalies by monitoring compiler executions initiated by suspicious parent processes, signaling potential evasion or execution tactics. + +### Possible investigation steps + +- Review the process tree to understand the relationship between the suspicious parent process (e.g., wscript.exe, mshta.exe) and the .NET compiler process (csc.exe or vbc.exe) to determine if the execution flow is typical or anomalous. +- Examine the command-line arguments used by the .NET compiler process to identify any potentially malicious code or scripts being compiled. +- Check the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates potential compromise or misuse. +- Investigate the source and integrity of the parent process executable to ensure it has not been tampered with or replaced by a malicious version. +- Correlate the event with other security alerts or logs from the same host or user to identify any patterns or additional indicators of compromise. +- Analyze network activity from the host around the time of the alert to detect any suspicious outbound connections that may indicate data exfiltration or command-and-control communication. + +### False positive analysis + +- Legitimate software development activities may trigger this rule if developers use scripting engines or system utilities to automate the compilation of .NET code. To manage this, identify and whitelist known development environments or scripts that frequently compile code using these methods. +- System administrators might use scripts or automation tools that invoke .NET compilers for maintenance tasks. Review and document these processes, then create exceptions for recognized administrative scripts to prevent unnecessary alerts. +- Some enterprise applications may use .NET compilers as part of their normal operation, especially if they dynamically generate or compile code. Investigate these applications and exclude their processes from the rule if they are verified as non-threatening. +- Security tools or monitoring solutions might simulate suspicious behavior for testing purposes, which could trigger this rule. Coordinate with your security team to identify such tools and exclude their activities from detection. +- In environments where custom scripts are frequently used for deployment or configuration, ensure these scripts are reviewed and, if safe, added to an exclusion list to reduce false positives. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further execution or spread of potentially malicious code. +- Terminate any suspicious processes identified, such as `csc.exe` or `vbc.exe`, that are running with unusual parent processes. +- Conduct a thorough scan of the isolated system using updated antivirus and endpoint detection tools to identify and remove any malicious files or remnants. +- Review and analyze the execution logs to determine the source and scope of the threat, focusing on the parent processes like `wscript.exe` or `mshta.exe` that initiated the compiler execution. +- Restore the system from a known good backup if malicious activity is confirmed and cannot be fully remediated through cleaning. +- Implement application whitelisting to prevent unauthorized execution of compilers and scripting engines by non-standard parent processes. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the need for broader organizational response measures.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_execution_control_panel_suspicious_args.toml b/rules/windows/defense_evasion_execution_control_panel_suspicious_args.toml index 24186a5e8cd..d5221ca2f18 100644 --- a/rules/windows/defense_evasion_execution_control_panel_suspicious_args.toml +++ b/rules/windows/defense_evasion_execution_control_panel_suspicious_args.toml @@ -2,7 +2,7 @@ creation_date = "2021/09/08" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2024/10/31" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -62,6 +62,41 @@ process where host.os.type == "windows" and event.type == "start" and "*\\AppData\\Local\\*" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Control Panel Process with Unusual Arguments + +The Control Panel in Windows is a system utility that allows users to view and adjust system settings. Adversaries may exploit this by using control.exe to execute malicious code under the guise of legitimate processes. The detection rule identifies anomalies in command-line arguments, such as unexpected file types or suspicious paths, which may indicate an attempt to evade defenses or execute unauthorized actions. + +### Possible investigation steps + +- Review the command line arguments of the control.exe process to identify any unusual file types or suspicious paths, such as image file extensions or paths like */AppData/Local/*. +- Check the parent process of control.exe to determine if it was spawned by a legitimate application or a potentially malicious one. +- Investigate the user account associated with the process to verify if the activity aligns with their typical behavior or if it appears suspicious. +- Examine recent file modifications or creations in directories like \\AppData\\Local\\ or \\Users\\Public\\ to identify any unauthorized or unexpected changes. +- Correlate the event with other security alerts or logs from data sources like Microsoft Defender for Endpoint or Sysmon to gather additional context on the potential threat. +- Assess the network activity of the host during the time of the alert to identify any unusual outbound connections that may indicate data exfiltration or command and control communication. + +### False positive analysis + +- Image file paths in command-line arguments may trigger false positives if users or applications are legitimately accessing image files through control.exe. To mitigate this, create exceptions for known applications or user activities that frequently access image files. +- Paths involving AppData or Users\\Public directories might be flagged if legitimate software installations or updates use these locations. Review and whitelist specific software processes that are known to use these directories for legitimate purposes. +- Relative path traversal patterns like ../../.. could be used by legitimate scripts or applications for configuration purposes. Identify and exclude these scripts or applications from the detection rule if they are verified as non-malicious. +- Frequent use of control.exe with specific command-line arguments by system administrators or IT personnel for legitimate system management tasks can be excluded by creating user-based exceptions for these roles. +- If certain security tools or monitoring software are known to trigger this rule due to their operational behavior, consider excluding these tools after confirming their legitimacy and necessity. + +### Response and remediation + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate the suspicious control.exe process to stop any ongoing malicious execution. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or remnants. +- Review and clean up any unauthorized changes or files in the directories specified in the alert, such as AppData/Local or Users/Public, to ensure no persistence mechanisms remain. +- Restore any affected files or system settings from a known good backup to ensure system integrity. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised. +- Implement additional monitoring and alerting for similar command-line anomalies to enhance detection and prevent recurrence of this threat.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_execution_msbuild_started_by_script.toml b/rules/windows/defense_evasion_execution_msbuild_started_by_script.toml index bb5c221efa9..e251faec73c 100755 --- a/rules/windows/defense_evasion_execution_msbuild_started_by_script.toml +++ b/rules/windows/defense_evasion_execution_msbuild_started_by_script.toml @@ -2,7 +2,7 @@ creation_date = "2020/03/25" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -46,6 +46,41 @@ host.os.type:windows and event.category:process and event.type:start and ( process.parent.name:("cmd.exe" or "powershell.exe" or "pwsh.exe" or "powershell_ise.exe" or "cscript.exe" or "wscript.exe" or "mshta.exe") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft Build Engine Started by a Script Process + +The Microsoft Build Engine (MSBuild) is a platform for building applications, typically invoked by developers. However, adversaries exploit its ability to execute inline tasks, using it as a proxy for executing malicious code. The detection rule identifies unusual MSBuild invocations initiated by script interpreters, signaling potential misuse for stealthy execution or defense evasion tactics. + +### Possible investigation steps + +- Review the process tree to understand the parent-child relationship, focusing on the parent process names such as cmd.exe, powershell.exe, pwsh.exe, powershell_ise.exe, cscript.exe, wscript.exe, or mshta.exe, which initiated the msbuild.exe process. +- Examine the command line arguments used to start msbuild.exe to identify any suspicious or unusual inline tasks or scripts that may indicate malicious activity. +- Check the user account associated with the msbuild.exe process to determine if it aligns with expected usage patterns or if it might be compromised. +- Investigate the timing and frequency of the msbuild.exe execution to see if it coincides with known legitimate build activities or if it appears anomalous. +- Look for any related network activity or file modifications around the time of the msbuild.exe execution to identify potential data exfiltration or further malicious actions. +- Cross-reference the alert with other security events or logs to identify any correlated indicators of compromise or additional suspicious behavior. + +### False positive analysis + +- Development environments where scripts are used to automate builds may trigger this rule. To manage this, identify and whitelist specific script processes or directories commonly used by developers. +- Automated testing frameworks that utilize scripts to initiate builds can cause false positives. Exclude these processes by creating exceptions for known testing tools and their associated scripts. +- Continuous integration/continuous deployment (CI/CD) pipelines often use scripts to invoke MSBuild. Consider excluding the parent processes associated with these pipelines from the rule. +- Administrative scripts that perform legitimate system maintenance tasks might start MSBuild. Review and exclude these scripts if they are verified as non-threatening. +- Custom scripts developed in-house for specific business functions may also trigger alerts. Conduct a review of these scripts and exclude them if they are deemed safe and necessary for operations. + +### Response and remediation + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate the suspicious MSBuild process and any associated script interpreter processes (e.g., cmd.exe, powershell.exe) to stop the execution of potentially malicious code. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious payloads or artifacts. +- Review and analyze the parent script or command that initiated the MSBuild process to understand the scope and intent of the attack, and identify any additional compromised systems or accounts. +- Reset credentials for any user accounts that were active on the affected system during the time of the alert to prevent unauthorized access. +- 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 enhanced monitoring and logging for MSBuild and script interpreter activities across the network to detect and respond to similar threats in the future.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_execution_msbuild_started_by_system_process.toml b/rules/windows/defense_evasion_execution_msbuild_started_by_system_process.toml index 3478af63413..664cec790d5 100644 --- a/rules/windows/defense_evasion_execution_msbuild_started_by_system_process.toml +++ b/rules/windows/defense_evasion_execution_msbuild_started_by_system_process.toml @@ -2,7 +2,7 @@ creation_date = "2020/03/25" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2024/10/31" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -53,6 +53,41 @@ process where host.os.type == "windows" and event.type == "start" and process.name : "MSBuild.exe" and process.parent.name : ("explorer.exe", "wmiprvse.exe") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft Build Engine Started by a System Process + +The Microsoft Build Engine (MSBuild) is a platform for building applications, typically invoked by developers. However, adversaries exploit it to execute malicious code, leveraging its trusted status to bypass security measures. The detection rule identifies unusual MSBuild activity initiated by system processes like Explorer or WMI, which may indicate an attempt to evade defenses and execute unauthorized actions. + +### Possible investigation steps + +- Review the process tree to understand the parent-child relationship, focusing on instances where MSBuild.exe is started by explorer.exe or wmiprvse.exe. +- Check the command line arguments used to start MSBuild.exe for any suspicious or unusual parameters that could indicate malicious activity. +- Investigate the user account associated with the process to determine if it aligns with expected behavior or if it might be compromised. +- Examine recent file modifications or creations in directories commonly used by MSBuild to identify any unauthorized or unexpected files. +- Correlate the event with other security alerts or logs from data sources like Microsoft Defender for Endpoint or Sysmon to gather additional context on the activity. +- Assess the network activity of the host during the time of the alert to identify any potential data exfiltration or communication with known malicious IP addresses. + +### False positive analysis + +- Legitimate software installations or updates may trigger MSBuild.exe to start from Explorer or WMI. Monitor these events and verify if they coincide with known software changes. +- Development environments where MSBuild is frequently used might see this behavior as part of normal operations. Identify and document these environments to create exceptions for known development machines. +- Automated scripts or administrative tools that leverage MSBuild for legitimate tasks can cause false positives. Review and whitelist these scripts or tools if they are verified as non-malicious. +- System maintenance tasks initiated by IT personnel might use MSBuild in a manner that appears suspicious. Coordinate with IT to understand routine maintenance activities and exclude them from alerts. +- Security software or monitoring tools that interact with MSBuild for scanning or analysis purposes should be identified and excluded from triggering alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate the MSBuild.exe process if it is confirmed to be executing unauthorized or malicious code. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious payloads or associated files. +- Review and analyze the parent processes (explorer.exe or wmiprvse.exe) to determine if they have been compromised or are executing other suspicious activities. +- Restore the system from a known good backup if any critical system files or applications have been altered or corrupted. +- 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 enhanced monitoring and logging for MSBuild.exe and related processes to detect similar activities in the future, ensuring alerts are configured for rapid response.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_execution_msbuild_started_unusal_process.toml b/rules/windows/defense_evasion_execution_msbuild_started_unusal_process.toml index 0e0e298687a..79a9580145d 100644 --- a/rules/windows/defense_evasion_execution_msbuild_started_unusal_process.toml +++ b/rules/windows/defense_evasion_execution_msbuild_started_unusal_process.toml @@ -2,7 +2,7 @@ creation_date = "2020/03/25" integration = ["endpoint", "windows", "system"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -51,6 +51,41 @@ query = ''' host.os.type:windows and event.category:process and event.type:start and process.parent.name:("MSBuild.exe" or "msbuild.exe") and process.name:("csc.exe" or "iexplore.exe" or "powershell.exe") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft Build Engine Started an Unusual Process + +The Microsoft Build Engine (MSBuild) is a platform for building applications, often used in software development environments. Adversaries may exploit MSBuild to execute malicious scripts or compile code, bypassing security controls. The detection rule identifies unusual processes initiated by MSBuild, such as PowerShell or C# compiler, signaling potential misuse for executing unauthorized or harmful actions. + +### Possible investigation steps + +- Review the process tree to understand the parent-child relationship, focusing on MSBuild.exe or msbuild.exe as the parent process and any unusual child processes like csc.exe, iexplore.exe, or powershell.exe. +- Examine the command line arguments used by the unusual process to identify any suspicious or malicious scripts or commands being executed. +- Check the user account associated with the process to determine if it aligns with expected usage patterns or if it might be compromised. +- Investigate the source and integrity of the MSBuild project file (.proj or .sln) to ensure it hasn't been tampered with or used to execute unauthorized code. +- Analyze recent changes or deployments in the environment that might explain the unusual process execution, such as new software installations or updates. +- Correlate this event with other security alerts or logs to identify any patterns or additional indicators of compromise that might suggest a broader attack. + +### False positive analysis + +- Development environments often use MSBuild to execute legitimate PowerShell scripts or compile C# code. Regularly review and whitelist known development processes to prevent unnecessary alerts. +- Automated build systems may trigger this rule when running scripts or compiling code as part of their normal operation. Identify and exclude these systems by their hostnames or IP addresses. +- Some software installations or updates might use MSBuild to execute scripts. Monitor and document these activities, and create exceptions for recognized software vendors. +- Internal tools or scripts that rely on MSBuild for execution should be cataloged. Establish a baseline of expected behavior and exclude these from triggering alerts. +- Collaborate with development teams to understand their use of MSBuild and adjust the detection rule to accommodate their workflows without compromising security. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further execution of potentially malicious processes and lateral movement. +- Terminate any suspicious processes initiated by MSBuild, such as PowerShell or the C# compiler, to halt any ongoing malicious activity. +- Conduct a thorough review of the affected system for any unauthorized changes or additional malicious files, focusing on scripts or executables that may have been deployed. +- Restore the system from a known good backup if any malicious activity or unauthorized changes are confirmed, ensuring that the backup is clean and uncompromised. +- Escalate the incident to the security operations team for further analysis and to determine if the threat is part of a larger attack campaign. +- Implement additional monitoring and logging for MSBuild and related processes to detect any future misuse or anomalies promptly. +- Review and update endpoint protection configurations to enhance detection and prevention capabilities against similar threats, ensuring that security controls are effectively blocking unauthorized script execution.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_execution_suspicious_explorer_winword.toml b/rules/windows/defense_evasion_execution_suspicious_explorer_winword.toml index 17ca6cfd018..1779dcff668 100644 --- a/rules/windows/defense_evasion_execution_suspicious_explorer_winword.toml +++ b/rules/windows/defense_evasion_execution_suspicious_explorer_winword.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/03" integration = ["endpoint", "windows", "m365_defender"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -55,6 +55,41 @@ process where host.os.type == "windows" and event.type == "start" and "?:\\Windows\\System32\\inetsrv\\w3wp.exe") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 DLL Side-Loading via Trusted Microsoft Programs + +DLL side-loading exploits the DLL search order to load malicious code into trusted Microsoft programs, which are often whitelisted by security tools. Adversaries rename or relocate these programs to execute unauthorized DLLs, evading detection. The detection rule identifies unusual execution paths or renamed instances of these programs, signaling potential misuse and enabling timely threat response. + +### Possible investigation steps + +- Review the process details to confirm the original file name and the path from which the process was executed. Check if the process.pe.original_file_name matches any of the specified trusted programs like "WinWord.exe", "EXPLORER.EXE", "w3wp.exe", or "DISM.EXE". +- Investigate the process execution path to determine if it deviates from the standard paths listed in the query, such as "?:\\Windows\\explorer.exe" or "?:\\Program Files\\Microsoft Office\\root\\Office*\\WINWORD.EXE". +- Examine the process creation history and parent process to identify any unusual or suspicious parent-child relationships that might indicate malicious activity. +- Check for any recent file modifications or creations in the directory from which the process was executed, which could suggest the presence of a malicious DLL. +- Correlate the event with other security logs or alerts from data sources like Elastic Endgame, Elastic Defend, Sysmon, or Microsoft Defender for Endpoint to gather additional context and identify potential patterns of malicious behavior. +- Assess the risk and impact of the event by considering the risk score and severity level provided, and determine if immediate containment or further investigation is necessary. + +### False positive analysis + +- Legitimate software updates or installations may temporarily execute trusted Microsoft programs from non-standard paths. Users can create exceptions for known update processes to prevent false alerts. +- Custom enterprise applications might use renamed instances of trusted Microsoft programs for legitimate purposes. Identify and whitelist these specific applications to avoid unnecessary alerts. +- Virtual environments or sandboxed applications may execute trusted programs from unusual paths as part of their normal operation. Review and exclude these environments if they are known and trusted. +- Security or IT administrative tools might mimic trusted Microsoft programs for monitoring or management tasks. Verify these tools and add them to an exception list if they are part of standard operations. +- Development or testing environments often involve renamed or relocated executables for debugging purposes. Ensure these environments are recognized and excluded from the detection rule to reduce false positives. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of the potential threat and unauthorized access. +- Terminate the suspicious process identified by the detection rule to stop any ongoing malicious activity. +- Conduct a forensic analysis of the affected system to identify any malicious DLLs or additional compromised files, and remove them. +- Restore the affected system from a known good backup to ensure all malicious changes are reverted. +- Update and patch all software on the affected system, focusing on the trusted Microsoft programs identified in the alert, to mitigate vulnerabilities exploited by DLL side-loading. +- Monitor the network for any signs of lateral movement or additional compromised systems, using the indicators of compromise identified during the investigation. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems or data have been affected.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_execution_windefend_unusual_path.toml b/rules/windows/defense_evasion_execution_windefend_unusual_path.toml index c46c13405b5..cccb6701f31 100644 --- a/rules/windows/defense_evasion_execution_windefend_unusual_path.toml +++ b/rules/windows/defense_evasion_execution_windefend_unusual_path.toml @@ -2,7 +2,7 @@ creation_date = "2021/07/07" integration = ["endpoint", "windows", "m365_defender"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -59,6 +59,39 @@ process where host.os.type == "windows" and event.type == "start" and "?:\\Program Files (x86)\\Microsoft Security Client\\*.exe")) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 DLL Side-Loading via Microsoft Antimalware Service Executable + +The Microsoft Antimalware Service Executable, a core component of Windows Defender, is crucial for real-time protection against malware. Adversaries exploit its trust by renaming it or executing it from non-standard paths to load malicious DLLs, bypassing security measures. The detection rule identifies such anomalies by monitoring process names and paths, flagging deviations from expected behavior to uncover potential threats. + +### Possible investigation steps + +- Review the process details to confirm if the process name is MsMpEng.exe but is executing from a non-standard path. Check the process.executable field to identify the exact path and verify if it deviates from the expected directories. +- Investigate the parent process of the suspicious MsMpEng.exe instance to determine how it was initiated. This can provide insights into whether the process was started by a legitimate application or a potentially malicious one. +- Examine the system for any recent file modifications or creations in the directory where the suspicious MsMpEng.exe is located. This can help identify if a malicious DLL was recently placed in the same directory. +- Check for any network connections or communications initiated by the suspicious MsMpEng.exe process. This can help determine if the process is attempting to communicate with external servers, which may indicate malicious activity. +- Look for any other processes or activities on the host that may indicate compromise, such as unusual user account activity or other processes running from unexpected locations. This can help assess the broader impact of the potential threat. + +### False positive analysis + +- Legitimate software updates or installations may temporarily rename or relocate the Microsoft Antimalware Service Executable. Users should verify if any software updates or installations occurred around the time of the alert and consider excluding these paths if they are known and trusted. +- Custom security or IT management tools might execute the executable from non-standard paths for monitoring or testing purposes. Confirm with IT or security teams if such tools are in use and add these paths to the exclusion list if they are verified as safe. +- Virtualization or sandbox environments may replicate the executable in different locations for testing or analysis. Check if the environment is part of a controlled setup and exclude these paths if they are part of legitimate operations. +- Backup or recovery processes might involve copying the executable to alternate locations. Ensure these processes are legitimate and consider excluding these paths if they are part of routine operations. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further spread of the potential threat. +- Terminate any suspicious processes identified by the detection rule, specifically those involving MsMpEng.exe running from non-standard paths. +- Conduct a thorough scan of the affected system using an updated antivirus or endpoint detection and response (EDR) tool to identify and remove any malicious DLLs or other malware. +- Review and restore any altered or deleted system files from a known good backup to ensure system integrity. +- Investigate the source of the DLL side-loading attempt to determine if it was part of a broader attack campaign, and gather forensic evidence for further analysis. +- Escalate the incident to the security operations center (SOC) or incident response team for a deeper investigation and to assess the need for further containment measures. +- Implement additional monitoring and alerting for similar anomalies in process execution paths to enhance detection capabilities and prevent recurrence.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_file_creation_mult_extension.toml b/rules/windows/defense_evasion_file_creation_mult_extension.toml index b3b03816550..62a852d1053 100644 --- a/rules/windows/defense_evasion_file_creation_mult_extension.toml +++ b/rules/windows/defense_evasion_file_creation_mult_extension.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/19" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -41,6 +41,40 @@ file where host.os.type == "windows" and event.type == "creation" and file.exten not (process.executable : ("?:\\Windows\\System32\\msiexec.exe", "C:\\Users\\*\\QGIS_SCCM\\Files\\QGIS-OSGeo4W-*-Setup-x86_64.exe") and file.path : "?:\\Program Files\\QGIS *\\apps\\grass\\*.exe") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Executable File Creation with Multiple Extensions + +In Windows environments, adversaries may exploit file extensions to disguise malicious executables as benign files, such as documents or images, by appending multiple extensions. This tactic, known as masquerading, aims to deceive users and evade security measures. The detection rule identifies suspicious file creations by monitoring for executables with misleading extensions, excluding known legitimate processes, thus highlighting potential threats. + +### Possible investigation steps + +- Review the file creation event details to identify the full file path and name, focusing on the extensions used to determine if they match the suspicious pattern outlined in the query. +- Investigate the process that created the file by examining the process.executable field to determine if it is a known legitimate process or potentially malicious. +- Check the file's origin by analyzing the user account and network activity associated with the file creation event to identify any unusual or unauthorized access patterns. +- Utilize threat intelligence sources to assess if the file hash or any related indicators of compromise (IOCs) are known to be associated with malicious activity. +- Examine the file's metadata and properties to verify its authenticity and check for any signs of tampering or unusual characteristics. +- Conduct a behavioral analysis of the file in a controlled environment to observe any malicious actions or network communications it may attempt. + +### False positive analysis + +- Legitimate software installations may create executables with multiple extensions during setup processes. Users can exclude these by adding exceptions for known installer paths, such as "C:\\Users\\*\\QGIS_SCCM\\Files\\QGIS-OSGeo4W-*-Setup-x86_64.exe". +- System updates or patches might temporarily create files with multiple extensions. Monitor and verify these activities, and if confirmed as legitimate, add exceptions for the specific update processes. +- Development environments or script-based applications may generate files with multiple extensions for testing purposes. Identify these environments and exclude their specific file paths or processes to prevent false positives. +- Security tools or administrative scripts might use multiple extensions for legitimate purposes. Review and whitelist these tools by their executable paths or process names to avoid unnecessary alerts. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity. +- Terminate any suspicious processes associated with the masquerading executable files to halt any ongoing malicious actions. +- Quarantine the identified files with multiple extensions to prevent execution and further analysis. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional threats. +- Review and restore any altered system configurations or files to their original state to ensure system integrity. +- 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 enhanced monitoring and logging for similar file creation activities to improve detection and response capabilities for future incidents.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_hide_encoded_executable_registry.toml b/rules/windows/defense_evasion_hide_encoded_executable_registry.toml index 25ed246466d..34404a28ec3 100644 --- a/rules/windows/defense_evasion_hide_encoded_executable_registry.toml +++ b/rules/windows/defense_evasion_hide_encoded_executable_registry.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende maturity = "production" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." min_stack_version = "8.14.0" -updated_date = "2024/10/15" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -29,6 +29,40 @@ registry where host.os.type == "windows" and /* update here with encoding combinations */ registry.data.strings : "TVqQAAMAAAAEAAAA*" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Encoded Executable Stored in the Registry + +Windows Registry is a hierarchical database storing low-level settings for the OS and applications. Adversaries exploit it to hide encoded executables, evading detection by avoiding direct disk storage. The detection rule identifies suspicious registry modifications, specifically targeting encoded patterns indicative of hidden executables, thus flagging potential defense evasion tactics. + +### Possible investigation steps + +- Review the registry path and key where the modification was detected to understand the context and potential impact on the system. +- Analyze the encoded data string "TVqQAAMAAAAEAAAA*" to determine if it corresponds to a known malicious executable or pattern. +- Check the modification timestamp to correlate with any other suspicious activities or events on the system around the same time. +- Investigate the process or user account responsible for the registry modification to assess if it is associated with legitimate activity or known threats. +- Cross-reference the alert with other data sources such as Sysmon, Microsoft Defender for Endpoint, or SentinelOne for additional context or corroborating evidence of malicious behavior. +- Evaluate the system's network activity and connections during the time of the registry modification to identify any potential command and control communications or data exfiltration attempts. + +### False positive analysis + +- Legitimate software installations or updates may write encoded executables to the registry as part of their normal operation. Users can create exceptions for known software by identifying their specific registry paths and excluding them from the detection rule. +- Security tools and system management software might store encoded data in the registry for legitimate purposes. Review the registry paths and data associated with these tools and exclude them if they are verified as non-threatening. +- Custom scripts or enterprise applications developed in-house may use encoded executables in the registry for deployment or configuration purposes. Work with development teams to identify these scripts and add exceptions for their registry modifications. +- Regularly review and update the list of exceptions to ensure that only verified and necessary exclusions are maintained, minimizing the risk of overlooking potential threats. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of the potential threat. +- Use endpoint detection and response (EDR) tools to terminate any suspicious processes associated with the encoded executable. +- Remove the malicious registry entry by using a trusted registry editor or automated script to ensure the encoded executable is no longer stored in the registry. +- Conduct a full system scan using updated antivirus and anti-malware tools to identify and remove any additional threats or remnants of the attack. +- Restore the system from a known good backup if the integrity of the system is compromised and cannot be assured through cleaning. +- Monitor the system and network for any signs of re-infection or similar registry modifications, adjusting detection rules if necessary to enhance future threat identification. +- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further analysis and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_injection_msbuild.toml b/rules/windows/defense_evasion_injection_msbuild.toml index d89f796cde2..41c8747ec4d 100755 --- a/rules/windows/defense_evasion_injection_msbuild.toml +++ b/rules/windows/defense_evasion_injection_msbuild.toml @@ -2,7 +2,7 @@ creation_date = "2020/03/25" integration = ["windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -35,6 +35,42 @@ query = ''' process where host.os.type == "windows" and process.name: "MSBuild.exe" and event.action:("CreateRemoteThread detected (rule: CreateRemoteThread)", "CreateRemoteThread") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Process Injection by the Microsoft Build Engine + +The Microsoft Build Engine (MSBuild) is a platform for building applications, often used in software development environments. Adversaries exploit MSBuild to perform process injection, a technique to execute malicious code within the address space of another process, thereby evading detection and potentially escalating privileges. The detection rule identifies suspicious MSBuild activity by monitoring for thread creation in other processes, leveraging Sysmon data to flag potential abuse. + +### Possible investigation steps + +- Review the alert details to confirm that the process name is "MSBuild.exe" and the event action is "CreateRemoteThread detected (rule: CreateRemoteThread)". +- Examine the parent process of MSBuild.exe to determine if it was launched by a legitimate application or user, which could indicate whether the activity is expected or suspicious. +- Check the timeline of events to see if there are any other related alerts or activities around the same time, such as unusual network connections or file modifications, which could provide additional context. +- Investigate the target process where the thread was created to assess its normal behavior and determine if it is a common target for injection or if it has been compromised. +- Analyze the command line arguments used to launch MSBuild.exe to identify any unusual or suspicious parameters that could indicate malicious intent. +- Review the user account associated with the MSBuild.exe process to verify if it has the necessary permissions and if the activity aligns with the user's typical behavior. +- Consult threat intelligence sources to check if there are any known campaigns or malware that utilize MSBuild for process injection, which could help in understanding the potential threat actor or objective. + +### False positive analysis + +- Development environments often use MSBuild for legitimate purposes, which can trigger false positives. Users should monitor and establish a baseline of normal MSBuild activity to differentiate between benign and suspicious behavior. +- Automated build systems may frequently invoke MSBuild, leading to false positives. Consider excluding known build server IP addresses or specific user accounts associated with these systems from the detection rule. +- Some legitimate software may use MSBuild for plugin or extension loading, which could appear as process injection. Identify and whitelist these applications by their process hashes or paths to reduce noise. +- Regular updates or installations of software development tools might cause MSBuild to create threads in other processes. Temporarily disable the rule during scheduled maintenance windows to prevent unnecessary alerts. +- Collaborate with development teams to understand their use of MSBuild and adjust the detection rule to exclude known safe operations, ensuring that only unexpected or unauthorized uses are flagged. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate the MSBuild.exe process if it is confirmed to be involved in unauthorized thread creation, using task management tools or scripts. +- Conduct a memory analysis on the affected system to identify and extract any injected code or payloads for further investigation. +- Review and restore any altered or compromised system files and configurations to their original state using known good backups. +- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the scope of the intrusion. +- Implement application whitelisting to prevent unauthorized execution of MSBuild.exe or similar tools in non-development environments. +- Enhance monitoring and detection capabilities by ensuring Sysmon is configured to log detailed process creation and thread injection events across the network.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_installutil_beacon.toml b/rules/windows/defense_evasion_installutil_beacon.toml index 6abd0388863..b32862e2dcf 100644 --- a/rules/windows/defense_evasion_installutil_beacon.toml +++ b/rules/windows/defense_evasion_installutil_beacon.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/02" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -42,6 +42,41 @@ sequence by process.entity_id [process where host.os.type == "windows" and event.type == "start" and process.name : "installutil.exe"] [network where host.os.type == "windows" and process.name : "installutil.exe" and network.direction : ("outgoing", "egress")] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 InstallUtil Process Making Network Connections + +InstallUtil.exe is a legitimate Windows utility used for installing and uninstalling server resources by executing installer components. Adversaries exploit it to run malicious code under the guise of legitimate processes, often to evade detection. The detection rule identifies suspicious network activity by monitoring InstallUtil.exe's outbound connections, flagging potential misuse by alerting on the initial network connection attempt. + +### Possible investigation steps + +- Review the alert details to confirm the process.entity_id and ensure it matches the InstallUtil.exe process making the outbound network connection. +- Investigate the destination IP address and port of the network connection to determine if it is known, trusted, or associated with malicious activity. +- Examine the parent process of InstallUtil.exe to identify how it was launched and assess if this behavior is expected or potentially malicious. +- Check the timeline of events around the process start and network connection to identify any other suspicious activities or related processes. +- Look for any additional network connections made by the same process.entity_id to assess if there is a pattern or further evidence of malicious behavior. +- Review system logs and security alerts for any other indicators of compromise or related suspicious activities on the host. + +### False positive analysis + +- Legitimate software installations or updates may trigger InstallUtil.exe to make network connections. Users can create exceptions for known software update processes by identifying their specific process entity IDs and excluding them from the alert. +- System administrators may use InstallUtil.exe for routine maintenance tasks that require network access. To prevent false positives, document these tasks and configure the detection rule to exclude these specific instances. +- Automated deployment tools that utilize InstallUtil.exe for legitimate purposes can be a source of false positives. Identify these tools and their associated network activities, then adjust the rule to ignore these benign connections. +- Development environments where InstallUtil.exe is used for testing purposes might generate alerts. Establish a list of development machines and exclude their process entity IDs from the detection rule to reduce noise. +- Scheduled tasks or scripts that use InstallUtil.exe for legitimate network operations should be reviewed. Once verified as non-threatening, these can be added to an exception list to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further malicious activity and potential lateral movement. +- Terminate the InstallUtil.exe process on the affected system to stop any ongoing malicious actions. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious payloads or associated files. +- Review and analyze the network logs to identify any other systems that may have been contacted by the malicious process and assess if they are compromised. +- Restore the affected system from a known good backup if malicious activity is confirmed and cannot be fully remediated. +- 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 network monitoring and alerting for unusual outbound connections from critical systems to enhance detection of similar threats in the future.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_lolbas_win_cdb_utility.toml b/rules/windows/defense_evasion_lolbas_win_cdb_utility.toml index ff5cb36de8a..4aca06bb77a 100644 --- a/rules/windows/defense_evasion_lolbas_win_cdb_utility.toml +++ b/rules/windows/defense_evasion_lolbas_win_cdb_utility.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "system","sentinel_one_cloud_funnel", "m36 maturity = "production" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." min_stack_version = "8.14.0" -updated_date = "2024/11/02" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -55,6 +55,40 @@ process where host.os.type == "windows" and event.type == "start" and "\\Device\\HarddiskVolume?\\Program Files\\*\\cdb.exe" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Execution via Windows Command Debugging Utility + +The Windows command line debugging utility, cdb.exe, is a legitimate tool used for debugging applications. However, adversaries can exploit it to execute unauthorized commands or shellcode, bypassing security measures. The detection rule identifies suspicious use of cdb.exe by monitoring its execution outside standard installation paths and specific command-line arguments, indicating potential misuse for defense evasion. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of cdb.exe running from non-standard paths, as specified in the query. +- Examine the command-line arguments used with cdb.exe, particularly looking for "-cf", "-c", or "-pd", to understand the potential actions or scripts being executed. +- Investigate the parent process of cdb.exe to determine how it was launched and identify any associated suspicious activity or processes. +- Check the user account associated with the cdb.exe execution to assess if it aligns with expected behavior or if it indicates potential compromise. +- Analyze recent system logs and security alerts for any related or preceding suspicious activities that might correlate with the execution of cdb.exe. +- Review network activity from the host to identify any unusual outbound connections that could suggest data exfiltration or command-and-control communication. + +### False positive analysis + +- Legitimate debugging activities by developers or IT staff using cdb.exe outside standard paths can trigger alerts. To manage this, create exceptions for known user accounts or specific machines frequently used for development. +- Automated testing environments may execute cdb.exe with command-line arguments for legitimate purposes. Identify these environments and exclude their processes from triggering alerts. +- Software installations or updates might temporarily use cdb.exe in non-standard paths. Monitor installation logs and exclude these specific instances if they are verified as part of legitimate software deployment. +- Security tools or scripts that leverage cdb.exe for monitoring or analysis can be mistaken for malicious activity. Document these tools and add them to the exclusion list to prevent false positives. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or execution of malicious commands. +- Terminate any suspicious instances of cdb.exe running outside the standard installation paths to halt potential malicious activity. +- Conduct a forensic analysis of the affected system to identify any unauthorized changes or additional malicious payloads that may have been executed. +- Restore the system from a known good backup if any unauthorized changes or malware are detected, ensuring that the backup is clean and uncompromised. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. +- Implement application whitelisting to prevent unauthorized execution of cdb.exe from non-standard paths. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_masquerading_as_elastic_endpoint_process.toml b/rules/windows/defense_evasion_masquerading_as_elastic_endpoint_process.toml index 2aa5a43e6fe..b6177118795 100644 --- a/rules/windows/defense_evasion_masquerading_as_elastic_endpoint_process.toml +++ b/rules/windows/defense_evasion_masquerading_as_elastic_endpoint_process.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/24" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -71,6 +71,41 @@ process where host.os.type == "windows" and event.type == "start" and ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Endpoint Security Parent Process + +Endpoint security solutions, like Elastic and Microsoft Defender, monitor and protect systems by analyzing process behaviors. Adversaries may exploit these processes through techniques like process hollowing, where malicious code is injected into legitimate processes to evade detection. The detection rule identifies anomalies by flagging unexpected parent processes of security executables, excluding known benign paths and arguments, thus highlighting potential threats. + +### Possible investigation steps + +- Review the process details for the flagged executable (e.g., esensor.exe or elastic-endpoint.exe) to understand its expected behavior and any recent changes in its configuration or deployment. +- Examine the parent process executable path and name to determine if it is a known legitimate process or potentially malicious. Pay special attention to paths not listed in the known benign paths, such as those outside "?:\\Program Files\\Elastic\\*" or "?:\\Windows\\System32\\*". +- Investigate the command-line arguments used by the parent process to identify any unusual or suspicious patterns that could indicate malicious activity, especially if they do not match the benign arguments like "test", "version", or "status". +- Check the historical activity of the parent process to see if it has been involved in other suspicious activities or if it has a history of spawning security-related processes. +- Correlate the alert with other security events or logs from data sources like Elastic Endgame, Microsoft Defender for Endpoint, or Sysmon to gather additional context and identify any related suspicious activities. +- Assess the risk and impact of the alert by considering the environment, the criticality of the affected systems, and any potential data exposure or operational disruption. + +### False positive analysis + +- Security tools or scripts that automate tasks may trigger false positives if they launch endpoint security processes with unexpected parent processes. To manage this, identify and document these tools, then add their parent executable paths to the exclusion list. +- System administrators or IT personnel may use command-line tools like PowerShell or cmd.exe for legitimate maintenance tasks. If these tasks frequently trigger alerts, consider adding specific command-line arguments used in these tasks to the exclusion list. +- Software updates or installations might temporarily cause unexpected parent processes for security executables. Monitor these activities and, if they are routine and verified, add the associated parent executable paths to the exclusion list. +- Custom scripts or third-party applications that interact with security processes can also lead to false positives. Review these scripts or applications, and if they are deemed safe, include their parent executable paths in the exclusion list. +- Regularly review and update the exclusion list to ensure it reflects the current environment and operational practices, minimizing the risk of overlooking new legitimate processes. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity. +- Terminate the suspicious process identified by the alert to stop any ongoing malicious activity and prevent further code execution. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise, such as unauthorized changes or additional malicious files. +- Restore the system from a known good backup if any malicious activity or unauthorized changes are confirmed, ensuring that the backup is clean and uncompromised. +- Update endpoint security solutions and apply any available patches to address vulnerabilities that may have been exploited by the adversary. +- Monitor the network and systems for any signs of re-infection or similar suspicious activities, using enhanced logging and alerting based on the identified threat indicators. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be affected.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_masquerading_business_apps_installer.toml b/rules/windows/defense_evasion_masquerading_business_apps_installer.toml index 69125b3d1b2..9baf3de0d59 100644 --- a/rules/windows/defense_evasion_masquerading_business_apps_installer.toml +++ b/rules/windows/defense_evasion_masquerading_business_apps_installer.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/01" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -163,6 +163,42 @@ process where host.os.type == "windows" and ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Masquerading as Business App Installer + +Business applications are integral to productivity, often downloaded and installed by users. Adversaries exploit this by creating malicious executables with names mimicking legitimate apps, tricking users into installing them. The detection rule identifies such threats by checking for unsigned executables in download directories, ensuring they don't masquerade as trusted applications. + +### Possible investigation steps + +- Review the process name and executable path to confirm if it matches any known legitimate business application names listed in the rule, such as Slack, WebEx, or Teams, and verify if it was executed from a typical download directory. +- Check the process code signature status and subject name to determine if the executable is unsigned or signed by an untrusted entity, which could indicate a masquerading attempt. +- Investigate the source of the download by examining browser history, email attachments, or any recent file transfers to identify potential phishing attempts or malicious download sources. +- Analyze the process execution context, including parent processes and command-line arguments, to understand how the executable was launched and if it aligns with typical user behavior. +- Look for any network connections initiated by the process to identify suspicious outbound traffic or connections to known malicious IP addresses or domains. +- Cross-reference the executable's hash with threat intelligence databases to check for known malware signatures or previous reports of malicious activity. +- If the executable is determined to be suspicious, isolate the affected system and perform a full malware scan to prevent further compromise. + +### False positive analysis + +- Unsigned executables from legitimate developers may trigger alerts if they are not properly signed or if the signature is not recognized. Users can create exceptions for specific executables by verifying the developer's authenticity and adding them to a trusted list. +- Custom or in-house developed applications that mimic business app names but are unsigned can cause false positives. Organizations should ensure these applications are signed with a trusted certificate or add them to an exclusion list after verifying their safety. +- Software updates or beta versions of legitimate applications might not have updated signatures, leading to false positives. Users should verify the source of the update and, if legitimate, temporarily exclude these versions from the rule. +- Applications installed in non-standard directories that match the naming patterns but are legitimate can be excluded by specifying trusted paths or directories in the rule configuration. +- Third-party tools or utilities that integrate with business applications and use similar naming conventions might be flagged. Users should verify these tools and, if safe, add them to an exception list to prevent future alerts. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity. +- Terminate the suspicious process identified by the alert to stop any ongoing malicious actions. +- Quarantine the executable file flagged by the detection rule to prevent execution and further analysis. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or remnants. +- Review and analyze the process execution logs and any related network activity to understand the scope of the intrusion and identify any other potentially compromised systems. +- 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 application whitelisting to prevent unauthorized executables from running, ensuring only trusted and signed applications are allowed to execute.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_masquerading_communication_apps.toml b/rules/windows/defense_evasion_masquerading_communication_apps.toml index 27f59a47cb9..6a8fa9e23ad 100644 --- a/rules/windows/defense_evasion_masquerading_communication_apps.toml +++ b/rules/windows/defense_evasion_masquerading_communication_apps.toml @@ -2,7 +2,7 @@ creation_date = "2023/05/05" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/31" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -90,6 +90,41 @@ process where host.os.type == "windows" and ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Masquerading as Communication Apps + +Communication apps are integral to modern workflows, facilitating seamless interaction. However, adversaries can exploit these apps by masquerading malicious processes as legitimate ones, bypassing security measures and deceiving users. The detection rule identifies suspicious instances by checking for unsigned or improperly signed processes, ensuring they match known trusted signatures. This helps in flagging potential threats that mimic trusted communication tools, aiding in defense evasion detection. + +### Possible investigation steps + +- Review the process name and code signature details to confirm if the process is indeed masquerading as a legitimate communication app. Check if the process name matches any of the specified apps like slack.exe, WebexHost.exe, etc., and verify the code signature subject name and trust status. +- Investigate the origin of the executable file by checking its file path and creation date. Determine if it was recently added or modified, which might indicate suspicious activity. +- Analyze the parent process to understand how the suspicious process was initiated. This can provide insights into whether it was launched by a legitimate application or a potentially malicious script or program. +- Check for any network connections initiated by the suspicious process. Look for unusual or unauthorized external connections that might suggest data exfiltration or command and control communication. +- Review recent system logs and security alerts for any related activities or anomalies that coincide with the start of the suspicious process. This can help identify if the process is part of a larger attack pattern. +- Consult threat intelligence sources to see if there are any known indicators of compromise (IOCs) associated with the process or its hash value, which can help in assessing the threat level. + +### False positive analysis + +- Legitimate software updates or installations may temporarily result in unsigned or improperly signed processes. Users can create exceptions for known update processes to prevent false positives during these periods. +- Custom or internally developed communication tools that mimic the names of popular apps might trigger alerts. Ensure these tools are properly signed and add them to an allowlist if they are trusted. +- Some third-party security or monitoring tools may interact with communication apps in a way that alters their signature status. Verify the legitimacy of these tools and consider excluding them from the rule if they are deemed safe. +- In environments where communication apps are deployed via non-standard methods, such as portable versions, ensure these versions are signed correctly or add them to an exception list if they are verified as safe. +- Temporary network issues or system misconfigurations might cause legitimate apps to appear unsigned. Regularly audit and correct any network or system issues to minimize these occurrences. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further spread of potential malware or unauthorized access. +- Terminate any suspicious processes identified by the detection rule that are masquerading as communication apps, ensuring they are not legitimate processes. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious files or software. +- Review and validate the code signatures of all communication apps on the affected system to ensure they are properly signed by trusted entities. +- Restore any compromised systems from a known good backup to ensure the integrity of the system and data. +- Monitor network traffic and system logs for any signs of lateral movement or further attempts to exploit communication apps. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_masquerading_suspicious_werfault_childproc.toml b/rules/windows/defense_evasion_masquerading_suspicious_werfault_childproc.toml index c6e35d6317b..fc8a23b75c6 100644 --- a/rules/windows/defense_evasion_masquerading_suspicious_werfault_childproc.toml +++ b/rules/windows/defense_evasion_masquerading_suspicious_werfault_childproc.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende maturity = "production" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." min_stack_version = "8.14.0" -updated_date = "2024/10/15" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -60,6 +60,40 @@ process where host.os.type == "windows" and event.type == "start" and not process.executable : ("?:\\Windows\\SysWOW64\\Initcrypt.exe", "?:\\Program Files (x86)\\Heimdal\\Heimdal.Guard.exe") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious WerFault Child Process + +WerFault.exe is a Windows error reporting tool that handles application crashes. Adversaries may exploit it by manipulating the SilentProcessExit registry key to execute malicious processes stealthily. The detection rule identifies unusual child processes of WerFault.exe, focusing on specific command-line arguments indicative of this abuse, while excluding known legitimate executables, thus highlighting potential threats. + +### Possible investigation steps + +- Review the command line arguments of the suspicious child process to confirm the presence of "-s", "-t", and "-c" flags, which indicate potential abuse of the SilentProcessExit mechanism. +- Examine the process executable path to ensure it is not one of the known legitimate executables ("?:\\Windows\\SysWOW64\\Initcrypt.exe", "?:\\Program Files (x86)\\Heimdal\\Heimdal.Guard.exe") that are excluded from the detection rule. +- Investigate the network connections established by the suspicious process to identify any unusual or unauthorized external communications. +- Analyze file writes and modifications made by the process to detect any unauthorized changes or potential indicators of compromise. +- Check the parent process tree to understand the context of how WerFault.exe was invoked and identify any preceding suspicious activities or processes. +- Correlate the event with other security alerts or logs from data sources like Elastic Endgame, Elastic Defend, Microsoft Defender for Endpoint, Sysmon, or SentinelOne to gather additional context and assess the scope of the potential threat. + +### False positive analysis + +- Legitimate software updates or installations may trigger WerFault.exe with command-line arguments similar to those used in the SilentProcessExit mechanism. Users should verify the digital signature of the executable and check if it aligns with known update processes. +- Security software or system management tools might use WerFault.exe for legitimate purposes. Users can create exceptions for these known tools by adding their executables to the exclusion list in the detection rule. +- Custom scripts or enterprise applications that utilize WerFault.exe for error handling could be flagged. Review the process details and, if verified as non-threatening, add these scripts or applications to the exclusion list. +- Frequent occurrences of the same process being flagged can indicate a benign pattern. Users should monitor these patterns and, if consistently verified as safe, update the rule to exclude these specific processes. + +### Response and remediation + +- Isolate the affected system from the network to prevent further potential malicious activity and lateral movement. +- Terminate the suspicious child process of WerFault.exe immediately to halt any ongoing malicious actions. +- Conduct a thorough review of the SilentProcessExit registry key to identify and remove any unauthorized entries that may have been used to execute the malicious process. +- Restore any altered or deleted files from a known good backup to ensure system integrity and recover any lost data. +- Update and run a full antivirus and anti-malware scan on the affected system to detect and remove any additional threats or remnants of the attack. +- Monitor network traffic and system logs for any signs of persistence mechanisms or further attempts to exploit the SilentProcessExit mechanism. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_masquerading_trusted_directory.toml b/rules/windows/defense_evasion_masquerading_trusted_directory.toml index 34442a07c20..29e6592ece3 100644 --- a/rules/windows/defense_evasion_masquerading_trusted_directory.toml +++ b/rules/windows/defense_evasion_masquerading_trusted_directory.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/18" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2024/10/31" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -75,6 +75,41 @@ process where host.os.type == "windows" and event.type == "start" and ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Program Files Directory Masquerading + +The Program Files directories in Windows are trusted locations for legitimate software. Adversaries may exploit this trust by creating similarly named directories to execute malicious files, bypassing security measures. The detection rule identifies suspicious executions from these masquerading paths, excluding known legitimate directories, to flag potential threats. This helps in identifying defense evasion tactics used by attackers. + +### Possible investigation steps + +- Review the process executable path to confirm if it matches any known masquerading patterns, such as unexpected directories containing "Program Files" in their path. +- Check the parent process of the suspicious executable to determine how it was launched and assess if the parent process is legitimate or potentially malicious. +- Investigate the user account associated with the process execution to determine if it has low privileges and if the activity aligns with typical user behavior. +- Correlate the event with other security logs or alerts from data sources like Microsoft Defender for Endpoint or Sysmon to identify any related suspicious activities or patterns. +- Examine the file hash of the executable to see if it matches known malware signatures or if it has been flagged in threat intelligence databases. +- Assess the network activity associated with the process to identify any unusual outbound connections that could indicate data exfiltration or command-and-control communication. + +### False positive analysis + +- Legitimate software installations or updates may create temporary directories resembling Program Files paths. Users can monitor installation logs and exclude these specific paths if they are verified as part of a legitimate process. +- Some enterprise applications may use custom directories that mimic Program Files for compatibility reasons. IT administrators should document these paths and add them to the exclusion list to prevent false alerts. +- Development environments might create test directories with similar naming conventions. Developers should ensure these paths are excluded during active development phases to avoid unnecessary alerts. +- Security tools or scripts that perform regular checks or updates might execute from non-standard directories. Verify these tools and add their execution paths to the exception list if they are confirmed safe. +- Backup or recovery software might temporarily use directories that resemble Program Files for storing executable files. Confirm the legitimacy of these operations and exclude the paths if they are part of routine backup processes. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity. +- Terminate any suspicious processes identified as executing from masquerading directories to halt any ongoing malicious actions. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or remnants. +- Review and restore any altered system configurations or settings to their original state to ensure system integrity. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement additional monitoring on the affected system and similar environments to detect any recurrence of the threat or similar tactics. +- Update security policies and access controls to prevent unauthorized creation of directories that mimic trusted paths, enhancing defenses against similar masquerading attempts.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_mshta_beacon.toml b/rules/windows/defense_evasion_mshta_beacon.toml index e36fa0afdba..975894325db 100644 --- a/rules/windows/defense_evasion_mshta_beacon.toml +++ b/rules/windows/defense_evasion_mshta_beacon.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/02" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -47,6 +47,39 @@ sequence by process.entity_id with maxspan=10m not process.args : "ADSelfService_Enroll.hta"] [network where host.os.type == "windows" and process.name : "mshta.exe"] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Mshta Making Network Connections + +Mshta.exe is a legitimate Windows utility used to execute Microsoft HTML Application (HTA) files. Adversaries exploit it to run malicious scripts, leveraging its trusted status to bypass security measures. The detection rule identifies suspicious network activity by Mshta.exe, excluding known benign processes, to flag potential threats. This approach helps in identifying unauthorized network connections indicative of malicious intent. + +### Possible investigation steps + +- Review the process tree to understand the parent-child relationship of mshta.exe, focusing on any unusual or unexpected parent processes that are not excluded by the rule, such as Microsoft.ConfigurationManagement.exe or known benign executables. +- Analyze the command-line arguments used by mshta.exe to identify any suspicious or unexpected scripts being executed, especially those not matching the excluded ADSelfService_Enroll.hta. +- Examine the network connections initiated by mshta.exe, including destination IP addresses, domains, and ports, to identify any connections to known malicious or suspicious endpoints. +- Check for any related alerts or logs from the same host around the time of the mshta.exe activity to identify potential lateral movement or additional malicious behavior. +- Investigate the user account associated with the mshta.exe process to determine if it has been compromised or is exhibiting unusual activity patterns. + +### False positive analysis + +- Mshta.exe may be triggered by legitimate software updates or installations, such as those from Microsoft Configuration Management. To handle this, add exceptions for processes with parent names like Microsoft.ConfigurationManagement.exe. +- Certain applications like Amazon Assistant and TeamViewer may use Mshta.exe for legitimate purposes. Exclude these by specifying their executable paths, such as C:\\Amazon\\Amazon Assistant\\amazonAssistantService.exe and C:\\TeamViewer\\TeamViewer.exe. +- Custom scripts or internal tools that utilize HTA files for automation might cause false positives. Identify these scripts and exclude them by their specific arguments, such as ADSelfService_Enroll.hta. +- Regularly review and update the list of exceptions to ensure that only verified benign activities are excluded, minimizing the risk of overlooking genuine threats. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate the mshta.exe process if it is confirmed to be making unauthorized network connections. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious scripts or files. +- Review and analyze the process tree and network connections associated with mshta.exe to identify any additional compromised processes or systems. +- Restore the system from a known good backup if malicious activity is confirmed and cannot be fully remediated. +- Implement application whitelisting to prevent unauthorized execution of mshta.exe and similar system binaries. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_msiexec_child_proc_netcon.toml b/rules/windows/defense_evasion_msiexec_child_proc_netcon.toml index 3ec331c277f..1e6d83350b5 100644 --- a/rules/windows/defense_evasion_msiexec_child_proc_netcon.toml +++ b/rules/windows/defense_evasion_msiexec_child_proc_netcon.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel"] maturity = "production" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." min_stack_version = "8.14.0" -updated_date = "2024/10/15" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -48,6 +48,41 @@ sequence by process.entity_id with maxspan=1m not (process.name : ("rundll32.exe", "regsvr32.exe") and process.args : ("?:\\Program Files\\*", "?:\\Program Files (x86)\\*"))] [any where host.os.type == "windows" and event.category in ("network", "dns") and process.name != null] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 MsiExec Service Child Process With Network Connection + +MsiExec is a Windows utility for installing, maintaining, and removing software. Adversaries exploit it to execute malicious payloads by disguising them as legitimate installations. The detection rule identifies suspicious child processes spawned by MsiExec that initiate network activity, which is atypical for standard installations. By focusing on unusual executable paths and network connections, the rule helps uncover potential misuse indicative of malware delivery or initial access attempts. + +### Possible investigation steps + +- Review the process tree to identify the parent and child processes of the suspicious MsiExec activity, focusing on the process.entity_id and process.parent.name fields to understand the execution flow. +- Examine the process.executable path to determine if it deviates from typical installation paths, as specified in the query, to assess the likelihood of malicious activity. +- Analyze the network or DNS activity associated with the process by reviewing the event.category field for network or dns events, and correlate these with the process.name to identify any unusual or unauthorized connections. +- Check the process.args for any unusual or suspicious command-line arguments that might indicate an attempt to execute malicious payloads or scripts. +- Investigate the host's recent activity and security logs to identify any other indicators of compromise or related suspicious behavior, leveraging data sources like Elastic Defend, Sysmon, or SentinelOne as mentioned in the rule's tags. +- Assess the risk and impact of the detected activity by considering the context of the alert, such as the host's role in the network and any potential data exposure or system compromise. + +### False positive analysis + +- Legitimate software installations or updates may trigger the rule if they involve network activity. Users can create exceptions for known software update processes that are verified as safe. +- Custom enterprise applications that use MsiExec for deployment and require network access might be flagged. Identify these applications and exclude their specific executable paths from the rule. +- Automated deployment tools that utilize MsiExec and perform network operations could be misidentified. Review these tools and whitelist their processes to prevent false alerts. +- Security software or system management tools that leverage MsiExec for legitimate purposes may cause false positives. Confirm these tools' activities and add them to an exclusion list if necessary. +- Regularly review and update the exclusion list to ensure it reflects the current environment and any new legitimate software that may interact with MsiExec. + +### Response and remediation + +- Isolate the affected system from the network immediately to prevent further malicious activity and lateral movement. +- Terminate the suspicious child process spawned by MsiExec to halt any ongoing malicious operations. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious payloads or remnants. +- Review and analyze the process execution and network activity logs to identify any additional indicators of compromise (IOCs) and assess the scope of the intrusion. +- Reset credentials and review access permissions for any accounts that may have been compromised or used during the attack. +- 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 enhanced monitoring and detection rules to identify similar threats in the future, focusing on unusual MsiExec activity and network connections.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_msxsl_network.toml b/rules/windows/defense_evasion_msxsl_network.toml index 513740d35b9..da8423c925e 100644 --- a/rules/windows/defense_evasion_msxsl_network.toml +++ b/rules/windows/defense_evasion_msxsl_network.toml @@ -2,7 +2,7 @@ creation_date = "2020/03/18" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -46,6 +46,40 @@ sequence by process.entity_id "100.64.0.0/10", "192.175.48.0/24","198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", "FF00::/8")] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Network Connection via MsXsl + +MsXsl.exe is a legitimate Windows utility used to transform XML data using XSLT stylesheets. Adversaries exploit it to execute malicious scripts, bypassing security measures. The detection rule identifies suspicious network activity by MsXsl.exe, focusing on connections to non-local IPs, which may indicate unauthorized data exfiltration or command-and-control communication. + +### Possible investigation steps + +- Review the process execution details for msxsl.exe, focusing on the process.entity_id and event.type fields to confirm the process start event and gather initial context. +- Analyze the network connection details, particularly the destination.ip field, to identify the external IP address msxsl.exe attempted to connect to and assess its reputation or any known associations with malicious activity. +- Check for any related alerts or logs involving the same process.entity_id to determine if msxsl.exe has been involved in other suspicious activities or if there are patterns of behavior indicating a broader attack. +- Investigate the parent process of msxsl.exe to understand how it was launched and whether it was initiated by a legitimate application or a potentially malicious script. +- Examine the system for any additional indicators of compromise, such as unusual file modifications or other processes making unexpected network connections, to assess the scope of potential adversarial activity. + +### False positive analysis + +- Legitimate use of msxsl.exe for XML transformations in enterprise applications may trigger alerts. Users should identify and whitelist known applications or processes that use msxsl.exe for legitimate purposes. +- Automated scripts or scheduled tasks that utilize msxsl.exe for data processing can cause false positives. Review and document these tasks, then create exceptions for their network activity. +- Development or testing environments where msxsl.exe is used for debugging or testing XML transformations might be flagged. Ensure these environments are recognized and excluded from monitoring if they are verified as non-threatening. +- Internal network tools or monitoring solutions that leverage msxsl.exe for legitimate network communications should be identified. Add these tools to an exception list to prevent unnecessary alerts. +- Regularly review and update the list of excluded IP addresses to ensure that only trusted and verified internal IPs are exempt from triggering the rule. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized data exfiltration or command-and-control communication. +- Terminate the msxsl.exe process if it is still running to stop any ongoing malicious activity. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious scripts or files associated with msxsl.exe. +- Review and analyze the network logs to identify any other systems that may have been targeted or compromised by similar activity. +- Restore the affected system from a known good backup if any critical system files or configurations have been altered. +- Implement network segmentation to limit the ability of msxsl.exe or similar utilities to make unauthorized external connections in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or data have been impacted.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_parent_process_pid_spoofing.toml b/rules/windows/defense_evasion_parent_process_pid_spoofing.toml index 6cdf87d08fc..a877b60cf48 100644 --- a/rules/windows/defense_evasion_parent_process_pid_spoofing.toml +++ b/rules/windows/defense_evasion_parent_process_pid_spoofing.toml @@ -2,7 +2,7 @@ creation_date = "2021/07/14" integration = ["endpoint"] maturity = "production" -updated_date = "2024/09/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -73,6 +73,42 @@ sequence by host.id, user.id with maxspan=3m "?:\\Windows\\SysWOW64\\WerFault.exe") ] by process.parent.Ext.real.pid ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Parent Process PID Spoofing + +Parent Process PID Spoofing involves manipulating the parent process identifier to disguise the origin of a process, often to bypass security measures or gain elevated privileges. Adversaries exploit this by launching processes with falsified parent PIDs, making them appear benign. The detection rule identifies such anomalies by monitoring process creation events, focusing on unexpected parent-child relationships and unsigned executables, thus flagging potential spoofing attempts. + +### Possible investigation steps + +- Review the process creation event details to identify the specific executable and its path that triggered the alert. Pay attention to the process.executable field to determine if it matches any suspicious patterns like "?:\\\\Users\\\\*.exe" or "?:\\\\Windows\\\\Temp\\\\*.exe". +- Check the process.parent.Ext.real.pid field to confirm if the parent process PID has been spoofed. Investigate the legitimacy of the parent process by examining its name and executable path. +- Analyze the process.code_signature.status field to determine if the executable is unsigned or has a bad digest, which could indicate tampering or a lack of authenticity. +- Investigate the user context by reviewing the user.id field to understand which user account was associated with the process creation. This can help determine if the activity aligns with expected user behavior. +- Correlate the process creation event with other related events on the same host.id within the maxspan of 3 minutes to identify any additional suspicious activities or patterns. +- Examine the integrity level of the process using the process.Ext.token.integrity_level_name field to assess if the process is running with elevated privileges unexpectedly. +- Cross-reference the process with known legitimate applications by checking if the process.pe.original_file_name matches common applications like "winword.exe" or "powershell.exe" to rule out false positives. + +### False positive analysis + +- Processes like msedge.exe with sihost.exe as the parent may trigger false positives. Consider adding exceptions for these specific parent-child relationships if they are common in your environment. +- Executables located in user directories or temporary folders may be flagged if they lack valid code signatures. Regularly review and whitelist known benign applications that operate from these paths. +- Processes with a parent PID mismatch due to legitimate software updates or installations can be mistaken for spoofing. Monitor and document such activities to refine detection rules and reduce false alerts. +- WerFault.exe and its variants are excluded by default, but if other legitimate system processes are frequently flagged, consider expanding the exclusion list to include them. +- Regularly update the list of known safe executables and their expected parent processes to ensure the rule remains effective without generating unnecessary alerts. + +### Response and remediation + +- Isolate the affected host immediately to prevent further spread of the threat. Disconnect the host from the network to contain any potential malicious activity. +- Terminate any suspicious processes identified by the alert, especially those with spoofed parent PIDs or unsigned executables, to halt any ongoing malicious actions. +- Conduct a thorough review of the affected system's process tree and logs to identify any additional malicious processes or indicators of compromise that may have been missed. +- Restore the affected system from a known good backup if any critical system files or configurations have been altered by the threat. +- Update and patch the affected system to the latest security standards to close any vulnerabilities that may have been exploited by the adversary. +- Implement enhanced monitoring on the affected host and similar systems to detect any recurrence of the threat, focusing on process creation events and parent-child process relationships. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_persistence_account_tokenfilterpolicy.toml b/rules/windows/defense_evasion_persistence_account_tokenfilterpolicy.toml index e58222e18b6..7e006d0bd06 100644 --- a/rules/windows/defense_evasion_persistence_account_tokenfilterpolicy.toml +++ b/rules/windows/defense_evasion_persistence_account_tokenfilterpolicy.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende maturity = "production" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." min_stack_version = "8.14.0" -updated_date = "2024/10/15" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -50,6 +50,40 @@ registry where host.os.type == "windows" and event.type == "change" and "MACHINE\\*\\LocalAccountTokenFilterPolicy" ) and registry.data.strings : ("1", "0x00000001") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Local Account TokenFilter Policy Disabled + +The LocalAccountTokenFilterPolicy is a Windows registry setting that, when enabled, allows remote connections from local administrators to use full high-integrity tokens. Adversaries may exploit this to bypass User Account Control (UAC) and gain elevated privileges remotely. The detection rule monitors changes to this registry setting, identifying potential unauthorized modifications that could indicate an attempt to facilitate lateral movement or evade defenses. + +### Possible investigation steps + +- Review the registry event logs to confirm the change to the LocalAccountTokenFilterPolicy setting, specifically looking for entries where the registry.value is "LocalAccountTokenFilterPolicy" and registry.data.strings is "1" or "0x00000001". +- Identify the user account and process responsible for the registry modification by examining the associated event logs for user and process information. +- Check for any recent remote connections to the affected system, focusing on connections initiated by local administrator accounts, to determine if the change was exploited for lateral movement. +- Investigate any other recent registry changes on the host to identify potential patterns of unauthorized modifications that could indicate broader malicious activity. +- Correlate the event with other security alerts or logs from data sources like Elastic Endgame, Elastic Defend, Sysmon, SentinelOne, or Microsoft Defender for Endpoint to gather additional context and assess the scope of the potential threat. +- Assess the system for signs of compromise or malicious activity, such as unusual processes, network connections, or file modifications, that may have occurred around the time of the registry change. + +### False positive analysis + +- Administrative tools or scripts that modify the LocalAccountTokenFilterPolicy for legitimate configuration purposes may trigger alerts. To manage this, identify and document these tools, then create exceptions for their known registry changes. +- System updates or patches that adjust registry settings as part of their installation process can cause false positives. Monitor update schedules and correlate alerts with these activities to determine if they are benign. +- Security software or management solutions that enforce policy changes across endpoints might modify this registry setting. Verify these actions with your IT or security team and consider excluding these processes from triggering alerts. +- Custom scripts or automation tasks used for system hardening or configuration management may alter this setting. Review these scripts and whitelist their expected changes to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Revert the registry setting for LocalAccountTokenFilterPolicy to its default state if it was modified without authorization. +- Conduct a thorough review of recent administrative activities and access logs on the affected system to identify any unauthorized access or changes. +- Reset passwords for all local administrator accounts on the affected system to prevent potential misuse of compromised credentials. +- Deploy endpoint detection and response (EDR) tools to monitor for any further suspicious activities or attempts to modify registry settings. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if the threat is part of a larger attack campaign. +- Implement additional network segmentation and access controls to limit administrative access to critical systems and reduce the risk of similar threats.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_posh_obfuscation.toml b/rules/windows/defense_evasion_posh_obfuscation.toml index a526da2b50a..ee546d65188 100644 --- a/rules/windows/defense_evasion_posh_obfuscation.toml +++ b/rules/windows/defense_evasion_posh_obfuscation.toml @@ -2,7 +2,7 @@ creation_date = "2024/07/03" integration = ["windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -66,6 +66,41 @@ event.category:process and host.os.type:windows and ("rahc" or "ekovin" or "gnirts" or "ecnereferpesobrev" or "ecalper" or "cepsmoc" or "dillehs") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 PowerShell Obfuscated Script + +PowerShell is a powerful scripting language used for task automation and configuration management in Windows environments. Adversaries exploit its flexibility to obfuscate scripts, evading security measures like AMSI. The detection rule identifies obfuscation patterns, such as string manipulation and encoding techniques, to flag potentially malicious scripts, aiding in defense evasion detection. + +### Possible investigation steps + +- Review the PowerShell script block text captured in the alert to identify any suspicious patterns or obfuscation techniques, such as string manipulation or encoding methods like "[string]::join" or "-Join". +- Check the process execution details, including the parent process and command line arguments, to understand the context in which the PowerShell script was executed. +- Investigate the source and destination of the script execution by examining the host and user details to determine if the activity aligns with expected behavior or if it originates from an unusual or unauthorized source. +- Analyze any network connections or file modifications associated with the PowerShell process to identify potential data exfiltration or lateral movement activities. +- Correlate the alert with other security events or logs, such as Windows Event Logs or network traffic logs, to gather additional context and identify any related suspicious activities. +- Assess the risk and impact of the detected activity by considering the severity and risk score provided in the alert, and determine if immediate remediation actions are necessary. + +### False positive analysis + +- Legitimate administrative scripts may use string manipulation and encoding techniques for benign purposes, such as data processing or configuration management. Review the context of the script execution and verify the source and intent before flagging it as malicious. +- Scripts that automate complex tasks might use obfuscation-like patterns to handle data securely or efficiently. Consider whitelisting known scripts or trusted sources to reduce false positives. +- Development and testing environments often run scripts with obfuscation patterns for testing purposes. Exclude these environments from the rule or create exceptions for specific users or groups involved in development. +- Security tools and monitoring solutions might generate PowerShell scripts with obfuscation patterns as part of their normal operation. Identify these tools and exclude their activities from triggering the rule. +- Regularly update the list of exceptions and whitelisted scripts to ensure that new legitimate scripts are not mistakenly flagged as threats. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of potentially malicious scripts. +- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing malicious activity. +- Conduct a thorough review of the PowerShell script block logs to identify and remove any obfuscated scripts or malicious code remnants. +- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised. +- Update and patch the affected system to ensure all security vulnerabilities are addressed, reducing the risk of exploitation. +- Monitor the system and network for any signs of re-infection or similar obfuscation patterns to ensure the threat has been fully mitigated. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules/windows/defense_evasion_proxy_execution_via_msdt.toml b/rules/windows/defense_evasion_proxy_execution_via_msdt.toml index 01bf525400c..d2cffe567b0 100644 --- a/rules/windows/defense_evasion_proxy_execution_via_msdt.toml +++ b/rules/windows/defense_evasion_proxy_execution_via_msdt.toml @@ -2,7 +2,7 @@ creation_date = "2022/05/31" integration = ["endpoint", "windows", "m365_defender"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -52,6 +52,41 @@ process where host.os.type == "windows" and event.type == "start" and (process.pe.original_file_name == "msdt.exe" and not process.executable : ("?:\\Windows\\system32\\msdt.exe", "?:\\Windows\\SysWOW64\\msdt.exe")) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Microsoft Diagnostics Wizard Execution + +The Microsoft Diagnostics Troubleshooting Wizard (MSDT) is a legitimate tool used for diagnosing and resolving issues within Windows environments. However, adversaries can exploit MSDT to execute malicious commands by manipulating its process arguments, effectively using it as a proxy for harmful activities. The detection rule identifies such abuse by monitoring for unusual execution patterns, such as atypical file paths, unexpected parent processes, and non-standard executable locations, which are indicative of potential misuse. This proactive detection helps in mitigating risks associated with defense evasion tactics. + +### Possible investigation steps + +- Review the process arguments to identify any suspicious patterns, such as "IT_RebrowseForFile=*", "ms-msdt:/id", "ms-msdt:-id", or "*FromBase64*", which may indicate malicious intent. +- Examine the parent process of msdt.exe to determine if it was launched by an unexpected or potentially malicious process like cmd.exe, powershell.exe, or mshta.exe. +- Check the file path of the msdt.exe executable to ensure it matches the standard locations (?:\\Windows\\system32\\msdt.exe or ?:\\Windows\\SysWOW64\\msdt.exe) and investigate any deviations. +- Investigate the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Correlate the event with other security alerts or logs from data sources like Microsoft Defender for Endpoint or Sysmon to identify any related malicious activities or patterns. +- Assess the risk score and severity of the alert to prioritize the investigation and determine if immediate action is required to mitigate potential threats. + +### False positive analysis + +- Legitimate troubleshooting activities by IT staff using MSDT may trigger alerts. To manage this, create exceptions for known IT user accounts or specific machines frequently used for diagnostics. +- Automated scripts or software updates that utilize MSDT for legitimate purposes can cause false positives. Identify these scripts and whitelist their execution paths or parent processes. +- Custom diagnostic tools that leverage MSDT might be flagged. Review these tools and exclude their specific process arguments or executable paths if they are verified as safe. +- Non-standard installations of MSDT in custom environments could be misidentified. Ensure that any legitimate non-standard paths are documented and excluded from monitoring. +- Frequent use of MSDT in virtualized environments for testing purposes may lead to alerts. Consider excluding these environments or specific virtual machines from the rule. + +### Response and remediation + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate the suspicious msdt.exe process to stop any ongoing malicious execution. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes. +- Review and analyze the process arguments and parent processes associated with the msdt.exe execution to identify potential entry points or related malicious activities. +- Restore any affected files or system components from a known good backup to ensure system integrity. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Implement enhanced monitoring and logging for msdt.exe and related processes to detect and respond to similar threats in the future.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_reg_disable_enableglobalqueryblocklist.toml b/rules/windows/defense_evasion_reg_disable_enableglobalqueryblocklist.toml index e42b52ac964..04f0884e0e9 100644 --- a/rules/windows/defense_evasion_reg_disable_enableglobalqueryblocklist.toml +++ b/rules/windows/defense_evasion_reg_disable_enableglobalqueryblocklist.toml @@ -2,7 +2,7 @@ creation_date = "2024/05/31" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -55,6 +55,40 @@ registry where host.os.type == "windows" and event.type == "change" and (registry.value : "GlobalQueryBlockList" and not registry.data.strings : "wpad") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 DNS Global Query Block List Modified or Disabled + +The DNS Global Query Block List (GQBL) is a security feature in Windows environments that blocks the resolution of specific DNS names, such as WPAD, to prevent attacks like spoofing. Adversaries with elevated privileges can alter or disable the GQBL, enabling them to exploit default settings for privilege escalation. The detection rule monitors registry changes indicating such modifications, flagging potential defense evasion attempts. + +### Possible investigation steps + +- Review the registry event logs to confirm the specific changes made to the DNS Global Query Block List, focusing on the registry values "EnableGlobalQueryBlockList" and "GlobalQueryBlockList". +- Identify the user account associated with the registry change event to determine if the account has elevated privileges, such as DNSAdmins, which could indicate potential misuse. +- Check for any recent changes in user permissions or group memberships that might have granted the necessary privileges to modify the GQBL. +- Investigate any other suspicious activities or alerts related to the same user or host around the time of the registry change to identify potential lateral movement or privilege escalation attempts. +- Correlate the event with network traffic logs to detect any unusual DNS queries or attempts to resolve WPAD or other blocked names, which could suggest exploitation attempts. +- Review system and security logs for any signs of unauthorized access or other indicators of compromise on the affected host. + +### False positive analysis + +- Legitimate administrative changes to DNS settings by IT staff can trigger the rule. To manage this, create exceptions for known maintenance windows or authorized personnel making these changes. +- Automated scripts or software updates that modify DNS settings might be flagged. Identify and whitelist these processes if they are verified as safe and necessary for system operations. +- Changes made by security tools or network management software that adjust DNS settings for legitimate reasons can be mistaken for threats. Review and exclude these tools from monitoring if they are part of the organization's approved security infrastructure. +- In environments where WPAD is intentionally used, the absence of "wpad" in the GlobalQueryBlockList might be a normal configuration. Document and exclude these cases if they align with the organization's network design and security policies. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement. +- Revert any unauthorized changes to the DNS Global Query Block List by restoring the registry settings to their default state, ensuring WPAD and other critical entries are included. +- Conduct a thorough review of user accounts with elevated privileges, such as DNSAdmins, to identify any unauthorized access or privilege escalation. Revoke unnecessary privileges and reset credentials as needed. +- Deploy endpoint detection and response (EDR) tools to scan the affected system for additional indicators of compromise or malicious activity, focusing on defense evasion techniques. +- Monitor network traffic for signs of WPAD spoofing or other related attacks, and implement network segmentation to limit the impact of potential threats. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Update security policies and procedures to include specific measures for monitoring and protecting the DNS Global Query Block List, ensuring rapid detection and response to similar threats in the future.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_root_dir_ads_creation.toml b/rules/windows/defense_evasion_root_dir_ads_creation.toml index 3da978e81f0..0d05950312b 100644 --- a/rules/windows/defense_evasion_root_dir_ads_creation.toml +++ b/rules/windows/defense_evasion_root_dir_ads_creation.toml @@ -2,7 +2,7 @@ creation_date = "2024/03/14" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -50,6 +50,41 @@ any where host.os.type == "windows" and event.category in ("file", "process") an (event.type == "start" and process.executable regex~ """[A-Z]:\\:.+""") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Alternate Data Stream Creation/Execution at Volume Root Directory + +Alternate Data Streams (ADS) in Windows allow files to contain multiple streams of data, which can be exploited by adversaries to conceal malicious tools or data. By creating or executing ADS at the root of a volume, attackers can evade detection by standard system utilities. The detection rule identifies suspicious ADS activity by monitoring file creation and process execution patterns at the volume root, flagging potential defense evasion attempts. + +### Possible investigation steps + +- Review the alert details to identify the specific file path or process executable that triggered the alert, focusing on the volume root directory pattern [A-Z]:\\\\:. +- Check the file or process creation timestamp to determine when the suspicious activity occurred and correlate it with other events or activities on the system around the same time. +- Investigate the file or process owner and the user account associated with the activity to assess if it aligns with expected behavior or if it indicates potential unauthorized access. +- Examine the file or process for known indicators of compromise (IOCs) or signatures of malicious activity using threat intelligence sources or antivirus tools. +- Analyze the system for additional signs of compromise, such as unexpected network connections, registry changes, or other suspicious files, to determine if the ADS activity is part of a larger attack. +- Review system logs and security tools for any related alerts or anomalies that could provide further context or evidence of malicious intent. + +### False positive analysis + +- System utilities or legitimate applications may create ADS at the volume root for benign purposes, such as storing metadata or configuration data. Review the source of the ADS creation to determine if it is associated with known safe applications. +- Backup or disk management software might use ADS to store additional information about files. Verify if the detected activity aligns with scheduled backup operations or disk management tasks. +- Some security tools or system monitoring applications may use ADS for logging or tracking purposes. Cross-reference the process or file path with known security tools to rule out false positives. +- If a specific application is consistently triggering alerts due to its use of ADS, consider creating an exception for that application's process or file path in your monitoring solution to reduce noise. +- Regularly update your list of known safe applications and processes that interact with ADS to ensure that legitimate activities are not flagged as suspicious. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Use endpoint detection and response (EDR) tools to terminate any suspicious processes associated with the identified ADS activity. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any hidden malicious files or tools. +- Review and delete any unauthorized or suspicious ADS found at the volume root directory to eliminate potential hiding places for malware. +- Restore affected files from a known good backup to ensure system integrity and remove any compromised data. +- Monitor network traffic for unusual patterns or connections that may indicate ongoing malicious activity or data exfiltration attempts. +- Escalate the incident to the security operations center (SOC) or relevant IT security team for further investigation and to assess the need for broader organizational response measures.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_sc_sdset.toml b/rules/windows/defense_evasion_sc_sdset.toml index c5be261625f..cda6a7fb1c3 100644 --- a/rules/windows/defense_evasion_sc_sdset.toml +++ b/rules/windows/defense_evasion_sc_sdset.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende maturity = "production" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." min_stack_version = "8.14.0" -updated_date = "2024/11/02" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -47,6 +47,42 @@ process where host.os.type == "windows" and event.type == "start" and process.args : "sdset" and process.args : "*D;*" and process.args : ("*;IU*", "*;SU*", "*;BA*", "*;SY*", "*;WD*") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Service DACL Modification via sc.exe + +The `sc.exe` utility in Windows is used to manage services, including modifying their Discretionary Access Control Lists (DACLs). Adversaries may exploit this to alter service permissions, making them unmanageable or hidden. The detection rule identifies such modifications by monitoring for specific command patterns that indicate DACL changes, focusing on access denial to key user groups, thus flagging potential defense evasion attempts. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of "sc.exe" with the "sdset" argument, indicating a potential DACL modification attempt. +- Examine the specific arguments used with "sc.exe" to identify which user groups (e.g., IU, SU, BA, SY, WD) were targeted for access denial. +- Check the process execution timeline to determine if this activity coincides with other suspicious behavior or unauthorized access attempts. +- Investigate the user account associated with the process execution to assess if it has the necessary privileges and if the activity aligns with their typical behavior. +- Correlate this event with other security alerts or logs from data sources like Elastic Endgame, Sysmon, or Microsoft Defender for Endpoint to identify potential patterns or related incidents. +- Assess the impact on the affected service by verifying its current state and functionality, ensuring it is not hidden or unmanageable. +- If necessary, consult with system administrators to understand the legitimate need for such modifications and confirm if the activity was authorized. + +### False positive analysis + +- Routine administrative tasks using sc.exe to modify service permissions may trigger the rule. Review the context of the command and verify if it aligns with standard IT maintenance activities. +- Automated scripts or software deployment tools that adjust service DACLs for legitimate configuration purposes can cause false positives. Identify these scripts and consider excluding their specific command patterns from the rule. +- Security software updates or patches that modify service permissions as part of their installation process might be flagged. Confirm the legitimacy of the update and exclude the associated process arguments if necessary. +- Custom applications that require specific service permissions for functionality may inadvertently match the detection criteria. Validate the application's behavior and create exceptions for its known safe operations. +- Regular audits or compliance checks that involve service DACL modifications could be misinterpreted as malicious. Document these activities and adjust the rule to ignore them when performed by authorized personnel. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or changes to service permissions. +- Terminate any suspicious processes related to sc.exe that are actively modifying service DACLs to stop ongoing malicious activity. +- Restore the original DACL settings for the affected services using a known good configuration or backup to ensure proper access control is reinstated. +- Conduct a thorough review of user accounts and permissions to identify and revoke any unauthorized access that may have been granted during the attack. +- Implement additional monitoring on the affected system and similar systems to detect any further attempts to modify service DACLs, using enhanced logging and alerting mechanisms. +- 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. +- Review and update endpoint protection policies to prevent similar threats in the future, ensuring that all systems are equipped with the latest security patches and configurations.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_sccm_scnotification_dll.toml b/rules/windows/defense_evasion_sccm_scnotification_dll.toml index 8abfbc3726a..e08c10a7bac 100644 --- a/rules/windows/defense_evasion_sccm_scnotification_dll.toml +++ b/rules/windows/defense_evasion_sccm_scnotification_dll.toml @@ -2,7 +2,7 @@ creation_date = "2024/04/17" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -36,6 +36,39 @@ query = ''' library where host.os.type == "windows" and process.name : "SCNotification.exe" and (dll.Ext.relative_file_creation_time < 86400 or dll.Ext.relative_file_name_modify_time <= 500) and dll.code_signature.status != "trusted" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Windows Session Hijacking via CcmExec + +CcmExec, part of Microsoft's System Center Configuration Manager, manages client configurations and software updates. Adversaries may exploit it by loading malicious DLLs into SCNotification.exe, a process associated with user notifications. This detection rule identifies suspicious DLL activity, such as recent file creation or modification and untrusted signatures, indicating potential session hijacking attempts. + +### Possible investigation steps + +- Review the alert details to confirm that the process name is SCNotification.exe and check the associated DLL file's creation or modification times to ensure they match the query conditions. +- Investigate the untrusted DLL by examining its file path, hash, and any available metadata to determine its origin and legitimacy. +- Check the code signature status of the DLL to understand why it is marked as untrusted and verify if it has been tampered with or is from an unknown publisher. +- Analyze recent system logs and user activity around the time the DLL was loaded to identify any suspicious behavior or unauthorized access attempts. +- Correlate the alert with other security events or alerts from the same host to identify potential patterns or related incidents that could indicate a broader attack. + +### False positive analysis + +- Legitimate software updates or installations may trigger the rule if they involve recent DLL file creation or modification. Users can create exceptions for known software update processes to prevent unnecessary alerts. +- System maintenance activities, such as patch management or configuration changes, might cause SCNotification.exe to load new DLLs. Exclude these activities by identifying and whitelisting trusted maintenance operations. +- Custom or in-house applications that are not signed by a recognized authority may be flagged. Ensure these applications are signed with a trusted certificate or add them to an allowlist to avoid false positives. +- Security tools or monitoring software that interact with SCNotification.exe could be mistakenly identified. Verify these tools and exclude them from the rule if they are deemed safe and necessary for operations. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the attacker. +- Terminate the SCNotification.exe process to stop the execution of the untrusted DLL and prevent further malicious activity. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious files or software. +- Review and restore any modified or corrupted system files from a known good backup to ensure system integrity. +- Investigate the source of the untrusted DLL and remove any unauthorized software or scripts that may have facilitated its introduction. +- Implement application whitelisting to prevent unauthorized DLLs from being loaded by SCNotification.exe or other critical processes in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_scheduledjobs_at_protocol_enabled.toml b/rules/windows/defense_evasion_scheduledjobs_at_protocol_enabled.toml index 7d5d97ca9d5..ed84b7eb9db 100644 --- a/rules/windows/defense_evasion_scheduledjobs_at_protocol_enabled.toml +++ b/rules/windows/defense_evasion_scheduledjobs_at_protocol_enabled.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/23" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -45,6 +45,40 @@ registry where host.os.type == "windows" and event.type == "change" and "MACHINE\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Schedule\\Configuration\\EnableAt" ) and registry.data.strings : ("1", "0x00000001") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Scheduled Tasks AT Command Enabled + +The AT command, a legacy Windows utility, schedules tasks for execution, often used for automation. Despite its deprecation post-Windows 8, it remains for compatibility, posing a security risk. Attackers exploit it to maintain persistence or move laterally. The detection rule monitors registry changes enabling this command, flagging potential misuse by checking specific registry paths and values indicative of enabling the AT command. + +### Possible investigation steps + +- Review the registry event logs to confirm the change in the registry path "HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Schedule\\Configuration\\EnableAt" and verify if the value was set to "1" or "0x00000001". +- Identify the user account and process responsible for the registry change by examining the event logs for associated user and process information. +- Check for any scheduled tasks created or modified around the time of the registry change to determine if the AT command was used to schedule any tasks. +- Investigate the system for any signs of lateral movement or persistence mechanisms that may have been established using the AT command. +- Correlate the event with other security alerts or logs from data sources like Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender for Endpoint, or SentinelOne to gather additional context and assess the scope of potential malicious activity. + +### False positive analysis + +- System administrators or IT management tools may enable the AT command for legacy support or compatibility testing. Verify if the change aligns with scheduled maintenance or updates. +- Some enterprise environments might have legacy applications that rely on the AT command for task scheduling. Confirm with application owners if such dependencies exist and document them. +- Security software or monitoring tools might trigger registry changes as part of their normal operation. Cross-reference with logs from these tools to ensure the change is benign. +- If a specific user or system frequently triggers this alert without malicious intent, consider creating an exception for that user or system in your monitoring solution to reduce noise. +- Regularly review and update the list of exceptions to ensure they remain relevant and do not inadvertently allow malicious activity. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further lateral movement or persistence by the attacker. +- Review the registry changes identified in the alert to confirm unauthorized enabling of the AT command. Revert the registry setting to its secure state by setting the value to "0" or "0x00000000". +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious software or scripts. +- Investigate user accounts and permissions on the affected system to ensure no unauthorized accounts or privilege escalations have occurred. Reset passwords for any compromised accounts. +- Monitor network traffic and logs for any signs of data exfiltration or communication with known 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 affected. +- Implement enhanced monitoring and alerting for similar registry changes across the network to detect and respond to future attempts promptly.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_script_via_html_app.toml b/rules/windows/defense_evasion_script_via_html_app.toml index 12b49fd1160..b3853ec371a 100644 --- a/rules/windows/defense_evasion_script_via_html_app.toml +++ b/rules/windows/defense_evasion_script_via_html_app.toml @@ -4,7 +4,7 @@ integration = ["windows", "system", "sentinel_one_cloud_funnel", "m365_defender" maturity = "production" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." min_stack_version = "8.14.0" -updated_date = "2024/10/15" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -79,6 +79,39 @@ process where host.os.type == "windows" and event.type == "start" and process.args : ("?:\\Users\\*\\Temp\\7z*", "?:\\Users\\*\\Temp\\Rar$*", "?:\\Users\\*\\Temp\\Temp?_*", "?:\\Users\\*\\Temp\\BNZ.*")) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Script Execution via Microsoft HTML Application + +Microsoft HTML Applications (HTA) allow scripts to run in a trusted environment, often using utilities like `rundll32.exe` or `mshta.exe`. Adversaries exploit this by executing malicious scripts under the guise of legitimate processes, bypassing defenses. The detection rule identifies suspicious script execution patterns, such as unusual command lines or execution from common download locations, to flag potential abuse. + +### Possible investigation steps + +- Review the process command line details to identify any suspicious patterns or indicators of malicious activity, such as the presence of script execution commands like "eval", "GetObject", or "WScript.Shell". +- Check the parent process executable path to determine if the process was spawned by a known legitimate application or if it deviates from expected behavior, especially if it is not from the specified exceptions like Citrix, Microsoft Office, or Quokka.Works GTInstaller. +- Investigate the origin of the HTA file, particularly if it was executed from common download locations like the Downloads folder or temporary archive extraction paths, to assess if it was downloaded from the internet or extracted from an archive. +- Analyze the process arguments and count to identify any unusual or unexpected parameters that could indicate malicious intent, especially if the process name is "mshta.exe" and the command line does not include typical HTA or HTM file references. +- Correlate the event with other security logs and alerts from data sources like Sysmon, SentinelOne, or Microsoft Defender for Endpoint to gather additional context and determine if this activity is part of a broader attack pattern. + +### False positive analysis + +- Execution of legitimate scripts by enterprise applications like Citrix, Microsoft Office, or Quokka.Works GTInstaller can trigger false positives. Users can mitigate this by adding these applications to the exclusion list in the detection rule. +- Scripts executed by mshta.exe that do not involve malicious intent, such as internal web applications or administrative scripts, may be flagged. Users should review these scripts and, if deemed safe, exclude them based on specific command line patterns or parent processes. +- HTA files downloaded from trusted internal sources or vendors might be mistakenly identified as threats. Users can create exceptions for these sources by specifying trusted download paths or file hashes. +- Temporary files created by legitimate software installations or updates in user temp directories can be misinterpreted as malicious. Users should monitor these activities and exclude known safe processes or directories from the detection rule. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further spread of the malicious script or unauthorized access. +- Terminate any suspicious processes identified by the detection rule, specifically those involving `rundll32.exe` or `mshta.exe` with unusual command lines. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or scripts. +- Review and analyze the command lines and scripts executed to understand the scope and intent of the attack, and identify any additional compromised systems. +- Restore the affected system from a known good backup if malicious activity is confirmed and cannot be fully remediated. +- Implement network segmentation to limit the ability of similar threats to propagate across the network in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or data have been compromised.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_sip_provider_mod.toml b/rules/windows/defense_evasion_sip_provider_mod.toml index 64d6862f7ec..f729e670df1 100644 --- a/rules/windows/defense_evasion_sip_provider_mod.toml +++ b/rules/windows/defense_evasion_sip_provider_mod.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/20" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -48,6 +48,40 @@ registry where host.os.type == "windows" and event.type == "change" and registry not (process.name : "msiexec.exe" and registry.data.strings : "mso.dll") and not (process.name : "regsvr32.exe" and registry.data.strings == "WINTRUST.DLL") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 SIP Provider Modification + +Subject Interface Package (SIP) providers are integral to Windows' cryptographic system, ensuring file signature validation. Adversaries may modify SIP providers to bypass these checks, facilitating unauthorized code execution. The detection rule identifies suspicious registry changes linked to SIP providers, excluding benign processes, to flag potential defense evasion attempts. + +### Possible investigation steps + +- Review the registry path and value changes to confirm if they match the suspicious patterns specified in the query, such as modifications under the paths related to CryptSIPDllPutSignedDataMsg or Trust FinalPolicy. +- Identify the process responsible for the registry change by examining the process name and compare it against the exclusions in the query, ensuring it is not a benign process like msiexec.exe or regsvr32.exe. +- Investigate the DLL file specified in the registry change to determine its legitimacy, checking its digital signature and origin. +- Correlate the event with other security logs or alerts from data sources like Sysmon or Microsoft Defender for Endpoint to identify any related suspicious activities or patterns. +- Assess the risk context by considering the host's role and any recent changes or incidents that might explain the registry modification, ensuring it aligns with expected behavior or authorized changes. + +### False positive analysis + +- Installation or update processes like msiexec.exe may trigger registry changes as part of legitimate software installations. Exclude these by adding exceptions for msiexec.exe when registry data strings include mso.dll. +- System maintenance tasks using regsvr32.exe might modify SIP provider-related registry entries. Exclude regsvr32.exe when registry data strings match WINTRUST.DLL to prevent false alerts. +- Regular updates or patches from trusted software vendors may alter SIP provider registry entries. Monitor and document these changes to establish a baseline of expected behavior, allowing for informed exclusions. +- Security software or endpoint protection solutions might interact with SIP provider settings as part of their normal operation. Identify and whitelist these processes to reduce unnecessary alerts. +- Custom enterprise applications with legitimate needs to modify cryptographic settings should be reviewed and, if verified as safe, added to an exclusion list to prevent disruption. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or code execution. +- Terminate any suspicious processes identified in the alert, such as those not typically associated with legitimate SIP provider modifications. +- Restore the modified registry entries to their original state using a known good backup or by manually correcting the entries to ensure the integrity of the SIP providers. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious software that may have been introduced. +- Review and update endpoint protection policies to ensure that similar unauthorized modifications are detected and blocked in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Document the incident details, including the steps taken for containment and remediation, to enhance future response efforts and update threat intelligence databases.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_solarwinds_backdoor_service_disabled_via_registry.toml b/rules/windows/defense_evasion_solarwinds_backdoor_service_disabled_via_registry.toml index 14445099941..e7a1d34f75c 100644 --- a/rules/windows/defense_evasion_solarwinds_backdoor_service_disabled_via_registry.toml +++ b/rules/windows/defense_evasion_solarwinds_backdoor_service_disabled_via_registry.toml @@ -2,7 +2,7 @@ creation_date = "2020/12/14" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -56,6 +56,41 @@ registry where host.os.type == "windows" and event.type == "change" and registry ) and registry.data.strings : ("4", "0x00000004") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 SolarWinds Process Disabling Services via Registry + +SolarWinds software is integral for network management, often requiring deep system access. Adversaries may exploit this by altering registry settings to disable critical services, evading detection. The detection rule identifies changes to service start types by specific SolarWinds processes, flagging potential misuse aimed at disabling security defenses. This proactive monitoring helps mitigate risks associated with unauthorized registry modifications. + +### Possible investigation steps + +- Review the process name involved in the alert to confirm it matches one of the specified SolarWinds processes, such as "SolarWinds.BusinessLayerHost*.exe" or "NetFlowService*.exe". +- Examine the registry path in the alert to ensure it corresponds to the critical service start type locations, such as "HKLM\\\\SYSTEM\\\\*ControlSet*\\\\Services\\\\*\\\\Start". +- Check the registry data value to verify if it has been set to "4" (disabled), indicating a potential attempt to disable a service. +- Investigate the timeline of the registry change event to identify any preceding or subsequent suspicious activities on the host. +- Correlate the alert with other security logs or alerts from data sources like Sysmon or Microsoft Defender for Endpoint to identify any related malicious activities or patterns. +- Assess the impacted service to determine its role in security operations and evaluate the potential impact of it being disabled. +- Contact the system owner or administrator to verify if the registry change was authorized or part of a legitimate maintenance activity. + +### False positive analysis + +- Routine updates or maintenance by SolarWinds software may trigger registry changes. Verify if the process corresponds to a scheduled update or maintenance task and consider excluding these specific processes during known maintenance windows. +- Legitimate configuration changes by IT administrators using SolarWinds tools can appear as registry modifications. Confirm with the IT team if the changes align with authorized configuration activities and create exceptions for these known activities. +- Automated scripts or tools that utilize SolarWinds processes for legitimate network management tasks might cause false positives. Review the scripts or tools in use and whitelist them if they are verified as safe and necessary for operations. +- Temporary service modifications for troubleshooting purposes by SolarWinds processes can be mistaken for malicious activity. Ensure that any troubleshooting activities are documented and create temporary exceptions during these periods. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized registry modifications and potential lateral movement by the adversary. +- Terminate any suspicious SolarWinds processes identified in the alert, such as "SolarWinds.BusinessLayerHost*.exe" or "NetFlowService*.exe", to halt any ongoing malicious activity. +- Restore the registry settings for the affected services to their original state, ensuring that critical security services are re-enabled and configured to start automatically. +- Conduct a thorough review of the affected system for additional signs of compromise, including unauthorized user accounts, scheduled tasks, or other persistence mechanisms. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach. +- Implement enhanced monitoring on the affected system and similar environments to detect any future unauthorized registry changes, leveraging data sources like Sysmon and Microsoft Defender for Endpoint. +- Review and update access controls and permissions for SolarWinds processes to limit their ability to modify critical system settings, reducing the risk of future exploitation.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_suspicious_execution_from_mounted_device.toml b/rules/windows/defense_evasion_suspicious_execution_from_mounted_device.toml index 4fbeafb570a..db9d7220038 100644 --- a/rules/windows/defense_evasion_suspicious_execution_from_mounted_device.toml +++ b/rules/windows/defense_evasion_suspicious_execution_from_mounted_device.toml @@ -2,7 +2,7 @@ creation_date = "2021/05/28" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -51,6 +51,41 @@ process where host.os.type == "windows" and event.type == "start" and process.ex process.name : ("rundll32.exe", "mshta.exe", "powershell.exe", "pwsh.exe", "cmd.exe", "regsvr32.exe", "cscript.exe", "wscript.exe") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Execution from a Mounted Device + +In Windows environments, script interpreters and signed binaries are essential for executing legitimate tasks. However, adversaries can exploit these by launching them from non-standard directories, such as mounted devices, to bypass security measures. The detection rule identifies such anomalies by monitoring processes initiated from unexpected directories, especially when triggered by common parent processes like explorer.exe, thus flagging potential defense evasion attempts. + +### Possible investigation steps + +- Review the process details to confirm the executable path and working directory, ensuring they match the criteria of being launched from a non-standard directory (e.g., not from "C:\\\\"). +- Investigate the parent process, explorer.exe, to determine if there are any unusual activities or user actions that might have triggered the suspicious execution. +- Check the user account associated with the process to verify if the activity aligns with their typical behavior or if the account might be compromised. +- Analyze the command line arguments used by the suspicious process to identify any potentially malicious scripts or commands being executed. +- Correlate the event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise. +- Examine the mounted device from which the process was executed to determine its origin, legitimacy, and any associated files that might be malicious. + +### False positive analysis + +- Legitimate software installations or updates may trigger the rule if they are executed from a mounted device. Users can create exceptions for known software update processes that are verified as safe. +- Portable applications running from USB drives or external storage can be flagged. To mitigate this, users should whitelist specific applications that are frequently used and deemed non-threatening. +- IT administrative scripts executed from network shares or mounted drives for maintenance tasks might be detected. Users can exclude these scripts by specifying trusted network paths or script names. +- Development environments where scripts are tested from non-standard directories can cause alerts. Developers should ensure their working directories are recognized as safe or use designated development machines with adjusted monitoring rules. +- Backup or recovery operations that utilize mounted devices for script execution may be misidentified. Users should identify and exclude these operations by defining exceptions for known backup tools and processes. + +### Response and remediation + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified by the detection rule, such as those initiated by script interpreters or signed binaries from non-standard directories. +- Conduct a forensic analysis of the mounted device and the affected system to identify any malicious payloads or scripts and remove them. +- Review and restore any altered system configurations or registry settings to their original state to ensure system integrity. +- Update and patch the system to close any vulnerabilities that may have been exploited by the attacker. +- Monitor for any recurrence of similar activities by enhancing logging and alerting mechanisms, focusing on process execution from non-standard directories. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_suspicious_managedcode_host_process.toml b/rules/windows/defense_evasion_suspicious_managedcode_host_process.toml index ef418dc1c99..34412f928c2 100644 --- a/rules/windows/defense_evasion_suspicious_managedcode_host_process.toml +++ b/rules/windows/defense_evasion_suspicious_managedcode_host_process.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/21" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2024/10/31" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -49,6 +49,41 @@ file where host.os.type == "windows" and event.type != "deletion" and "cmstp.exe.log", "regsvr32.exe.log") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Managed Code Hosting Process + +Managed code hosting processes like wscript.exe, cscript.exe, and others are integral to executing scripts and managing code in Windows environments. Adversaries exploit these processes for code injection or executing malicious scripts, often evading detection. The detection rule identifies anomalies by monitoring specific process logs, flagging high-risk activities that deviate from normal operations, thus alerting analysts to potential threats. + +### Possible investigation steps + +- Review the process logs for the specific file names flagged in the alert, such as wscript.exe.log or cscript.exe.log, to identify any unusual or unauthorized script executions. +- Correlate the suspicious process activity with user account activity to determine if the actions were performed by a legitimate user or potentially compromised account. +- Examine the parent process of the flagged managed code hosting process to identify if it was spawned by a legitimate application or a known malicious process. +- Check for any recent changes or modifications to the scripts or executables associated with the flagged process to identify potential tampering or unauthorized updates. +- Investigate network connections initiated by the suspicious process to detect any communication with known malicious IP addresses or domains. +- Utilize threat intelligence sources to cross-reference any identified indicators of compromise (IOCs) such as file hashes or IP addresses associated with the suspicious process. + +### False positive analysis + +- Legitimate administrative scripts may trigger alerts when executed by IT personnel using wscript.exe or cscript.exe. To manage this, create exceptions for known scripts and trusted user accounts. +- Automated system maintenance tasks using mshta.exe or wmic.exe can be flagged as suspicious. Identify and whitelist these tasks if they are part of regular system operations. +- Software updates or installations might use svchost.exe or dllhost.exe, leading to false positives. Monitor and document these activities, then exclude them from alerts if they are verified as safe. +- Custom applications that rely on cmstp.exe or regsvr32.exe for legitimate purposes can be mistaken for threats. Validate these applications and add them to an exception list to prevent unnecessary alerts. +- Regularly review and update the exception list to ensure it reflects current legitimate activities, minimizing the risk of overlooking genuine threats. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Terminate the suspicious process identified in the alert, such as wscript.exe, cscript.exe, or any other flagged process, to stop any ongoing malicious activity. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious files or scripts. +- Review and restore any system or application configurations that may have been altered by the malicious process to ensure system integrity. +- Collect and preserve relevant logs and forensic data from the affected system for further analysis and to aid in understanding the scope and impact of the incident. +- Notify the security operations center (SOC) or incident response team to escalate the incident for further investigation and to determine if additional systems are affected. +- Implement additional monitoring and detection rules to enhance visibility and prevent similar threats in the future, focusing on the specific processes and behaviors identified in the alert.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_suspicious_scrobj_load.toml b/rules/windows/defense_evasion_suspicious_scrobj_load.toml index 02c9c309f06..b85cf9342dd 100644 --- a/rules/windows/defense_evasion_suspicious_scrobj_load.toml +++ b/rules/windows/defense_evasion_suspicious_scrobj_load.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/02" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -57,6 +57,40 @@ any where host.os.type == "windows" and "?:\\Windows\\System32\\wbem\\WMIADAP.exe", "?:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Script Object Execution + +The scrobj.dll is a legitimate Windows library used for executing scriptlets, often in automation tasks. However, adversaries can exploit it to run malicious scripts within trusted processes, evading detection. The detection rule identifies unusual loading of scrobj.dll in non-standard processes, flagging potential misuse. By excluding common executables, it focuses on anomalous activity, aiding in early threat detection. + +### Possible investigation steps + +- Review the process executable path to confirm if it is indeed non-standard for loading scrobj.dll, as specified in the query. +- Check the parent process of the flagged executable to understand how it was initiated and assess if it aligns with typical behavior. +- Investigate the user account associated with the process execution to determine if it is a legitimate user or potentially compromised. +- Analyze recent activity on the host for any other suspicious behavior or anomalies that might correlate with the alert. +- Examine network connections from the host to identify any unusual or unauthorized external communications that could indicate malicious activity. +- Review historical data for similar alerts on the same host to identify patterns or repeated suspicious behavior. + +### False positive analysis + +- Legitimate administrative scripts may trigger the rule if they are executed using non-standard processes. To handle this, identify and document regular administrative tasks that use scriptlets and exclude these specific processes from the rule. +- Custom enterprise applications that utilize scrobj.dll for legitimate automation purposes might be flagged. Review these applications and add them to the exclusion list if they are verified as safe. +- Scheduled tasks or maintenance scripts that load scrobj.dll in non-standard processes can cause false positives. Regularly audit scheduled tasks and exclude known safe processes from the detection rule. +- Development or testing environments where scriptlets are frequently used for automation may generate alerts. Consider creating a separate rule set for these environments to reduce noise while maintaining security monitoring. + +### Response and remediation + +- Isolate the affected system from the network to prevent further execution of potentially malicious scripts and lateral movement. +- Terminate any suspicious processes identified as loading scrobj.dll in non-standard executables to halt malicious activity. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious scripts or files. +- Review and restore any altered system configurations or settings to their default state to ensure system integrity. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement application whitelisting to prevent unauthorized execution of scripts and binaries, focusing on the processes identified in the detection rule. +- Update detection mechanisms to monitor for similar activities across the network, ensuring that any future attempts to exploit scrobj.dll are promptly identified and addressed.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_suspicious_wmi_script.toml b/rules/windows/defense_evasion_suspicious_wmi_script.toml index 3f1cee8f4c1..fbfd68fdc08 100644 --- a/rules/windows/defense_evasion_suspicious_wmi_script.toml +++ b/rules/windows/defense_evasion_suspicious_wmi_script.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/02" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -45,6 +45,41 @@ sequence by process.entity_id with maxspan = 2m [any where host.os.type == "windows" and (event.category == "library" or (event.category == "process" and event.action : "Image loaded*")) and (?dll.name : ("jscript.dll", "vbscript.dll") or file.name : ("jscript.dll", "vbscript.dll"))] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious WMIC XSL Script Execution + +Windows Management Instrumentation Command-line (WMIC) is a powerful tool for managing Windows systems. Adversaries exploit WMIC to bypass security measures by executing scripts via XSL files, often loading scripting libraries like jscript.dll or vbscript.dll. The detection rule identifies such suspicious activities by monitoring WMIC executions with atypical arguments and the loading of specific libraries, indicating potential misuse for defense evasion. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of WMIC.exe or wmic.exe with suspicious arguments such as "format*:*", "/format*:*", or "*-format*:*" that deviate from typical usage patterns. +- Examine the command line used in the process execution to identify any unusual or unexpected parameters that could indicate malicious intent, excluding known benign patterns like "* /format:table *". +- Investigate the sequence of events to determine if there was a library or process event involving the loading of jscript.dll or vbscript.dll, which may suggest script execution through XSL files. +- Correlate the process.entity_id with other related events within the 2-minute window to identify any additional suspicious activities or processes that may have been spawned as a result of the initial execution. +- Check the parent process of the suspicious WMIC execution to understand the context and origin of the activity, which may provide insights into whether it was initiated by a legitimate application or a potentially malicious actor. +- Analyze the host's recent activity and security logs for any other indicators of compromise or related suspicious behavior that could be part of a broader attack campaign. + +### False positive analysis + +- Legitimate administrative tasks using WMIC with custom scripts may trigger alerts. Review the command line arguments and context to determine if the execution is part of routine system management. +- Automated scripts or software updates that utilize WMIC for legitimate purposes might load scripting libraries like jscript.dll or vbscript.dll. Identify these processes and consider adding them to an allowlist to prevent future false positives. +- Security tools or monitoring solutions that use WMIC for system checks can be mistaken for suspicious activity. Verify the source and purpose of the execution and exclude these known tools from triggering alerts. +- Scheduled tasks or maintenance scripts that use WMIC with non-standard arguments could be flagged. Document these tasks and create exceptions for their specific command line patterns to reduce noise. +- Custom applications developed in-house that rely on WMIC for functionality may inadvertently match the detection criteria. Work with development teams to understand these applications and adjust the detection rule to accommodate their legitimate use cases. + +### Response and remediation + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious WMIC processes identified by the alert to stop ongoing malicious script execution. +- Conduct a thorough review of the system's recent activity logs to identify any additional indicators of compromise or related malicious activities. +- Remove any unauthorized or suspicious XSL files and associated scripts from the system to prevent re-execution. +- Restore the system from a known good backup if any critical system files or configurations have been altered. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_timestomp_sysmon.toml b/rules/windows/defense_evasion_timestomp_sysmon.toml index 1664fbad7f2..e9b6a211fcf 100644 --- a/rules/windows/defense_evasion_timestomp_sysmon.toml +++ b/rules/windows/defense_evasion_timestomp_sysmon.toml @@ -2,7 +2,7 @@ creation_date = "2023/01/17" integration = ["windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -54,6 +54,41 @@ file where host.os.type == "windows" and event.code : "2" and not file.extension : ("temp", "tmp", "~tmp", "xml", "newcfg") and not user.name : ("SYSTEM", "Local Service", "Network Service") and not file.name : ("LOG", "temp-index", "license.rtf", "iconcache_*.db") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Time Changed +File creation timestamps are crucial for tracking file history and integrity. Adversaries may alter these timestamps, a tactic known as timestomping, to disguise malicious files as benign. This detection rule leverages Sysmon logs to identify suspicious changes in file creation times, excluding trusted processes and file types, thus highlighting potential evasion attempts by attackers. + +### Possible investigation steps + +- Review the Sysmon logs to confirm the event code 2, which indicates a file creation time change, and verify the associated process and file details. +- Identify the process executable path that triggered the alert and determine if it is outside the list of trusted paths specified in the query. +- Check the file extension and name to ensure they are not part of the excluded types such as "temp", "tmp", or "LOG". +- Investigate the user account associated with the event to determine if it is a non-system account, as the query excludes "SYSTEM", "Local Service", and "Network Service". +- Correlate the file creation time change event with other security events or logs to identify any related suspicious activities or patterns. +- Assess the file's location and context to determine if it is in a sensitive or unusual directory that could indicate malicious intent. +- If necessary, perform a deeper forensic analysis on the file and process to identify any potential malicious behavior or indicators of compromise. + +### False positive analysis + +- Trusted software updates or installations may alter file creation times. Exclude known update processes like msiexec.exe from detection to reduce noise. +- System maintenance tasks, such as disk cleanup, can modify timestamps. Exclude cleanmgr.exe to prevent these benign changes from triggering alerts. +- User-initiated actions in trusted applications like Chrome or Firefox might change file creation times. Exclude these applications to avoid unnecessary alerts. +- Temporary files created by legitimate processes may have altered timestamps. Exclude file extensions like temp and tmp to minimize false positives. +- System accounts such as SYSTEM or Local Service may perform legitimate file operations. Exclude these user names to focus on suspicious activities. + +### Response and remediation + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement by the adversary. +- Conduct a thorough review of the file in question to determine if it is malicious. Use a combination of antivirus scans and manual analysis to assess the file's behavior and origin. +- If the file is confirmed to be malicious, remove it from the system and any other locations it may have been copied to. Ensure that all associated processes are terminated. +- Restore any affected files from a known good backup to ensure data integrity and continuity. +- Review and update endpoint protection settings to ensure that similar threats are detected and blocked in the future. This may include adjusting Sysmon configurations to enhance logging and detection capabilities. +- 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. +- Document the incident, including all actions taken, to improve future response efforts and update threat intelligence databases with any new indicators of compromise (IOCs) identified.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_unsigned_dll_loaded_from_suspdir.toml b/rules/windows/defense_evasion_unsigned_dll_loaded_from_suspdir.toml index 17af2ccdeeb..c8602abe2bd 100644 --- a/rules/windows/defense_evasion_unsigned_dll_loaded_from_suspdir.toml +++ b/rules/windows/defense_evasion_unsigned_dll_loaded_from_suspdir.toml @@ -2,7 +2,7 @@ creation_date = "2022/11/22" integration = ["endpoint"] maturity = "production" -updated_date = "2024/09/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -125,6 +125,40 @@ library where host.os.type == "windows" and /* DLL loaded from the process.executable current directory */ endswith~(substring(dll.path, 0, length(dll.path) - (length(dll.name) + 1)), substring(process.executable, 0, length(process.executable) - (length(process.name) + 1))) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Unsigned DLL Side-Loading from a Suspicious Folder + +DLL side-loading exploits the trust of signed executables to load malicious DLLs, often from suspicious directories. Adversaries use this to bypass security measures by placing unsigned DLLs in locations mimicking legitimate paths. The detection rule identifies this by checking for trusted programs loading recently modified, unsigned DLLs from atypical directories, signaling potential evasion tactics. + +### Possible investigation steps + +- Review the process code signature to confirm the legitimacy of the trusted program that loaded the DLL. Check if the process is expected to run from the identified directory. +- Examine the DLL's path and creation or modification time to determine if it aligns with typical user or system activity. Investigate why the DLL was recently modified or created. +- Analyze the DLL's code signature status to understand why it is unsigned or has an error status. This can help identify if the DLL is potentially malicious. +- Investigate the parent process and any associated child processes to understand the context of the DLL loading event. This can provide insights into how the DLL was introduced. +- Check for any recent changes or anomalies in the system or user activity logs around the time the DLL was created or modified to identify potential indicators of compromise. +- Correlate the alert with other security events or alerts in the environment to determine if this is part of a broader attack or isolated incident. + +### False positive analysis + +- Legitimate software updates or installations may temporarily load unsigned DLLs from atypical directories. Users can create exceptions for known update processes by verifying the source and ensuring the process is part of a legitimate update. +- Custom or in-house applications might load unsigned DLLs from non-standard directories. Users should verify the application's behavior and, if deemed safe, exclude these specific paths or processes from the rule. +- Development environments often involve testing unsigned DLLs in various directories. Developers can exclude these environments by specifying the directories or processes involved in the development workflow. +- Some third-party security or system management tools may use unsigned DLLs for legitimate purposes. Users should confirm the tool's legitimacy and add exceptions for these tools to prevent false positives. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity. +- Terminate the process associated with the unsigned DLL to stop any ongoing malicious operations. +- Quarantine the suspicious DLL file and any related files for further analysis to understand the scope and nature of the threat. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or remnants. +- Review and restore any altered system configurations or settings to their original state to ensure system integrity. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has impacted other systems. +- Implement additional monitoring and logging on the affected system and network to detect any recurrence or similar threats in the future.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_unusual_dir_ads.toml b/rules/windows/defense_evasion_unusual_dir_ads.toml index 9d0dc28418d..08fb59cfba8 100644 --- a/rules/windows/defense_evasion_unusual_dir_ads.toml +++ b/rules/windows/defense_evasion_unusual_dir_ads.toml @@ -2,7 +2,7 @@ creation_date = "2020/12/04" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2024/10/31" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -39,6 +39,41 @@ query = ''' process where host.os.type == "windows" and event.type == "start" and process.args : "?:\\*:*" and process.args_count == 1 ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Execution Path - Alternate Data Stream + +Alternate Data Streams (ADS) in Windows allow files to contain multiple data streams, which can be exploited by adversaries to conceal malicious code. This technique is often used for defense evasion, as it hides malware within legitimate files. The detection rule identifies processes initiated from ADS by monitoring specific execution patterns, such as unique argument structures, to flag potential threats. + +### Possible investigation steps + +- Review the process details, including the process name and path, to determine if it is a known legitimate application or potentially malicious. +- Examine the process arguments, specifically looking for the pattern "?:\\\\*:*", to understand the context of the execution and identify any suspicious or unusual characteristics. +- Check the parent process of the flagged process to assess if it was initiated by a legitimate or expected source. +- Investigate the user account associated with the process execution to determine if the activity aligns with the user's typical behavior or if it appears anomalous. +- Correlate the event with other security logs or alerts from data sources like Sysmon, Microsoft Defender for Endpoint, or Crowdstrike to gather additional context and identify any related suspicious activities. +- Search for any known indicators of compromise (IOCs) related to the process or file path in threat intelligence databases to assess if the activity is associated with known threats. + +### False positive analysis + +- Legitimate software installations or updates may use alternate data streams to execute processes. Users can create exceptions for known software update paths to prevent unnecessary alerts. +- Some backup or file synchronization tools might utilize alternate data streams for metadata storage. Identify these tools and exclude their execution paths from the detection rule. +- Certain system administration scripts or tools may leverage alternate data streams for legitimate purposes. Review and whitelist these scripts if they are verified as non-threatening. +- Developers might use alternate data streams during software development for testing purposes. Ensure development environments are accounted for in the exception list to avoid false positives. +- Security tools themselves may use alternate data streams for scanning or monitoring activities. Verify and exclude these tools from the detection rule to reduce noise. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of potential malware. +- Terminate any suspicious processes identified as running from an Alternate Data Stream to halt malicious activity. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any hidden malware. +- Examine the file system for any additional Alternate Data Streams and remove or quarantine any suspicious files. +- Restore any affected files or systems from known good backups to ensure system integrity. +- Monitor the network for any unusual outbound traffic from the affected system that may indicate data exfiltration attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_unusual_network_connection_via_dllhost.toml b/rules/windows/defense_evasion_unusual_network_connection_via_dllhost.toml index 0e2c84b0d56..746be96af71 100644 --- a/rules/windows/defense_evasion_unusual_network_connection_via_dllhost.toml +++ b/rules/windows/defense_evasion_unusual_network_connection_via_dllhost.toml @@ -2,7 +2,7 @@ creation_date = "2021/05/28" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -50,6 +50,39 @@ sequence by host.id, process.entity_id with maxspan=1m "192.175.48.0/24", "198.18.0.0/15", "198.51.100.0/24", "203.0.113.0/24", "240.0.0.0/4", "::1", "FE80::/10", "FF00::/8")] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 via DllHost + +Dllhost.exe is a legitimate Windows process used to host DLL services. Adversaries may exploit it for stealthy command and control by initiating unauthorized network connections. The detection rule identifies suspicious dllhost.exe activity by monitoring outbound connections to non-local IPs, which may indicate malicious intent. This approach helps in identifying potential threats by focusing on unusual network behaviors associated with this process. + +### Possible investigation steps + +- Review the process start event for dllhost.exe to confirm its legitimacy by checking the process arguments and the parent process that initiated it. +- Analyze the destination IP addresses involved in the network connections to determine if they are known malicious or suspicious entities, using threat intelligence sources. +- Check the timeline of events to see if there are any other unusual activities on the host around the time of the dllhost.exe network connection, such as other process executions or file modifications. +- Investigate the user account associated with the dllhost.exe process to determine if there are any signs of compromise or unauthorized access. +- Examine the network traffic patterns from the host to identify any other unusual outbound connections that might indicate broader malicious activity. + +### False positive analysis + +- Legitimate software updates or system maintenance tasks may cause dllhost.exe to make outbound connections. Users can monitor and whitelist known update servers to prevent these from being flagged. +- Certain enterprise applications might use dllhost.exe for legitimate network communications. Identify and document these applications, then create exceptions for their known IP addresses. +- Automated scripts or administrative tools that leverage dllhost.exe for network tasks can trigger false positives. Review and exclude these scripts or tools by specifying their associated IP ranges. +- Cloud-based services or virtual environments might route traffic through dllhost.exe. Verify these services and exclude their IP addresses from the detection rule to avoid unnecessary alerts. + +### Response and remediation + +- Isolate the affected host from the network immediately to prevent further unauthorized communications and potential lateral movement. +- Terminate the suspicious dllhost.exe process to stop any ongoing malicious activity and prevent further outbound connections. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious software or artifacts. +- Review and analyze the network logs to identify any other systems that may have been targeted or compromised, and apply similar containment measures if necessary. +- Restore the affected system from a known good backup to ensure that any potential backdoors or persistent threats are removed. +- Implement network segmentation to limit the ability of similar threats to spread across the network in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional organizational measures are required.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_unusual_system_vp_child_program.toml b/rules/windows/defense_evasion_unusual_system_vp_child_program.toml index f2dc01c3942..2321bdd1cd9 100644 --- a/rules/windows/defense_evasion_unusual_system_vp_child_program.toml +++ b/rules/windows/defense_evasion_unusual_system_vp_child_program.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/19" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -46,6 +46,42 @@ process where host.os.type == "windows" and event.type == "start" and process.parent.pid == 4 and process.executable : "?*" and not process.executable : ("Registry", "MemCompression", "?:\\Windows\\System32\\smss.exe") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Child Process from a System Virtual Process + +In Windows environments, the System process (PID 4) is a critical component responsible for managing system-level operations. Adversaries may exploit this by injecting malicious code to spawn unauthorized child processes, evading detection. The detection rule identifies anomalies by flagging unexpected child processes originating from the System process, excluding known legitimate executables, thus highlighting potential threats. + +### Possible investigation steps + +- Review the process details of the suspicious child process, including the executable path and command line arguments, to determine if it matches known malicious patterns or anomalies. +- Check the parent process (PID 4) to confirm it is indeed the System process and verify if any legitimate processes are excluded as per the rule (e.g., Registry, MemCompression, smss.exe). +- Investigate the timeline of events leading up to the process start event to identify any preceding suspicious activities or anomalies that might indicate process injection or exploitation. +- Correlate the alert with other security telemetry from data sources like Microsoft Defender for Endpoint or Sysmon to identify any related alerts or indicators of compromise. +- Examine the network activity associated with the suspicious process to detect any unauthorized connections or data exfiltration attempts. +- Consult threat intelligence sources to determine if the process executable or its behavior is associated with known malware or threat actor techniques. +- If necessary, isolate the affected system to prevent further potential malicious activity and conduct a deeper forensic analysis. + +### False positive analysis + +- Legitimate system maintenance tools may occasionally spawn child processes from the System process. Users should monitor and verify these tools and add them to the exclusion list if they are confirmed to be safe. +- Some security software might create child processes from the System process as part of their normal operation. Identify these processes and configure exceptions to prevent unnecessary alerts. +- Windows updates or system patches can sometimes trigger unexpected child processes. Ensure that these processes are part of a legitimate update cycle and exclude them if they are verified. +- Custom scripts or administrative tools used for system management might also cause false positives. Review these scripts and tools, and if they are deemed safe, add them to the exclusion list. +- Virtualization software or sandbox environments may mimic or interact with the System process in ways that trigger alerts. Validate these interactions and exclude them if they are part of normal operations. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further spread of the potential threat. +- Terminate any suspicious child processes identified as originating from the System process (PID 4) that are not part of the known legitimate executables. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any injected malicious code. +- Review recent system changes and installed software to identify any unauthorized modifications or installations that could have facilitated the process injection. +- Restore the system from a known good backup if malicious activity is confirmed and cannot be fully remediated through other means. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for the affected system and similar environments to detect any recurrence of the threat, focusing on process creation events and anomalies related to the System process.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_windows_filtering_platform.toml b/rules/windows/defense_evasion_windows_filtering_platform.toml index a409ebe9849..ba8acd7b348 100644 --- a/rules/windows/defense_evasion_windows_filtering_platform.toml +++ b/rules/windows/defense_evasion_windows_filtering_platform.toml @@ -2,7 +2,7 @@ creation_date = "2023/12/15" integration = ["system", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -97,6 +97,42 @@ sequence by winlog.computer_name with maxspan=1m "splunk.exe", "sysmon.exe", "sysmon64.exe", "taniumclient.exe" )] with runs=5 ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Evasion via Windows Filtering Platform + +The Windows Filtering Platform (WFP) is a set of API and system services that provide a platform for network filtering and packet processing. Adversaries may exploit WFP by creating malicious rules to block endpoint security processes, hindering their ability to send telemetry data. The detection rule identifies patterns of blocked network events linked to security software processes, signaling potential evasion tactics. + +### Possible investigation steps + +- Review the specific network events that triggered the alert, focusing on the event.action values "windows-firewall-packet-block" and "windows-firewall-packet-drop" to understand which processes were blocked. +- Identify the process names involved in the alert from the process.name field and verify if they are related to known endpoint security software, as listed in the query. +- Check the winlog.computer_name field to determine which systems are affected and assess if multiple systems are involved, indicating a broader issue. +- Investigate the recent changes to the Windows Filtering Platform rules on the affected systems to identify any unauthorized or suspicious modifications. +- Correlate the blocked events with any recent security incidents or alerts to determine if there is a pattern or ongoing attack. +- Consult system logs and security software logs on the affected systems for additional context or anomalies around the time of the alert. +- Engage with the system or network administrators to verify if any legitimate changes were made to the WFP rules that could explain the blocked events. + +### False positive analysis + +- Security software updates or installations can trigger multiple block events as they modify network configurations. Users should monitor for these events during known update windows and consider excluding them from alerts. +- Legitimate network troubleshooting or diagnostic tools may temporarily block network traffic as part of their operation. Identify these tools and create exceptions for their processes to prevent false alerts. +- Custom security configurations or policies in enterprise environments might intentionally block certain network activities. Review and document these configurations to differentiate between expected behavior and potential threats. +- Temporary network disruptions or misconfigurations can cause legitimate security processes to be blocked. Regularly audit network settings and ensure they align with security policies to minimize these occurrences. +- Scheduled maintenance or testing of security systems might result in blocked events. Coordinate with IT teams to whitelist these activities during planned maintenance periods. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity and data exfiltration. +- Terminate any suspicious processes identified in the alert, particularly those related to endpoint security software, to restore normal security operations. +- Review and remove any unauthorized or suspicious Windows Filtering Platform rules that may have been added to block security processes. +- Conduct a thorough scan of the affected system using a trusted antivirus or endpoint detection and response (EDR) tool to identify and remove any malware or persistent threats. +- Restore any affected security software to its default configuration and ensure it is fully operational and updated. +- Monitor network traffic and system logs for any signs of continued evasion tactics or re-infection attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_wsl_bash_exec.toml b/rules/windows/defense_evasion_wsl_bash_exec.toml index 28b232f3d9d..79a1da37f21 100644 --- a/rules/windows/defense_evasion_wsl_bash_exec.toml +++ b/rules/windows/defense_evasion_wsl_bash_exec.toml @@ -2,7 +2,7 @@ creation_date = "2023/01/13" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -66,6 +66,40 @@ process where host.os.type == "windows" and event.type : "start" and ) and not process.parent.executable : ("?:\\Program Files\\Docker\\*.exe", "?:\\Program Files (x86)\\Docker\\*.exe") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Execution via Windows Subsystem for Linux + +Windows Subsystem for Linux (WSL) allows users to run Linux binaries natively on Windows, providing a seamless integration of Linux tools. Adversaries may exploit WSL to execute Linux commands stealthily, bypassing traditional Windows security measures. The detection rule identifies unusual WSL activity by monitoring specific executable paths, command-line arguments, and parent-child process relationships, flagging deviations from typical usage patterns to uncover potential threats. + +### Possible investigation steps + +- Review the process command line and executable path to determine if the execution of bash.exe or any other Linux binaries is expected or authorized for the user or system in question. +- Investigate the parent-child process relationship, especially focusing on whether wsl.exe is the parent process and if it has spawned any unexpected child processes that are not wslhost.exe. +- Examine the command-line arguments used with wsl.exe for any suspicious or unauthorized commands, such as accessing sensitive files like /etc/shadow or /etc/passwd, or using network tools like curl. +- Check the user's activity history and system logs to identify any patterns of behavior that might indicate misuse or compromise, particularly focusing on any deviations from typical usage patterns. +- Correlate the alert with other security events or logs from data sources like Elastic Endgame, Microsoft Defender for Endpoint, or Sysmon to gather additional context and determine if this is part of a broader attack or isolated incident. + +### False positive analysis + +- Frequent use of WSL for legitimate development tasks may trigger alerts. Users can create exceptions for specific user accounts or directories commonly used for development to reduce noise. +- Automated scripts or tools that utilize WSL for system maintenance or monitoring might be flagged. Identify these scripts and whitelist their specific command-line patterns or parent processes. +- Docker-related processes may cause false positives due to their interaction with WSL. Exclude Docker executable paths from the detection rule to prevent unnecessary alerts. +- Visual Studio Code extensions that interact with WSL can generate alerts. Exclude known non-threatening extensions by specifying their command-line arguments in the exception list. +- Regular system updates or administrative tasks that involve WSL might be misidentified. Document these activities and adjust the detection rule to recognize them as benign. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, such as those involving bash.exe or wsl.exe with unusual command-line arguments. +- Conduct a thorough review of the affected system's WSL configuration and installed Linux distributions to identify any unauthorized changes or installations. +- Remove any unauthorized or suspicious Linux binaries or scripts found within the WSL environment. +- Reset credentials for any accounts that may have been compromised, especially if sensitive files like /etc/shadow or /etc/passwd were accessed. +- 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 enhanced monitoring and logging for WSL activities across the network to detect similar threats in the future, ensuring that alerts are promptly reviewed and acted upon.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_wsl_child_process.toml b/rules/windows/defense_evasion_wsl_child_process.toml index eb1713f9cfb..f072aac0692 100644 --- a/rules/windows/defense_evasion_wsl_child_process.toml +++ b/rules/windows/defense_evasion_wsl_child_process.toml @@ -2,7 +2,7 @@ creation_date = "2023/01/12" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2024/10/31" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -70,6 +70,41 @@ process where host.os.type == "windows" and event.type : "start" and ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Execution via Windows Subsystem for Linux + +Windows Subsystem for Linux (WSL) allows users to run Linux binaries natively on Windows, providing a seamless integration of Linux tools. Adversaries may exploit WSL to execute malicious scripts or binaries, bypassing traditional Windows security mechanisms. The detection rule identifies suspicious executions initiated by WSL processes, excluding known safe executables, to flag potential misuse for defense evasion. + +### Possible investigation steps + +- Review the process details to identify the executable path and determine if it matches any known malicious or suspicious binaries not listed in the safe executables. +- Investigate the parent process, specifically wsl.exe or wslhost.exe, to understand how the execution was initiated and if it aligns with expected user behavior or scheduled tasks. +- Check the user account associated with the process execution to verify if the activity is consistent with the user's typical behavior or if the account may have been compromised. +- Analyze the event dataset, especially if it is from crowdstrike.fdr, to gather additional context about the process execution and any related activities on the host. +- Correlate the alert with other security events or logs from data sources like Microsoft Defender for Endpoint or SentinelOne to identify any related suspicious activities or patterns. +- Assess the risk score and severity in the context of the organization's environment to prioritize the investigation and response actions accordingly. + +### False positive analysis + +- Legitimate administrative tasks using WSL may trigger alerts. Users can create exceptions for known administrative scripts or binaries that are frequently executed via WSL. +- Development environments often use WSL for compiling or testing code. Exclude specific development tools or scripts that are regularly used by developers to prevent unnecessary alerts. +- Automated system maintenance scripts running through WSL can be mistaken for malicious activity. Identify and whitelist these scripts to reduce false positives. +- Security tools or monitoring solutions that leverage WSL for legitimate purposes should be identified and excluded from detection to avoid interference with their operations. +- Frequent use of WSL by specific users or groups for non-malicious purposes can be managed by creating user-based exceptions, allowing their activities to proceed without triggering alerts. + +### Response and remediation + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified as being executed via WSL that are not part of the known safe executables list. +- Conduct a thorough review of the affected system's WSL configuration and installed Linux distributions to identify unauthorized changes or installations. +- Remove any unauthorized or malicious scripts and binaries found within the WSL environment. +- Restore the system from a known good backup if malicious activity has compromised system integrity. +- Update and patch the system to ensure all software, including WSL, is up to date to mitigate known vulnerabilities. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_wsl_filesystem.toml b/rules/windows/defense_evasion_wsl_filesystem.toml index eb37721421f..29f11f5ca87 100644 --- a/rules/windows/defense_evasion_wsl_filesystem.toml +++ b/rules/windows/defense_evasion_wsl_filesystem.toml @@ -2,7 +2,7 @@ creation_date = "2023/01/12" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -46,6 +46,40 @@ sequence by process.entity_id with maxspan=5m process.command_line : "*{DFB65C4C-B34F-435D-AFE9-A86218684AA8}*"] [file where host.os.type == "windows" and process.name : "dllhost.exe" and not file.path : "?:\\Users\\*\\Downloads\\*"] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Host Files System Changes via Windows Subsystem for Linux + +Windows Subsystem for Linux (WSL) allows users to run a Linux environment directly on Windows, facilitating seamless file access between systems. Adversaries may exploit WSL to modify host files stealthily, bypassing traditional security measures. The detection rule identifies suspicious file operations initiated by WSL processes, particularly those involving the Plan9FileSystem, to flag potential defense evasion attempts. + +### Possible investigation steps + +- Review the process details for the "dllhost.exe" instance that triggered the alert, focusing on the command line arguments to confirm the presence of the Plan9FileSystem CLSID "{DFB65C4C-B34F-435D-AFE9-A86218684AA8}". +- Examine the file paths involved in the alert to determine if any sensitive or critical files were accessed or modified outside of typical user directories, excluding the Downloads folder. +- Investigate the parent process of "dllhost.exe" to understand the context of its execution and identify any potentially malicious parent processes. +- Check the timeline of events leading up to and following the alert to identify any other suspicious activities or related alerts that may indicate a broader attack pattern. +- Correlate the alert with user activity logs to determine if the actions were performed by a legitimate user or if there are signs of compromised credentials or unauthorized access. + +### False positive analysis + +- Routine file operations by legitimate applications using WSL may trigger alerts. Identify and whitelist these applications to prevent unnecessary alerts. +- Development activities involving WSL, such as compiling code or running scripts, can generate false positives. Exclude specific development directories or processes from monitoring. +- Automated backup or synchronization tools that interact with WSL might be flagged. Configure exceptions for these tools by specifying their process names or file paths. +- System maintenance tasks that involve WSL, like updates or system checks, could be mistaken for suspicious activity. Schedule these tasks during known maintenance windows and adjust monitoring rules accordingly. +- Frequent downloads or file transfers to directories outside the typical user download paths may appear suspicious. Define clear policies for acceptable file paths and exclude them from alerts. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes associated with "dllhost.exe" that are linked to the Plan9FileSystem CLSID to stop ongoing malicious activities. +- Conduct a thorough review of recent file changes on the host system to identify and restore any unauthorized modifications or deletions. +- Revoke any unauthorized access or permissions granted to WSL that may have been exploited by the adversary. +- Update and patch the Windows Subsystem for Linux and related components to mitigate any known vulnerabilities that could be exploited. +- Monitor for any recurrence of similar activities by setting up alerts for processes and file operations involving "dllhost.exe" and the Plan9FileSystem. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/defense_evasion_wsl_kalilinux.toml b/rules/windows/defense_evasion_wsl_kalilinux.toml index 5e45f738e56..f9a8bc1091e 100644 --- a/rules/windows/defense_evasion_wsl_kalilinux.toml +++ b/rules/windows/defense_evasion_wsl_kalilinux.toml @@ -2,7 +2,7 @@ creation_date = "2023/01/12" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2024/10/31" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -61,6 +61,40 @@ process where host.os.type == "windows" and event.type == "start" and ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Attempt to Install Kali Linux via WSL + +Windows Subsystem for Linux (WSL) allows users to run Linux distributions on Windows, providing a seamless integration of Linux tools. Adversaries may exploit WSL to install Kali Linux, a penetration testing distribution, to evade detection by traditional Windows security tools. The detection rule identifies suspicious processes and file paths associated with Kali Linux installations, flagging potential misuse for defense evasion. + +### Possible investigation steps + +- Review the process details to confirm the presence of "wsl.exe" with arguments indicating an attempt to install or use Kali Linux, such as "-d", "--distribution", "-i", or "--install". +- Check the file paths associated with the Kali Linux installation, such as "?:\\Users\\*\\AppData\\Local\\packages\\kalilinux*" or "?:\\Program Files*\\WindowsApps\\KaliLinux.*\\kali.exe", to verify if the installation files exist on the system. +- Investigate the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Correlate the event with other security logs or alerts from data sources like Microsoft Defender for Endpoint or Sysmon to identify any related suspicious activities or patterns. +- Assess the risk and impact of the detected activity by considering the context of the environment and any potential threats posed by the use of Kali Linux on the system. + +### False positive analysis + +- Legitimate use of Kali Linux for development or educational purposes may trigger the rule. Users can create exceptions for specific user accounts or groups known to use Kali Linux for authorized activities. +- Automated scripts or deployment tools that install or configure Kali Linux as part of a legitimate IT process might be flagged. Consider whitelisting these scripts or processes by their hash or path. +- Security researchers or IT professionals conducting penetration testing on a Windows machine may cause false positives. Implement user-based exclusions for these professionals to prevent unnecessary alerts. +- System administrators testing WSL features with various Linux distributions, including Kali, could inadvertently trigger the rule. Establish a policy to document and approve such activities, then exclude them from detection. +- Training environments where Kali Linux is used to teach cybersecurity skills might be mistakenly flagged. Set up environment-specific exclusions to avoid disrupting educational activities. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent any potential lateral movement or data exfiltration. +- Terminate any suspicious processes related to the Kali Linux installation attempt, specifically those involving `wsl.exe` with arguments indicating a Kali distribution. +- Remove any unauthorized installations of Kali Linux by deleting associated files and directories, such as those found in `AppData\\\\Local\\\\packages\\\\kalilinux*` or `Program Files*\\\\WindowsApps\\\\KaliLinux.*`. +- Conduct a thorough review of user accounts and permissions on the affected system to ensure no unauthorized access or privilege escalation has occurred. +- 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 similar activities across the network, focusing on WSL usage and installation attempts of known penetration testing tools. +- Review and update endpoint protection configurations to enhance detection and prevention capabilities against similar threats, leveraging data sources like Microsoft Defender for Endpoint and Sysmon.""" [[rule.threat]] diff --git a/rules/windows/discovery_active_directory_webservice.toml b/rules/windows/discovery_active_directory_webservice.toml index e43e63aa66c..7b899f87244 100644 --- a/rules/windows/discovery_active_directory_webservice.toml +++ b/rules/windows/discovery_active_directory_webservice.toml @@ -2,7 +2,7 @@ creation_date = "2024/01/31" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -44,6 +44,40 @@ sequence by process.entity_id with maxspan=3m [network where host.os.type == "windows" and destination.port == 9389 and source.port >= 49152 and network.direction == "egress" and network.transport == "tcp" and not cidrmatch(destination.ip, "127.0.0.0/8", "::1/128")] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Enumeration via Active Directory Web Service + +Active Directory Web Service (ADWS) facilitates querying Active Directory (AD) over a network, providing a web-based interface for directory services. Adversaries may exploit ADWS to enumerate network resources and user accounts, gaining insights into the environment. The detection rule identifies suspicious activity by monitoring processes that load AD-related modules and establish network connections to the ADWS port, indicating potential unauthorized enumeration attempts. + +### Possible investigation steps + +- Review the process entity ID to identify the specific process that triggered the alert and gather details such as the process name, executable path, and user context. +- Examine the user ID associated with the process to determine if it belongs to a legitimate user or service account, and verify if the user has a history of accessing Active Directory resources. +- Investigate the network connection details, focusing on the destination IP address and port 9389, to identify the target server and assess if it is a legitimate Active Directory Web Service endpoint. +- Check for any recent changes or unusual activity on the host machine, such as new software installations or configuration changes, that could explain the loading of Active Directory-related modules. +- Correlate the alert with other security events or logs from the same timeframe to identify any patterns or additional suspicious activities that might indicate a broader attack or reconnaissance effort. + +### False positive analysis + +- Legitimate administrative tools or scripts may load Active Directory-related modules and connect to the ADWS port. To handle this, create exceptions for known administrative processes that regularly perform these actions. +- Scheduled tasks or automated scripts running under service accounts might trigger the rule. Identify these tasks and exclude their associated user IDs or process paths from the detection rule. +- Security or monitoring software that queries Active Directory for legitimate purposes can cause false positives. Review and whitelist these applications by adding their executable paths to the exclusion list. +- Development or testing environments where developers frequently interact with Active Directory services may generate alerts. Consider excluding specific user IDs or process paths associated with these environments to reduce noise. +- Ensure that any exceptions or exclusions are regularly reviewed and updated to reflect changes in the environment or administrative practices. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified in the alert that are loading Active Directory-related modules and making network connections to the ADWS port. +- Conduct a thorough review of the affected system's user accounts and permissions to identify any unauthorized changes or access. +- Reset credentials for any accounts that were potentially compromised or used in the suspicious activity. +- Implement network segmentation to limit access to the ADWS port (9389) to only trusted systems and users. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Update and enhance monitoring rules to detect similar enumeration attempts in the future, focusing on unusual process behavior and network connections to critical services.""" [[rule.threat]] diff --git a/rules/windows/discovery_high_number_ad_properties.toml b/rules/windows/discovery_high_number_ad_properties.toml index 0b6dad34e2a..980639372cd 100644 --- a/rules/windows/discovery_high_number_ad_properties.toml +++ b/rules/windows/discovery_high_number_ad_properties.toml @@ -2,7 +2,7 @@ creation_date = "2023/01/29" integration = ["windows", "system"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -49,6 +49,40 @@ any where event.action in ("Directory Service Access", "object-operation-perform event.code == "4662" and not winlog.event_data.SubjectUserSid : "S-1-5-18" and winlog.event_data.AccessMaskDescription == "Read Property" and length(winlog.event_data.Properties) >= 2000 ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Access to LDAP Attributes + +LDAP (Lightweight Directory Access Protocol) is crucial for querying and modifying directory services like Active Directory, which stores user credentials and permissions. Adversaries exploit LDAP to enumerate directory attributes, seeking vulnerabilities or sensitive data. The detection rule identifies unusual read access patterns, such as excessive attribute queries, which may indicate reconnaissance or privilege escalation attempts. + +### Possible investigation steps + +- Review the event logs for the specific event code 4662 to gather details about the suspicious read access, focusing on the winlog.event_data.Properties field to understand which attributes were accessed. +- Identify the user associated with the suspicious activity by examining the winlog.event_data.SubjectUserSid field, and determine if this user has a legitimate reason to access a high number of Active Directory object attributes. +- Check the user's recent activity and login history to identify any unusual patterns or anomalies that could indicate compromised credentials or unauthorized access. +- Investigate the source machine from which the LDAP queries originated to determine if it is a known and trusted device or if it shows signs of compromise or unauthorized use. +- Correlate this event with other security alerts or logs to identify if this activity is part of a larger pattern of reconnaissance or privilege escalation attempts within the network. + +### False positive analysis + +- Regular system maintenance or updates may trigger high attribute read access. Exclude known maintenance accounts from the rule to prevent false alerts. +- Automated scripts or applications that query Active Directory for legitimate purposes can cause excessive attribute reads. Identify and whitelist these scripts or applications to reduce noise. +- Security audits or compliance checks often involve extensive directory queries. Coordinate with IT and security teams to recognize these activities and adjust the rule to exclude them. +- Service accounts with legitimate high-volume access patterns should be reviewed and, if deemed non-threatening, added to an exception list to avoid unnecessary alerts. +- Consider the context of the access, such as time of day or associated user activity, to differentiate between normal and suspicious behavior. Adjust the rule to account for these patterns where applicable. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Conduct a thorough review of the user account associated with the suspicious LDAP access to determine if it has been compromised. Reset the account credentials and enforce multi-factor authentication. +- Analyze the event logs to identify any other systems or accounts that may have been accessed using similar methods, and apply the same containment measures. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the full scope of the breach. +- Implement additional monitoring on LDAP queries and Active Directory access to detect similar patterns of excessive attribute queries in the future. +- Review and tighten access controls and permissions within Active Directory to ensure that only necessary attributes are accessible to users based on their roles. +- Conduct a post-incident review to identify any gaps in security controls and update policies or procedures to prevent recurrence of similar threats.""" [[rule.threat]] diff --git a/rules/windows/discovery_signal_unusual_discovery_signal_proc_cmdline.toml b/rules/windows/discovery_signal_unusual_discovery_signal_proc_cmdline.toml index 6c49a43316c..19bd22e270b 100644 --- a/rules/windows/discovery_signal_unusual_discovery_signal_proc_cmdline.toml +++ b/rules/windows/discovery_signal_unusual_discovery_signal_proc_cmdline.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2023/09/22" maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -35,6 +35,41 @@ host.os.type:windows and event.kind:signal and kibana.alert.rule.rule_id:( "c4e9ed3e-55a2-4309-a012-bc3c78dad10a" or "51176ed2-2d90-49f2-9f3d-17196428b169" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Discovery Signal Alert with Unusual Process Command Line + +This detection rule identifies anomalies in process command lines on Windows systems, which may indicate adversarial reconnaissance activities. Attackers often exploit legitimate discovery tools to gather system information stealthily. By monitoring unique combinations of host, user, and command line data, the rule flags deviations from normal behavior, helping analysts pinpoint potential threats early. + +### Possible investigation steps + +- Review the alert details to identify the specific host.id, user.id, and process.command_line that triggered the alert. This will help in understanding the context of the anomaly. +- Check the historical activity of the identified host.id and user.id to determine if the process.command_line has been executed previously and assess if this behavior is truly unusual. +- Investigate the process.command_line for any known malicious patterns or suspicious commands that could indicate reconnaissance or other adversarial activities. +- Correlate the alert with other security events or logs from the same host or user around the same time to identify any additional suspicious activities or patterns. +- Consult threat intelligence sources to see if the process.command_line or any associated indicators have been reported in recent threat campaigns or advisories. +- If necessary, isolate the affected host to prevent potential lateral movement or further compromise while the investigation is ongoing. + +### False positive analysis + +- Legitimate administrative tools may trigger alerts when used by IT staff for routine system checks. To manage this, create exceptions for known safe tools and processes frequently used by trusted users. +- Automated scripts or scheduled tasks that perform regular system audits can be flagged as unusual. Identify these scripts and add them to an allowlist to prevent unnecessary alerts. +- Software updates or installations that involve system discovery commands might be misidentified as threats. Monitor update schedules and exclude related processes during these times. +- Security software performing scans or inventory checks can mimic adversarial reconnaissance. Verify the processes associated with these tools and configure the rule to ignore them. +- New software deployments or changes in system configurations may temporarily alter normal command line behavior. Document these changes and adjust the rule settings to accommodate expected deviations. + +### Response and remediation + +- Isolate the affected host immediately to prevent further lateral movement or data exfiltration. Disconnect it from the network while maintaining power to preserve volatile data for forensic analysis. +- Terminate any suspicious processes identified by the alert, especially those with unusual command lines, to halt any ongoing malicious activity. +- Conduct a thorough review of the affected user's account for any unauthorized access or privilege escalation. Reset passwords and revoke any unnecessary permissions. +- Analyze the command line arguments and process execution context to understand the scope and intent of the reconnaissance activity. This may involve reviewing logs and correlating with other security events. +- Restore the affected system from a known good backup if any malicious changes or persistence mechanisms are detected. Ensure the backup is free from compromise. +- Update endpoint protection and intrusion detection systems with the latest threat intelligence to enhance detection capabilities against similar reconnaissance activities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the activity is part of a larger attack campaign.""" [[rule.threat]] diff --git a/rules/windows/discovery_signal_unusual_discovery_signal_proc_executable.toml b/rules/windows/discovery_signal_unusual_discovery_signal_proc_executable.toml index b39b57e1999..a9003d91c7e 100644 --- a/rules/windows/discovery_signal_unusual_discovery_signal_proc_executable.toml +++ b/rules/windows/discovery_signal_unusual_discovery_signal_proc_executable.toml @@ -1,7 +1,7 @@ [metadata] creation_date = "2023/09/22" maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -30,6 +30,41 @@ type = "new_terms" query = ''' host.os.type:windows and event.kind:signal and kibana.alert.rule.rule_id:"1d72d014-e2ab-4707-b056-9b96abe7b511" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Discovery Signal Alert with Unusual Process Executable + +In Windows environments, discovery activities often involve querying system information, which adversaries exploit to gather intelligence for further attacks. They may use uncommon processes to evade detection. This detection rule identifies anomalies by flagging signals with rare host, user, and process combinations, indicating potential misuse of discovery tactics. + +### Possible investigation steps + +- Review the alert details to identify the specific host.id, user.id, and process.executable involved in the alert to understand the context of the unusual activity. +- Check the historical activity of the identified host.id and user.id to determine if this combination has been seen before and assess if the behavior is truly anomalous. +- Investigate the process.executable to verify its legitimacy, including checking its file path, digital signature, and any known associations with legitimate or malicious software. +- Correlate the alert with other security events or logs from the same host or user to identify any additional suspicious activities or patterns that may indicate a broader threat. +- Consult threat intelligence sources to determine if the process.executable or any related indicators are associated with known threat actors or campaigns. +- Assess the potential impact and risk of the activity by considering the host's role within the network and the user's access level to sensitive data or systems. + +### False positive analysis + +- Routine administrative tasks may trigger alerts if they involve uncommon processes. Identify these tasks and create exceptions for known benign activities to prevent unnecessary alerts. +- Software updates or installations can generate unusual process executions. Monitor and document these events, and exclude them from alerts if they are verified as legitimate. +- Custom scripts or tools used by IT staff for system management might be flagged. Review these scripts and whitelist them if they are part of regular operations. +- Automated processes or scheduled tasks that run under specific user accounts may appear suspicious. Verify these tasks and exclude them if they are part of normal system behavior. +- Third-party security or monitoring tools might use unique processes for legitimate discovery activities. Validate these tools and add them to the exception list to avoid false positives. + +### Response and remediation + +- Isolate the affected host immediately to prevent further lateral movement or data exfiltration. Disconnect it from the network while maintaining power to preserve volatile data for forensic analysis. +- Terminate the unusual process executable identified in the alert to halt any ongoing malicious activity. Use task management tools or scripts to ensure the process is stopped. +- Conduct a thorough review of the user account associated with the alert. Reset the account credentials and enforce multi-factor authentication to prevent unauthorized access. +- Analyze the process executable and its origin. Check for any associated files or scripts that may have been dropped on the system and remove them. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign. +- Implement additional monitoring on the affected host and user account to detect any further suspicious activities. Use enhanced logging and alerting to capture detailed information. +- Review and update endpoint protection policies to block similar unusual processes in the future, ensuring that the security tools are configured to detect and respond to such anomalies.""" [[rule.threat]] diff --git a/rules/windows/execution_apt_solarwinds_backdoor_child_cmd_powershell.toml b/rules/windows/execution_apt_solarwinds_backdoor_child_cmd_powershell.toml index e80673b2bbd..d72891b5a05 100644 --- a/rules/windows/execution_apt_solarwinds_backdoor_child_cmd_powershell.toml +++ b/rules/windows/execution_apt_solarwinds_backdoor_child_cmd_powershell.toml @@ -2,7 +2,7 @@ creation_date = "2020/12/14" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2024/10/31" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -62,6 +62,41 @@ process.parent.name: ( "SolarwindsDiagnostics*.exe" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Command Execution via SolarWinds Process + +SolarWinds is a widely used IT management tool that can be targeted by adversaries to execute unauthorized commands. Attackers may exploit SolarWinds processes to launch command-line interpreters like Cmd.exe or Powershell.exe, potentially leading to system compromise. The detection rule identifies suspicious child processes initiated by specific SolarWinds executables, flagging potential misuse by correlating process start events with known SolarWinds parent processes. This helps in early detection of malicious activities leveraging SolarWinds for command execution. + +### Possible investigation steps + +- Review the alert details to identify the specific SolarWinds parent process that initiated the suspicious child process (Cmd.exe or Powershell.exe) and note the exact executable name and path. +- Examine the timeline of events around the process start event to identify any preceding or subsequent suspicious activities, such as unusual network connections or file modifications. +- Check the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates potential compromise or misuse. +- Investigate the command line arguments used by the child process to assess if they contain any malicious or unexpected commands. +- Correlate the event with other security logs and alerts from data sources like Microsoft Defender for Endpoint or Sysmon to gather additional context and identify potential patterns of malicious behavior. +- Assess the system's current state for any indicators of compromise, such as unauthorized changes to system configurations or the presence of known malware signatures. + +### False positive analysis + +- Routine administrative tasks using SolarWinds may trigger the rule when legitimate scripts are executed via Cmd.exe or Powershell.exe. Users can create exceptions for known maintenance scripts or tasks that are regularly scheduled and verified as safe. +- Automated updates or patches initiated by SolarWinds processes might be flagged. To mitigate this, users should whitelist specific update processes or scripts that are part of the regular update cycle. +- Monitoring or diagnostic activities performed by IT staff using SolarWinds tools can result in false positives. Establish a baseline of normal activities and exclude these from alerts by identifying and documenting regular diagnostic commands. +- Custom scripts developed for internal use that leverage SolarWinds processes could be misidentified as threats. Ensure these scripts are reviewed and approved, then add them to an exception list to prevent unnecessary alerts. +- Third-party integrations with SolarWinds that require command execution might be mistakenly flagged. Verify the legitimacy of these integrations and exclude their associated processes from detection rules. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized command execution and potential lateral movement. +- Terminate any suspicious child processes such as Cmd.exe or Powershell.exe that were initiated by the identified SolarWinds parent processes. +- Conduct a thorough review of the affected system's logs and configurations to identify any unauthorized changes or additional indicators of compromise. +- Restore the system from a known good backup if any unauthorized changes or malicious activities are confirmed. +- Update and patch the SolarWinds software and any other vulnerable applications on the affected system to mitigate known vulnerabilities. +- Implement application whitelisting to prevent unauthorized execution of command-line interpreters from SolarWinds processes. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network.""" [[rule.threat]] diff --git a/rules/windows/execution_apt_solarwinds_backdoor_unusual_child_processes.toml b/rules/windows/execution_apt_solarwinds_backdoor_unusual_child_processes.toml index 1d85e3cce88..4d76d9499b7 100644 --- a/rules/windows/execution_apt_solarwinds_backdoor_unusual_child_processes.toml +++ b/rules/windows/execution_apt_solarwinds_backdoor_unusual_child_processes.toml @@ -2,7 +2,7 @@ creation_date = "2020/12/14" integration = ["endpoint", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/10" +updated_date = "2025/01/10" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." @@ -58,6 +58,41 @@ process where host.os.type == "windows" and event.type == "start" and ) and not process.executable : ("?:\\Windows\\SysWOW64\\ARP.EXE", "?:\\Windows\\SysWOW64\\lodctr.exe", "?:\\Windows\\SysWOW64\\unlodctr.exe") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious SolarWinds Child Process + +SolarWinds is a widely used IT management software that operates critical network and system monitoring functions. Adversaries may exploit its trusted processes to execute unauthorized programs, leveraging its elevated privileges to bypass security controls. The detection rule identifies unusual child processes spawned by SolarWinds' core services, excluding known legitimate operations, to flag potential malicious activity. + +### Possible investigation steps + +- Review the details of the triggered alert to identify the specific child process name and executable path that caused the alert. +- Check the parent process details, specifically SolarWinds.BusinessLayerHost.exe or SolarWinds.BusinessLayerHostx64.exe, to confirm its legitimacy and ensure it is running from the expected directory. +- Investigate the child process's code signature to determine if it is trusted or if there are any anomalies in the signature that could indicate tampering. +- Analyze the historical activity of the suspicious child process on the host to identify any patterns or previous instances of execution that could provide context. +- Correlate the suspicious process activity with other security events or logs from the same host to identify any related malicious behavior or indicators of compromise. +- Consult threat intelligence sources to determine if the suspicious process or executable path is associated with known malware or adversary techniques. + +### False positive analysis + +- Legitimate SolarWinds updates or patches may trigger the rule. Ensure that the process code signature is verified as trusted and matches known update signatures. +- Custom scripts or tools integrated with SolarWinds for automation purposes might be flagged. Review these processes and add them to the exclusion list if they are verified as safe and necessary for operations. +- Third-party plugins or extensions that interact with SolarWinds could be misidentified. Validate these plugins and consider excluding them if they are from a trusted source and essential for functionality. +- Scheduled tasks or maintenance activities that involve SolarWinds processes may appear suspicious. Confirm these tasks are part of regular operations and exclude them if they are consistent with expected behavior. +- Temporary diagnostic or troubleshooting tools used by IT staff might be detected. Ensure these tools are authorized and add them to the exclusion list if they are frequently used and pose no threat. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious child processes identified that are not part of the known legitimate operations list, ensuring that no malicious programs continue to execute. +- Conduct a thorough review of the affected system's recent activity logs to identify any additional indicators of compromise or unauthorized changes. +- Restore the affected system from a known good backup to ensure that any potential malware or unauthorized changes are removed. +- Update all SolarWinds software and related components to the latest versions to patch any known vulnerabilities that could be exploited. +- Implement enhanced monitoring on the affected system and similar environments to detect any recurrence of suspicious activity, focusing on unusual child processes spawned by SolarWinds services. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if broader organizational impacts need to be addressed.""" [[rule.threat]] diff --git a/rules/windows/execution_com_object_xwizard.toml b/rules/windows/execution_com_object_xwizard.toml index d0f0f60ae02..bfaaa10fd00 100644 --- a/rules/windows/execution_com_object_xwizard.toml +++ b/rules/windows/execution_com_object_xwizard.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/20" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel", "system", "crowdstrike"] maturity = "production" -updated_date = "2024/11/02" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -66,6 +66,40 @@ process where host.os.type == "windows" and event.type == "start" and ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Execution of COM object via Xwizard + +The Windows Component Object Model (COM) facilitates communication between software components. Adversaries exploit this by using Xwizard to execute COM objects, bypassing security measures. The detection rule identifies suspicious Xwizard executions by monitoring process starts, checking for unusual arguments, and verifying executable paths, thus flagging potential misuse of COM objects for malicious activities. + +### Possible investigation steps + +- Review the process start event details to confirm the presence of xwizard.exe execution, focusing on the process.name and process.pe.original_file_name fields. +- Examine the process.args field to identify any unusual or suspicious arguments, particularly looking for the "RunWizard" command and any GUIDs or patterns that may indicate malicious activity. +- Verify the process.executable path to ensure it matches the expected system paths (C:\\Windows\\SysWOW64\\xwizard.exe or C:\\Windows\\System32\\xwizard.exe). Investigate any deviations from these paths as potential indicators of compromise. +- Check the parent process of xwizard.exe to understand the context of its execution and identify any potentially malicious parent processes. +- Correlate the event with other security data sources such as Microsoft Defender for Endpoint or Sysmon logs to gather additional context and identify any related suspicious activities or patterns. +- Investigate the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates potential unauthorized access or privilege escalation. + +### False positive analysis + +- Legitimate software installations or updates may trigger the rule if they use Xwizard to execute COM objects. Users can create exceptions for known software update processes by verifying the executable paths and arguments. +- System administrators might use Xwizard for legitimate configuration tasks. To handle this, identify and document regular administrative activities and exclude these from the rule by specifying the expected process arguments and executable paths. +- Automated scripts or management tools that utilize Xwizard for system management tasks can cause false positives. Review and whitelist these scripts or tools by ensuring their execution paths and arguments are consistent with known safe operations. +- Some security tools or monitoring solutions might use Xwizard as part of their normal operations. Confirm these activities with the tool's documentation and exclude them by adding their specific execution patterns to the exception list. + +### Response and remediation + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious xwizard.exe processes identified by the detection rule to halt potential malicious execution. +- Conduct a thorough review of the system's registry for unauthorized COM objects and remove any entries that are not recognized or are deemed malicious. +- Restore the system from a known good backup if unauthorized changes or persistent threats are detected. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. +- Monitor the network for any signs of similar activity or related threats, ensuring that detection systems are tuned to identify variations of this attack. +- Escalate the incident to the security operations center (SOC) or relevant security team for further analysis and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/execution_command_shell_started_by_unusual_process.toml b/rules/windows/execution_command_shell_started_by_unusual_process.toml index 437d881b36d..e36ce13cb64 100644 --- a/rules/windows/execution_command_shell_started_by_unusual_process.toml +++ b/rules/windows/execution_command_shell_started_by_unusual_process.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende maturity = "production" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." min_stack_version = "8.14.0" -updated_date = "2024/10/15" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -58,6 +58,42 @@ process where host.os.type == "windows" and event.type == "start" and "wlanext.exe" ) and not (process.parent.name : "dllhost.exe" and process.parent.args : "/Processid:{CA8C87C1-929D-45BA-94DB-EF8E6CB346AD}") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Parent Process for cmd.exe + +Cmd.exe is a command-line interpreter on Windows systems, often used for legitimate administrative tasks. However, adversaries can exploit it by launching it from atypical parent processes to execute malicious commands stealthily. The detection rule identifies such anomalies by flagging cmd.exe instances spawned by uncommon parent processes, which may indicate unauthorized or suspicious activity, thus aiding in early threat detection. + +### Possible investigation steps + +- Review the process tree to understand the context in which cmd.exe was launched, focusing on the parent process identified in the alert. +- Investigate the parent process by examining its command-line arguments, start time, and any associated network activity to determine if it is behaving anomalously. +- Check the historical behavior of the parent process to see if it has previously spawned cmd.exe or if this is an unusual occurrence. +- Analyze any child processes spawned by the cmd.exe instance to identify potentially malicious activities or commands executed. +- Correlate the alert with other security events or logs from the same host to identify any related suspicious activities or patterns. +- Assess the user account associated with the cmd.exe process to determine if it has been compromised or is exhibiting unusual behavior. +- Consult threat intelligence sources to see if the parent process or its behavior is associated with known malware or attack techniques. + +### False positive analysis + +- Cmd.exe instances spawned by legitimate system maintenance tools like Windows Update or system indexing services can trigger false positives. Users can create exceptions for processes like SearchIndexer.exe or WUDFHost.exe if they are verified as part of routine system operations. +- Software updates or installations that use cmd.exe for scripting purposes might be flagged. If GoogleUpdate.exe or FlashPlayerUpdateService.exe are known to be part of regular update processes, consider excluding them after confirming their legitimacy. +- Administrative scripts or tools that are scheduled to run via Task Scheduler might use cmd.exe and be flagged. If taskhostw.exe is a known parent process for these tasks, verify and exclude it to prevent unnecessary alerts. +- Certain third-party applications might use cmd.exe for legitimate background tasks. If applications like jusched.exe or jucheck.exe are identified as part of trusted software, they can be excluded after validation. +- System recovery or diagnostic tools that interact with cmd.exe could be misidentified. If WerFault.exe or wermgr.exe are part of these processes, ensure they are legitimate and exclude them accordingly. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate the suspicious cmd.exe process and its parent process to halt any ongoing malicious activity. +- Conduct a thorough review of the affected system's recent activity logs to identify any unauthorized changes or additional compromised processes. +- Restore any altered or deleted files from a known good backup to ensure system integrity. +- Update and run a full antivirus and anti-malware scan on the affected system to detect and remove any additional threats. +- 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 enhanced monitoring and logging for cmd.exe and its parent processes to detect similar anomalies in the future.""" [[rule.threat]] diff --git a/rules/windows/execution_command_shell_via_rundll32.toml b/rules/windows/execution_command_shell_via_rundll32.toml index f19d1e775db..46d47e879fb 100644 --- a/rules/windows/execution_command_shell_via_rundll32.toml +++ b/rules/windows/execution_command_shell_via_rundll32.toml @@ -2,7 +2,7 @@ creation_date = "2020/10/19" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -42,6 +42,41 @@ process where host.os.type == "windows" and event.type == "start" and not process.parent.args : ("C:\\Windows\\System32\\SHELL32.dll,RunAsNewUser_RunDLL", "C:\\WINDOWS\\*.tmp,zzzzInvokeManagedCustomActionOutOfProc") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Command Shell Activity Started via RunDLL32 + +RunDLL32 is a legitimate Windows utility used to execute functions in DLLs, often leveraged by attackers to run malicious code stealthily. Adversaries exploit it to launch command shells like cmd.exe or PowerShell, bypassing security controls. The detection rule identifies such abuse by monitoring for command shells initiated by RunDLL32, excluding known benign patterns, thus highlighting potential threats. + +### Possible investigation steps + +- Review the process details to confirm the parent-child relationship between rundll32.exe and the command shell (cmd.exe or powershell.exe) to ensure the alert is not a false positive. +- Examine the command line arguments of rundll32.exe to identify any suspicious or unusual DLLs or functions being executed, excluding known benign patterns. +- Check the user account associated with the process to determine if it aligns with expected behavior or if it indicates potential compromise. +- Investigate the source and destination network connections associated with the process to identify any suspicious or unauthorized communication. +- Correlate the event with other security alerts or logs from the same host or user to identify any patterns or additional indicators of compromise. +- Review recent changes or activities on the host, such as software installations or updates, that might explain the execution of rundll32.exe with command shells. + +### False positive analysis + +- Known false positives include command shells initiated by RunDLL32 for legitimate administrative tasks or software installations. +- Exclude command lines that match common benign patterns, such as those involving SHELL32.dll or temporary files used by trusted applications. +- Regularly update the list of exceptions to include new benign patterns identified through monitoring and analysis. +- Collaborate with IT and security teams to identify and document legitimate use cases of RunDLL32 in your environment. +- Use process monitoring tools to verify the legitimacy of command shells started by RunDLL32, ensuring they align with expected behavior. + +### Response and remediation + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified as cmd.exe or powershell.exe that were initiated by rundll32.exe to halt potential malicious actions. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or remnants. +- Review and analyze the rundll32.exe command line arguments to understand the scope and intent of the activity, and identify any additional compromised systems or accounts. +- Reset credentials for any user accounts that were active on the affected system during the time of the alert to prevent unauthorized access. +- 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 enhanced monitoring and logging for rundll32.exe and related processes to detect similar activities in the future and improve response times.""" [[rule.threat]] diff --git a/rules/windows/execution_delayed_via_ping_lolbas_unsigned.toml b/rules/windows/execution_delayed_via_ping_lolbas_unsigned.toml index 1fe398d770d..7dcd6f690f9 100644 --- a/rules/windows/execution_delayed_via_ping_lolbas_unsigned.toml +++ b/rules/windows/execution_delayed_via_ping_lolbas_unsigned.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/25" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -63,6 +63,41 @@ sequence by process.parent.entity_id with maxspan=1m "?:\\Users\\*\\AppData\\Local\\Temp\\QBTools\\")) ] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Delayed Execution via Ping + +Ping, a network utility, can be misused by attackers to delay execution of malicious commands, aiding in evasion. Adversaries may use ping to introduce pauses, allowing them to execute harmful scripts or binaries stealthily. The detection rule identifies suspicious ping usage followed by execution of known malicious utilities, flagging potential threats by monitoring specific command patterns and excluding benign processes. + +### Possible investigation steps + +- Review the process tree to understand the sequence of events, focusing on the parent-child relationship between cmd.exe, ping.exe, and any subsequent suspicious processes like rundll32.exe or powershell.exe. +- Examine the command line arguments used with ping.exe to determine the delay introduced and assess if it aligns with typical malicious behavior. +- Investigate the user account associated with the process execution, especially if the user.id is not S-1-5-18, to determine if the account has been compromised or is being misused. +- Check the file path and code signature of any executables launched from the user's AppData directory to verify if they are trusted or potentially malicious. +- Analyze the command line arguments and working directory of any suspicious processes to identify any known malicious patterns or scripts being executed. +- Correlate the alert with any other recent alerts or logs from the same host or user to identify potential patterns or ongoing malicious activity. + +### False positive analysis + +- Legitimate administrative scripts or maintenance tasks may use ping to introduce delays, especially in batch files executed by system administrators. To handle this, identify and exclude specific scripts or command lines that are known to be safe. +- Software installations or updates might use ping for timing purposes. Review the command lines and parent processes involved, and create exceptions for trusted software paths or signatures. +- Automated testing environments may use ping to simulate network latency or wait for services to start. Exclude these processes by identifying the testing framework or environment and adding it to the exception list. +- Some legitimate applications might use ping as part of their normal operation. Monitor these applications and, if verified as safe, exclude their specific command patterns or executable paths. +- Regularly review and update the exception list to ensure it reflects the current environment and any new legitimate use cases that arise. + +### Response and remediation + +- Isolate the affected system from the network immediately to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified in the alert, such as those involving ping.exe followed by the execution of known malicious utilities. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malware or unauthorized software. +- Review and analyze the command history and logs of the affected system to understand the scope of the attack and identify any additional compromised systems. +- Restore the system from a known good backup if malware removal is not feasible or if the system's integrity is in question. +- Implement application whitelisting to prevent unauthorized execution of scripts and binaries, focusing on the utilities identified in the alert. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/execution_downloaded_shortcut_files.toml b/rules/windows/execution_downloaded_shortcut_files.toml index 43fbff23e7a..ed5486f4fe6 100644 --- a/rules/windows/execution_downloaded_shortcut_files.toml +++ b/rules/windows/execution_downloaded_shortcut_files.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/02" integration = ["endpoint"] maturity = "production" -updated_date = "2024/08/06" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -31,6 +31,40 @@ type = "eql" query = ''' file where host.os.type == "windows" and event.type == "creation" and file.extension == "lnk" and file.Ext.windows.zone_identifier > 1 ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Downloaded Shortcut Files + +Shortcut files (.lnk) are used in Windows environments to link to executable files or scripts, streamlining user access. Adversaries exploit this by embedding malicious commands in these files, often distributing them via phishing. The detection rule identifies suspicious .lnk files created on Windows systems, especially those downloaded from external sources, indicating potential phishing attempts. This is achieved by monitoring file creation events and zone identifiers, which help trace the file's origin. + +### Possible investigation steps + +- Review the file creation event details to identify the specific .lnk file and its associated metadata, such as the file path and creation timestamp. +- Examine the zone identifier value to confirm that the file was indeed downloaded from an external source, as indicated by a value greater than 1. +- Investigate the source of the download by checking network logs or browser history to identify the URL or IP address from which the .lnk file was downloaded. +- Analyze the contents of the .lnk file to detect any embedded commands or scripts that may indicate malicious intent. +- Check for any related alerts or events on the same host around the time of the .lnk file creation to identify potential follow-up actions or additional threats. +- Assess the user account associated with the file creation event to determine if the account has been compromised or if the user was targeted in a phishing campaign. + +### False positive analysis + +- Corporate software deployments may trigger the rule when legitimate .lnk files are distributed across the network. Users can create exceptions for known software distribution servers to prevent these false positives. +- Automated backup or synchronization tools that create .lnk files as part of their normal operation can be mistaken for threats. Identifying and excluding these tools from the rule can reduce unnecessary alerts. +- User-created shortcuts for frequently accessed network resources might be flagged. Monitoring and excluding specific user activities or directories where these shortcuts are commonly created can help manage these false positives. +- Some legitimate applications may download .lnk files as part of their update process. Identifying these applications and adding them to an exception list can prevent false alerts. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of the potential threat. +- Quarantine the suspicious .lnk file to prevent execution and further analysis. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes. +- Review and remove any unauthorized or suspicious user accounts or privileges that may have been created or altered as a result of the phishing attempt. +- Restore the system from a known good backup if any critical system files or configurations have been compromised. +- Notify the security team and relevant stakeholders about the incident for awareness and further investigation. +- Update security policies and rules to block similar phishing attempts in the future, such as restricting the execution of .lnk files from untrusted sources.""" [[rule.threat]] diff --git a/rules/windows/execution_downloaded_url_file.toml b/rules/windows/execution_downloaded_url_file.toml index 8b72e8d4a46..77fedd4cb3c 100644 --- a/rules/windows/execution_downloaded_url_file.toml +++ b/rules/windows/execution_downloaded_url_file.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/02" integration = ["endpoint"] maturity = "production" -updated_date = "2024/08/06" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -32,6 +32,41 @@ query = ''' file where host.os.type == "windows" and event.type == "creation" and file.extension == "url" and file.Ext.windows.zone_identifier > 1 and not process.name : "explorer.exe" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Downloaded URL Files + +URL shortcut files, typically used for quick access to web resources, can be exploited by attackers in phishing schemes to execute malicious content. These files, when downloaded from non-local sources, may bypass traditional security measures. The detection rule identifies such files by monitoring their creation events on Windows systems, focusing on those not initiated by standard processes like Explorer, and flags them based on their network origin, aiding in early threat detection. + +### Possible investigation steps + +- Review the file creation event details to confirm the file extension is ".url" and verify the zone identifier is greater than 1, indicating a non-local source. +- Investigate the process that created the .url file, ensuring it was not initiated by "explorer.exe" and identify the actual process responsible for the creation. +- Check the network origin of the downloaded .url file to determine if it is from a known malicious domain or IP address. +- Analyze the contents of the .url file to identify the target URL and assess its reputation and potential risk. +- Correlate the event with other security alerts or logs from the same host to identify any additional suspicious activities or patterns. +- Contact the user associated with the alert to verify if they intentionally downloaded the file and gather any additional context regarding their actions. + +### False positive analysis + +- Corporate applications that generate .url files for legitimate purposes may trigger alerts. Identify these applications and create exceptions for their processes to prevent unnecessary alerts. +- Automated scripts or system management tools that download .url files as part of routine operations can be mistaken for threats. Review these tools and whitelist their activities if they are verified as safe. +- User-initiated downloads from trusted internal web portals might be flagged. Educate users on safe downloading practices and consider excluding specific trusted domains from monitoring. +- Security software updates or patches that include .url files could be misidentified. Verify the source of these updates and adjust the rule to exclude known safe update processes. +- Collaboration platforms that share .url files for internal use may cause false positives. Evaluate the platform's behavior and exclude its processes if they are deemed secure. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of any potential malicious activity. +- Terminate any suspicious processes that are not initiated by standard processes like Explorer, especially those related to the creation of .url files. +- Delete the identified .url files from the system to remove the immediate threat. +- Conduct a full antivirus and anti-malware scan on the affected system to identify and remove any additional threats. +- Review and analyze the network logs to identify any other systems that may have downloaded similar .url files and apply the same containment measures. +- Escalate the incident to the security operations team for further investigation and to determine if there is a broader campaign targeting the organization. +- Update security policies and endpoint protection configurations to block the download and execution of .url files from untrusted sources in the future.""" [[rule.threat]] diff --git a/rules/windows/execution_enumeration_via_wmiprvse.toml b/rules/windows/execution_enumeration_via_wmiprvse.toml index dce7b4392db..df8dd1c0616 100644 --- a/rules/windows/execution_enumeration_via_wmiprvse.toml +++ b/rules/windows/execution_enumeration_via_wmiprvse.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/19" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2024/10/31" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -61,6 +61,41 @@ process where host.os.type == "windows" and event.type == "start" and process.co ) and not process.args : "tenable_mw_scan" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Enumeration Command Spawned via WMIPrvSE + +Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. Adversaries exploit WMI to execute enumeration commands stealthily, leveraging the WMI Provider Service (WMIPrvSE) to gather system and network information. The detection rule identifies suspicious command executions initiated by WMIPrvSE, focusing on common enumeration tools while excluding benign use cases, thus highlighting potential malicious activity. + +### Possible investigation steps + +- Review the process command line details to understand the specific enumeration command executed and its arguments, focusing on the process.command_line field. +- Investigate the parent process to confirm it is indeed WMIPrvSE by examining the process.parent.name field, ensuring the execution context aligns with potential misuse of WMI. +- Check the user context under which the process was executed to determine if it aligns with expected administrative activity or if it suggests unauthorized access. +- Correlate the event with other logs or alerts from the same host to identify any preceding or subsequent suspicious activities, such as lateral movement or privilege escalation attempts. +- Assess the network activity from the host around the time of the alert to identify any unusual outbound connections or data exfiltration attempts. +- Verify if the process execution is part of a known and legitimate administrative task or script by consulting with system administrators or reviewing change management records. + +### False positive analysis + +- Routine administrative tasks using WMI may trigger the rule, such as network configuration checks or system diagnostics. To manage this, identify and exclude specific command patterns or arguments that are part of regular maintenance. +- Security tools like Tenable may use WMI for legitimate scans, which can be mistaken for malicious activity. Exclude processes with arguments related to known security tools, such as "tenable_mw_scan". +- Automated scripts or scheduled tasks that perform system enumeration for inventory or monitoring purposes can cause false positives. Review and whitelist these scripts by excluding their specific command lines or parent processes. +- Certain enterprise applications may use WMI for legitimate operations, such as querying system information. Identify these applications and create exceptions based on their process names or command line arguments. +- Regular use of network utilities by IT staff for troubleshooting can be flagged. Implement exclusions for known IT user accounts or specific command line patterns used during these activities. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified as being spawned by WMIPrvSE, especially those matching the enumeration tools listed in the detection query. +- Conduct a thorough review of recent WMI activity on the affected system to identify any additional unauthorized or suspicious commands executed. +- Reset credentials for any accounts that may have been compromised or used in the suspicious activity to prevent further unauthorized access. +- Restore the system from a known good backup if any malicious activity is confirmed and cannot be remediated through other means. +- Implement additional monitoring on the affected system and network to detect any recurrence of similar suspicious activities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems.""" [[rule.threat]] diff --git a/rules/windows/execution_initial_access_foxmail_exploit.toml b/rules/windows/execution_initial_access_foxmail_exploit.toml index 7a82513cf24..2ebe421b5f4 100644 --- a/rules/windows/execution_initial_access_foxmail_exploit.toml +++ b/rules/windows/execution_initial_access_foxmail_exploit.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "system", "sentinel_one_cloud_funnel", "m3 maturity = "production" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." min_stack_version = "8.14.0" -updated_date = "2024/10/31" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -53,6 +53,41 @@ query = ''' process where host.os.type == "windows" and event.type == "start" and process.parent.name : "Foxmail.exe" and process.args : ("?:\\Users\\*\\AppData\\*", "\\\\*") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Foxmail Exploitation + +Foxmail, a popular email client, can be exploited by adversaries to gain initial access and execute malicious payloads. Attackers may leverage vulnerabilities to spawn child processes from Foxmail, directing them to temporary directories where malicious files reside. The detection rule identifies such suspicious activities by monitoring process creation events, specifically when Foxmail spawns processes with arguments pointing to its temp directory, indicating potential exploitation attempts. + +### Possible investigation steps + +- Review the process creation event details to confirm that Foxmail.exe is the parent process and check the specific child process that was spawned. +- Examine the arguments of the spawned process to verify if they point to a suspicious temporary directory, as indicated by the query pattern (e.g., paths under "?:\\Users\\*\\AppData\\*"). +- Investigate the contents of the identified temporary directory for any unusual or malicious files that may have been executed. +- Check the email logs and Foxmail client activity to identify any recent emails that could have contained malicious attachments or links leading to the exploitation attempt. +- Correlate the event with other security alerts or logs from data sources like Elastic Defend, Sysmon, or Microsoft Defender for Endpoint to identify any related suspicious activities or patterns. +- Assess the risk and impact on the affected system by determining if any unauthorized changes or additional malicious processes have been initiated following the initial alert. + +### False positive analysis + +- Routine software updates or installations may cause Foxmail to spawn child processes in the temp directory. Users can create exceptions for known update processes to prevent false alerts. +- Legitimate plugins or extensions for Foxmail might execute processes from the temp directory. Verify the legitimacy of these plugins and exclude them if they are trusted. +- Automated scripts or backup software interacting with Foxmail could trigger the rule. Identify these scripts and add them to an exclusion list if they are verified as safe. +- User-initiated actions such as importing or exporting data in Foxmail might result in temporary process creation. Monitor these activities and exclude them if they are part of regular operations. +- Security software performing scans or checks on Foxmail's temp directory can be mistaken for exploitation attempts. Confirm these activities and whitelist the security software processes involved. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any ongoing malicious activity. +- Terminate any suspicious processes spawned by Foxmail that are identified in the alert to stop the execution of potentially malicious payloads. +- Conduct a thorough scan of the affected system using an updated antivirus or endpoint detection and response (EDR) tool to identify and remove any malicious files or remnants. +- Review and analyze email logs and quarantine any suspicious emails that may have been the source of the exploit to prevent further exploitation attempts. +- Apply any available security patches or updates to Foxmail and the operating system to mitigate known vulnerabilities and prevent future exploitation. +- Monitor the network and systems for any signs of lateral movement or additional compromise, using indicators of compromise (IOCs) identified during the investigation. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional actions are required based on the scope and impact of the threat.""" [[rule.threat]] diff --git a/rules/windows/execution_initial_access_wps_dll_exploit.toml b/rules/windows/execution_initial_access_wps_dll_exploit.toml index 499d310019c..a07b115da36 100644 --- a/rules/windows/execution_initial_access_wps_dll_exploit.toml +++ b/rules/windows/execution_initial_access_wps_dll_exploit.toml @@ -2,7 +2,7 @@ creation_date = "2024/08/29" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -50,6 +50,41 @@ any where host.os.type == "windows" and process.name : "promecefpluginhost.exe" "\\Device\\Mup\\**", "\\\\*")) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 WPS Office Exploitation via DLL Hijack + +DLL hijacking exploits the way applications load dynamic link libraries (DLLs), allowing adversaries to execute malicious code. In WPS Office, attackers may exploit vulnerabilities by loading a rogue DLL via the promecefpluginhost.exe process, leveraging the ksoqing protocol. The detection rule identifies suspicious DLL loads from temporary or network paths, signaling potential exploitation attempts. + +### Possible investigation steps + +- Review the alert details to confirm the process name is promecefpluginhost.exe and check if the event category is either "library" or "process" with the action "Image loaded*". +- Examine the DLL or file path involved in the alert to determine if it matches suspicious paths such as those in the user's Temp directory or network paths like \\\\Device\\\\Mup\\\\** or \\\\*. +- Investigate the source of the DLL by checking the file's origin, creation date, and any associated network activity to identify potential malicious downloads or transfers. +- Analyze the process tree to understand the parent and child processes of promecefpluginhost.exe, looking for any unusual or unexpected behavior that might indicate exploitation. +- Check for any other alerts or logs related to the same host or user account to identify patterns or repeated attempts of exploitation. +- Correlate the findings with known vulnerabilities CVE-2024-7262 and CVE-2024-7263 to assess if the observed activity aligns with known exploitation techniques. + +### False positive analysis + +- Legitimate software updates or installations may temporarily load DLLs from network paths or temporary directories. Users can create exceptions for known update processes or trusted software installations to prevent false alerts. +- Some enterprise environments use network-based storage solutions that may trigger alerts when legitimate DLLs are loaded from these paths. Administrators can whitelist specific network paths or devices that are known to host trusted libraries. +- Custom scripts or automation tools that interact with WPS Office might inadvertently load DLLs from temporary directories. Identifying and excluding these scripts or tools from monitoring can reduce false positives. +- Security software or system maintenance tools may perform scans or operations that mimic the behavior of DLL hijacking. Users should verify and exclude these tools if they are known to cause benign alerts. +- In environments where WPS Office is heavily used, consider monitoring the frequency and context of alerts to distinguish between normal usage patterns and potential threats, adjusting the rule parameters accordingly. + +### Response and remediation + +- Isolate the affected system from the network immediately to prevent further exploitation or lateral movement by the attacker. +- Terminate the promecefpluginhost.exe process to stop any ongoing malicious activity and prevent further DLL hijacking attempts. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious DLLs or other malware. +- Review and clean up the temporary and network paths identified in the detection query, specifically focusing on the AppData\\Local\\Temp\\wps\\INetCache directory and any suspicious network shares. +- Apply patches or updates for WPS Office to address the vulnerabilities CVE-2024-7262 and CVE-2024-7263, ensuring that the software is up to date and less susceptible to exploitation. +- Monitor for any further suspicious activity related to the ksoqing protocol or similar DLL hijacking attempts, using enhanced logging and alerting mechanisms. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.""" [[rule.threat]] diff --git a/rules/windows/execution_mofcomp.toml b/rules/windows/execution_mofcomp.toml index be4fb305278..6f848848ccf 100644 --- a/rules/windows/execution_mofcomp.toml +++ b/rules/windows/execution_mofcomp.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/23" integration = ["endpoint", "m365_defender", "system", "crowdstrike"] maturity = "production" -updated_date = "2024/10/31" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -47,6 +47,38 @@ process where host.os.type == "windows" and event.type == "start" and ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Mofcomp Activity +Mofcomp.exe is a tool used to compile Managed Object Format (MOF) files, which define classes and namespaces in the Windows Management Instrumentation (WMI) repository. Adversaries exploit this by creating malicious WMI scripts for persistence or execution. The detection rule identifies suspicious mofcomp.exe activity by filtering out legitimate processes and focusing on unusual executions, excluding known safe parent processes and system accounts. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of mofcomp.exe and verify the command-line arguments used, focusing on any unusual or unexpected MOF file paths. +- Investigate the user account associated with the process execution, especially if it is not the system account (S-1-5-18), to determine if the account has been compromised or is being misused. +- Examine the parent process of mofcomp.exe to ensure it is not a known safe process like ScenarioEngine.exe, and assess whether the parent process is legitimate or potentially malicious. +- Check for any recent changes or additions to the WMI repository, including new namespaces or classes, which could indicate malicious activity or persistence mechanisms. +- Correlate the alert with other security events or logs from data sources like Microsoft Defender for Endpoint or Crowdstrike to identify any related suspicious activities or patterns. + +### False positive analysis + +- Legitimate SQL Server operations may trigger the rule when SQL Server components compile MOF files. To handle this, exclude processes with parent names like ScenarioEngine.exe and specific MOF file paths related to SQL Server. +- System maintenance tasks executed by trusted system accounts can cause false positives. Exclude activities initiated by the system account with user ID S-1-5-18 to reduce noise. +- Regular administrative tasks involving WMI may appear suspicious. Identify and document these tasks, then create exceptions for known safe parent processes or specific MOF file paths to prevent unnecessary alerts. +- Software installations or updates that involve MOF file compilation might be flagged. Monitor installation logs and exclude these processes if they are verified as part of legitimate software updates. + +### Response and remediation + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate the mofcomp.exe process if it is confirmed to be executing malicious MOF files. +- Conduct a thorough review of the WMI repository to identify and remove any unauthorized namespaces or classes that may have been created by the attacker. +- Remove any malicious MOF files from the system to prevent re-execution. +- Restore the system from a known good backup if unauthorized changes to the WMI repository or system files are detected. +- Monitor for any recurrence of similar activity by setting up alerts for unusual mofcomp.exe executions and unauthorized WMI modifications. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/execution_posh_hacktool_authors.toml b/rules/windows/execution_posh_hacktool_authors.toml index 40c31c3be42..dffddb67d7b 100644 --- a/rules/windows/execution_posh_hacktool_authors.toml +++ b/rules/windows/execution_posh_hacktool_authors.toml @@ -2,7 +2,7 @@ creation_date = "2024/05/08" integration = ["windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -80,6 +80,40 @@ host.os.type:windows and event.category:process and "splinter_code" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 PowerShell HackTool Script by Author + +PowerShell is a powerful scripting language and automation framework used in Windows environments for task automation and configuration management. Adversaries exploit PowerShell's capabilities to execute malicious scripts, often leveraging well-known offensive tools without altering the original code. The detection rule identifies scripts containing specific author names linked to these tools, flagging potential misuse by recognizing unmodified author artifacts in the script block text. + +### Possible investigation steps + +- Review the PowerShell script block text associated with the alert to identify the specific author name that triggered the detection. This can provide insight into the potential tool or script being used. +- Examine the process details, including the parent process and command line arguments, to understand the context in which the PowerShell script was executed. This can help determine if the execution was part of a legitimate task or a suspicious activity. +- Check the host's recent activity logs for any other unusual or related events, such as network connections, file modifications, or other process executions, to identify potential lateral movement or data exfiltration attempts. +- Investigate the user account under which the PowerShell script was executed to determine if it has been compromised or if the activity aligns with the user's typical behavior. +- Correlate the alert with other security tools and logs, such as antivirus or endpoint detection and response (EDR) solutions, to gather additional context and confirm whether the activity is malicious. + +### False positive analysis + +- Scripts used in legitimate red team exercises may trigger the rule due to the presence of known author names. To manage this, create exceptions for scripts verified as part of authorized security assessments. +- PowerShell scripts from open-source security tools used for internal testing or training might be flagged. Ensure these tools are documented and approved, then exclude them from the rule. +- Automated scripts for system administration that include code snippets from well-known authors could be mistakenly identified. Review and whitelist these scripts if they are part of routine operations. +- Security research and development activities using sample scripts from recognized authors may cause alerts. Maintain a list of such activities and exclude them from detection to avoid unnecessary alerts. +- Internal development teams using PowerShell scripts for legitimate purposes might inadvertently use code from popular authors. Conduct regular reviews and exclude these scripts if they are deemed non-threatening. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further execution of potentially malicious scripts and lateral movement. +- Terminate any suspicious PowerShell processes identified by the alert to halt ongoing malicious activity. +- Conduct a thorough review of the PowerShell script block text to confirm the presence of known offensive tool author names and assess the potential impact. +- Remove any unauthorized or malicious scripts from the affected system and ensure that all legitimate scripts are verified and restored from a clean backup. +- Update endpoint protection and antivirus signatures to detect and block the specific PowerShell scripts and associated indicators of compromise (IOCs) identified in the alert. +- 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 enhanced monitoring and logging for PowerShell activity across the network to detect similar threats in the future, leveraging the MITRE ATT&CK framework for guidance on relevant techniques and tactics.""" [[rule.threat]] diff --git a/rules/windows/execution_powershell_susp_args_via_winscript.toml b/rules/windows/execution_powershell_susp_args_via_winscript.toml index 146ff0b2c9b..acbeeb7993f 100644 --- a/rules/windows/execution_powershell_susp_args_via_winscript.toml +++ b/rules/windows/execution_powershell_susp_args_via_winscript.toml @@ -4,7 +4,7 @@ integration = ["windows", "system", "sentinel_one_cloud_funnel", "m365_defender" maturity = "production" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." min_stack_version = "8.14.0" -updated_date = "2024/10/15" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -98,6 +98,40 @@ process where host.os.type == "windows" and event.action == "start" and not (process.parent.name : "wscript.exe" and ?process.parent.args : "C:\\Program Files (x86)\\Telivy\\Telivy Agent\\telivy.js") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious PowerShell Execution via Windows Scripts + +PowerShell, a powerful scripting language in Windows, is often targeted by adversaries for executing malicious scripts. Attackers exploit Windows Script Host processes like cscript or wscript to launch PowerShell with obfuscated commands, evading detection. The detection rule identifies such suspicious activity by monitoring PowerShell executions with specific patterns and parent processes, while filtering out known legitimate use cases to reduce false positives. + +### Possible investigation steps + +- Review the process command line and arguments to identify any obfuscation patterns or suspicious commands, such as Base64 encoding or web requests, that match the query's suspicious patterns. +- Examine the parent process details, specifically focusing on wscript.exe, cscript.exe, or mshta.exe, to determine if the PowerShell execution was initiated by a legitimate script or a potentially malicious one. +- Check the process execution context, including the user account and host, to assess if the activity aligns with expected behavior for that user or system. +- Investigate any network connections or file downloads initiated by the PowerShell process, especially those involving external IP addresses or domains, to identify potential data exfiltration or further malicious activity. +- Correlate the alert with other security events or logs from the same host or user to identify any preceding or subsequent suspicious activities that could indicate a broader attack campaign. + +### False positive analysis + +- Legitimate PowerShell commands using non-shortened execution flags may trigger false positives. To manage this, exclude processes with arguments like "-EncodedCommand", "Import-Module*", and "-NonInteractive" unless they are associated with suspicious activity. +- Third-party installation scripts, such as those related to Microsoft System Center or WebLogic, can cause false positives. Exclude these by filtering out specific parent process arguments or command lines, such as "Microsoft.SystemCenter.ICMPProbe.WithConsecutiveSamples.vbs" and "WEBLOGIC_ARGS_CURRENT_1.DATA". +- Routine administrative tasks, like gathering network information, may be flagged. Exclude known scripts like "gatherNetworkInfo.vbs" from detection to prevent unnecessary alerts. +- Exclude specific user scripts or tools that are known to be safe, such as those located in user directories like "C:\\Users\\Prestige\\AppData\\Local\\Temp\\Rar$*\\KMS_VL_ALL_AIO.cmd" if they are verified as non-malicious. +- Regularly review and update exclusion lists to ensure they reflect current legitimate activities and do not inadvertently allow new threats. + +### Response and remediation + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious PowerShell processes identified by the alert to stop ongoing malicious execution. +- Conduct a thorough review of the affected system's PowerShell execution logs to identify any additional malicious scripts or commands that may have been executed. +- Remove any malicious scripts or files identified during the investigation from the system to prevent re-execution. +- Restore the system from a known good backup if any critical system files or configurations have been altered by the malicious activity. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/execution_scheduled_task_powershell_source.toml b/rules/windows/execution_scheduled_task_powershell_source.toml index 443716555aa..e9fa85b6bf9 100644 --- a/rules/windows/execution_scheduled_task_powershell_source.toml +++ b/rules/windows/execution_scheduled_task_powershell_source.toml @@ -2,7 +2,7 @@ creation_date = "2020/12/15" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -46,6 +46,39 @@ sequence by host.id, process.entity_id with maxspan = 5s (?dll.name : "taskschd.dll" or file.name : "taskschd.dll") and process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe")] [network where host.os.type == "windows" and process.name : ("powershell.exe", "pwsh.exe", "powershell_ise.exe") and destination.port == 135 and not destination.address in ("127.0.0.1", "::1")] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Outbound Scheduled Task Activity via PowerShell + +PowerShell, a powerful scripting language in Windows, can automate tasks via the Task Scheduler. Adversaries exploit this by creating scheduled tasks to execute malicious scripts, facilitating lateral movement or remote discovery. The detection rule identifies suspicious PowerShell activity by monitoring for the Task Scheduler DLL load and subsequent outbound RPC connections, signaling potential misuse. + +### Possible investigation steps + +- Review the alert details to identify the specific host.id and process.entity_id associated with the suspicious activity. +- Examine the process execution history on the affected host to determine if the PowerShell process (powershell.exe, pwsh.exe, or powershell_ise.exe) has executed any unexpected or unauthorized scripts. +- Check the network logs for the host to identify any unusual or unauthorized outbound RPC connections, particularly those targeting port 135, and verify if the destination addresses are legitimate and expected. +- Investigate the context of the taskschd.dll library load by reviewing recent scheduled tasks on the host to identify any newly created or modified tasks that could be linked to the alert. +- Correlate the alert with other security events or logs from the same host or network segment to identify any patterns or additional indicators of compromise that may suggest lateral movement or remote discovery attempts. + +### False positive analysis + +- Legitimate administrative tasks using PowerShell may trigger the rule if they involve loading the Task Scheduler DLL and making RPC connections. To manage this, identify and whitelist specific scripts or processes that are known to perform these actions regularly. +- Automated system maintenance or monitoring tools might also load the Task Scheduler DLL and establish RPC connections. Review these tools and exclude their process IDs or hashes from the detection rule to prevent false alerts. +- Software updates or installations that use PowerShell scripts could mimic the behavior detected by the rule. Monitor update schedules and temporarily disable the rule during these periods if necessary, or create exceptions for known update processes. +- Developers or IT staff using PowerShell for legitimate remote management tasks may inadvertently trigger the rule. Implement user-based exceptions for trusted personnel or restrict the rule to non-administrative accounts to reduce false positives. + +### Response and remediation + +- Isolate the affected host immediately from the network to prevent further lateral movement or data exfiltration. +- Terminate the suspicious PowerShell process identified in the alert to stop any ongoing malicious activity. +- Conduct a forensic analysis of the affected system to identify any additional malicious scheduled tasks or scripts and remove them. +- Review and clean up any unauthorized scheduled tasks created on the system to ensure no persistence mechanisms remain. +- Reset credentials for any accounts that were used or potentially compromised during the incident to prevent unauthorized access. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the attack. +- Implement enhanced monitoring for similar PowerShell and scheduled task activities across the network to detect and respond to future threats promptly.""" [[rule.threat]] diff --git a/rules/windows/execution_suspicious_cmd_wmi.toml b/rules/windows/execution_suspicious_cmd_wmi.toml index 1e55aa7ab0d..6825f682e8f 100644 --- a/rules/windows/execution_suspicious_cmd_wmi.toml +++ b/rules/windows/execution_suspicious_cmd_wmi.toml @@ -2,7 +2,7 @@ creation_date = "2020/10/19" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2024/10/31" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -55,6 +55,41 @@ process where host.os.type == "windows" and event.type == "start" and process.parent.name : "WmiPrvSE.exe" and process.name : "cmd.exe" and process.args : "\\\\127.0.0.1\\*" and process.args : ("2>&1", "1>") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Cmd Execution via WMI + +Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. Adversaries exploit WMI for lateral movement by executing commands remotely, often using cmd.exe. The detection rule identifies such activity by monitoring for cmd.exe processes initiated by WmiPrvSE.exe with specific arguments, indicating potential misuse for executing commands on remote hosts. + +### Possible investigation steps + +- Review the process details to confirm the parent-child relationship between WmiPrvSE.exe and cmd.exe, ensuring that cmd.exe was indeed initiated by WmiPrvSE.exe. +- Examine the command-line arguments used by cmd.exe, specifically looking for the presence of "\\\\\\\\127.0.0.1\\\\*" and redirection operators like "2>&1" or "1>", to understand the nature of the command executed. +- Investigate the source and destination IP addresses involved in the WMI activity to determine if the remote host is legitimate or potentially compromised. +- Check for any related alerts or logs from the same host or user account around the same timeframe to identify any patterns or additional suspicious activities. +- Correlate the event with user activity logs to determine if the command execution aligns with expected user behavior or if it appears anomalous. +- Consult threat intelligence sources to see if the command or pattern matches known adversary techniques or campaigns. + +### False positive analysis + +- Legitimate administrative tasks using WMI may trigger this rule. System administrators often use WMI for remote management, which can include executing scripts or commands. To handle this, identify and whitelist known administrative accounts or specific scripts that are regularly used for maintenance. +- Automated scripts or software that rely on WMI for legitimate operations might also cause false positives. Review and document these processes, then create exceptions for them in the detection rule to prevent unnecessary alerts. +- Security software or monitoring tools that utilize WMI for system checks can inadvertently match the rule's criteria. Verify these tools and exclude their specific processes or arguments from the rule to reduce noise. +- Scheduled tasks or system updates that use WMI for execution might be flagged. Regularly review scheduled tasks and update the rule to exclude these known benign activities. +- Internal network monitoring or testing tools that simulate attacks for security assessments may trigger alerts. Ensure these activities are logged and excluded from the rule to avoid confusion during security evaluations. + +### Response and remediation + +- Isolate the affected host immediately to prevent further lateral movement and potential data exfiltration. Disconnect it from the network while maintaining power to preserve volatile data for forensic analysis. +- Terminate any suspicious cmd.exe processes initiated by WmiPrvSE.exe to halt any ongoing malicious activities. +- Conduct a thorough review of the affected system's WMI subscriptions and scripts to identify and remove any unauthorized or malicious entries. +- Reset credentials for any accounts that were used in the suspicious activity to prevent further unauthorized access. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Enhance monitoring and logging for WMI activities across the network to detect similar threats in the future, ensuring that logs are retained for an adequate period for forensic purposes. +- 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.""" [[rule.threat]] diff --git a/rules/windows/execution_suspicious_image_load_wmi_ms_office.toml b/rules/windows/execution_suspicious_image_load_wmi_ms_office.toml index dc17bde0562..f76e6b136e1 100644 --- a/rules/windows/execution_suspicious_image_load_wmi_ms_office.toml +++ b/rules/windows/execution_suspicious_image_load_wmi_ms_office.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/17" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -50,6 +50,40 @@ any where host.os.type == "windows" and process.name : ("WINWORD.EXE", "EXCEL.EXE", "POWERPNT.EXE", "MSPUB.EXE", "MSACCESS.EXE") and (?dll.name : "wmiutils.dll" or file.name : "wmiutils.dll") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious WMI Image Load from MS Office + +Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. Adversaries exploit WMI to execute code stealthily, bypassing traditional security measures by spawning processes indirectly. The detection rule identifies unusual loading of the `wmiutils.dll` library by Microsoft Office applications, signaling potential misuse of WMI for malicious execution. This rule leverages event categories and process names to pinpoint suspicious activity, aiding in early threat detection. + +### Possible investigation steps + +- Review the alert details to confirm the specific Microsoft Office process involved (e.g., WINWORD.EXE, EXCEL.EXE) and the associated event category (library, driver, or process). +- Check the process execution history to determine if the process has a legitimate reason to load the wmiutils.dll library, such as recent updates or legitimate automation tasks. +- Investigate the parent process of the flagged Microsoft Office application to identify any unusual or unexpected parent-child process relationships that could indicate malicious activity. +- Analyze recent user activity on the affected system to identify any suspicious behavior or unauthorized access that might correlate with the alert. +- Examine network connections and data transfers initiated by the flagged process to detect any potential data exfiltration or communication with known malicious IP addresses. +- Cross-reference the alert with other security logs and alerts to identify any patterns or additional indicators of compromise that might suggest a broader attack campaign. + +### False positive analysis + +- Legitimate use of WMI by Microsoft Office applications for automation tasks or system management can trigger the rule. Users should verify if the activity aligns with expected administrative tasks. +- Some third-party plugins or add-ins for Microsoft Office may load wmiutils.dll for legitimate purposes. Users can create exceptions for these known plugins after confirming their benign nature. +- Scheduled tasks or scripts that utilize WMI for legitimate business processes might cause false positives. Review and document these processes, then exclude them from the rule if they are verified as non-threatening. +- Security or monitoring tools that interact with Office applications and use WMI for data collection could be flagged. Ensure these tools are recognized and excluded from the rule after validation. + +### Response and remediation + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious Microsoft Office processes identified in the alert that are loading the `wmiutils.dll` library. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious code or files. +- Review and analyze the system's WMI repository and scripts for unauthorized or suspicious entries, and remove any that are identified as malicious. +- Restore the system from a known good backup if malicious activity has compromised system integrity or data. +- 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 enhanced monitoring and logging for WMI activity and Microsoft Office processes to detect similar threats in the future.""" [[rule.threat]] diff --git a/rules/windows/execution_via_mmc_console_file_unusual_path.toml b/rules/windows/execution_via_mmc_console_file_unusual_path.toml index 5e8bd3c2454..9bce81762f0 100644 --- a/rules/windows/execution_via_mmc_console_file_unusual_path.toml +++ b/rules/windows/execution_via_mmc_console_file_unusual_path.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende maturity = "production" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." min_stack_version = "8.14.0" -updated_date = "2024/10/31" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -50,6 +50,40 @@ process where host.os.type == "windows" and event.type == "start" and "?:\\Program Files (x86)\\*.msc" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft Management Console File from Unusual Path + +Microsoft Management Console (MMC) is a Windows utility that provides a framework for system management. Adversaries may exploit MMC by executing .msc files from non-standard directories to bypass security controls. The detection rule identifies such anomalies by monitoring the execution of mmc.exe with .msc files from untrusted paths, flagging potential unauthorized access or execution attempts. + +### Possible investigation steps + +- Review the process execution details to confirm the path of the mmc.exe and the .msc file being executed. Check if the path is indeed non-standard or untrusted as per the query criteria. +- Investigate the origin of the .msc file by examining file creation and modification timestamps, and check for any recent changes or unusual activity in the directory where the file resides. +- Analyze the user account associated with the process execution to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Check for any related alerts or logs around the same timeframe that might indicate lateral movement or other malicious activities, such as unusual network connections or file access patterns. +- Correlate the event with other data sources mentioned in the rule, such as Microsoft Defender for Endpoint or Crowdstrike, to gather additional context or corroborating evidence of potential malicious activity. +- Assess the risk and impact of the execution by determining if the .msc file has any known malicious signatures or if it attempts to perform unauthorized actions on the system. + +### False positive analysis + +- Legitimate administrative tasks may trigger this rule if system administrators execute .msc files from custom directories. To manage this, create exceptions for known administrative scripts or tools that are regularly used from non-standard paths. +- Software installations or updates might involve executing .msc files from temporary or installation directories. Monitor these activities and whitelist specific installation paths if they are verified as safe and part of routine operations. +- Automated scripts or third-party management tools could execute .msc files from non-standard locations as part of their normal operation. Identify these tools and add their execution paths to the exception list to prevent unnecessary alerts. +- Development or testing environments may involve running .msc files from various directories for testing purposes. Establish a separate monitoring policy for these environments or exclude known development paths to reduce false positives. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes related to mmc.exe executing from untrusted paths to halt potential malicious activity. +- Conduct a thorough review of the system's recent activity logs to identify any additional indicators of compromise or related suspicious activities. +- Remove any unauthorized .msc files found in non-standard directories and ensure they are not reintroduced. +- Restore the system from a known good backup if any unauthorized changes or damage is detected. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/execution_windows_cmd_shell_susp_args.toml b/rules/windows/execution_windows_cmd_shell_susp_args.toml index d6bb9f17af1..f7b239b8f3b 100644 --- a/rules/windows/execution_windows_cmd_shell_susp_args.toml +++ b/rules/windows/execution_windows_cmd_shell_susp_args.toml @@ -4,7 +4,7 @@ integration = ["windows", "system", "sentinel_one_cloud_funnel", "m365_defender" maturity = "production" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." min_stack_version = "8.14.0" -updated_date = "2024/10/15" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -104,6 +104,41 @@ process where host.os.type == "windows" and event.type == "start" and not (process.name : "cmd.exe" and process.args : "%TEMP%\\Spiceworks\\*" and process.args : "http*/dataloader/persist_netstat_data") and not (process.args == "echo" and process.args == "GEQ" and process.args == "1073741824") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Windows Command Shell Arguments + +The Windows Command Shell (cmd.exe) is a critical component for executing commands and scripts. Adversaries exploit it to execute malicious scripts, download payloads, or manipulate system settings. The detection rule identifies unusual command-line arguments and patterns indicative of such abuse, filtering out known benign processes to minimize false positives. This helps in early detection of potential threats by monitoring for suspicious command executions. + +### Possible investigation steps + +- Review the command line arguments associated with the cmd.exe process to identify any suspicious patterns or keywords such as "curl", "regsvr32", "wscript", or "Invoke-WebRequest" that may indicate malicious activity. +- Check the parent process of the cmd.exe execution to determine if it is a known benign process or if it is associated with potentially malicious activity, especially if the parent process is explorer.exe or other unusual executables. +- Investigate the user account associated with the cmd.exe process to determine if the activity aligns with the user's typical behavior or if it appears anomalous. +- Examine the network activity of the host to identify any unusual outbound connections or data transfers that may correlate with the suspicious command execution. +- Cross-reference the alert with other security logs or alerts from tools like Sysmon, SentinelOne, or Microsoft Defender for Endpoint to gather additional context and corroborate findings. +- Assess the risk score and severity of the alert to prioritize the investigation and determine if immediate response actions are necessary. + +### False positive analysis + +- Processes related to Spiceworks and wmiprvse.exe can trigger false positives. Exclude these by adding exceptions for process arguments containing "%TEMP%\\\\Spiceworks\\\\*" when the parent process is wmiprvse.exe. +- Development tools like Perl, Node.js, and NetBeans may cause false alerts. Exclude these by specifying their executable paths in the exception list. +- Citrix Secure Access Client initiated by userinit.exe can be a false positive. Exclude this by adding an exception for process arguments containing "?:\\\\Program Files\\\\Citrix\\\\Secure Access Client\\\\nsauto.exe" with the parent process name as userinit.exe. +- Scheduled tasks or services like PCPitstopScheduleService.exe may trigger alerts. Exclude these by adding their paths to the exception list. +- Command-line operations involving npm or Maven commands can be benign. Exclude these by specifying command-line patterns like "\\"cmd\\" /c %NETBEANS_MAVEN_COMMAND_LINE%" in the exception list. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of potential malware or unauthorized access. +- Terminate any suspicious cmd.exe processes identified by the detection rule to halt malicious activity. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or scripts. +- Review and restore any altered system settings or configurations to their original state to ensure system integrity. +- Analyze the command-line arguments and parent processes involved in the alert to understand the scope and origin of the threat, and identify any additional compromised systems. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional containment measures are necessary. +- Implement additional monitoring and detection rules to identify similar suspicious command-line activities in the future, enhancing the organization's ability to detect and respond to such threats promptly.""" [[rule.threat]] diff --git a/rules/windows/execution_windows_powershell_susp_args.toml b/rules/windows/execution_windows_powershell_susp_args.toml index 190e0bee76c..a45cfcd0ba0 100644 --- a/rules/windows/execution_windows_powershell_susp_args.toml +++ b/rules/windows/execution_windows_powershell_susp_args.toml @@ -4,7 +4,7 @@ integration = ["windows", "system", "sentinel_one_cloud_funnel", "m365_defender" maturity = "production" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." min_stack_version = "8.14.0" -updated_date = "2024/10/31" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -106,6 +106,41 @@ process where host.os.type == "windows" and event.type == "start" and process.command_line : ("*-encodedCommand*", "*Invoke-webrequest*", "*WebClient*", "*Reflection.Assembly*")) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Windows Powershell Arguments + +PowerShell is a powerful scripting language and command-line shell used for task automation and configuration management in Windows environments. Adversaries exploit PowerShell's capabilities to execute malicious scripts, download payloads, and obfuscate commands. The detection rule identifies unusual PowerShell arguments indicative of such abuse, focusing on patterns like encoded commands, suspicious downloads, and obfuscation techniques, thereby flagging potential threats for further investigation. + +### Possible investigation steps + +- Review the process command line and arguments to identify any encoded or obfuscated content, such as Base64 strings or unusual character sequences, which may indicate malicious intent. +- Check the parent process of the PowerShell execution, especially if it is explorer.exe or cmd.exe, to determine if the PowerShell instance was launched from a suspicious or unexpected source. +- Investigate any network activity associated with the PowerShell process, particularly looking for connections to known malicious domains or IP addresses, or the use of suspicious commands like DownloadFile or DownloadString. +- Examine the user account associated with the PowerShell execution to determine if it aligns with expected behavior or if it might be compromised. +- Correlate the event with other security alerts or logs from the same host or user to identify patterns or additional indicators of compromise. +- Assess the risk and impact of the detected activity by considering the context of the environment, such as the presence of sensitive data or critical systems that might be affected. + +### False positive analysis + +- Legitimate administrative scripts may use encoded commands for obfuscation to protect sensitive data. Review the script's source and purpose to determine if it is authorized. If confirmed, add the script's hash or specific command pattern to an allowlist. +- Automated software deployment tools might use PowerShell to download and execute scripts from trusted internal sources. Verify the source and destination of the download. If legitimate, exclude the specific tool or process from the detection rule. +- System maintenance tasks often involve PowerShell scripts that manipulate files or system settings. Identify routine maintenance scripts and exclude their specific command patterns or file paths from triggering the rule. +- Security software may use PowerShell for scanning or remediation tasks, which can mimic suspicious behavior. Confirm the software's legitimacy and add its processes to an exception list to prevent false alerts. +- Developers might use PowerShell for testing or development purposes, which can include obfuscation techniques. Validate the developer's activities and exclude their specific development environments or scripts from the rule. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing malicious activities. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious payloads or scripts. +- Review and clean up any unauthorized changes to system configurations or scheduled tasks that may have been altered by the malicious PowerShell activity. +- Restore any affected files or system components from known good backups to ensure system integrity and functionality. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are compromised. +- Implement additional monitoring and logging for PowerShell activities across the network to enhance detection of similar threats in the future.""" [[rule.threat]] diff --git a/rules/windows/exfiltration_smb_rare_destination.toml b/rules/windows/exfiltration_smb_rare_destination.toml index 4d605159cf9..67542883b04 100644 --- a/rules/windows/exfiltration_smb_rare_destination.toml +++ b/rules/windows/exfiltration_smb_rare_destination.toml @@ -2,7 +2,7 @@ creation_date = "2023/12/04" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -79,6 +79,41 @@ event.category:network and host.os.type:windows and process.pid:4 and "FF00::/8" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Rare SMB Connection to the Internet + +Server Message Block (SMB) is a protocol used for sharing files and printers within a network. Adversaries exploit SMB to exfiltrate data by injecting rogue paths to capture NTLM credentials. The detection rule identifies unusual SMB traffic from internal IPs to external networks, flagging potential exfiltration attempts by monitoring specific ports and excluding known safe IP ranges. + +### Possible investigation steps + +- Review the alert details to identify the internal source IP address involved in the SMB connection and verify if it belongs to a known or authorized device within the organization. +- Check the destination IP address to determine if it is associated with any known malicious activity or if it belongs to an external network that should not be receiving SMB traffic from internal systems. +- Investigate the process with PID 4 on the source host, which typically corresponds to the Windows System process, to identify any unusual activity or recent changes that could indicate compromise or misuse. +- Analyze network logs to trace the SMB traffic flow and identify any patterns or additional connections that may suggest data exfiltration attempts. +- Correlate the alert with other security events or logs from data sources like Microsoft Defender for Endpoint or Sysmon to gather additional context and determine if this is part of a larger attack campaign. +- Consult with the IT or network team to verify if there are any legitimate business reasons for the detected SMB traffic to the external network, and if not, consider blocking the connection and conducting a deeper investigation into the source host. + +### False positive analysis + +- Internal network scanning tools may trigger alerts if they simulate SMB traffic to external IPs. Exclude IPs associated with these tools from the rule to prevent false positives. +- Legitimate business applications that require SMB connections to external cloud services might be flagged. Identify and whitelist these specific external IPs or domains to avoid unnecessary alerts. +- Backup solutions that use SMB for data transfer to offsite locations can be mistaken for exfiltration attempts. Ensure these backup service IPs are added to the exception list. +- Misconfigured network devices that inadvertently route SMB traffic externally could cause false alerts. Regularly audit and correct device configurations to minimize these occurrences. +- Security testing or penetration testing activities might generate SMB traffic to external IPs. Coordinate with security teams to temporarily disable the rule or add exceptions during testing periods. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further data exfiltration or lateral movement. +- Conduct a thorough review of the host's network connections and processes to identify any unauthorized SMB traffic or suspicious activities. +- Reset credentials for any accounts that may have been exposed or compromised, focusing on those with elevated privileges. +- Apply patches and updates to the affected system and any other vulnerable systems to mitigate known SMB vulnerabilities. +- Implement network segmentation to limit SMB traffic to only necessary internal communications, reducing the risk of external exposure. +- Enhance monitoring and logging for SMB traffic, particularly for connections to external IPs, to detect and respond to future anomalies more effectively. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/initial_access_evasion_suspicious_htm_file_creation.toml b/rules/windows/initial_access_evasion_suspicious_htm_file_creation.toml index 9833b3ed3e6..931cf623700 100644 --- a/rules/windows/initial_access_evasion_suspicious_htm_file_creation.toml +++ b/rules/windows/initial_access_evasion_suspicious_htm_file_creation.toml @@ -2,7 +2,7 @@ creation_date = "2022/07/03" integration = ["endpoint"] maturity = "production" -updated_date = "2024/08/08" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -15,7 +15,43 @@ index = ["logs-endpoint.events.process-*", "logs-endpoint.events.file-*"] language = "eql" license = "Elastic License v2" name = "Suspicious HTML File Creation" -note = "This rule may have a low to medium performance impact due variety of file paths potentially matching each EQL sequence." +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious HTML File Creation + +HTML files, typically used for web content, can be exploited by adversaries to smuggle malicious payloads past security filters. By embedding harmful data within seemingly benign HTML files, attackers can bypass traditional defenses. The detection rule identifies such threats by monitoring the creation of HTML files with unusual characteristics, such as high entropy or large size, in common download and temporary directories. It also tracks browser processes that open these files, ensuring that any suspicious activity is flagged for further investigation. This approach helps in identifying potential phishing attempts and other initial access tactics used by attackers. + +### Possible investigation steps + +- Review the file creation or rename event details to confirm the file extension is .htm or .html and check if the file's entropy is 5 or higher or if the file size is 150,000 bytes or more. +- Verify the file path to ensure it is located in one of the common download or temporary directories specified in the rule, such as "?:\\Users\\*\\Downloads\\*" or "?:\\Users\\*\\AppData\\Local\\Temp\\*". +- Examine the process start event to identify the browser process involved, ensuring it matches one of the specified browsers like chrome.exe or firefox.exe, and check if the process arguments align with the rule's conditions. +- Investigate the user.id associated with the sequence to determine if the activity aligns with the user's typical behavior or if it appears suspicious. +- Check for any recent phishing attempts or suspicious emails received by the user that could have led to the download and execution of the HTML file. +- Analyze the content of the HTML file for any embedded scripts or links that could indicate malicious intent or payload delivery. + +### False positive analysis + +- Legitimate large HTML files downloaded from trusted sources may trigger the rule. Users can create exceptions for specific trusted domains or file hashes to prevent these from being flagged. +- HTML files generated by certain applications or services, such as email clients or document converters, might have high entropy due to embedded data. Identify these applications and exclude their file creation paths from monitoring. +- Temporary HTML files created during software updates or installations in the AppData or Temp directories can be mistaken for suspicious activity. Monitor and whitelist known update processes to reduce false positives. +- Browser extensions or plugins that save web content locally might create HTML files with characteristics similar to those flagged by the rule. Review and whitelist extensions that are known to be safe and necessary for business operations. +- Automated scripts or tools that process web content and save it as HTML files could be misidentified. Ensure these scripts are documented and their file paths are excluded from the rule's scope. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity. +- Terminate any suspicious browser processes identified in the alert to stop the execution of potentially harmful HTML files. +- Quarantine the suspicious HTML files detected in the specified directories to prevent accidental execution or further access by users. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional threats or malicious payloads. +- Review and analyze the system and network logs to identify any lateral movement or additional compromised systems, escalating findings to the security team for further investigation. +- Restore any affected files or systems from known good backups to ensure the integrity and availability of data and services. +- Implement additional monitoring and alerting for similar activities, focusing on high entropy and large HTML files in common download and temporary directories to enhance detection capabilities. + +This rule may have a low to medium performance impact due variety of file paths potentially matching each EQL sequence.""" risk_score = 47 rule_id = "f0493cb4-9b15-43a9-9359-68c23a7f2cf3" setup = """## Setup diff --git a/rules/windows/initial_access_execution_from_inetcache.toml b/rules/windows/initial_access_execution_from_inetcache.toml index 78d9de0f304..9a49917fbe7 100644 --- a/rules/windows/initial_access_execution_from_inetcache.toml +++ b/rules/windows/initial_access_execution_from_inetcache.toml @@ -2,7 +2,7 @@ creation_date = "2024/02/14" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2024/10/31" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -61,6 +61,41 @@ process where host.os.type == "windows" and event.type == "start" and ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Execution from INET Cache + +The INetCache folder stores temporary internet files, which can be exploited by adversaries to execute malicious payloads delivered via WININET. Attackers may disguise malware as legitimate files cached during browsing. The detection rule identifies suspicious processes initiated from this cache, especially when launched by common file explorers, signaling potential initial access or command and control activities. + +### Possible investigation steps + +- Review the process details to confirm the executable path and arguments match the INetCache folder pattern specified in the query. +- Identify the parent process, such as explorer.exe, winrar.exe, 7zFM.exe, or Bandizip.exe, to determine if the process launch is consistent with typical user behavior or potentially malicious activity. +- Check the user account associated with the process to assess if the activity aligns with the user's normal behavior or if the account may be compromised. +- Investigate the file in the INetCache directory for known malware signatures or anomalies using antivirus or endpoint detection tools. +- Analyze network activity from the host to identify any suspicious connections that may indicate command and control communication. +- Correlate the event with other security alerts or logs to identify patterns or additional indicators of compromise related to the initial access or command and control tactics. + +### False positive analysis + +- Legitimate software updates or installations may temporarily use the INetCache folder for storing executable files. Users can create exceptions for known update processes by identifying their specific executable paths and excluding them from the rule. +- Some browser extensions or plugins might cache executable files in the INetCache folder during normal operations. Users should monitor and whitelist these extensions if they are verified as safe and frequently trigger alerts. +- Automated scripts or tools that interact with web content might inadvertently store executables in the INetCache folder. Users can adjust the rule to exclude these scripts by specifying their parent process names or paths. +- Certain enterprise applications may use the INetCache folder for legitimate purposes. Users should collaborate with IT departments to identify these applications and configure exceptions based on their unique process signatures. +- Regularly review and update the list of excluded processes to ensure that only verified and non-threatening activities are exempt from triggering alerts. + +### Response and remediation + +- Isolate the affected system from the network to prevent further communication with potential command and control servers. +- Terminate any suspicious processes identified as originating from the INetCache folder to halt any ongoing malicious activity. +- Delete any malicious files found within the INetCache directory to remove the immediate threat. +- Conduct a full antivirus and antimalware scan on the affected system to identify and remove any additional threats. +- Review and analyze recent email logs and web browsing history to identify potential phishing attempts or malicious downloads that may have led to the initial compromise. +- 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 enhanced monitoring and logging for the INetCache directory and related processes to detect similar threats in the future.""" [[rule.threat]] diff --git a/rules/windows/initial_access_execution_from_removable_media.toml b/rules/windows/initial_access_execution_from_removable_media.toml index 495c84b76fd..e9438f064b5 100644 --- a/rules/windows/initial_access_execution_from_removable_media.toml +++ b/rules/windows/initial_access_execution_from_removable_media.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/27" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -39,6 +39,42 @@ sequence by process.entity_id with maxspan=5m not process.code_signature.status : ("errorExpired", "errorCode_endpoint*")] [network where host.os.type == "windows" and event.action == "connection_attempted"] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Execution from a Removable Media with Network Connection + +Removable media, like USB drives, are often used for data transfer but can be exploited by adversaries to introduce malware into isolated systems. Attackers may leverage autorun features to execute malicious code upon insertion. The detection rule identifies suspicious process executions from USB devices, especially those lacking valid code signatures, and correlates them with network connection attempts, signaling potential unauthorized access efforts. + +### Possible investigation steps + +- Review the process execution details, focusing on the process.entity_id to identify the specific process that was executed from the USB device. +- Check the process.Ext.device.bus_type and process.Ext.device.product_id fields to confirm the involvement of a USB device and gather information about the specific device used. +- Investigate the process.code_signature fields to determine if the process lacks a valid code signature, which could indicate malicious intent. +- Correlate the process execution with network connection attempts by examining the network event logs, particularly looking for any unusual or unauthorized connection attempts. +- Assess the context of the network connection attempt, including the destination IP address and port, to evaluate the potential risk and intent of the connection. +- Gather additional context by reviewing recent activity on the host, such as other process executions or file modifications, to identify any further signs of compromise. +- If necessary, isolate the affected system to prevent further unauthorized access or data exfiltration while continuing the investigation. + +### False positive analysis + +- Legitimate software installations from USB drives may trigger the rule. To manage this, create exceptions for known software installers by verifying their code signatures and adding them to an allowlist. +- IT administrators often use USB devices for system updates or maintenance. Identify and exclude these activities by correlating them with known administrator accounts or devices. +- Some organizations use USB devices for regular data transfers. Establish a baseline of normal USB activity and exclude these patterns from triggering alerts. +- Devices with expired but previously trusted code signatures might be flagged. Regularly update the list of trusted certificates and exclude processes with known expired signatures that are still considered safe. +- Network connection attempts by legitimate applications running from USB drives can be mistaken for threats. Monitor and document these applications, then configure exceptions based on their process names and network behavior. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Disable autorun features on all systems to prevent automatic execution of potentially malicious code from removable media. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malware. +- Review and block any suspicious network connections originating from the affected system to prevent communication with potential command and control servers. +- Collect and preserve relevant logs and forensic evidence from the affected system and removable media for further analysis and potential legal action. +- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine if other systems may be affected. +- Implement enhanced monitoring and alerting for similar activities, focusing on process executions from removable media and unauthorized network connection attempts.""" [[rule.threat]] diff --git a/rules/windows/initial_access_execution_remote_via_msiexec.toml b/rules/windows/initial_access_execution_remote_via_msiexec.toml index 054e39cfd39..c98affc9b30 100644 --- a/rules/windows/initial_access_execution_remote_via_msiexec.toml +++ b/rules/windows/initial_access_execution_remote_via_msiexec.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/28" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -61,6 +61,41 @@ sequence with maxspan=1m not (process.name : "rundll32.exe" and process.args : "printui.dll,PrintUIEntry") ] by process.parent.entity_id ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Remote File Execution via MSIEXEC + +MSIEXEC, the Windows Installer, facilitates software installation, modification, and removal. Adversaries exploit it to execute remote MSI files, bypassing security controls. The detection rule identifies suspicious MSIEXEC activity by monitoring process starts, network connections, and child processes, filtering out known benign signatures and paths, thus highlighting potential misuse for initial access or defense evasion. + +### Possible investigation steps + +- Review the process start event for msiexec.exe to identify the command-line arguments used, focusing on the presence of the "/V" flag, which indicates a remote installation attempt. +- Examine the network connection attempts associated with msiexec.exe to determine the remote IP addresses or domains being contacted, and assess their reputation or any known associations with malicious activity. +- Investigate the child processes spawned by msiexec.exe, especially those not matching known benign executables or paths, to identify any suspicious or unexpected activity. +- Check the user ID associated with the msiexec.exe process to verify if it aligns with expected user behavior or if it indicates potential compromise, especially focusing on user IDs like "S-1-5-21-*" or "S-1-5-12-1-*". +- Analyze the code signature of any child processes to ensure they are trusted and expected, paying particular attention to any unsigned or untrusted executables. +- Correlate the alert with any recent phishing attempts or suspicious emails received by the user, as the MITRE ATT&CK technique T1566 (Phishing) is associated with this rule. + +### False positive analysis + +- Legitimate software installations using msiexec.exe may trigger the rule. To manage this, create exceptions for known software update processes that use msiexec.exe with trusted code signatures. +- System maintenance tasks that involve msiexec.exe, such as Windows updates or system repairs, can be excluded by identifying and allowing specific system paths and executables involved in these processes. +- Enterprise software deployment tools that utilize msiexec.exe for remote installations might cause false positives. Exclude these by verifying the code signature and adding exceptions for trusted deployment tools. +- Administrative scripts or automation tools that invoke msiexec.exe for legitimate purposes should be reviewed and, if verified as safe, excluded based on their execution context and code signature. +- Network monitoring tools or security software that simulate msiexec.exe activity for testing or monitoring purposes can be excluded by identifying their specific signatures and paths. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. This can be done by disabling network interfaces or moving the system to a quarantine VLAN. +- Terminate the msiexec.exe process if it is still running to stop any ongoing malicious activity. Use task management tools or scripts to ensure the process is completely stopped. +- Conduct a thorough review of the system for any unauthorized changes or installations. Check for newly installed software or modifications to system files that could indicate further compromise. +- Restore the system from a known good backup if unauthorized changes are detected and cannot be easily reversed. Ensure the backup is clean and free from any malicious alterations. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. This includes applying all relevant Windows updates and security patches. +- Enhance monitoring and logging on the affected system and network to detect any similar future attempts. Ensure that all relevant security events are being captured and analyzed. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. Provide them with all relevant logs and findings for a comprehensive analysis.""" [[rule.threat]] diff --git a/rules/windows/initial_access_execution_via_office_addins.toml b/rules/windows/initial_access_execution_via_office_addins.toml index 4faad5dfbcf..dabf610c6f9 100644 --- a/rules/windows/initial_access_execution_via_office_addins.toml +++ b/rules/windows/initial_access_execution_via_office_addins.toml @@ -2,7 +2,7 @@ creation_date = "2023/03/20" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -81,6 +81,40 @@ process where process.parent.args : "?:\\WINDOWS\\Installer\\MSI*.tmp,zzzzInvokeManagedCustomActionOutOfProc") and not (process.name : "VSTOInstaller.exe" and process.args : "https://dl.getsidekick.com/outlook/vsto/Sidekick.vsto") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Execution via Microsoft Office Add-Ins + +Microsoft Office Add-Ins enhance productivity by integrating additional features into Office applications. However, adversaries can exploit this by embedding malicious code within add-ins, often delivered through phishing. The detection rule identifies unusual execution patterns, such as Office apps launching add-ins from suspicious paths or with atypical parent processes, signaling potential threats. It filters out known benign activities to minimize false positives, focusing on genuine anomalies indicative of malicious intent. + +### Possible investigation steps + +- Review the process name and arguments to confirm if the execution involves a Microsoft Office application launching an add-in from a suspicious path, as indicated by the process.name and process.args fields. +- Check the parent process name to determine if the Office application was launched by an unusual or potentially malicious parent process, such as cmd.exe or powershell.exe, using the process.parent.name field. +- Investigate the file path from which the add-in was executed to assess if it matches any of the suspicious paths listed in the query, such as the Temp or Downloads directories, using the process.args field. +- Examine the host's recent activity logs to identify any related events or patterns that might indicate a broader attack or compromise, focusing on the host.os.type and event.type fields. +- Correlate the alert with any recent phishing attempts or suspicious emails received by the user to determine if the execution is part of a phishing campaign, leveraging the MITRE ATT&CK tactic and technique information provided. +- Verify if the execution is a false positive by checking against the known benign activities excluded in the query, such as specific VSTOInstaller.exe paths or arguments, to rule out legitimate software installations or updates. + +### False positive analysis + +- Logitech software installations can trigger false positives when VSTO files are executed by Logitech's PlugInInstallerUtility. To mitigate this, exclude processes with paths related to Logitech installations from the detection rule. +- The VSTOInstaller.exe process may be flagged when uninstalling applications. Exclude processes with the /Uninstall argument to prevent these false positives. +- Rundll32.exe executing with specific arguments related to MSI temporary files can be benign. Exclude these specific rundll32.exe executions to avoid false alerts. +- Sidekick.vsto installations from the specified URL can be legitimate. Exclude this specific VSTOInstaller.exe process with the Sidekick.vsto argument to reduce false positives. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any ongoing malicious activity. +- Terminate any suspicious processes identified by the detection rule, such as those involving unusual parent processes or originating from suspicious paths. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious add-ins or related malware. +- Review and clean up any unauthorized or suspicious Office add-ins from the affected applications to ensure no malicious code remains. +- Restore the system from a known good backup if the integrity of the system is compromised and cannot be assured through cleaning alone. +- 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 similar suspicious activities to enhance detection and response capabilities for future incidents.""" [[rule.threat]] diff --git a/rules/windows/initial_access_exfiltration_first_time_seen_usb.toml b/rules/windows/initial_access_exfiltration_first_time_seen_usb.toml index 288d91f4f02..2597f2957a8 100644 --- a/rules/windows/initial_access_exfiltration_first_time_seen_usb.toml +++ b/rules/windows/initial_access_exfiltration_first_time_seen_usb.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funne min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." min_stack_version = "8.14.0" maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -49,6 +49,40 @@ type = "new_terms" query = ''' event.category:"registry" and host.os.type:"windows" and registry.value:"FriendlyName" and registry.path:*USBSTOR* ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 First Time Seen Removable Device + +Removable devices, like USB drives, are common in Windows environments for data transfer. Adversaries exploit these to introduce malware or exfiltrate data, leveraging their plug-and-play nature. The detection rule monitors registry changes for new device names, signaling potential unauthorized access. By focusing on first-time-seen devices, it helps identify suspicious activities linked to data exfiltration or initial access attempts. + +### Possible investigation steps + +- Review the registry event details to confirm the presence of a new device by checking the registry.value for "FriendlyName" and registry.path for USBSTOR. +- Correlate the timestamp of the registry event with user activity logs to identify which user was logged in at the time of the device connection. +- Check for any subsequent file access or transfer events involving the new device to assess potential data exfiltration. +- Investigate the device's history by searching for any previous connections to other systems within the network to determine if it has been used elsewhere. +- Analyze any related alerts or logs from data sources like Elastic Endgame, Sysmon, or Microsoft Defender for Endpoint for additional context or suspicious activities linked to the device. + +### False positive analysis + +- Frequent use of company-issued USB drives for legitimate data transfer can trigger alerts. Maintain a list of approved devices and create exceptions for these in the monitoring system. +- Software updates or installations via USB drives may be flagged. Identify and whitelist known update devices or processes to prevent unnecessary alerts. +- IT department activities involving USB devices for maintenance or troubleshooting can appear suspicious. Coordinate with IT to log and exclude these routine operations from triggering alerts. +- Devices used for regular backups might be detected as new. Ensure backup devices are registered and excluded from the rule to avoid false positives. +- Personal USB devices used by employees for non-work-related purposes can cause alerts. Implement a policy for registering personal devices and exclude them if deemed non-threatening. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent potential data exfiltration or further spread of malware. +- Conduct a thorough scan of the isolated host using updated antivirus and anti-malware tools to identify and remove any malicious software introduced via the removable device. +- Review and analyze the registry changes logged by the detection rule to confirm the legitimacy of the device and assess any unauthorized access attempts. +- If malicious activity is confirmed, collect and preserve relevant logs and evidence for further forensic analysis and potential legal action. +- Notify the security team and relevant stakeholders about the incident, providing details of the device and any identified threats. +- Implement a temporary block on the use of removable devices across the network until the threat is fully contained and remediated. +- Enhance monitoring and detection capabilities by updating security tools and rules to better identify similar threats in the future, focusing on registry changes and device connections.""" [[rule.threat]] diff --git a/rules/windows/initial_access_exploit_jetbrains_teamcity.toml b/rules/windows/initial_access_exploit_jetbrains_teamcity.toml index bd42e3ff3ef..a718f46c188 100644 --- a/rules/windows/initial_access_exploit_jetbrains_teamcity.toml +++ b/rules/windows/initial_access_exploit_jetbrains_teamcity.toml @@ -2,7 +2,7 @@ creation_date = "2024/03/24" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -72,6 +72,41 @@ process where host.os.type == "windows" and event.type == "start" and not (process.name : "powershell.exe" and process.args : "-ExecutionPolicy" and process.args : "?:\\TeamCity\\buildAgent\\work\\*.ps1") and not (process.name : "cmd.exe" and process.args : "dir" and process.args : "/-c") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious JetBrains TeamCity Child Process + +JetBrains TeamCity is a continuous integration and deployment server used to automate software development processes. Adversaries may exploit vulnerabilities in TeamCity to execute unauthorized code, potentially spawning malicious child processes. The detection rule identifies unusual child processes initiated by TeamCity's Java executable, flagging potential exploitation attempts by monitoring for known suspicious executables, while excluding legitimate operations. + +### Possible investigation steps + +- Review the process tree to identify the parent and child processes associated with the suspicious activity, focusing on the parent executable paths like "?:\\TeamCity\\jre\\bin\\java.exe". +- Examine the command-line arguments of the suspicious child processes, especially those involving "cmd.exe" or "powershell.exe", to understand the actions being executed. +- Check for any recent vulnerabilities or patches related to JetBrains TeamCity that might explain the suspicious behavior. +- Investigate the user account under which the suspicious processes were executed to determine if it aligns with expected usage patterns or if it indicates potential compromise. +- Correlate the alert with other security events or logs from data sources like Sysmon or Microsoft Defender for Endpoint to identify any related malicious activity or indicators of compromise. +- Assess network activity from the host to detect any unusual outbound connections that might suggest data exfiltration or communication with a command and control server. + +### False positive analysis + +- Legitimate build scripts may invoke command-line utilities like cmd.exe or powershell.exe. To handle these, create exceptions for specific scripts by matching known safe arguments or paths. +- Automated tasks or maintenance scripts might use network utilities such as ping.exe or netstat.exe. Exclude these by identifying and allowing specific scheduled tasks or maintenance windows. +- System monitoring tools could trigger processes like tasklist.exe or systeminfo.exe. Whitelist these tools by verifying their source and ensuring they are part of authorized monitoring solutions. +- Development or testing environments may frequently use utilities like explorer.exe or control.exe. Establish exceptions for these environments by defining specific hostnames or IP ranges where such activity is expected. +- Custom scripts or applications might use msiexec.exe for legitimate software installations. Allow these by confirming the source and purpose of the installations, and excluding them based on known safe paths or signatures. + +### Response and remediation + +- Immediately isolate the affected TeamCity server from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious child processes identified by the detection rule, such as cmd.exe or powershell.exe, to halt potential malicious activities. +- Conduct a thorough review of recent changes and deployments in TeamCity to identify any unauthorized modifications or suspicious activities. +- Apply the latest security patches and updates to TeamCity and its underlying Java runtime environment to mitigate known vulnerabilities. +- Restore the affected system from a clean backup taken before the suspicious activity was detected, ensuring no remnants of the exploit remain. +- Monitor network traffic and system logs for any signs of continued or related suspicious activity, focusing on the indicators identified in the detection rule. +- Escalate the incident to the security operations center (SOC) or relevant IT security team for further investigation and to assess the need for additional security measures.""" [[rule.threat]] diff --git a/rules/windows/initial_access_rdp_file_mail_attachment.toml b/rules/windows/initial_access_rdp_file_mail_attachment.toml index 87b45b1a35b..1e27db0f462 100644 --- a/rules/windows/initial_access_rdp_file_mail_attachment.toml +++ b/rules/windows/initial_access_rdp_file_mail_attachment.toml @@ -2,7 +2,7 @@ creation_date = "2024/11/05" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/11/05" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -59,6 +59,41 @@ process where host.os.type == "windows" and event.type == "start" and "?:\\Users\\*\\AppData\\Local\\Temp\\BNZ.*.rdp", "C:\\Users\\*\\AppData\\Local\\Microsoft\\Windows\\INetCache\\Content.Outlook\\*.rdp") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Desktop File Opened from Suspicious Path + +Remote Desktop Protocol (RDP) allows users to connect to and control a computer remotely, facilitating remote work and administration. However, adversaries can exploit RDP files, which store connection settings, to gain unauthorized access. They may distribute malicious RDP files via phishing, placing them in suspicious directories. The detection rule identifies when RDP files are opened from unusual paths, signaling potential misuse and enabling analysts to investigate further. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of "mstsc.exe" and verify the suspicious path from which the RDP file was opened, as specified in the query. +- Check the user account associated with the process to determine if the activity aligns with their typical behavior or if it appears anomalous. +- Investigate the source of the RDP file by examining recent email activity or downloads to identify potential phishing attempts or unauthorized file transfers. +- Analyze the system's event logs for any other unusual activities or processes that occurred around the same time as the RDP file execution. +- Assess the network connections established by the system during the time of the alert to identify any suspicious or unauthorized remote connections. +- Consult threat intelligence sources to determine if the identified path or file name pattern is associated with known malicious campaigns or threat actors. + +### False positive analysis + +- Users frequently download legitimate RDP files from trusted sources like corporate emails or internal portals. To manage this, create exceptions for known safe domains or email addresses in your security tools. +- Temporary directories often store RDP files during legitimate software installations or updates. Monitor these activities and whitelist specific processes or software that are known to use RDP files during their operations. +- Employees working remotely may use RDP files stored in their Downloads folder for legitimate access to company resources. Implement a policy to educate users on safe RDP file handling and consider excluding the Downloads folder from alerts if it is a common practice. +- Some business applications may generate RDP files in temporary directories as part of their normal operation. Identify these applications and configure your detection systems to exclude their specific file paths or process names. +- Automated scripts or IT management tools might use RDP files for routine administrative tasks. Document these scripts and tools, and adjust your detection rules to ignore their specific activities. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any active RDP sessions initiated from the suspicious paths identified in the alert to cut off potential attacker access. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious files or software. +- Review and remove any unauthorized RDP files from the suspicious directories listed in the detection query to prevent future misuse. +- Reset credentials for any accounts that were used to open the suspicious RDP files, ensuring that new passwords are strong and unique. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Implement enhanced monitoring and logging for RDP activities across the network to detect and respond to similar threats more effectively in the future.""" [[rule.threat]] diff --git a/rules/windows/initial_access_scripts_process_started_via_wmi.toml b/rules/windows/initial_access_scripts_process_started_via_wmi.toml index 23c41341535..f195d33108e 100644 --- a/rules/windows/initial_access_scripts_process_started_via_wmi.toml +++ b/rules/windows/initial_access_scripts_process_started_via_wmi.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/27" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -69,6 +69,40 @@ sequence by host.id with maxspan = 5s ) ] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Windows Script Interpreter Executing Process via WMI + +Windows Management Instrumentation (WMI) is a powerful Windows feature that allows for system management and automation. Adversaries exploit WMI to execute scripts or processes stealthily, often using script interpreters like cscript.exe or wscript.exe. The detection rule identifies suspicious activity by monitoring for these interpreters executing processes via WMI, especially when initiated by non-system accounts, indicating potential malicious intent. + +### Possible investigation steps + +- Review the alert details to identify the specific script interpreter (cscript.exe or wscript.exe) and the process it executed. Check the process name and executable path for any anomalies or known malicious indicators. +- Examine the user account associated with the process execution. Verify if the user domain is not "NT AUTHORITY" and assess whether the account is expected to perform such actions. Investigate any unusual or unauthorized account activity. +- Investigate the parent process wmiprvse.exe to determine how it was initiated. Look for any preceding suspicious activities or processes that might have triggered the WMI execution. +- Check the system for any additional indicators of compromise, such as unexpected network connections, changes in system configurations, or other alerts related to the same host or user. +- Correlate the event with other security logs and alerts to identify any patterns or related incidents that might indicate a broader attack campaign or persistent threat. + +### False positive analysis + +- Legitimate administrative scripts or automation tasks may trigger this rule if they use cscript.exe or wscript.exe via WMI. To handle this, identify and document these scripts, then create exceptions for their specific execution paths or user accounts. +- Software installations or updates that utilize script interpreters through WMI can be mistaken for malicious activity. Monitor and whitelist known installation processes or update mechanisms that are frequently used in your environment. +- Custom applications or internal tools that rely on WMI for process execution might be flagged. Review these applications and exclude their specific process names or executable paths from the rule. +- Scheduled tasks or system maintenance scripts executed by non-system accounts could generate alerts. Verify these tasks and exclude them by specifying the user accounts or domains that are authorized to perform such actions. +- Security tools or monitoring solutions that leverage WMI for legitimate purposes may also be detected. Identify these tools and add them to the exception list based on their process names or executable locations. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified in the alert, such as cscript.exe or wscript.exe, that are running under non-system accounts. +- Conduct a thorough review of the affected host's scheduled tasks, startup items, and services to identify and remove any persistence mechanisms. +- Analyze the parent process wmiprvse.exe and its command-line arguments to understand the scope of the attack and identify any additional compromised systems. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger campaign. +- Implement additional monitoring and alerting for similar activities across the network, focusing on WMI-based script execution and non-standard process launches. +- Review and update endpoint protection policies to block or alert on the execution of high-risk processes like those listed in the detection query, especially when initiated by non-system accounts.""" [[rule.threat]] diff --git a/rules/windows/initial_access_suspicious_ms_exchange_process.toml b/rules/windows/initial_access_suspicious_ms_exchange_process.toml index cfc6a035f4e..1a9f7b3e2a8 100644 --- a/rules/windows/initial_access_suspicious_ms_exchange_process.toml +++ b/rules/windows/initial_access_suspicious_ms_exchange_process.toml @@ -2,7 +2,7 @@ creation_date = "2021/03/04" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2024/10/31" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -82,6 +82,41 @@ process where host.os.type == "windows" and event.type == "start" and "\\Device\\HarddiskVolume?\\Exchange Server\\V15\\Bin\\UMWorkerProcess.exe" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft Exchange Server UM Spawning Suspicious Processes + +Microsoft Exchange Server's Unified Messaging (UM) integrates voice messaging with email, allowing users to access voicemails via their inbox. Adversaries exploit vulnerabilities like CVE-2021-26857 to execute unauthorized processes, potentially leading to system compromise. The detection rule identifies unusual processes initiated by UM services, excluding known legitimate executables, to flag potential exploitation attempts. + +### Possible investigation steps + +- Review the alert details to confirm the process parent name is either "UMService.exe" or "UMWorkerProcess.exe" and verify the process executable path is not among the known legitimate paths listed in the exclusion criteria. +- Gather additional context by checking the process command line arguments and the user account under which the suspicious process was executed to identify any anomalies or unauthorized access. +- Investigate the historical activity of the host by reviewing recent logs for any other unusual or unauthorized processes, especially those related to the Microsoft Exchange Server. +- Check for any recent patches or updates applied to the Microsoft Exchange Server to ensure that vulnerabilities like CVE-2021-26857 have been addressed. +- Correlate the alert with other security tools and data sources such as Microsoft Defender for Endpoint or Sysmon to identify any related suspicious activities or indicators of compromise. +- Assess the network activity from the host to detect any potential lateral movement or data exfiltration attempts that might be associated with the suspicious process. + +### False positive analysis + +- Legitimate UM service updates or patches may trigger the rule. Regularly update the list of known legitimate executables to include new or updated UM service files. +- Custom scripts or monitoring tools that interact with UM services might be flagged. Identify these scripts and add their executables to the exclusion list if they are verified as safe. +- Non-standard installation paths for Exchange Server can cause false positives. Ensure that all legitimate installation paths are included in the exclusion list to prevent unnecessary alerts. +- Administrative tasks performed by IT staff using command-line tools may be misidentified. Document these tasks and consider excluding the associated executables if they are part of routine maintenance. +- Third-party integrations with Exchange Server that spawn processes could be flagged. Verify these integrations and exclude their executables if they are deemed secure and necessary for business operations. + +### Response and remediation + +- Isolate the affected Microsoft Exchange Server from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified as being spawned by the UM service that are not part of the known legitimate executables list. +- Apply the latest security patches and updates to the Microsoft Exchange Server to address CVE-2021-26857 and any other known vulnerabilities. +- Conduct a thorough review of the server's security logs and network traffic to identify any additional indicators of compromise or unauthorized access attempts. +- Restore the server from a known good backup taken before the suspicious activity was detected, ensuring that the backup is free from compromise. +- Implement enhanced monitoring and alerting for any future suspicious processes spawned by the UM service, using the detection rule as a baseline. +- Escalate the incident to the organization's security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be affected.""" [[rule.threat]] diff --git a/rules/windows/initial_access_suspicious_ms_exchange_worker_child_process.toml b/rules/windows/initial_access_suspicious_ms_exchange_worker_child_process.toml index 24a7a35c94a..7f6d60614bf 100644 --- a/rules/windows/initial_access_suspicious_ms_exchange_worker_child_process.toml +++ b/rules/windows/initial_access_suspicious_ms_exchange_worker_child_process.toml @@ -2,7 +2,7 @@ creation_date = "2021/03/08" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -46,6 +46,42 @@ process where host.os.type == "windows" and event.type == "start" and (process.name : ("cmd.exe", "powershell.exe", "pwsh.exe", "powershell_ise.exe") or ?process.pe.original_file_name in ("cmd.exe", "powershell.exe", "pwsh.dll", "powershell_ise.exe")) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft Exchange Worker Spawning Suspicious Processes + +Microsoft Exchange Server uses the worker process (w3wp.exe) to handle web requests, often running under specific application pools. Adversaries exploit this by executing malicious scripts or commands, potentially via web shells, to gain unauthorized access or execute arbitrary code. The detection rule identifies unusual child processes like command-line interpreters spawned by w3wp.exe, signaling possible exploitation or backdoor activity. + +### Possible investigation steps + +- Review the alert details to confirm the parent process is w3wp.exe and check if the process arguments include "MSExchange*AppPool" to ensure the alert is relevant to Microsoft Exchange. +- Examine the child process details, focusing on the process names and original file names such as cmd.exe, powershell.exe, pwsh.exe, and powershell_ise.exe, to identify any unauthorized or unexpected command-line activity. +- Investigate the timeline of events leading up to the alert, including any preceding or subsequent processes, to understand the context and potential impact of the suspicious activity. +- Check for any associated network activity or connections initiated by the suspicious processes to identify potential data exfiltration or communication with external command and control servers. +- Review recent changes or access logs on the affected Exchange server to identify any unauthorized access attempts or modifications that could indicate exploitation or the presence of a web shell. +- Correlate the alert with other security events or logs from data sources like Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender for Endpoint, or SentinelOne to gather additional context and corroborate findings. +- Assess the risk and impact of the detected activity, considering the severity and risk score, and determine appropriate response actions, such as isolating the affected system or conducting a deeper forensic analysis. + +### False positive analysis + +- Routine administrative tasks may trigger the rule if administrators use command-line tools like cmd.exe or powershell.exe for legitimate maintenance. To manage this, create exceptions for known administrative accounts or specific IP addresses that regularly perform these tasks. +- Scheduled tasks or scripts that run under the MSExchangeAppPool context might spawn command-line interpreters as part of their normal operation. Identify these tasks and exclude them by specifying their unique process arguments or command lines. +- Monitoring or backup software that interacts with Exchange Server could inadvertently trigger the rule. Review the software's documentation to confirm its behavior and exclude its processes by name or hash if they are verified as safe. +- Custom applications or integrations that interact with Exchange Server and use command-line tools for automation may also cause false positives. Work with application developers to understand these interactions and exclude them based on process names or specific command-line patterns. +- If a known security tool or script is used to test Exchange Server's security posture, it might mimic suspicious behavior. Document these tools and exclude their processes during scheduled testing periods to avoid false alerts. + +### Response and remediation + +- Immediately isolate the affected Microsoft Exchange Server from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified as being spawned by w3wp.exe, such as cmd.exe or powershell.exe, to halt any ongoing malicious activity. +- Conduct a thorough review of the server's application pools and web directories to identify and remove any unauthorized web shells or scripts. +- Restore the server from a known good backup taken before the suspicious activity was detected to ensure system integrity. +- Apply the latest security patches and updates to the Microsoft Exchange Server to mitigate known vulnerabilities and prevent exploitation. +- Monitor network traffic and server logs for any signs of continued or attempted exploitation, focusing on unusual outbound connections or repeated access attempts. +- 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.""" [[rule.threat]] diff --git a/rules/windows/initial_access_via_explorer_suspicious_child_parent_args.toml b/rules/windows/initial_access_via_explorer_suspicious_child_parent_args.toml index 3f33d06e360..2a5918ab9dc 100644 --- a/rules/windows/initial_access_via_explorer_suspicious_child_parent_args.toml +++ b/rules/windows/initial_access_via_explorer_suspicious_child_parent_args.toml @@ -2,7 +2,7 @@ creation_date = "2020/10/29" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -51,6 +51,41 @@ process where host.os.type == "windows" and event.type == "start" and "/factory,{ceff45ee-c862-41de-aee2-a022c81eda92}" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Explorer Child Process + +Windows Explorer, a core component of the Windows OS, manages file and folder navigation. Adversaries exploit its trusted status to launch malicious scripts or executables, often using DCOM to start processes like PowerShell or cmd.exe. The detection rule identifies such anomalies by monitoring child processes of Explorer with specific characteristics, excluding known benign activities, to flag potential threats. + +### Possible investigation steps + +- Review the process details to confirm the suspicious child process was indeed started by explorer.exe with the specific parent arguments indicating DCOM usage, such as "-Embedding". +- Check the process command line arguments and execution context to identify any potentially malicious scripts or commands being executed by the child process. +- Investigate the parent process explorer.exe to determine if it was started by a legitimate user action or if there are signs of compromise, such as unusual user activity or recent phishing attempts. +- Correlate the event with other security logs or alerts from data sources like Microsoft Defender for Endpoint or Sysmon to identify any related suspicious activities or patterns. +- Examine the network activity associated with the suspicious process to detect any unauthorized data exfiltration or communication with known malicious IP addresses. +- Assess the system for any additional indicators of compromise, such as unexpected changes in system files or registry keys, which might suggest a broader attack. + +### False positive analysis + +- Legitimate software installations or updates may trigger the rule when they use scripts or executables like PowerShell or cmd.exe. Users can create exceptions for known software update processes by identifying their specific command-line arguments or parent process details. +- System administrators often use scripts for maintenance tasks that might be flagged by this rule. To prevent false positives, administrators should document and exclude these routine scripts by specifying their unique process arguments or execution times. +- Some enterprise applications may use DCOM to launch processes for legitimate purposes. Users should identify these applications and exclude their specific process signatures or parent-child process relationships from the rule. +- Automated testing environments might execute scripts or commands that resemble suspicious activity. Users can mitigate false positives by excluding processes that are part of known testing frameworks or environments. +- Certain security tools or monitoring software may use similar techniques to gather system information. Users should verify and exclude these tools by confirming their process names and execution patterns. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity. +- Terminate the suspicious child process identified in the alert, such as cscript.exe, wscript.exe, powershell.exe, rundll32.exe, cmd.exe, mshta.exe, or regsvr32.exe, to stop any ongoing malicious actions. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes. +- Review and analyze the parent process explorer.exe and its command-line arguments to understand how the malicious process was initiated and to identify any potential persistence mechanisms. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign. +- Implement additional monitoring and alerting for similar suspicious activities involving explorer.exe to enhance detection capabilities and prevent recurrence. +- Review and update endpoint security policies to restrict the execution of potentially malicious scripts or executables from explorer.exe, especially when initiated via DCOM.""" [[rule.threat]] diff --git a/rules/windows/initial_access_webshell_screenconnect_server.toml b/rules/windows/initial_access_webshell_screenconnect_server.toml index c00dfc3018e..05073737ac9 100644 --- a/rules/windows/initial_access_webshell_screenconnect_server.toml +++ b/rules/windows/initial_access_webshell_screenconnect_server.toml @@ -2,7 +2,7 @@ creation_date = "2024/03/26" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2024/11/02" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -54,6 +54,41 @@ process where host.os.type == "windows" and event.type == "start" and (process.name : ("cmd.exe", "powershell.exe", "pwsh.exe", "powershell_ise.exe", "csc.exe") or ?process.pe.original_file_name in ("cmd.exe", "powershell.exe", "pwsh.dll", "powershell_ise.exe")) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 ScreenConnect Server Spawning Suspicious Processes + +ScreenConnect, a remote support tool, allows administrators to control systems remotely. Adversaries may exploit this by executing unauthorized commands or scripts, potentially using it as a backdoor. The detection rule identifies unusual child processes like command shells spawned by the ScreenConnect service, signaling possible exploitation or web shell activity, thus aiding in early threat detection. + +### Possible investigation steps + +- Review the alert details to confirm the parent process is ScreenConnect.Service.exe and identify the suspicious child process name, such as cmd.exe or powershell.exe. +- Check the timestamp of the process start event to determine when the suspicious activity occurred and correlate it with any other unusual activities or alerts around the same time. +- Investigate the user account associated with the process to determine if it is a legitimate user or potentially compromised. +- Examine the command line arguments of the spawned process to identify any malicious or unauthorized commands being executed. +- Review network logs for any unusual outbound connections initiated by the ScreenConnect service or the suspicious child process, which may indicate data exfiltration or communication with a command and control server. +- Analyze the system for any additional indicators of compromise, such as unexpected file modifications or the presence of web shells, to assess the extent of the potential breach. + +### False positive analysis + +- Legitimate administrative tasks using command shells or scripting tools like cmd.exe or powershell.exe may trigger the rule. To manage this, create exceptions for known administrative scripts or tasks that are regularly executed by trusted users. +- Automated maintenance scripts that utilize ScreenConnect for legitimate purposes can be mistaken for suspicious activity. Identify these scripts and whitelist their execution paths or specific process names to prevent false alerts. +- Software updates or installations that require command line execution through ScreenConnect might be flagged. Document these processes and exclude them from the rule by specifying the associated process names or hashes. +- Security tools or monitoring solutions that interact with ScreenConnect for legitimate scanning or logging purposes may inadvertently trigger the rule. Verify these tools and add them to an exception list based on their process identifiers or parent-child process relationships. +- Training or demonstration sessions using ScreenConnect to showcase command line features could be misinterpreted as threats. Schedule these sessions and temporarily adjust the rule sensitivity or disable it during the known timeframes to avoid false positives. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified as being spawned by ScreenConnect.Service.exe, such as cmd.exe or powershell.exe, to halt any ongoing malicious activity. +- Conduct a thorough review of recent ScreenConnect session logs to identify unauthorized access or unusual activity patterns, and revoke any compromised credentials. +- Scan the affected system for additional indicators of compromise, such as web shells or other malware, using endpoint detection and response tools. +- Apply security patches and updates to the ScreenConnect server and any other vulnerable applications to mitigate exploitation risks. +- Restore the system from a known good backup if evidence of compromise is confirmed, ensuring that the backup is free from malicious artifacts. +- Report the incident to the appropriate internal security team or external authorities if required, providing them with detailed findings and evidence for further investigation.""" [[rule.threat]] diff --git a/rules/windows/initial_access_xsl_script_execution_via_com.toml b/rules/windows/initial_access_xsl_script_execution_via_com.toml index 4b35a4ed939..f145ce6612a 100644 --- a/rules/windows/initial_access_xsl_script_execution_via_com.toml +++ b/rules/windows/initial_access_xsl_script_execution_via_com.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/27" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -42,6 +42,41 @@ sequence with maxspan=1m "?:\\Program Files\\*.exe", "?:\\Program Files (x86)\\*exe")] by process.parent.entity_id ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 XSL Script Execution via COM + +The Microsoft.XMLDOM COM interface allows applications to parse and transform XML documents using XSL scripts. Adversaries exploit this by embedding malicious scripts in Office documents, triggering execution via Office processes like Word or Excel. The detection rule identifies suspicious activity by monitoring for the loading of specific DLLs and the execution of unexpected child processes, indicating potential script execution attempts. + +### Possible investigation steps + +- Review the alert details to identify the specific Office process (e.g., winword.exe, excel.exe) that triggered the alert and note the process entity ID for further investigation. +- Check the process tree to identify any unexpected child processes spawned by the Office application, focusing on those not matching typical system executables like WerFault.exe or conhost.exe. +- Investigate the loaded DLLs, specifically msxml3.dll, to confirm its legitimate use and check for any anomalies or unusual patterns in its loading sequence. +- Analyze the parent and child process relationships to determine if the execution flow aligns with typical user activity or if it suggests malicious behavior. +- Gather additional context by reviewing recent user activity and document interactions to identify any potential phishing attempts or suspicious document handling that could have led to the alert. +- Correlate the findings with other security events or alerts in the environment to assess if this activity is part of a broader attack pattern or isolated incident. + +### False positive analysis + +- Legitimate use of Microsoft Office applications for XML processing can trigger the rule. Users should identify and whitelist known applications or scripts that regularly perform XML transformations using the Microsoft.XMLDOM COM interface. +- Automated document processing systems that utilize Office applications to handle XML data might cause false positives. Exclude these systems by specifying their process names or executable paths in the detection rule. +- Software updates or installations that involve Office applications may load the msxml3.dll and start child processes. Temporarily disable the rule during scheduled maintenance or update windows to prevent false alerts. +- Custom Office add-ins or macros that interact with XML files could be misidentified as threats. Review and approve these add-ins, then adjust the rule to exclude their specific behaviors. +- Regular business processes that involve document conversion or data extraction using Office tools might be flagged. Document these processes and create exceptions based on their unique characteristics, such as specific file paths or process names. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further spread of the malicious script execution. +- Terminate any suspicious processes identified as child processes of Office applications, such as winword.exe or excel.exe, that are not part of the standard executable paths. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious scripts or files. +- Review and restore any altered or deleted files from secure backups to ensure data integrity and system functionality. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement application whitelisting to restrict the execution of unauthorized scripts and executables, particularly those not located in standard directories. +- Enhance monitoring and alerting for similar activities by ensuring that the detection rule is actively deployed and that alerts are configured to notify the appropriate personnel promptly.""" [[rule.threat]] diff --git a/rules/windows/lateral_movement_alternate_creds_pth.toml b/rules/windows/lateral_movement_alternate_creds_pth.toml index b8afff146d2..d3b22ba5c4f 100644 --- a/rules/windows/lateral_movement_alternate_creds_pth.toml +++ b/rules/windows/lateral_movement_alternate_creds_pth.toml @@ -2,7 +2,7 @@ creation_date = "2023/03/29" integration = ["windows", "system"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -32,6 +32,41 @@ event.category : "authentication" and event.action : "logged-in" and winlog.logon.type : "NewCredentials" and event.outcome : "success" and user.id : (S-1-5-21-* or S-1-12-1-*) and winlog.event_data.LogonProcessName : "seclogo" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Pass-the-Hash (PtH) Attempt + +Pass-the-Hash (PtH) is a technique where attackers use stolen password hashes to authenticate and move laterally across systems without needing plaintext passwords. This method exploits the authentication process in Windows environments. The detection rule identifies suspicious logins using specific logon types and processes, indicating potential PtH activity, by monitoring successful authentications with certain user IDs and logon processes. + +### Possible investigation steps + +- Review the event logs for the specific user IDs (S-1-5-21-* or S-1-12-1-*) to identify any unusual or unauthorized access patterns, focusing on the time and source of the logon events. +- Examine the winlog.event_data.LogonProcessName field for "seclogo" to determine if this process is commonly used in your environment or if it appears suspicious or unexpected. +- Correlate the successful authentication events with other security logs to identify any lateral movement or access to sensitive systems that occurred after the initial logon. +- Investigate the source IP addresses and hostnames associated with the logon events to determine if they are known and trusted within the network or if they originate from unusual or external locations. +- Check for any recent changes or anomalies in the accounts associated with the suspicious user IDs, such as password resets, privilege escalations, or unusual account activity. +- Consult threat intelligence sources to see if there are any known campaigns or threat actors using similar techniques or targeting similar environments. + +### False positive analysis + +- Legitimate administrative tools or scripts that use the "NewCredentials" logon type for automation or scheduled tasks can trigger false positives. Review and whitelist known benign processes or scripts that are part of regular operations. +- Security software or monitoring tools that perform regular checks using the "seclogo" logon process may be misidentified. Identify and exclude these tools from the detection rule to prevent unnecessary alerts. +- Service accounts with user IDs matching the specified patterns (S-1-5-21-* or S-1-12-1-*) might be flagged during routine operations. Ensure these accounts are documented and create exceptions for their expected activities. +- Regularly scheduled tasks or maintenance activities that involve authentication processes similar to PtH can cause false positives. Document these activities and adjust the detection rule to account for their occurrence. +- User behavior analytics might incorrectly flag normal user activities as suspicious. Implement user behavior baselining to differentiate between typical and atypical logon patterns, refining the detection criteria accordingly. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further lateral movement by the attacker. +- Revoke any active sessions associated with the compromised user IDs (S-1-5-21-* or S-1-12-1-*) to disrupt the attacker's access. +- Conduct a password reset for the affected accounts and any other accounts that may have been accessed using the compromised hashes. +- Review and update access controls and permissions for the affected accounts to ensure they adhere to the principle of least privilege. +- Deploy endpoint detection and response (EDR) tools to monitor for any further suspicious activity or attempts to use stolen hashes. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach. +- Implement additional logging and monitoring for the "seclogo" logon process to enhance detection of future pass-the-hash attempts.""" [[rule.threat]] diff --git a/rules/windows/lateral_movement_cmd_service.toml b/rules/windows/lateral_movement_cmd_service.toml index 6bc844d0c45..8cb0dca8327 100644 --- a/rules/windows/lateral_movement_cmd_service.toml +++ b/rules/windows/lateral_movement_cmd_service.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/02" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -43,6 +43,40 @@ sequence by process.entity_id with maxspan = 1m process.args : ("create", "config", "failure", "start")] [network where host.os.type == "windows" and process.name : "sc.exe" and destination.ip != "127.0.0.1"] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Service Command Lateral Movement + +The Service Control Manager in Windows allows for the management of services, which are crucial for system operations. Adversaries exploit this by using `sc.exe` to manipulate services on remote systems, facilitating lateral movement. The detection rule identifies suspicious `sc.exe` usage by monitoring for service-related commands targeting remote hosts, which may indicate unauthorized access attempts. This rule helps differentiate between legitimate administrative actions and potential threats. + +### Possible investigation steps + +- Review the process details to confirm the use of sc.exe, focusing on the process.entity_id and process.args fields to understand the specific service-related actions attempted. +- Examine the network activity associated with the sc.exe process, particularly the destination.ip field, to identify the remote host targeted by the command and assess if it is a legitimate administrative target. +- Check the event logs on the remote host for any corresponding service creation, modification, or start events to verify if the actions were successfully executed and to gather additional context. +- Investigate the user account associated with the sc.exe process to determine if it has the necessary permissions for such actions and if the account usage aligns with expected behavior. +- Correlate the alert with other recent alerts or logs involving the same process.entity_id or destination.ip to identify any patterns or additional suspicious activities that may indicate a broader attack campaign. + +### False positive analysis + +- Routine administrative tasks using sc.exe on remote systems can trigger false positives. Identify and document regular maintenance schedules and responsible personnel to differentiate these from potential threats. +- Automated scripts or management tools that use sc.exe for legitimate service management may cause alerts. Review and whitelist these scripts or tools by their process entity IDs to reduce noise. +- Internal IT operations often involve creating or modifying services remotely. Establish a baseline of normal activity patterns and exclude these from alerts by setting exceptions for known IP addresses or user accounts. +- Software deployment processes that involve service configuration changes can be mistaken for lateral movement. Coordinate with software deployment teams to understand their processes and exclude these activities from detection. +- Regularly review and update the exclusion list to ensure it reflects current operational practices and does not inadvertently allow malicious activity. + +### Response and remediation + +- Isolate the affected system from the network to prevent further lateral movement and unauthorized access to other systems. +- Terminate any suspicious `sc.exe` processes identified on the affected system to halt any ongoing malicious activity. +- Review and reset credentials for any accounts that were used in the suspicious `sc.exe` activity to prevent unauthorized access. +- Conduct a thorough examination of the affected system for any additional signs of compromise, such as unauthorized services or changes to existing services. +- Restore the affected system from a known good backup if any malicious modifications or persistent threats are detected. +- Implement network segmentation to limit the ability of adversaries to move laterally across the network in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/lateral_movement_dcom_hta.toml b/rules/windows/lateral_movement_dcom_hta.toml index 17625556c65..4b76978dc12 100644 --- a/rules/windows/lateral_movement_dcom_hta.toml +++ b/rules/windows/lateral_movement_dcom_hta.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/03" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -47,6 +47,41 @@ sequence with maxspan=1m source.port > 49151 and destination.port > 49151 and source.ip != "127.0.0.1" and source.ip != "::1" ] by host.id, process.entity_id ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Incoming DCOM Lateral Movement via MSHTA + +DCOM allows software components to communicate over a network, enabling remote execution of applications like MSHTA, which runs HTML applications. Adversaries exploit this by executing commands remotely, bypassing traditional security measures. The detection rule identifies suspicious MSHTA activity by monitoring process starts and network traffic, focusing on unusual port usage and remote IP addresses, indicating potential lateral movement attempts. + +### Possible investigation steps + +- Review the process start event for mshta.exe on the affected host to gather details such as the process entity ID, command-line arguments, and parent process information to understand how mshta.exe was executed. +- Analyze the network traffic associated with the mshta.exe process, focusing on the source and destination IP addresses and ports, to identify any unusual or unauthorized remote connections. +- Check the source IP address involved in the network event to determine if it is known or associated with any previous suspicious activity or if it belongs to an internal or external network. +- Investigate the timeline of events on the host to identify any preceding or subsequent suspicious activities that might indicate a broader attack pattern or lateral movement attempts. +- Correlate the findings with other security logs and alerts from the same host or network segment to identify any additional indicators of compromise or related malicious activities. +- Assess the risk and impact of the detected activity by considering the host's role within the network and any sensitive data or systems it may have access to. + +### False positive analysis + +- Legitimate administrative tasks using MSHTA for remote management can trigger the rule. Identify and document these tasks, then create exceptions for known administrative IP addresses or specific user accounts. +- Automated software updates or deployments that utilize MSHTA may appear as suspicious activity. Monitor and whitelist the IP addresses and ports associated with these updates to prevent false positives. +- Internal network scanning tools or security assessments might mimic lateral movement behavior. Coordinate with IT and security teams to recognize these activities and exclude them from triggering alerts. +- Custom applications that leverage MSHTA for inter-process communication could be flagged. Review these applications and exclude their known processes or network patterns from the detection rule. +- Remote desktop or support tools that use MSHTA for legitimate purposes should be identified. Whitelist these tools by their process names or associated network traffic to reduce unnecessary alerts. + +### Response and remediation + +- Isolate the affected host immediately from the network to prevent further lateral movement and potential data exfiltration. +- Terminate the mshta.exe process on the affected host to stop any ongoing malicious activity. +- Conduct a thorough examination of the affected host to identify any additional malicious files or processes, focusing on those initiated around the time of the alert. +- Reset credentials for any accounts that were active on the affected host during the time of the alert to prevent unauthorized access. +- Review and restrict DCOM permissions and configurations on the affected host and other critical systems to limit the potential for similar attacks. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems have been compromised. +- Update detection mechanisms and threat intelligence feeds to enhance monitoring for similar DCOM-based lateral movement attempts in the future.""" [[rule.threat]] diff --git a/rules/windows/lateral_movement_dcom_mmc20.toml b/rules/windows/lateral_movement_dcom_mmc20.toml index fd2ad45bc02..1bd081e4ee4 100644 --- a/rules/windows/lateral_movement_dcom_mmc20.toml +++ b/rules/windows/lateral_movement_dcom_mmc20.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/06" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -47,6 +47,40 @@ sequence by host.id with maxspan=1m [process where host.os.type == "windows" and event.type == "start" and process.parent.name : "mmc.exe" ] by process.parent.entity_id ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Incoming DCOM Lateral Movement with MMC + +Distributed Component Object Model (DCOM) enables software components to communicate over a network, often used in Windows environments for remote management. Adversaries exploit DCOM to execute commands remotely, leveraging applications like MMC20 to move laterally. The detection rule identifies suspicious activity by monitoring network traffic and process creation patterns, flagging potential misuse when MMC initiates remote commands, indicating possible lateral movement or defense evasion tactics. + +### Possible investigation steps + +- Review the network traffic logs to identify the source IP address that initiated the connection to the host running mmc.exe. Verify if this IP address is known and expected within the network environment. +- Examine the process creation logs to confirm the parent-child relationship between mmc.exe and any suspicious processes. Investigate the child processes for any unusual or unauthorized activities. +- Check the source and destination ports (both should be >= 49152) involved in the network connection to determine if they align with typical application behavior or if they are indicative of potential misuse. +- Investigate the timeline of events to see if there are any other related alerts or activities on the same host or originating from the same source IP address, which could provide additional context or indicate a broader attack pattern. +- Correlate the findings with any existing threat intelligence or known attack patterns related to DCOM abuse and lateral movement to assess the potential risk and impact on the organization. + +### False positive analysis + +- Legitimate administrative tasks using MMC may trigger the rule. Regularly review and document routine administrative activities to differentiate them from suspicious behavior. +- Automated scripts or management tools that use MMC for remote management can cause false positives. Identify and whitelist these tools by their process and network patterns. +- Internal network scanning or monitoring tools might mimic the behavior detected by the rule. Exclude known IP addresses or ranges associated with these tools to reduce noise. +- Scheduled tasks or maintenance operations that involve MMC could be misinterpreted as lateral movement. Ensure these tasks are logged and recognized as part of normal operations. +- Software updates or patches that require MMC to execute remote commands might trigger alerts. Maintain an updated list of such activities and exclude them from triggering the rule. + +### Response and remediation + +- Isolate the affected host immediately from the network to prevent further lateral movement and contain the threat. +- Terminate any suspicious processes associated with mmc.exe on the affected host to stop any ongoing malicious activity. +- Conduct a thorough review of the affected host's event logs and network traffic to identify any additional indicators of compromise or other affected systems. +- Reset credentials for any accounts that were accessed or potentially compromised during the incident to prevent unauthorized access. +- Apply patches and updates to the affected systems and any other vulnerable systems in the network to mitigate known vulnerabilities that could be exploited. +- Implement network segmentation to limit the ability of threats to move laterally within the network in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional actions are necessary.""" [[rule.threat]] diff --git a/rules/windows/lateral_movement_dcom_shellwindow_shellbrowserwindow.toml b/rules/windows/lateral_movement_dcom_shellwindow_shellbrowserwindow.toml index 0ae4173fb6c..5648650c87e 100644 --- a/rules/windows/lateral_movement_dcom_shellwindow_shellbrowserwindow.toml +++ b/rules/windows/lateral_movement_dcom_shellwindow_shellbrowserwindow.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/06" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -47,6 +47,41 @@ sequence by host.id with maxspan=5s process.parent.name : "explorer.exe" ] by process.parent.entity_id ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Incoming DCOM Lateral Movement with ShellBrowserWindow or ShellWindows + +DCOM enables software components to communicate over a network, often used in Windows environments for legitimate inter-process communication. Adversaries exploit DCOM, particularly ShellBrowserWindow or ShellWindows, to execute commands remotely, facilitating stealthy lateral movement. The detection rule identifies suspicious network activity and process creation patterns, such as incoming TCP connections to high ports and explorer.exe spawning processes, which may indicate DCOM abuse. + +### Possible investigation steps + +- Review the network activity to identify the source IP address of the incoming TCP connection. Verify if the source IP is known or expected within the network environment. +- Examine the process tree for explorer.exe to identify any unusual or unexpected child processes that were spawned. Investigate these processes for any signs of malicious activity. +- Check the destination port and source port numbers to determine if they are commonly used for legitimate services or if they are unusual for the environment. +- Correlate the event with other security logs or alerts to identify any additional suspicious activities or patterns associated with the same source IP or process entity. +- Investigate the user account associated with the explorer.exe process to determine if there are any signs of compromise or unauthorized access. +- Review historical data for any previous occurrences of similar network connections or process creations to identify potential patterns or repeated attempts. + +### False positive analysis + +- Legitimate software updates or installations may trigger the rule due to the use of DCOM for remote management tasks. Users can create exceptions for known update processes by identifying their specific network and process patterns. +- Internal IT management tools that utilize DCOM for remote administration might cause false positives. Review and whitelist these tools by confirming their source IP addresses and process behaviors. +- Automated scripts or scheduled tasks that leverage DCOM for legitimate purposes can be mistaken for lateral movement. Document and exclude these tasks by correlating their execution times and process chains. +- Network scanning or monitoring tools that generate high-port TCP connections could be misinterpreted as suspicious activity. Validate and exclude these tools by cross-referencing their network traffic with known benign sources. +- User-initiated remote desktop sessions or file transfers using DCOM may appear as lateral movement. Verify and exclude these activities by checking user authentication logs and session details. + +### Response and remediation + +- Isolate the affected host immediately from the network to prevent further lateral movement and potential data exfiltration. +- Terminate any suspicious processes spawned by explorer.exe that are not part of normal operations, focusing on those initiated through high TCP ports. +- Conduct a thorough review of recent network connections and process creation logs on the affected host to identify any additional compromised systems or lateral movement attempts. +- Reset credentials for any accounts that were active on the affected host during the time of the alert to prevent unauthorized access. +- Apply patches and updates to the affected systems to address any vulnerabilities that may have been exploited during the attack. +- Enhance monitoring and logging on the network to detect similar DCOM abuse attempts, ensuring that alerts are configured for high TCP port activity and unusual process spawning by explorer.exe. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional containment or remediation actions are necessary.""" [[rule.threat]] diff --git a/rules/windows/lateral_movement_defense_evasion_lanman_nullsessionpipe_modification.toml b/rules/windows/lateral_movement_defense_evasion_lanman_nullsessionpipe_modification.toml index 74e5284a1ad..3f1af9489dd 100644 --- a/rules/windows/lateral_movement_defense_evasion_lanman_nullsessionpipe_modification.toml +++ b/rules/windows/lateral_movement_defense_evasion_lanman_nullsessionpipe_modification.toml @@ -2,7 +2,7 @@ creation_date = "2021/03/22" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -48,6 +48,40 @@ registry.path : ( ) and length(registry.data.strings) > 0 and not registry.data.strings : "(empty)" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 NullSessionPipe Registry Modification + +The NullSessionPipe registry setting in Windows defines which named pipes can be accessed without authentication, facilitating anonymous connections. Adversaries may exploit this by modifying the registry to enable lateral movement, allowing unauthorized access to network resources. The detection rule monitors changes to this registry path, flagging modifications that introduce new accessible pipes, which could indicate malicious intent. + +### Possible investigation steps + +- Review the registry event details to confirm the specific named pipes added or modified in the NullSessionPipes registry path. Focus on the registry.data.strings field to identify any new or suspicious entries. +- Correlate the timestamp of the registry change event with other security events or logs from the same host to identify any concurrent suspicious activities, such as unusual network connections or process executions. +- Investigate the user account or process responsible for the registry modification by examining the event data for user context or process identifiers. This can help determine if the change was made by an unauthorized user or malicious process. +- Check for any recent alerts or logs related to lateral movement or unauthorized access attempts on the network, focusing on the host where the registry change was detected. +- Assess the risk and impact of the modified named pipes by determining if they are commonly used in legitimate operations or if they are known to be exploited by malware or threat actors. + +### False positive analysis + +- Legitimate administrative tools or scripts may modify the NullSessionPipe registry setting as part of routine network management. Review the source of the change and verify if it aligns with known administrative activities. +- Some network services or applications might require anonymous access to specific pipes for functionality. Identify these services and document them to differentiate between expected and unexpected modifications. +- Scheduled tasks or automated deployment scripts could alter the registry setting during updates or installations. Ensure these tasks are documented and verify their legitimacy. +- Security software or network monitoring tools might adjust the NullSessionPipe settings for scanning purposes. Confirm with your security team if such tools are in use and adjust the detection rule to exclude these known activities. +- Regularly review and update the list of known exceptions in your detection system to prevent alert fatigue and ensure focus on genuine threats. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Review the registry changes to identify any unauthorized pipes added to the NullSessionPipes registry key and remove them to restore secure configurations. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to detect and remove any malicious software that may have been introduced. +- Analyze network logs and system event logs to identify any unauthorized access attempts or successful connections made through the modified pipes, and block any suspicious IP addresses or accounts. +- Reset credentials for any accounts that may have been compromised or used in conjunction with the unauthorized access to ensure they cannot be reused by adversaries. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been affected. +- Implement enhanced monitoring and alerting for changes to the NullSessionPipes registry key and similar registry paths to detect and respond to future unauthorized modifications promptly.""" [[rule.threat]] diff --git a/rules/windows/lateral_movement_evasion_rdp_shadowing.toml b/rules/windows/lateral_movement_evasion_rdp_shadowing.toml index 1e1e22abd20..591fc4776de 100644 --- a/rules/windows/lateral_movement_evasion_rdp_shadowing.toml +++ b/rules/windows/lateral_movement_evasion_rdp_shadowing.toml @@ -2,7 +2,7 @@ creation_date = "2021/04/12" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -66,6 +66,40 @@ any where host.os.type == "windows" and ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Remote Desktop Shadowing Activity + +Remote Desktop Shadowing allows administrators to view or control active RDP sessions, aiding in support and troubleshooting. However, adversaries can exploit this feature to monitor or hijack user sessions without consent. The detection rule identifies suspicious modifications to RDP Shadow registry settings and the execution of specific processes linked to shadowing, signaling potential misuse. + +### Possible investigation steps + +- Review the registry event details to confirm if there was a modification to the RDP Shadow registry path, specifically checking for changes in "HKLM\\Software\\Policies\\Microsoft\\Windows NT\\Terminal Services\\Shadow". +- Investigate the process events to identify if "RdpSaUacHelper.exe" or "RdpSaProxy.exe" were started by "svchost.exe", which could indicate unauthorized shadowing activity. +- Check for any instances of "mstsc.exe" being executed with the "/shadow:*" argument, as this could signify an attempt to shadow an RDP session. +- Correlate the identified processes and registry changes with user activity logs to determine if the actions were authorized or expected as part of legitimate administrative tasks. +- Analyze network logs for any unusual remote connections or lateral movement patterns that coincide with the timing of the detected shadowing activity. +- Consult endpoint security solutions like Microsoft Defender for Endpoint or SentinelOne for additional context or alerts related to the same host or user account involved in the shadowing activity. + +### False positive analysis + +- Legitimate administrative activities may trigger alerts when IT staff use RDP Shadowing for support. To manage this, create exceptions for known IT administrator accounts or specific IP addresses. +- Scheduled maintenance or automated scripts that modify RDP Shadow registry settings can be mistaken for malicious activity. Identify and exclude these processes or scripts from the detection rule. +- Security software or monitoring tools that interact with RDP sessions might mimic shadowing behavior. Verify these tools and whitelist their processes to prevent false alerts. +- Training sessions or remote support tools that use RDP Shadowing features can generate alerts. Document and exclude these activities by identifying their unique process names or arguments. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified in the alert, such as RdpSaUacHelper.exe, RdpSaProxy.exe, or mstsc.exe with shadowing arguments, to stop potential session hijacking. +- Revert any unauthorized changes to the RDP Shadow registry settings to their default or secure state to prevent further exploitation. +- Conduct a thorough review of user accounts and permissions on the affected system to ensure no unauthorized changes have been made, and reset passwords for any compromised accounts. +- 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 enhanced monitoring and logging for RDP activities across the network to detect and respond to similar threats more quickly in the future. +- Review and update RDP access policies and configurations to ensure they align with best practices, such as enforcing multi-factor authentication and limiting RDP access to only necessary users and systems.""" [[rule.threat]] diff --git a/rules/windows/lateral_movement_execution_from_tsclient_mup.toml b/rules/windows/lateral_movement_execution_from_tsclient_mup.toml index d5fa197c1de..b67ca1b496d 100644 --- a/rules/windows/lateral_movement_execution_from_tsclient_mup.toml +++ b/rules/windows/lateral_movement_execution_from_tsclient_mup.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/11" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2024/10/31" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -53,6 +53,41 @@ type = "eql" query = ''' process where host.os.type == "windows" and event.type == "start" and process.executable : "\\Device\\Mup\\tsclient\\*.exe" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Execution via TSClient Mountpoint + +The TSClient mountpoint is a feature of the Remote Desktop Protocol (RDP) that allows users to access local drives from a remote session. Adversaries can exploit this by executing malicious files from the shared mountpoint, facilitating lateral movement within a network. The detection rule identifies such activities by monitoring for process executions originating from the TSClient path, signaling potential unauthorized access attempts. + +### Possible investigation steps + +- Review the alert details to confirm the process execution path matches the pattern "\\\\Device\\\\Mup\\\\tsclient\\\\*.exe" and verify the host operating system is Windows. +- Identify the user account associated with the RDP session and check for any unusual or unauthorized access patterns, such as logins from unexpected locations or at odd times. +- Examine the executed process's hash and compare it against known malicious hashes in threat intelligence databases to determine if the file is potentially harmful. +- Investigate the source system from which the RDP session originated to identify any signs of compromise or unauthorized access that could indicate lateral movement. +- Check for any additional suspicious activities on the target host, such as unexpected network connections or file modifications, that may correlate with the execution event. +- Review the security logs from data sources like Microsoft Defender for Endpoint or Sysmon for any related alerts or anomalies that could provide further context on the incident. + +### False positive analysis + +- Legitimate software updates or installations may trigger the rule if they are executed from a local drive mapped through TSClient. To manage this, create exceptions for known update processes or installation paths that are frequently used in your environment. +- IT administrative tasks performed via RDP sessions can also cause false positives. Identify and exclude specific administrative tools or scripts that are regularly executed from TSClient paths by trusted personnel. +- Automated backup or synchronization software that accesses local drives through RDP might be flagged. Review and whitelist these processes if they are part of routine operations. +- Development or testing activities involving remote execution of scripts or applications from TSClient can be mistaken for threats. Establish a list of approved development tools and paths to exclude from monitoring. +- Regularly review and update the list of exceptions to ensure that only verified and necessary exclusions are maintained, minimizing the risk of overlooking genuine threats. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further lateral movement and potential data exfiltration. +- Terminate any suspicious processes running from the TSClient path to halt any ongoing malicious activity. +- Conduct a thorough scan of the affected host using endpoint detection and response (EDR) tools to identify and remove any malicious files or artifacts. +- Review and analyze RDP logs and session details to identify unauthorized access attempts and determine the source of the intrusion. +- Reset credentials for any accounts that were accessed or potentially compromised during the incident to prevent unauthorized access. +- Implement network segmentation to limit RDP access to only necessary systems and users, reducing the attack surface for similar threats. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts.""" [[rule.threat]] diff --git a/rules/windows/lateral_movement_incoming_winrm_shell_execution.toml b/rules/windows/lateral_movement_incoming_winrm_shell_execution.toml index f3a096eded1..f9dae8c38ba 100644 --- a/rules/windows/lateral_movement_incoming_winrm_shell_execution.toml +++ b/rules/windows/lateral_movement_incoming_winrm_shell_execution.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/24" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -48,6 +48,41 @@ sequence by host.id with maxspan=30s [process where host.os.type == "windows" and event.type == "start" and process.parent.name : "winrshost.exe" and not process.executable : "?:\\Windows\\System32\\conhost.exe"] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Incoming Execution via WinRM Remote Shell + +Windows Remote Management (WinRM) is a protocol that allows for remote management and execution of commands on Windows machines. While beneficial for legitimate administrative tasks, adversaries can exploit WinRM for lateral movement by executing commands remotely. The detection rule identifies suspicious activity by monitoring network traffic on specific ports and processes initiated by WinRM, flagging potential unauthorized remote executions. + +### Possible investigation steps + +- Review the network traffic logs to confirm the presence of incoming connections on ports 5985 or 5986, which are used by WinRM, and verify if these connections are expected or authorized. +- Identify the source IP address of the incoming connection and determine if it belongs to a known and trusted network or device. Investigate any unfamiliar or suspicious IP addresses. +- Examine the process tree for the process initiated by winrshost.exe to identify any unusual or unauthorized processes that were started as a result of the remote execution. +- Check the user account associated with the WinRM session to ensure it is legitimate and has not been compromised. Look for any signs of unauthorized access or privilege escalation. +- Correlate the event with other security logs, such as authentication logs, to identify any related suspicious activities or patterns that might indicate lateral movement or a broader attack campaign. +- Investigate the timeline of events to determine if there are any other related alerts or activities occurring around the same time that could provide additional context or evidence of malicious intent. + +### False positive analysis + +- Legitimate administrative tasks using WinRM can trigger alerts. Regularly review and whitelist known administrative IP addresses or users to reduce false positives. +- Automated scripts or management tools that use WinRM for routine tasks may be flagged. Identify these scripts and create exceptions for their specific process names or execution paths. +- Monitoring tools that check system health via WinRM might be misidentified as threats. Exclude these tools by specifying their source IPs or process names in the detection rule. +- Scheduled tasks that utilize WinRM for updates or maintenance can cause alerts. Document these tasks and adjust the rule to ignore their specific execution patterns. +- Internal security scans or compliance checks using WinRM should be accounted for. Coordinate with security teams to recognize these activities and exclude them from triggering alerts. + +### Response and remediation + +- Isolate the affected host immediately from the network to prevent further lateral movement and potential data exfiltration. +- Terminate any suspicious processes associated with WinRM, particularly those not originating from legitimate administrative tools or known good sources. +- Review and revoke any unauthorized access credentials or accounts that may have been used to initiate the WinRM session. +- Conduct a thorough examination of the affected host for any additional signs of compromise, such as unauthorized software installations or changes to system configurations. +- Restore the affected system from a known good backup if any malicious activity or unauthorized changes are confirmed. +- Implement network segmentation to limit the ability of threats to move laterally across the network, focusing on restricting access to critical systems. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/lateral_movement_incoming_wmi.toml b/rules/windows/lateral_movement_incoming_wmi.toml index 0c695c6002d..cc46ebefe0b 100644 --- a/rules/windows/lateral_movement_incoming_wmi.toml +++ b/rules/windows/lateral_movement_incoming_wmi.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/15" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -59,6 +59,41 @@ sequence by host.id with maxspan = 2s not (process.executable : "?:\\Windows\\System32\\inetsrv\\appcmd.exe" and process.args : "uninstall") ] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 WMI Incoming Lateral Movement + +Windows Management Instrumentation (WMI) is a core Windows feature enabling remote management and data collection. Adversaries exploit WMI for lateral movement by executing processes on remote hosts, often bypassing traditional security measures. The detection rule identifies suspicious WMI activity by monitoring specific network connections and process executions, filtering out common false positives to highlight potential threats. + +### Possible investigation steps + +- Review the source IP address of the incoming RPC connection to determine if it is from a known or trusted network segment, excluding localhost addresses like 127.0.0.1 and ::1. +- Check the process name and parent process name, specifically looking for svchost.exe and WmiPrvSE.exe, to confirm the execution context and identify any unusual parent-child process relationships. +- Investigate the user ID associated with the process execution to ensure it is not a system account (S-1-5-18, S-1-5-19, S-1-5-20) and assess if the user has legitimate reasons for remote WMI activity. +- Examine the process executable path to verify it is not one of the excluded common false positives, such as those related to HPWBEM, SCCM, or other specified system utilities. +- Analyze the network connection details, including source and destination ports, to identify any patterns or anomalies that could indicate malicious lateral movement. +- Correlate the alert with other security events or logs from the same host or network segment to gather additional context and identify potential patterns of compromise. + +### False positive analysis + +- Administrative use of WMI for remote management can trigger alerts. To manage this, create exceptions for known administrative accounts or specific IP addresses used by IT staff. +- Security tools like Nessus and SCCM may cause false positives. Exclude processes associated with these tools by adding their executables to the exception list. +- System processes running with high integrity levels might be flagged. Exclude processes with integrity levels marked as "System" to reduce noise. +- Specific executables such as msiexec.exe and appcmd.exe with certain arguments can be safely excluded if they are part of routine administrative tasks. +- Regularly review and update the exception list to ensure it aligns with current network management practices and tools. + +### Response and remediation + +- Isolate the affected host immediately from the network to prevent further lateral movement by the adversary. This can be done by disabling network interfaces or using network segmentation tools. +- Terminate any suspicious processes identified as being executed via WMI on the affected host. Use task management tools or scripts to stop these processes. +- Conduct a thorough review of the affected host's WMI logs and process execution history to identify any unauthorized changes or additional malicious activity. +- Reset credentials for any accounts that were used in the suspicious WMI activity, especially if they have administrative privileges, to prevent further unauthorized access. +- Apply patches and updates to the affected host and any other systems that may be vulnerable to similar exploitation methods, ensuring that all security updates are current. +- Enhance monitoring and logging for WMI activity across the network to detect and respond to similar threats more quickly in the future. This includes setting up alerts for unusual WMI usage patterns. +- If the threat is confirmed to be part of a larger attack, escalate the incident to the appropriate security team or authority for further investigation and potential legal action.""" [[rule.threat]] diff --git a/rules/windows/lateral_movement_mount_hidden_or_webdav_share_net.toml b/rules/windows/lateral_movement_mount_hidden_or_webdav_share_net.toml index 9f0ca208eae..580e0199488 100644 --- a/rules/windows/lateral_movement_mount_hidden_or_webdav_share_net.toml +++ b/rules/windows/lateral_movement_mount_hidden_or_webdav_share_net.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/02" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2024/11/02" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -57,6 +57,40 @@ process where host.os.type == "windows" and event.type == "start" and /* excluding shares deletion operation */ not process.args : "/d*" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Mounting Hidden or WebDav Remote Shares + +WebDav and hidden remote shares facilitate file sharing and collaboration across networks, often used in enterprise environments. Adversaries exploit these to move laterally or exfiltrate data by mounting shares using tools like net.exe. The detection rule identifies suspicious share mounts by monitoring specific command patterns, excluding benign operations, to flag potential threats. + +### Possible investigation steps + +- Review the process details to confirm the use of net.exe or net1.exe for mounting shares, focusing on the process.name and process.pe.original_file_name fields. +- Examine the process.args field to identify the specific share being accessed, noting any patterns like "\\\\\\\\*\\\\*$*", "\\\\\\\\*@SSL\\\\*", or "http*" that indicate hidden or WebDav shares. +- Check the parent process information to determine if net1.exe was executed independently or as a child of another suspicious process, which could suggest malicious intent. +- Investigate the user account associated with the process to verify if the activity aligns with their typical behavior or if it appears anomalous. +- Correlate the event with other logs or alerts from the same host or user to identify any patterns of lateral movement or data exfiltration attempts. +- Assess the network activity around the time of the alert to detect any unusual outbound connections that might indicate data exfiltration. + +### False positive analysis + +- Legitimate use of net.exe for mounting network drives in enterprise environments can trigger false positives. Users can create exceptions for known internal IP addresses or specific user accounts frequently performing these actions. +- Automated scripts or system processes that use net.exe to connect to WebDav or hidden shares for legitimate purposes may be flagged. Identify these scripts and processes, and exclude them by their process hash or command line patterns. +- Regular operations involving OneDrive or other cloud-based services might be misidentified as suspicious. Exclude these by specifying known service URLs or domains in the detection rule. +- Administrative tasks involving network share management can be mistaken for threats. Document and exclude these tasks by correlating them with scheduled maintenance windows or specific admin user accounts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further lateral movement or data exfiltration. +- Terminate any suspicious processes related to net.exe or net1.exe that are actively mounting hidden or WebDav shares. +- Conduct a thorough review of recent file access and transfer logs to identify any unauthorized data access or exfiltration attempts. +- Change credentials for any accounts that were used in the suspicious activity to prevent further unauthorized access. +- Implement network segmentation to limit access to critical systems and sensitive data, reducing the risk of lateral movement. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Enhance monitoring and alerting for similar activities by ensuring that all relevant security tools are configured to detect and alert on suspicious use of net.exe and net1.exe.""" [[rule.threat]] diff --git a/rules/windows/lateral_movement_powershell_remoting_target.toml b/rules/windows/lateral_movement_powershell_remoting_target.toml index d819cf2f387..d144f3dd34e 100644 --- a/rules/windows/lateral_movement_powershell_remoting_target.toml +++ b/rules/windows/lateral_movement_powershell_remoting_target.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/24" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -52,6 +52,41 @@ sequence by host.id with maxspan = 30s [process where host.os.type == "windows" and event.type == "start" and process.parent.name : "wsmprovhost.exe" and not process.executable : "?:\\Windows\\System32\\conhost.exe"] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Incoming Execution via PowerShell Remoting + +PowerShell Remoting enables administrators to execute commands on remote Windows systems, facilitating efficient management. However, adversaries can exploit this feature for lateral movement within a network. The detection rule identifies suspicious activity by monitoring network traffic on specific ports and processes initiated by PowerShell Remoting, flagging potential unauthorized remote executions. + +### Possible investigation steps + +- Review the network traffic logs to identify the source IP address involved in the alert, ensuring it is not a known or authorized management system. +- Check the destination port (5985 or 5986) to confirm it aligns with PowerShell Remoting activity and verify if the connection was expected or authorized. +- Investigate the process tree on the affected host to determine if the process initiated by wsmprovhost.exe is legitimate or if it shows signs of suspicious activity. +- Examine the parent process of wsmprovhost.exe to identify any unusual or unauthorized processes that may have triggered the PowerShell Remoting session. +- Correlate the event with user activity logs to determine if the remote execution was performed by a legitimate user or if there are signs of compromised credentials. +- Assess the risk score and severity in the context of the organization's environment to prioritize the response and determine if further containment or remediation actions are necessary. + +### False positive analysis + +- Legitimate administrative tasks using PowerShell Remoting can trigger the rule. To manage this, identify and whitelist known administrative IP addresses or user accounts that frequently perform remote management tasks. +- Automated scripts or scheduled tasks that use PowerShell Remoting for system maintenance might be flagged. Review and document these scripts, then create exceptions for their specific process names or execution paths. +- Security tools or monitoring solutions that leverage PowerShell Remoting for legitimate purposes may cause alerts. Verify these tools and exclude their associated network traffic or processes from the detection rule. +- Internal IT support activities that involve remote troubleshooting using PowerShell Remoting can be mistaken for threats. Maintain a list of support personnel and their IP addresses to exclude them from triggering alerts. +- Regular software updates or patch management processes that utilize PowerShell Remoting should be considered. Identify these processes and exclude their network traffic or process executions to prevent false positives. + +### Response and remediation + +- Isolate the affected host immediately from the network to prevent further lateral movement by the adversary. +- Terminate any suspicious PowerShell processes identified, especially those initiated by wsmprovhost.exe, to stop unauthorized remote executions. +- Conduct a thorough review of recent user activity and access logs on the affected host to identify any unauthorized access or changes. +- Reset credentials for any accounts that were used in the suspicious activity to prevent further unauthorized access. +- Apply patches and updates to the affected systems to address any vulnerabilities that may have been exploited. +- Enhance monitoring on the network for unusual activity on ports 5985 and 5986 to detect any future attempts at unauthorized PowerShell Remoting. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.""" [[rule.threat]] diff --git a/rules/windows/lateral_movement_rdp_sharprdp_target.toml b/rules/windows/lateral_movement_rdp_sharprdp_target.toml index ea6733fab44..5dad77a8d64 100644 --- a/rules/windows/lateral_movement_rdp_sharprdp_target.toml +++ b/rules/windows/lateral_movement_rdp_sharprdp_target.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/11" integration = ["endpoint"] maturity = "production" -updated_date = "2024/09/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -51,6 +51,40 @@ sequence by host.id with maxspan=1m not process.name : "conhost.exe" ] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 SharpRDP Behavior + +Remote Desktop Protocol (RDP) enables users to connect to and control remote systems, facilitating legitimate administrative tasks. However, adversaries can exploit RDP for lateral movement within a network. SharpRDP, a tool for executing commands on remote systems via RDP, can be misused for unauthorized access. The detection rule identifies suspicious RDP activity by monitoring network connections, registry changes, and process executions, flagging potential misuse indicative of SharpRDP behavior. + +### Possible investigation steps + +- Review the network logs to confirm the presence of incoming RDP connections on port 3389, specifically looking for connections initiated by IP addresses other than localhost (127.0.0.1 or ::1). +- Examine the registry changes to identify any new RunMRU string values set to cmd, powershell, taskmgr, or tsclient, which could indicate command execution attempts. +- Investigate the process execution logs to verify if any processes were started with parent processes like cmd.exe, powershell.exe, or taskmgr.exe, and ensure these are not legitimate administrative actions. +- Correlate the timestamps of the RDP connection, registry change, and process execution to determine if they align within the 1-minute window specified by the detection rule. +- Check the source IP address of the RDP connection against known threat intelligence feeds to assess if it is associated with any malicious activity. +- Analyze user account activity associated with the RDP session to determine if the account was compromised or if the actions were authorized. + +### False positive analysis + +- Legitimate administrative tasks using RDP may trigger the rule if they involve command execution through cmd, powershell, or taskmgr. To manage this, create exceptions for known administrative IP addresses or user accounts frequently performing these tasks. +- Automated scripts or software updates that modify the RunMRU registry key with benign commands can be mistaken for SharpRDP behavior. Identify and exclude these processes or scripts from the detection rule. +- Remote management tools that use RDP and execute commands as part of their normal operation might be flagged. Whitelist these tools by their process names or specific command patterns to prevent false positives. +- Internal network scanning or monitoring tools that simulate RDP connections for security assessments could be misinterpreted. Exclude these tools by their source IP addresses or network behavior signatures. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further lateral movement and unauthorized access. +- Terminate any suspicious processes identified in the alert, such as those initiated by cmd.exe, powershell.exe, or taskmgr.exe, to halt any ongoing malicious activity. +- Review and revert any unauthorized registry changes, particularly those related to the RunMRU registry path, to restore system integrity. +- Conduct a thorough examination of the affected host for additional indicators of compromise, such as unauthorized user accounts or scheduled tasks, and remove any found. +- Reset credentials for any accounts that were accessed or potentially compromised during the incident to prevent further unauthorized access. +- 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 enhanced monitoring and logging for RDP connections and registry changes to detect and respond to similar threats more effectively in the future.""" [[rule.threat]] diff --git a/rules/windows/lateral_movement_remote_file_copy_hidden_share.toml b/rules/windows/lateral_movement_remote_file_copy_hidden_share.toml index 232552123a3..4dd1ff96e5c 100644 --- a/rules/windows/lateral_movement_remote_file_copy_hidden_share.toml +++ b/rules/windows/lateral_movement_remote_file_copy_hidden_share.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/04" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2024/10/31" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -55,6 +55,41 @@ process where host.os.type == "windows" and event.type == "start" and process.name : "robocopy.exe" ) and process.args : "*\\\\*\\*$*" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Copy to a Hidden Share + +In Windows environments, hidden network shares are often used for legitimate administrative tasks, allowing file transfers without user visibility. However, adversaries can exploit these shares for lateral movement or data exfiltration. The detection rule identifies suspicious file copy attempts using common command-line tools like cmd.exe and powershell.exe, focusing on hidden share patterns to flag potential threats. + +### Possible investigation steps + +- Review the process details to identify the specific command-line tool used (cmd.exe, powershell.exe, xcopy.exe, or robocopy.exe) and examine the arguments to understand the nature of the file copy operation. +- Investigate the source and destination of the file copy by analyzing the network share path in the process arguments, focusing on the hidden share pattern (e.g., \\\\*\\\\*$). +- Check the user account associated with the process to determine if it has legitimate access to the hidden share and assess if the activity aligns with the user's typical behavior. +- Correlate the event with other logs or alerts from the same host or user to identify any additional suspicious activities, such as unusual login attempts or privilege escalation. +- Examine the historical activity of the involved host to identify any previous instances of similar file copy attempts or other indicators of lateral movement. +- Consult threat intelligence sources to determine if the detected pattern or tools are associated with known adversary techniques or campaigns. + +### False positive analysis + +- Administrative tasks using hidden shares can trigger alerts. Regularly review and document legitimate administrative activities that involve file transfers to hidden shares. +- Backup operations often use hidden shares for data storage. Identify and exclude backup processes by specifying known backup software and their typical command-line arguments. +- Software deployment tools may utilize hidden shares for distributing updates. Create exceptions for recognized deployment tools by listing their process names and associated arguments. +- IT maintenance scripts might copy files to hidden shares for system updates. Maintain a list of approved maintenance scripts and exclude them from triggering alerts. +- User-initiated file transfers for legitimate purposes can be mistaken for threats. Educate users on proper file transfer methods and monitor for unusual patterns that deviate from documented procedures. + +### Response and remediation + +- Isolate the affected system from the network to prevent further lateral movement or data exfiltration. +- Terminate any suspicious processes identified in the alert, such as cmd.exe, powershell.exe, xcopy.exe, or robocopy.exe, that are involved in the file copy attempt. +- Conduct a forensic analysis of the affected system to identify any additional indicators of compromise or unauthorized access. +- Change credentials for any accounts that were used in the suspicious activity to prevent further unauthorized access. +- Review and restrict permissions on network shares, especially hidden shares, to ensure only authorized users have access. +- Monitor network traffic for any further suspicious activity related to hidden shares and lateral movement attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.""" [[rule.threat]] diff --git a/rules/windows/lateral_movement_remote_service_installed_winlog.toml b/rules/windows/lateral_movement_remote_service_installed_winlog.toml index 52e69a456f1..68195e9ac98 100644 --- a/rules/windows/lateral_movement_remote_service_installed_winlog.toml +++ b/rules/windows/lateral_movement_remote_service_installed_winlog.toml @@ -2,7 +2,7 @@ creation_date = "2022/08/30" integration = ["system", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -63,6 +63,41 @@ event.outcome=="success" and source.ip != null and source.ip != "127.0.0.1" and "?:\\Windows\\SysWOW64\\NwxExeSvc\\NwxExeSvc.exe", "?:\\Windows\\System32\\taskhostex.exe")] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Windows Service Installed + +Windows services are crucial for running background processes. Adversaries exploit this by installing services remotely to maintain persistence or move laterally within a network. The detection rule identifies suspicious service installations following a network logon, excluding known legitimate services, to flag potential unauthorized activities. This helps in identifying and mitigating threats early. + +### Possible investigation steps + +- Review the source IP address from the authentication event to determine if it is from a known or trusted network segment. Investigate any unfamiliar or suspicious IP addresses. +- Check the winlog.logon.id to correlate the logon session with the service installation event, ensuring they are part of the same session. +- Investigate the user account associated with the logon session to determine if the activity aligns with their typical behavior or role within the organization. +- Examine the service file path from the service-installed event to identify if it is a known or legitimate application. Pay special attention to any paths not excluded in the query. +- Look into the history of the computer where the service was installed (winlog.computer_name) for any previous suspicious activities or alerts. +- Assess the timing and frequency of similar events to determine if this is an isolated incident or part of a broader pattern of suspicious behavior. + +### False positive analysis + +- Administrative activities can trigger false positives when administrators frequently install or update services remotely. To manage this, create exceptions for known administrative accounts or specific IP addresses used by IT staff. +- Legitimate software installations or updates may appear as suspicious service installations. Maintain an updated list of authorized software paths and exclude these from the detection rule. +- Automated deployment tools like PDQ Deploy or Veeam Backup can cause false positives. Identify and exclude the service paths associated with these tools to reduce noise. +- Scheduled tasks that install or update services as part of routine maintenance can be mistaken for threats. Document and exclude these tasks from the rule to prevent unnecessary alerts. +- Internal security tools that perform regular checks or updates may also trigger alerts. Ensure these tools are recognized and their service paths are excluded from the detection criteria. + +### Response and remediation + +- Isolate the affected system from the network to prevent further lateral movement by the adversary. This can be done by disabling network interfaces or using network segmentation tools. +- Terminate any unauthorized services identified by the alert to stop any malicious processes from running. Use task management tools or command-line utilities to stop and disable these services. +- Conduct a thorough review of recent logon events and service installations on the affected system to identify any additional unauthorized activities or compromised accounts. +- Change passwords for any accounts that were used in the unauthorized service installation, especially if they have administrative privileges, to prevent further unauthorized access. +- Restore the affected system from a known good backup if any malicious changes or persistence mechanisms are detected that cannot be easily remediated. +- Implement network monitoring and alerting for similar suspicious activities, such as unexpected service installations or network logons, to enhance detection and response capabilities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or accounts have been compromised.""" [[rule.threat]] diff --git a/rules/windows/lateral_movement_suspicious_rdp_client_imageload.toml b/rules/windows/lateral_movement_suspicious_rdp_client_imageload.toml index d6bf620d013..f14e56eea50 100644 --- a/rules/windows/lateral_movement_suspicious_rdp_client_imageload.toml +++ b/rules/windows/lateral_movement_suspicious_rdp_client_imageload.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/19" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -68,6 +68,40 @@ any where host.os.type == "windows" and "?:\\Windows\\System32\\hvsirdpclient.exe" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious RDP ActiveX Client Loaded + +The Remote Desktop Services ActiveX Client, mstscax.dll, facilitates remote desktop connections, enabling users to access and control other systems. Adversaries may exploit this by loading the DLL in unauthorized contexts to move laterally within a network. The detection rule identifies unusual loading of mstscax.dll outside typical system paths, flagging potential misuse indicative of lateral movement attempts. + +### Possible investigation steps + +- Review the process executable path to determine if mstscax.dll was loaded from an unusual or unauthorized location, as specified in the query. +- Check the associated process and user context to identify who initiated the process and whether it aligns with expected behavior or known user activity. +- Investigate the network connections associated with the process to identify any suspicious remote connections or lateral movement attempts. +- Examine recent login events and RDP session logs for the involved user account to detect any unauthorized access or anomalies. +- Correlate the alert with other security events or logs to identify potential patterns or related suspicious activities within the network. + +### False positive analysis + +- Legitimate administrative tools or scripts that load mstscax.dll from non-standard paths may trigger false positives. To mitigate this, identify and document these tools, then add their paths to the exclusion list in the detection rule. +- Software updates or installations that temporarily load mstscax.dll from unusual locations can cause false alerts. Monitor and log these activities, and consider excluding these paths if they are consistently flagged during known update periods. +- Virtualization software or sandbox environments that use mstscax.dll for legitimate purposes might be flagged. Verify the use of such software and exclude their executable paths from the rule to prevent unnecessary alerts. +- Custom user scripts or automation tasks that involve remote desktop functionalities may load mstscax.dll in unexpected ways. Review these scripts and, if deemed safe, add their execution paths to the exclusion list to reduce noise. +- Network drive mappings or shared folders that involve remote desktop components could lead to false positives. Ensure these are part of regular operations and exclude their paths if they are frequently flagged without malicious intent. + +### Response and remediation + +- Isolate the affected system from the network immediately to prevent further lateral movement by the adversary. +- Terminate any suspicious processes associated with the unauthorized loading of mstscax.dll to halt potential malicious activities. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malware or unauthorized software. +- Review and analyze the system and network logs to identify any other systems that may have been accessed or compromised by the adversary. +- Reset credentials for any accounts that were accessed or potentially compromised during the incident to prevent unauthorized access. +- Implement network segmentation to limit the ability of adversaries to move laterally within the network in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or data have been affected.""" [[rule.threat]] diff --git a/rules/windows/lateral_movement_via_startup_folder_rdp_smb.toml b/rules/windows/lateral_movement_via_startup_folder_rdp_smb.toml index 1694f8e9ad5..ebd46787a54 100644 --- a/rules/windows/lateral_movement_via_startup_folder_rdp_smb.toml +++ b/rules/windows/lateral_movement_via_startup_folder_rdp_smb.toml @@ -2,7 +2,7 @@ creation_date = "2020/10/19" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -47,6 +47,40 @@ file where host.os.type == "windows" and event.type in ("creation", "change") an file.path : ("?:\\Users\\*\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*", "?:\\ProgramData\\Microsoft\\Windows\\Start Menu\\Programs\\Startup\\*") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Lateral Movement via Startup Folder + +The Windows Startup folder is a mechanism that allows programs to run automatically upon user logon or system reboot. Adversaries exploit this by placing malicious files in the Startup folder of remote systems, often accessed via RDP or SMB, to ensure persistence and facilitate lateral movement. The detection rule identifies suspicious file activities in these folders, focusing on processes like mstsc.exe, which may indicate unauthorized access and file creation, signaling potential lateral movement attempts. + +### Possible investigation steps + +- Review the alert details to confirm the file creation or change event in the specified Startup folder paths, focusing on the file path patterns: "?:\\\\Users\\\\*\\\\AppData\\\\Roaming\\\\Microsoft\\\\Windows\\\\Start Menu\\\\Programs\\\\Startup\\\\*" and "?:\\\\ProgramData\\\\Microsoft\\\\Windows\\\\Start Menu\\\\Programs\\\\Startup\\\\*". +- Check the process information associated with the event, particularly if the process name is "mstsc.exe" or if the process ID is 4, to determine if the activity is linked to remote access via RDP or SMB. +- Investigate the origin of the remote connection by examining network logs or RDP session logs to identify the source IP address and user account involved in the connection. +- Analyze the newly created or modified file in the Startup folder for malicious characteristics, such as unusual file names, unexpected file types, or known malware signatures, using antivirus or sandbox analysis tools. +- Review user account activity and permissions to determine if the account associated with the process has been compromised or is being misused for unauthorized access. +- Correlate this event with other security alerts or logs from data sources like Sysmon, Microsoft Defender for Endpoint, or SentinelOne to identify any related suspicious activities or patterns indicating lateral movement attempts. + +### False positive analysis + +- Legitimate software installations or updates may create files in the Startup folder, triggering the rule. Users can manage this by maintaining a list of known software that typically modifies the Startup folder and creating exceptions for these processes. +- System administrators using remote desktop tools like mstsc.exe for legitimate purposes might inadvertently trigger the rule. To handle this, users can exclude specific administrator accounts or known IP addresses from the detection rule. +- Automated scripts or system management tools that deploy updates or configurations across multiple systems might cause false positives. Users should identify these tools and add them to an exclusion list to prevent unnecessary alerts. +- Some enterprise applications may use the Startup folder for legitimate operations, especially during system boot or user logon. Users should document these applications and configure the rule to ignore file changes associated with them. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further lateral movement and potential spread of the threat. +- Terminate any suspicious processes, particularly those related to mstsc.exe or any unauthorized processes with PID 4, to halt any ongoing malicious activities. +- Remove any unauthorized files or scripts found in the Startup folder paths specified in the detection query to prevent them from executing on reboot or user logon. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or remnants. +- Review and reset credentials for any accounts that were accessed or potentially compromised during the incident to prevent unauthorized access. +- 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 enhanced monitoring and logging for RDP and SMB activities, focusing on unusual file creation events in Startup folders, to improve detection of similar threats in the future.""" [[rule.threat]] diff --git a/rules/windows/lateral_movement_via_wsus_update.toml b/rules/windows/lateral_movement_via_wsus_update.toml index bd697c08064..6211207ab35 100644 --- a/rules/windows/lateral_movement_via_wsus_update.toml +++ b/rules/windows/lateral_movement_via_wsus_update.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "system","sentinel_one_cloud_funnel", "m36 maturity = "production" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." min_stack_version = "8.14.0" -updated_date = "2024/11/02" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -46,6 +46,40 @@ process.executable : ( ) and (process.name : "psexec64.exe" or ?process.pe.original_file_name : "psexec.c") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 WSUS Abuse for Lateral Movement + +Windows Server Update Services (WSUS) is a system that manages updates for Microsoft products, ensuring that only signed binaries are executed. Adversaries may exploit WSUS to run Microsoft-signed tools like PsExec for lateral movement within a network. The detection rule identifies suspicious processes initiated by WSUS, specifically targeting PsExec executions, to flag potential abuse attempts. + +### Possible investigation steps + +- Review the alert details to confirm the presence of the suspicious process execution, specifically checking for the parent process name "wuauclt.exe" and the child process name "psexec64.exe" or original file name "psexec.c". +- Examine the process execution path to verify if it matches the specified directories: "?:\\Windows\\SoftwareDistribution\\Download\\Install\\*" or "\\Device\\HarddiskVolume?\\Windows\\SoftwareDistribution\\Download\\Install\\*". +- Investigate the source and destination hosts involved in the alert to determine if there are any unauthorized or unexpected connections, focusing on potential lateral movement activities. +- Check the timeline of events leading up to and following the alert to identify any other suspicious activities or patterns that may indicate a broader attack. +- Correlate the alert with other security logs and alerts from data sources like Elastic Endgame, Sysmon, or Microsoft Defender for Endpoint to gather additional context and confirm the legitimacy of the activity. +- Assess the user accounts involved in the process execution to ensure they are legitimate and have not been compromised, paying attention to any anomalies in user behavior or access patterns. + +### False positive analysis + +- Legitimate administrative tasks using PsExec may trigger the rule. To manage this, create exceptions for known administrative accounts or specific times when these tasks are scheduled. +- Automated scripts or software deployment tools that use PsExec for legitimate purposes can cause false positives. Identify these tools and exclude their process hashes or specific execution paths from the rule. +- Security software or monitoring tools that utilize PsExec for scanning or remediation might be flagged. Verify these tools and whitelist their activities by excluding their specific process names or parent processes. +- Test environments where PsExec is used for development or testing purposes can generate alerts. Exclude these environments by specifying their IP ranges or hostnames in the rule exceptions. + +### Response and remediation + +- Isolate the affected system immediately to prevent further lateral movement within the network. Disconnect it from the network or use network segmentation to contain the threat. +- Terminate any suspicious processes identified as PsExec executions initiated by WSUS, specifically those matching the query criteria, to stop any ongoing malicious activity. +- Conduct a thorough review of the affected system's update logs and WSUS configuration to identify any unauthorized changes or updates that may have been exploited. +- Remove any unauthorized or malicious binaries found in the specified directories (e.g., Windows\\SoftwareDistribution\\Download\\Install) to prevent further execution. +- Reset credentials for any accounts that may have been compromised or used in the lateral movement attempt, especially those with administrative privileges. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems have been affected. +- Implement enhanced monitoring and logging for WSUS activities and PsExec executions to detect and respond to similar threats more effectively in the future.""" [[rule.threat]] diff --git a/rules/windows/persistence_ad_adminsdholder.toml b/rules/windows/persistence_ad_adminsdholder.toml index 943a4663f0c..7b0d9b0837b 100644 --- a/rules/windows/persistence_ad_adminsdholder.toml +++ b/rules/windows/persistence_ad_adminsdholder.toml @@ -2,7 +2,7 @@ creation_date = "2022/01/31" integration = ["system", "windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -43,6 +43,41 @@ query = ''' event.action:("Directory Service Changes" or "directory-service-object-modified") and event.code:5136 and winlog.event_data.ObjectDN:CN=AdminSDHolder,CN=System* ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AdminSDHolder Backdoor + +The AdminSDHolder object in Active Directory is crucial for maintaining consistent permissions across privileged accounts. It ensures that any changes to these accounts are reverted to match the AdminSDHolder's settings. Adversaries exploit this by modifying the AdminSDHolder to create persistent backdoors, regaining administrative privileges. The detection rule identifies such abuses by monitoring specific directory service changes, focusing on modifications to the AdminSDHolder object, thus alerting security teams to potential threats. + +### Possible investigation steps + +- Review the event logs for entries with event.code:5136 to identify specific changes made to the AdminSDHolder object. +- Examine the winlog.event_data.ObjectDN field to confirm the object path is CN=AdminSDHolder,CN=System* and verify the nature of the modifications. +- Identify the user account responsible for the changes by checking the event logs for the associated user information. +- Investigate the history of the identified user account to determine if there are any other suspicious activities or patterns of behavior. +- Assess the current permissions on the AdminSDHolder object and compare them with the expected baseline to identify unauthorized changes. +- Check for any recent changes in group memberships or permissions of privileged accounts that could indicate exploitation of the AdminSDHolder backdoor. +- Collaborate with the IT or security team to determine if the changes were authorized or if further action is needed to secure the environment. + +### False positive analysis + +- Routine administrative changes to the AdminSDHolder object can trigger alerts. To manage this, establish a baseline of expected changes and create exceptions for these known activities. +- Scheduled maintenance or updates to Active Directory may result in temporary modifications to the AdminSDHolder object. Document these events and exclude them from triggering alerts during the maintenance window. +- Automated scripts or tools used for Active Directory management might modify the AdminSDHolder object as part of their normal operation. Identify these tools and whitelist their activities to prevent false positives. +- Changes made by trusted security personnel or systems should be logged and reviewed. Implement a process to verify and exclude these changes from alerting if they are part of approved security operations. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation. +- Revert any unauthorized changes to the AdminSDHolder object by restoring it from a known good backup or manually resetting its permissions to the default secure state. +- Conduct a thorough review of all privileged accounts and groups to ensure their permissions align with organizational security policies and have not been altered to match the compromised AdminSDHolder settings. +- Reset passwords for all accounts that were potentially affected or had their permissions altered, focusing on privileged accounts to prevent adversaries from regaining access. +- Implement additional monitoring on the AdminSDHolder object and other critical Active Directory objects to detect any future unauthorized modifications promptly. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach, including identifying any other compromised systems or accounts. +- Review and update access control policies and security configurations to prevent similar attacks, ensuring that only authorized personnel have the ability to modify critical Active Directory objects.""" [[rule.threat]] diff --git a/rules/windows/persistence_app_compat_shim.toml b/rules/windows/persistence_app_compat_shim.toml index 888afb2ac42..2a89370136a 100644 --- a/rules/windows/persistence_app_compat_shim.toml +++ b/rules/windows/persistence_app_compat_shim.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/02" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -48,6 +48,41 @@ registry where host.os.type == "windows" and event.type == "change" and "?:\\Program Files (x86)\\SAP\\SapSetup\\OnRebootSvc\\NWSAPSetupOnRebootInstSvc.exe", "?:\\Program Files (x86)\\Kaspersky Lab\\Kaspersky Security for Windows Server\\kavfs.exe") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Installation of Custom Shim Databases + +Application Compatibility Shim databases are used in Windows to ensure older applications run smoothly on newer OS versions by applying compatibility fixes. However, attackers can exploit this feature to maintain persistence and execute arbitrary code by installing malicious shim databases. The detection rule identifies changes in specific registry paths associated with these databases, excluding known legitimate processes, to flag potential abuse. + +### Possible investigation steps + +- Review the registry path changes identified in the alert to confirm the presence of any unexpected or unauthorized .sdb files in the specified registry paths. +- Investigate the process that made the registry change by examining the process executable path and comparing it against the list of known legitimate processes excluded in the query. +- Check the historical activity of the process responsible for the change to identify any patterns or anomalies that might indicate malicious behavior. +- Analyze the context around the time of the registry change, including other system events or alerts, to identify any related suspicious activities. +- If a suspicious .sdb file is found, conduct a file analysis to determine its purpose and whether it contains any malicious code or configurations. +- Consult threat intelligence sources to see if there are any known threats or campaigns associated with the identified process or .sdb file. + +### False positive analysis + +- Known legitimate processes such as SAP and Kaspersky applications may trigger false positives due to their use of shim databases. These processes are already excluded in the detection rule to minimize unnecessary alerts. +- If additional legitimate applications are identified as causing false positives, users can update the exclusion list by adding the specific process executable paths to the rule. +- Regularly review and update the exclusion list to ensure it reflects the current environment and any new legitimate applications that may use shim databases. +- Monitor the frequency and context of alerts to distinguish between benign and potentially malicious activities, adjusting the rule as necessary to reduce noise. +- Engage with application owners to verify the legitimacy of processes that frequently trigger alerts, ensuring that only trusted applications are excluded. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further propagation or communication with potential command and control servers. +- Terminate any suspicious processes identified as responsible for the installation of the custom shim database, ensuring they are not legitimate processes mistakenly flagged. +- Remove the malicious shim database entries from the registry paths specified in the detection query to eliminate persistence mechanisms. +- Conduct a thorough scan of the affected system using updated antivirus and endpoint detection tools to identify and remove any additional malware or unauthorized changes. +- Review and restore any altered system configurations or files to their original state to ensure system integrity. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for the specified registry paths and associated processes to detect and respond to similar threats in the future.""" [[rule.threat]] diff --git a/rules/windows/persistence_appcertdlls_registry.toml b/rules/windows/persistence_appcertdlls_registry.toml index 8ced36769d3..c2edf2ea416 100644 --- a/rules/windows/persistence_appcertdlls_registry.toml +++ b/rules/windows/persistence_appcertdlls_registry.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende maturity = "production" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." min_stack_version = "8.14.0" -updated_date = "2024/10/15" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -40,6 +40,41 @@ registry where host.os.type == "windows" and event.type == "change" and "MACHINE\\SYSTEM\\*ControlSet*\\Control\\Session Manager\\AppCertDLLs\\*" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Registry Persistence via AppCert DLL + +AppCert DLLs are dynamic link libraries that can be configured to load with every process that uses common API functions to create processes on Windows systems. This feature is intended for legitimate use, such as application compatibility. However, adversaries can exploit this by inserting malicious DLLs into the registry path, ensuring their code executes persistently across system reboots. The detection rule identifies changes to specific registry paths associated with AppCert DLLs, flagging potential unauthorized modifications indicative of persistence or privilege escalation attempts. By monitoring these registry changes, security analysts can detect and respond to such threats effectively. + +### Possible investigation steps + +- Review the specific registry path changes identified in the alert to confirm if they match the paths specified in the query: "HKLM\\\\SYSTEM\\\\*ControlSet*\\\\Control\\\\Session Manager\\\\AppCertDLLs\\\\*", "\\\\REGISTRY\\\\MACHINE\\\\SYSTEM\\\\*ControlSet*\\\\Control\\\\Session Manager\\\\AppCertDLLs\\\\*", or "MACHINE\\\\SYSTEM\\\\*ControlSet*\\\\Control\\\\Session Manager\\\\AppCertDLLs\\\\*". +- Check the timestamp of the registry change event to determine when the modification occurred and correlate it with other system activities or logs around the same time. +- Identify the user account or process responsible for the registry modification by examining the event logs or security logs to determine if it was an authorized change or potentially malicious activity. +- Investigate the DLL file specified in the registry change for any known malicious signatures or behaviors using threat intelligence sources or antivirus tools. +- Analyze the system for any additional indicators of compromise or persistence mechanisms, such as unusual scheduled tasks, startup items, or other registry modifications. +- Review historical data to determine if similar registry changes have occurred in the past, which might indicate a recurring threat or persistent adversary activity. + +### False positive analysis + +- Legitimate software installations or updates may modify the AppCert DLL registry paths as part of their setup process. Users can handle these by creating exceptions for known and trusted software vendors. +- System administrators might intentionally configure AppCert DLLs for application compatibility purposes. To manage this, maintain a list of approved configurations and exclude these from alerts. +- Security tools or endpoint protection software might interact with these registry paths during routine scans or updates. Identify and whitelist these tools to prevent unnecessary alerts. +- Custom enterprise applications may use AppCert DLLs for legitimate process monitoring or enhancement. Collaborate with application developers to document these cases and exclude them from detection. +- Regular system maintenance scripts or group policies might inadvertently trigger changes in these registry paths. Review and adjust these scripts or policies to minimize false positives, or document and exclude them if they are necessary. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Use endpoint detection and response (EDR) tools to terminate any suspicious processes associated with the malicious AppCert DLLs identified in the registry paths. +- Remove the unauthorized AppCert DLL entries from the registry paths: HKLM\\SYSTEM\\*ControlSet*\\Control\\Session Manager\\AppCertDLLs\\* to eliminate persistence mechanisms. +- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to identify and remove any additional malicious files or remnants. +- Review and restore any system files or configurations that may have been altered by the malicious DLLs to ensure system integrity. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for the specific registry paths and related process creation activities to detect any future unauthorized changes promptly.""" [[rule.threat]] diff --git a/rules/windows/persistence_browser_extension_install.toml b/rules/windows/persistence_browser_extension_install.toml index 7bcc2ade5b5..83ca4bb9d9e 100644 --- a/rules/windows/persistence_browser_extension_install.toml +++ b/rules/windows/persistence_browser_extension_install.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/22" integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -61,6 +61,40 @@ file where host.os.type == "windows" and event.type : "creation" and ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Browser Extension Install +Browser extensions enhance functionality in web browsers but can be exploited by adversaries to gain persistence or execute malicious activities. Attackers may disguise harmful extensions as legitimate or use compromised systems to install them. The detection rule identifies suspicious extension installations by monitoring file creation events in typical extension directories, filtering out known safe processes, and focusing on Windows environments. + +### Possible investigation steps + +- Review the file creation event details to identify the specific browser extension file (e.g., .xpi or .crx) and its path to determine if it aligns with known malicious patterns or locations. +- Check the process that initiated the file creation event, especially if it is not a known safe process like firefox.exe, to assess if it is a legitimate application or potentially malicious. +- Investigate the user account associated with the file creation event to determine if the activity is expected or if the account may have been compromised. +- Examine recent system activity and logs for any signs of social engineering attempts or unauthorized access that could have led to the installation of the extension. +- Cross-reference the extension file name and path with threat intelligence sources to identify if it is associated with known malicious browser extensions. +- If applicable, review the browser's extension management interface to verify the presence and legitimacy of the installed extension. + +### False positive analysis + +- Language pack installations for Firefox can trigger false positives. Exclude files named "langpack-*@firefox.mozilla.org.xpi" from detection to prevent unnecessary alerts. +- Dictionary add-ons for Firefox may also be flagged. Add exceptions for files named "*@dictionaries.addons.mozilla.org.xpi" to reduce false positives. +- Regular updates or installations of legitimate browser extensions from trusted sources can be mistaken for malicious activity. Maintain a list of trusted processes and paths to exclude from monitoring. +- User-initiated installations from official browser stores might be flagged. Educate users on safe installation practices and consider excluding known safe processes like "firefox.exe" when associated with legitimate extension paths. +- Frequent installations in enterprise environments due to software deployment tools can cause alerts. Coordinate with IT to identify and exclude these routine activities from detection. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Terminate any suspicious processes associated with the unauthorized browser extension installation, such as unknown or unexpected instances of browser processes. +- Remove the malicious browser extension by deleting the associated files from the extension directories identified in the alert. +- Conduct a full antivirus and anti-malware scan on the affected system to identify and remove any additional threats or remnants of the malicious extension. +- Review and reset browser settings to default to ensure no residual configurations or settings are left by the malicious extension. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement application whitelisting to prevent unauthorized browser extensions from being installed in the future, focusing on the directories and file types identified in the detection query.""" [[rule.threat]] diff --git a/rules/windows/persistence_evasion_registry_ifeo_injection.toml b/rules/windows/persistence_evasion_registry_ifeo_injection.toml index 783c763a025..0f6684125d5 100644 --- a/rules/windows/persistence_evasion_registry_ifeo_injection.toml +++ b/rules/windows/persistence_evasion_registry_ifeo_injection.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/17" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -58,6 +58,40 @@ registry where host.os.type == "windows" and event.type == "change" and /* add FPs here */ not registry.data.strings regex~ ("""C:\\Program Files( \(x86\))?\\ThinKiosk\\thinkiosk\.exe""", """.*\\PSAppDeployToolkit\\.*""") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Image File Execution Options Injection + +Image File Execution Options (IFEO) is a Windows feature allowing developers to debug applications by specifying an alternative executable to run. Adversaries exploit this by setting a debugger to execute malicious code instead, achieving persistence or evasion. The detection rule identifies changes to specific registry keys associated with IFEO, flagging potential misuse by monitoring for unexpected executables being set as debuggers. + +### Possible investigation steps + +- Review the registry path and value that triggered the alert to identify the specific executable or process being targeted for debugging or monitoring. +- Check the registry.data.strings field to determine the unexpected executable set as a debugger or monitor process, and assess its legitimacy. +- Investigate the origin and purpose of the executable found in the registry.data.strings by checking its file properties, digital signature, and any associated metadata. +- Correlate the alert with recent system or user activity to identify any suspicious behavior or changes that coincide with the registry modification. +- Examine the system for additional indicators of compromise, such as unusual network connections, file modifications, or other registry changes, to assess the scope of potential malicious activity. +- Consult threat intelligence sources to determine if the identified executable or behavior is associated with known malware or threat actors. + +### False positive analysis + +- ThinKiosk and PSAppDeployToolkit are known to trigger false positives due to their legitimate use of the Debugger registry key. Users can mitigate this by adding exceptions for these applications in the detection rule. +- Regularly review and update the list of exceptions to include any new legitimate applications that may use the Debugger or MonitorProcess registry keys for valid purposes. +- Monitor the environment for any new software installations or updates that might interact with the IFEO registry keys and adjust the rule exceptions accordingly to prevent unnecessary alerts. +- Collaborate with IT and security teams to identify any internal tools or scripts that might be using these registry keys for legitimate reasons and ensure they are accounted for in the rule exceptions. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Terminate any suspicious processes identified as being executed through the IFEO mechanism to halt any ongoing malicious activity. +- Revert any unauthorized changes to the registry keys associated with Image File Execution Options and SilentProcessExit to their default or intended state. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware or persistence mechanisms. +- Review and restore any altered or deleted system files from a known good backup to ensure system integrity. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for registry changes related to IFEO to detect and respond to similar threats in the future.""" [[rule.threat]] diff --git a/rules/windows/persistence_group_modification_by_system.toml b/rules/windows/persistence_group_modification_by_system.toml index a652ef77e0b..c07d73ac3ef 100644 --- a/rules/windows/persistence_group_modification_by_system.toml +++ b/rules/windows/persistence_group_modification_by_system.toml @@ -2,7 +2,7 @@ creation_date = "2024/06/26" integration = ["system", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -40,6 +40,41 @@ winlog.event_data.SubjectUserSid : "S-1-5-18" and /* DOMAIN_USERS and local groups */ not group.id : "S-1-5-21-*-513" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Active Directory Group Modification by SYSTEM + +Active Directory (AD) is a critical component in Windows environments, managing user and group permissions. SYSTEM, a high-privilege account, can modify AD groups, which attackers exploit to gain unauthorized access. By monitoring specific event logs for SYSTEM-initiated group changes, the detection rule identifies potential privilege escalation, signaling an attacker may have compromised a domain controller. + +### Possible investigation steps + +- Review the event log entry with event code 4728 to confirm the SYSTEM account (S-1-5-18) initiated the group modification. +- Identify the specific Active Directory group that was modified and determine if it is a sensitive or high-privilege group. +- Check for any recent changes or anomalies in the domain controller's security logs that might indicate SYSTEM privilege escalation. +- Investigate the timeline of events leading up to the group modification to identify any suspicious activities or patterns. +- Correlate this event with other security alerts or logs to assess if there is a broader attack pattern or campaign. +- Verify if there are any known vulnerabilities or misconfigurations in the domain controller that could have been exploited to gain SYSTEM privileges. + +### False positive analysis + +- Routine administrative tasks performed by automated scripts or scheduled tasks may trigger this rule. Review and document these tasks, then create exceptions for known benign scripts to prevent unnecessary alerts. +- System maintenance activities, such as software updates or system reconfigurations, might involve legitimate group modifications by SYSTEM. Coordinate with IT teams to identify and whitelist these activities. +- Certain security tools or monitoring solutions may perform group modifications as part of their normal operation. Verify these tools' actions and exclude them from triggering alerts if they are confirmed to be safe. +- In environments with custom applications that require SYSTEM-level access for group management, ensure these applications are documented and their actions are excluded from detection to avoid false positives. +- Regularly review and update the list of exceptions to ensure they remain relevant and do not inadvertently allow malicious activities to go undetected. + +### Response and remediation + +- Immediately isolate the affected domain controller from the network to prevent further unauthorized access or lateral movement by the attacker. +- Revoke any unauthorized group memberships added by the SYSTEM account to prevent privilege escalation and unauthorized access. +- Conduct a thorough review of recent changes in Active Directory, focusing on group modifications and user account activities, to identify any other potential unauthorized changes. +- Reset passwords for all accounts that were added to groups by the SYSTEM account to mitigate the risk of compromised credentials being used. +- Apply security patches and updates to the domain controller to address any vulnerabilities that may have been exploited to gain SYSTEM privileges. +- Monitor for any further suspicious activities or attempts to modify Active Directory groups, using enhanced logging and alerting mechanisms. +- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the full scope of the breach.""" [[rule.threat]] diff --git a/rules/windows/persistence_local_scheduled_job_creation.toml b/rules/windows/persistence_local_scheduled_job_creation.toml index e771f3d2d8e..bb95a64c5dc 100644 --- a/rules/windows/persistence_local_scheduled_job_creation.toml +++ b/rules/windows/persistence_local_scheduled_job_creation.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende maturity = "production" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." min_stack_version = "8.14.0" -updated_date = "2024/10/15" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -42,6 +42,40 @@ file where host.os.type == "windows" and event.type != "deletion" and ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Persistence via Scheduled Job Creation + +Scheduled jobs in Windows environments allow tasks to be automated by executing scripts or programs at specified times. Adversaries exploit this feature to maintain persistence by scheduling malicious code execution. The detection rule identifies suspicious job creation by monitoring specific file paths and extensions, excluding known legitimate processes, to flag potential abuse while minimizing false positives. + +### Possible investigation steps + +- Review the file path and extension to confirm the presence of a scheduled job in the "?:\\Windows\\Tasks\\" directory with a ".job" extension, which is indicative of a scheduled task. +- Examine the process executable path to determine if the job creation is associated with any known legitimate processes, such as CCleaner or ManageEngine, which are excluded in the detection rule. +- Investigate the origin of the process that created the scheduled job by checking the process execution history and command line arguments to identify any potentially malicious behavior. +- Analyze the scheduled job's content and associated scripts or programs to identify any suspicious or unauthorized code that may indicate malicious intent. +- Correlate the event with other security logs and alerts from data sources like Elastic Endgame, Sysmon, or Microsoft Defender for Endpoint to gather additional context and identify any related malicious activity. +- Assess the risk and impact of the scheduled job by determining if it aligns with known adversary tactics, techniques, and procedures (TTPs) related to persistence, as outlined in the MITRE ATT&CK framework. + +### False positive analysis + +- Scheduled jobs created by CCleaner for crash reporting can trigger false positives. Exclude the path "?:\\Windows\\Tasks\\CCleanerCrashReporting.job" when the process executable is "?:\\Program Files\\CCleaner\\CCleaner64.exe". +- ManageEngine UEMS Agent and DesktopCentral Agent may create scheduled jobs for updates, leading to false positives. Exclude the path "?:\\Windows\\Tasks\\DCAgentUpdater.job" when the process executable is "?:\\Program Files (x86)\\ManageEngine\\UEMS_Agent\\bin\\dcagentregister.exe" or "?:\\Program Files (x86)\\DesktopCentral_Agent\\bin\\dcagentregister.exe". +- Regularly review and update exclusion lists to ensure they reflect the current environment and legitimate software behavior. +- Consider implementing a whitelist of known legitimate processes and paths to further reduce false positives while maintaining effective threat detection. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further execution of potentially malicious scheduled jobs and limit lateral movement. +- Terminate any suspicious processes associated with the identified scheduled job, using tools like Task Manager or PowerShell, to halt any ongoing malicious activity. +- Delete the suspicious scheduled job file from the system to prevent future execution. This can be done using the Task Scheduler or command-line tools. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) solutions to identify and remove any additional malicious files or remnants. +- Review and audit other scheduled tasks on the system to ensure no additional unauthorized or suspicious jobs are present. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems are affected. +- Implement enhanced monitoring and alerting for scheduled job creation activities across the network to detect similar threats in the future, leveraging the specific query fields used in the detection rule.""" [[rule.threat]] diff --git a/rules/windows/persistence_local_scheduled_task_creation.toml b/rules/windows/persistence_local_scheduled_task_creation.toml index b16d94cda6a..d467331d35e 100644 --- a/rules/windows/persistence_local_scheduled_task_creation.toml +++ b/rules/windows/persistence_local_scheduled_task_creation.toml @@ -2,7 +2,7 @@ creation_date = "2020/02/18" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -53,6 +53,41 @@ sequence with maxspan=1m not (?process.Ext.token.integrity_level_name : "System" or ?winlog.event_data.IntegrityLevel : "System") ] by process.parent.entity_id ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Local Scheduled Task Creation + +Scheduled tasks in Windows automate routine tasks, but adversaries exploit them for persistence, lateral movement, or privilege escalation. They may use command-line tools like `schtasks.exe` to create tasks under non-system accounts. The detection rule identifies suspicious task creation by monitoring specific processes and command-line arguments, excluding those initiated by system-level users, to flag potential misuse. + +### Possible investigation steps + +- Review the process entity ID to identify the parent process that initiated the scheduled task creation. This can provide context on whether the task was created by a legitimate application or a potentially malicious one. +- Examine the command-line arguments used with schtasks.exe, specifically looking for unusual or suspicious parameters that might indicate malicious intent, such as unexpected task names or execution paths. +- Check the user account associated with the task creation to determine if it is a non-system account and assess whether this account should have the capability to create scheduled tasks. +- Investigate the integrity level of the process to confirm it is not running with elevated privileges, which could indicate an attempt to bypass security controls. +- Correlate the event with other recent activities on the host, such as file modifications or network connections, to identify any patterns or additional indicators of compromise. +- Review the code signature of the initiating process to determine if it is trusted or untrusted, which can help assess the legitimacy of the process creating the task. + +### False positive analysis + +- Scheduled tasks created by legitimate administrative tools or scripts may trigger false positives. Users should identify and whitelist these known benign processes to prevent unnecessary alerts. +- Routine maintenance tasks initiated by IT departments, such as software updates or system checks, can be mistaken for suspicious activity. Exclude these tasks by specifying their unique process names or command-line arguments. +- Tasks created by trusted third-party applications for legitimate purposes might be flagged. Review and exclude these applications by verifying their code signatures and adding them to an exception list. +- Automated tasks set up by non-system accounts for regular operations, like backups or monitoring, can be misinterpreted. Document these tasks and exclude them based on their specific parameters or user accounts involved. +- Consider excluding tasks with a consistent and verified schedule that aligns with organizational policies, as these are less likely to be malicious. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious scheduled tasks identified by the alert using Task Scheduler or command-line tools like schtasks.exe to stop further execution. +- Review and remove any unauthorized scheduled tasks created by non-system accounts to eliminate persistence mechanisms. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious artifacts. +- Analyze the user account involved in the task creation for signs of compromise, and reset credentials if necessary to prevent further unauthorized access. +- 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 enhanced monitoring and logging for scheduled task creation events to detect similar threats in the future, ensuring alerts are configured to notify the appropriate teams promptly.""" [[rule.threat]] diff --git a/rules/windows/persistence_ms_office_addins_file.toml b/rules/windows/persistence_ms_office_addins_file.toml index 040eb7fed6e..5dbd00e8eef 100644 --- a/rules/windows/persistence_ms_office_addins_file.toml +++ b/rules/windows/persistence_ms_office_addins_file.toml @@ -2,7 +2,7 @@ creation_date = "2020/10/16" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -42,6 +42,41 @@ file where host.os.type == "windows" and event.type != "deletion" and "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Excel\\XLSTART\\*" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Persistence via Microsoft Office AddIns + +Microsoft Office AddIns enhance productivity by allowing custom functionalities in Office applications. However, adversaries exploit this by placing malicious add-ins in specific startup directories, ensuring execution each time the application launches. The detection rule identifies suspicious files with extensions like .xll or .xlam in these directories, flagging potential persistence mechanisms on Windows systems. + +### Possible investigation steps + +- Review the file path and extension from the alert to confirm it matches the suspicious directories and extensions specified in the detection rule, such as .xll or .xlam in the Microsoft Office startup directories. +- Check the file creation and modification timestamps to determine when the suspicious file was added or altered, which can help establish a timeline of potential malicious activity. +- Investigate the file's origin by examining recent file downloads, email attachments, or network activity that might have introduced the file to the system. +- Analyze the file's contents or hash against known malware databases to identify if it is a known threat or potentially malicious. +- Review user activity and system logs around the time the file was created or modified to identify any unusual behavior or processes that could be related to the persistence mechanism. +- Assess the impacted user's role and access level to determine the potential risk and impact of the persistence mechanism on the organization. + +### False positive analysis + +- Legitimate add-ins installed by trusted software vendors may trigger alerts. Verify the source and publisher of the add-in to determine its legitimacy. +- Custom add-ins developed internally for business purposes can be flagged. Maintain a whitelist of known internal add-ins to prevent unnecessary alerts. +- Frequent updates to legitimate add-ins might cause repeated alerts. Implement version control and update the whitelist accordingly to accommodate these changes. +- User-specific add-ins for accessibility or productivity tools may be detected. Educate users on safe add-in practices and monitor for any unusual behavior. +- Temporary add-ins used for specific projects or tasks can be mistaken for threats. Document and review these cases to ensure they are recognized as non-threatening. + +### Response and remediation + +- Isolate the affected endpoint from the network to prevent further spread of the potential threat. +- Terminate any suspicious Microsoft Office processes that may be running add-ins from the identified directories. +- Remove the malicious add-in files from the specified startup directories: "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Word\\Startup\\", "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\AddIns\\", and "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Excel\\XLSTART\\". +- Conduct a full antivirus and antimalware scan on the affected system using tools like Microsoft Defender for Endpoint to ensure no other malicious files are present. +- Review and restore any altered system configurations or settings to their default state to ensure system integrity. +- Monitor the affected system and network for any signs of re-infection or related suspicious activity, using enhanced logging and alerting mechanisms. +- Escalate the incident to the security operations center (SOC) or relevant IT security team for further analysis and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/persistence_ms_outlook_vba_template.toml b/rules/windows/persistence_ms_outlook_vba_template.toml index 3cec5159564..ff72c20da93 100644 --- a/rules/windows/persistence_ms_outlook_vba_template.toml +++ b/rules/windows/persistence_ms_outlook_vba_template.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/23" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -40,6 +40,42 @@ query = ''' file where host.os.type == "windows" and event.type != "deletion" and file.path : "C:\\Users\\*\\AppData\\Roaming\\Microsoft\\Outlook\\VbaProject.OTM" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Persistence via Microsoft Outlook VBA + +Microsoft Outlook supports VBA scripting to automate tasks, which can be exploited by adversaries to maintain persistence. Attackers may install malicious VBA templates in the Outlook environment, triggering scripts upon application startup. The detection rule identifies suspicious activity by monitoring for unauthorized modifications to the VBAProject.OTM file, a common target for such persistence techniques, leveraging various data sources to flag potential threats. + +### Possible investigation steps + +- Review the alert details to confirm the file path matches the pattern "C:\\\\Users\\\\*\\\\AppData\\\\Roaming\\\\Microsoft\\\\Outlook\\\\VbaProject.OTM" and ensure the event type is not "deletion". +- Check the modification timestamp of the VbaProject.OTM file to determine when the unauthorized change occurred. +- Identify the user account associated with the file path to understand which user profile was potentially compromised. +- Investigate recent login activities and processes executed by the identified user to detect any anomalies or unauthorized access. +- Examine the contents of the VbaProject.OTM file for any suspicious or unfamiliar VBA scripts that could indicate malicious intent. +- Correlate the findings with other data sources such as Sysmon, Microsoft Defender for Endpoint, or SentinelOne to gather additional context or related events. +- Assess the risk and impact of the detected activity and determine if further containment or remediation actions are necessary. + +### False positive analysis + +- Routine updates or legitimate changes to the Outlook environment can trigger alerts. Users should verify if recent software updates or administrative changes align with the detected activity. +- Custom scripts or macros developed by IT departments for legitimate automation tasks may be flagged. Establish a whitelist of known and approved VBA scripts to prevent unnecessary alerts. +- User-initiated actions such as importing or exporting Outlook settings might modify the VbaProject.OTM file. Educate users on the implications of these actions and consider excluding these specific user actions from triggering alerts. +- Security software or backup solutions that interact with Outlook files could cause false positives. Identify and exclude these processes if they are known to be safe and necessary for operations. +- Regularly review and update the exclusion list to ensure it reflects current organizational needs and does not inadvertently allow malicious activity. + +### Response and remediation + +- Isolate the affected endpoint from the network to prevent further spread of the malicious VBA script and to contain the threat. +- Terminate any suspicious Outlook processes on the affected machine to stop the execution of potentially harmful scripts. +- Remove the unauthorized or malicious VbaProject.OTM file from the affected user's Outlook directory to eliminate the persistence mechanism. +- Restore the VbaProject.OTM file from a known good backup if available, ensuring that it is free from any unauthorized modifications. +- Conduct a full antivirus and antimalware scan on the affected endpoint using tools like Microsoft Defender for Endpoint to identify and remove any additional threats. +- Review and update endpoint security policies to restrict unauthorized modifications to Outlook VBA files, leveraging application whitelisting or similar controls. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] diff --git a/rules/windows/persistence_msds_alloweddelegateto_krbtgt.toml b/rules/windows/persistence_msds_alloweddelegateto_krbtgt.toml index 446ca449b00..017be43d3b3 100644 --- a/rules/windows/persistence_msds_alloweddelegateto_krbtgt.toml +++ b/rules/windows/persistence_msds_alloweddelegateto_krbtgt.toml @@ -2,7 +2,7 @@ creation_date = "2022/01/27" integration = ["system", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -56,6 +56,40 @@ query = ''' iam where event.action == "modified-user-account" and event.code == "4738" and winlog.event_data.AllowedToDelegateTo : "*krbtgt*" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 KRBTGT Delegation Backdoor + +In Active Directory, the KRBTGT account is crucial for Kerberos ticket granting. Adversaries may exploit this by altering the msDS-AllowedToDelegateTo attribute, enabling unauthorized ticket requests and persistent domain access. The detection rule identifies such modifications by monitoring specific event actions and codes, flagging high-risk changes to the KRBTGT delegation settings. + +### Possible investigation steps + +- Review the event logs for the specific event code 4738 to identify the user account that was modified and verify if the msDS-AllowedToDelegateTo attribute includes the KRBTGT service. +- Investigate the user account that performed the modification by checking their recent activities and login history to determine if the action was authorized or suspicious. +- Examine the timeline of the modification event to correlate it with any other unusual activities or alerts in the network around the same time. +- Check for any other modifications to sensitive attributes or accounts in Active Directory that might indicate a broader compromise. +- Assess the potential impact on the domain by evaluating the access level and permissions of the modified account and any associated systems or services. +- Consult with the IT security team to determine if there are any known maintenance activities or changes that could explain the modification, ensuring it was not a legitimate administrative action. + +### False positive analysis + +- Routine administrative tasks involving legitimate changes to the msDS-AllowedToDelegateTo attribute for service accounts may trigger alerts. Review the context of the change and verify with the IT team if it aligns with scheduled maintenance or updates. +- Automated scripts or tools used for Active Directory management might modify delegation settings as part of their operations. Identify these scripts and exclude their activity from triggering alerts by creating exceptions based on the script's signature or the account used. +- Changes made by trusted third-party applications that require delegation for functionality can be mistaken for malicious activity. Document these applications and adjust the detection rule to exclude their known and expected behavior. +- Regular audits or compliance checks that involve modifications to delegation settings should be accounted for. Coordinate with audit teams to schedule these activities and temporarily adjust monitoring rules to prevent false positives during these periods. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or ticket requests using the KRBTGT account. +- Revert any unauthorized changes to the msDS-AllowedToDelegateTo attribute for the KRBTGT account by restoring it to its previous state using a known good backup or manually resetting the attribute. +- Reset the KRBTGT account password twice to invalidate any existing Kerberos tickets that may have been issued using the compromised delegation settings. +- Conduct a thorough review of recent changes to user accounts and delegation settings in Active Directory to identify any other potential unauthorized modifications. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the compromise. +- Implement enhanced monitoring for changes to critical accounts and attributes in Active Directory, focusing on the KRBTGT account and similar high-value targets. +- Review and update access controls and delegation permissions to ensure that only authorized personnel have the ability to modify sensitive attributes like msDS-AllowedToDelegateTo.""" [[rule.threat]] diff --git a/rules/windows/persistence_msi_installer_task_startup.toml b/rules/windows/persistence_msi_installer_task_startup.toml index 6c41a97a039..aad57db99ec 100644 --- a/rules/windows/persistence_msi_installer_task_startup.toml +++ b/rules/windows/persistence_msi_installer_task_startup.toml @@ -2,7 +2,7 @@ creation_date = "2024/09/05" integration = ["endpoint"] maturity = "production" -updated_date = "2024/09/05" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -48,6 +48,42 @@ any where host.os.type == "windows" and "H*\\Software\\WOW6432Node\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\*")) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Persistence via a Windows Installer + +Windows Installer, through msiexec.exe, facilitates software installation and configuration. Adversaries exploit this by creating persistence mechanisms, such as scheduled tasks or startup entries, to maintain access. The detection rule identifies suspicious activity by monitoring msiexec.exe for file creation in startup directories or registry modifications linked to auto-run keys, signaling potential persistence tactics. + +### Possible investigation steps + +- Review the alert details to identify the specific file path or registry path involved in the suspicious activity, focusing on the paths specified in the query such as "?:\\\\Windows\\\\System32\\\\Tasks\\\\*" or "H*\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run\\\\*". +- Check the creation or modification timestamps of the files or registry entries to determine when the suspicious activity occurred and correlate it with other events or logs around the same time. +- Investigate the parent process of msiexec.exe to understand how it was executed and whether it was initiated by a legitimate user action or another suspicious process. +- Examine the contents of the created or modified files or registry entries to identify any scripts, executables, or commands that may indicate malicious intent. +- Look for any associated network activity or connections initiated by msiexec.exe or related processes to identify potential command and control communication. +- Cross-reference the involved file or registry paths with known indicators of compromise or threat intelligence sources to assess the risk level and potential threat actor involvement. +- If applicable, isolate the affected system and perform a deeper forensic analysis to uncover any additional persistence mechanisms or lateral movement within the network. + +### False positive analysis + +- Legitimate software installations or updates may trigger the rule when msiexec.exe creates scheduled tasks or startup entries. Users can create exceptions for known software vendors or specific installation paths to reduce noise. +- System administrators might use msiexec.exe for deploying software across the network, which can appear as suspicious activity. To handle this, exclude specific administrative accounts or IP ranges from the rule. +- Some enterprise management tools may utilize msiexec.exe for legitimate configuration changes, including registry modifications. Identify and exclude these tools by their process names or associated registry paths. +- Automated scripts or deployment tools that rely on msiexec.exe for software management can generate false positives. Consider excluding these scripts or tools by their execution context or associated file paths. +- Regularly review and update the exclusion list to ensure it aligns with the current software deployment and management practices within the organization. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate the msiexec.exe process if it is confirmed to be involved in creating unauthorized persistence mechanisms. +- Remove any scheduled tasks or startup entries created by msiexec.exe that are identified as malicious or unauthorized. +- Restore any modified registry keys to their original state if they were altered to establish persistence. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes. +- Review and update security policies to restrict the use of msiexec.exe for non-administrative users, reducing the risk of exploitation. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/persistence_msoffice_startup_registry.toml b/rules/windows/persistence_msoffice_startup_registry.toml index 4565aedddf2..ad031b63897 100644 --- a/rules/windows/persistence_msoffice_startup_registry.toml +++ b/rules/windows/persistence_msoffice_startup_registry.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/22" integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/10" +updated_date = "2025/01/10" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for SentinelOne Integration." @@ -42,6 +42,40 @@ query = ''' registry where host.os.type == "windows" and event.action != "deletion" and registry.path : "*\\Software\\Microsoft\\Office Test\\Special\\Perf\\*" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Office Test Registry Persistence + +The Office Test Registry key in Windows environments allows specifying a DLL to execute whenever an Office application starts, providing a mechanism for legitimate customization. However, adversaries can exploit this for persistence by loading malicious DLLs. The detection rule monitors modifications to this registry path, excluding deletions, to identify potential abuse, leveraging data from various security sources to flag suspicious activity. + +### Possible investigation steps + +- Review the registry event details to identify the specific DLL path that was added or modified in the Office Test Registry key. +- Check the file properties and digital signature of the DLL specified in the registry modification to determine its legitimacy. +- Investigate the source of the registry modification by correlating with user activity logs to identify which user account made the change. +- Analyze recent process execution logs for any Office applications to detect if the suspicious DLL has been loaded or executed. +- Cross-reference the DLL and associated registry modification with threat intelligence sources to check for known malicious indicators. +- Examine the system for additional signs of compromise, such as unusual network connections or other persistence mechanisms, to assess the scope of potential intrusion. + +### False positive analysis + +- Legitimate software installations or updates may modify the Office Test Registry key as part of their setup process. Users can create exceptions for known software vendors or specific applications that are frequently updated. +- System administrators might use scripts or management tools that modify the registry for configuration purposes. Identify and exclude these trusted scripts or tools from triggering alerts. +- Customization by IT departments for legitimate business needs can lead to registry modifications. Document and whitelist these customizations to prevent false positives. +- Security software or monitoring tools might interact with the registry as part of their normal operations. Verify and exclude these interactions if they are known to be safe and necessary for system functionality. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further spread or communication with potential command and control servers. +- Use endpoint detection and response (EDR) tools to terminate any suspicious processes associated with the malicious DLL identified in the registry path. +- Remove the malicious DLL entry from the Office Test Registry key to prevent it from executing on future Office application startups. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious files or remnants. +- Review recent user activity and system logs to identify any unauthorized access or changes that may have led to the registry modification, and reset credentials if necessary. +- 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 enhanced monitoring and alerting for similar registry modifications across the network to detect and respond to future attempts promptly.""" [[rule.threat]] diff --git a/rules/windows/persistence_netsh_helper_dll.toml b/rules/windows/persistence_netsh_helper_dll.toml index b024cd12e5b..96831535eb0 100644 --- a/rules/windows/persistence_netsh_helper_dll.toml +++ b/rules/windows/persistence_netsh_helper_dll.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/29" integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -43,6 +43,39 @@ registry where host.os.type == "windows" and event.type == "change" and "MACHINE\\Software\\Microsoft\\netsh\\*" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Netsh Helper DLL + +Netsh, a command-line utility in Windows, allows for network configuration and diagnostics. It supports extensibility through Helper DLLs, which can be added to enhance its capabilities. However, attackers can exploit this by adding malicious DLLs, ensuring their code runs whenever netsh is executed. The detection rule monitors registry changes related to netsh DLLs, flagging unauthorized modifications that may indicate persistence tactics. + +### Possible investigation steps + +- Review the registry path specified in the alert to confirm the presence of any unauthorized or suspicious DLLs under "HKLM\\Software\\Microsoft\\netsh\\". +- Check the timestamp of the registry change event to determine when the modification occurred and correlate it with any other suspicious activities or events on the system. +- Investigate the origin of the DLL file by examining its properties, such as the file path, creation date, and digital signature, to assess its legitimacy. +- Analyze recent user activity and scheduled tasks to identify any potential execution of netsh.exe that could have triggered the malicious DLL. +- Cross-reference the alert with other security logs and alerts from data sources like Microsoft Defender for Endpoint or Sysmon to gather additional context and identify any related threats or indicators of compromise. + +### False positive analysis + +- Legitimate software installations or updates may add or modify Netsh Helper DLLs, triggering the detection rule. Users should verify if recent installations or updates coincide with the registry changes. +- Network management tools or scripts used by IT departments might legitimately extend netsh functionality. Identify and document these tools to create exceptions in the detection rule. +- Scheduled tasks or administrative scripts that configure network settings could cause expected changes. Review scheduled tasks and scripts to ensure they are authorized and adjust the rule to exclude these known activities. +- Security software or network monitoring solutions may interact with netsh for legitimate purposes. Confirm with the software vendor if their product modifies netsh settings and consider excluding these changes from the rule. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further execution of the malicious DLL and potential lateral movement. +- Terminate any suspicious processes associated with netsh.exe to halt the execution of the malicious payload. +- Remove the unauthorized Netsh Helper DLL entry from the registry path identified in the alert to eliminate the persistence mechanism. +- Conduct a thorough scan of the affected system using an updated antivirus or endpoint detection and response (EDR) tool to identify and remove any additional malicious files or artifacts. +- Review and restore any altered system configurations to their original state to ensure system integrity. +- 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 enhanced monitoring and logging for registry changes related to Netsh Helper DLLs to detect similar threats in the future.""" [[rule.threat]] diff --git a/rules/windows/persistence_powershell_exch_mailbox_activesync_add_device.toml b/rules/windows/persistence_powershell_exch_mailbox_activesync_add_device.toml index 35c401eed9e..f1773f5fd72 100644 --- a/rules/windows/persistence_powershell_exch_mailbox_activesync_add_device.toml +++ b/rules/windows/persistence_powershell_exch_mailbox_activesync_add_device.toml @@ -2,7 +2,7 @@ creation_date = "2020/12/15" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2024/10/31" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -56,6 +56,41 @@ query = ''' process where host.os.type == "windows" and event.type == "start" and process.name: ("powershell.exe", "pwsh.exe", "powershell_ise.exe") and process.args : "Set-CASMailbox*ActiveSyncAllowedDeviceIDs*" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating New ActiveSyncAllowedDeviceID Added via PowerShell + +ActiveSync is a protocol enabling mobile devices to synchronize with Exchange mailboxes, crucial for accessing emails on-the-go. Adversaries may exploit the Exchange PowerShell cmdlet, Set-CASMailbox, to add unauthorized devices, gaining persistent access to sensitive email data. The detection rule identifies suspicious PowerShell activity by monitoring for specific command patterns, helping to flag potential unauthorized device additions and mitigate risks associated with account manipulation. + +### Possible investigation steps + +- Review the alert details to identify the specific process name (e.g., powershell.exe, pwsh.exe, powershell_ise.exe) and the command line arguments used, focusing on the presence of "Set-CASMailbox" and "ActiveSyncAllowedDeviceIDs". +- Examine the user account associated with the process execution to determine if the account has a history of legitimate administrative actions or if it might be compromised. +- Check the device ID added to the ActiveSyncAllowedDeviceIDs list to verify if it is recognized and authorized for use within the organization. +- Investigate the source IP address and host from which the PowerShell command was executed to assess if it aligns with expected administrative activity or if it originates from an unusual or suspicious location. +- Review recent email access logs for the user account to identify any unusual patterns or access from unfamiliar devices that could indicate unauthorized access. +- Correlate this event with other security alerts or logs from data sources like Microsoft Defender for Endpoint or Sysmon to identify any related suspicious activities or patterns. + +### False positive analysis + +- Legitimate administrative tasks may trigger the rule when IT staff use PowerShell to configure or update ActiveSync settings for users. To manage this, create exceptions for known administrative accounts or specific maintenance windows. +- Automated scripts for device management that include the Set-CASMailbox cmdlet can cause false positives. Review and whitelist these scripts if they are verified as part of routine operations. +- Third-party applications that integrate with Exchange and modify ActiveSync settings might be flagged. Identify and exclude these applications if they are trusted and necessary for business operations. +- Regular audits of device additions by authorized personnel can help distinguish between legitimate and suspicious activities, allowing for more accurate exception handling. +- Consider the context of the activity, such as the time of day and the user account involved, to refine detection rules and reduce false positives. + +### Response and remediation + +- Immediately isolate the affected user account by disabling it to prevent further unauthorized access to the mailbox. +- Revoke the ActiveSync device access by removing the unauthorized device ID from the user's mailbox settings using the Exchange PowerShell cmdlet. +- Conduct a thorough review of the affected user's mailbox and account activity logs to identify any unauthorized access or data exfiltration attempts. +- Reset the password for the compromised user account and enforce multi-factor authentication (MFA) to enhance security. +- Notify the security team and relevant stakeholders about the incident for further investigation and potential escalation. +- Implement additional monitoring on the affected account and similar accounts for any unusual activity or further attempts to add unauthorized devices. +- Review and update the organization's security policies and procedures related to mobile device access and PowerShell usage to prevent recurrence.""" [[rule.threat]] diff --git a/rules/windows/persistence_registry_uncommon.toml b/rules/windows/persistence_registry_uncommon.toml index dba7ca9b4e9..e92d89a51d0 100644 --- a/rules/windows/persistence_registry_uncommon.toml +++ b/rules/windows/persistence_registry_uncommon.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/18" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/12/10" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -115,6 +115,41 @@ registry where host.os.type == "windows" and event.type == "change" and ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Registry Persistence Change + +Windows Registry is a critical system database storing configuration settings. Adversaries exploit registry keys for persistence, ensuring malicious code executes on startup or during specific events. The detection rule identifies unusual modifications to less commonly altered registry keys, which may indicate stealthy persistence attempts. It filters out benign changes by excluding known legitimate processes and paths, focusing on suspicious alterations. + +### Possible investigation steps + +- Review the specific registry path and value that triggered the alert to understand the context of the change and its potential impact on system behavior. +- Identify the process responsible for the registry modification by examining the process.name and process.executable fields, and determine if it is a known legitimate process or potentially malicious. +- Check the registry.data.strings field to see the new data or command being set in the registry key, and assess whether it aligns with known legitimate software or suspicious activity. +- Investigate the user account associated with the registry change by reviewing the HKEY_USERS path, if applicable, to determine if the change was made by an authorized user or an unexpected account. +- Correlate the alert with other recent events on the host, such as file modifications or network connections, to identify any additional indicators of compromise or related suspicious activity. +- Consult threat intelligence sources or databases to see if the registry path or process involved is associated with known malware or adversary techniques. + +### False positive analysis + +- Legitimate software installations or updates may modify registry keys for setup or configuration purposes. Users can create exceptions for known software paths like C:\\Program Files\\*.exe to reduce noise. +- System maintenance processes such as Windows Update might trigger changes in registry keys like SetupExecute. Exclude processes like TiWorker.exe and poqexec.exe when they match known update patterns. +- Administrative scripts or tools that automate system configurations can alter registry keys. Identify and exclude these scripts by their executable paths or process names to prevent false alerts. +- Security software, including antivirus or endpoint protection, may interact with registry keys for monitoring purposes. Exclude paths related to these tools, such as C:\\ProgramData\\Microsoft\\Windows Defender\\Platform\\*\\MsMpEng.exe, to avoid false positives. +- User-initiated changes through control panel settings or personalization options can affect registry keys like SCRNSAVE.EXE. Exclude common system paths like %windir%\\system32\\rundll32.exe user32.dll,LockWorkStation to minimize false detections. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of potential malicious activity. +- Terminate any suspicious processes identified in the alert, particularly those not matching known legitimate executables or paths. +- Restore any altered registry keys to their original state using a known good backup or by manually resetting them to default values. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes. +- Review and update endpoint protection policies to ensure that similar registry changes are monitored and alerted on in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Document the incident, including all actions taken, to improve future response efforts and update threat intelligence databases.""" [[rule.threat]] diff --git a/rules/windows/persistence_remote_password_reset.toml b/rules/windows/persistence_remote_password_reset.toml index c0698e0647d..5ff1c295a2e 100644 --- a/rules/windows/persistence_remote_password_reset.toml +++ b/rules/windows/persistence_remote_password_reset.toml @@ -2,7 +2,7 @@ creation_date = "2021/10/18" integration = ["system", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -18,7 +18,41 @@ index = ["winlogbeat-*", "logs-system.security*", "logs-windows.forwarded*"] language = "eql" license = "Elastic License v2" name = "Account Password Reset Remotely" -note = """ +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Account Password Reset Remotely + +Remote password resets are crucial for managing user accounts, especially for privileged users. However, adversaries exploit this by resetting passwords to maintain unauthorized access or bypass security policies. The detection rule identifies suspicious remote password resets by monitoring successful network logins and subsequent password reset actions, focusing on privileged accounts to minimize noise and highlight potential threats. + +### Possible investigation steps + +- Review the source IP address from the authentication event to determine if it is from a known or trusted network. Investigate any unfamiliar or suspicious IP addresses. +- Check the winlog.event_data.TargetUserName from the password reset event to confirm if it belongs to a privileged account and verify if the reset was authorized. +- Correlate the winlog.event_data.SubjectLogonId from both the authentication and password reset events to ensure they are linked and identify the user or process responsible for the actions. +- Investigate the timing and frequency of similar events to identify patterns or anomalies that may indicate malicious activity. +- Examine any recent changes or activities associated with the account in question to assess if there are other signs of compromise or unauthorized access. + +### False positive analysis + +- Routine administrative tasks can trigger false positives when legitimate IT staff reset passwords for maintenance or support. To manage this, create exceptions for known IT personnel or service accounts that frequently perform these actions. +- Automated scripts or tools used for account management might cause false alerts. Identify and exclude these scripts or tools by their specific account names or IP addresses. +- Scheduled password resets for compliance or security policies may appear suspicious. Document and exclude these scheduled tasks by their timing and associated accounts. +- Service accounts with naming conventions similar to privileged accounts might be flagged. Review and adjust the rule to exclude these specific service accounts by refining the naming patterns in the query. +- Internal network devices or systems that perform regular password resets could be misinterpreted as threats. Whitelist these devices by their IP addresses or hostnames to reduce noise. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Revoke any active sessions associated with the compromised account to disrupt any ongoing malicious activities. +- Reset the password of the affected account using a secure method, ensuring it is done from a trusted and secure system. +- Conduct a thorough review of recent account activities and system logs to identify any additional unauthorized changes or access attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach. +- Implement additional monitoring on the affected account and related systems to detect any further suspicious activities. +- Review and update access controls and privileged account management policies to prevent similar incidents in the future. + ## Performance This rule may cause medium to high performance impact due to logic scoping all remote Windows logon activity. """ diff --git a/rules/windows/persistence_runtime_run_key_startup_susp_procs.toml b/rules/windows/persistence_runtime_run_key_startup_susp_procs.toml index ddc19d2048d..8293ddb3d9d 100644 --- a/rules/windows/persistence_runtime_run_key_startup_susp_procs.toml +++ b/rules/windows/persistence_runtime_run_key_startup_susp_procs.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/19" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -51,6 +51,41 @@ sequence by host.id, user.name with maxspan=1m process.args : ("C:\\Users\\*", "C:\\ProgramData\\*", "C:\\Windows\\Temp\\*", "C:\\Windows\\Tasks\\*", "C:\\PerfLogs\\*", "C:\\Intel\\*") ] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Execution of Persistent Suspicious Program + +Persistent programs, like scripts or rundll32, are often used by adversaries to maintain access to a system. These programs can be executed at startup, leveraging process lineage and command line arguments to evade detection. The detection rule identifies suspicious executions by monitoring the sequence of processes initiated after user logon, focusing on known malicious executables and unusual file paths, thus highlighting potential abuse of persistence mechanisms. + +### Possible investigation steps + +- Review the process lineage to confirm the sequence of userinit.exe, explorer.exe, and the suspicious child process. Verify if the child process was indeed launched shortly after user logon. +- Examine the command line arguments of the suspicious process to identify any unusual or malicious patterns, especially those involving known suspicious paths like C:\\Users\\*, C:\\ProgramData\\*, or C:\\Windows\\Temp\\*. +- Check the original file name of the suspicious process against known malicious executables such as cscript.exe, wscript.exe, or PowerShell.EXE to determine if it matches any of these. +- Investigate the parent process explorer.exe to ensure it was not compromised or manipulated to launch the suspicious child process. +- Analyze the user account associated with the suspicious process to determine if it has been involved in any other suspicious activities or if it has elevated privileges that could be exploited. +- Review recent system changes or installations that might have introduced the suspicious executable or altered startup configurations. + +### False positive analysis + +- Legitimate administrative scripts or tools may trigger alerts if they are executed from common directories like C:\\Users or C:\\ProgramData. To manage this, create exceptions for known administrative scripts that are regularly used in your environment. +- Software updates or installations might use processes like PowerShell or RUNDLL32, leading to false positives. Identify and exclude these processes when they are part of a verified update or installation routine. +- Custom scripts or automation tasks that run at startup could be flagged. Document these tasks and exclude them from the rule if they are part of normal operations. +- Security or monitoring tools that use similar execution patterns may be mistakenly identified. Verify these tools and add them to an exclusion list to prevent unnecessary alerts. +- User-initiated actions that mimic suspicious behavior, such as running scripts from the command line, can cause false positives. Educate users on safe practices and adjust the rule to exclude known benign user actions. + +### Response and remediation + +- Isolate the affected host from the network to prevent further spread or communication with potential command and control servers. +- Terminate any suspicious processes identified in the alert, such as those executed by cscript.exe, wscript.exe, PowerShell.EXE, MSHTA.EXE, RUNDLL32.EXE, REGSVR32.EXE, RegAsm.exe, MSBuild.exe, or InstallUtil.exe. +- Remove any unauthorized or suspicious startup entries or scheduled tasks that may have been created to ensure persistence. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or remnants. +- Review and restore any modified system configurations or registry settings to their default or secure state. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for the affected host and similar systems to detect any recurrence or related suspicious activities.""" [[rule.threat]] diff --git a/rules/windows/persistence_scheduled_task_creation_winlog.toml b/rules/windows/persistence_scheduled_task_creation_winlog.toml index 6fa9f59b94f..77b3f381b52 100644 --- a/rules/windows/persistence_scheduled_task_creation_winlog.toml +++ b/rules/windows/persistence_scheduled_task_creation_winlog.toml @@ -2,7 +2,7 @@ creation_date = "2022/08/29" integration = ["system", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -44,6 +44,39 @@ iam where event.action == "scheduled-task-created" and "\\OneDrive Standalone Update Task-S-1-12-1-*" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 A scheduled task was created + +Scheduled tasks in Windows automate routine tasks, enhancing efficiency. However, adversaries exploit this feature to maintain persistence, move laterally, or escalate privileges by creating malicious tasks. The detection rule identifies suspicious task creation by filtering out benign tasks and those initiated by system accounts, focusing on potential threats. This approach helps security analysts pinpoint unauthorized task creation indicative of malicious activity. + +### Possible investigation steps + +- Review the user account associated with the task creation to determine if it is a known and authorized user, ensuring it is not a system account by checking that the username does not end with a dollar sign. +- Examine the task name and path in the event data to identify if it matches any known benign tasks or if it appears suspicious or unfamiliar. +- Investigate the origin of the task creation by checking the source IP address or hostname, if available, to determine if it aligns with expected network activity. +- Check the task's scheduled actions and triggers to understand what the task is designed to execute and when, looking for any potentially harmful or unexpected actions. +- Correlate the task creation event with other security events or logs around the same time to identify any related suspicious activities or anomalies. + +### False positive analysis + +- Scheduled tasks created by system accounts or computer accounts are often benign. These can be excluded by filtering out user names ending with a dollar sign, which typically represent system accounts. +- Tasks associated with common software updates or maintenance, such as those from Hewlett-Packard or Microsoft Visual Studio, are generally non-threatening. These can be excluded by specifying their full task names in the exclusion list. +- OneDrive update tasks are frequently triggered and are usually safe. Exclude these by using patterns that match their task names, such as those starting with "OneDrive Standalone Update Task". +- Regularly review and update the exclusion list to include any new benign tasks that are identified over time, ensuring that the rule remains effective without generating unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious scheduled tasks identified by the alert to halt any ongoing malicious activity. +- Conduct a thorough review of the system's scheduled tasks to identify and remove any other unauthorized or suspicious tasks. +- Restore the system from a known good backup if any malicious activity has been confirmed and has potentially compromised system integrity. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. +- Monitor the system and network for any signs of re-infection or further unauthorized scheduled task creation. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/persistence_scheduled_task_updated.toml b/rules/windows/persistence_scheduled_task_updated.toml index 6983c1da7a1..0a6deb606a9 100644 --- a/rules/windows/persistence_scheduled_task_updated.toml +++ b/rules/windows/persistence_scheduled_task_updated.toml @@ -2,7 +2,7 @@ creation_date = "2022/08/29" integration = ["system", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -48,6 +48,39 @@ iam where event.action == "scheduled-task-updated" and "\\Microsoft\\VisualStudio\\Updates\\BackgroundDownload") and not winlog.event_data.SubjectUserSid : ("S-1-5-18", "S-1-5-19", "S-1-5-20") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 A scheduled task was updated + +Scheduled tasks in Windows automate routine tasks, enhancing efficiency. However, adversaries exploit this by modifying tasks to maintain persistence, often altering legitimate tasks to evade detection. The detection rule identifies suspicious updates by filtering out benign changes, such as those by system accounts or known safe tasks, focusing on anomalies that suggest malicious intent. + +### Possible investigation steps + +- Review the event logs to identify the specific scheduled task that was updated, focusing on the winlog.event_data.TaskName field to determine if it matches any known malicious patterns. +- Investigate the user account associated with the update by examining the user.name field to ensure it is not a compromised account or an unauthorized user. +- Check the winlog.event_data.SubjectUserSid field to verify if the update was made by a system account or a potentially malicious user, as system accounts like S-1-5-18, S-1-5-19, and S-1-5-20 are typically benign. +- Analyze the history of changes to the scheduled task to identify any unusual or unauthorized modifications that could indicate persistence mechanisms. +- Correlate the scheduled task update with other security events or alerts to determine if it is part of a broader attack pattern or campaign. + +### False positive analysis + +- Scheduled tasks updated by system accounts can be false positives. Exclude updates made by system accounts by filtering out user names ending with a dollar sign. +- Legitimate Microsoft tasks often update automatically. Exclude tasks with names containing "Microsoft" to reduce noise from these updates. +- Commonly updated tasks like User Feed Synchronization and OneDrive Reporting are typically benign. Exclude these specific task names to avoid unnecessary alerts. +- Tasks updated by well-known service SIDs such as S-1-5-18, S-1-5-19, and S-1-5-20 are generally safe. Exclude these SIDs to prevent false positives from routine system operations. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Review the specific scheduled task that was updated to determine if it was altered by an unauthorized user or process. Revert any unauthorized changes to their original state. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious software that may have been introduced. +- Analyze the user account that made the changes to the scheduled task. If the account is compromised, reset the password and review recent activities for further signs of compromise. +- Implement additional monitoring on the affected system and similar systems to detect any further unauthorized scheduled task updates or related suspicious activities. +- Escalate the incident to the security operations team for further investigation and to determine if the threat is part of a larger attack campaign. +- Review and update access controls and permissions related to scheduled tasks to ensure only authorized personnel can make changes, reducing the risk of future unauthorized modifications.""" [[rule.threat]] diff --git a/rules/windows/persistence_service_dll_unsigned.toml b/rules/windows/persistence_service_dll_unsigned.toml index 63ce6c7c0e4..7b336a0b0f0 100644 --- a/rules/windows/persistence_service_dll_unsigned.toml +++ b/rules/windows/persistence_service_dll_unsigned.toml @@ -2,7 +2,7 @@ creation_date = "2023/01/17" integration = ["endpoint"] maturity = "production" -updated_date = "2024/09/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -126,6 +126,42 @@ library where host.os.type == "windows" and "23aa95b637a1bf6188b386c21c4e87967ede80242327c55447a5bb70d9439244", "5050b025909e81ae5481db37beb807a80c52fc6dd30c8aa47c9f7841e2a31be7") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Unsigned DLL Loaded by Svchost + +Svchost.exe is a critical Windows process that hosts multiple services, allowing efficient resource management. Adversaries exploit this by loading unsigned DLLs to gain persistence or execute code with elevated privileges. The detection rule identifies such threats by monitoring DLLs recently created and loaded by svchost, focusing on untrusted signatures and unusual file paths, thus highlighting potential malicious activity. + +### Possible investigation steps + +- Review the specific DLL file path and hash (dll.path and dll.hash.sha256) to determine if it is known to be associated with legitimate software or if it is potentially malicious. +- Check the creation time of the DLL (dll.Ext.relative_file_creation_time) to understand the timeline of events and correlate it with other activities on the system around the same time. +- Investigate the process that loaded the DLL (process.executable) to determine if it is a legitimate instance of svchost.exe or if it has been tampered with or replaced. +- Analyze the code signature status (dll.code_signature.trusted and dll.code_signature.status) to verify if the DLL is unsigned or has an untrusted signature, which could indicate tampering or a malicious origin. +- Cross-reference the DLL's hash (dll.hash.sha256) against known malware databases or threat intelligence sources to identify if it is associated with known threats. +- Examine the system for other indicators of compromise, such as unusual network activity or additional suspicious files, to assess the scope of potential malicious activity. +- Consider isolating the affected system to prevent further potential compromise while conducting a deeper forensic analysis. + +### False positive analysis + +- System maintenance or updates may trigger the rule by loading legitimate unsigned DLLs. Users can create exceptions for known update processes or maintenance activities to prevent unnecessary alerts. +- Custom or in-house applications might load unsigned DLLs from unusual paths. Verify the legitimacy of these applications and consider adding their specific paths to the exclusion list if they are deemed safe. +- Security or monitoring tools might use unsigned DLLs for legitimate purposes. Identify these tools and exclude their associated DLLs by hash or path to reduce false positives. +- Temporary files created by legitimate software in monitored directories can be mistaken for threats. Regularly review and update the exclusion list to include hashes of these known benign files. +- Development environments often generate unsigned DLLs during testing phases. Ensure that development paths are excluded from monitoring to avoid false alerts during software development cycles. + +### Response and remediation + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate the svchost.exe process that loaded the unsigned DLL to stop any ongoing malicious actions. +- Remove the identified unsigned DLL from the system to eliminate the immediate threat. +- Conduct a full antivirus and anti-malware scan on the affected system to detect and remove any additional threats. +- Review and restore any modified system configurations or settings to their original state to ensure system integrity. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for svchost.exe and DLL loading activities to detect similar threats in the future.""" [[rule.threat]] diff --git a/rules/windows/persistence_services_registry.toml b/rules/windows/persistence_services_registry.toml index 7225410023f..a9bb55f50e2 100644 --- a/rules/windows/persistence_services_registry.toml +++ b/rules/windows/persistence_services_registry.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/18" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -65,6 +65,41 @@ registry where host.os.type == "windows" and event.type == "change" and "?:\\Windows\\System32\\WaaSMedicAgent.exe" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Persistence via Services Registry + +Windows services are crucial for running background processes. Adversaries may exploit this by directly altering service registry keys to maintain persistence, bypassing standard APIs. The detection rule identifies such anomalies by monitoring changes to specific registry paths and filtering out legitimate processes, thus highlighting potential unauthorized service modifications indicative of malicious activity. + +### Possible investigation steps + +- Review the specific registry paths and values that triggered the alert, focusing on "ServiceDLL" and "ImagePath" within the specified registry paths to identify any unauthorized or suspicious modifications. +- Examine the process responsible for the registry change, paying attention to the process name and executable path, to determine if it is a known legitimate process or potentially malicious. +- Cross-reference the process executable path against the list of known legitimate paths excluded in the query to ensure it is not a false positive. +- Investigate the historical behavior of the process and any associated files or network activity to identify patterns indicative of malicious intent or persistence mechanisms. +- Check for any recent changes or anomalies in the system's service configurations that could correlate with the registry modifications, indicating potential unauthorized service creation or alteration. +- Consult threat intelligence sources or databases to determine if the process or registry changes are associated with known malware or adversary techniques. + +### False positive analysis + +- Legitimate software installations or updates may modify service registry keys directly. Users can create exceptions for known software update processes by excluding their executables from the detection rule. +- System maintenance tools like Process Explorer may trigger false positives when they interact with service registry keys. Exclude these tools by adding their process names and paths to the exception list. +- Drivers installed by trusted hardware peripherals might alter service registry keys. Users should identify and exclude these driver paths if they are known to be safe and frequently updated. +- Custom enterprise applications that require direct registry modifications for service management can be excluded by specifying their executable paths in the rule exceptions. +- Regular system processes such as svchost.exe or services.exe are already excluded, but ensure any custom scripts or automation tools that mimic these processes are also accounted for in the exceptions. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified in the alert that are not part of legitimate applications or services. +- Restore the modified registry keys to their original state using a known good backup or by manually correcting the entries to ensure the integrity of the service configurations. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious software or artifacts. +- Review and update endpoint protection policies to ensure that similar unauthorized registry modifications are detected and blocked in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Document the incident details, including the steps taken for containment and remediation, to enhance future response efforts and update threat intelligence databases.""" [[rule.threat]] diff --git a/rules/windows/persistence_suspicious_scheduled_task_runtime.toml b/rules/windows/persistence_suspicious_scheduled_task_runtime.toml index a593685c0f5..ff3c3de7369 100644 --- a/rules/windows/persistence_suspicious_scheduled_task_runtime.toml +++ b/rules/windows/persistence_suspicious_scheduled_task_runtime.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/19" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -80,6 +80,41 @@ process where host.os.type == "windows" and event.type == "start" and not (process.name : "powershell.exe" and process.args : ("-File", "-PSConsoleFile") and user.id : "S-1-5-18") and not (process.name : "msiexec.exe" and user.id : "S-1-5-18") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Execution via Scheduled Task + +Scheduled tasks in Windows automate routine tasks, but adversaries exploit them for persistence and execution of malicious programs. By examining process lineage and command line usage, the detection rule identifies suspicious executions initiated by scheduled tasks. It flags known malicious executables and unusual file paths, while excluding benign processes, to pinpoint potential threats effectively. + +### Possible investigation steps + +- Review the process lineage to confirm the parent process is "svchost.exe" with arguments containing "Schedule" to verify the execution was initiated by a scheduled task. +- Examine the command line arguments and file paths of the suspicious process to identify any unusual or unauthorized file locations, such as those listed in the query (e.g., "C:\\Users\\*", "C:\\ProgramData\\*"). +- Check the original file name of the process against the list of known suspicious executables (e.g., "PowerShell.EXE", "Cmd.Exe") to determine if it matches any commonly abused binaries. +- Investigate the user context under which the process was executed, especially if it deviates from expected system accounts or known service accounts. +- Correlate the event with other security logs or alerts to identify any related suspicious activities or patterns that might indicate a broader attack campaign. +- Assess the risk and impact of the detected activity by considering the severity and risk score provided, and determine if immediate containment or remediation actions are necessary. + +### False positive analysis + +- Scheduled tasks running legitimate scripts or executables like cmd.exe or cscript.exe in system directories may trigger false positives. To manage this, create exceptions for these processes when they are executed from known safe directories such as C:\\Windows\\System32. +- PowerShell scripts executed by the system account (S-1-5-18) for administrative tasks can be mistakenly flagged. Exclude these by specifying exceptions for PowerShell executions with arguments like -File or -PSConsoleFile when run by the system account. +- Legitimate software installations or updates using msiexec.exe by the system account may be incorrectly identified as threats. Mitigate this by excluding msiexec.exe processes initiated by the system account. +- Regular maintenance tasks or scripts stored in common directories like C:\\ProgramData or C:\\Windows\\Temp might be flagged. Review these tasks and exclude known benign scripts or executables from these paths. +- Custom scripts or administrative tools that mimic suspicious executables (e.g., PowerShell.EXE, RUNDLL32.EXE) but are part of routine operations should be reviewed and excluded if verified as safe. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further spread of any potential malicious activity. +- Terminate any suspicious processes identified by the detection rule, especially those matching the flagged executables and paths. +- Conduct a thorough review of scheduled tasks on the affected system to identify and disable any unauthorized or suspicious tasks. +- Remove any malicious files or executables found in the suspicious paths listed in the detection rule. +- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for scheduled tasks and the flagged executables to detect similar threats in the future.""" [[rule.threat]] diff --git a/rules/windows/persistence_suspicious_service_created_registry.toml b/rules/windows/persistence_suspicious_service_created_registry.toml index 491958437d6..7d579168ba3 100644 --- a/rules/windows/persistence_suspicious_service_created_registry.toml +++ b/rules/windows/persistence_suspicious_service_created_registry.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/23" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -45,6 +45,41 @@ registry where host.os.type == "windows" and event.type == "change" and /* add suspicious registry ImagePath values here */ registry.data.strings : ("%COMSPEC%*", "*\\.\\pipe\\*") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious ImagePath Service Creation + +Windows services are crucial for running background processes. Adversaries exploit this by creating or modifying services with malicious ImagePath values to gain persistence or escalate privileges. The detection rule monitors registry changes to ImagePath entries, flagging unusual patterns like command shells or named pipes, which are often used in stealthy attacks. This helps identify and mitigate potential threats early. + +### Possible investigation steps + +- Review the registry event logs to identify the specific ImagePath value that triggered the alert, focusing on entries with command shells or named pipes, such as those containing "%COMSPEC%*" or "*\\\\.\\\\pipe\\\\*". +- Investigate the associated service name and description in the registry path "HKLM\\\\SYSTEM\\\\ControlSet*\\\\Services\\\\*\\\\ImagePath" to determine if it is a legitimate service or potentially malicious. +- Check the creation or modification timestamp of the suspicious ImagePath entry to correlate with other system events or user activities around the same time. +- Analyze the parent process and user account responsible for the registry change to assess if it aligns with expected behavior or if it indicates unauthorized access. +- Search for related network activity or connections, especially those involving named pipes, to identify any lateral movement or data exfiltration attempts. +- Cross-reference the alert with threat intelligence sources to determine if the ImagePath value or associated service is linked to known malware or adversary techniques. + +### False positive analysis + +- Legitimate software updates or installations may modify ImagePath values, triggering alerts. Users can create exceptions for known software update processes to reduce noise. +- System administrators might intentionally change service configurations for maintenance or optimization. Document and exclude these planned changes to prevent false positives. +- Some enterprise applications use named pipes for inter-process communication, which could be flagged. Identify and whitelist these applications to avoid unnecessary alerts. +- Security tools or scripts that automate service management might alter ImagePath values. Ensure these tools are recognized and excluded from monitoring to minimize false alerts. +- Regularly review and update the list of exceptions to ensure they align with current organizational practices and software environments. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes associated with the identified ImagePath values, such as those involving command shells or named pipes. +- Remove or disable the malicious service by reverting the ImagePath registry entry to its legitimate state or deleting the service if it is not required. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional threats or malware. +- Review and restore any modified system files or configurations to their original state to ensure system integrity. +- 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 enhanced monitoring and logging for similar registry changes and suspicious service creations to detect and respond to future threats promptly.""" [[rule.threat]] diff --git a/rules/windows/persistence_sysmon_wmi_event_subscription.toml b/rules/windows/persistence_sysmon_wmi_event_subscription.toml index 3a2b3cca798..6610a755f23 100644 --- a/rules/windows/persistence_sysmon_wmi_event_subscription.toml +++ b/rules/windows/persistence_sysmon_wmi_event_subscription.toml @@ -2,7 +2,7 @@ creation_date = "2023/02/02" integration = ["windows", "endpoint"] maturity = "production" -updated_date = "2024/12/23" +updated_date = "2025/01/10" min_stack_version = "8.15.0" min_stack_comments = "Elastic Defend WMI events were added in Elastic Defend 8.15.0." @@ -45,6 +45,40 @@ any where process.Ext.api.parameters.consumer_type in ("ActiveScriptEventConsumer", "CommandLineEventConsumer")) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious WMI Event Subscription Created + +Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. It allows for event subscriptions that can trigger actions based on system events. Adversaries exploit this for persistence by creating event subscriptions that execute malicious scripts or commands. The detection rule identifies such abuse by monitoring specific event codes and API calls related to the creation of suspicious WMI event consumers, flagging potential threats. + +### Possible investigation steps + +- Review the event logs for event code 21 in the windows.sysmon_operational dataset to identify the specific WMI event subscription created, focusing on the winlog.event_data.Operation and winlog.event_data.Consumer fields. +- Examine the process details associated with the IWbemServices::PutInstance API call in the endpoint.events.api dataset, particularly the process.Ext.api.parameters.consumer_type, to determine the nature of the consumer created. +- Investigate the source and context of the command or script associated with the CommandLineEventConsumer or ActiveScriptEventConsumer to assess its legitimacy and potential malicious intent. +- Check for any related processes or activities around the time of the event to identify potential lateral movement or further persistence mechanisms. +- Correlate the findings with other security alerts or logs to determine if this event is part of a broader attack pattern or campaign. + +### False positive analysis + +- Legitimate administrative scripts or tools may create WMI event subscriptions for system monitoring or automation. Review the source and context of the event to determine if it aligns with known administrative activities. +- Software installations or updates might use WMI event subscriptions as part of their setup or configuration processes. Verify if the event coincides with recent software changes and consider excluding these specific events if they are routine. +- Security software or management tools often use WMI for legitimate purposes. Identify and document these tools in your environment, and create exceptions for their known behaviors to reduce noise. +- Scheduled tasks or system maintenance scripts may trigger similar events. Cross-reference with scheduled task logs or maintenance windows to confirm if these are expected activities. +- Custom scripts developed in-house for system management might inadvertently match the detection criteria. Ensure these scripts are documented and consider excluding their specific signatures from the rule. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes associated with the WMI event subscription, specifically those linked to CommandLineEventConsumer or ActiveScriptEventConsumer. +- Remove the malicious WMI event subscription by using WMI management tools or scripts to delete the identified event consumer. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional threats. +- Review and reset any compromised credentials, especially if SYSTEM privileges were potentially accessed or escalated. +- Monitor the network for any signs of similar activity or attempts to recreate the WMI event subscription, using enhanced logging and alerting mechanisms. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] diff --git a/rules/windows/persistence_temp_scheduled_task.toml b/rules/windows/persistence_temp_scheduled_task.toml index a23aede04b4..42eecac8317 100644 --- a/rules/windows/persistence_temp_scheduled_task.toml +++ b/rules/windows/persistence_temp_scheduled_task.toml @@ -2,7 +2,7 @@ creation_date = "2022/08/29" integration = ["system", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -37,6 +37,40 @@ sequence by winlog.computer_name, winlog.event_data.TaskName with maxspan=5m [iam where event.action == "scheduled-task-created" and not user.name : "*$"] [iam where event.action == "scheduled-task-deleted" and not user.name : "*$"] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Temporarily Scheduled Task Creation + +Scheduled tasks in Windows environments automate routine tasks, but adversaries exploit them for persistence and execution by creating and quickly deleting tasks to mask malicious activity. The detection rule identifies such behavior by tracking task creation and deletion within a short timeframe, flagging potential misuse when these actions occur in rapid succession without typical user patterns. + +### Possible investigation steps + +- Review the winlog.computer_name field to identify the affected system and determine if it is a critical asset or part of a sensitive network segment. +- Examine the winlog.event_data.TaskName to understand the nature of the task created and deleted, and assess if it aligns with known legitimate tasks or appears suspicious. +- Investigate the user.name associated with the task creation and deletion events to determine if the activity was performed by a legitimate user or potentially compromised account. +- Check for any related events or logs around the same timeframe on the affected system to identify any additional suspicious activities or anomalies. +- Correlate the task creation and deletion events with other security alerts or incidents to determine if this activity is part of a broader attack campaign or isolated incident. + +### False positive analysis + +- Routine administrative tasks may trigger the rule if system administrators frequently create and delete scheduled tasks for maintenance purposes. To manage this, create exceptions for known administrative accounts or specific task names that are part of regular operations. +- Automated scripts or software updates that temporarily create scheduled tasks can also cause false positives. Identify these scripts or update processes and exclude their associated user accounts or task names from the detection rule. +- Some legitimate applications may use scheduled tasks for temporary operations. Review application documentation to confirm such behavior and exclude these applications by their task names or associated user accounts. +- In environments with frequent testing or development activities, developers might create and delete tasks as part of their workflow. Consider excluding developer accounts or specific task names used in testing environments to reduce noise. +- Scheduled tasks created by monitoring or security tools for short-lived operations can be mistaken for malicious activity. Verify these tools' behavior and exclude their task names or user accounts if they are known to be safe. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Review the scheduled task details, including the task name and associated scripts or executables, to identify any malicious payloads or commands. +- Terminate any malicious processes or executables identified from the scheduled task analysis to stop ongoing threats. +- Restore any altered or deleted system files from a known good backup to ensure system integrity. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malware. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if other systems are affected. +- Implement additional monitoring and alerting for similar scheduled task activities to enhance detection and prevent recurrence of this threat.""" [[rule.threat]] diff --git a/rules/windows/persistence_user_account_creation_event_logs.toml b/rules/windows/persistence_user_account_creation_event_logs.toml index 316984f9db8..e9e4ea36162 100644 --- a/rules/windows/persistence_user_account_creation_event_logs.toml +++ b/rules/windows/persistence_user_account_creation_event_logs.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/04" integration = ["system", "windows"] maturity = "development" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -34,6 +34,41 @@ query = ''' event.module:("system" or "security") and winlog.api:"wineventlog" and (event.code:"4720" or event.action:"added-user-account") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Windows User Account Creation + +Windows user accounts are essential for managing access and permissions within a system or domain. Adversaries may exploit this by creating unauthorized accounts to maintain persistence or escalate privileges. The detection rule leverages event logs, specifically targeting account creation events, to identify suspicious activities. By monitoring these logs, security analysts can detect and respond to potential threats effectively. + +### Possible investigation steps + +- Review the event logs for event.code "4720" or event.action "added-user-account" to identify the specific account creation event. +- Determine the source of the account creation by examining the event.module field to see if it originated from the "system" or "security" module. +- Identify the user account that initiated the account creation by checking the associated user information in the event logs. +- Investigate the context around the time of the account creation event, such as other related events or anomalies, to assess if it aligns with normal administrative activities. +- Check for any recent privilege escalation activities or changes in user permissions that might be associated with the newly created account. +- Correlate the account creation event with other security alerts or logs to identify potential patterns of malicious behavior or persistence tactics. + +### False positive analysis + +- Routine administrative tasks may trigger account creation events. Regularly review and document legitimate administrative activities to differentiate them from suspicious actions. +- Automated scripts or software installations that create user accounts can generate false positives. Identify and whitelist these processes to prevent unnecessary alerts. +- Temporary accounts for contractors or short-term projects might be flagged. Implement a naming convention for such accounts and exclude them from alerts based on this pattern. +- System updates or patches that involve account creation could be misinterpreted as threats. Monitor update schedules and correlate them with account creation events to verify legitimacy. +- Accounts created by trusted third-party management tools should be recognized and excluded. Maintain an updated list of these tools and configure exceptions accordingly. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Review the newly created user account details, including the username, creation time, and associated privileges, to assess the potential impact and scope of the threat. +- Disable or delete the unauthorized user account to eliminate the adversary's persistence mechanism. +- Conduct a thorough review of recent account creation logs and correlate with other security events to identify any additional unauthorized accounts or related suspicious activities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Implement enhanced monitoring and alerting for account creation events, focusing on unusual patterns or deviations from normal behavior to improve early detection of similar threats. +- Review and update access control policies and user account management procedures to prevent unauthorized account creation and ensure adherence to the principle of least privilege.""" [[rule.threat]] diff --git a/rules/windows/persistence_via_application_shimming.toml b/rules/windows/persistence_via_application_shimming.toml index bd2dc22911a..f8ee49d894a 100644 --- a/rules/windows/persistence_via_application_shimming.toml +++ b/rules/windows/persistence_via_application_shimming.toml @@ -2,7 +2,7 @@ creation_date = "2020/02/18" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2024/11/02" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -53,6 +53,41 @@ process where host.os.type == "windows" and event.type == "start" and process.na not (process.args : "-m" and process.args : "-bg") and not process.args : "-mm" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Application Shimming via Sdbinst + +Application shimming is a Windows feature designed to ensure software compatibility across different OS versions. However, attackers exploit this by using the `sdbinst.exe` tool to execute malicious code under the guise of legitimate processes, achieving persistence. The detection rule identifies suspicious invocations of `sdbinst.exe` by filtering out benign arguments, flagging potential misuse for further investigation. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of sdbinst.exe with suspicious arguments that do not include the benign flags -m, -bg, or -mm. +- Investigate the parent process of sdbinst.exe to determine if it is a legitimate and expected process or if it is potentially malicious. +- Check the timeline of events around the execution of sdbinst.exe to identify any related or preceding suspicious activities, such as unusual file modifications or network connections. +- Analyze the user account associated with the execution of sdbinst.exe to verify if it is a legitimate user and if there are any signs of account compromise. +- Examine the system for any newly installed or modified application compatibility databases (.sdb files) that could be associated with the suspicious execution of sdbinst.exe. +- Correlate the alert with other security tools and logs, such as Microsoft Defender for Endpoint or Sysmon, to gather additional context and confirm the presence of malicious activity. + +### False positive analysis + +- Legitimate software installations or updates may trigger sdbinst.exe with arguments that are not typically malicious. Users should verify the source and purpose of the software to determine if it is expected behavior. +- System administrators might use sdbinst.exe for deploying compatibility fixes across an organization. In such cases, document these activities and create exceptions for known administrative tasks. +- Some enterprise applications may use sdbinst.exe as part of their normal operation. Identify these applications and exclude their specific command-line arguments from triggering alerts. +- Scheduled tasks or scripts that include sdbinst.exe for maintenance purposes can be a source of false positives. Review these tasks and scripts, and whitelist them if they are part of routine operations. +- Regularly review and update the list of exceptions to ensure that only verified and necessary exclusions are maintained, minimizing the risk of overlooking genuine threats. + +### Response and remediation + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes associated with `sdbinst.exe` that do not match known legitimate usage patterns. +- Remove any unauthorized or suspicious application compatibility databases (.sdb files) that may have been installed using `sdbinst.exe`. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious files or persistence mechanisms. +- Review and restore any altered system configurations or registry settings to their default or secure state. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for `sdbinst.exe` executions across the network to detect and respond to future attempts at application shimming.""" [[rule.threat]] diff --git a/rules/windows/persistence_via_bits_job_notify_command.toml b/rules/windows/persistence_via_bits_job_notify_command.toml index 42a345b965a..be0f8640ba2 100644 --- a/rules/windows/persistence_via_bits_job_notify_command.toml +++ b/rules/windows/persistence_via_bits_job_notify_command.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "windows", "sentinel_one_cloud_funnel", "m365_defende maturity = "production" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." min_stack_version = "8.14.0" -updated_date = "2024/10/15" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -40,6 +40,42 @@ process where host.os.type == "windows" and event.type == "start" and "?:\\Windows\\System32\\wermgr.exe", "?:\\WINDOWS\\system32\\directxdatabaseupdater.exe") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Persistence via BITS Job Notify Cmdline + +Background Intelligent Transfer Service (BITS) is a Windows service that facilitates asynchronous, prioritized, and throttled transfer of files between machines. Adversaries exploit BITS by using the SetNotifyCmdLine method to execute malicious programs post-transfer, achieving persistence. The detection rule identifies suspicious processes initiated by BITS, excluding known legitimate executables, to flag potential abuse. + +### Possible investigation steps + +- Review the process details to confirm the parent process is "svchost.exe" with arguments containing "BITS" to ensure the alert is not a false positive. +- Examine the process executable path to verify it is not one of the known legitimate executables listed in the exclusion criteria. +- Investigate the command line arguments of the suspicious process to identify any potentially malicious or unusual commands being executed. +- Check the file hash and signature of the suspicious executable to determine if it is known malware or a legitimate application. +- Analyze the network activity associated with the process to identify any suspicious connections or data transfers that may indicate malicious behavior. +- Review the system's event logs for any additional context or related events that could provide insight into the persistence mechanism or the adversary's actions. +- Assess the affected system for any other signs of compromise or persistence mechanisms that may have been employed by the adversary. + +### False positive analysis + +- Legitimate system processes or updates may occasionally trigger the rule if they are not included in the exclusion list. Regularly review and update the exclusion list to include any new legitimate executables that are identified. +- Some third-party software may use BITS for legitimate purposes, such as software updates or data synchronization. Identify these applications and consider adding their executables to the exclusion list to prevent false positives. +- Scheduled tasks or scripts that utilize BITS for file transfers might be flagged. Verify the legitimacy of these tasks and, if deemed safe, exclude their associated executables from the detection rule. +- In environments where custom scripts or administrative tools are used, ensure that these are documented and, if necessary, excluded from the rule to avoid unnecessary alerts. +- Monitor the frequency and context of alerts to identify patterns that may indicate benign activity. Use this information to refine the rule and reduce false positives without compromising security. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified as being initiated by BITS that are not part of the known legitimate executables list. +- Conduct a thorough review of the BITS job configurations on the affected system to identify and remove any unauthorized or suspicious jobs. +- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised. +- Update and run a full antivirus and anti-malware scan on the affected system to ensure no additional threats are present. +- Review and enhance endpoint protection policies to prevent unauthorized use of BITS for persistence, ensuring that only trusted applications can create or modify BITS jobs. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/persistence_via_hidden_run_key_valuename.toml b/rules/windows/persistence_via_hidden_run_key_valuename.toml index 88ed115ee77..03993645c3b 100644 --- a/rules/windows/persistence_via_hidden_run_key_valuename.toml +++ b/rules/windows/persistence_via_hidden_run_key_valuename.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/15" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -62,6 +62,41 @@ registry where host.os.type == "windows" and event.type == "change" and length(r "\\REGISTRY\\USER\\*\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\", "\\REGISTRY\\MACHINE\\Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\Explorer\\Run\\") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Persistence via Hidden Run Key Detected + +The Windows Registry is a critical system database that stores configuration settings. Adversaries exploit it for persistence by creating hidden registry keys using native APIs, making them invisible to standard tools like regedit. The detection rule identifies changes in specific registry paths associated with startup programs, flagging null-terminated keys that suggest stealthy persistence tactics. + +### Possible investigation steps + +- Review the specific registry path where the change was detected to determine if it matches any of the paths listed in the query, such as "HKEY_USERS\\\\*\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run\\\\" or "HKLM\\\\Software\\\\Microsoft\\\\Windows\\\\CurrentVersion\\\\Run\\\\". +- Check the timestamp of the registry change event to correlate it with other system activities or user actions that occurred around the same time. +- Investigate the process that made the registry change by examining process creation logs or using tools like Sysmon to identify the responsible process and its parent process. +- Analyze the content of the registry key value that was modified or created to determine if it points to a legitimate application or a potentially malicious executable. +- Cross-reference the detected registry change with known threat intelligence sources to identify if the key or value is associated with known malware or adversary techniques. +- Assess the affected system for additional indicators of compromise, such as unusual network connections, file modifications, or other persistence mechanisms. + +### False positive analysis + +- Legitimate software installations or updates may create registry keys in the specified paths, leading to false positives. Users can monitor the installation process and temporarily disable the rule during known software updates to prevent unnecessary alerts. +- System administrators may intentionally configure startup programs for maintenance or monitoring purposes. Document these configurations and create exceptions in the detection rule to avoid flagging them as threats. +- Some security software may use similar techniques to ensure their components start with the system. Verify the legitimacy of such software and whitelist their registry changes to prevent false alarms. +- Custom scripts or automation tools used within an organization might modify registry keys for operational reasons. Identify these scripts and exclude their activities from the detection rule to reduce false positives. +- Regularly review and update the list of known safe applications and processes that interact with the registry paths in question, ensuring that the detection rule remains relevant and accurate. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Use a trusted tool to manually inspect and remove the hidden registry keys identified in the alert from the specified registry paths to eliminate the persistence mechanism. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or processes associated with the threat. +- Review recent user activity and system logs to identify any unauthorized access or changes made by the adversary, and reset credentials for any compromised accounts. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring on the affected system and similar endpoints to detect any recurrence of the threat, focusing on registry changes and process execution. +- Update and reinforce endpoint security configurations to prevent similar persistence techniques, such as enabling registry auditing and restricting access to critical registry paths.""" [[rule.threat]] diff --git a/rules/windows/persistence_via_lsa_security_support_provider_registry.toml b/rules/windows/persistence_via_lsa_security_support_provider_registry.toml index 7a3c8569eb7..6a14303762f 100644 --- a/rules/windows/persistence_via_lsa_security_support_provider_registry.toml +++ b/rules/windows/persistence_via_lsa_security_support_provider_registry.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/18" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -47,6 +47,41 @@ registry where host.os.type == "windows" and event.type == "change" and ) and not process.executable : ("C:\\Windows\\System32\\msiexec.exe", "C:\\Windows\\SysWOW64\\msiexec.exe") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Installation of Security Support Provider + +Security Support Providers (SSPs) in Windows environments facilitate authentication processes. Adversaries may exploit SSPs by modifying registry entries to maintain persistence or evade defenses. The detection rule identifies suspicious changes to specific registry paths associated with SSPs, excluding legitimate processes like msiexec.exe, to flag potential unauthorized modifications indicative of malicious activity. + +### Possible investigation steps + +- Review the registry change event details to identify the specific registry path that was modified, focusing on paths related to "HKLM\\SYSTEM\\*ControlSet*\\Control\\Lsa\\Security Packages" and "HKLM\\SYSTEM\\*ControlSet*\\Control\\Lsa\\OSConfig\\Security Packages". +- Investigate the process responsible for the registry modification by examining the process executable path, ensuring it is not a legitimate process like "C:\\Windows\\System32\\msiexec.exe" or "C:\\Windows\\SysWOW64\\msiexec.exe". +- Check the historical activity of the identified process to determine if it has been involved in other suspicious activities or registry changes. +- Analyze the user account context under which the process was executed to assess if it aligns with expected behavior or if it indicates potential compromise. +- Correlate the event with other security alerts or logs from data sources such as Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender for Endpoint, or SentinelOne to gather additional context and identify any related malicious activity. +- Evaluate the potential impact of the registry change on system security and persistence mechanisms, considering the MITRE ATT&CK tactic of Persistence and technique T1547. + +### False positive analysis + +- Legitimate software installations or updates may trigger registry changes in SSP paths. Users can create exceptions for known software installers or updaters that frequently modify these registry entries. +- System administrators performing routine maintenance or configuration changes might inadvertently cause registry modifications. Document and exclude these activities when they are verified as non-threatening. +- Security software updates, including those from Microsoft or third-party vendors, may alter SSP configurations as part of their normal operation. Monitor and whitelist these updates to prevent false alerts. +- Automated deployment tools or scripts that modify system settings could lead to false positives. Ensure these tools are accounted for and excluded if they are part of regular operations. +- Custom scripts or applications developed in-house that interact with SSP registry paths should be reviewed and excluded if they are deemed safe and necessary for business operations. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes that are not whitelisted, especially those modifying the registry paths associated with Security Support Providers. +- Restore the modified registry entries to their original state using a known good backup or by manually correcting the entries to remove unauthorized changes. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious software or artifacts. +- Review and update access controls and permissions to ensure that only authorized personnel can modify critical registry paths related to Security Support Providers. +- Monitor the affected system and network for any signs of re-infection or further suspicious activity, focusing on registry changes and process executions. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.""" [[rule.threat]] diff --git a/rules/windows/persistence_via_telemetrycontroller_scheduledtask_hijack.toml b/rules/windows/persistence_via_telemetrycontroller_scheduledtask_hijack.toml index 93aef1c28b4..20ed84dce90 100644 --- a/rules/windows/persistence_via_telemetrycontroller_scheduledtask_hijack.toml +++ b/rules/windows/persistence_via_telemetrycontroller_scheduledtask_hijack.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/17" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2024/11/02" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -58,6 +58,41 @@ process where host.os.type == "windows" and event.type == "start" and "rundll32.exe", "powershell.exe") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Persistence via TelemetryController Scheduled Task Hijack + +The Microsoft Compatibility Appraiser, part of Windows telemetry, uses scheduled tasks to assess system compatibility. Adversaries exploit this by hijacking the task to execute malicious code with system-level privileges, ensuring persistence. The detection rule identifies anomalies by monitoring processes initiated by the Appraiser that deviate from expected behavior, flagging potential hijacks for further investigation. + +### Possible investigation steps + +- Review the process tree to identify the parent process CompatTelRunner.exe and verify if it has spawned any unexpected child processes that match the alert criteria. +- Examine the command-line arguments of the suspicious process to determine if they include the "-cv*" flag, which may indicate a hijack attempt. +- Check the execution history of the flagged process to see if it aligns with legitimate system activities or if it appears anomalous. +- Investigate the user account context under which the suspicious process is running to assess if it has elevated privileges or is associated with unusual user behavior. +- Correlate the alert with other security logs and telemetry data from sources like Microsoft Defender for Endpoint or Sysmon to identify any related malicious activities or indicators of compromise. +- Analyze any network connections initiated by the suspicious process to detect potential data exfiltration or communication with known malicious IP addresses. +- Review recent changes to scheduled tasks on the system to identify unauthorized modifications that could indicate persistence mechanisms. + +### False positive analysis + +- Legitimate system maintenance tasks may trigger the rule if they involve processes that are not typically associated with the Microsoft Compatibility Appraiser. Users can create exceptions for known maintenance scripts or tools that are verified as safe. +- Software updates or installations that temporarily use unusual processes under the Appraiser's context might be flagged. Users should monitor and whitelist these processes if they are part of a trusted update or installation routine. +- Custom scripts or administrative tools that leverage the Appraiser's context for legitimate purposes could be misidentified. Users should document and exclude these scripts from detection if they are part of regular administrative operations. +- Security tools or monitoring software that interact with the Appraiser process for analysis or logging purposes may cause false positives. Users should ensure these tools are recognized and excluded from the detection rule to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified by the detection rule that are not part of the expected process list, such as those not matching "conhost.exe", "DeviceCensus.exe", "CompatTelRunner.exe", "DismHost.exe", "rundll32.exe", or "powershell.exe". +- Review and restore the integrity of the Microsoft Compatibility Appraiser scheduled task by resetting it to its default configuration to ensure it is not executing unauthorized code. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional malicious files or software. +- Analyze the system for any unauthorized changes to user accounts or privileges, and revert any modifications to ensure that only legitimate users have access. +- 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 enhanced monitoring and logging for the affected system and similar scheduled tasks across the network to detect any future attempts at hijacking or unauthorized modifications.""" [[rule.threat]] diff --git a/rules/windows/persistence_via_windows_management_instrumentation_event_subscription.toml b/rules/windows/persistence_via_windows_management_instrumentation_event_subscription.toml index c174b2eed5e..9dec899f8fe 100644 --- a/rules/windows/persistence_via_windows_management_instrumentation_event_subscription.toml +++ b/rules/windows/persistence_via_windows_management_instrumentation_event_subscription.toml @@ -2,7 +2,7 @@ creation_date = "2020/12/04" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2024/11/02" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -55,6 +55,39 @@ process where host.os.type == "windows" and event.type == "start" and process.args : "create" and process.args : ("ActiveScriptEventConsumer", "CommandLineEventConsumer") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Persistence via WMI Event Subscription + +Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. Adversaries exploit WMI by creating event subscriptions that trigger malicious code execution, ensuring persistence. The detection rule identifies suspicious use of `wmic.exe` to create event consumers, signaling potential abuse of WMI for persistence by monitoring specific process activities and arguments. + +### Possible investigation steps + +- Review the process execution details for `wmic.exe` to confirm the presence of suspicious arguments such as "create", "ActiveScriptEventConsumer", or "CommandLineEventConsumer" that indicate potential WMI event subscription abuse. +- Examine the parent process of `wmic.exe` to determine how it was launched and assess whether this aligns with expected behavior or if it suggests malicious activity. +- Investigate the user account associated with the `wmic.exe` process to determine if it has the necessary privileges to create WMI event subscriptions and whether the account activity is consistent with normal operations. +- Check for any recent changes or additions to WMI event filters, consumers, or bindings on the affected system to identify unauthorized modifications that could indicate persistence mechanisms. +- Correlate the alert with other security events or logs from data sources like Microsoft Defender for Endpoint or Sysmon to gather additional context and identify any related suspicious activities or patterns. + +### False positive analysis + +- Legitimate administrative tasks using wmic.exe may trigger the rule, such as system monitoring or configuration changes. To handle this, identify and document routine administrative scripts and exclude them from triggering alerts. +- Software installations or updates that use WMI for legitimate event subscriptions can be mistaken for malicious activity. Maintain a list of trusted software and their expected behaviors to create exceptions in the detection rule. +- Automated system management tools that rely on WMI for event handling might cause false positives. Review and whitelist these tools by verifying their source and purpose to prevent unnecessary alerts. +- Security software or monitoring solutions that utilize WMI for legitimate purposes can be flagged. Collaborate with IT and security teams to identify these tools and adjust the rule to exclude their known benign activities. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes related to `wmic.exe` that are identified as creating event consumers, specifically those involving "ActiveScriptEventConsumer" or "CommandLineEventConsumer". +- Remove any unauthorized WMI event subscriptions by using tools like `wevtutil` or PowerShell scripts to list and delete suspicious event filters, consumers, and bindings. +- Conduct a thorough review of the system's WMI repository to ensure no other malicious or unauthorized configurations exist. +- Restore the system from a known good backup if the integrity of the system is compromised and cannot be assured through manual remediation. +- Update and patch the system to the latest security standards to mitigate any vulnerabilities that may have been exploited. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/persistence_werfault_reflectdebugger.toml b/rules/windows/persistence_werfault_reflectdebugger.toml index b798b066051..ee355aab4c6 100644 --- a/rules/windows/persistence_werfault_reflectdebugger.toml +++ b/rules/windows/persistence_werfault_reflectdebugger.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/29" integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -43,6 +43,40 @@ registry where host.os.type == "windows" and event.type == "change" and "MACHINE\\Software\\Microsoft\\Windows\\Windows Error Reporting\\Hangs\\ReflectDebugger" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Werfault ReflectDebugger Persistence + +Werfault, the Windows Error Reporting service, can be manipulated by attackers to maintain persistence. By registering a ReflectDebugger, adversaries can execute malicious code whenever Werfault is triggered with specific parameters. The detection rule monitors registry changes in key paths associated with ReflectDebugger, alerting on unauthorized modifications indicative of potential abuse. + +### Possible investigation steps + +- Review the registry change event details to identify the specific path modified, focusing on the paths listed in the query: "HKLM\\Software\\Microsoft\\Windows\\Windows Error Reporting\\Hangs\\ReflectDebugger", "\\REGISTRY\\MACHINE\\Software\\Microsoft\\Windows\\Windows Error Reporting\\Hangs\\ReflectDebugger", or "MACHINE\\Software\\Microsoft\\Windows\\Windows Error Reporting\\Hangs\\ReflectDebugger". +- Check the timestamp of the registry change event to determine when the modification occurred and correlate it with other suspicious activities or events on the system around the same time. +- Investigate the user account or process responsible for the registry change to assess whether it is a legitimate action or potentially malicious. Look for unusual or unauthorized accounts making the change. +- Examine the system for any recent executions of Werfault with the "-pr" parameter, as this could indicate attempts to trigger the malicious payload. +- Search for any related alerts or logs from data sources such as Elastic Endgame, Elastic Defend, Microsoft Defender for Endpoint, SentinelOne, or Sysmon that might provide additional context or corroborate the suspicious activity. +- Assess the system for any signs of compromise or persistence mechanisms, such as unexpected startup items, scheduled tasks, or other registry modifications that could indicate a broader attack. + +### False positive analysis + +- Legitimate software installations or updates may modify the ReflectDebugger registry key as part of their error reporting configuration. Users can create exceptions for known software vendors by verifying the digital signature of the executable associated with the change. +- System administrators may intentionally configure the ReflectDebugger for debugging purposes. Document and whitelist these changes in the security monitoring system to prevent unnecessary alerts. +- Automated system maintenance tools might interact with the ReflectDebugger registry key. Identify and exclude these tools by correlating the registry changes with scheduled maintenance activities. +- Security software or endpoint protection solutions may alter the ReflectDebugger settings as part of their protective measures. Confirm these changes with the security vendor and add them to the exclusion list if deemed safe. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further execution of malicious code via the Werfault ReflectDebugger. +- Terminate any suspicious processes associated with Werfault that are running with the "-pr" parameter to halt potential malicious activity. +- Remove unauthorized entries from the registry path "HKLM\\Software\\Microsoft\\Windows\\Windows Error Reporting\\Hangs\\ReflectDebugger" to eliminate persistence mechanisms. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection tools to identify and remove any additional malware or malicious artifacts. +- Review and restore any system or application configurations that may have been altered by the attacker to their original state. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected. +- Implement enhanced monitoring and alerting for registry changes in the specified paths to detect and respond to similar threats in the future.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_create_process_as_different_user.toml b/rules/windows/privilege_escalation_create_process_as_different_user.toml index ffaaf3a68b9..9874bd76eec 100644 --- a/rules/windows/privilege_escalation_create_process_as_different_user.toml +++ b/rules/windows/privilege_escalation_create_process_as_different_user.toml @@ -2,7 +2,7 @@ creation_date = "2022/08/30" integration = ["system", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -46,6 +46,40 @@ sequence by winlog.computer_name with maxspan=1m [process where event.type == "start"] by winlog.event_data.TargetLogonId ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Process Creation via Secondary Logon + +The Secondary Logon service in Windows allows users to run processes with different credentials, facilitating legitimate administrative tasks. However, adversaries can exploit this to escalate privileges by creating processes with alternate tokens, bypassing access controls. The detection rule identifies such abuse by monitoring successful logins via the Secondary Logon service and subsequent process creation, linking them through unique logon identifiers. + +### Possible investigation steps + +- Review the event logs for the specific TargetLogonId to identify the user account associated with the process creation and verify if the account is authorized to use alternate credentials. +- Examine the source IP address "::1" to confirm if the process creation originated from the local machine, which might indicate a local privilege escalation attempt. +- Investigate the process name "svchost.exe" to determine if it is being used legitimately or if it has been exploited for malicious purposes, such as running unauthorized services. +- Check the sequence of events within the 1-minute maxspan to identify any unusual or suspicious activities that occurred immediately before or after the process creation. +- Correlate the detected activity with other security alerts or logs to identify any patterns or additional indicators of compromise that might suggest a broader attack campaign. + +### False positive analysis + +- Legitimate administrative tasks using the Secondary Logon service can trigger alerts. To manage this, identify and whitelist specific administrative accounts or tasks that frequently use this service for legitimate purposes. +- Scheduled tasks or automated scripts that use alternate credentials for routine operations may cause false positives. Review and exclude these tasks by creating exceptions for known scripts or scheduled jobs. +- Internal IT support activities often involve using alternate credentials for troubleshooting or maintenance. Document and exclude these activities by maintaining a list of support personnel and their typical actions. +- Software updates or installations that require elevated privileges might be flagged. Monitor and exclude these processes by identifying and documenting the update mechanisms used within the organization. +- Development or testing environments where alternate credentials are used for testing purposes can generate alerts. Exclude these environments by setting up specific rules that recognize and ignore these non-production activities. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified as being created via the Secondary Logon service, especially those linked to the unique logon identifiers from the alert. +- Review and revoke any alternate credentials or tokens used in the suspicious process creation to prevent further misuse. +- Conduct a thorough examination of the affected system for additional signs of compromise, such as unauthorized user accounts or changes to system configurations. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the full scope of the breach. +- Implement stricter access controls and monitoring on the Secondary Logon service to detect and prevent similar privilege escalation attempts in the future. +- Update and reinforce endpoint detection and response (EDR) solutions to enhance monitoring of process creation events and logon activities, ensuring they are aligned with the latest threat intelligence.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_create_process_with_token_unpriv.toml b/rules/windows/privilege_escalation_create_process_with_token_unpriv.toml index ffd8fd02012..a1dabec0a54 100644 --- a/rules/windows/privilege_escalation_create_process_with_token_unpriv.toml +++ b/rules/windows/privilege_escalation_create_process_with_token_unpriv.toml @@ -2,7 +2,7 @@ creation_date = "2023/10/02" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -58,6 +58,41 @@ process where host.os.type == "windows" and event.action == "start" and not (process.Ext.effective_parent.executable : "?:\\Windows\\explorer.exe" and process.parent.executable : ("?:\\Windows\\System32\\svchost.exe", "?:\\Windows\\System32\\msiexec.exe", "?:\\Windows\\twain_32\\*.exe")) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Process Created with a Duplicated Token + +In Windows environments, tokens are used to represent user credentials and permissions. Adversaries may duplicate tokens to create processes with elevated privileges, bypassing security controls. The detection rule identifies suspicious process creation by examining token usage patterns, process origins, and recent file modifications, while excluding known legitimate behaviors, to flag potential privilege escalation attempts. + +### Possible investigation steps + +- Review the process name and executable path to determine if it matches any known legitimate applications or if it is potentially malicious. Pay special attention to processes like powershell.exe, cmd.exe, and rundll32.exe. +- Examine the parent process and its executable path to understand the process hierarchy and identify any unusual or unexpected parent-child relationships, especially if the parent is not a typical system process. +- Check the user ID associated with the process to verify if it belongs to a legitimate user or if it appears to be an anomaly, such as a service account being used unexpectedly. +- Investigate the code signature status of the process to determine if it is trusted or if there are any issues like an expired or untrusted signature, which could indicate tampering or a malicious executable. +- Analyze the relative file creation and modification times to assess if the process was created or modified recently, which could suggest a recent compromise or unauthorized change. +- Look for any known exclusions in the query, such as specific command lines or parent processes, to ensure the alert is not a false positive based on legitimate behavior patterns. + +### False positive analysis + +- Processes initiated by legitimate system maintenance tools like Windows Update or system repair utilities may trigger the rule. Users can create exceptions for these processes by excluding specific parent-child process relationships that are known to be safe. +- Software installations or updates that involve temporary elevation of privileges might be flagged. Users should consider excluding processes originating from trusted directories like Program Files or Program Files (x86) if they are part of a verified installation or update process. +- Administrative scripts or automation tools that run with elevated privileges could be misidentified. Users can exclude these by specifying trusted code signatures or known script paths in the rule configuration. +- Certain legitimate applications that frequently update or modify files within a short time frame may be mistakenly flagged. Users can adjust the relative file creation or modification time thresholds or exclude specific applications by their executable paths. +- Processes that are part of normal user activity, such as those initiated by explorer.exe, may be incorrectly identified. Users can refine the rule by excluding processes with known benign parent-child relationships involving explorer.exe. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, especially those with duplicated tokens or originating from unexpected parent processes. +- Conduct a thorough review of user accounts and privileges on the affected system to identify any unauthorized changes or escalations. Revoke any unnecessary or suspicious privileges. +- Perform a comprehensive scan of the affected system using updated antivirus and anti-malware tools to detect and remove any malicious software or scripts. +- Review recent file modifications and system logs to identify any additional indicators of compromise or unauthorized activities that may have occurred. +- Restore any altered or corrupted system files from a known good backup to ensure system integrity and functionality. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or accounts have been compromised.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_credroaming_ldap.toml b/rules/windows/privilege_escalation_credroaming_ldap.toml index 2595cb73e58..4499d2c19e9 100644 --- a/rules/windows/privilege_escalation_credroaming_ldap.toml +++ b/rules/windows/privilege_escalation_credroaming_ldap.toml @@ -2,7 +2,7 @@ creation_date = "2022/11/09" integration = ["system", "windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -60,6 +60,41 @@ event.action:("Directory Service Changes" or "directory-service-object-modified" winlog.event_data.AttributeLDAPDisplayName:"msPKIAccountCredentials" and winlog.event_data.OperationType:"%%14674" and not winlog.event_data.SubjectUserSid : "S-1-5-18" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Modification of the msPKIAccountCredentials + +The msPKIAccountCredentials attribute in Active Directory stores encrypted credential data, including private keys and certificates. Adversaries may exploit this by altering the attribute to escalate privileges, potentially overwriting files. The detection rule identifies such modifications by monitoring specific directory service events, focusing on changes to this attribute, excluding actions by the system account, thus highlighting unauthorized access attempts. + +### Possible investigation steps + +- Review the event logs for the specific event code 5136 to gather details about the modification event, including the timestamp and the user account involved. +- Examine the winlog.event_data.SubjectUserSid field to identify the user who attempted the modification, ensuring it is not the system account (S-1-5-18). +- Investigate the history and behavior of the identified user account to determine if there are any previous suspicious activities or anomalies. +- Check for any recent changes or anomalies in the affected Active Directory User Object, focusing on the msPKIAccountCredentials attribute. +- Assess the potential impact of the modification by identifying any files or systems that may have been affected by the altered credentials. +- Correlate this event with other security alerts or logs to identify any patterns or coordinated activities that might indicate a broader attack. + +### False positive analysis + +- Routine administrative tasks by IT personnel may trigger the rule. To manage this, create exceptions for specific user accounts or groups known to perform these tasks regularly. +- Scheduled maintenance scripts or automated processes that modify Active Directory attributes could be mistaken for unauthorized changes. Identify these processes and exclude their associated user accounts or service accounts from the rule. +- Software updates or installations that require changes to user credentials might cause false positives. Document these events and adjust the rule to ignore modifications during known update windows. +- Legitimate changes made by third-party applications integrated with Active Directory can be flagged. Review and whitelist these applications by excluding their associated user accounts or service accounts. +- Temporary changes during incident response or security audits may appear suspicious. Coordinate with security teams to ensure these activities are recognized and excluded from triggering alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Revoke any potentially compromised certificates and private keys associated with the affected msPKIAccountCredentials attribute to prevent misuse. +- Conduct a thorough review of recent changes in Active Directory, focusing on the msPKIAccountCredentials attribute, to identify any unauthorized modifications or access patterns. +- Reset passwords and regenerate keys for any accounts or services that may have been affected to ensure that compromised credentials are no longer valid. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the full scope of the breach. +- Implement additional monitoring on the affected systems and accounts to detect any further suspicious activity or attempts to exploit similar vulnerabilities. +- Review and update access controls and permissions in Active Directory to ensure that only authorized personnel have the ability to modify sensitive attributes like msPKIAccountCredentials.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_dns_serverlevelplugindll.toml b/rules/windows/privilege_escalation_dns_serverlevelplugindll.toml index a6e2874c53a..25df3ece26b 100644 --- a/rules/windows/privilege_escalation_dns_serverlevelplugindll.toml +++ b/rules/windows/privilege_escalation_dns_serverlevelplugindll.toml @@ -2,7 +2,7 @@ creation_date = "2024/05/29" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -43,6 +43,42 @@ any where host.os.type == "windows" and event.category : ("library", "process") not ?dll.code_signature.trusted == true and not file.code_signature.status == "Valid" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Unsigned DLL loaded by DNS Service + +The DNS service in Windows environments is crucial for resolving domain names to IP addresses. It can be extended via DLLs, which, if unsigned, may indicate tampering. Adversaries exploit this by loading malicious DLLs to gain elevated privileges or execute code with SYSTEM rights. The detection rule identifies such threats by monitoring the DNS process for loading untrusted DLLs, flagging potential privilege escalation attempts. + +### Possible investigation steps + +- Review the alert details to identify the specific DLL file that was loaded by the DNS service and check its file path and name for any known malicious indicators. +- Examine the file's code signature status and metadata to determine why it is not trusted or valid, and cross-reference with known trusted sources or databases. +- Investigate the process tree of dns.exe to identify any parent or child processes that may indicate how the unsigned DLL was introduced or executed. +- Check the system's event logs for any recent changes or anomalies around the time the DLL was loaded, focusing on events related to process creation, file modification, or user account activity. +- Analyze network traffic logs for any unusual DNS queries or outbound connections that could suggest communication with a command and control server. +- Assess the system for other signs of compromise, such as unauthorized user accounts, scheduled tasks, or registry changes that could indicate further exploitation or persistence mechanisms. +- If possible, isolate the affected system to prevent further potential malicious activity and begin remediation steps based on the findings. + +### False positive analysis + +- Legitimate software updates or patches may introduce new DLLs that are unsigned. Verify the source of the update and, if trusted, create an exception for these DLLs to prevent future alerts. +- Custom or in-house applications might use unsigned DLLs for specific functionalities. Confirm the legitimacy of these applications and add them to an allowlist to avoid unnecessary alerts. +- Some third-party security or monitoring tools may load unsigned DLLs as part of their operation. Validate these tools with your security team and configure exceptions for known, safe DLLs. +- Development or testing environments often use unsigned DLLs during the software development lifecycle. Ensure these environments are properly segmented and consider excluding them from this rule to reduce noise. +- Legacy systems might rely on older, unsigned DLLs that are still in use. Conduct a risk assessment and, if deemed safe, exclude these DLLs from triggering alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary. +- Terminate the DNS service process (dns.exe) to stop the execution of the malicious DLL and prevent further potential damage. +- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to identify and remove any additional malicious files or software. +- Restore the DNS service to its original state by replacing the compromised DLL with a legitimate, signed version from a trusted source or backup. +- Review and update the system's security patches and configurations to address any vulnerabilities that may have been exploited, particularly those related to privilege escalation. +- Monitor the system and network for any signs of continued or repeated unauthorized activity, focusing on similar indicators of compromise. +- Report the incident to the appropriate internal security team or external authorities if required, providing details of the threat and actions taken for further investigation and response.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_expired_driver_loaded.toml b/rules/windows/privilege_escalation_expired_driver_loaded.toml index 5026c5b0606..fcd932fc921 100644 --- a/rules/windows/privilege_escalation_expired_driver_loaded.toml +++ b/rules/windows/privilege_escalation_expired_driver_loaded.toml @@ -2,7 +2,7 @@ creation_date = "2023/06/26" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -36,6 +36,40 @@ query = ''' driver where host.os.type == "windows" and process.pid == 4 and dll.code_signature.status : ("errorExpired", "errorRevoked") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Expired or Revoked Driver Loaded +In Windows environments, drivers facilitate communication between the OS and hardware. Adversaries exploit vulnerabilities in outdated drivers or misuse revoked certificates to execute malicious code in kernel mode, bypassing security controls. The detection rule identifies such threats by monitoring for drivers with expired or revoked signatures, focusing on processes critical to system integrity, thus flagging potential privilege escalation or defense evasion attempts. + +### Possible investigation steps + +- Review the alert details to confirm the presence of a driver with an expired or revoked signature, focusing on the process with PID 4, which is typically the System process in Windows. +- Investigate the specific driver file that triggered the alert by checking its file path, hash, and any associated metadata to determine its origin and legitimacy. +- Cross-reference the driver file against known vulnerability databases and security advisories to identify any known exploits associated with it. +- Examine recent system logs and security events for any unusual activities or attempts to load other drivers around the same time as the alert. +- Assess the system for any signs of privilege escalation or defense evasion, such as unauthorized access attempts or changes to security settings. +- If the driver is confirmed to be malicious or suspicious, isolate the affected system to prevent further compromise and initiate a detailed forensic analysis. + +### False positive analysis + +- Legitimate software updates may load drivers with expired or revoked signatures temporarily. Verify the source and purpose of the driver before excluding it. +- Some older hardware devices may rely on drivers that have expired signatures but are still necessary for functionality. Confirm the device's necessity and consider excluding these drivers if they are from a trusted source. +- Security software or system management tools might use drivers with expired signatures for legitimate operations. Validate the software's legitimacy and add exceptions for these drivers if they are verified as safe. +- Custom or in-house developed drivers might not have updated signatures. Ensure these drivers are from a trusted internal source and consider excluding them if they are essential for operations. +- Test environments may intentionally use expired or revoked drivers for research or development purposes. Clearly document these cases and exclude them to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary. +- Terminate any processes associated with the expired or revoked driver to halt any ongoing malicious activity. +- Conduct a thorough review of the system to identify any unauthorized changes or additional malicious drivers that may have been loaded. +- Revoke any compromised certificates and update the certificate trust list to prevent future misuse. +- Apply the latest security patches and driver updates to close any vulnerabilities that may have been exploited. +- Restore the system from a known good backup if any unauthorized changes or persistent threats are detected. +- Escalate the incident to the security operations center (SOC) for further analysis and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_exploit_cve_202238028.toml b/rules/windows/privilege_escalation_exploit_cve_202238028.toml index 3d234029f7e..b416904bb8e 100644 --- a/rules/windows/privilege_escalation_exploit_cve_202238028.toml +++ b/rules/windows/privilege_escalation_exploit_cve_202238028.toml @@ -2,7 +2,7 @@ creation_date = "2024/04/23" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -43,6 +43,41 @@ file where host.os.type == "windows" and event.type != "deletion" and "?:\\*\\Windows\\WinSxS\\amd64_microsoft-windows-printing-printtopdf_*\\MPDW-constraints.js" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 privilege escalation via CVE-2022-38028 + +CVE-2022-38028 targets the Windows Print Spooler service, a core component managing print jobs. Adversaries exploit this by manipulating specific JavaScript files within system directories to gain elevated privileges. The detection rule identifies unauthorized file presence in critical paths, signaling potential exploitation attempts, leveraging multiple data sources for comprehensive threat detection. + +### Possible investigation steps + +- Review the alert details to confirm the presence of the file "MPDW-constraints.js" in the specified critical paths: "?:\\\\*\\\\Windows\\\\system32\\\\DriVerStoRe\\\\FiLeRePoSiToRy\\\\*\\\\MPDW-constraints.js" or "?:\\\\*\\\\Windows\\\\WinSxS\\\\amd64_microsoft-windows-printing-printtopdf_*\\\\MPDW-constraints.js". +- Check the file creation and modification timestamps to determine when the file was placed or altered in the system directories. +- Investigate the source of the file by examining recent user activity and process execution logs around the time the file appeared, focusing on any suspicious or unauthorized actions. +- Correlate the event with other data sources such as Sysmon, Microsoft Defender for Endpoint, or SentinelOne to identify any related suspicious activities or processes that might indicate exploitation attempts. +- Assess the risk and impact by determining if the affected system has any sensitive roles or access that could be leveraged by an attacker through privilege escalation. +- If malicious activity is confirmed, initiate containment measures such as isolating the affected system and conducting a full malware scan to prevent further exploitation. + +### False positive analysis + +- Legitimate software updates or installations may place JavaScript files in the monitored directories. Verify the source and integrity of the software to ensure it is from a trusted vendor. +- System administrators or automated scripts might deploy or modify JavaScript files in these paths for legitimate configuration purposes. Review change management logs to confirm authorized activities. +- Security tools or system maintenance processes could temporarily create or modify files in these directories. Cross-reference with scheduled tasks or security tool logs to validate these actions. +- Exclude known benign applications or processes that frequently interact with the specified file paths by creating exceptions in the detection rule to reduce noise. +- Regularly update the detection rule to incorporate new intelligence on false positives, ensuring it remains effective and relevant. + +### Response and remediation + +- Isolate the affected system from the network immediately to prevent further exploitation or lateral movement by the adversary. +- Terminate any suspicious processes related to the Windows Print Spooler service to halt ongoing exploitation attempts. +- Remove unauthorized JavaScript files, specifically "MPDW-constraints.js", from the identified critical paths to eliminate the immediate threat. +- Apply the latest security patches and updates from Microsoft to address CVE-2022-38028 and ensure the system is protected against known vulnerabilities. +- Conduct a thorough review of user accounts and privileges on the affected system to identify and revoke any unauthorized privilege escalations. +- Monitor the network and system logs for any signs of further exploitation attempts or related suspicious activities, using enhanced detection rules. +- Report the incident to the appropriate internal security team or external authorities if required, providing detailed information about the exploitation attempt and actions taken.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_gpo_schtask_service_creation.toml b/rules/windows/privilege_escalation_gpo_schtask_service_creation.toml index 1b27f5b2e7c..3b34bff3439 100644 --- a/rules/windows/privilege_escalation_gpo_schtask_service_creation.toml +++ b/rules/windows/privilege_escalation_gpo_schtask_service_creation.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/13" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -45,6 +45,41 @@ file where host.os.type == "windows" and event.type != "deletion" and event.acti ) and not process.executable : "C:\\Windows\\System32\\dfsrs.exe" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Creation or Modification of a new GPO Scheduled Task or Service + +Group Policy Objects (GPOs) are crucial for centralized management in Windows environments, allowing administrators to configure settings across domain-joined machines. Adversaries with domain admin rights can exploit GPOs to create or modify scheduled tasks or services, deploying malicious payloads network-wide. The detection rule identifies such activities by monitoring specific file changes in GPO paths, excluding legitimate system processes, thus highlighting potential abuse for privilege escalation or persistence. + +### Possible investigation steps + +- Review the file path and name to confirm if the changes were made to "ScheduledTasks.xml" or "Services.xml" within the specified GPO paths, as these are indicative of potential unauthorized modifications. +- Check the process that initiated the file change, ensuring it is not "C:\\\\Windows\\\\System32\\\\dfsrs.exe", which is excluded as a legitimate system process. +- Investigate the user account associated with the file modification event to determine if it has domain admin rights and assess if the activity aligns with their typical behavior or role. +- Examine recent changes in the GPO settings to identify any new or altered scheduled tasks or services that could be used for malicious purposes. +- Correlate the event with other security logs or alerts from data sources like Elastic Endgame, Sysmon, or Microsoft Defender for Endpoint to identify any related suspicious activities or patterns. +- Assess the impact by identifying which domain-joined machines are affected by the GPO changes and determine if any unauthorized tasks or services have been executed. + +### False positive analysis + +- Legitimate administrative changes to GPOs can trigger alerts. Regularly review and document scheduled administrative tasks to differentiate between expected and unexpected changes. +- Automated system management tools may modify GPO scheduled tasks or services as part of routine operations. Identify these tools and create exceptions for their processes to reduce noise. +- Updates or patches from Microsoft or other trusted vendors might alter GPO settings. Monitor update schedules and correlate changes with known update activities to verify legitimacy. +- Internal IT scripts or processes that manage GPOs for configuration consistency can cause false positives. Ensure these scripts are well-documented and consider excluding their specific actions from monitoring. +- Temporary changes made by IT staff for troubleshooting or testing purposes can be mistaken for malicious activity. Implement a change management process to log and approve such activities, allowing for easy exclusion from alerts. + +### Response and remediation + +- Immediately isolate affected systems from the network to prevent further spread of any malicious payloads deployed via the modified GPO scheduled tasks or services. +- Revoke domain admin privileges from any accounts that are suspected of being compromised to prevent further unauthorized modifications to GPOs. +- Conduct a thorough review of the modified ScheduledTasks.xml and Services.xml files to identify any unauthorized or malicious entries, and revert them to their previous legitimate state. +- Utilize endpoint detection and response (EDR) tools to scan for and remove any malicious payloads that may have been executed on domain-joined machines as a result of the GPO modifications. +- Notify the security operations center (SOC) and escalate the incident to the incident response team for further investigation and to determine the scope of the compromise. +- Implement additional monitoring on GPO paths and domain admin activities to detect any further unauthorized changes or suspicious behavior. +- Review and strengthen access controls and auditing policies for GPO management to prevent unauthorized modifications in the future.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_krbrelayup_service_creation.toml b/rules/windows/privilege_escalation_krbrelayup_service_creation.toml index c2ba7fc2038..f76fee68a41 100644 --- a/rules/windows/privilege_escalation_krbrelayup_service_creation.toml +++ b/rules/windows/privilege_escalation_krbrelayup_service_creation.toml @@ -2,7 +2,7 @@ creation_date = "2022/04/27" integration = ["system", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -54,6 +54,39 @@ sequence by winlog.computer_name with maxspan=5m /* event 4697 need to be logged */ event.action : "service-installed"] by winlog.event_data.SubjectLogonId ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Service Creation via Local Kerberos Authentication + +Kerberos is a network authentication protocol designed to provide strong authentication for client/server applications. In Windows environments, it is often used for secure identity verification. Adversaries may exploit Kerberos by relaying authentication tickets locally to escalate privileges, potentially creating services with elevated rights. The detection rule identifies suspicious local logons using Kerberos, followed by service creation, indicating possible misuse. By monitoring specific logon events and service installations, it helps detect unauthorized privilege escalation attempts. + +### Possible investigation steps + +- Review the event logs for the specific LogonId identified in the alert to gather details about the logon session, including the user account involved and the time of the logon event. +- Examine the source IP address and port from the logon event to confirm it matches the localhost (127.0.0.1 or ::1) and determine if this aligns with expected behavior for the user or system. +- Investigate the service creation event (event ID 4697) associated with the same LogonId to identify the service name, executable path, and any related command-line arguments to assess if it is legitimate or potentially malicious. +- Check for any recent changes or anomalies in the system or user account, such as modifications to user privileges, group memberships, or recent software installations, that could indicate unauthorized activity. +- Correlate the findings with other security alerts or logs from the same timeframe to identify any patterns or additional indicators of compromise that may suggest a broader attack or compromise. + +### False positive analysis + +- Routine administrative tasks may trigger the rule if administrators frequently log in locally using Kerberos and create services as part of their duties. To manage this, create exceptions for known administrative accounts or specific service creation activities that are part of regular maintenance. +- Automated scripts or software updates that use Kerberos authentication and subsequently install or update services can also generate false positives. Identify these scripts or update processes and exclude their associated logon IDs from the rule. +- Security software or monitoring tools that perform regular checks and use Kerberos for authentication might inadvertently trigger the rule. Review the behavior of these tools and whitelist their activities if they are verified as non-threatening. +- In environments where localhost is used for testing or development purposes, developers might log in using Kerberos and create services. Consider excluding specific development machines or user accounts from the rule to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or privilege escalation. +- Terminate any suspicious services created during the incident to halt potential malicious activities. +- Conduct a thorough review of the affected system's event logs, focusing on the specific LogonId and service creation events to identify the scope of the compromise. +- Reset the credentials of the compromised user account and any other accounts that may have been accessed using the relayed Kerberos tickets. +- Apply patches and updates to the affected system and any other systems in the network to address known vulnerabilities that could be exploited in similar attacks. +- Implement network segmentation to limit the ability of attackers to move laterally within the network, reducing the risk of privilege escalation. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts are undertaken.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_lsa_auth_package.toml b/rules/windows/privilege_escalation_lsa_auth_package.toml index 73c5572df3c..ebffcb765c5 100644 --- a/rules/windows/privilege_escalation_lsa_auth_package.toml +++ b/rules/windows/privilege_escalation_lsa_auth_package.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/21" integration = ["endpoint", "m365_defender"] maturity = "production" -updated_date = "2024/10/10" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -40,6 +40,40 @@ registry where host.os.type == "windows" and event.type == "change" and /* exclude SYSTEM SID - look for changes by non-SYSTEM user */ not user.id : "S-1-5-18" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 LSA Authentication Package Abuse + +The Local Security Authority (LSA) in Windows manages authentication and security policies. Adversaries exploit LSA by modifying registry paths to include malicious binaries, which are executed with SYSTEM privileges during authentication package loading. The detection rule identifies unauthorized registry changes by non-SYSTEM users, signaling potential privilege escalation or persistence attempts. + +### Possible investigation steps + +- Review the registry change event details to identify the specific binary path added to the LSA Authentication Packages registry key. +- Investigate the user account associated with the registry change event to determine if it is a legitimate user or potentially compromised. +- Check the timestamp of the registry modification to correlate with any other suspicious activities or events on the system around the same time. +- Analyze the binary referenced in the registry change for any known malicious signatures or behaviors using antivirus or threat intelligence tools. +- Examine system logs and security events for any signs of privilege escalation or persistence techniques used by the adversary. +- Assess the system for any additional unauthorized changes or indicators of compromise that may suggest further malicious activity. + +### False positive analysis + +- Legitimate software installations or updates may modify the LSA authentication package registry path. Users should verify if recent installations or updates coincide with the detected changes and consider excluding these specific software processes if they are deemed safe. +- System administrators or IT management tools might perform authorized changes to the registry for maintenance or configuration purposes. Users can create exceptions for known administrative tools or processes that are regularly used for legitimate system management tasks. +- Security software or endpoint protection solutions may alter the registry as part of their normal operation. Users should identify and whitelist these security applications to prevent unnecessary alerts. +- Custom scripts or automation tools used within the organization might inadvertently trigger this rule. Users should review and document these scripts, ensuring they are secure, and exclude them if they are confirmed to be non-threatening. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes associated with the unauthorized registry change to halt potential malicious activity. +- Restore the modified registry path to its original state by removing any unauthorized entries in the LSA Authentication Packages registry key. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious binaries or remnants. +- Review and reset credentials for any accounts that may have been compromised, focusing on those with elevated privileges. +- 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 enhanced monitoring and logging for registry changes, particularly those involving LSA authentication packages, to detect and respond to similar threats in the future.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_make_token_local.toml b/rules/windows/privilege_escalation_make_token_local.toml index 087a566beff..23552c3d2a7 100644 --- a/rules/windows/privilege_escalation_make_token_local.toml +++ b/rules/windows/privilege_escalation_make_token_local.toml @@ -2,7 +2,7 @@ creation_date = "2023/12/04" integration = ["system", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -50,6 +50,39 @@ authentication where "?:\\Windows\\System32\\inetsrv\\w3wp.exe", "?:\\Windows\\SysWOW64\\msiexec.exe") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Interactive Logon by an Unusual Process + +Interactive logons in Windows environments typically involve standard processes like winlogon.exe. Adversaries may exploit alternate processes to create tokens, escalating privileges and bypassing controls. This detection rule identifies anomalies by flagging logons via non-standard executables, focusing on mismatched user SIDs and unusual process paths, thus highlighting potential privilege escalation attempts. + +### Possible investigation steps + +- Review the process executable path to determine if it is a known or expected application for interactive logons. Investigate any unfamiliar or suspicious paths. +- Examine the SubjectUserSid and TargetUserSid to identify the users involved in the logon attempt. Check for any discrepancies or unusual patterns in user activity. +- Analyze the event logs around the time of the alert to identify any related or preceding events that might indicate how the unusual process was initiated. +- Investigate the system for any signs of compromise, such as unexpected changes in system files, unauthorized software installations, or other indicators of malicious activity. +- Check for any recent privilege escalation attempts or access token manipulations that might correlate with the alert, using the MITRE ATT&CK framework references for guidance. + +### False positive analysis + +- Legitimate administrative tools or scripts may trigger this rule if they use non-standard executables for logon processes. To manage this, identify and whitelist these known tools by adding their executable paths to the exception list. +- Custom applications developed in-house that require interactive logon might be flagged. Review these applications and, if verified as safe, exclude their executable paths from the detection rule. +- Automated tasks or services that use alternate credentials for legitimate purposes can cause false positives. Analyze these tasks and, if they are part of regular operations, adjust the rule to exclude their specific user SIDs or executable paths. +- Security software or monitoring tools that perform logon actions for scanning or auditing purposes may be incorrectly flagged. Confirm their legitimacy and add them to the exception list to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified as executing from non-standard paths that are not part of the legitimate Windows system processes. +- Revoke any tokens or credentials associated with the anomalous logon session to prevent further misuse. +- Conduct a thorough review of user accounts involved, focusing on any unauthorized privilege escalations or changes in permissions, and reset passwords as necessary. +- Analyze the system for any signs of persistence mechanisms or additional malware, and remove any identified threats. +- Restore the system from a known good backup if any unauthorized changes or malware are detected that cannot be easily remediated. +- Report the incident to the appropriate internal security team or management for further investigation and potential escalation to law enforcement if necessary.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_msi_repair_via_mshelp_link.toml b/rules/windows/privilege_escalation_msi_repair_via_mshelp_link.toml index 61ad9c71af4..21643af5b41 100644 --- a/rules/windows/privilege_escalation_msi_repair_via_mshelp_link.toml +++ b/rules/windows/privilege_escalation_msi_repair_via_mshelp_link.toml @@ -4,7 +4,7 @@ integration = ["endpoint", "sentinel_one_cloud_funnel", "m365_defender", "window maturity = "production" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." min_stack_version = "8.14.0" -updated_date = "2024/10/17" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -51,6 +51,40 @@ process where event.type == "start" and host.os.type == "windows" and "opera.exe", "iexplore", "firefox.exe", "waterfox.exe", "iexplore.exe", "tor.exe", "safari.exe") and process.parent.command_line : "*go.microsoft.com*" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Escalation via Vulnerable MSI Repair + +Windows Installer (MSI) is a service used for software installation and maintenance. Adversaries exploit vulnerabilities in MSI repair functions to gain elevated privileges. This detection rule identifies suspicious activity by monitoring browser processes accessing Microsoft Help pages, followed by elevated process creation, indicating potential privilege escalation attempts. + +### Possible investigation steps + +- Review the alert details to identify the specific browser process that accessed the Microsoft Help page, noting the process name and command line details. +- Check the user domain associated with the process to confirm if it matches "NT AUTHORITY", "AUTORITE NT", or "AUTORIDADE NT", which may indicate a system-level account was used. +- Investigate the parent process of the browser to determine if it was expected or if it shows signs of compromise or unusual behavior. +- Examine the timeline of events to see if an elevated process was spawned shortly after the browser accessed the Microsoft Help page, indicating potential exploitation. +- Correlate the event with other security logs or alerts from data sources like Elastic Endgame, Sysmon, or Microsoft Defender for Endpoint to gather additional context or evidence of malicious activity. +- Assess the risk and impact of the elevated process by identifying its actions and any changes made to the system, such as modifications to critical files or registry keys. + +### False positive analysis + +- Legitimate software updates or installations may trigger the rule if they involve browser-based help documentation. To manage this, identify and whitelist known software update processes that frequently access Microsoft Help pages. +- Automated scripts or administrative tools that use browsers to access Microsoft Help for legitimate purposes can cause false positives. Exclude these scripts or tools by specifying their unique command-line patterns or process names. +- User-initiated troubleshooting or help-seeking behavior that involves accessing Microsoft Help pages might be misinterpreted as suspicious. Educate users on safe browsing practices and consider excluding specific user accounts or domains that are known to frequently engage in such activities. +- Security tools or monitoring solutions that simulate browser activity for testing purposes may inadvertently trigger the rule. Identify these tools and create exceptions based on their process names or command-line arguments to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary. +- Terminate any suspicious elevated processes that were spawned following the browser's navigation to the Microsoft Help page to halt potential privilege escalation activities. +- Conduct a thorough review of the affected system's event logs and process creation history to identify any unauthorized changes or additional indicators of compromise. +- Apply the latest security patches and updates to the Windows Installer service and any other vulnerable components to mitigate the exploited vulnerability. +- Restore the affected system from a known good backup if unauthorized changes or persistent threats are detected that cannot be easily remediated. +- Monitor the network for any signs of similar exploitation attempts or related suspicious activities, using enhanced detection rules and threat intelligence feeds. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation and recovery efforts.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_newcreds_logon_rare_process.toml b/rules/windows/privilege_escalation_newcreds_logon_rare_process.toml index 77e4e70c55a..1a714ad9b13 100644 --- a/rules/windows/privilege_escalation_newcreds_logon_rare_process.toml +++ b/rules/windows/privilege_escalation_newcreds_logon_rare_process.toml @@ -2,7 +2,7 @@ creation_date = "2023/11/15" integration = ["system", "windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -28,6 +28,40 @@ type = "new_terms" query = ''' event.category:"authentication" and host.os.type:"windows" and winlog.logon.type:"NewCredentials" and winlog.event_data.LogonProcessName:(Advapi* or "Advapi ") and not winlog.event_data.SubjectUserName:*$ and not process.executable :???\\Program?Files* ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 First Time Seen NewCredentials Logon Process + +The NewCredentials logon type in Windows allows processes to impersonate a user without requiring a new logon session, often used for legitimate tasks like network resource access. However, adversaries can exploit this by forging access tokens to escalate privileges and bypass controls. The detection rule identifies unusual processes performing this logon type, excluding known system paths and service accounts, to flag potential misuse indicative of token manipulation attacks. + +### Possible investigation steps + +- Review the process executable path to determine if it is a known or expected application, especially since the query excludes common system paths like Program Files. +- Investigate the SubjectUserName to identify the user account associated with the logon event and determine if it is a legitimate user or a potential compromised account. +- Check the historical activity of the identified process and user account to see if this behavior is consistent with past actions or if it is anomalous. +- Correlate the event with other security logs to identify any preceding or subsequent suspicious activities, such as failed logon attempts or unusual network connections. +- Assess the environment for any recent changes or incidents that might explain the unusual logon process, such as software updates or new application deployments. +- Consult threat intelligence sources to determine if the process or behavior is associated with known malicious activity or threat actors. + +### False positive analysis + +- Legitimate administrative tools or scripts may trigger this rule if they use the NewCredentials logon type for network resource access. To manage this, identify and whitelist these tools by their process executable paths. +- Scheduled tasks or automated processes running under service accounts might be flagged. Review these tasks and exclude them by adding exceptions for known service account names. +- Software updates or installations that require elevated privileges could cause false positives. Monitor these activities and create exceptions for the specific processes involved in regular update cycles. +- Custom in-house applications that use impersonation for legitimate purposes may be detected. Work with development teams to document these applications and exclude their process paths from the rule. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified as using the NewCredentials logon type that are not part of known system paths or service accounts. +- Revoke any potentially compromised access tokens and reset credentials for affected user accounts to prevent further misuse. +- Conduct a thorough review of recent logon events and process executions on the affected system to identify any additional unauthorized activities or compromised accounts. +- 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 enhanced monitoring for similar suspicious logon activities across the network to detect and respond to potential future attempts promptly. +- Review and update access control policies and token management practices to mitigate the risk of access token manipulation in the future.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_port_monitor_print_pocessor_abuse.toml b/rules/windows/privilege_escalation_port_monitor_print_pocessor_abuse.toml index a7cba94a807..914e76d5ef2 100644 --- a/rules/windows/privilege_escalation_port_monitor_print_pocessor_abuse.toml +++ b/rules/windows/privilege_escalation_port_monitor_print_pocessor_abuse.toml @@ -2,7 +2,7 @@ creation_date = "2021/01/21" integration = ["endpoint", "m365_defender"] maturity = "production" -updated_date = "2024/10/10" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -43,6 +43,41 @@ registry where host.os.type == "windows" and event.type == "change" and /* exclude SYSTEM SID - look for changes by non-SYSTEM user */ not user.id : "S-1-5-18" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Monitor or Print Processor Registration Abuse + +Port monitors and print processors are integral to Windows printing, managing data flow and processing print jobs. Adversaries exploit these by registering malicious DLLs, which execute with SYSTEM privileges at boot, enabling persistence and privilege escalation. The detection rule identifies registry changes in specific paths, focusing on non-SYSTEM user modifications, to flag potential abuse. + +### Possible investigation steps + +- Review the registry path specified in the alert to confirm the presence of any unauthorized or suspicious DLLs in the paths: HKLM\\SYSTEM\\*ControlSet*\\Control\\Print\\Monitors\\* and HKLM\\SYSTEM\\*ControlSet*\\Control\\Print\\Environments\\Windows*\\Print Processors\\*. +- Identify the user account associated with the registry change by examining the user.id field, ensuring it is not the SYSTEM account (S-1-5-18), and determine if the account has a legitimate reason to modify these registry paths. +- Check the file properties and digital signatures of the DLLs found in the registry paths to verify their legitimacy and identify any anomalies or signs of tampering. +- Investigate the system's event logs around the time of the registry change to gather additional context, such as other activities performed by the same user or related processes that might indicate malicious behavior. +- Conduct a threat intelligence search on the identified DLLs and any associated file hashes to determine if they are known to be associated with malicious activity or threat actors. +- Assess the system for any signs of privilege escalation or persistence mechanisms that may have been established as a result of the registry modification, such as new services or scheduled tasks. + +### False positive analysis + +- Legitimate software installations or updates may modify print processor or port monitor registry paths. Users should verify if recent installations or updates coincide with the detected changes. +- System administrators performing maintenance or configuration changes might trigger alerts. Ensure that such activities are documented and cross-referenced with the alert timestamps. +- Some third-party printing solutions may register their own DLLs in these registry paths. Identify and whitelist these known applications to prevent unnecessary alerts. +- Automated scripts or management tools that modify printer settings could cause false positives. Review and adjust these tools to ensure they operate under expected user accounts or exclude their known behaviors. +- Regularly review and update the exclusion list to include any new benign applications or processes that interact with the monitored registry paths. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Terminate any suspicious processes associated with the malicious DLLs identified in the registry paths to halt their execution. +- Remove the unauthorized DLL entries from the registry paths: HKLM\\SYSTEM\\*ControlSet*\\Control\\Print\\Monitors\\* and HKLM\\SYSTEM\\*ControlSet*\\Control\\Print\\Environments\\Windows*\\Print Processors\\* to eliminate persistence mechanisms. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or remnants. +- Review and reset credentials for any accounts that may have been compromised, especially those with elevated privileges, to prevent unauthorized access. +- Implement application whitelisting to prevent unauthorized DLLs from executing, focusing on the paths identified in the alert. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected, ensuring comprehensive threat containment and eradication.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_printspooler_registry_copyfiles.toml b/rules/windows/privilege_escalation_printspooler_registry_copyfiles.toml index c27dff3ffb8..1582cf363c6 100644 --- a/rules/windows/privilege_escalation_printspooler_registry_copyfiles.toml +++ b/rules/windows/privilege_escalation_printspooler_registry_copyfiles.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/26" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/17" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -53,6 +53,40 @@ sequence by host.id with maxspan=30s ) and registry.data.strings : "C:\\Windows\\System32\\spool\\drivers\\x64\\4\\*"] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Print Spooler Point and Print DLL + +The Windows Print Spooler service manages print jobs and is integral to printing operations. Adversaries exploit vulnerabilities like CVE-2020-1030 to escalate privileges by loading malicious DLLs into the spooler process, which runs with SYSTEM-level permissions. The detection rule identifies suspicious registry modifications linked to the Print Spooler, indicating potential exploitation attempts by monitoring specific registry paths and data patterns. + +### Possible investigation steps + +- Review the registry paths specified in the alert to confirm any unauthorized modifications, focusing on the paths: HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Print\\Printers\\*\\SpoolDirectory and HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Print\\Printers\\*\\CopyFiles\\Payload\\Module. +- Check the registry data strings for any unexpected or suspicious DLLs located in C:\\Windows\\System32\\spool\\drivers\\x64\\4, which may indicate a malicious payload. +- Investigate the host identified by host.id to determine if there are any other signs of compromise or unusual activity, such as unexpected processes or network connections. +- Correlate the alert with other security events or logs from the same host to identify any related activities or patterns that could suggest a broader attack. +- Assess the system's patch level and update status to ensure that all known vulnerabilities, including CVE-2020-1030, have been addressed and mitigated. +- If a malicious DLL is confirmed, isolate the affected system to prevent further exploitation and begin remediation efforts, such as removing the malicious files and restoring the system to a known good state. + +### False positive analysis + +- Legitimate printer driver updates or installations may trigger the rule due to registry modifications in the specified paths. Users can create exceptions for known and trusted driver update processes to prevent false alerts. +- Custom print configurations by IT departments that modify the SpoolDirectory or CopyFiles registry paths might be flagged. Document and exclude these configurations if they are verified as safe and necessary for business operations. +- Automated scripts or software that manage printer settings and inadvertently modify the monitored registry paths can cause false positives. Identify and whitelist these scripts or applications after confirming their legitimacy. +- Third-party print management solutions that interact with the Print Spooler service may lead to false detections. Evaluate these solutions and exclude their known benign activities from the detection rule. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary. +- Terminate the Print Spooler service on the compromised system to stop any ongoing malicious activity and prevent further DLL loading. +- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to identify and remove any malicious DLLs or related files. +- Review and restore the registry paths identified in the detection query to their default values to ensure no malicious configurations remain. +- Apply the latest security patches and updates from Microsoft to address CVE-2020-1030 and other known vulnerabilities in the Print Spooler service. +- Monitor the network for any signs of similar exploitation attempts, focusing on the registry paths and data patterns specified in the detection rule. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_printspooler_service_suspicious_file.toml b/rules/windows/privilege_escalation_printspooler_service_suspicious_file.toml index f43288f064e..d9c5a9ac6fb 100644 --- a/rules/windows/privilege_escalation_printspooler_service_suspicious_file.toml +++ b/rules/windows/privilege_escalation_printspooler_service_suspicious_file.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/14" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -51,6 +51,40 @@ query = ''' event.category : "file" and host.os.type : "windows" and event.type : "creation" and process.name : "spoolsv.exe" and file.extension : "dll" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious PrintSpooler Service Executable File Creation + +The Print Spooler service in Windows manages print jobs, but vulnerabilities like CVE-2020-1048 can be exploited for privilege escalation. Adversaries may create malicious DLL files executed by the spooler to gain elevated privileges. The detection rule identifies such threats by monitoring file creation events linked to the spooler process, focusing on DLL files, which are common vectors for exploitation. + +### Possible investigation steps + +- Review the alert details to confirm the presence of a file creation event with the extension "dll" associated with the "spoolsv.exe" process on a Windows host. +- Check the file path and name of the created DLL to determine if it matches known malicious patterns or locations typically used for exploitation. +- Investigate the source of the spoolsv.exe process by examining the parent process and any associated user accounts to identify potential unauthorized access or activity. +- Analyze recent system logs and security events for any other suspicious activities or anomalies around the time of the DLL creation, such as unexpected user logins or privilege changes. +- Verify the patch status of the affected system against the vulnerabilities CVE-2020-1048, CVE-2020-1337, and CVE-2020-1300 to ensure it is up to date and not susceptible to known exploits. +- If the DLL is confirmed to be malicious, isolate the affected system to prevent further exploitation and begin remediation efforts, including removing the malicious file and any associated threats. + +### False positive analysis + +- Legitimate DLL updates by trusted software can trigger the rule. Users should verify the source of the DLL and, if confirmed safe, add the software's update process to an exception list. +- System maintenance activities, such as Windows updates, may create DLLs that match the rule's criteria. Users can exclude these activities by identifying the associated update processes and adding them to the exception list. +- Custom in-house applications that interact with the Print Spooler service might generate DLLs during normal operation. Users should validate these applications and exclude their file creation events if they are deemed non-threatening. +- Security software or monitoring tools that interact with the Print Spooler service could inadvertently create DLLs. Users should confirm the legitimacy of these tools and configure exceptions for their operations. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary. +- Terminate the spoolsv.exe process if it is confirmed to be executing a malicious DLL, to halt any ongoing malicious activity. +- Remove the malicious DLL file from the system to prevent re-execution and further exploitation. +- Apply the latest security patches and updates to the affected system, specifically addressing CVE-2020-1048, CVE-2020-1337, and CVE-2020-1300, to close the vulnerabilities exploited by the adversary. +- Conduct a thorough review of user accounts and privileges on the affected system to ensure no unauthorized privilege escalation has occurred. +- Monitor the network for any signs of similar exploitation attempts or related suspicious activity, using enhanced logging and alerting mechanisms. +- Report the incident to the appropriate internal security team or external authorities if required, providing details of the exploit and actions taken for further investigation and response.""" [[rule.filters]] [rule.filters.meta] diff --git a/rules/windows/privilege_escalation_printspooler_suspicious_file_deletion.toml b/rules/windows/privilege_escalation_printspooler_suspicious_file_deletion.toml index 65e8bd0d499..b62efa4f950 100644 --- a/rules/windows/privilege_escalation_printspooler_suspicious_file_deletion.toml +++ b/rules/windows/privilege_escalation_printspooler_suspicious_file_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2021/07/06" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -47,6 +47,40 @@ file where host.os.type == "windows" and event.type == "deletion" and file.extension : "dll" and file.path : "?:\\Windows\\System32\\spool\\drivers\\x64\\3\\*.dll" and not process.name : ("spoolsv.exe", "dllhost.exe", "explorer.exe") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Print Spooler File Deletion + +The Print Spooler service in Windows manages print jobs and interactions with printers. Adversaries exploit vulnerabilities in this service to escalate privileges, often deleting print driver files to cover their tracks. The detection rule identifies unusual deletions of these files by processes other than legitimate ones, signaling potential misuse and aiding in early threat detection. + +### Possible investigation steps + +- Review the alert details to identify the specific file path and name of the deleted DLL file within "C:\\Windows\\System32\\spool\\drivers\\x64\\3\\". +- Examine the process responsible for the deletion by checking the process name and its parent process to determine if it is a known legitimate process or a potentially malicious one. +- Investigate the timeline of events around the deletion to identify any preceding or subsequent suspicious activities, such as privilege escalation attempts or unauthorized access. +- Check for any recent vulnerabilities or exploits related to the Print Spooler service that might have been leveraged in this context. +- Correlate the event with other security logs and alerts from data sources like Sysmon, Microsoft Defender for Endpoint, or SentinelOne to gather additional context and confirm the presence of malicious activity. +- Assess the affected system for any signs of compromise or persistence mechanisms that may have been established following the deletion event. + +### False positive analysis + +- System maintenance or updates may trigger legitimate deletions of print driver files. Monitor scheduled maintenance activities and correlate them with detected events to confirm legitimacy. +- Third-party printer management software might delete or update driver files as part of its normal operation. Identify and whitelist these processes if they are verified as non-threatening. +- Custom scripts or administrative tools used by IT staff for printer management could inadvertently match the rule's criteria. Review and document these tools, then create exceptions for known safe operations. +- Automated deployment tools that update or clean up printer drivers across the network might cause false positives. Ensure these tools are recognized and excluded from the detection rule if they are part of routine operations. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified as responsible for the deletion of print driver files, ensuring they are not legitimate system processes. +- Restore the deleted print driver files from a known good backup to ensure the Print Spooler service functions correctly. +- Conduct a thorough review of user accounts and privileges on the affected system to identify and revoke any unauthorized privilege escalations. +- Apply the latest security patches and updates to the Print Spooler service and related components to mitigate known vulnerabilities. +- Monitor the affected system and network for any signs of further suspicious activity, focusing on similar file deletion patterns or privilege escalation attempts. +- Escalate the incident to the security operations center (SOC) or relevant IT security team for further investigation and to assess the need for broader organizational response measures.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_reg_service_imagepath_mod.toml b/rules/windows/privilege_escalation_reg_service_imagepath_mod.toml index fb45da30925..8953e2de71d 100644 --- a/rules/windows/privilege_escalation_reg_service_imagepath_mod.toml +++ b/rules/windows/privilege_escalation_reg_service_imagepath_mod.toml @@ -2,7 +2,7 @@ creation_date = "2024/06/05" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -87,6 +87,41 @@ registry where host.os.type == "windows" and event.type == "change" and process. ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Privilege Escalation via Service ImagePath Modification + +Windows services are crucial for system operations, often running with high privileges. Adversaries exploit this by altering the ImagePath registry key of services to execute malicious code with elevated privileges. The detection rule identifies suspicious modifications to service ImagePaths, focusing on changes that deviate from standard executable paths, thus flagging potential privilege escalation attempts. + +### Possible investigation steps + +- Review the specific registry key and value that triggered the alert to confirm it matches one of the monitored service keys, such as those listed in the query (e.g., *\\LanmanServer, *\\Winmgmt). +- Examine the modified ImagePath value to determine if it points to a non-standard executable path or a suspicious executable, especially those not located in %systemroot%\\system32\\. +- Check the process.executable field to identify the process responsible for the registry modification and assess its legitimacy. +- Investigate the user account associated with the modification event to determine if it has elevated privileges, such as membership in the Server Operators group. +- Correlate the event with other logs or alerts to identify any related suspicious activities, such as unexpected service starts or process executions. +- Review recent changes or activities on the host to identify any unauthorized access or configuration changes that could indicate a broader compromise. + +### False positive analysis + +- Legitimate software updates or installations may modify service ImagePaths. Users can create exceptions for known update processes or installation paths to prevent false positives. +- System administrators might intentionally change service configurations for maintenance or troubleshooting. Document and exclude these changes by adding exceptions for specific administrator actions or paths. +- Custom scripts or automation tools that modify service settings as part of their operation can trigger alerts. Identify and whitelist these scripts or tools to avoid unnecessary alerts. +- Some third-party security or management software may alter service ImagePaths as part of their functionality. Verify the legitimacy of such software and exclude their known paths from detection. +- Changes made by trusted IT personnel during system configuration or optimization should be logged and excluded from alerts to reduce noise. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified as running from non-standard executable paths, especially those not originating from the system32 directory. +- Restore the modified ImagePath registry key to its original state using a known good configuration or backup. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or persistence mechanisms. +- Review and audit user accounts and group memberships, particularly those with elevated privileges like Server Operators, to ensure no unauthorized changes have been made. +- 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 enhanced monitoring and alerting for future modifications to service ImagePath registry keys, focusing on deviations from standard paths to detect similar threats promptly.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_rogue_windir_environment_var.toml b/rules/windows/privilege_escalation_rogue_windir_environment_var.toml index c87668f25ff..3240d6eaba6 100644 --- a/rules/windows/privilege_escalation_rogue_windir_environment_var.toml +++ b/rules/windows/privilege_escalation_rogue_windir_environment_var.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/26" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -52,6 +52,42 @@ registry.path : ( ) and not registry.data.strings : ("C:\\windows", "%SystemRoot%") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Privilege Escalation via Windir Environment Variable + +The Windir environment variable points to the Windows directory, crucial for system operations. Adversaries may alter this variable to redirect processes to malicious directories, gaining elevated privileges. The detection rule monitors changes to this variable in the registry, flagging deviations from expected paths like "C:\\windows," thus identifying potential privilege escalation attempts. + +### Possible investigation steps + +- Review the registry change event details to identify the specific user account associated with the altered Windir or SystemRoot environment variable. This can be done by examining the registry path and user context in the event data. +- Check the registry data strings to determine the new path set for the Windir or SystemRoot variable. Investigate if this path points to a known malicious directory or an unexpected location. +- Correlate the event with other recent registry changes or system events on the same host to identify any patterns or additional suspicious activities that might indicate a broader attack. +- Investigate the process or application that initiated the registry change by reviewing process creation logs or command-line arguments around the time of the event. This can help identify the source of the change. +- Assess the affected system for any signs of compromise or unauthorized access, such as unusual network connections, unexpected running processes, or new user accounts. +- Consult threat intelligence sources to determine if the observed behavior matches any known attack patterns or campaigns, particularly those involving privilege escalation techniques. +- If possible, restore the Windir or SystemRoot environment variable to its expected value and monitor the system for any further unauthorized changes. + +### False positive analysis + +- System updates or patches may temporarily alter the Windir environment variable. Monitor for these events during known maintenance windows and consider excluding them from alerts. +- Custom scripts or applications that modify environment variables for legitimate purposes can trigger false positives. Identify these scripts and whitelist their activity in the detection rule. +- User profile migrations or system restorations might change the Windir path. Exclude these operations if they are part of routine IT processes. +- Virtual environments or sandboxed applications may use different Windir paths. Verify these environments and adjust the detection rule to accommodate their specific configurations. +- Administrative tools that modify user environments for configuration management can cause alerts. Document these tools and create exceptions for their expected behavior. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Revert the Windir environment variable to its legitimate value, typically "C:\\windows", to restore normal system operations. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious software or scripts. +- Review recent user activity and system logs to identify any unauthorized access or changes, focusing on the time frame around the detected registry change. +- Reset passwords for any user accounts that may have been compromised, especially those with elevated privileges. +- 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 enhanced monitoring on the affected system and similar endpoints to detect any further attempts to alter critical environment variables or other suspicious activities.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_samaccountname_spoofing_attack.toml b/rules/windows/privilege_escalation_samaccountname_spoofing_attack.toml index 74ffe84b293..67a5e4854c7 100644 --- a/rules/windows/privilege_escalation_samaccountname_spoofing_attack.toml +++ b/rules/windows/privilege_escalation_samaccountname_spoofing_attack.toml @@ -2,7 +2,7 @@ creation_date = "2021/12/12" integration = ["system", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -55,6 +55,40 @@ iam where event.action == "renamed-user-account" and /* machine account name renamed to user like account name */ winlog.event_data.OldTargetUserName : "*$" and not winlog.event_data.NewTargetUserName : "*$" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Privileged Escalation via SamAccountName Spoofing + +In Active Directory environments, the samAccountName attribute is crucial for identifying user and computer accounts. Adversaries may exploit vulnerabilities like CVE-2021-42278 to spoof this attribute, potentially elevating privileges by renaming computer accounts to mimic domain controllers. The detection rule identifies suspicious renaming events, where a machine account is altered to resemble a user account, signaling possible privilege escalation attempts. + +### Possible investigation steps + +- Review the event logs to confirm the occurrence of a "renamed-user-account" action, focusing on entries where the OldTargetUserName ends with a "$" and the NewTargetUserName does not, indicating a potential spoofing attempt. +- Identify the source of the rename event by examining the event logs for the user or system that initiated the change, and determine if it aligns with expected administrative activity. +- Check the history of the NewTargetUserName to see if it has been used in any recent authentication attempts or privileged operations, which could indicate malicious intent. +- Investigate the associated IP address and hostname from which the rename action was performed to determine if it is a known and trusted source within the network. +- Correlate the event with other security alerts or logs to identify any patterns or additional suspicious activities that might suggest a broader attack campaign. +- Assess the potential impact by determining if the renamed account has been granted elevated privileges or access to sensitive resources since the rename event occurred. + +### False positive analysis + +- Routine administrative tasks involving legitimate renaming of computer accounts can trigger false positives. To manage this, create exceptions for known administrative activities by excluding specific administrator accounts or service accounts from the detection rule. +- Automated processes or scripts that rename computer accounts as part of regular maintenance or deployment procedures may also cause false alerts. Identify these processes and exclude their associated accounts or event patterns from the rule. +- Temporary renaming of computer accounts for troubleshooting or testing purposes can be mistaken for suspicious activity. Document and exclude these temporary changes by maintaining a list of authorized personnel and their activities. +- Changes made by trusted third-party software or management tools that interact with Active Directory should be reviewed and, if deemed safe, excluded from triggering alerts by specifying the tool's account or signature in the rule exceptions. + +### Response and remediation + +- Immediately isolate the affected machine from the network to prevent further unauthorized access or lateral movement within the domain. +- Revert any unauthorized changes to the samAccountName attribute by renaming the affected computer account back to its original name. +- Conduct a thorough review of recent changes in Active Directory, focusing on user and computer account modifications, to identify any other potentially compromised accounts. +- Reset passwords for the affected machine account and any other accounts that may have been accessed or modified during the incident. +- Apply the latest security patches and updates to all domain controllers and critical systems to mitigate vulnerabilities like CVE-2021-42278. +- Enhance monitoring and logging for Active Directory events, specifically focusing on account renaming activities, 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 ensure comprehensive remediation efforts are undertaken.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_suspicious_dnshostname_update.toml b/rules/windows/privilege_escalation_suspicious_dnshostname_update.toml index 100d963e6e4..6b8d0118def 100644 --- a/rules/windows/privilege_escalation_suspicious_dnshostname_update.toml +++ b/rules/windows/privilege_escalation_suspicious_dnshostname_update.toml @@ -2,7 +2,7 @@ creation_date = "2022/05/11" integration = ["system", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -48,6 +48,41 @@ iam where event.action == "changed-computer-account" and user.id : ("S-1-5-21-*" /* exclude FPs where DnsHostName starts with the ComputerName that was changed */ not startswith~(winlog.event_data.DnsHostName, substring(winlog.event_data.TargetUserName, 0, length(winlog.event_data.TargetUserName) - 1)) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Computer Account DnsHostName Update + +In Active Directory environments, the DnsHostName attribute links computer accounts to their DNS names, crucial for network communication. Adversaries may exploit this by altering a non-domain controller's DnsHostName to mimic a domain controller, potentially exploiting vulnerabilities like CVE-2022-26923 for privilege escalation. The detection rule identifies suspicious changes by monitoring for remote updates to this attribute, especially when the new hostname resembles a domain controller's, flagging potential exploitation attempts. + +### Possible investigation steps + +- Review the event logs to confirm the occurrence of the "changed-computer-account" action, focusing on the user.id fields ("S-1-5-21-*", "S-1-12-1-*") to identify the user who initiated the change. +- Verify the new DnsHostName value against the list of legitimate domain controller DNS hostnames to assess if it matches any known domain controllers. +- Check the winlog.event_data.TargetUserName to ensure that the DnsHostName does not start with the computer name that was changed, which could indicate a false positive. +- Investigate the account associated with the user.id to determine if it has a history of suspicious activity or if it has been compromised. +- Examine recent changes or activities on the affected computer account to identify any unauthorized access or configuration changes. +- Correlate this event with other security alerts or logs to identify potential patterns or coordinated activities that might indicate a broader attack. + +### False positive analysis + +- Routine maintenance or updates to computer accounts may trigger the rule if the DnsHostName is temporarily set to a domain controller-like name. To manage this, create exceptions for known maintenance periods or specific administrative accounts performing these updates. +- Automated scripts or tools that update computer account attributes might inadvertently match the rule's conditions. Identify and exclude these scripts or tools by their user IDs or specific patterns in their operations. +- Legitimate changes in network architecture, such as the promotion of a server to a domain controller, could be flagged. Ensure that such changes are documented and create exceptions for the involved accounts or systems during the transition period. +- Temporary testing environments where non-domain controllers are configured with domain controller-like hostnames for testing purposes can cause false positives. Exclude these environments by their specific hostnames or network segments. +- Regularly review and update the list of known domain controller hostnames to ensure that legitimate changes in the network are not mistakenly flagged as suspicious. + +### Response and remediation + +- Immediately isolate the affected computer from the network to prevent further unauthorized changes or potential exploitation. +- Verify the legitimacy of the DnsHostName change by cross-referencing with known domain controller hostnames and authorized change requests. +- Revert any unauthorized changes to the DnsHostName attribute to its original state to restore proper network communication and prevent misuse. +- Conduct a thorough review of recent account activities and permissions for the user account involved in the change to identify any unauthorized access or privilege escalation attempts. +- Escalate the incident to the security operations team for further investigation and to assess potential exploitation of CVE-2022-26923 or other vulnerabilities. +- Implement additional monitoring on the affected system and similar systems to detect any further suspicious activities or attempts to exploit vulnerabilities. +- Review and update access controls and permissions for computer accounts in Active Directory to ensure only authorized personnel can make changes to critical attributes like DnsHostName.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_tokenmanip_sedebugpriv_enabled.toml b/rules/windows/privilege_escalation_tokenmanip_sedebugpriv_enabled.toml index b661cf23c54..4bf6f7109ee 100644 --- a/rules/windows/privilege_escalation_tokenmanip_sedebugpriv_enabled.toml +++ b/rules/windows/privilege_escalation_tokenmanip_sedebugpriv_enabled.toml @@ -2,7 +2,7 @@ creation_date = "2022/10/20" integration = ["windows", "system"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -70,6 +70,41 @@ any where host.os.type == "windows" and event.provider: "Microsoft-Windows-Secur "?:\\Windows\\System32\\wbem\\WmiPrvSe.exe", "?:\\Windows\\SysWOW64\\wbem\\WmiPrvSe.exe") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 SeDebugPrivilege Enabled by a Suspicious Process + +SeDebugPrivilege is a powerful Windows privilege allowing processes to debug and modify other processes, typically reserved for system-level tasks. Adversaries exploit this to escalate privileges, bypassing security controls by impersonating system processes. The detection rule identifies suspicious processes enabling SeDebugPrivilege, excluding known legitimate processes, to flag potential privilege escalation attempts. + +### Possible investigation steps + +- Review the event logs for the specific event.provider "Microsoft-Windows-Security-Auditing" and event.action "Token Right Adjusted Events" to gather more details about the process that enabled SeDebugPrivilege. +- Identify the process name from winlog.event_data.ProcessName and determine if it is known or expected in the environment. Investigate any unknown or suspicious processes. +- Check the winlog.event_data.SubjectUserSid to identify the user account associated with the process. Investigate if this account has a history of suspicious activity or if it should have the ability to enable SeDebugPrivilege. +- Analyze the parent process of the suspicious process to understand how it was initiated and if it was spawned by a legitimate or malicious process. +- Correlate the timestamp of the event with other security events or alerts to identify any related activities or patterns that could indicate a broader attack or compromise. +- Investigate the network activity of the suspicious process to determine if it is communicating with any known malicious IP addresses or domains. + +### False positive analysis + +- Legitimate system maintenance tasks may trigger the rule, such as Windows Update or system diagnostics. Users can monitor the timing of these tasks and correlate them with alerts to determine if they are the cause. +- Software installations or updates using msiexec.exe might be flagged. Consider excluding msiexec.exe from the rule if it is frequently used in your environment for legitimate purposes. +- Administrative tools like taskhostw.exe and mmc.exe can sometimes enable SeDebugPrivilege during normal operations. Evaluate the necessity of these tools in your environment and exclude them if they are regularly used by trusted administrators. +- Temporary files created by legitimate applications, such as DismHost.exe in user temp directories, may be flagged. Review the context of these files and exclude them if they are part of routine application behavior. +- Regularly review and update the exclusion list to include any new legitimate processes that are identified as false positives, ensuring the rule remains effective without generating unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate the suspicious process identified in the alert to stop any ongoing malicious activity and prevent privilege escalation. +- Conduct a thorough review of the affected system's event logs, focusing on the "Token Right Adjusted Events" to identify any additional unauthorized privilege changes or suspicious activities. +- Reset credentials for any accounts that may have been compromised or used by the suspicious process, especially those with elevated privileges. +- Restore the affected system from a known good backup to ensure any malicious changes are removed and the system is returned to a secure state. +- Implement additional monitoring on the affected system and similar systems to detect any recurrence of the threat, focusing on processes attempting to enable SeDebugPrivilege. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_uac_bypass_com_clipup.toml b/rules/windows/privilege_escalation_uac_bypass_com_clipup.toml index fc2f865bcc9..9d183646630 100644 --- a/rules/windows/privilege_escalation_uac_bypass_com_clipup.toml +++ b/rules/windows/privilege_escalation_uac_bypass_com_clipup.toml @@ -2,7 +2,7 @@ creation_date = "2020/10/28" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -43,6 +43,41 @@ process where host.os.type == "windows" and event.type == "start" and process.na /* CLSID of the Elevated COM Interface IEditionUpgradeManager */ process.parent.args : "/Processid:{BD54C901-076B-434E-B6C7-17C531F4AB41}" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 UAC Bypass Attempt with IEditionUpgradeManager Elevated COM Interface + +User Account Control (UAC) is a security feature in Windows designed to prevent unauthorized changes by prompting for elevated permissions. The IEditionUpgradeManager COM interface can be exploited by attackers to bypass UAC, allowing them to execute code with elevated privileges without user consent. This detection rule identifies such attempts by monitoring for the execution of the ClipUp program from non-standard paths, initiated by a specific COM interface, indicating potential misuse for privilege escalation. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of ClipUp.exe running from a non-standard path, as indicated by the process.executable field not matching "C:\\Windows\\System32\\ClipUp.exe". +- Investigate the parent process, dllhost.exe, to determine if it was legitimately initiated or if it shows signs of compromise, focusing on the process.parent.args field to verify the use of the specific COM interface CLSID: /Processid:{BD54C901-076B-434E-B6C7-17C531F4AB41}. +- Check the user account context under which ClipUp.exe was executed to assess if it aligns with expected user behavior or if it suggests unauthorized access. +- Correlate this event with other security logs and alerts from data sources like Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender for Endpoint, or SentinelOne to identify any related suspicious activities or patterns. +- Examine recent changes or anomalies in system configurations or installed software that might indicate preparation for or execution of a UAC bypass attempt. +- If available, review network activity logs for any unusual outbound connections or data exfiltration attempts following the execution of ClipUp.exe. + +### False positive analysis + +- Legitimate software updates or installations may trigger the rule if they temporarily use non-standard paths for ClipUp.exe. Verify the source and purpose of the process to determine if it is part of a legitimate update or installation. +- Custom scripts or administrative tools that utilize ClipUp.exe from non-standard paths for legitimate purposes can cause false positives. Review the script or tool usage and consider excluding these specific paths if they are verified as safe. +- Software testing environments where ClipUp.exe is executed from non-standard paths for testing purposes may trigger the rule. Implement exclusions for known testing environments to prevent unnecessary alerts. +- Automated deployment tools that use ClipUp.exe from non-standard paths as part of their deployment process can be mistaken for malicious activity. Confirm the deployment tool's behavior and add exceptions for its known operations. +- In environments where multiple users have administrative privileges, legitimate administrative actions might inadvertently match the rule's criteria. Regularly audit administrative actions and consider excluding known benign activities. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate the ClipUp.exe process if it is running from a non-standard path to stop any ongoing malicious activity. +- Conduct a thorough review of the system's recent activity logs to identify any additional unauthorized changes or suspicious behavior. +- Restore any altered system files or configurations to their original state using known good backups or system restore points. +- Update and patch the operating system and all installed software to the latest versions to mitigate known vulnerabilities. +- Implement application whitelisting to prevent unauthorized programs from executing, focusing on blocking non-standard paths for critical system executables. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_uac_bypass_com_ieinstal.toml b/rules/windows/privilege_escalation_uac_bypass_com_ieinstal.toml index 216891dbd73..ac5454795a3 100644 --- a/rules/windows/privilege_escalation_uac_bypass_com_ieinstal.toml +++ b/rules/windows/privilege_escalation_uac_bypass_com_ieinstal.toml @@ -2,7 +2,7 @@ creation_date = "2020/11/03" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -45,6 +45,42 @@ process where host.os.type == "windows" and event.type == "start" and /* uncomment once in winlogbeat */ /* and not (process.code_signature.subject_name == "Microsoft Corporation" and process.code_signature.trusted == true) */ ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 UAC Bypass Attempt via Elevated COM Internet Explorer Add-On Installer + +User Account Control (UAC) is a security feature in Windows designed to prevent unauthorized changes by prompting for elevated permissions. Adversaries may exploit elevated COM interfaces, such as the Internet Explorer Add-On Installer, to bypass UAC and execute malicious code with higher privileges. The detection rule identifies suspicious processes originating from temporary directories, launched by the IE installer with specific arguments, indicating potential UAC bypass attempts. + +### Possible investigation steps + +- Review the process details to confirm the executable path matches the pattern "C:\\\\*\\\\AppData\\\\*\\\\Temp\\\\IDC*.tmp\\\\*.exe" and verify if it is expected or known within the environment. +- Investigate the parent process "ieinstal.exe" to determine if its execution is legitimate, checking for any unusual or unexpected usage patterns. +- Examine the command-line arguments used by the parent process, specifically looking for the "-Embedding" argument, to understand the context of its execution. +- Check the code signature of the suspicious process to determine if it is signed by a trusted entity, and assess the trustworthiness of the signature if present. +- Correlate this event with other security alerts or logs from data sources like Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender for Endpoint, or SentinelOne to identify any related malicious activity. +- Investigate the user account associated with the process to determine if there are any signs of compromise or unauthorized access attempts. +- Assess the risk and impact of the potential UAC bypass attempt on the system and broader network, and take appropriate containment or remediation actions if necessary. + +### False positive analysis + +- Legitimate software installations or updates may trigger the rule if they temporarily use the specified directory structure. Users can monitor the frequency and context of these alerts to determine if they align with known software behaviors. +- Development or testing environments might generate alerts due to the execution of scripts or applications from temporary directories. Users can create exceptions for specific environments or processes that are known to be safe. +- System administrators or IT personnel performing legitimate administrative tasks might inadvertently trigger the rule. Users can exclude specific user accounts or processes from monitoring if they are verified as non-threatening. +- Automated software deployment tools that use temporary directories for installation processes may cause false positives. Users can whitelist these tools by verifying their code signatures and adding them to an exception list. +- Regularly review and update the list of trusted applications and processes to ensure that only verified and necessary exceptions are in place, minimizing the risk of overlooking genuine threats. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes identified by the detection rule, specifically those originating from temporary directories and launched by "ieinstal.exe" with the "-Embedding" argument. +- Conduct a thorough review of the affected system to identify any additional unauthorized changes or malware installations, focusing on temporary directories and COM interface usage. +- Restore the system to a known good state using backups or system restore points, ensuring that any malicious changes are reversed. +- Update and patch the affected system to the latest security updates to mitigate known vulnerabilities that could be exploited for UAC bypass. +- Implement application whitelisting to prevent unauthorized executables from running, particularly those in temporary directories. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_uac_bypass_com_interface_icmluautil.toml b/rules/windows/privilege_escalation_uac_bypass_com_interface_icmluautil.toml index 1f75e4522af..4c4e4fdbd13 100644 --- a/rules/windows/privilege_escalation_uac_bypass_com_interface_icmluautil.toml +++ b/rules/windows/privilege_escalation_uac_bypass_com_interface_icmluautil.toml @@ -2,7 +2,7 @@ creation_date = "2020/10/19" integration = ["endpoint", "windows", "m365_defender"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -41,6 +41,41 @@ process where host.os.type == "windows" and event.type == "start" and process.parent.args in ("/Processid:{3E5FC7F9-9A51-4367-9063-A120244FBEC7}", "/Processid:{D2E7041B-2927-42FB-8E9F-7CE93B6DC937}") and process.pe.original_file_name != "WerFault.exe" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 UAC Bypass via ICMLuaUtil Elevated COM Interface + +The ICMLuaUtil Elevated COM Interface is a Windows component that facilitates User Account Control (UAC) operations, allowing certain processes to execute with elevated privileges. Adversaries exploit this by invoking the interface to bypass UAC, executing malicious code stealthily. The detection rule identifies such attempts by monitoring processes initiated by `dllhost.exe` with specific arguments, excluding legitimate processes like `WerFault.exe`, thus flagging potential privilege escalation activities. + +### Possible investigation steps + +- Review the process tree to identify the parent and child processes of the flagged `dllhost.exe` instance to understand the context of its execution. +- Examine the command-line arguments of the `dllhost.exe` process to confirm the presence of the suspicious `/Processid:{3E5FC7F9-9A51-4367-9063-A120244FBEC7}` or `/Processid:{D2E7041B-2927-42FB-8E9F-7CE93B6DC937}` arguments. +- Check for any recent changes or installations on the system that might have introduced the suspicious behavior, focusing on software that might interact with UAC settings. +- Investigate the user account under which the `dllhost.exe` process was executed to determine if it has been compromised or if it has elevated privileges. +- Correlate the event with other security logs or alerts from data sources like Sysmon or Microsoft Defender for Endpoint to identify any related suspicious activities or patterns. +- Assess the network activity of the affected system around the time of the alert to detect any potential data exfiltration or communication with known malicious IP addresses. + +### False positive analysis + +- Legitimate software updates or installations may trigger the rule if they use the ICMLuaUtil Elevated COM Interface for necessary elevation. Users can monitor the specific software involved and create exceptions for trusted applications. +- System maintenance tasks initiated by IT administrators might use similar processes for legitimate purposes. Identifying these tasks and excluding them from the rule can reduce false positives. +- Certain enterprise applications may require elevated privileges and use the same COM interface. Regularly review and whitelist these applications to prevent unnecessary alerts. +- Automated scripts or tools used for system management that invoke the interface should be evaluated. If deemed safe, they can be added to an exclusion list to avoid repeated false positives. +- Regularly update the list of excluded processes to reflect changes in the organization's software environment, ensuring that only non-threatening behaviors are excluded. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes initiated by `dllhost.exe` with the specified arguments to stop the execution of potentially malicious code. +- Conduct a thorough review of the affected system to identify any unauthorized changes or additional malicious files, and remove them. +- Restore the system from a known good backup if any critical system files or configurations have been altered. +- Update and patch the operating system and all installed software to mitigate any known vulnerabilities that could be exploited for UAC bypass. +- Implement application whitelisting to prevent unauthorized applications from executing, focusing on blocking the execution of `dllhost.exe` with suspicious arguments. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_uac_bypass_diskcleanup_hijack.toml b/rules/windows/privilege_escalation_uac_bypass_diskcleanup_hijack.toml index b967a003284..8190711c258 100644 --- a/rules/windows/privilege_escalation_uac_bypass_diskcleanup_hijack.toml +++ b/rules/windows/privilege_escalation_uac_bypass_diskcleanup_hijack.toml @@ -2,7 +2,7 @@ creation_date = "2020/08/18" integration = ["endpoint", "windows", "system", "m365_defender", "sentinel_one_cloud_funnel", "crowdstrike"] maturity = "production" -updated_date = "2024/11/02" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -60,6 +60,42 @@ process where host.os.type == "windows" and event.type == "start" and "\\Device\\HarddiskVolume?\\Windows\\System32\\taskhostw.exe" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 UAC Bypass via DiskCleanup Scheduled Task Hijack + +User Account Control (UAC) is a security feature in Windows that helps prevent unauthorized changes. Adversaries may exploit the DiskCleanup Scheduled Task to bypass UAC, executing code with elevated privileges. The detection rule identifies suspicious processes using specific arguments and executables not matching known safe paths, flagging potential UAC bypass attempts for further investigation. + +### Possible investigation steps + +- Review the process details to confirm the presence of suspicious arguments "/autoclean" and "/d" in the process execution. +- Verify the executable path of the process to ensure it does not match known safe paths such as "C:\\Windows\\System32\\cleanmgr.exe" or "C:\\Windows\\SysWOW64\\cleanmgr.exe". +- Investigate the parent process to determine how the suspicious process was initiated and assess if it was triggered by a legitimate application or script. +- Check the user account under which the process was executed to identify if it aligns with expected user behavior or if it indicates potential compromise. +- Analyze recent system changes or scheduled tasks to identify any unauthorized modifications that could facilitate UAC bypass. +- Correlate the event with other security alerts or logs from data sources like Microsoft Defender for Endpoint or Sysmon to gather additional context on the activity. +- Assess the risk and impact of the event by considering the severity and risk score, and determine if further containment or remediation actions are necessary. + +### False positive analysis + +- Legitimate system maintenance tools or scripts may trigger the rule if they use similar arguments and executables not listed in the safe paths. Review the process origin and context to determine if it is part of routine maintenance. +- Custom administrative scripts that automate disk cleanup tasks might be flagged. Verify the script's source and purpose, and consider adding it to an exception list if it is deemed safe. +- Software updates or installations that temporarily use disk cleanup functionalities could be misidentified. Monitor the timing and context of these events, and exclude known update processes from the rule. +- Third-party disk management tools that mimic or extend Windows disk cleanup features may cause alerts. Validate the tool's legitimacy and add it to the exclusion list if it is a trusted application. +- Scheduled tasks created by IT departments for system optimization might match the rule's criteria. Confirm the task's legitimacy and adjust the rule to exclude these specific tasks if they are verified as non-threatening. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule that are not using the legitimate DiskCleanup executables. +- Conduct a thorough review of scheduled tasks on the affected system to identify and remove any unauthorized or malicious tasks that may have been created or modified. +- Restore any altered system files or configurations to their original state using known good backups or system restore points. +- Update and patch the affected system to the latest security updates to mitigate any known vulnerabilities that could be exploited for UAC bypass. +- Monitor the affected system and network for any signs of recurring unauthorized activity or similar UAC bypass attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_uac_bypass_dll_sideloading.toml b/rules/windows/privilege_escalation_uac_bypass_dll_sideloading.toml index 8e26acb0697..abcd2445f99 100644 --- a/rules/windows/privilege_escalation_uac_bypass_dll_sideloading.toml +++ b/rules/windows/privilege_escalation_uac_bypass_dll_sideloading.toml @@ -2,7 +2,7 @@ creation_date = "2020/10/27" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -46,6 +46,42 @@ file where host.os.type == "windows" and event.type : "change" and process.name /* has no impact on rule logic just to avoid OS install related FPs */ not file.path : ("C:\\Windows\\SoftwareDistribution\\*", "C:\\Windows\\WinSxS\\*") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 UAC Bypass Attempt via Privileged IFileOperation COM Interface + +The IFileOperation COM interface is a Windows component used for file operations with elevated privileges. Adversaries exploit this by side-loading malicious DLLs into processes like dllhost.exe, bypassing UAC to gain elevated permissions stealthily. The detection rule identifies such attempts by monitoring changes in specific DLLs loaded into high-integrity processes, filtering out benign system paths to reduce false positives. + +### Possible investigation steps + +- Review the alert details to confirm the process name is "dllhost.exe" and verify the integrity level of the process to ensure it is running with high or system integrity. +- Check the file name involved in the alert to see if it matches any of the known malicious DLLs such as "wow64log.dll", "comctl32.dll", "DismCore.dll", "OskSupport.dll", "duser.dll", or "Accessibility.ni.dll". +- Investigate the file path of the loaded DLL to ensure it does not originate from benign system paths like "C:\\Windows\\SoftwareDistribution\\" or "C:\\Windows\\WinSxS\\". +- Analyze the parent process of "dllhost.exe" to determine how it was initiated and whether it aligns with expected behavior or indicates potential compromise. +- Review recent system changes or installations that might have introduced the suspicious DLL, focusing on any unauthorized or unexpected software installations. +- Correlate the event with other security logs or alerts from data sources such as Elastic Endgame, Elastic Defend, Sysmon, Microsoft Defender for Endpoint, or SentinelOne to identify any related suspicious activities or patterns. +- Assess the risk and impact of the potential UAC bypass attempt and determine if further containment or remediation actions are necessary. + +### False positive analysis + +- System updates and installations can trigger false positives due to legitimate changes in DLLs. Exclude paths related to Windows updates and installations, such as C:\\Windows\\SoftwareDistribution\\* and C:\\Windows\\WinSxS\\*. +- Certain legitimate software may use DLLs like comctl32.dll or duser.dll in a manner that mimics side-loading. Identify and whitelist these applications if they are known and trusted within your environment. +- Security software or system management tools might perform operations that resemble UAC bypass attempts. Review and exclude these tools if they are verified as safe and necessary for your operations. +- Regularly review and update the list of known benign DLLs and paths to ensure that new legitimate software does not trigger false positives. +- Monitor for patterns of repeated false positives from specific processes or paths and consider creating exceptions for these scenarios after thorough validation. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Terminate the dllhost.exe process if it is confirmed to be involved in the UAC bypass attempt to stop any ongoing malicious activity. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious DLLs or associated malware. +- Review and restore any modified system files or settings to their original state to ensure system integrity. +- Apply any pending security patches and updates to the operating system and installed software to mitigate known vulnerabilities. +- Monitor the network for any signs of similar activity or attempts to exploit the IFileOperation COM interface on other systems. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_unquoted_service_path.toml b/rules/windows/privilege_escalation_unquoted_service_path.toml index a5d975e7816..a48dcfe165d 100644 --- a/rules/windows/privilege_escalation_unquoted_service_path.toml +++ b/rules/windows/privilege_escalation_unquoted_service_path.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/13" integration = ["endpoint", "m365_defender", "sentinel_one_cloud_funnel", "windows", "system"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -43,6 +43,41 @@ process where host.os.type == "windows" and event.type == "start" and process.executable regex """(C:\\Program Files \(x86\)\\|C:\\Program Files\\)\w+.exe""" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Exploitation of an Unquoted Service Path Vulnerability + +Unquoted service paths in Windows can be exploited by adversaries to escalate privileges. When a service path lacks quotes, Windows may execute a malicious executable placed in a higher-level directory. The detection rule identifies suspicious processes starting from common unquoted paths, signaling potential exploitation attempts. This helps in early detection and mitigation of privilege escalation threats. + +### Possible investigation steps + +- Review the process executable path to confirm if it matches the patterns specified in the query, such as "?:\\\\Program.exe" or executables within "C:\\\\Program Files (x86)\\\\" or "C:\\\\Program Files\\\\". +- Check the parent process of the suspicious executable to determine how it was initiated and assess if it aligns with expected behavior. +- Investigate the file creation and modification timestamps of the suspicious executable to identify any recent changes that could indicate malicious activity. +- Analyze the user account associated with the process start event to determine if it has the necessary privileges and if the activity is consistent with the user's typical behavior. +- Examine the system's event logs for any related activities or anomalies around the time the suspicious process was started, such as other process executions or file modifications. +- Cross-reference the executable's hash with known threat intelligence databases to identify if it is associated with any known malware or suspicious activity. + +### False positive analysis + +- Legitimate software installations or updates may trigger the rule if they temporarily create executables in common unquoted paths. Users can create exceptions for known software update processes to prevent unnecessary alerts. +- System administrators might use scripts or tools that inadvertently place executables in unquoted paths for legitimate purposes. Identifying and documenting these tools can help in setting up exclusions. +- Some enterprise applications may have legitimate executables in unquoted paths due to legacy configurations. Review and verify these applications, then configure exceptions for them to avoid false positives. +- Regularly scheduled tasks or maintenance scripts that run from unquoted paths can be mistaken for malicious activity. Ensure these tasks are documented and excluded from the rule if they are verified as safe. +- Security tools or monitoring software might simulate or test unquoted path vulnerabilities as part of their operations. Confirm these activities with the security team and exclude them if they are part of routine security assessments. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, specifically those matching the unquoted service path pattern. +- Conduct a thorough review of the service configurations on the affected system to identify and correct any unquoted service paths. Ensure all service paths are properly quoted to prevent future exploitation. +- Remove any unauthorized executables found in higher-level directories that could be used to exploit the unquoted service path vulnerability. +- Restore the affected system from a known good backup if malicious activity is confirmed and system integrity is compromised. +- 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 enhanced monitoring and logging for similar suspicious activities across the network to detect and respond to future attempts promptly.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_unusual_printspooler_childprocess.toml b/rules/windows/privilege_escalation_unusual_printspooler_childprocess.toml index 99d0b03ae20..6b0325334ab 100644 --- a/rules/windows/privilege_escalation_unusual_printspooler_childprocess.toml +++ b/rules/windows/privilege_escalation_unusual_printspooler_childprocess.toml @@ -2,7 +2,7 @@ creation_date = "2021/07/06" integration = ["endpoint", "windows", "system"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -64,6 +64,43 @@ process where host.os.type == "windows" and event.type == "start" and "?:\\Program Files (x86)\\GPLGS\\gswin32c.exe" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Print Spooler Child Process + +The Print Spooler service, integral to Windows environments, manages print jobs and interactions with printers. Adversaries may exploit vulnerabilities in this service to escalate privileges, gaining unauthorized access or control. The detection rule identifies suspicious child processes spawned by the Print Spooler, excluding known legitimate processes, to flag potential exploitation attempts, focusing on unusual command lines and integrity levels. + +### Possible investigation steps + +- Review the process details to identify the unusual child process spawned by spoolsv.exe, focusing on the process name and command line arguments to understand its purpose and potential malicious intent. +- Check the integrity level of the process using the fields process.Ext.token.integrity_level_name or winlog.event_data.IntegrityLevel to confirm if it is running with elevated privileges, which could indicate an exploitation attempt. +- Investigate the parent-child relationship by examining the process tree to determine if there are any other suspicious processes associated with the same parent process, spoolsv.exe. +- Cross-reference the process executable path against known legitimate software paths to ensure it is not a false positive, especially if the executable is not listed in the exclusion paths. +- Analyze recent system logs and security events around the time of the alert to identify any other anomalous activities or patterns that could be related to the potential exploitation attempt. +- If the process is confirmed suspicious, isolate the affected system to prevent further exploitation and conduct a deeper forensic analysis to understand the scope and impact of the incident. + +### False positive analysis + +- Legitimate print-related processes like splwow64.exe, PDFCreator.exe, and acrodist.exe may trigger alerts. These are excluded in the rule to prevent false positives. +- System processes such as msiexec.exe, route.exe, and WerFault.exe are known to be legitimate child processes of the Print Spooler and are excluded to reduce false alerts. +- Commands involving net.exe for starting or stopping services are common in administrative tasks and are excluded to avoid unnecessary alerts. +- Command-line operations involving cmd.exe or powershell.exe that reference .spl files or system paths are often legitimate and are excluded to minimize false positives. +- Network configuration changes using netsh.exe, such as adding port openings or rules, are typical in network management and are excluded to prevent false alerts. +- Registration of PrintConfig.dll via regsvr32.exe is a known legitimate operation and is excluded to avoid false positives. +- Executables from known paths like CutePDF Writer and GPLGS are excluded to prevent alerts from common, non-threatening applications. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary. +- Terminate any suspicious child processes spawned by the Print Spooler service that do not match known legitimate processes or command lines. +- Conduct a thorough review of the system's security logs to identify any unauthorized access or privilege escalation attempts related to the Print Spooler service. +- Apply the latest security patches and updates to the Windows operating system and specifically to the Print Spooler service to mitigate known vulnerabilities. +- Restore the system from a clean backup if any unauthorized changes or malicious activities are confirmed. +- Monitor the system closely for any recurrence of similar suspicious activities, ensuring enhanced logging and alerting are in place for spoolsv.exe and its child processes. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_unusual_svchost_childproc_childless.toml b/rules/windows/privilege_escalation_unusual_svchost_childproc_childless.toml index 12e5a8b5448..cb92d3708ce 100644 --- a/rules/windows/privilege_escalation_unusual_svchost_childproc_childless.toml +++ b/rules/windows/privilege_escalation_unusual_svchost_childproc_childless.toml @@ -2,7 +2,7 @@ creation_date = "2020/10/13" integration = ["endpoint", "windows", "m365_defender", "sentinel_one_cloud_funnel"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -64,6 +64,42 @@ process where host.os.type == "windows" and event.type == "start" and ) and process.parent.args : "imgsvc" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Service Host Child Process - Childless Service + +Service Host (svchost.exe) is a critical Windows process that hosts multiple services to optimize resource usage. Typically, certain services under svchost.exe do not spawn child processes. Adversaries exploit this by injecting malicious code to execute unauthorized processes, evading detection. The detection rule identifies anomalies by monitoring child processes of traditionally childless services, flagging potential exploitation attempts. + +### Possible investigation steps + +- Review the process details of the child process, including its name and executable path, to determine if it is a known legitimate process or potentially malicious. +- Examine the parent process arguments to confirm if the svchost.exe instance is associated with a service that traditionally does not spawn child processes, as listed in the query. +- Check the process creation time and correlate it with any other suspicious activities or alerts in the system around the same timeframe. +- Investigate the user account under which the child process was executed to assess if it has the necessary privileges and if the activity aligns with typical user behavior. +- Analyze any network connections or file modifications made by the child process to identify potential malicious actions or data exfiltration attempts. +- Cross-reference the child process with known false positives listed in the query to rule out benign activities. +- Utilize threat intelligence sources to determine if the child process or its executable path is associated with known malware or attack patterns. + +### False positive analysis + +- Processes like WerFault.exe, WerFaultSecure.exe, and wermgr.exe are known to be legitimate Windows error reporting tools that may occasionally be spawned by svchost.exe. To handle these, add them to the exclusion list in the detection rule to prevent unnecessary alerts. +- RelPost.exe associated with WdiSystemHost can be a legitimate process in certain environments. If this is a common occurrence, consider adding an exception for this executable when it is spawned by WdiSystemHost. +- Rundll32.exe executing winethc.dll with ForceProxyDetectionOnNextRun arguments under WdiServiceHost may be a benign operation in some network configurations. If verified as non-malicious, exclude this specific process and argument combination. +- Processes under the imgsvc service, such as lexexe.exe from Kodak directories, might be legitimate in environments using specific imaging software. Validate these occurrences and exclude them if they are confirmed to be non-threatening. +- Regularly review and update the exclusion list to ensure it reflects the current environment and does not inadvertently allow malicious activity. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further spread or communication with potential command and control servers. +- Terminate any suspicious child processes spawned by svchost.exe that are not typically associated with legitimate operations, as identified in the alert. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any injected malicious code or associated malware. +- Review and analyze the process tree and parent-child relationships to understand the scope of the compromise and identify any additional affected processes or systems. +- Restore the affected system from a known good backup if malicious activity is confirmed and cannot be fully remediated through cleaning. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Implement enhanced monitoring and logging for svchost.exe and related processes to detect similar anomalies in the future, ensuring that alerts are configured to notify the appropriate personnel promptly.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_via_ppid_spoofing.toml b/rules/windows/privilege_escalation_via_ppid_spoofing.toml index 57c9603c900..b00731f8421 100644 --- a/rules/windows/privilege_escalation_via_ppid_spoofing.toml +++ b/rules/windows/privilege_escalation_via_ppid_spoofing.toml @@ -2,7 +2,7 @@ creation_date = "2022/10/20" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -95,6 +95,41 @@ process where host.os.type == "windows" and event.action == "start" and ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Privileges Elevation via Parent Process PID Spoofing + +Parent Process ID (PPID) spoofing is a technique where adversaries manipulate the PPID of a process to disguise its origin, often to bypass security measures or gain elevated privileges. This is particularly concerning in Windows environments where processes can inherit permissions from their parent. The detection rule identifies suspicious process creation patterns, such as unexpected PPID values and elevated user IDs, while filtering out known legitimate processes and trusted signatures, to flag potential privilege escalation attempts. + +### Possible investigation steps + +- Review the process creation event details, focusing on the process.parent.Ext.real.pid and user.id fields to confirm if the PPID spoofing led to privilege escalation to SYSTEM. +- Examine the process.executable and process.parent.executable paths to determine if the process is known or expected in the environment, and check against the list of excluded legitimate processes. +- Investigate the process.code_signature fields to verify if the process is signed by a trusted entity and if the signature is valid, especially if the process is not excluded by the rule. +- Check the historical activity of the involved user.id and process.parent.executable to identify any unusual patterns or recent changes in behavior. +- Correlate the alert with other security events or logs to identify any related suspicious activities or potential lateral movement attempts within the network. + +### False positive analysis + +- Processes related to Windows Error Reporting such as WerFault.exe and Wermgr.exe can trigger false positives. These are legitimate system processes and can be excluded by verifying their signatures and paths. +- Logon utilities like Utilman.exe spawning processes such as osk.exe, Narrator.exe, or Magnify.exe may appear suspicious but are often legitimate. Exclude these by confirming their usage context and ensuring they are executed by trusted users. +- Third-party software like TeamViewer, Cisco WebEx, and Dell Inc. may cause false positives due to their legitimate use of process creation. Verify the code signature and trust status to exclude these processes. +- Windows Update processes involving MpSigStub.exe and wuauclt.exe can be mistakenly flagged. Confirm these are part of regular update activities and exclude them based on their known paths and parent processes. +- Remote support and management tools such as LogMeIn, GoToAssist, and Chrome Remote Desktop may be flagged. Ensure these are installed and used by authorized personnel and exclude them by their executable paths. +- Netwrix Corporation's processes like adcrcpy.exe may be flagged if they are part of legitimate auditing activities. Verify the code signature and exclude these processes if they are part of authorized Netwrix Auditor operations. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified by the alert, especially those with spoofed PPIDs or elevated privileges, to stop potential malicious activities. +- Review and revoke any unauthorized user accounts or privileges that may have been created or escalated during the incident. +- Conduct a thorough forensic analysis of the affected system to identify any additional indicators of compromise or persistence mechanisms. +- Restore the system from a known good backup if necessary, ensuring that all malicious artifacts are removed and system integrity is maintained. +- Implement additional monitoring and logging on the affected system and network to detect any recurrence of similar activities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_via_rogue_named_pipe.toml b/rules/windows/privilege_escalation_via_rogue_named_pipe.toml index 05672066a7b..54db661628b 100644 --- a/rules/windows/privilege_escalation_via_rogue_named_pipe.toml +++ b/rules/windows/privilege_escalation_via_rogue_named_pipe.toml @@ -2,7 +2,7 @@ creation_date = "2021/10/13" integration = ["windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -51,6 +51,40 @@ file where host.os.type == "windows" and event.action : "Pipe Created*" and /* normal sysmon named pipe creation events truncate the pipe keyword */ file.name : "\\*\\Pipe\\*" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Privilege Escalation via Rogue Named Pipe Impersonation + +Named pipes in Windows facilitate inter-process communication, allowing data exchange between processes. Adversaries exploit this by creating rogue named pipes, tricking privileged processes into connecting and executing malicious actions under elevated privileges. The detection rule identifies suspicious named pipe creation events, focusing on patterns indicative of impersonation attempts, thus flagging potential privilege escalation activities. + +### Possible investigation steps + +- Review the event logs for the specific named pipe creation event identified by the query, focusing on the file.name field to determine the exact named pipe path and assess its legitimacy. +- Correlate the event with the process that created the named pipe by examining related process creation logs, identifying the process ID and executable responsible for the action. +- Investigate the user context under which the named pipe was created to determine if it aligns with expected behavior or if it indicates potential misuse of privileges. +- Check for any recent changes or anomalies in the system's configuration or user accounts that could suggest unauthorized access or privilege escalation attempts. +- Analyze historical data for similar named pipe creation events to identify patterns or repeated attempts that could indicate a persistent threat or ongoing attack. + +### False positive analysis + +- Legitimate software or system processes may create named pipes that match the detection pattern. Regularly review and whitelist known benign processes that frequently create named pipes to reduce noise. +- System management tools and monitoring software might generate named pipe creation events as part of their normal operation. Identify these tools and exclude their events from triggering alerts. +- Custom in-house applications that use named pipes for inter-process communication can trigger false positives. Work with development teams to document these applications and create exceptions for their activity. +- Scheduled tasks or scripts that run with elevated privileges and create named pipes could be mistaken for malicious activity. Ensure these tasks are documented and excluded from the detection rule. +- Security software or endpoint protection solutions may use named pipes for legitimate purposes. Verify these activities and adjust the rule to prevent unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes associated with the rogue named pipe to halt any ongoing malicious activities. +- Conduct a thorough review of the system's event logs, focusing on named pipe creation events, to identify any other potentially compromised processes or systems. +- Reset credentials for any accounts that may have been exposed or used in the privilege escalation attempt to prevent further unauthorized access. +- Apply security patches and updates to the affected system to address any vulnerabilities that may have been exploited. +- Implement enhanced monitoring for named pipe creation events across the network to detect and respond to similar threats in the future. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to ensure comprehensive remediation efforts are undertaken.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_via_token_theft.toml b/rules/windows/privilege_escalation_via_token_theft.toml index 4e4c0049a82..a4a4b6dd1b3 100644 --- a/rules/windows/privilege_escalation_via_token_theft.toml +++ b/rules/windows/privilege_escalation_via_token_theft.toml @@ -2,7 +2,7 @@ creation_date = "2022/10/20" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -98,6 +98,42 @@ not (process.parent.executable : "?\\Windows\\System32\\spoolsv.exe" and "Cisco WebEx LLC", "Dell Inc")) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Process Created with an Elevated Token + +In Windows environments, processes can be created with elevated tokens to perform tasks requiring higher privileges. Adversaries exploit this by impersonating system-level binaries to escalate privileges and bypass security controls. The detection rule identifies such activities by monitoring process creation events, focusing on those initiated by privileged binaries and excluding known benign processes. This helps in identifying unauthorized privilege escalation attempts. + +### Possible investigation steps + +- Review the process creation event details to identify the specific executable and its parent process, focusing on the fields process.executable and process.Ext.effective_parent.executable. +- Check the user.id field to confirm if the process was created with the SYSTEM user ID (S-1-5-18), indicating elevated privileges. +- Investigate the parent process executable path to determine if it matches any known privileged Microsoft native binaries, which could be targets for token theft. +- Examine the process code signature details, especially process.code_signature.trusted and process.code_signature.subject_name, to verify if the executable is signed by a trusted entity or if it matches any excluded signatures. +- Correlate the process creation event with other security logs and alerts to identify any related suspicious activities or patterns that might indicate privilege escalation attempts. +- Assess the context and timing of the event to determine if it aligns with legitimate administrative tasks or if it appears anomalous in the environment. + +### False positive analysis + +- Utility Manager in Windows running in debug mode can trigger false positives. To handle this, exclude processes where both the effective parent and parent executables are Utilman.exe with the /debug argument. +- Windows print spooler service correlated with Access Intelligent Form may cause false alerts. Exclude processes where the parent executable is spoolsv.exe and the process executable is LaunchCreate.exe under Access Intelligent Form. +- Windows error reporting executables like WerFault.exe can be mistakenly flagged. Exclude these specific executables from the rule to prevent unnecessary alerts. +- Windows updates initiated by TiWorker.exe running with elevated privileges can be misidentified. Exclude processes where TiWorker.exe is the parent and the process executable matches known update-related paths. +- Additional parent executables that typically run with elevated privileges, such as AtBroker.exe and svchost.exe, can lead to false positives. Exclude these parent executables from the rule to reduce noise. +- Trusted Windows binaries with specific signature names, such as those from TeamViewer or Cisco WebEx, may be incorrectly flagged. Exclude processes with a trusted code signature and matching subject names to avoid false alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule that are running with elevated privileges, especially those not matching known benign processes. +- Conduct a thorough review of user accounts and privileges on the affected system to identify and disable any unauthorized accounts or privilege escalations. +- Restore the affected system from a known good backup to ensure any malicious changes are reverted, and verify the integrity of the system post-restoration. +- Implement additional monitoring on the affected system and network to detect any further attempts at privilege escalation or token manipulation. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems. +- Review and update endpoint protection and detection capabilities to ensure they are configured to detect similar threats in the future, leveraging the MITRE ATT&CK framework for guidance on Access Token Manipulation (T1134).""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_windows_service_via_unusual_client.toml b/rules/windows/privilege_escalation_windows_service_via_unusual_client.toml index 758b1a47d47..39bd669b6fb 100644 --- a/rules/windows/privilege_escalation_windows_service_via_unusual_client.toml +++ b/rules/windows/privilege_escalation_windows_service_via_unusual_client.toml @@ -2,7 +2,7 @@ creation_date = "2022/02/07" integration = ["system", "windows"] maturity = "production" -updated_date = "2024/10/15" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -64,6 +64,41 @@ configuration where host.os.type == "windows" and "\"%windir%\\AdminArsenal\\PDQInventory-Scanner\\service-1\\PDQInventory-Scanner-1.exe\" " ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Windows Service Installed via an Unusual Client + +Windows services are crucial for running background processes with elevated privileges. Adversaries exploit this by creating services to escalate privileges from administrator to SYSTEM. The detection rule identifies anomalies by flagging service installations initiated by atypical processes, excluding known legitimate services. This helps in spotting potential privilege escalation attempts by monitoring unusual client activity. + +### Possible investigation steps + +- Review the event logs to identify the specific client process that initiated the service installation by examining the winlog.event_data.ClientProcessId and winlog.event_data.ParentProcessId fields. +- Investigate the parent process associated with the unusual client process to determine if it is a known legitimate application or potentially malicious. +- Check the winlog.event_data.ServiceFileName to verify the path and name of the service file, ensuring it is not a known legitimate service excluded in the query. +- Analyze the timeline of events around the service installation to identify any preceding suspicious activities or related alerts that might indicate a broader attack. +- Conduct a reputation check on the client process and service file using threat intelligence sources to assess if they are associated with known malicious activities. +- Examine the system for any additional indicators of compromise, such as unexpected network connections or changes to critical system files, that may suggest privilege escalation or lateral movement attempts. + +### False positive analysis + +- Legitimate software installations or updates may trigger the rule if they create services using unusual client processes. To manage this, identify and whitelist these processes in the detection rule to prevent unnecessary alerts. +- System management tools like Veeam and PDQ Inventory are already excluded, but other similar tools might not be. Regularly review and update the exclusion list to include any additional legitimate tools used in your environment. +- Custom scripts or administrative tools that create services for maintenance or monitoring purposes can also cause false positives. Document these scripts and consider adding them to the exclusion list if they are verified as safe. +- Temporary or one-time service installations for troubleshooting or testing can be mistaken for threats. Ensure that such activities are logged and communicated to the security team to avoid confusion and unnecessary alerts. +- Changes in system configurations or updates to existing software might alter the behavior of legitimate processes, causing them to be flagged. Regularly review and adjust the detection rule to accommodate these changes while maintaining security integrity. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate the suspicious service and any associated processes identified by the alert to stop potential privilege escalation or malicious activity. +- Conduct a thorough review of the service's configuration and associated files to identify any unauthorized changes or malicious code. +- Restore any altered or compromised system files from a known good backup to ensure system integrity. +- Change all administrator and SYSTEM account passwords on the affected system and any connected systems to prevent further unauthorized access. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine the scope of the breach. +- Implement additional monitoring and logging on the affected system and similar environments to detect any recurrence of the threat or related suspicious activities.""" [[rule.threat]] diff --git a/rules/windows/privilege_escalation_wpad_exploitation.toml b/rules/windows/privilege_escalation_wpad_exploitation.toml index 4ce6d2b03c5..e331e08f58b 100644 --- a/rules/windows/privilege_escalation_wpad_exploitation.toml +++ b/rules/windows/privilege_escalation_wpad_exploitation.toml @@ -2,7 +2,7 @@ creation_date = "2020/09/02" integration = ["endpoint"] maturity = "development" -updated_date = "2024/04/08" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -38,6 +38,40 @@ sequence with maxspan=5s [process where host.os.type == "windows" and event.type == "start" and process.parent.name : "svchost.exe"] by process.parent.entity_id ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 WPAD Service Exploit + +The Web Proxy Auto-Discovery Protocol (WPAD) helps devices on a network automatically find a proxy server. Adversaries can exploit WPAD by injecting malicious scripts into the service, potentially compromising systems. The detection rule identifies suspicious WPAD activity by monitoring specific processes and network behaviors, such as DNS queries and unusual DLL loads, to flag potential privilege escalation attempts. + +### Possible investigation steps + +- Review the process tree for the svchost.exe instance identified in the alert to understand its parent and child processes, focusing on any unusual or unexpected behavior. +- Analyze DNS query logs for the domain "wpad" to identify any suspicious or unauthorized requests, and cross-reference with known malicious domains. +- Examine network traffic logs for outgoing connections on port 80 from the svchost.exe process to detect any unauthorized data exfiltration or communication with suspicious external IP addresses. +- Investigate the loading of jscript.dll by svchost.exe to determine if there are any anomalies or signs of script execution that could indicate malicious activity. +- Check for any recent changes or anomalies in the user account associated with the LOCAL SERVICE domain, as this could indicate privilege escalation attempts. + +### False positive analysis + +- Legitimate network services using WPAD may trigger alerts if they perform DNS queries for "wpad" or communicate over port 80. To manage this, identify and whitelist known benign services that frequently use WPAD. +- Routine system updates or software installations might cause svchost.exe to load jscript.dll, leading to false positives. Monitor and document regular update schedules and exclude these time frames from triggering alerts. +- Some enterprise environments use custom scripts or applications that interact with WPAD for legitimate purposes. Review and document these applications, then create exceptions for their known behaviors to prevent unnecessary alerts. +- In environments with frequent DNS changes or testing, legitimate DNS queries for WPAD might be flagged. Establish a baseline of normal DNS activity and adjust the detection rule to accommodate expected patterns. +- If svchost.exe is commonly used by other legitimate processes in your network, consider refining the rule to include additional context or attributes that distinguish malicious from benign activity. + +### Response and remediation + +- Isolate the affected system from the network immediately to prevent further exploitation or lateral movement by the attacker. +- Terminate any suspicious svchost.exe processes identified in the alert to stop the execution of potentially malicious scripts. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious payloads or scripts. +- Review and reset any potentially compromised credentials, especially those associated with the LOCAL SERVICE account, to prevent unauthorized access. +- Apply security patches and updates to the operating system and all software to mitigate known vulnerabilities that could be exploited by similar attacks. +- Monitor network traffic for any further suspicious DNS queries or unusual outbound connections, particularly those involving the WPAD service, to detect any ongoing or new threats. +- Escalate the incident to the security operations center (SOC) or relevant IT security team for further investigation and to ensure comprehensive remediation and recovery efforts.""" [[rule.threat]] diff --git a/rules_building_block/collection_archive_data_zip_imageload.toml b/rules_building_block/collection_archive_data_zip_imageload.toml index 445af055e36..9a6070c5164 100644 --- a/rules_building_block/collection_archive_data_zip_imageload.toml +++ b/rules_building_block/collection_archive_data_zip_imageload.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/06" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -52,6 +52,41 @@ library where host.os.type == "windows" and event.action == "load" and ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Compression DLL Loaded by Unusual Process + +Compression DLLs, like those in the .NET framework, facilitate data compression and decompression, crucial for efficient data storage and transfer. Adversaries exploit these DLLs to compress and encrypt data before exfiltration, evading detection. The detection rule identifies unusual processes loading these DLLs, excluding trusted applications, to flag potential malicious activity. + +### Possible investigation steps + +- Review the process executable path to determine if it is indeed unusual or potentially malicious, focusing on paths not listed in the exclusion criteria. +- Check the process code signature to verify if it is trusted or if there are any anomalies in the signature that could indicate tampering. +- Investigate the user account associated with the process, especially if it is not one of the trusted system accounts (S-1-5-18, S-1-5-20), to assess if the account has been compromised. +- Analyze the parent process of the flagged process to understand how it was initiated and if there are any suspicious activities leading up to the DLL load. +- Correlate the event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise. +- Examine network activity from the host around the time of the DLL load to detect any potential data exfiltration attempts. + +### False positive analysis + +- Trusted applications not covered by the exclusion list may trigger false positives. Regularly review and update the exclusion list to include additional trusted applications that are known to load compression DLLs. +- System administrators or developers using custom scripts or tools that load compression DLLs for legitimate purposes might cause alerts. Consider adding these specific processes to the exclusion list if they are verified as non-malicious and signed by a trusted code signature. +- Automated software updates or installations that temporarily load compression DLLs can be mistaken for suspicious activity. Monitor these events and, if they are routine and verified, adjust the rule to exclude these specific update processes. +- Security or monitoring tools that perform legitimate data compression as part of their operations may be flagged. Ensure these tools are signed by a trusted code signature and add them to the exclusion list if necessary. +- User-initiated processes that involve data compression for legitimate business purposes might trigger alerts. Educate users on the types of activities that could cause alerts and adjust the rule to exclude these processes if they are frequent and verified. + +### Response and remediation + +- Isolate the affected system from the network to prevent further data exfiltration or lateral movement by the adversary. +- Terminate the suspicious process that loaded the compression DLL to halt any ongoing malicious activity. +- Conduct a forensic analysis of the affected system to identify any compressed or encrypted files that may have been prepared for exfiltration. +- Restore any compromised files from a known good backup to ensure data integrity and availability. +- Update and patch the affected system to close any vulnerabilities that may have been exploited by the adversary. +- Monitor network traffic for any signs of data exfiltration attempts or communication with known malicious IP addresses. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules_building_block/collection_common_compressed_archived_file.toml b/rules_building_block/collection_common_compressed_archived_file.toml index 8cbf9f55494..149b31b6374 100644 --- a/rules_building_block/collection_common_compressed_archived_file.toml +++ b/rules_building_block/collection_common_compressed_archived_file.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/10/11" integration = "endpoint" maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -110,6 +110,40 @@ file where host.os.type == "windows" and event.type in ("creation", "change") an ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Compressed or Archived into Common Format + +File compression and archiving are essential for efficient data storage and transfer, using formats like ZIP, RAR, and 7-Zip. However, adversaries exploit these technologies to obfuscate malicious files or stage data for exfiltration. The detection rule identifies suspicious compression activities by monitoring file creation or modification events, excluding trusted processes, and focusing on specific file signatures indicative of compression or archiving. + +### Possible investigation steps + +- Review the process executable and its code signature details to determine if the process is expected or potentially malicious. Pay attention to processes not listed in the exclusions, such as unknown or untrusted executables. +- Examine the user ID associated with the event to identify if the activity was performed by a legitimate user or an unauthorized account. Investigate any anomalies in user behavior. +- Analyze the file path and name to understand the context of the compressed or archived file. Check if the file location is typical for such activities or if it appears suspicious. +- Investigate the file header bytes to confirm the type of compression or archive format used. This can help identify if the format is commonly used in the environment or if it is unusual. +- Check for any recent changes or creations of similar files on the host to identify patterns or repeated activities that might indicate malicious intent. +- Correlate the event with other security alerts or logs from the same host or user to gather additional context and determine if this is part of a larger attack or data exfiltration attempt. + +### False positive analysis + +- Trusted applications like Firefox, Wazuh Agent, Microsoft Office, OneDrive, Dropbox, Dell SupportAssist, and IIS may trigger false positives when they perform legitimate compression or archiving activities. Users can mitigate these by ensuring the processes are correctly signed and trusted, and by adding exceptions for these applications in the rule configuration. +- Files with specific extensions or paths, such as those associated with OneDrive logs or IIS temporary compressed files, may be flagged. Users should review these paths and extensions and consider excluding them if they are part of regular, non-malicious operations. +- Regular updates or operations by trusted software, such as Windows Update or Dell SupportAssist, might be misidentified as suspicious. Users should verify the legitimacy of these operations and adjust the rule to exclude these known, safe activities. +- If certain processes are frequently involved in legitimate compression activities, users can add these processes to the exception list, provided they are verified as safe and necessary for business operations. + +### Response and remediation + +- Isolate the affected system from the network to prevent further data exfiltration or lateral movement by the adversary. +- Terminate any suspicious processes identified in the alert that are not part of the trusted processes list, especially those involved in file compression or archiving. +- Conduct a thorough scan of the isolated system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or software. +- Review and analyze the compressed or archived files identified in the alert to determine if they contain sensitive data or malware, and take appropriate action based on the findings. +- Restore any affected files from a known good backup if they have been altered or corrupted by the malicious activity. +- 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 similar file compression activities across the network to enhance detection and prevent recurrence.""" [[rule.threat]] diff --git a/rules_building_block/collection_files_staged_in_recycle_bin_root.toml b/rules_building_block/collection_files_staged_in_recycle_bin_root.toml index 9ac96708907..a8adbd20510 100644 --- a/rules_building_block/collection_files_staged_in_recycle_bin_root.toml +++ b/rules_building_block/collection_files_staged_in_recycle_bin_root.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/24" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -41,6 +41,40 @@ file where host.os.type == "windows" and event.type == "creation" and not file.path : "?:\\$RECYCLE.BIN\\*\\*" and not file.name : "desktop.ini" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Staged in Root Folder of Recycle Bin + +The Recycle Bin in Windows is designed to temporarily store deleted files, typically organized in subdirectories. Adversaries may exploit this by placing files directly in the root to prepare for data exfiltration or to bypass security measures. The detection rule identifies such anomalies by flagging file creations in the root, excluding typical system files, thus highlighting potential malicious staging activities. + +### Possible investigation steps + +- Review the file path to confirm it matches the pattern "?:\\\\$RECYCLE.BIN\\\\*" and ensure it is not a typical system file like "desktop.ini". +- Investigate the file creation event to determine the user account associated with the action, checking for any unusual or unauthorized activity. +- Examine the file's metadata and properties, such as creation time, size, and file type, to assess its legitimacy and potential risk. +- Check for any recent or related alerts involving the same user or host to identify patterns or repeated suspicious behavior. +- Analyze the file's content, if accessible, to determine if it contains sensitive or exfiltration-worthy data. +- Review system logs and other security tools for any signs of data exfiltration attempts or other malicious activities around the time of the file creation. + +### False positive analysis + +- System maintenance tools or scripts may create files in the root of the Recycle Bin for temporary storage. Review the source of the file creation and consider excluding known maintenance tools from the detection rule. +- Backup or recovery software might use the Recycle Bin's root for staging files during operations. Verify the software's behavior and add exceptions for trusted applications. +- User actions, such as manual file management or organization, can result in files being placed in the root. Educate users on proper file management practices and consider excluding specific user actions if they are verified as non-malicious. +- Automated processes or scripts that are part of legitimate business operations may inadvertently use the Recycle Bin's root. Identify these processes and create exceptions to prevent unnecessary alerts. + +### Response and remediation + +- Isolate the affected system from the network to prevent potential data exfiltration or further malicious activity. +- Verify the legitimacy of the file(s) found in the root of the Recycle Bin by cross-referencing with known good files and recent user activity. +- If the file is confirmed malicious, remove it from the Recycle Bin and perform a full system scan using updated antivirus or endpoint detection and response (EDR) tools to identify and eliminate any additional threats. +- Review recent user and system activity logs to identify any unauthorized access or actions that may have led to the file's creation. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack. +- Implement additional monitoring on the affected system and similar endpoints to detect any recurrence of this activity. +- Update security policies and access controls to limit the ability of users and processes to write files directly to the root of the Recycle Bin, if feasible.""" [[rule.threat]] diff --git a/rules_building_block/collection_outlook_email_archive.toml b/rules_building_block/collection_outlook_email_archive.toml index 921f2861096..364c3087bc3 100644 --- a/rules_building_block/collection_outlook_email_archive.toml +++ b/rules_building_block/collection_outlook_email_archive.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/21" integration = ["endpoint", "windows", "system"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -44,6 +44,40 @@ process where host.os.type == "windows" and event.type == "start" and process.ar process.args : "*davclnt.dll,DavSetCookie*" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Accessing Outlook Data Files + +Outlook data files, such as OST and PST, store emails and other data locally on Windows systems. Adversaries may target these files to collect sensitive information, bypassing email server security. The detection rule identifies suspicious processes accessing these files, excluding legitimate Outlook operations, to flag potential unauthorized access or data exfiltration attempts. + +### Possible investigation steps + +- Review the process details to identify the process name and arguments that triggered the alert, ensuring it matches the criteria of accessing OST or PST files without being a legitimate Outlook operation. +- Investigate the parent process of the suspicious activity to determine if it was initiated by a legitimate application or a potentially malicious one. +- Check the user account associated with the process to assess if the activity aligns with the user's typical behavior or if it appears suspicious. +- Analyze the timeline of events to see if there are any other related alerts or activities around the same time that could indicate a broader attack or data exfiltration attempt. +- Examine the network activity of the host to identify any unusual outbound connections that might suggest data exfiltration following the access of Outlook data files. + +### False positive analysis + +- Legitimate backup software may access OST and PST files as part of routine data backup processes. To handle this, identify and exclude these backup processes by adding them to the exception list in the detection rule. +- Antivirus or endpoint protection software might scan Outlook data files during regular system checks. Review the processes associated with these scans and exclude them if they are verified as non-threatening. +- System maintenance tools or scripts that perform file indexing or system optimization could trigger the rule. Determine if these tools are part of regular maintenance and exclude them accordingly. +- Custom scripts or applications developed in-house that interact with Outlook data files for legitimate business purposes should be reviewed and excluded if they are deemed safe. +- Occasionally, third-party email clients or plugins may access Outlook data files. Verify the legitimacy of these applications and exclude them if they are necessary for business operations. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule that are accessing Outlook data files, ensuring that legitimate Outlook operations are not disrupted. +- Conduct a forensic analysis of the affected system to determine the extent of the compromise, focusing on identifying any data that may have been accessed or exfiltrated. +- Change passwords and review access permissions for any accounts that may have been compromised as a result of the unauthorized access to Outlook data files. +- Restore any corrupted or compromised Outlook data files from a known good backup to ensure data integrity and continuity of operations. +- Implement additional monitoring and alerting for similar suspicious activities, focusing on processes accessing OST and PST files, to enhance detection capabilities. +- Escalate the incident to the appropriate internal security team or external cybersecurity experts if the scope of the threat is beyond the current team's capacity to handle effectively.""" [[rule.threat]] diff --git a/rules_building_block/collection_posh_compression.toml b/rules_building_block/collection_posh_compression.toml index 5b1150f75d0..dec4c7d5506 100644 --- a/rules_building_block/collection_posh_compression.toml +++ b/rules_building_block/collection_posh_compression.toml @@ -5,7 +5,7 @@ integration = ["windows"] maturity = "production" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." min_stack_version = "8.14.0" -updated_date = "2024/10/28" +updated_date = "2025/01/10" [rule] @@ -70,6 +70,40 @@ not powershell.file.script_block_text : ( ) and not file.directory : "C:\Program Files\Microsoft Dependency Agent\plugins\lib" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 PowerShell Script with Archive Compression Capabilities + +PowerShell, a powerful scripting language in Windows, includes capabilities for file compression using various methods like ZipFile and GZipStream. While these are useful for legitimate data management, adversaries exploit them to compress and encrypt data for exfiltration. The detection rule identifies suspicious use of compression-related cmdlets and methods, excluding known benign activities, to flag potential threats. + +### Possible investigation steps + +- Review the PowerShell script block text associated with the alert to identify the specific compression methods or cmdlets used, such as "IO.Compression.ZipFile" or "Compress-Archive". +- Check the process execution details, including the parent process, to understand the context in which the PowerShell script was executed and identify any potentially malicious parent processes. +- Investigate the user account under which the PowerShell script was executed to determine if it aligns with expected behavior or if it might be compromised. +- Examine the file paths and directories involved in the compression activity to identify any unusual or sensitive data locations that might indicate data exfiltration attempts. +- Correlate the alert with other security events or logs, such as network traffic or file access logs, to identify any related suspicious activities or data transfers. +- Verify if the alert corresponds to any known benign activities or exclusions, such as those specified in the query, to rule out false positives. + +### False positive analysis + +- Legitimate software updates or diagnostics tools, such as Lenovo's diagnostics, may use compression methods. Exclude these by adding specific paths or script block text to the exception list. +- Automation tools like Ansible may trigger the rule during routine operations. Identify and exclude these by recognizing unique script block text patterns associated with these tools. +- System management or monitoring agents, such as the Microsoft Dependency Agent, might perform compression tasks. Exclude their known directories or script block text to prevent false alerts. +- Regular administrative tasks that involve file compression for backup or archiving purposes can be excluded by identifying and whitelisting specific script block text or directories used by trusted administrators. + +### Response and remediation + +- Isolate the affected system from the network to prevent further data exfiltration and limit the adversary's access. +- Terminate any suspicious PowerShell processes identified by the alert to stop ongoing malicious activities. +- Conduct a thorough review of the compressed files and directories mentioned in the alert to determine if sensitive data was involved and assess the extent of potential data loss. +- Restore any compromised or altered files from backups, ensuring that the restored data is free from malicious modifications. +- Implement additional monitoring on the affected system and similar endpoints to detect any further attempts at data compression or exfiltration. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign. +- Review and update endpoint protection configurations to enhance detection and prevention capabilities against similar threats in the future.""" [[rule.filters]] [rule.filters.meta] diff --git a/rules_building_block/command_and_control_bitsadmin_activity.toml b/rules_building_block/command_and_control_bitsadmin_activity.toml index 2b54cbba541..6590f57eaf7 100644 --- a/rules_building_block/command_and_control_bitsadmin_activity.toml +++ b/rules_building_block/command_and_control_bitsadmin_activity.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/21" integration = ["endpoint", "windows", "system"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -49,6 +49,41 @@ process where host.os.type == "windows" and event.type == "start" and ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Bitsadmin Activity + +Windows Background Intelligent Transfer Service (BITS) facilitates low-bandwidth file transfers, often used for updates. Adversaries exploit BITS to persistently download and execute malicious payloads, leveraging its ability to operate in the background. The detection rule identifies suspicious BITS usage by monitoring specific command-line arguments associated with bitsadmin.exe and PowerShell, flagging potential misuse indicative of command and control activities. + +### Possible investigation steps + +- Review the process details to confirm the presence of suspicious command-line arguments associated with bitsadmin.exe or powershell.exe, such as "*Transfer*", "*Create*", "AddFile", or "*Start-BitsTransfer*". +- Check the parent process of bitsadmin.exe or powershell.exe to determine if it was spawned by a legitimate application or a potentially malicious one. +- Investigate the network connections established by the host during the time of the alert to identify any unusual or unauthorized external communications. +- Examine the file paths and file names involved in the BITS transfer to assess if they are known or potentially malicious files. +- Correlate the alert with other security events or logs from the same host to identify any additional indicators of compromise or related suspicious activities. +- Review the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised. + +### False positive analysis + +- Routine system updates or legitimate software installations may trigger BITS activity. Users can create exceptions for known update processes or trusted software installations to prevent false alerts. +- Automated scripts or administrative tasks using PowerShell to manage BITS for legitimate purposes might be flagged. Identify and whitelist these scripts if they are verified as non-malicious. +- Internal IT operations that utilize BITS for file transfers within the organization could be misidentified as threats. Document and exclude these operations from monitoring if they are part of regular IT maintenance. +- Software distribution tools that rely on BITS for deploying applications across the network may cause false positives. Ensure these tools are recognized and excluded from the detection rule. +- Frequent use of BITS for legitimate data synchronization tasks, such as cloud backups, should be reviewed and excluded if they are part of standard business operations. + +### Response and remediation + +- Isolate the affected system from the network to prevent further command and control communication and potential lateral movement. +- Terminate any suspicious BITS jobs using bitsadmin.exe or PowerShell commands identified in the alert to stop ongoing malicious file transfers. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious payloads or remnants. +- Review and analyze the BITS job history and PowerShell logs to identify any additional indicators of compromise (IOCs) or related malicious activities. +- Restore the system from a known good backup if malicious activity has compromised system integrity or critical files. +- Implement network-level controls to block known malicious IP addresses or domains associated with the detected command and control activity. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules_building_block/credential_access_iis_apppoolsa_pwd_appcmd.toml b/rules_building_block/credential_access_iis_apppoolsa_pwd_appcmd.toml index 1eed992f989..3837808b8c6 100644 --- a/rules_building_block/credential_access_iis_apppoolsa_pwd_appcmd.toml +++ b/rules_building_block/credential_access_iis_apppoolsa_pwd_appcmd.toml @@ -5,7 +5,7 @@ integration = ["endpoint", "windows", "system"] min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." min_stack_version = "8.14.0" maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -47,6 +47,40 @@ process where host.os.type == "windows" and event.type == "start" and (process.name : "appcmd.exe" or ?process.pe.original_file_name == "appcmd.exe") and process.args : "list" and process.args : "/text*" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs. + +### Investigating Microsoft IIS Service Account Password Dumped + +Microsoft Internet Information Services (IIS) is a web server platform used to host websites and applications. AppCmd is a command-line tool for managing IIS configurations, including application pools. Adversaries with access to IIS can exploit AppCmd to extract service account passwords, potentially leading to credential theft. The detection rule identifies suspicious use of AppCmd by monitoring process execution patterns indicative of password dumping activities, thereby alerting security teams to potential credential access threats. + +### Possible investigation steps + +- Review the alert details to confirm the presence of "appcmd.exe" in the process name or original file name, and check if the process arguments include "list" and "/text*". +- Identify the user account under which the "appcmd.exe" process was executed to determine if it aligns with expected administrative activity or if it indicates potential unauthorized access. +- Examine the source IP address and host from which the "appcmd.exe" process was initiated to assess if it is a known and trusted source or if it requires further scrutiny. +- Check for any recent changes or anomalies in the IIS configuration or application pools that might suggest tampering or unauthorized access. +- Investigate any associated web shell activity or other indicators of compromise on the IIS server that could have facilitated the unauthorized use of AppCmd. +- Correlate this event with other security alerts or logs to identify any patterns or additional suspicious activities that might indicate a broader attack campaign. + +### False positive analysis + +- Routine administrative tasks using AppCmd may trigger alerts. If AppCmd is regularly used for legitimate configuration management, consider excluding these specific process executions by identifying the responsible user accounts or scheduled tasks. +- Automated scripts that manage IIS configurations and use AppCmd with similar arguments might be flagged. Review and whitelist these scripts by verifying their source and ensuring they are part of authorized operations. +- Development or testing environments where AppCmd is frequently used for debugging or configuration purposes can generate false positives. Implement exclusions for these environments by filtering based on hostnames or IP addresses. +- Security tools or monitoring solutions that simulate attacks for testing purposes might mimic the behavior detected by this rule. Coordinate with security teams to identify and exclude these benign activities from triggering alerts. + +### Response and remediation + +- Immediately isolate the affected IIS server from the network to prevent further unauthorized access or lateral movement. +- Terminate any suspicious processes related to appcmd.exe that are currently running on the server to halt any ongoing credential dumping activities. +- Change the passwords for all service accounts associated with the IIS application pools to prevent unauthorized access using potentially compromised credentials. +- Conduct a thorough review of IIS server logs and other relevant system logs to identify any additional indicators of compromise or unauthorized access attempts. +- Restore the IIS server from a known good backup taken before the incident, ensuring that all patches and security updates are applied. +- Implement network segmentation to limit access to the IIS server, allowing only necessary traffic and users to interact with it. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be affected.""" [[rule.threat]] diff --git a/rules_building_block/credential_access_mdmp_file_creation.toml b/rules_building_block/credential_access_mdmp_file_creation.toml index 938d4cba5ab..b1fe8349602 100644 --- a/rules_building_block/credential_access_mdmp_file_creation.toml +++ b/rules_building_block/credential_access_mdmp_file_creation.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/09/21" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -76,6 +76,41 @@ file where host.os.type == "windows" and event.type == "creation" and ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Credential Access via Memory Dump File Creation + +Memory dump files capture the state of a process's memory, which can include sensitive information like credentials. Adversaries exploit this by creating or modifying dump files to extract credentials. The detection rule identifies suspicious dump file activities by monitoring file creation events, focusing on specific file headers and sizes, while excluding trusted processes and paths to reduce false positives. This helps in identifying unauthorized attempts to access credentials. + +### Possible investigation steps + +- Review the file creation event details to confirm the presence of the MDMP header (4d444d50) and verify the file size is 30,000 bytes or larger, as these are key indicators of a suspicious memory dump. +- Identify the process responsible for creating the dump file by examining the process.name and process.executable fields. Check if the process is listed as a trusted executable in the exclusion list. +- Investigate the file path where the dump file was created. Ensure it does not match any of the known trusted paths specified in the rule, such as "?:\\\\ProgramData\\\\Microsoft\\\\Windows\\\\WER\\\\*" or "?:\\\\Users\\\\*\\\\AppData\\\\*\\\\CrashDumps\\\\*". +- Check the process.code_signature.trusted field to determine if the process creating the dump file is signed and trusted. If not, this could indicate a higher risk of malicious activity. +- Correlate the event with other recent alerts or logs from the same host to identify any patterns or additional suspicious activities that might suggest credential dumping attempts. +- If the process or path is not trusted, consider isolating the host for further forensic analysis to prevent potential credential theft or further compromise. + +### False positive analysis + +- System processes like WerFault.exe and Wermgr.exe are known to create legitimate memory dump files. To reduce false positives, ensure these processes are marked as trusted in the detection rule. +- Applications installed in standard directories such as Program Files or Program Files (x86) may generate dump files during normal operations. Consider excluding these paths if the applications are verified and trusted. +- User applications like Zoom may create crash reports in user-specific directories. If these are frequent and verified as non-malicious, add exceptions for these paths to minimize alerts. +- Windows Error Reporting (WER) paths are common for legitimate dump file creation. Exclude these paths if the processes involved are trusted and verified to prevent unnecessary alerts. +- Ensure that any process with a valid and trusted code signature is excluded from triggering alerts, as these are less likely to be associated with malicious activity. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified in the alert that are not part of the trusted list, especially those involved in creating or modifying memory dump files. +- Conduct a thorough review of the affected system's memory dump files to identify any extracted credentials or sensitive information. +- Change credentials for any accounts potentially exposed through the memory dump, prioritizing high-privilege accounts. +- Restore the affected system from a known good backup if unauthorized modifications are detected and cannot be easily remediated. +- Implement additional monitoring on the affected system and similar systems to detect any further attempts at credential access via memory dumps. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist.""" [[rule.threat]] diff --git a/rules_building_block/credential_access_mdmp_file_unusual_extension.toml b/rules_building_block/credential_access_mdmp_file_unusual_extension.toml index 666c28d4f06..0ee079f1987 100644 --- a/rules_building_block/credential_access_mdmp_file_unusual_extension.toml +++ b/rules_building_block/credential_access_mdmp_file_unusual_extension.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/09/21" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -48,6 +48,41 @@ file where host.os.type == "windows" and event.type == "creation" and process.name : "System" and file.extension : "tmpscan" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Memory Dump File with Unusual Extension + +Memory dumps capture the contents of system memory, often used for debugging or analysis. Adversaries may disguise these files with atypical extensions to evade detection, facilitating credential theft or defense evasion. The detection rule identifies such anomalies by checking for specific memory dump signatures and filtering out known benign processes, alerting analysts to potential threats. + +### Possible investigation steps + +- Review the file path and name to determine if the unusual extension could be an attempt to disguise the memory dump file. +- Examine the process that created the file, focusing on the process.executable and process.name fields, to identify if it is a known or trusted application. +- Check the process code signature status (process.code_signature.trusted) to verify if the process is signed and trusted, which might reduce the likelihood of malicious intent. +- Investigate the host where the file was created to identify any recent suspicious activities or alerts that might correlate with this event. +- Analyze the file header bytes (file.Ext.header_bytes) to confirm the presence of the MDMP signature, ensuring the file is indeed a memory dump. +- Cross-reference the event with other security logs or alerts to identify any related incidents or patterns of behavior that could indicate a broader threat. + +### False positive analysis + +- Memory dump files created by trusted security software like Endgame's esensor.exe may trigger alerts. To handle this, add an exception for processes with a trusted code signature and no file extension. +- System processes generating files with the extension "tmpscan" can be benign. Exclude these specific cases to reduce unnecessary alerts. +- Regularly review and update the list of known benign extensions to ensure that legitimate memory dump activities are not flagged as suspicious. +- Monitor for any new software installations or updates that might introduce legitimate memory dump activities, and adjust the rule exceptions accordingly. +- Collaborate with IT and security teams to identify any internal processes or tools that may generate memory dumps with unusual extensions, and whitelist these as needed. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes associated with the creation of the memory dump file, especially those not matching known benign processes. +- Conduct a thorough review of the system's recent activity logs to identify any unauthorized access or actions that may have led to the creation of the memory dump. +- Restore the system from a known good backup if any unauthorized changes or data exfiltration are confirmed. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. +- Implement stricter file monitoring and alerting for unusual file extensions and memory dump activities to enhance future detection capabilities. +- Escalate the incident to the security operations center (SOC) or relevant cybersecurity team for further investigation and to assess the potential impact on other systems within the network.""" [[rule.threat]] diff --git a/rules_building_block/credential_access_win_private_key_access.toml b/rules_building_block/credential_access_win_private_key_access.toml index 5cb1e8fc4d8..4a3c37f64ce 100644 --- a/rules_building_block/credential_access_win_private_key_access.toml +++ b/rules_building_block/credential_access_win_private_key_access.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/21" integration = ["endpoint", "windows", "system"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -54,6 +54,41 @@ process where host.os.type == "windows" and event.type == "start" and "?:\\Windows\\System32\\OpenSSH\\*" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Attempted Private Key Access + +Private keys, such as SSH keys, are critical for secure authentication in environments. Adversaries may attempt to access these keys to gain unauthorized access. The detection rule identifies suspicious processes on Windows systems that attempt to access files typically associated with private keys, while excluding legitimate processes. This helps in identifying potential credential access attempts by filtering out known benign activities. + +### Possible investigation steps + +- Review the process details to identify the executable that attempted to access private key files, focusing on the process.args field to understand the specific files targeted. +- Check the process execution context, including the user account under which the process was running, to determine if it aligns with expected behavior or if it indicates potential compromise. +- Investigate the parent process of the suspicious activity to trace back the origin of the execution and assess if it was initiated by a legitimate application or script. +- Examine recent login and authentication logs for the user account associated with the process to identify any unusual access patterns or failed login attempts. +- Correlate the event with other security alerts or logs from the same host or user to identify any additional indicators of compromise or related suspicious activities. +- Verify if the host has any known vulnerabilities or misconfigurations that could have been exploited to execute the process, and assess the need for remediation. + +### False positive analysis + +- Processes related to legitimate software updates, such as LogiLuUpdater.exe and LogiBoltUpdater.exe, may trigger false positives. Users can handle these by adding these executables to the exclusion list if they are verified as part of regular update activities. +- Security tools like osqueryd.exe and various Guardicore agents may access files that match the pattern used in the detection rule. These should be excluded if they are confirmed to be part of authorized security operations. +- The use of openssl.exe in Splunk installations for legitimate purposes can be mistaken for suspicious activity. Users should verify the context of its use and exclude it if it aligns with expected behavior. +- Python scripts executed by Schneider Electric EcoStruxure software may access key files as part of their normal operation. If these scripts are verified as non-threatening, they should be added to the exclusion list. +- The icacls.exe utility in Windows system32 directory may be used in administrative scripts that access key files. Confirm the legitimacy of these scripts and exclude them if they are part of routine administrative tasks. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule that are attempting to access private key files. +- Conduct a thorough review of the system's access logs to identify any unauthorized access or data exfiltration attempts that may have occurred. +- Change all potentially compromised private keys and associated credentials immediately to prevent unauthorized access using these keys. +- Implement additional monitoring on the affected system and similar systems to detect any further attempts to access private keys or other sensitive files. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign. +- Review and update access controls and permissions to ensure that only authorized processes and users have access to private key files, reducing the risk of future unauthorized access attempts.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_aws_rds_snapshot_created.toml b/rules_building_block/defense_evasion_aws_rds_snapshot_created.toml index f825349247d..f2a6ddeb46a 100644 --- a/rules_building_block/defense_evasion_aws_rds_snapshot_created.toml +++ b/rules_building_block/defense_evasion_aws_rds_snapshot_created.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2024/06/22" integration = ["aws"] maturity = "production" -updated_date = "2024/06/25" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -45,6 +45,40 @@ query = ''' event.dataset: "aws.cloudtrail" and event.provider: "rds.amazonaws.com" and event.action: ("CreateDBSnapshot" or "CreateDBClusterSnapshot") and event.outcome: "success" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS RDS DB Snapshot Created +AWS RDS DB Snapshots are backups of databases that ensure data recovery and continuity. However, adversaries may exploit this feature to bypass security controls or erase traces by reverting databases to previous states. The detection rule monitors successful snapshot creation events, serving as a foundational element to correlate with other alerts, thereby identifying potential misuse indicative of defense evasion tactics. + +### Possible investigation steps + +- Review the event details in AWS CloudTrail for the specific snapshot creation event, focusing on the event.provider as "rds.amazonaws.com" and event.action as "CreateDBSnapshot" or "CreateDBClusterSnapshot" to confirm the snapshot creation. +- Identify the IAM user or role (event.userIdentity) associated with the snapshot creation to determine if the action was performed by an authorized entity or if it appears suspicious. +- Check the event.sourceIPAddress to verify the origin of the request and assess if it aligns with expected network locations or if it indicates potential unauthorized access. +- Investigate the timing of the snapshot creation event in relation to other activities in the AWS environment to identify any unusual patterns or sequences that might suggest malicious intent. +- Correlate this snapshot creation event with other security alerts or logs to identify any concurrent or subsequent actions that could indicate an attempt to evade defenses or cover tracks. +- Review the AWS RDS instance's recent activity and configuration changes to assess if there have been any unauthorized modifications or access attempts that could be related to the snapshot creation. + +### False positive analysis + +- Routine database maintenance activities by authorized personnel can trigger snapshot creation events. To manage this, create exceptions for known maintenance schedules or specific user accounts responsible for these tasks. +- Automated backup solutions may regularly create snapshots as part of their operation. Identify and exclude these automated processes by filtering events based on the source or associated tags. +- Development and testing environments often involve frequent snapshot creation for testing purposes. Exclude these environments by using environment-specific identifiers or tags in your filtering criteria. +- Third-party integrations or services that require snapshot creation for functionality can generate false positives. Review and whitelist these services by their unique identifiers or API calls. +- Ensure that any exclusion rules are regularly reviewed and updated to reflect changes in infrastructure or operational practices to maintain security integrity. + +### Response and remediation + +- Immediately review the AWS CloudTrail logs to identify the source of the snapshot creation, including the IAM user or role involved, and verify if the action was authorized. +- Temporarily revoke or restrict permissions for the identified IAM user or role to prevent further unauthorized snapshot creations. +- Assess the integrity of the database by comparing the current state with the snapshot to ensure no unauthorized changes have been made. +- If unauthorized activity is confirmed, initiate a rollback to a known good state using a verified snapshot, ensuring that the compromised snapshot is not used. +- Notify the security operations team and relevant stakeholders about the incident for further investigation and potential escalation. +- Implement additional monitoring and alerting for unusual snapshot creation activities, focusing on deviations from normal patterns. +- Review and update IAM policies to enforce the principle of least privilege, ensuring only necessary permissions are granted for snapshot creation.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_cmd_copy_binary_contents.toml b/rules_building_block/defense_evasion_cmd_copy_binary_contents.toml index 45e62b40635..ff4306e1095 100644 --- a/rules_building_block/defense_evasion_cmd_copy_binary_contents.toml +++ b/rules_building_block/defense_evasion_cmd_copy_binary_contents.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/23" integration = ["endpoint", "windows", "system"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -40,6 +40,40 @@ process where host.os.type == "windows" and event.type == "start" and (process.args : "type" and process.args : (">", ">>")) or (process.args : "copy" and process.args : "/b")) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Binary Content Copy via Cmd.exe + +Cmd.exe, a command-line interpreter on Windows, is often exploited by attackers to reconstruct binary files from fragments using commands like 'type' and 'copy /b'. This technique allows adversaries to evade detection by assembling malicious payloads directly on the target system. The detection rule identifies such activities by monitoring for specific command patterns indicative of binary reassembly, thus alerting analysts to potential threats. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of cmd.exe with arguments related to 'type' and 'copy /b', as these are indicative of binary reassembly attempts. +- Examine the parent process of the cmd.exe instance to determine if it was spawned by a legitimate application or a suspicious process, which could provide context on how the command was initiated. +- Check the file paths and names involved in the 'type' and 'copy /b' commands to identify any unusual or unauthorized files being manipulated, which may indicate malicious intent. +- Investigate the user account associated with the cmd.exe process to assess whether the activity aligns with the user's typical behavior or if the account may be compromised. +- Correlate this event with other security alerts or logs from the same host or user to identify any patterns or additional indicators of compromise that could suggest a broader attack campaign. + +### False positive analysis + +- System administrators may use cmd.exe to concatenate log files or other non-malicious binary data. To handle this, create exceptions for known administrative scripts or processes that frequently use the 'type' or 'copy /b' commands. +- Backup or maintenance scripts might use similar command patterns for legitimate purposes. Identify these scripts and exclude them from triggering alerts by specifying their file paths or process hashes in the monitoring tool. +- Software installations or updates might involve the use of cmd.exe to manage binary files. Monitor installation logs and whitelist these activities when they are verified as part of legitimate software deployment processes. +- Developers or IT personnel might use cmd.exe for testing or debugging purposes. Establish a list of trusted users or machines where such activities are expected and exclude them from the rule's scope. +- Automated tasks or scheduled jobs that involve file manipulation using cmd.exe could trigger false positives. Review scheduled tasks and exclude those that are part of routine operations from the detection rule. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further spread of the potential malicious payload. +- Terminate any suspicious cmd.exe processes identified by the detection rule to halt ongoing binary reassembly activities. +- Conduct a forensic analysis of the affected system to identify and remove any malicious binaries that may have been assembled and executed. +- Review and restore any altered or deleted system files from a known good backup to ensure system integrity. +- Escalate the incident to the security operations center (SOC) for further investigation and correlation with other potential threats in the environment. +- Implement additional monitoring on the affected system and similar endpoints to detect any recurrence of the binary reassembly activity. +- Update endpoint protection and intrusion detection systems with the latest threat intelligence to enhance detection capabilities against similar tactics.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_cmstp_execution.toml b/rules_building_block/defense_evasion_cmstp_execution.toml index 5e901e34f2b..fbe5d758f3b 100644 --- a/rules_building_block/defense_evasion_cmstp_execution.toml +++ b/rules_building_block/defense_evasion_cmstp_execution.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/24" integration = ["endpoint", "windows", "system"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -42,6 +42,40 @@ query = ''' process where host.os.type == "windows" and event.type == "start" and process.name : "cmstp.exe" and process.args == "/s" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Defense Evasion via CMSTP.exe + +CMSTP.exe is a legitimate Windows utility used to install network profiles via INF files. However, attackers can exploit it to execute malicious code by crafting INF files with harmful commands. The detection rule identifies suspicious activity by monitoring the execution of CMSTP.exe with specific arguments, flagging potential misuse for defense evasion tactics. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of CMSTP.exe with the argument "/s" in the event logs, as this matches the suspicious activity pattern. +- Investigate the parent process of CMSTP.exe to determine if it was launched by a legitimate application or a potentially malicious one. +- Examine the associated INF file used during the execution to identify any unusual or malicious commands that may have been embedded. +- Check the user account under which CMSTP.exe was executed to assess if it aligns with expected behavior or if it indicates potential compromise. +- Analyze recent system changes or installations around the time of the alert to identify any unauthorized or suspicious modifications. +- Correlate this event with other security alerts or logs to identify patterns or additional indicators of compromise that may suggest a broader attack campaign. + +### False positive analysis + +- Legitimate network profile installations may trigger the rule if CMSTP.exe is used with the /s argument. To manage this, identify and whitelist specific network profiles or installation scripts that are known and trusted within your organization. +- Automated system management tools might use CMSTP.exe for legitimate purposes. Review and document these tools, then create exceptions for their known behaviors to prevent unnecessary alerts. +- Scheduled tasks or scripts that regularly execute CMSTP.exe for maintenance or configuration purposes can be excluded by identifying their specific command-line patterns and adding them to an exception list. +- User-initiated actions, such as manual network configuration changes, might also cause false positives. Educate users on the implications of using CMSTP.exe and establish a process for reporting legitimate use cases to the security team for review and potential exclusion. + +### Response and remediation + +- Isolate the affected system from the network to prevent further execution of potentially malicious code and lateral movement. +- Terminate any running instances of CMSTP.exe that are executing with suspicious arguments, such as "/s", to halt any ongoing malicious activity. +- Conduct a thorough review of the INF files associated with the CMSTP.exe execution to identify and remove any malicious commands or scripts. +- Restore the system from a known good backup if malicious activity is confirmed and system integrity is compromised. +- Update and patch the operating system and all software to the latest versions to mitigate exploitation of known vulnerabilities. +- Implement application whitelisting to prevent unauthorized execution of CMSTP.exe and other system binaries that can be abused for proxy execution. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to assess the potential impact on the broader network.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_collection_masquerading_unusual_archive_file_extension.toml b/rules_building_block/defense_evasion_collection_masquerading_unusual_archive_file_extension.toml index e59ad5a89c1..c6bff02aeb7 100644 --- a/rules_building_block/defense_evasion_collection_masquerading_unusual_archive_file_extension.toml +++ b/rules_building_block/defense_evasion_collection_masquerading_unusual_archive_file_extension.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/09/25" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -53,6 +53,41 @@ file where host.os.type == "windows" and event.action != "deletion" and not (process.executable : "?:\\Windows\\System32\\inetsrv\\w3wp.exe" and file.path : "?:\\inetpub\\temp\\IIS Temporary Compressed Files\\*") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Archive File with Unusual Extension + +Archive files are commonly used for data compression and storage, often identified by specific headers. Adversaries may exploit this by disguising archives with extensions typical of images, audio, or documents to bypass security measures. The detection rule identifies such anomalies by checking for archive headers paired with unusual extensions, flagging potential masquerading attempts while excluding legitimate system processes. + +### Possible investigation steps + +- Review the file path and name to determine if it aligns with typical user or system activity, focusing on unusual directories or naming conventions. +- Examine the file header bytes to confirm the file type and verify if it matches the expected format for the extension used. +- Investigate the process that created or modified the file, especially if it is not a known or legitimate system process, to identify potential malicious activity. +- Check the user account associated with the file creation or modification for any signs of compromise or unusual behavior. +- Analyze recent network activity from the host to identify any suspicious connections or data exfiltration attempts that may correlate with the file creation. +- Review historical alerts or logs for the host to identify any patterns or previous incidents that might indicate ongoing malicious activity. + +### False positive analysis + +- System-generated temporary files may trigger false positives, especially in environments where web servers like IIS are used. To mitigate this, ensure that the rule excludes paths such as "?:\\inetpub\\temp\\IIS Temporary Compressed Files\\*". +- Legitimate software installations or updates might create archive files with unusual extensions as part of their process. Identify these processes and consider adding them to an exception list if they are verified as non-threatening. +- Some backup or synchronization tools may use non-standard extensions for archive files. Review the tools in use within your environment and exclude their specific file paths or processes if they are known to be safe. +- Custom applications developed in-house might use unconventional file extensions for archives. Work with development teams to understand these applications and exclude their file paths or processes as needed. +- Regularly review and update the list of excluded processes and paths to ensure that only verified non-threatening behaviors are excluded, maintaining the effectiveness of the detection rule. + +### Response and remediation + +- Isolate the affected system from the network to prevent potential lateral movement or data exfiltration by the adversary. +- Terminate any suspicious processes associated with the unusual archive file creation, especially those not originating from legitimate system processes. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or software. +- Restore any altered or deleted files from backups, ensuring that the backup is clean and free from any malicious alterations. +- Review and update file association settings and policies to prevent unauthorized applications from executing or creating files with mismatched extensions and headers. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement additional monitoring and alerting for similar activities across the network to enhance detection and response capabilities for future attempts.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_communication_apps_suspicious_child_process.toml b/rules_building_block/defense_evasion_communication_apps_suspicious_child_process.toml index 60798ca9d0f..2a3e248240c 100644 --- a/rules_building_block/defense_evasion_communication_apps_suspicious_child_process.toml +++ b/rules_building_block/defense_evasion_communication_apps_suspicious_child_process.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/08/04" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/31" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -253,6 +253,41 @@ process where host.os.type == "windows" and event.type == "start" and ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Communication App Child Process + +Communication apps like Slack, WebEx, and Teams are integral to modern workflows, facilitating collaboration. However, adversaries can exploit these apps by spawning unauthorized child processes, potentially masquerading as legitimate ones or exploiting vulnerabilities to execute malicious code. The detection rule identifies such anomalies by monitoring child processes of these apps, ensuring they are trusted and signed by recognized entities. This helps in identifying potential threats that deviate from expected behavior, thus safeguarding against unauthorized access and execution. + +### Possible investigation steps + +- Review the process details, including the parent process name and executable path, to confirm if the child process is expected or unusual for the communication app in question. +- Check the code signature of the suspicious child process to determine if it is trusted and signed by a recognized entity, as specified in the query. +- Investigate the command line arguments of the child process to identify any potentially malicious or unexpected commands being executed. +- Correlate the event with other logs or alerts to identify any related suspicious activities or patterns, such as repeated unauthorized child process executions. +- Assess the user account associated with the process to determine if it has been compromised or is exhibiting unusual behavior. +- Examine the network activity of the affected system to identify any suspicious outbound connections that may indicate data exfiltration or communication with a command and control server. + +### False positive analysis + +- Legitimate software updates or installations may trigger the rule if they spawn child processes from communication apps. Users can create exceptions for known update processes by verifying their code signatures and paths. +- Custom scripts or automation tools that interact with communication apps might be flagged. Users should ensure these scripts are signed and located in trusted directories, then add them to the exception list. +- Certain administrative tasks, such as using command-line tools like cmd.exe or powershell.exe, may be mistakenly identified as suspicious. Users can whitelist specific command lines or arguments that are regularly used in their environment. +- Some third-party integrations with communication apps may generate child processes that are not inherently malicious. Users should verify the legitimacy of these integrations and add them to the trusted list if they are deemed safe. +- Regularly review and update the list of trusted code signatures and executable paths to ensure that legitimate processes are not inadvertently flagged as suspicious. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or execution of malicious code. +- Terminate any suspicious child processes identified by the detection rule that are not signed by recognized entities or are executing from unexpected locations. +- Conduct a thorough review of the affected communication app's logs and configurations to identify any unauthorized changes or access patterns. +- Restore the affected system from a known good backup if malicious activity is confirmed, ensuring that the backup is free from compromise. +- Update the communication app and all related software to the latest versions to patch any known vulnerabilities that may have been exploited. +- Implement application whitelisting to ensure only trusted and signed applications can execute, reducing the risk of similar threats. +- Escalate the incident to the security operations center (SOC) or relevant security team for further investigation and to assess the potential impact on other systems.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_dll_hijack.toml b/rules_building_block/defense_evasion_dll_hijack.toml index 68d23e22874..f74dc8391fb 100644 --- a/rules_building_block/defense_evasion_dll_hijack.toml +++ b/rules_building_block/defense_evasion_dll_hijack.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/12" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -79,6 +79,40 @@ library where host.os.type == "windows" and "553451008520a5f0110d84192cba40208fb001c27454f946e85e6fb2e6553292" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Unsigned DLL Loaded by a Trusted Process + +In Windows environments, trusted processes are often digitally signed to ensure integrity and authenticity. Adversaries exploit this by loading unsigned DLLs into these processes, effectively masking malicious activities. The detection rule identifies such anomalies by checking for unsigned DLLs loaded by trusted processes, focusing on recent file modifications and excluding known safe hashes, thus highlighting potential threats. + +### Possible investigation steps + +- Review the process code signature status to confirm the legitimacy of the trusted process that loaded the unsigned DLL. This can help determine if the process itself has been compromised. +- Examine the file creation and modification times of the DLL using the fields dll.Ext.relative_file_creation_time and dll.Ext.relative_file_name_modify_time to assess if the DLL was recently altered or created, which might indicate malicious activity. +- Investigate the path of the DLL and the process executable using the dll.path and process.executable fields to verify if the DLL is located in an expected directory or if it is suspiciously placed in the application's directory. +- Check the user ID associated with the process using the user.id field to determine if the process was executed by a legitimate user or a system account, excluding the known safe user ID "S-1-5-18". +- Cross-reference the DLL's SHA-256 hash against known safe hashes to ensure it is not a false positive. If the hash is not listed in the known safe hashes, further analysis of the DLL's behavior and origin is warranted. + +### False positive analysis + +- Unsigned DLLs from legitimate software updates or installations may trigger alerts. Users can manage this by maintaining an updated list of known safe hashes and excluding them from the rule. +- Virtual devices like "Virtual DVD-ROM" or "Virtual Disk" may load unsigned DLLs as part of their normal operation. Consider excluding these specific device product IDs if they are frequently used in your environment. +- System processes running under the local system account (user ID "S-1-5-18") might load unsigned DLLs during legitimate operations. Ensure these are excluded to prevent unnecessary alerts. +- Frequent modifications to DLLs in development environments can cause false positives. Implement exceptions for directories or processes associated with development activities to reduce noise. +- Regularly review and update the list of excluded hashes to ensure it reflects the current state of trusted software and system updates, minimizing the risk of overlooking new threats. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any ongoing malicious activity. +- Terminate the trusted process that has loaded the unsigned DLL to stop any malicious actions being executed under its context. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or remnants. +- Review and restore any modified or deleted system files from a known good backup to ensure system integrity and functionality. +- Analyze the unsigned DLL and its associated process to determine the source and method of compromise, documenting findings for further investigation. +- Escalate the incident to the security operations center (SOC) or incident response team for a deeper investigation and to assess the potential impact on other systems. +- Implement application whitelisting and enhance monitoring to prevent similar threats, ensuring that only digitally signed and verified DLLs are allowed to load into trusted processes.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_dotnet_clickonce_dfsvc_netcon.toml b/rules_building_block/defense_evasion_dotnet_clickonce_dfsvc_netcon.toml index 79332fc5371..2ae63164fea 100644 --- a/rules_building_block/defense_evasion_dotnet_clickonce_dfsvc_netcon.toml +++ b/rules_building_block/defense_evasion_dotnet_clickonce_dfsvc_netcon.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/25" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -36,6 +36,41 @@ sequence by user.id with maxspan=5s process.name : "rundll32.exe" and process.command_line : ("*dfshim*ShOpenVerbApplication*", "*dfshim*#*")] [network where host.os.type == "windows" and process.name : "dfsvc.exe"] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Execution via Microsoft DotNet ClickOnce Host + +Microsoft DotNet ClickOnce is a deployment technology that allows users to install and run applications by clicking a link in a web browser. Adversaries may exploit this by using trusted processes like Dfsvc.exe to execute malicious payloads, bypassing security measures. The detection rule identifies suspicious activity by monitoring for specific process behaviors and network activities, indicating potential misuse of ClickOnce for defense evasion. + +### Possible investigation steps + +- Review the process execution details for rundll32.exe, focusing on the command line arguments to confirm the presence of dfshim and ShOpenVerbApplication or dfshim with a hash (#) symbol, which may indicate suspicious activity. +- Investigate the network activity associated with dfsvc.exe to identify any unusual or unauthorized connections, especially those that might be communicating with external or suspicious IP addresses. +- Correlate the user.id associated with the alert to determine if the activity aligns with expected behavior for that user or if it appears anomalous. +- Check the parent process of rundll32.exe to understand how it was initiated and whether it was spawned by a legitimate application or process. +- Examine recent file modifications or creations in the user's profile or temporary directories that might be related to the ClickOnce deployment, looking for any unexpected or malicious files. +- Review security logs and alerts for any additional indicators of compromise or related suspicious activities around the same timeframe to assess the broader context of the potential threat. + +### False positive analysis + +- Legitimate ClickOnce applications may trigger the rule when they are installed or updated. Users can create exceptions for known trusted applications by whitelisting their specific command lines or network behaviors. +- Software development environments that utilize ClickOnce for deploying applications might frequently trigger this rule. Exclude these environments by identifying and allowing specific user accounts or machines involved in the development process. +- Automated deployment systems that use ClickOnce for distributing updates can cause false positives. Implement exceptions for these systems by monitoring and excluding their typical network and process patterns. +- Internal IT tools that leverage ClickOnce for remote installations may be flagged. Identify these tools and exclude their associated processes and network activities from the rule. +- Regularly review and update the list of exceptions to ensure that only verified and non-threatening activities are excluded, maintaining the effectiveness of the detection rule. + +### Response and remediation + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate the suspicious processes, specifically rundll32.exe and dfsvc.exe, to stop the execution of any potentially malicious payloads. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or remnants. +- Review and analyze network logs to identify any unauthorized or suspicious connections initiated by dfsvc.exe, and block any malicious IP addresses or domains. +- Restore the system from a known good backup if any critical system files or applications have been compromised. +- 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 application whitelisting to prevent unauthorized applications from executing, and ensure that only trusted ClickOnce applications are allowed to run.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_download_susp_extension.toml b/rules_building_block/defense_evasion_download_susp_extension.toml index 0e65e8b4c34..82a6f512170 100644 --- a/rules_building_block/defense_evasion_download_susp_extension.toml +++ b/rules_building_block/defense_evasion_download_susp_extension.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/27" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -57,6 +57,40 @@ file where host.os.type == "windows" and event.type == "creation" and ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 with Suspicious Extension Downloaded + +In Windows environments, certain file extensions can be exploited for unauthorized code execution. Adversaries may download files with these extensions to bypass security measures and execute malicious payloads. The detection rule identifies such files downloaded from external sources, excluding known safe paths and processes, to flag potential threats. This helps in early detection of defense evasion tactics. + +### Possible investigation steps + +- Review the file path and extension to determine if the file is located in a known safe directory or if it matches any of the excluded paths in the query. +- Check the file's zone identifier to confirm it was downloaded from an external source, as indicated by a value greater than 1. +- Investigate the process that created the file, focusing on whether it is a known and trusted application, especially if the process name is not Teams.exe or lacks a trusted code signature. +- Analyze the file's metadata and properties to identify any unusual characteristics or discrepancies that could indicate tampering or malicious intent. +- Correlate the event with other security logs and alerts to identify any related suspicious activities or patterns that could suggest a broader attack campaign. +- Consult threat intelligence sources to determine if the file extension or any associated indicators of compromise (IOCs) are linked to known malware or threat actors. + +### False positive analysis + +- Files downloaded by trusted applications like Microsoft Teams may trigger false positives when they use the msix extension. To handle this, ensure that the process name is Teams.exe and the code signature is trusted, then exclude these paths from the rule. +- Temporary files created by Windows Package Manager (WinGet) in specific directories can be mistakenly flagged. Exclude paths such as AppData\\Local\\Temp\\WinGet and systemprofile\\AppData\\Local\\Microsoft\\WinGet\\State\\defaultState\\Microsoft.PreIndexed.Package\\Microsoft.Winget.Source to prevent these false alerts. +- Regularly review and update the list of trusted applications and paths to ensure that legitimate activities are not incorrectly identified as threats. This helps maintain the balance between security and operational efficiency. +- Consider implementing a whitelist for known safe file extensions and paths that are frequently used in your organization to reduce the number of false positives and streamline the detection process. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of potential malicious activity. +- Terminate any suspicious processes associated with the downloaded file, especially if they match the process names or paths identified in the detection rule. +- Delete the suspicious file from the system to prevent accidental execution or further exploitation. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional threats or malware. +- Review system logs and network traffic to identify any signs of lateral movement or data exfiltration attempts, and take appropriate action to contain any identified threats. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement additional monitoring and alerting for the specific file extensions and paths identified in the detection rule to enhance detection of similar threats in the future.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_execution_via_visualstudio_prebuildevent.toml b/rules_building_block/defense_evasion_execution_via_visualstudio_prebuildevent.toml index 2eecbdb9c35..8dc8e03a3cf 100644 --- a/rules_building_block/defense_evasion_execution_via_visualstudio_prebuildevent.toml +++ b/rules_building_block/defense_evasion_execution_via_visualstudio_prebuildevent.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/26" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -74,6 +74,40 @@ sequence with maxspan=1m "*Common\\..\\..\\BuildTools\\*")) ] by process.parent.entity_id ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Execution via MS VisualStudio Pre/Post Build Events + +Microsoft Visual Studio allows developers to automate tasks using pre/post build events, which execute commands during the build process. Adversaries can exploit this by injecting malicious commands into these events, executing harmful code under the guise of a legitimate build. The detection rule identifies suspicious command executions linked to Visual Studio builds, focusing on unusual parent-child process relationships and command patterns, while excluding known safe operations, to flag potential misuse. + +### Possible investigation steps + +- Review the process tree to identify the parent-child relationship, focusing on instances where MSBuild.exe spawns cmd.exe or other suspicious processes like powershell.exe or rundll32.exe. +- Examine the command line arguments of the suspicious process to determine if they match known malicious patterns or if they deviate from typical build operations. +- Check the file path and content of any scripts or executables in the Temp directory (e.g., tmp*.exec.cmd) to identify potential malicious payloads. +- Investigate the user account associated with the process execution to determine if it aligns with expected developer activity or if it indicates unauthorized access. +- Correlate the alert with recent changes in the Visual Studio project files to identify any unauthorized modifications to pre/post build events. +- Look for additional indicators of compromise on the host, such as unusual network connections or file modifications, that may suggest further malicious activity. + +### False positive analysis + +- Visual Studio build scripts that legitimately use cmd.exe or powershell.exe for automation tasks may trigger false positives. Users can handle these by adding specific script paths or command patterns to the exclusion list. +- Developers using MSBuild.exe for legitimate build processes might see false positives if their processes match the suspicious patterns. Exclude known safe MSBuild.exe paths from detection to mitigate this. +- Automated build systems that utilize tools like vswhere.exe or git log for version control and project management can be mistakenly flagged. Exclude these command lines from the detection rule to prevent unnecessary alerts. +- Custom scripts or tools that interact with Visual Studio projects, such as applocal.ps1 or MediaCache.ps1, may cause false positives. Users should identify and exclude these specific scripts if they are part of regular, non-malicious operations. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further execution of malicious commands and potential lateral movement. +- Terminate any suspicious processes identified by the detection rule, particularly those involving cmd.exe or other flagged executables like powershell.exe, MSHTA.EXE, or rundll32.exe. +- Conduct a thorough review of the Visual Studio project files and build scripts to identify and remove any unauthorized or malicious pre/post build commands. +- Restore the affected system from a known good backup to ensure any backdoor or malicious modifications are completely removed. +- Implement application whitelisting to restrict the execution of unauthorized scripts and executables, focusing on those commonly abused in this context. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised. +- Enhance monitoring and logging for Visual Studio build processes and related command executions to detect similar threats in the future.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_file_permission_modification.toml b/rules_building_block/defense_evasion_file_permission_modification.toml index f58bdff58c1..8ecb20c862e 100644 --- a/rules_building_block/defense_evasion_file_permission_modification.toml +++ b/rules_building_block/defense_evasion_file_permission_modification.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/12" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -43,6 +43,42 @@ not ( process.args : ("C:\\ProgramData\\Lenovo\\*", "C:\\ProgramData\\Adobe\\*", "C:\\ProgramData\\ASUS\\ASUS*") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 and Directory Permissions Modification + +File and directory permissions in Windows environments control access and modification rights, crucial for maintaining system integrity. Adversaries may exploit utilities like `icacls`, `cacls`, `takeown`, and `attrib` to alter permissions, enabling unauthorized access or deletion. The detection rule identifies suspicious use of these utilities, excluding known legitimate processes, to flag potential threats. + +### Possible investigation steps + +- Review the process details to identify the specific utility used (icacls.exe, cacls.exe, takeown.exe, or attrib.exe) and the arguments passed, as these can indicate the type of permission modification attempted. +- Check the user ID associated with the process to determine if it is a known or unknown user, especially since the rule excludes the system account (S-1-5-18). +- Investigate the file or directory path targeted by the permission modification to assess its importance and potential impact on the system. +- Examine the process execution context, including the parent process and command line, to understand how the utility was invoked and whether it aligns with typical user behavior. +- Correlate the event with other security alerts or logs around the same timeframe to identify any related suspicious activities or patterns. +- Verify if the process arguments match any of the excluded paths (e.g., C:\\ProgramData\\Lenovo\\*) to ensure the alert is not a false positive due to legitimate software operations. +- Assess the risk and potential impact of the permission change on system security and data integrity, considering the severity and risk score provided by the rule. + +### False positive analysis + +- Legitimate software installations or updates may trigger permission changes, especially from trusted vendors like Lenovo, Adobe, or ASUS. To manage these, add specific paths to the exclusion list, as shown in the rule. +- System administrators often use utilities like icacls or takeown for routine maintenance. Identify and exclude these activities by correlating with known administrative tasks or by excluding specific user IDs associated with admin accounts. +- Automated scripts or scheduled tasks that modify file permissions for backup or system optimization purposes can be mistaken for threats. Review and whitelist these scripts by their execution paths or associated user accounts. +- Security software or system management tools may alter permissions as part of their normal operation. Verify these tools and exclude their processes or paths to prevent false alerts. +- Temporary permission changes during software testing or development can be flagged. Coordinate with development teams to identify and exclude these activities during known testing periods. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or potential lateral movement by the threat actor. +- Terminate any suspicious processes identified in the alert, such as instances of `icacls.exe`, `cacls.exe`, `takeown.exe`, or `attrib.exe` that match the query criteria. +- Conduct a thorough review of the modified file and directory permissions to assess the extent of unauthorized changes and restore them to their original state. +- Check for any unauthorized user accounts or changes in user privileges that may have been created or altered during the incident and revert them to their legitimate state. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised. +- Implement additional monitoring on the affected system and similar environments to detect any recurrence of the threat, focusing on the specific utilities and arguments used in the attack. +- Review and update access control policies and permissions to ensure they adhere to the principle of least privilege, reducing the risk of similar attacks in the future.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_generic_deletion.toml b/rules_building_block/defense_evasion_generic_deletion.toml index 845c9e5546e..d9914104cba 100644 --- a/rules_building_block/defense_evasion_generic_deletion.toml +++ b/rules_building_block/defense_evasion_generic_deletion.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/13" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -48,6 +48,40 @@ process where host.os.type == "windows" and event.type == "start" and (process.name: "powershell.exe" and process.args: ("*rmdir", "rm", "rd", "*Remove-Item*", "del", "*]::Delete(*")) ) and not user.id : "S-1-5-18" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 or Directory Deletion Command + +In Windows environments, commands like `rundll32.exe`, `reg.exe`, `cmd.exe`, and `powershell.exe` are integral for system management, allowing users to delete files or directories. Adversaries exploit these to erase logs or evidence of their activities, aiding in defense evasion. The detection rule identifies suspicious deletions by monitoring these command executions, excluding benign paths, and flagging non-system users, thus highlighting potential malicious activity. + +### Possible investigation steps + +- Review the process details to identify the specific command executed, focusing on the process name and arguments, such as "rundll32.exe", "reg.exe", "cmd.exe", or "powershell.exe", and their respective arguments. +- Check the user ID associated with the process execution to determine if it is a non-system user, as the rule excludes the system user ID "S-1-5-18". +- Investigate the context of the file or directory targeted for deletion by examining the process arguments, especially if they involve critical directories or files like logs or browser history. +- Correlate the event with other recent activities on the host to identify any patterns or sequences that suggest malicious intent, such as multiple deletion attempts or other suspicious processes. +- Assess the risk and impact of the deletion by determining if any important system or application logs were removed, which could hinder further investigation or system functionality. + +### False positive analysis + +- Routine system maintenance or software updates may trigger file or directory deletions. Users can create exceptions for known maintenance scripts or update processes to prevent false positives. +- Automated cleanup tools like disk cleanup utilities or third-party software may use similar commands. Identify these tools and exclude their specific paths or user accounts from the rule. +- User-initiated actions such as clearing browser history or temporary files can be mistaken for malicious activity. Educate users on the implications of these actions and consider excluding common user directories from monitoring. +- Development environments often involve frequent file deletions during build processes. Exclude directories or processes associated with development tools to reduce noise. +- Backup or synchronization software might delete files as part of their normal operation. Identify these applications and exclude their operations from the rule to avoid unnecessary alerts. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, such as those involving `rundll32.exe`, `reg.exe`, `cmd.exe`, or `powershell.exe` with deletion arguments. +- Conduct a forensic analysis of the affected system to identify any deleted files or directories, focusing on logs, browser history, or other critical data that may have been targeted. +- Restore any critical files or logs from backups if they were deleted and are necessary for ongoing operations or investigations. +- Review user account activity, especially for non-system users flagged by the detection rule, to determine if any accounts have been compromised and reset credentials as necessary. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat is part of a larger attack campaign. +- Implement additional monitoring and alerting for similar command executions to enhance detection and response capabilities for future incidents.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_indirect_command_exec_pcalua_forfiles.toml b/rules_building_block/defense_evasion_indirect_command_exec_pcalua_forfiles.toml index 68ad590b53a..3f200b71591 100644 --- a/rules_building_block/defense_evasion_indirect_command_exec_pcalua_forfiles.toml +++ b/rules_building_block/defense_evasion_indirect_command_exec_pcalua_forfiles.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/24" integration = ["endpoint", "windows", "system"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -42,6 +42,40 @@ query = ''' process where host.os.type == "windows" and event.type == "start" and process.parent.name : ("pcalua.exe", "forfiles.exe") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Indirect Command Execution via Forfiles/Pcalua + +Forfiles and pcalua.exe are legitimate Windows utilities used for file management and program compatibility tasks. Adversaries exploit these tools to execute commands indirectly, bypassing security controls. The detection rule identifies suspicious activity by monitoring process initiation events where these utilities are the parent process, indicating potential misuse for defense evasion. + +### Possible investigation steps + +- Review the process details to identify the command line arguments used with pcalua.exe or forfiles.exe to understand the intended action and potential impact. +- Check the parent process of pcalua.exe or forfiles.exe to determine how these utilities were invoked and assess if this aligns with expected behavior. +- Investigate the user account associated with the process initiation to verify if the activity is consistent with their typical behavior or if the account may be compromised. +- Examine recent system logs and security events for any related or suspicious activities that occurred around the same time as the alert. +- Correlate the alert with other security events or alerts to identify if this is part of a larger attack pattern or campaign. + +### False positive analysis + +- Routine administrative tasks may trigger alerts when forfiles.exe or pcalua.exe are used for legitimate file management or compatibility checks. To manage this, identify and document regular administrative scripts or tasks that use these utilities and create exceptions for these known activities. +- Software installations or updates often invoke pcalua.exe as part of their normal operation. Monitor and whitelist specific software installation processes that are known and trusted within your environment to reduce unnecessary alerts. +- Scheduled tasks or automated scripts that utilize forfiles.exe for file cleanup or management can generate false positives. Review and exclude these tasks by correlating them with scheduled task logs or known maintenance windows. +- Some third-party applications may use these utilities as part of their normal functionality. Identify these applications and consider creating exceptions based on the application's path or hash to prevent false alerts. +- User-initiated actions, such as compatibility troubleshooting, might involve pcalua.exe. Educate users on the implications of using these tools and establish a process for reporting legitimate use cases to security teams for exclusion. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes initiated by pcalua.exe or forfiles.exe to stop potential malicious activity. +- Conduct a thorough review of recent changes and scheduled tasks on the affected system to identify any unauthorized modifications or persistence mechanisms. +- Restore any altered or deleted files from a known good backup to ensure system integrity and functionality. +- Update and patch the affected system to close any vulnerabilities that may have been exploited by the adversary. +- Monitor the network for any further suspicious activity related to pcalua.exe or forfiles.exe to detect potential follow-up attacks. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_injection_from_msoffice.toml b/rules_building_block/defense_evasion_injection_from_msoffice.toml index 6d1c96172e8..2f06dbb7516 100644 --- a/rules_building_block/defense_evasion_injection_from_msoffice.toml +++ b/rules_building_block/defense_evasion_injection_from_msoffice.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/25" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -48,6 +48,41 @@ process where host.os.type == "windows" and event.action == "start" and "?:\\Windows\\Sys*\\ctfmon.exe", "?:\\Windows\\System32\\notepad.exe") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Process Injection from Malicious Document + +Process injection is a technique used by adversaries to execute malicious code within the address space of another process, often to evade detection. Microsoft Office applications, like Word and Excel, are common targets due to their widespread use and ability to run macros. The detection rule identifies unusual child processes spawned by these applications, focusing on suspicious arguments and executable paths, to flag potential exploitation attempts. + +### Possible investigation steps + +- Review the parent process details to confirm if the process name is one of the targeted Microsoft Office applications (excel.exe, powerpnt.exe, winword.exe) and verify the legitimacy of the parent process. +- Examine the child process executable path to determine if it matches the suspicious paths specified in the rule (e.g., "?:\\Windows\\SysWOW64\\*.exe", "?:\\Windows\\system32\\*.exe") and assess if the executable is expected or known to be used by the organization. +- Investigate the process arguments to understand the context of the process execution, especially since the rule flags processes with a single argument, which might indicate an attempt to obfuscate or hide malicious activity. +- Check the code signature of the executable to determine if it is trusted and verify the subject name to ensure it is not a spoofed or untrusted signature. +- Correlate the alert with any recent activity involving the same user or host to identify patterns or additional indicators of compromise, such as other unusual process executions or network connections. +- Review any related document files or email attachments that might have been opened around the time of the alert to identify potential sources of the malicious document or macro. + +### False positive analysis + +- Legitimate software updates or installations may trigger the rule if they are executed by Office applications. Users can create exceptions for known update processes by verifying their code signatures and adding them to a trusted list. +- Automated scripts or administrative tools that interact with Office applications might be flagged. Review these scripts and, if verified as safe, exclude their specific executable paths from the rule. +- Some enterprise applications may integrate with Office applications and spawn processes with similar characteristics. Identify these applications and exclude their executable paths or signatures to prevent false positives. +- Users running custom macros that launch legitimate processes could trigger the rule. Educate users on safe macro practices and consider excluding specific macros or processes if they are deemed non-threatening. +- System maintenance tasks that involve Office applications might be misidentified. Document these tasks and exclude their associated processes if they are confirmed to be safe. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any ongoing malicious activity. +- Terminate any suspicious processes identified by the alert, particularly those spawned by Microsoft Office applications with unusual arguments or paths. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious code or files. +- Review and analyze the parent Office document suspected of containing malicious macros to understand the scope of the threat and to prevent similar future incidents. +- Restore the affected system from a known good backup if any system integrity issues are detected, ensuring that the backup is free from any malicious code. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Update and enhance detection capabilities by reviewing and refining security monitoring rules to better identify similar threats in the future, leveraging insights from the current incident.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_installutil_command_activity.toml b/rules_building_block/defense_evasion_installutil_command_activity.toml index f0718951b7f..26cb68a3927 100644 --- a/rules_building_block/defense_evasion_installutil_command_activity.toml +++ b/rules_building_block/defense_evasion_installutil_command_activity.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/24" integration = ["endpoint", "windows", "system"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -46,6 +46,40 @@ query = ''' process where host.os.type == "windows" and event.type == "start" and process.name : "installutil.exe" and not user.id : "S-1-5-18" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 InstallUtil Activity + +InstallUtil is a legitimate Windows utility used for installing and uninstalling .NET applications by executing installer components. However, adversaries can exploit it to execute malicious code under the guise of a trusted process, evading security measures. The detection rule identifies suspicious InstallUtil activity by monitoring process starts on Windows systems, specifically flagging instances not initiated by the system account, which may indicate unauthorized use. + +### Possible investigation steps + +- Review the process details for the triggered alert, focusing on the user ID to identify the account that initiated the InstallUtil process, as it should not be the system account (S-1-5-18). +- Investigate the parent process of InstallUtil to determine how it was launched and assess if the parent process is legitimate or potentially malicious. +- Check the command-line arguments used with InstallUtil to identify any suspicious or unexpected parameters that could indicate malicious activity. +- Analyze the timeline of events around the InstallUtil process start to identify any related or preceding suspicious activities, such as file downloads or other process executions. +- Review the network activity associated with the user account and the host to identify any unusual outbound connections that could suggest data exfiltration or command-and-control communication. +- Correlate the alert with other security events or logs from the same host or user account to identify patterns or repeated suspicious behavior. + +### False positive analysis + +- Legitimate software installations by IT administrators may trigger the rule if InstallUtil is used for deploying .NET applications. To manage this, create exceptions for known administrative accounts or specific installation scripts. +- Automated deployment tools that utilize InstallUtil for legitimate software updates can cause false positives. Identify these tools and exclude their associated processes or user accounts from the rule. +- Development environments where developers frequently use InstallUtil for testing purposes might be flagged. Consider excluding specific development machines or user accounts from the rule to reduce noise. +- Scheduled tasks or scripts that use InstallUtil for routine maintenance or updates can be mistaken for malicious activity. Review and whitelist these tasks or scripts by their unique identifiers or execution paths. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized activity and potential lateral movement by the adversary. +- Terminate the suspicious InstallUtil process to stop any ongoing malicious activity and prevent further execution of unauthorized code. +- Conduct a thorough review of the affected system to identify any additional malicious files or processes that may have been introduced by the adversary. +- Restore the system from a known good backup if any unauthorized changes or malicious software are detected, ensuring that the backup is free from compromise. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited by the adversary. +- Monitor for any recurrence of similar activity by setting up alerts for InstallUtil executions not initiated by the system account, ensuring quick detection and response to future threats. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems may be affected.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_invalid_codesign_imageload.toml b/rules_building_block/defense_evasion_invalid_codesign_imageload.toml index 2017bffb2fb..459b67672b0 100644 --- a/rules_building_block/defense_evasion_invalid_codesign_imageload.toml +++ b/rules_building_block/defense_evasion_invalid_codesign_imageload.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/27" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -40,6 +40,41 @@ library where host.os.type == "windows" and event.action == "load" and "?:\\Windows\\System32\\DriverStore\\FileRepository\\*" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Image Loaded with Invalid Signature + +In Windows environments, code signing ensures the integrity and authenticity of binaries. Adversaries may exploit this by loading binaries with invalid signatures to masquerade as legitimate software, evading detection. The detection rule identifies such anomalies by scrutinizing signature errors and recent file modifications, excluding trusted system paths, to flag potential threats. + +### Possible investigation steps + +- Review the specific dll.name and process.name involved in the alert to understand which binary is attempting to load with an invalid signature. +- Check the dll.code_signature.status to determine the nature of the signature error, such as "errorUntrustedRoot" or "errorBadDigest", to assess the potential risk. +- Investigate the dll.Ext.relative_file_creation_time and dll.Ext.relative_file_name_modify_time to determine if the file was recently created or modified, which could indicate suspicious activity. +- Examine the dll.path to ensure it does not fall within trusted system paths, as the rule excludes paths like "?:\\Windows\\System32\\DriverStore\\FileRepository\\*". +- Correlate the event with other recent alerts or logs from the same host to identify any patterns or additional suspicious activities that might indicate a broader compromise. +- Consult threat intelligence sources to see if the binary or its signature error has been associated with known malicious activity or campaigns. + +### False positive analysis + +- System or vendor updates may load binaries with temporary invalid signatures. Monitor update schedules and correlate alerts with known update activities to verify legitimacy. +- Custom or in-house applications might not have valid signatures but are trusted within the organization. Create exceptions for these applications by specifying their paths or names in the exclusion list. +- Development or testing environments often use unsigned or self-signed binaries. Consider excluding these environments from the rule or adjusting the risk score to reflect their lower threat level. +- Security or monitoring tools may load unsigned components as part of their operation. Verify the legitimacy of these tools and exclude their paths if they are known and trusted. +- Temporary file modifications during legitimate software installations or updates can trigger alerts. Cross-reference with installation logs or schedules to confirm benign activity. + +### Response and remediation + +- Isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes associated with the loaded binary to halt any ongoing malicious activity. +- Verify the integrity of the affected binary by comparing it against a known good version or reinstalling it from a trusted source. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or artifacts. +- Review recent file modifications and system logs to identify any unauthorized changes or access, and restore any altered files from backups if necessary. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement additional monitoring and alerting for similar signature anomalies to enhance detection and response capabilities for future incidents.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_masquerading_browsers.toml b/rules_building_block/defense_evasion_masquerading_browsers.toml index 3ad0df05445..07be25f7c2d 100644 --- a/rules_building_block/defense_evasion_masquerading_browsers.toml +++ b/rules_building_block/defense_evasion_masquerading_browsers.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/08/02" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/31" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -157,6 +157,41 @@ process where host.os.type == "windows" and event.type == "start" and ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Masquerading as Browser Process + +Browsers are integral to user interaction with the web, often trusted and whitelisted in security policies. Adversaries exploit this trust by masquerading malicious processes as legitimate browser processes, bypassing security measures and deceiving users. The detection rule identifies anomalies in browser processes, such as unusual or unsigned certificates, to flag potential threats, ensuring that only verified processes are executed. + +### Possible investigation steps + +- Review the process name and executable path to determine if it matches any known legitimate browser processes or paths listed in the query. +- Check the process code signature details, specifically the subject name and trust status, to verify if the process is signed by a recognized and trusted entity. +- Investigate the parent process to understand how the suspicious process was initiated and assess if it aligns with typical browser launch behavior. +- Analyze the command-line arguments used by the process to identify any unusual or suspicious flags that may indicate malicious activity. +- Correlate the process start event with other security events or logs from the same host to identify any related suspicious activities or patterns. +- Consult threat intelligence sources to determine if the process name, executable path, or code signature has been associated with known threats or malware campaigns. + +### False positive analysis + +- Processes from legitimate software like HP Sure Click, Dynatrace, and Burp Suite may trigger false positives due to their use of Chrome executables. Users can mitigate this by adding exceptions for these specific paths and code signatures. +- Microsoft Edge WebView2 processes signed by trusted entities like Bromium, Amazon, or Code Systems Corporation might be flagged. To handle this, users should ensure these signatures are included in the allowlist. +- Firefox's default-browser-agent.exe signed by WATERFOX LIMITED can be a false positive. Users should verify the signature and add it to the trusted list if applicable. +- Chromium-based browser processes from trusted vendors such as Citrix, AVG, or NortonLifeLock may be incorrectly flagged. Users should confirm the legitimacy of these signatures and update the allowlist accordingly. +- Regularly review and update the list of trusted code signatures and executable paths to minimize false positives while maintaining security. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of potential malware or unauthorized access. +- Terminate any suspicious processes identified by the detection rule that are masquerading as legitimate browser processes. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or software. +- Review and validate the code signatures of all browser-related processes on the affected system to ensure they are from trusted sources. +- Restore any compromised systems from a known good backup to ensure system integrity and remove any persistent threats. +- 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 enhanced monitoring and logging for browser processes across the network to detect similar threats in the future and improve response times.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_masquerading_unusual_exe_file_extension.toml b/rules_building_block/defense_evasion_masquerading_unusual_exe_file_extension.toml index 7df37c1057b..df750959876 100644 --- a/rules_building_block/defense_evasion_masquerading_unusual_exe_file_extension.toml +++ b/rules_building_block/defense_evasion_masquerading_unusual_exe_file_extension.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/25" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -50,6 +50,40 @@ file where host.os.type == "windows" and event.action != "deletion" and not process.pid == 4 and not process.executable : "?:\\Program Files (x86)\\Trend Micro\\Client Server Security Agent\\Ntrtscan.exe" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Executable File with Unusual Extension + +Executable files are crucial for running applications, but adversaries may disguise them with non-executable extensions like images or documents to evade detection. This tactic, known as masquerading, exploits user trust and bypasses security filters. The detection rule identifies such anomalies by inspecting file headers for executable signatures, even if the extension suggests otherwise, thus flagging potential threats. + +### Possible investigation steps + +- Review the file path and name to determine if it aligns with typical user activity or known software installations, focusing on unusual directories or naming conventions. +- Examine the file header bytes to confirm the presence of the "MZ" signature, indicating an executable file, despite the non-executable extension. +- Check the file creation or modification timestamp to correlate with user activity or scheduled tasks, identifying any anomalies or unexpected changes. +- Investigate the process that created or modified the file, excluding known safe processes like "Ntrtscan.exe", to identify potentially malicious activity. +- Analyze the user account associated with the file creation or modification to determine if it has been compromised or is exhibiting unusual behavior. +- Search for any related alerts or logs that might indicate a broader attack pattern or additional compromised files on the system. + +### False positive analysis + +- Files from legitimate software installations or updates may trigger the rule if they use non-standard extensions. Users can create exceptions for known software paths or specific file hashes to prevent these alerts. +- Multimedia files with embedded executable content for legitimate purposes, such as self-extracting archives, might be flagged. Users should verify the source and purpose of such files and whitelist them if they are deemed safe. +- Security or system administration tools that use unconventional file extensions for executables could be mistakenly identified. Users can exclude these tools by specifying their file paths or process names in the rule configuration. +- Backup or recovery software that temporarily renames executable files with non-standard extensions during operations may cause false positives. Users should identify these processes and add them to the exclusion list to avoid unnecessary alerts. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of the potentially malicious executable file. +- Terminate any suspicious processes associated with the identified executable file to halt any ongoing malicious activity. +- Quarantine the suspicious file to prevent execution and further analysis, ensuring it is not accessible to users or other systems. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional threats. +- Review recent file creation and modification logs to identify any other files with unusual extensions that may have been missed and take appropriate action. +- Restore any affected files or systems from known good backups to ensure integrity and availability of data. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_masquerading_vlc_dll.toml b/rules_building_block/defense_evasion_masquerading_vlc_dll.toml index 63f9383bbda..2ff4acbe855 100644 --- a/rules_building_block/defense_evasion_masquerading_vlc_dll.toml +++ b/rules_building_block/defense_evasion_masquerading_vlc_dll.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/08/09" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/31" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -41,6 +41,41 @@ library where host.os.type == "windows" and event.action == "load" and and dll.code_signature.trusted == true ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Masquerading as VLC DLL + +VLC media player uses specific DLLs for its functionality, typically signed by VideoLAN to ensure authenticity. Adversaries may exploit this by creating malicious DLLs with similar names to blend into systems, bypassing security measures. The detection rule identifies such anomalies by flagging unsigned or improperly signed DLLs mimicking VLC, focusing on defense evasion and persistence tactics. + +### Possible investigation steps + +- Review the alert details to identify the specific DLL name that triggered the alert, focusing on "libvlc.dll", "libvlccore.dll", or "axvlc.dll". +- Check the code signature details of the flagged DLL to confirm the absence of a valid signature from "VideoLAN" or the specific subject name "716F2E5E-A03A-486B-BC67-9B18474B9D51". +- Investigate the file path and location of the suspicious DLL to determine if it resides in a directory typically associated with VLC installations or if it is in an unusual location. +- Analyze the process that loaded the DLL, including the parent process, to understand the context of its execution and identify any potentially malicious activity. +- Correlate the event with other security logs or alerts to identify any related suspicious activities or patterns, such as recent downloads or installations that could have introduced the DLL. +- Conduct a reputation check on the DLL file hash using threat intelligence sources to determine if it is known to be associated with malicious activity. +- If necessary, isolate the affected system to prevent further potential compromise and perform a deeper forensic analysis to uncover any additional indicators of compromise. + +### False positive analysis + +- Legitimate software updates or installations may temporarily load unsigned or improperly signed VLC-related DLLs. Users can monitor the frequency and context of these events to determine if they align with known update schedules. +- Custom or third-party applications that integrate VLC components might use their own versions of VLC DLLs. Users should verify the source and purpose of these applications and consider adding them to an exception list if deemed safe. +- Development or testing environments may intentionally use modified VLC DLLs for debugging or feature testing. Users can exclude these environments from the rule or adjust the rule's scope to focus on production systems only. +- Security tools or monitoring software might load or interact with VLC DLLs in a way that triggers the rule. Users should review the behavior of these tools and whitelist them if they are confirmed to be non-threatening. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of the potential threat and to contain any malicious activity. +- Terminate any processes associated with the suspicious DLLs to halt any ongoing malicious operations. +- Remove the identified unsigned or improperly signed DLLs from the system to eliminate the immediate threat. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to detect and remove any additional malicious files or remnants. +- Restore any affected files or system components from a known good backup to ensure system integrity and functionality. +- Review and update endpoint protection policies to ensure that only signed and trusted DLLs are allowed to load, enhancing future detection and prevention. +- Escalate the incident to the security operations center (SOC) or relevant security team for further analysis and to determine if additional systems are affected, ensuring comprehensive threat management.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_masquerading_windows_dll.toml b/rules_building_block/defense_evasion_masquerading_windows_dll.toml index f64458b81cf..a9e5951fe78 100644 --- a/rules_building_block/defense_evasion_masquerading_windows_dll.toml +++ b/rules_building_block/defense_evasion_masquerading_windows_dll.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/08/18" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/31" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -104,6 +104,43 @@ library where event.action == "load" and dll.Ext.relative_file_creation_time <= ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Masquerading as System32 DLL + +System32 DLLs are critical components of the Windows operating system, providing essential functions for system operations. Adversaries may exploit this by replacing or mimicking these DLLs to execute malicious code, evade defenses, or maintain persistence. The detection rule identifies anomalies by checking for unsigned or non-Microsoft signed DLLs, recent file creation, and known masquerading patterns, helping to flag potential threats. + +### Possible investigation steps + +- Review the file creation time of the suspicious DLL to determine if it was recently created, as indicated by the `dll.Ext.relative_file_creation_time` field being less than or equal to 3600 seconds. +- Check the file path of the DLL using the `dll.path` field to confirm if it resides outside of typical system directories, which might indicate an attempt to masquerade as a legitimate system DLL. +- Verify the code signature of the DLL by examining the `dll.code_signature.subject_name` and `dll.code_signature.trusted` fields to identify if it is unsigned or signed by a non-Microsoft entity. +- Investigate the process that loaded the DLL by reviewing the `process.name` field to understand the context in which the DLL was used and assess if the process is legitimate or potentially malicious. +- Cross-reference the DLL name found in the `dll.name` field with known legitimate system DLLs to determine if the name is being used deceptively. +- Analyze any related network activity or system changes around the time the DLL was loaded to identify potential malicious behavior or persistence mechanisms. + +### False positive analysis + +- Certain DLLs like icuuc.dll, timeSync.dll, and appInfo.dll may be signed by trusted vendors such as Valve, VMware, and Adobe. These are often legitimate and can be excluded by adding exceptions for these specific signatures. +- DLLs like libcrypto.dll and wmi.dll signed by Bitdefender SRL or other trusted entities may trigger false positives. Users can mitigate this by creating exceptions for these trusted signatures. +- dbghelp.dll is commonly used by various applications and may be signed by trusted entities. Consider excluding this DLL if it is consistently flagged without malicious activity. +- DirectML.dll signed by Adobe Inc. can be a false positive. Users should verify the signature and exclude it if it is consistently trusted. +- icsvc.dll signed by Dell Inc. or Dell Technologies Inc. may be legitimate. Users can handle this by adding exceptions for these signatures. +- offreg.dll signed by Malwarebytes Inc. is often legitimate. Users should verify and exclude this DLL if it is consistently trusted. +- AppMgr.dll signed by Autodesk, Inc. may be a false positive. Users can exclude this DLL if it is verified as trusted. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of potential malicious activity. +- Terminate any suspicious processes associated with the unsigned or non-Microsoft signed DLLs identified in the alert. +- Restore the affected DLLs from a known good backup or reinstall the affected software to ensure integrity. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any additional malicious files or remnants. +- Review and update system access controls and permissions to limit the ability of unauthorized users to modify critical system files. +- Monitor the system and network for any signs of persistence mechanisms or further attempts to load unauthorized DLLs. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_masquerading_windows_system32_exe.toml b/rules_building_block/defense_evasion_masquerading_windows_system32_exe.toml index 96aa94f8133..8d85435b01d 100644 --- a/rules_building_block/defense_evasion_masquerading_windows_system32_exe.toml +++ b/rules_building_block/defense_evasion_masquerading_windows_system32_exe.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/08/20" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/31" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -78,6 +78,41 @@ process where host.os.type == "windows" and event.type == "start" and ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Masquerading as System32 Executable + +System32 executables are critical components of Windows, often targeted by adversaries for masquerading attacks. By replacing or mimicking these executables, attackers can execute malicious code under the guise of legitimate processes. The detection rule identifies anomalies by checking for unsigned executables or those signed by non-Microsoft entities, flagging potential masquerading attempts. It excludes known trusted signatures and paths to reduce false positives, focusing on defense evasion and persistence tactics. + +### Possible investigation steps + +- Review the process name and executable path to determine if it matches any known legitimate applications or if it appears suspicious based on the context of the alert. +- Check the code signature status and subject name to verify if the executable is signed by a trusted entity or if it is unsigned, which could indicate a potential masquerading attempt. +- Investigate the parent process to understand how the suspicious process was initiated and if it aligns with expected behavior for the system or user. +- Examine the process execution history and any associated network activity to identify any unusual patterns or connections that could suggest malicious intent. +- Cross-reference the executable path and process name against known false positives or exceptions listed in the rule to ensure the alert is not triggered by a benign process. +- Gather additional context from system logs or endpoint detection tools to corroborate findings and assess the potential impact or scope of the activity. + +### False positive analysis + +- Executables signed by trusted third-party vendors like Lenovo, HP Inc., Dell Inc., ImageMagick Studio LLC, Arctic Wolf Networks, Intel(R) Online Connect Access, Fortinet Technologies, and Cisco Systems may trigger false positives. Users can mitigate this by adding these vendors to the exception list if their signatures are verified as trusted. +- Processes running from temporary directories or specific paths such as "?:\\Program Files\\Git\\usr\\bin\\hostname.exe" or "?:\\Users\\*\\AppData\\Local\\Temp\\{*}\\taskkill.exe" might be flagged. Users should verify these paths and exclude them if they are part of legitimate operations. +- The rule may flag processes like "ucsvc.exe" signed by Wellbia.com Co., Ltd. or "pnputil.exe" signed by Lenovo, HP Inc., or Dell Inc. as false positives. Users should ensure these signatures are trusted and add them to the exception list if necessary. +- If "certutil.exe" is used by Intel(R) Online Connect Access or Fortinet Technologies, and the signature is trusted, users can exclude these specific instances to prevent false positives. +- For processes like "sfc.exe" signed by Cisco Systems, users should verify the signature's trust status and exclude them if they are part of legitimate activities. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of potential malicious activity. +- Terminate any suspicious processes identified by the alert that are unsigned or signed by non-Microsoft entities. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or executables. +- Restore any replaced or backdoored system32 executables from a known good backup to ensure system integrity. +- Review and update the system's security patches and software updates to close any vulnerabilities that may have been exploited. +- Monitor the system and network for any signs of persistence mechanisms or further unauthorized access attempts. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_msdt_suspicious_diagcab.toml b/rules_building_block/defense_evasion_msdt_suspicious_diagcab.toml index 1c7efb230f7..f4127cfc1dc 100644 --- a/rules_building_block/defense_evasion_msdt_suspicious_diagcab.toml +++ b/rules_building_block/defense_evasion_msdt_suspicious_diagcab.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/26" integration = ["endpoint", "windows", "system"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -57,6 +57,40 @@ process where host.os.type == "windows" and event.action == "start" and "ftp://*" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Troubleshooting Pack Cabinet Execution + +The Microsoft Diagnostic Wizard, often invoked via `msdt.exe`, is a legitimate tool used for troubleshooting and diagnostics on Windows systems. Adversaries may exploit this tool to execute malicious files by disguising them as troubleshooting packs, especially from unusual paths or with unexpected parent processes. The detection rule identifies such suspicious executions by monitoring for `msdt.exe` launches with specific arguments and parent processes, indicating potential misuse for defense evasion. + +### Possible investigation steps + +- Review the process tree to understand the parent-child relationship of msdt.exe, focusing on the parent process names such as browsers or office applications, to determine if the execution context is unusual or expected. +- Examine the command-line arguments used with msdt.exe, particularly looking for suspicious paths or URLs (e.g., network paths, HTTP, or FTP links) that could indicate a malicious source. +- Check the file path and origin of the diagcab file being executed to verify if it is from a trusted source or if it has been downloaded from an untrusted or external location. +- Investigate the user account under which msdt.exe was executed to determine if the activity aligns with the user's typical behavior or if it appears anomalous. +- Look for any related network activity or connections initiated around the time of the msdt.exe execution to identify potential data exfiltration or communication with a command and control server. +- Search for any additional alerts or logs related to the same user or system that might indicate a broader pattern of suspicious activity or compromise. + +### False positive analysis + +- Legitimate troubleshooting activities by IT staff or automated scripts may trigger this rule. To manage this, identify and whitelist known IT tools or scripts that regularly use msdt.exe for diagnostics. +- Software updates or installations that use msdt.exe as part of their process can be mistaken for suspicious activity. Monitor and document these processes, and create exceptions for recognized software update paths. +- Users accessing legitimate troubleshooting packs from network locations or URLs might cause false positives. Review and whitelist trusted network paths or domains frequently used for legitimate troubleshooting purposes. +- Certain applications, like browsers or email clients, may inadvertently launch msdt.exe during normal operations. Identify these applications and consider excluding them from the parent process list if they are consistently non-threatening. + +### Response and remediation + +- Isolate the affected system from the network to prevent further potential spread of malicious activity. +- Terminate the msdt.exe process if it is confirmed to be executing from a suspicious path or with an unusual parent process. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or remnants. +- Review and analyze the suspicious diagcab file and its source to determine the extent of the compromise and any additional payloads or scripts that may have been executed. +- Restore any affected files or system components from known good backups if any legitimate files were altered or deleted during the incident. +- 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 similar msdt.exe executions from unusual paths or with unexpected parent processes to enhance detection and prevent recurrence.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_msiexec_installsource_archive_file.toml b/rules_building_block/defense_evasion_msiexec_installsource_archive_file.toml index 2627af83080..fc4f5b5a55d 100644 --- a/rules_building_block/defense_evasion_msiexec_installsource_archive_file.toml +++ b/rules_building_block/defense_evasion_msiexec_installsource_archive_file.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/26" integration = ["endpoint"] maturity = "production" -updated_date = "2024/08/05" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -47,6 +47,40 @@ sequence with maxspan=1m not process.name : "msiexec.exe" and not (process.executable : ("?:\\Program Files (x86)\\*.exe", "?:\\Program Files\\*.exe") and process.code_signature.trusted == true)] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Windows Installer with Suspicious Properties + +The Windows Installer, or msiexec.exe, is a legitimate system utility used for installing, maintaining, and removing software. Adversaries may exploit it to execute malicious MSI files, bypassing security measures like application whitelisting. The detection rule identifies suspicious installer activity by monitoring registry changes and process executions linked to msiexec.exe, focusing on unusual sources or untrusted signatures. + +### Possible investigation steps + +- Review the registry change event details to identify the specific registry value and data strings involved, focusing on "InstallSource", "DisplayName", or "ProductName" to determine if they match suspicious patterns like temporary archive paths or "SetupTest". +- Examine the process execution details to identify the child process started by msiexec.exe, noting its name and executable path, especially if it is not located in trusted directories like "Program Files" or "Program Files (x86)". +- Check the code signature of the executed process to verify if it is untrusted, which could indicate a potential threat. +- Investigate the source of the MSI file, whether local or network-based, to determine if it is from a known and trusted source or if it appears suspicious. +- Correlate the alert with any recent user activity or changes in the system environment that might explain the execution of the installer, such as software updates or installations. +- Look for any additional alerts or logs related to the same user or system around the time of the alert to identify potential patterns or related suspicious activities. + +### False positive analysis + +- Legitimate software installations from compressed archives may trigger alerts. Users can create exceptions for known software sources by specifying trusted archive paths in the rule configuration. +- Internal software testing environments might use temporary or test names like "SetupTest" for legitimate purposes. Exclude these specific registry values or paths if they are part of routine operations. +- Custom or in-house applications installed from non-standard directories may be flagged. Ensure these applications have trusted code signatures or add their paths to an allowlist to prevent false positives. +- Frequent updates or installations from network shares within a controlled environment can be mistaken for suspicious activity. Define exceptions for these network paths if they are verified and secure. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread or communication with potential malicious sources. +- Terminate any suspicious processes initiated by msiexec.exe that are not signed by trusted vendors or originate from unusual directories. +- Remove any unauthorized or suspicious MSI files identified in the registry paths, especially those originating from temporary or archive directories. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection tools to identify and remove any additional malware or remnants. +- Review and restore any altered registry settings to their original state to ensure system integrity and prevent unauthorized software installations. +- Escalate the incident to the security operations team for further analysis and to determine if the threat is part of a larger attack campaign. +- Implement additional monitoring and alerting for similar activities, focusing on msiexec.exe executions from untrusted sources or with unusual properties, to enhance future detection capabilities.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_posh_defender_tampering.toml b/rules_building_block/defense_evasion_posh_defender_tampering.toml index d512e623895..830bfd439f3 100644 --- a/rules_building_block/defense_evasion_posh_defender_tampering.toml +++ b/rules_building_block/defense_evasion_posh_defender_tampering.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2024/09/11" integration = ["windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -60,6 +60,40 @@ event.category: "process" and host.os.type:windows and ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 PowerShell Script with Windows Defender Tampering Capabilities + +PowerShell, a powerful scripting language in Windows, can be exploited by adversaries to disable Windows Defender features, reducing detection risks. Attackers may use specific cmdlets to impair antivirus defenses, facilitating payload execution. The detection rule identifies scripts attempting such tampering by monitoring for key cmdlets and parameters indicative of defense evasion tactics. + +### Possible investigation steps + +- Review the PowerShell script block text to identify the specific cmdlets and parameters used, focusing on those related to disabling Windows Defender features such as Set-MpPreference. +- Check the event logs for the process category to gather additional context about the execution environment, including the user account and host involved. +- Investigate the timeline of events to determine if the script execution coincides with other suspicious activities, such as unauthorized access attempts or unusual network traffic. +- Analyze the host's security logs to assess whether any Windows Defender features were successfully disabled and if there are subsequent signs of malware or unauthorized changes. +- Correlate the alert with other security events or alerts from the same host or user to identify potential patterns or indicators of a broader attack campaign. + +### False positive analysis + +- Legitimate administrative scripts may use cmdlets like Set-MpPreference for valid configuration changes. Review the script's context and purpose to determine if it aligns with expected administrative tasks. +- Automated system management tools might trigger this rule when configuring Windows Defender settings as part of routine maintenance. Identify and whitelist these tools to prevent unnecessary alerts. +- Security software updates or patches could temporarily disable certain Windows Defender features, leading to false positives. Monitor update schedules and correlate alerts with known update activities. +- Custom scripts developed for internal use may include these cmdlets for specific security configurations. Validate the script's origin and intent, and consider excluding them if they are verified as safe. +- Training or testing environments might intentionally disable certain features for educational purposes. Ensure these environments are properly segmented and documented to avoid confusion with genuine threats. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further tampering or spread of malicious activities. +- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing tampering attempts. +- Conduct a thorough scan of the isolated system using an updated antivirus solution to identify and remove any malicious payloads or scripts. +- Restore Windows Defender settings to their default state to ensure all protective features are re-enabled. +- Review and update endpoint protection policies to prevent unauthorized changes to security settings, ensuring only trusted administrators have the necessary permissions. +- Monitor the network for any additional systems exhibiting similar behavior, indicating a broader compromise. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional containment or remediation actions are necessary.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_powershell_clear_logs_script.toml b/rules_building_block/defense_evasion_powershell_clear_logs_script.toml index ed5067dbc9e..2f6bb89c504 100644 --- a/rules_building_block/defense_evasion_powershell_clear_logs_script.toml +++ b/rules_building_block/defense_evasion_powershell_clear_logs_script.toml @@ -4,7 +4,7 @@ integration = ["windows"] maturity = "production" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." min_stack_version = "8.14.0" -updated_date = "2024/10/28" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -61,6 +61,40 @@ event.category:process and host.os.type:windows and ) and not file.directory : "C:\Program Files\WindowsAdminCenter\PowerShellModules\Microsoft.WindowsAdminCenter.Configuration" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 PowerShell Script with Log Clear Capabilities + +PowerShell, a powerful scripting language in Windows, enables automation and configuration management. Adversaries exploit its capabilities to clear event logs, erasing traces of their activities to evade detection. The detection rule identifies suspicious PowerShell commands linked to log deletion, excluding benign scripts and known safe directories, thus highlighting potential malicious behavior. + +### Possible investigation steps + +- Review the PowerShell script block text to confirm the presence of suspicious commands such as "Clear-EventLog" or "Remove-EventLog" and assess whether they are part of legitimate administrative activities or potentially malicious actions. +- Check the file directory from which the PowerShell script was executed to ensure it is not from a known safe directory like "C:\\Program Files\\WindowsAdminCenter\\PowerShellModules\\Microsoft.WindowsAdminCenter.Configuration". +- Investigate the process execution details, including the parent process, to determine if the PowerShell activity is part of a larger chain of suspicious behavior. +- Correlate the event with other logs and alerts from the same host to identify any additional indicators of compromise or related suspicious activities. +- Examine the user account associated with the PowerShell execution to verify if it has the necessary permissions and if the activity aligns with the user's typical behavior or role. + +### False positive analysis + +- Scripts from trusted directories like C:\\Program Files\\WindowsAdminCenter\\PowerShellModules\\Microsoft.WindowsAdminCenter.Configuration may trigger alerts. Exclude these directories in the rule configuration to prevent false positives. +- Legitimate administrative tasks using PowerShell cmdlets such as Clear-EventLog for routine maintenance can be mistaken for malicious activity. Identify and whitelist these specific scripts or tasks to avoid unnecessary alerts. +- PowerShell modules exporting benign cmdlets like Add-Content might be flagged. Ensure these modules are recognized and excluded by updating the rule to ignore known safe script block texts. +- Scheduled tasks or automated scripts that perform log management as part of system health checks can be misinterpreted. Document and exclude these tasks from the detection rule to reduce false positives. +- Security tools or monitoring solutions that use PowerShell for log management should be reviewed and excluded if they are known to be safe and necessary for operations. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity and potential lateral movement by the attacker. +- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing log clearing activities. +- Conduct a thorough review of the affected system's event logs and other forensic data to identify any additional malicious activities or indicators of compromise. +- Restore cleared event logs from backups if available, to aid in further investigation and maintain historical data integrity. +- Change all credentials used on the affected system, as attackers may have gained access to sensitive information during their activities. +- Implement enhanced monitoring on the affected system and similar environments to detect any recurrence of log clearing or other suspicious activities. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if broader organizational impacts exist.""" [[rule.filters]] [rule.filters.meta] diff --git a/rules_building_block/defense_evasion_processes_with_trailing_spaces.toml b/rules_building_block/defense_evasion_processes_with_trailing_spaces.toml index c5e63bbb893..1f8d689dba2 100644 --- a/rules_building_block/defense_evasion_processes_with_trailing_spaces.toml +++ b/rules_building_block/defense_evasion_processes_with_trailing_spaces.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/24" integration = ["endpoint", "auditd_manager"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -38,6 +38,40 @@ query = ''' process where event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started") and process.name : "* " ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Processes with Trailing Spaces + +In Linux and macOS environments, processes can be manipulated by appending trailing spaces to their names, a tactic used by adversaries to disguise malicious activities as legitimate processes. This evasion technique exploits default file handling, which often overlooks such anomalies. The detection rule identifies these deceptive processes by monitoring for execution events with names ending in spaces, flagging potential masquerading attempts. + +### Possible investigation steps + +- Review the process name that triggered the alert to confirm the presence of trailing spaces, which may indicate an attempt to masquerade as a legitimate process. +- Examine the parent process of the suspicious process to determine if it was spawned by a known legitimate application or a potentially malicious one. +- Check the user account associated with the process execution to assess if it aligns with expected behavior or if it might be compromised. +- Investigate the command line arguments used during the process execution to identify any unusual or unexpected parameters that could suggest malicious intent. +- Correlate the event with other logs or alerts from the same host or user to identify any patterns or additional suspicious activities that might indicate a broader attack. + +### False positive analysis + +- System utilities or scripts with trailing spaces in their names may trigger alerts. Review these processes to confirm their legitimacy and consider adding them to an exception list if they are verified as non-threatening. +- Custom applications or development scripts that inadvertently include trailing spaces in their process names can cause false positives. Regularly audit these applications and educate developers to avoid such naming conventions. +- Automated deployment or configuration management tools might create processes with trailing spaces as part of their operations. Identify these tools and exclude them from monitoring if they are confirmed to be safe. +- Legacy software that uses unconventional naming practices, including trailing spaces, should be assessed for security risks. If deemed safe, these can be added to an exclusion list to prevent unnecessary alerts. +- Regularly update and review the exception list to ensure that only verified non-threatening processes are excluded, maintaining the effectiveness of the detection rule. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes identified with trailing spaces in their names to halt any ongoing malicious activity. +- Conduct a thorough review of the system's process logs and execution history to identify any additional instances of masquerading or related suspicious activities. +- Restore the affected system from a known good backup to ensure any malicious modifications are removed. +- Update and patch the system to the latest security standards to close any vulnerabilities that may have been exploited. +- Implement enhanced monitoring for process execution events, specifically focusing on anomalies such as trailing spaces in process names, to improve detection capabilities. +- Escalate the incident to the security operations center (SOC) or relevant incident response team for further investigation and to determine if broader organizational impacts exist.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_service_disabled_registry.toml b/rules_building_block/defense_evasion_service_disabled_registry.toml index c1f1d49dab7..9cad11ccc64 100644 --- a/rules_building_block/defense_evasion_service_disabled_registry.toml +++ b/rules_building_block/defense_evasion_service_disabled_registry.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/29" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -44,6 +44,41 @@ registry where host.os.type == "windows" and event.type == "change" and ) and not registry.path : "HKLM\\SYSTEM\\ControlSet001\\Services\\MrxSmb10\\Start" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Service Disabled via Registry Modification + +Windows services are crucial for system operations, often configured via the registry. Adversaries may alter service start settings to disable security tools, evading detection. This detection rule identifies unauthorized registry changes to service start values, excluding legitimate processes like services.exe. By monitoring specific registry paths and values, it flags potential defense evasion attempts, aiding in timely threat response. + +### Possible investigation steps + +- Review the registry event details to identify the specific service affected by the registry modification, focusing on the registry.path field. +- Investigate the process responsible for the change by examining the process.name and process.id fields to determine if it is a known or suspicious application. +- Check the user.id associated with the event to verify if the change was made by an authorized user or account. +- Correlate the event with other recent security alerts or logs to identify any patterns or additional suspicious activities on the host. +- Assess the impact of the service modification by determining if the service is critical for security or monitoring, and evaluate the potential risk to the system. +- If the service is related to security or monitoring, consider restoring the original registry settings and conducting a full system scan to ensure no further compromise. + +### False positive analysis + +- Legitimate software updates or installations may modify service start settings. Users can create exceptions for known update processes by identifying their process names and user IDs. +- System administrators may intentionally change service configurations for maintenance or optimization. Document these changes and exclude them by specifying the responsible process names and user IDs. +- Some third-party management tools might alter service settings as part of their normal operation. Identify these tools and exclude their process names from the detection rule. +- Custom scripts or automation tasks that modify service settings for legitimate purposes should be reviewed and excluded by adding their process names to the exception list. +- Regularly review and update the exclusion list to ensure it reflects current legitimate activities while minimizing the risk of overlooking potential threats. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized changes or potential lateral movement by the adversary. +- Terminate any suspicious processes identified as modifying the registry, especially those not associated with legitimate system operations like services.exe. +- Restore the modified registry settings to their original state using a known good backup or by manually resetting the service start values to their default configuration. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious software that may have been introduced. +- Review and analyze system logs and security alerts to identify any additional indicators of compromise or related suspicious activities that may require further investigation. +- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine if the threat has impacted other systems within the network. +- Implement enhanced monitoring and alerting for registry changes on critical systems to detect similar threats in the future, ensuring that alerts are promptly reviewed and acted upon.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_service_path_registry.toml b/rules_building_block/defense_evasion_service_path_registry.toml index d8411c0a57f..64f93228773 100644 --- a/rules_building_block/defense_evasion_service_path_registry.toml +++ b/rules_building_block/defense_evasion_service_path_registry.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/29" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -49,6 +49,39 @@ registry where host.os.type == "windows" and event.type == "change" and ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Service Path Modification +Service paths in Windows define the executable location for services. Adversaries may alter these paths to execute malicious code, achieving persistence or privilege escalation. The detection rule identifies unusual modifications to service paths by monitoring registry changes, specifically targeting paths not associated with standard system processes, thus flagging potential unauthorized alterations. + +### Possible investigation steps + +- Review the registry path specified in the alert to confirm the exact service path that was modified, focusing on paths like HKLM\\SYSTEM\\*ControlSet*\\Services\\*\\ImagePath. +- Identify the process that made the change by examining the process.executable field in the alert, and determine if it is a known or expected application. +- Check the modification history of the service path to see if there have been any previous changes and if they were made by legitimate processes. +- Investigate the executable specified in the modified service path to determine if it is a legitimate application or potentially malicious. +- Correlate the alert with other security events or logs from the same host to identify any additional suspicious activity or patterns. +- Assess the risk and impact of the modification by determining if the service is critical and if the change could lead to persistence or privilege escalation. + +### False positive analysis + +- Legitimate software updates or installations may modify service paths, triggering the rule. Users can create exceptions for known update processes by adding their executables to the exclusion list. +- Custom or in-house applications installed in non-standard directories might be flagged. Verify these applications and add their paths to the exclusion list if they are deemed safe. +- Administrative scripts or tools that modify service configurations as part of routine maintenance can cause alerts. Identify these scripts and exclude their execution paths to prevent false positives. +- Security software or system management tools that alter service paths for legitimate reasons may be detected. Confirm their legitimacy and add them to the exclusion criteria to avoid unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified as modifying the service path, especially those not originating from standard system directories. +- Restore the modified service path to its original, legitimate state using system backups or by manually correcting the registry entry. +- Conduct a thorough scan of the system using updated antivirus and anti-malware tools to identify and remove any additional malicious software. +- Review and audit user accounts and permissions on the affected system to ensure no unauthorized privilege escalations have occurred. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Implement enhanced monitoring and logging for registry changes and service path modifications to detect similar threats in the future.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_services_exe_path.toml b/rules_building_block/defense_evasion_services_exe_path.toml index f31ea296712..b7ec1dbe8be 100644 --- a/rules_building_block/defense_evasion_services_exe_path.toml +++ b/rules_building_block/defense_evasion_services_exe_path.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/29" integration = ["endpoint", "windows", "system"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -40,6 +40,41 @@ query = ''' process where event.type == "start" and process.name : "sc.exe" and process.args : "*config*" and process.args : "*binPath*" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Service Path Modification via sc.exe + +The `sc.exe` utility is a command-line tool used in Windows environments to manage services. Adversaries may exploit this tool to alter service paths, enabling persistence or privilege escalation by redirecting service execution to malicious binaries. The detection rule identifies suspicious modifications by monitoring for `sc.exe` executions that include specific arguments related to service configuration changes, signaling potential unauthorized service path alterations. + +### Possible investigation steps + +- Review the process execution details to confirm the presence of "sc.exe" with arguments containing "config" and "binPath" to verify the alert's legitimacy. +- Identify the user account associated with the "sc.exe" process execution to determine if it aligns with expected administrative activity or if it indicates potential unauthorized access. +- Examine the service name and the new binary path specified in the "sc.exe" command to assess if the path points to a known or suspicious executable. +- Check the modification history of the service in question to identify any recent changes and correlate them with other system events or alerts. +- Investigate the source and destination of the binary path to ensure it is not linked to known malicious files or locations. +- Review related system logs and security events around the time of the alert to identify any additional suspicious activities or patterns. + +### False positive analysis + +- Routine administrative tasks using sc.exe may trigger alerts. System administrators often use sc.exe to configure services during maintenance or updates. To manage this, create exceptions for known administrative accounts or scheduled maintenance windows. +- Software installations or updates might modify service paths as part of their setup process. Identify and whitelist trusted software installers or update processes to prevent unnecessary alerts. +- Automated scripts or management tools that use sc.exe for legitimate service management can cause false positives. Review and exclude these scripts or tools by their process hash or command line patterns. +- Security software or monitoring tools may use sc.exe to adjust service configurations for protection purposes. Verify and exclude these tools by their digital signatures or known process names to reduce noise. +- Development environments where services are frequently started, stopped, or reconfigured for testing purposes can generate alerts. Implement exclusions for development machines or specific user accounts involved in testing. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further malicious activity or lateral movement. +- Terminate any suspicious processes related to the modified service path to halt potential malicious execution. +- Restore the original service path configuration by reviewing system logs or backups to identify the legitimate service path and revert any unauthorized changes. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection tools to identify and remove any malicious binaries that may have been introduced. +- Review user and service account permissions to ensure that only authorized personnel have the ability to modify service configurations, and adjust permissions as necessary. +- Monitor for any further attempts to modify service paths using sc.exe by setting up alerts for similar command-line patterns to detect and respond to future incidents promptly. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_suspicious_msiexec_execution.toml b/rules_building_block/defense_evasion_suspicious_msiexec_execution.toml index 6928b4187a8..0cc93ccecfc 100644 --- a/rules_building_block/defense_evasion_suspicious_msiexec_execution.toml +++ b/rules_building_block/defense_evasion_suspicious_msiexec_execution.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/26" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -68,6 +68,41 @@ process where host.os.type == "windows" and event.action == "start" and not process.args : ("?:\\Program Files (x86)\\*", "?:\\Program Files\\*") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Execution via MSIEXEC + +MSIEXEC is a Windows Installer utility used for installing, modifying, and removing applications. Adversaries exploit it to execute malicious MSI files, often using silent install options to avoid detection. The detection rule identifies unusual MSIEXEC activity by analyzing execution context, such as unexpected parent processes or atypical file paths, to flag potential misuse indicative of defense evasion tactics. + +### Possible investigation steps + +- Review the parent process of the msiexec.exe execution to determine if it is an unexpected or suspicious executable, especially if it is not from typical locations like Program Files or Windows directories. +- Analyze the command line arguments used with msiexec.exe, focusing on the presence of silent install options (/q, /quiet) and the number of arguments to identify potential misuse. +- Check the file path of the MSI file being executed to ensure it is not from unusual or user-specific directories like Users or ProgramData, which could indicate a malicious file. +- Investigate the user account associated with the execution, particularly if the user ID matches patterns like S-1-5-21* or S-1-12-*, to assess if the account has been compromised or is being used for unauthorized activities. +- Examine the working directory and any related files or scripts in the context of the execution to identify any additional indicators of compromise or related malicious activity. +- Correlate the event with other security alerts or logs to determine if this execution is part of a broader attack pattern or campaign. + +### False positive analysis + +- Legitimate software installations or updates may trigger the rule if they use msiexec.exe with silent install options. Users can create exceptions for known software paths or parent processes that frequently perform legitimate installations. +- System administrators using scripts or automation tools like PowerShell or CMD to deploy software across multiple machines might cause false positives. Exclude these specific parent processes or command line patterns if they are part of routine administrative tasks. +- Some enterprise software management tools may use msiexec.exe in a manner that matches the rule's criteria. Identify these tools and exclude their typical execution paths or parent processes to prevent unnecessary alerts. +- Temporary files created during legitimate installations in user directories might be flagged. Consider excluding specific temporary directories or known MSI file patterns that are part of regular software deployment processes. +- Regular updates from trusted software vendors that use msiexec.exe with quiet options can be excluded by identifying and whitelisting their specific update paths or parent processes. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of potential malware or unauthorized access. +- Terminate the suspicious msiexec.exe process to halt any ongoing malicious activity. +- Conduct a thorough scan of the system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or software. +- Review and analyze the parent process and command line arguments associated with the msiexec.exe execution to understand the attack vector and entry point. +- Restore any affected files or applications from a known good backup to ensure system integrity. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised. +- Implement additional monitoring and alerting for similar msiexec.exe activities to enhance detection and prevent recurrence of this threat.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_unsigned_bits_client.toml b/rules_building_block/defense_evasion_unsigned_bits_client.toml index 84012c3b2d4..bcaee625048 100644 --- a/rules_building_block/defense_evasion_unsigned_bits_client.toml +++ b/rules_building_block/defense_evasion_unsigned_bits_client.toml @@ -2,7 +2,7 @@ creation_date = "2023/09/27" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -40,6 +40,40 @@ library where dll.name : "Bitsproxy.dll" and process.executable != null and not process.code_signature.trusted == true and not process.code_signature.status : ("errorExpired", "errorCode_endpoint*") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Unsigned BITS Service Client Process + +The Windows Background Intelligent Transfer Service (BITS) facilitates asynchronous, prioritized, and throttled transfer of files between machines, often used for updates. Adversaries exploit BITS to stealthily download or upload data, bypassing traditional security measures. The detection rule identifies anomalies by flagging processes using BITS without a valid code signature, indicating potential misuse for evasion or masquerading tactics. + +### Possible investigation steps + +- Review the process executable path to determine if it is a known or expected application using BITS. Investigate any unfamiliar or suspicious executables. +- Check the process code signature details to understand why it is untrusted. Look for any discrepancies or missing signatures that could indicate tampering. +- Investigate the parent process of the unsigned BITS client process to identify how it was initiated and assess if the parent process is legitimate or potentially malicious. +- Analyze network activity associated with the process to identify any unusual or unauthorized data transfers, focusing on external connections that could indicate data exfiltration or command and control communication. +- Cross-reference the process and its associated files with threat intelligence sources to determine if they are linked to known malicious activity or threat actors. +- Review recent system changes or updates that might have introduced the unsigned process, such as new software installations or updates, to assess if they are legitimate or potentially compromised. + +### False positive analysis + +- Legitimate software updates or installations may trigger the rule if they use BITS without a valid code signature. Users can create exceptions for known software update processes that are verified as safe. +- Custom or in-house applications that utilize BITS for file transfers might not have a valid code signature. These can be whitelisted by verifying their source and ensuring they are part of the organization's approved software inventory. +- Development or testing environments often run unsigned applications that use BITS for data transfer. Exclude these environments from the rule to prevent unnecessary alerts, ensuring they are properly isolated from production systems. +- Some third-party security tools or network management software may use BITS in a way that triggers the rule. Confirm the legitimacy of these tools and add them to an exception list if they are deemed non-threatening. + +### Response and remediation + +- Isolate the affected system from the network to prevent further data exfiltration or malicious activity. +- Terminate the unsigned BITS client process to stop any ongoing unauthorized data transfers. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any additional threats. +- Review and analyze the process execution history and associated files to determine the source and intent of the unsigned BITS client process. +- Restore any altered or deleted files from backups, ensuring that the backup is clean and free from malware. +- Escalate the incident to the security operations team for further investigation and to assess the potential impact on the organization. +- Implement enhanced monitoring and logging for BITS-related activities to detect and respond to similar threats in the future.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_unusual_process_extension.toml b/rules_building_block/defense_evasion_unusual_process_extension.toml index 62072e9e4ed..0fdcf0f4bd2 100644 --- a/rules_building_block/defense_evasion_unusual_process_extension.toml +++ b/rules_building_block/defense_evasion_unusual_process_extension.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/23" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -59,6 +59,41 @@ process where host.os.type == "windows" and event.type == "start" and (process.name: "AGSRunner.bin" and process.code_signature.subject_name: "Intel Corporation") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Extension + +In Windows environments, processes typically run with standard executable extensions like .exe or .com. Adversaries may exploit this by using non-standard extensions to disguise malicious activities, evading detection. The 'Unusual Process Extension' rule identifies such anomalies by flagging processes with uncommon extensions, excluding known legitimate cases, thus helping to uncover potential masquerading tactics. + +### Possible investigation steps + +- Review the process executable path and name to determine if it matches any known legitimate software or if it appears suspicious or unfamiliar. +- Check the process code signature details, if available, to verify the authenticity of the process and identify the publisher. Pay special attention to any discrepancies or unsigned executables. +- Investigate the parent process that initiated the unusual process to understand the context of its execution and assess if the parent process is legitimate or potentially compromised. +- Search for any related network activity or connections initiated by the process to identify potential communication with malicious or suspicious external hosts. +- Examine the file creation and modification timestamps of the process executable to determine if it aligns with expected software updates or installations. +- Cross-reference the process with threat intelligence sources to identify if it is associated with known malware or threat actors. +- Review system logs and other endpoint data for additional indicators of compromise or related suspicious activities that may provide further context to the alert. + +### False positive analysis + +- Processes with extensions like .p5x, .bin, or .dep from known software such as Dell SupportAssist, Intel AGS, or Docker may trigger false positives. Users can mitigate this by adding these specific paths to the exclusion list. +- Signed executables from trusted vendors like Dell Inc, Bloomberg LP, Adobe Inc, and McAfee, LLC may be flagged. Verify the code signature and add these to exceptions if they are legitimate. +- Processes related to software management or security tools, such as those from Veeam Software Group GmbH or Panda Security, might be incorrectly identified. Confirm their legitimacy and exclude them if necessary. +- Regularly review and update the exclusion list to include new legitimate software that may use uncommon extensions, ensuring the rule remains effective without generating unnecessary alerts. + +### Response and remediation + +- Isolate the affected system from the network to prevent further spread of potential malicious activity. +- Terminate any suspicious processes identified with unusual extensions that do not match known legitimate cases. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious files. +- Review and restore any altered system configurations or files to their original state, ensuring system integrity. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems are affected. +- Implement application whitelisting to prevent execution of unauthorized or unusual file extensions in the future. +- Update and enhance endpoint detection and response (EDR) solutions to improve detection capabilities for similar masquerading tactics.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_unusual_process_path_wbem.toml b/rules_building_block/defense_evasion_unusual_process_path_wbem.toml index f5ab763eba2..076c75ad9e0 100644 --- a/rules_building_block/defense_evasion_unusual_process_path_wbem.toml +++ b/rules_building_block/defense_evasion_unusual_process_path_wbem.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/23" integration = ["endpoint", "windows", "system"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -53,6 +53,42 @@ process where host.os.type == "windows" and event.type == "start" and "wmiprvse.exe" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Execution on WBEM Path + +The Windows Management Instrumentation (WMI) is a core component for managing data and operations on Windows systems. It is often targeted by adversaries for executing malicious payloads under the guise of legitimate processes. The detection rule identifies non-standard processes executing from the WBEM directory, a typical location for WMI binaries, by filtering out known legitimate executables, thus highlighting potential misuse for defense evasion. + +### Possible investigation steps + +- Review the process executable path to confirm it matches the WBEM directory paths specified in the query (?:\\Windows\\System32\\wbem\\* or ?:\\Windows\\SysWow64\\wbem\\*). +- Identify the process name and compare it against the list of known legitimate WMI-related executables to ensure it is not mistakenly flagged. +- Gather additional context on the process by checking its parent process and command line arguments to understand how it was initiated. +- Investigate the user account associated with the process execution to determine if it aligns with expected behavior or if it indicates potential compromise. +- Check for any recent changes or anomalies in the system's WMI configuration or related services that could suggest tampering or misuse. +- Correlate the event with other security alerts or logs from the same host to identify any patterns or additional indicators of compromise. +- If suspicious, isolate the host for further forensic analysis and consider running a full malware scan to detect any hidden threats. + +### False positive analysis + +- Legitimate administrative scripts or tools may occasionally execute from the WBEM path, especially in environments with custom management scripts. Review and document any such scripts to determine if they are benign. +- Scheduled tasks or automated processes that utilize WMI for legitimate purposes might trigger this rule. Identify and whitelist these tasks to prevent unnecessary alerts. +- Software updates or installations that temporarily use the WBEM directory for execution can be mistaken for unusual activity. Monitor and verify these processes during known update windows. +- Security or monitoring tools that interact with WMI may execute processes from the WBEM path. Ensure these tools are recognized and excluded from the rule to avoid false positives. +- In environments with custom WMI providers or extensions, additional executables may be present in the WBEM directory. Validate these custom components and adjust the rule to exclude them if they are verified as safe. + +### Response and remediation + +- Isolate the affected system from the network to prevent further malicious activity and lateral movement. +- Terminate any suspicious processes identified running from the WBEM path that are not part of the known legitimate executables list. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious payloads or files. +- Review recent system changes and restore any altered or maliciously modified system files from a known good backup. +- Escalate the incident to the security operations center (SOC) or incident response team for further analysis and to determine if additional systems are affected. +- Implement additional monitoring on the affected system and network to detect any further attempts to execute unauthorized processes from the WBEM path. +- Update security policies and endpoint protection configurations to block execution of unauthorized processes from the WBEM directory in the future.""" [[rule.threat]] diff --git a/rules_building_block/defense_evasion_write_dac_access.toml b/rules_building_block/defense_evasion_write_dac_access.toml index de838caec6d..6624b04b3bf 100644 --- a/rules_building_block/defense_evasion_write_dac_access.toml +++ b/rules_building_block/defense_evasion_write_dac_access.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/15" integration = ["system", "windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -61,6 +61,40 @@ query = ''' host.os.type: "windows" and event.action : ("Directory Service Access" or "object-operation-performed") and event.code : "4662" and winlog.event_data.AccessMask:"0x40000" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 WRITEDAC Access on Active Directory Object + +WRITEDAC permissions allow modification of an object's access control list in Active Directory, crucial for managing access rights. Adversaries exploit this to alter permissions, enabling unauthorized access and privilege escalation. The detection rule identifies such abuse by monitoring specific Windows events and access masks, flagging potential threats for further investigation. + +### Possible investigation steps + +- Review the event logs for event code 4662 to identify the specific object and user account involved in the WRITEDAC access attempt. +- Examine the winlog.event_data.AccessMask field for the value "0x40000" to confirm the modification of the Discretionary Access Control List (DACL). +- Investigate the user account associated with the WRITEDAC access to determine if it has a history of suspicious activity or if it has been compromised. +- Check the Active Directory object that was accessed to understand its role and importance within the network, and assess the potential impact of unauthorized access. +- Analyze recent changes to the object's access control list to identify any unauthorized modifications or privilege escalations. +- Correlate this event with other security alerts or logs to identify patterns or additional indicators of compromise that may suggest a broader attack campaign. + +### False positive analysis + +- Routine administrative tasks may trigger WRITEDAC alerts when legitimate users modify access control lists as part of their job. To manage this, create exceptions for known administrative accounts performing regular maintenance. +- Automated scripts or tools used for Active Directory management might generate false positives if they modify access control lists. Identify these scripts and whitelist their activity to prevent unnecessary alerts. +- Software installations or updates that require changes to access control lists can also cause false positives. Monitor and document these activities, and consider excluding them from the rule if they are verified as safe. +- Changes made by security tools that automatically adjust permissions for compliance or security hardening purposes may be flagged. Review these tools' activities and exclude them if they are part of a controlled process. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or lateral movement. +- Revoke any unauthorized permissions or access rights granted through the WRITEDAC abuse by restoring the original Access Control List (ACL) settings on the compromised Active Directory object. +- Conduct a thorough review of recent changes to the ACLs of critical Active Directory objects to identify any additional unauthorized modifications. +- Reset passwords and review access rights for any accounts that were potentially compromised or used in the attack to prevent further unauthorized access. +- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the full scope of the breach. +- Implement enhanced monitoring and alerting for similar WRITEDAC access attempts by adjusting logging and alert thresholds to detect future unauthorized access attempts promptly. +- Review and update security policies and access controls to ensure that only authorized personnel have the necessary permissions to modify ACLs, reducing the risk of similar incidents in the future.""" [[rule.threat]] diff --git a/rules_building_block/discovery_capnetraw_capability.toml b/rules_building_block/discovery_capnetraw_capability.toml index 7fd2ca5a2a7..1a0db2aafaa 100644 --- a/rules_building_block/discovery_capnetraw_capability.toml +++ b/rules_building_block/discovery_capnetraw_capability.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2024/01/10" integration = ["endpoint"] maturity = "production" -updated_date = "2024/11/07" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -65,6 +65,41 @@ event.category:"process" and host.os.type:"linux" and event.type:"start" and eve (process.thread.capabilities.effective:"CAP_NET_RAW" or process.thread.capabilities.permitted:"CAP_NET_RAW") and not user.id:"0" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Network Traffic Capture via CAP_NET_RAW + +CAP_NET_RAW is a Linux capability that allows processes to create raw sockets, enabling them to send and receive packets directly at the network layer. This capability is crucial for network utilities but can be exploited by adversaries to intercept and manipulate network traffic, bypassing access controls. The detection rule identifies non-root processes with CAP_NET_RAW, flagging potential unauthorized network sniffing activities. + +### Possible investigation steps + +- Review the process details by examining the process.name field to identify the specific application or service that triggered the alert. +- Check the user.id field to determine which non-root user is associated with the process, and assess whether this user should have CAP_NET_RAW capabilities. +- Investigate the event.category and event.type fields to confirm the context of the process start event and ensure it aligns with expected behavior for the identified process. +- Analyze the host.os.type field to verify the operating system environment and consider any specific configurations or security measures in place on the Linux host. +- Correlate the event.action field with other recent events on the system to identify any unusual patterns or sequences of actions that might indicate malicious activity. +- Consult system logs and network traffic data to gather additional context around the time of the alert, looking for signs of unauthorized network sniffing or manipulation. + +### False positive analysis + +- Network diagnostic tools like tcpdump or Wireshark may trigger this rule when used by non-root users. To manage this, create exceptions for these specific processes if they are part of regular network monitoring activities. +- Custom scripts or applications developed in-house that require network packet analysis might also be flagged. Review these processes and, if deemed safe, add them to an allowlist to prevent future alerts. +- Security software or monitoring agents that operate with CAP_NET_RAW for legitimate purposes can be identified as false positives. Verify their legitimacy and configure exceptions to avoid unnecessary alerts. +- Development or testing environments where non-root users are granted CAP_NET_RAW for specific tasks may cause alerts. Ensure these environments are well-documented and apply exceptions where appropriate to reduce noise. +- Automated deployment tools that temporarily use CAP_NET_RAW during setup or configuration might be flagged. Confirm their activity is expected and safe, then exclude them from the rule to streamline operations. + +### Response and remediation + +- Immediately isolate the affected host from the network to prevent further unauthorized network traffic sniffing and potential data exfiltration. +- Terminate the suspicious process identified with CAP_NET_RAW capabilities to stop any ongoing malicious activities. +- Conduct a thorough review of the affected system to identify any unauthorized changes or additional malicious processes that may have been initiated by the same threat actor. +- Revoke CAP_NET_RAW capabilities from non-essential processes and users to minimize the risk of similar threats in the future. +- Implement strict firewall rules to limit the types and contents of packets that can be sent and received, reducing the attack surface for network sniffing. +- Escalate the incident to the security operations center (SOC) for further analysis and to determine if the threat is part of a larger attack campaign. +- Enhance monitoring and logging for CAP_NET_RAW capability usage across all systems to improve detection and response times for similar threats in the future.""" [[rule.threat]] diff --git a/rules_building_block/discovery_generic_account_groups.toml b/rules_building_block/discovery_generic_account_groups.toml index eb8dadcd502..8bff1640ece 100644 --- a/rules_building_block/discovery_generic_account_groups.toml +++ b/rules_building_block/discovery_generic_account_groups.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/07/13" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -60,6 +60,40 @@ process where host.os.type == "windows" and event.type == "start" and ) and not process.parent.args: "C:\\Program Files (x86)\\Microsoft Intune Management Extension\\Content\\DetectionScripts\\*.ps1" and not process.parent.name : "LTSVC.exe" and not user.id : "S-1-5-18" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Windows Account or Group Discovery + +Windows environments provide built-in tools for managing and querying user accounts and groups, essential for system administration. However, adversaries exploit these tools to gather information about user accounts and group memberships, aiding in privilege escalation and lateral movement. The detection rule identifies suspicious use of these tools by monitoring specific command executions and arguments, filtering out benign activities to highlight potential threats. + +### Possible investigation steps + +- Review the process name and arguments to determine if the command execution aligns with typical administrative tasks or if it appears suspicious. Pay particular attention to commands like net.exe, dsquery.exe, and whoami.exe. +- Check the parent process name and arguments to identify if the command was executed by a legitimate application or script, such as those related to Microsoft Intune Management Extension or LTSVC.exe, which are excluded in the rule. +- Investigate the user ID associated with the process to determine if it belongs to a legitimate system or service account, especially since the rule excludes the system account S-1-5-18. +- Analyze the context of the host where the process was executed, including recent login activities, to identify any unusual patterns or unauthorized access attempts. +- Correlate the alert with other security events or logs from the same host or user to identify potential lateral movement or privilege escalation activities. + +### False positive analysis + +- Routine administrative tasks using net.exe or net1.exe for legitimate account management may trigger alerts. Exclude these by identifying and whitelisting specific administrative scripts or processes that frequently use these commands. +- Automated scripts or software updates that query user or group information using dsquery.exe or dsget.exe can be mistaken for threats. Monitor and exclude these processes if they are part of regular maintenance or update routines. +- Commands executed by cmd.exe to display environment variables like %username% or %userdomain% during login scripts or system checks can be benign. Identify and exclude these scripts if they are part of standard operating procedures. +- Processes initiated by known management tools such as Microsoft Intune or LTSVC.exe may appear suspicious. Exclude these parent processes to reduce false positives from trusted management software. +- System accounts, particularly those with user ID S-1-5-18, may execute commands that match the rule criteria. Exclude these system accounts to prevent unnecessary alerts from standard system operations. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, such as those involving net.exe, dsquery.exe, or other flagged applications. +- Conduct a thorough review of user accounts and group memberships on the affected system to identify any unauthorized changes or additions. +- Reset passwords for potentially compromised accounts, especially those with elevated privileges, to mitigate the risk of further exploitation. +- Review and update access controls and permissions to ensure that only authorized users have access to sensitive resources and administrative tools. +- 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 enhanced monitoring and logging for the affected system and similar environments to detect any recurrence of the threat or related suspicious activities.""" [[rule.threat]] diff --git a/rules_building_block/discovery_generic_process_discovery.toml b/rules_building_block/discovery_generic_process_discovery.toml index 5cd753d8699..3addd03e269 100644 --- a/rules_building_block/discovery_generic_process_discovery.toml +++ b/rules_building_block/discovery_generic_process_discovery.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/07/13" integration = ["endpoint", "windows", "system"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -51,6 +51,41 @@ process where host.os.type == "windows" and event.type == "start" and (process.name : "query.exe" and process.args : "process") ) and not user.id : "S-1-5-18" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Process Discovery Using Built-in Tools + +Process discovery tools, like PsList, qprocess, and tasklist, are integral for system administrators to monitor active processes on Windows systems. However, adversaries exploit these tools to identify running applications and security defenses, aiding in further attacks. The detection rule identifies suspicious use of these tools by monitoring specific command executions and arguments, excluding known system accounts, to flag potential malicious activity. + +### Possible investigation steps + +- Review the alert details to identify the specific process name and arguments that triggered the rule, focusing on processes like PsList.exe, qprocess.exe, powershell.exe, wmic.exe, tasklist.exe, or query.exe. +- Check the user account associated with the process execution to determine if it is a known or legitimate user, ensuring it is not the system account (S-1-5-18). +- Investigate the context of the process execution by examining the parent process and any related processes to understand the sequence of events leading to the alert. +- Analyze the timing and frequency of the process execution to identify any patterns or anomalies that could indicate malicious activity. +- Correlate the alert with other security events or logs from the same host or user to gather additional context and assess the potential impact or intent of the activity. +- If necessary, conduct a deeper forensic analysis on the host to identify any signs of compromise or further malicious behavior associated with the process execution. + +### False positive analysis + +- System maintenance tasks may trigger the rule when administrators use built-in tools for legitimate monitoring or troubleshooting. To manage this, create exceptions for known maintenance scripts or scheduled tasks by excluding specific user accounts or process arguments. +- Automated monitoring solutions that regularly check system health can cause false positives. Identify these processes and exclude them by specifying their unique process arguments or user IDs in the rule configuration. +- Software updates or installations might use these tools to verify system compatibility or status, leading to false alerts. Exclude these activities by recognizing the associated user accounts or process names involved in the update procedures. +- Security software may use similar commands to perform routine checks. Determine which security tools are in use and exclude their known processes or user IDs to prevent unnecessary alerts. +- Development or testing environments often run scripts that mimic adversarial behavior for testing purposes. Exclude these environments by filtering out specific hostnames or user accounts associated with development activities. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, such as PsList.exe, qprocess.exe, or unauthorized instances of powershell.exe, wmic.exe, and tasklist.exe. +- Conduct a thorough review of the system's recent process execution history to identify any additional unauthorized or suspicious activities that may have been missed. +- Reset credentials for any accounts that were active on the affected system during the time of the alert, especially if they have elevated privileges. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if the threat has spread to other systems. +- Implement additional monitoring on the affected system and similar systems to detect any recurrence of the suspicious process discovery activities. +- Review and update endpoint protection configurations to ensure they are capable of detecting and blocking similar process discovery attempts in the future.""" [[rule.threat]] diff --git a/rules_building_block/discovery_generic_registry_query.toml b/rules_building_block/discovery_generic_registry_query.toml index 4370465eb15..c8692fef37a 100644 --- a/rules_building_block/discovery_generic_registry_query.toml +++ b/rules_building_block/discovery_generic_registry_query.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/07/13" integration = ["endpoint"] maturity = "production" -updated_date = "2024/12/19" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -52,6 +52,41 @@ host.os.type:windows and event.category:process and event.type:start and "reg query \"HKLM\\Software\\WOW6432Node\\Npcap\" /ve " ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Query Registry using Built-in Tools + +The Windows Registry is a critical database for system configuration and application settings. Adversaries exploit built-in tools like `reg.exe` and PowerShell to query the registry, seeking insights into installed software and system configurations. The detection rule identifies suspicious registry queries by monitoring specific command executions, filtering out benign activities, and focusing on potential threats, thus aiding in early threat detection. + +### Possible investigation steps + +- Review the process details, including process.name and process.args, to confirm if the command execution aligns with known legitimate administrative activities or if it appears suspicious. +- Check the process.command_line field to understand the full context of the command executed and identify any deviations from typical usage patterns. +- Investigate the user account associated with the process execution to determine if the activity is expected for that user or if it indicates potential unauthorized access. +- Correlate the event with other recent events involving the same host or user to identify any patterns or sequences that suggest malicious behavior. +- Examine the host's recent activity logs for any signs of compromise or other suspicious activities that might be related to the registry query. +- Assess the risk and impact of the queried registry keys, such as HKCU or HKLM, to determine if they contain sensitive information that could be leveraged by an adversary. + +### False positive analysis + +- Routine system inventory checks by IT management tools may trigger this rule. To handle this, identify and exclude specific command patterns used by these tools from the detection rule. +- Software update processes often query the registry to verify installation status. Exclude known update processes by adding their command lines to the exception list. +- Security software may perform regular registry queries as part of its monitoring activities. Review and whitelist these processes to prevent unnecessary alerts. +- Custom scripts used for system administration might query the registry. Document and exclude these scripts if they are verified as non-threatening. +- Automated compliance checks that involve registry queries can be excluded by identifying their specific command signatures and adding them to the exception list. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, such as instances of reg.exe or PowerShell executing unauthorized registry queries. +- Conduct a thorough review of the system's registry to identify any unauthorized changes or entries that may have been made by the adversary. +- Restore any altered registry settings to their original state using known good configurations or backups. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement additional monitoring on the affected system and similar endpoints to detect any recurrence of the suspicious activity. +- Review and update endpoint protection policies to block unauthorized registry access and enhance detection capabilities for similar threats.""" [[rule.threat]] diff --git a/rules_building_block/discovery_hosts_file_access.toml b/rules_building_block/discovery_hosts_file_access.toml index 8a3177bf266..f64c5c242ed 100644 --- a/rules_building_block/discovery_hosts_file_access.toml +++ b/rules_building_block/discovery_hosts_file_access.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/11" integration = ["endpoint", "auditd_manager"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -38,6 +38,39 @@ query = ''' process where event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started") and process.name in ("vi", "nano", "cat", "more", "less") and process.args == "/etc/hosts" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 System Hosts File Access + +The hosts file is a local system file used to map hostnames to IP addresses, crucial for network operations. Adversaries may exploit this by accessing the file to identify potential targets for lateral movement within a network. The detection rule monitors the execution of common text editors and commands accessing the hosts file, flagging potential unauthorized access attempts, thus aiding in early threat detection. + +### Possible investigation steps + +- Review the process details to confirm the execution of text editors or commands (vi, nano, cat, more, less) with the argument "/etc/hosts" to determine if the access was intentional or suspicious. +- Check the user account associated with the process to verify if the access aligns with their role and responsibilities within the organization. +- Investigate the timing and frequency of the access to the hosts file to identify any unusual patterns or repeated attempts that may indicate malicious intent. +- Correlate the event with other logs or alerts from the same host or user to identify any additional suspicious activities, such as attempts to access other sensitive files or network resources. +- Assess the network environment for any recent changes or anomalies that could be related to the access of the hosts file, such as new devices or unexpected network traffic. + +### False positive analysis + +- Routine administrative tasks: System administrators often access the hosts file using text editors like vi or nano for legitimate configuration changes. To manage this, create exceptions for known administrator accounts or specific maintenance windows. +- Automated scripts: Some automated scripts or configuration management tools may access the hosts file as part of their normal operation. Identify these scripts and exclude their process names or execution paths from the rule. +- System updates: During system updates, certain processes might access the hosts file to ensure network configurations are up-to-date. Monitor update schedules and exclude these processes during known update periods. +- Development environments: Developers may frequently access the hosts file to test network configurations. Consider excluding access from development machines or specific user accounts associated with development activities. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Conduct a thorough review of recent access logs and process execution history on the affected system to identify any unauthorized access or suspicious activity. +- Terminate any unauthorized processes that are currently accessing or have accessed the hosts file without legitimate reason. +- Change credentials for any accounts that were active on the affected system during the time of the alert to prevent unauthorized access using compromised credentials. +- Restore the hosts file to its original state if any unauthorized modifications are detected, ensuring that no malicious entries have been added. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised. +- Implement enhanced monitoring on the affected system and similar endpoints to detect any future unauthorized access attempts to the hosts file.""" [[rule.threat]] diff --git a/rules_building_block/discovery_internet_capabilities.toml b/rules_building_block/discovery_internet_capabilities.toml index 2ae9e761e72..c77f9ea4b66 100644 --- a/rules_building_block/discovery_internet_capabilities.toml +++ b/rules_building_block/discovery_internet_capabilities.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/07/12" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -37,6 +37,39 @@ host.os.type:windows and event.category:process and event.type:start and process.name.caseless:("ping.exe" or "tracert.exe" or "pathping.exe") and not process.args:("127.0.0.1" or "0.0.0.0" or "localhost" or "::1") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Discovery of Internet Capabilities via Built-in Tools + +Built-in network diagnostic tools like ping, tracert, and pathping are essential for assessing connectivity and network paths in Windows environments. Adversaries exploit these tools to verify internet access and map network routes, aiding in communication with command and control servers. The detection rule identifies suspicious use of these tools by monitoring process executions that target external IPs, excluding common local addresses, thus flagging potential reconnaissance activities. + +### Possible investigation steps + +- Review the process execution details to identify the specific built-in tool used (ping.exe, tracert.exe, or pathping.exe) and the external IP addresses targeted. +- Examine the user account and host associated with the process execution to determine if the activity aligns with expected behavior or if it appears suspicious. +- Check for any related network activity or connections to the external IP addresses identified, focusing on unusual or unauthorized communication patterns. +- Investigate the historical activity of the involved user and host to identify any previous suspicious behavior or patterns that might indicate compromise. +- Correlate the alert with other security events or logs from the same timeframe to identify potential indicators of compromise or related malicious activity. + +### False positive analysis + +- Routine network diagnostics by IT staff can trigger alerts when using tools like ping, tracert, or pathping to troubleshoot connectivity issues. To manage this, create exceptions for known IT user accounts or specific IP ranges frequently used for legitimate diagnostics. +- Automated monitoring systems or scripts that regularly check network connectivity might be flagged. Identify these systems and exclude their process executions from the rule to prevent unnecessary alerts. +- Software updates or installations that verify internet connectivity as part of their process can also be mistaken for suspicious activity. Whitelist these specific processes or applications to reduce false positives. +- Internal network testing by security teams may involve the use of these tools to map network paths. Coordinate with security teams to ensure their activities are recognized and excluded from detection rules. + +### Response and remediation + +- Isolate the affected system from the network to prevent further communication with potential command and control servers. +- Terminate any suspicious processes identified by the alert, specifically those involving ping.exe, tracert.exe, or pathping.exe targeting external IPs. +- Conduct a thorough review of the system's network configuration and routing tables to identify any unauthorized changes or suspicious routes. +- Scan the system for additional indicators of compromise, such as unusual network traffic patterns or unauthorized software installations. +- Restore the system from a known good backup if any malicious activity is confirmed, ensuring that all security patches and updates are applied. +- Implement network monitoring to detect and alert on similar suspicious activities in the future, focusing on unusual use of diagnostic tools. +- Escalate the incident to the security operations center (SOC) or relevant IT security team for further investigation and to determine if the threat is part of a larger attack campaign.""" [[rule.threat]] diff --git a/rules_building_block/discovery_kernel_module_enumeration_via_proc.toml b/rules_building_block/discovery_kernel_module_enumeration_via_proc.toml index e6ea704526d..d53f3759ada 100644 --- a/rules_building_block/discovery_kernel_module_enumeration_via_proc.toml +++ b/rules_building_block/discovery_kernel_module_enumeration_via_proc.toml @@ -2,7 +2,7 @@ creation_date = "2020/04/12" integration = ["auditd_manager"] maturity = "production" -updated_date = "2024/10/18" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -58,6 +58,40 @@ query = ''' host.os.type:linux and event.category:file and event.action:"opened-file" and file.path:"/proc/modules" and not process.name:(python* or chef-client) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Enumeration of Kernel Modules via Proc + +Loadable Kernel Modules (LKMs) enhance Linux kernel functionality dynamically. The `/proc/modules` file lists these modules, aiding utilities like `lsmod` in module management. Adversaries may exploit this to gather system details, aiding in further attacks. The detection rule identifies unauthorized access to `/proc/modules`, excluding benign processes, to flag potential reconnaissance activities. + +### Possible investigation steps + +- Review the alert details to identify the specific process that accessed /proc/modules, focusing on the process name and its parent process. +- Investigate the source of the process by examining the user account associated with the process and checking for any unusual or unauthorized user activity. +- Analyze the command line arguments and execution context of the process to determine if the access was part of a legitimate operation or a potential reconnaissance attempt. +- Check the system's recent login history and network connections to identify any suspicious activity that might correlate with the alert. +- Cross-reference the process with known benign processes that are excluded in the query (e.g., python*, chef-client) to ensure it is not mistakenly flagged. +- Review system logs and audit logs for any other related activities or anomalies around the time of the alert to gather additional context. + +### False positive analysis + +- System management tools like configuration management software may access /proc/modules as part of routine operations. Exclude these processes by adding them to the exception list in the detection rule. +- Monitoring or diagnostic tools that regularly check system status might open /proc/modules. Identify these tools and update the rule to exclude their process names. +- Custom scripts used for system maintenance or monitoring could trigger the rule. Review these scripts and, if they are verified as safe, add their process names to the exclusion list. +- Automated security scans or compliance checks might access /proc/modules. Determine if these are legitimate and adjust the rule to prevent false alerts by excluding the relevant process names. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Conduct a thorough review of the process that accessed /proc/modules to determine if it is a legitimate process or a potential threat actor. +- If unauthorized access is confirmed, terminate the suspicious process and remove any associated malicious binaries or scripts from the system. +- Review system logs and audit trails to identify any additional unauthorized access attempts or related suspicious activities. +- Update and patch the system to ensure all software, especially kernel-related components, are up to date to mitigate known vulnerabilities. +- Implement stricter access controls and monitoring on critical files and directories, such as /proc/modules, to prevent unauthorized access in the future. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules_building_block/discovery_linux_modprobe_enumeration.toml b/rules_building_block/discovery_linux_modprobe_enumeration.toml index 1a41af5ad2f..bfe8b45b86b 100644 --- a/rules_building_block/discovery_linux_modprobe_enumeration.toml +++ b/rules_building_block/discovery_linux_modprobe_enumeration.toml @@ -2,7 +2,7 @@ creation_date = "2023/06/08" integration = ["auditd_manager"] maturity = "production" -updated_date = "2024/10/18" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -61,6 +61,41 @@ file.path : ("/etc/modprobe.conf" or "/etc/modprobe.d" or /etc/modprobe.d/*) and aide or modprobe or python* ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Modprobe File Event + +Modprobe manages Linux kernel modules, crucial for system functionality. Adversaries may exploit modprobe configurations to load unauthorized modules, potentially bypassing security, escalating privileges, or concealing activities. The detection rule identifies unusual file access in modprobe directories, excluding benign processes, to flag potential tampering attempts. + +### Possible investigation steps + +- Review the alert details to identify the specific file path accessed, focusing on "/etc/modprobe.conf" or files within "/etc/modprobe.d". +- Examine the process that triggered the alert by checking the process name and its parent process to understand the context of the file access. +- Investigate the user account associated with the process to determine if it is a legitimate user or potentially compromised. +- Check for any recent changes or modifications to the accessed modprobe files to identify unauthorized alterations. +- Correlate the event with other security logs or alerts to identify any related suspicious activities or patterns. +- Assess the system for any unauthorized kernel modules that may have been loaded as a result of the file access. + +### False positive analysis + +- System maintenance tools like mkinitramfs and systemd-udevd may access modprobe files during routine operations. To prevent these from triggering alerts, ensure they are included in the exclusion list within the detection rule. +- Backup and recovery processes, such as those performed by borg, might interact with modprobe directories. Verify these processes are legitimate and add them to the exclusion criteria if they are part of regular system operations. +- Security auditing tools like auditbeat and aide can access modprobe files as part of their monitoring activities. Confirm these tools are authorized and exclude them from the rule to avoid unnecessary alerts. +- Package management and installation processes, such as those involving dpkg, may open modprobe files. If these actions are part of standard package updates or installations, include them in the exclusion list to reduce false positives. +- Custom scripts or automation tools using Python may interact with modprobe configurations. Review these scripts to ensure they are safe and consider adding them to the exclusion list if they are frequently triggering alerts without posing a threat. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement or further unauthorized access. +- Conduct a thorough review of the processes that accessed the modprobe configuration files to identify any unauthorized or suspicious activity. +- If unauthorized access is confirmed, remove any malicious or unauthorized kernel modules that have been loaded, and restore the modprobe configuration files from a known good backup. +- Apply security patches and updates to the system to address any vulnerabilities that may have been exploited. +- Enhance monitoring and logging for modprobe-related activities to detect any future unauthorized access attempts. +- Review and tighten permissions on modprobe configuration files to ensure only authorized processes and users can access them. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems may be affected.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules_building_block/discovery_linux_sysctl_enumeration.toml b/rules_building_block/discovery_linux_sysctl_enumeration.toml index 4da1313644c..729e1069a4b 100644 --- a/rules_building_block/discovery_linux_sysctl_enumeration.toml +++ b/rules_building_block/discovery_linux_sysctl_enumeration.toml @@ -2,7 +2,7 @@ creation_date = "2023/06/08" integration = ["auditd_manager"] maturity = "production" -updated_date = "2024/10/18" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -60,6 +60,41 @@ file.path : ("/etc/sysctl.conf" or "/etc/sysctl.d" or /etc/sysctl.d/*) and not p dpkg or dockerd or unattended-upg or systemd-sysctl or python* or auditbeat or dpkg or pool* ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Sysctl File Event + +Sysctl configuration files in Linux environments manage kernel parameters, crucial for system performance and security. Adversaries may exploit these files to alter system behavior, potentially destabilizing or compromising the system. The detection rule identifies unauthorized file access or modifications by monitoring specific file events and excluding benign processes, thus highlighting potential malicious activity. + +### Possible investigation steps + +- Review the specific file path involved in the alert to determine if it is a critical sysctl configuration file, such as /etc/sysctl.conf or a file within /etc/sysctl.d/. +- Identify the process that accessed or modified the file by examining the process.name field, ensuring it is not one of the excluded benign processes like dpkg or systemd-sysctl. +- Check the timestamp of the event to correlate it with any known system changes or updates that might explain the file access. +- Investigate the user account associated with the process to determine if the access was authorized or if the account has a history of suspicious activity. +- Examine recent system logs for any other unusual activities or errors that might indicate tampering with system configurations. +- Assess the current system stability and performance to identify any anomalies that could be linked to unauthorized sysctl file modifications. + +### False positive analysis + +- Routine system updates and package installations can trigger file events on sysctl configuration files. To manage this, exclude processes like dpkg and unattended-upg from the detection rule, as they are commonly involved in legitimate system maintenance activities. +- Docker-related operations may access sysctl files as part of container management. Exclude the dockerd process to prevent false positives during normal Docker operations. +- System initialization and configuration processes, such as systemd-sysctl, may read or write to sysctl files. Exclude this process to avoid alerts during standard system boot or configuration changes. +- Monitoring tools like auditbeat may access sysctl files for auditing purposes. Exclude auditbeat to prevent false positives from legitimate monitoring activities. +- Custom scripts or automation tools that frequently interact with sysctl files should be reviewed. If deemed non-threatening, add these specific process names to the exclusion list to reduce unnecessary alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or potential spread of malicious activity. +- Review the sysctl configuration files for unauthorized changes. Restore the files from a known good backup if any unauthorized modifications are detected. +- Identify and terminate any suspicious processes that accessed the sysctl files, especially those not listed in the exclusion criteria of the detection rule. +- Conduct a thorough investigation to determine how the unauthorized access occurred, focusing on potential vulnerabilities or misconfigurations that could have been exploited. +- Apply necessary patches or updates to the system to address any identified vulnerabilities that may have been exploited. +- Enhance monitoring and logging for sysctl file access to ensure any future unauthorized attempts are detected promptly. +- Escalate the incident to the security operations team for further analysis and to determine if additional systems may be affected.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules_building_block/discovery_linux_system_information_discovery.toml b/rules_building_block/discovery_linux_system_information_discovery.toml index 431c60f4301..c5f6478fc24 100644 --- a/rules_building_block/discovery_linux_system_information_discovery.toml +++ b/rules_building_block/discovery_linux_system_information_discovery.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/10" integration = ["endpoint", "auditd_manager"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -37,6 +37,41 @@ process where event.type == "start" and event.action in ("exec", "exec_event", " ) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 System Information Discovery + +Linux system information discovery involves commands like `uname`, `cat`, `more`, and `less` to gather system details such as kernel version, hardware, and configuration files. Adversaries exploit these to understand the environment and tailor attacks. The detection rule identifies suspicious use of these commands, focusing on process events that suggest system probing, thus alerting analysts to potential reconnaissance activities. + +### Possible investigation steps + +- Review the process event details to identify the specific command executed, focusing on the process.name and process.args fields to understand what system information was being queried. +- Check the user context under which the command was executed to determine if it aligns with expected behavior for that user or if it suggests unauthorized access. +- Investigate the parent process of the suspicious command to understand how the process was initiated and if it was part of a legitimate workflow or script. +- Correlate the event with other recent process events from the same host to identify any patterns or sequences that suggest a broader reconnaissance or attack attempt. +- Examine the network activity from the host around the time of the event to detect any potential data exfiltration or communication with known malicious IP addresses. +- Review historical alerts and logs for the host to determine if there have been previous similar activities or other indicators of compromise. + +### False positive analysis + +- Routine system administration tasks may trigger the rule, such as when administrators use commands like uname, cat, more, or less to check system configurations or hardware details. To manage this, consider creating exceptions for known administrator accounts or specific maintenance windows. +- Automated scripts or monitoring tools that regularly check system information for health and performance metrics can also cause false positives. Identify these scripts and exclude their process names or paths from the rule. +- Software updates or installations that involve checking system compatibility might execute these commands. Review the context of such events and whitelist the associated processes or update tools. +- Development or testing environments where frequent system information checks are part of normal operations can lead to alerts. Implement exclusions for these environments by specifying IP ranges or hostnames. +- Security tools that perform regular audits or compliance checks may use these commands as part of their operations. Verify the legitimacy of these tools and exclude their activities from triggering alerts. + +### Response and remediation + +- Isolate the affected system from the network to prevent further reconnaissance or lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, particularly those involving the use of `uname`, `cat`, `more`, or `less` with sensitive arguments. +- Conduct a thorough review of system logs and process histories to identify any unauthorized access or changes made by the adversary. +- Restore any altered configuration files or system settings to their original state using verified backups. +- Update and patch the Linux system to address any vulnerabilities that may have been exploited during the reconnaissance phase. +- Implement stricter access controls and monitoring on sensitive files and directories to prevent unauthorized access in the future. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been compromised.""" [[rule.threat]] diff --git a/rules_building_block/discovery_linux_system_owner_user_discovery.toml b/rules_building_block/discovery_linux_system_owner_user_discovery.toml index 2e2c8d3def8..a20226b1dbd 100644 --- a/rules_building_block/discovery_linux_system_owner_user_discovery.toml +++ b/rules_building_block/discovery_linux_system_owner_user_discovery.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/10" integration = ["endpoint", "auditd_manager"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -37,6 +37,41 @@ query = ''' process where event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started") and process.name : ("whoami", "w", "who", "users", "id") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 System Owner/User Discovery Linux + +In Linux environments, commands like `whoami`, `w`, `who`, `users`, and `id` are essential for identifying the current user and other logged-in users. Adversaries exploit these tools to gather information about system ownership and user activity, aiding in privilege escalation or lateral movement. The detection rule monitors the execution of these commands, flagging potential misuse by correlating process start events with specific command executions, thus alerting analysts to suspicious user enumeration activities. + +### Possible investigation steps + +- Review the process start event details to identify the user account associated with the execution of the flagged command, focusing on the process.name field to confirm which command was executed. +- Examine the timestamp of the event to determine if the command execution aligns with expected user activity or if it occurred during unusual hours. +- Check the source IP address or terminal from which the command was executed to identify if it originated from a known or trusted location. +- Investigate the parent process of the flagged command to understand the context in which it was executed and determine if it was initiated by a legitimate application or script. +- Correlate the event with other recent alerts or logs to identify any patterns of suspicious behavior, such as multiple enumeration commands executed in a short timeframe. +- Assess the risk score and severity in conjunction with other environmental factors to prioritize the investigation and determine if immediate action is required. + +### False positive analysis + +- Routine administrative tasks often involve the use of commands like `whoami` and `id` for legitimate purposes such as verifying user permissions. To reduce false positives, consider creating exceptions for known administrative scripts or users who frequently execute these commands as part of their regular duties. +- Automated monitoring tools or scripts may periodically execute user discovery commands to gather system metrics or perform health checks. Identify these tools and exclude their process names or execution paths from triggering alerts. +- Development and testing environments may see frequent use of these commands by developers or testers. Implement exceptions for specific environments or user groups where such activity is expected and non-threatening. +- Scheduled jobs or cron tasks might execute these commands for logging or auditing purposes. Review and whitelist these scheduled tasks to prevent unnecessary alerts. +- Security tools or agents running on the system might use these commands as part of their normal operation. Verify and exclude these processes to avoid false positives. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Terminate any suspicious processes identified by the alert, particularly those associated with the execution of the `whoami`, `w`, `who`, `users`, or `id` commands, if they are not part of normal operations. +- Conduct a thorough review of user accounts and permissions on the affected system to identify any unauthorized changes or suspicious accounts that may have been created or modified. +- Reset passwords for all user accounts on the affected system, prioritizing accounts with elevated privileges, to mitigate the risk of credential compromise. +- Review system logs and audit trails to identify any additional indicators of compromise or related suspicious activities that may have occurred before or after the alert. +- Escalate the incident to the security operations team or incident response team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and alerting for similar user enumeration activities across the network to detect and respond to future attempts promptly.""" [[rule.threat]] diff --git a/rules_building_block/discovery_net_share_discovery_winlog.toml b/rules_building_block/discovery_net_share_discovery_winlog.toml index 3194c52904e..06b6c79ee98 100644 --- a/rules_building_block/discovery_net_share_discovery_winlog.toml +++ b/rules_building_block/discovery_net_share_discovery_winlog.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/14" integration = ["windows", "system"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -42,6 +42,40 @@ sequence by user.name, source.port, source.ip with maxspan=15s winlog.event_data.ShareName in ("\\\\*\\ADMIN$", "\\\\*\\C$") and source.ip != null and source.ip != "0.0.0.0" and source.ip != "::1" and source.ip != "::" and source.ip != "127.0.0.1"] ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Network Share Discovery + +Network shares allow users to access files and resources across systems, facilitating collaboration. However, adversaries exploit this by scanning for shared folders, especially administrative shares, to gather intelligence or move laterally within a network. The detection rule identifies suspicious access attempts to these shares by monitoring specific event actions and filtering out benign IP addresses, thus highlighting potential reconnaissance activities. + +### Possible investigation steps + +- Review the source IP addresses involved in the alert to determine if they belong to known or trusted devices within the network. Cross-reference these IPs with asset management databases to identify the devices. +- Check the user.name field to verify if the user account associated with the access attempts is legitimate and if it has a history of accessing network shares. Investigate any anomalies in user behavior or access patterns. +- Analyze the timing and frequency of the access attempts by examining the sequence of events within the 15-second maxspan window to identify any patterns or unusual activity that could indicate automated scanning or reconnaissance. +- Investigate the context of the network-share-object-access-checked events by reviewing logs from the involved systems to determine if there were any successful access attempts or subsequent suspicious activities following the initial alert. +- Correlate the alert with other security events or alerts in the same timeframe to identify potential lateral movement or further reconnaissance activities by the same source IP or user account. + +### False positive analysis + +- Routine administrative tasks may trigger alerts when IT staff access administrative shares for legitimate purposes. To mitigate this, create exceptions for known IT personnel or service accounts that regularly perform these tasks. +- Automated backup or monitoring systems might access network shares as part of their normal operations. Identify these systems and exclude their IP addresses from triggering alerts. +- Software updates or patch management tools often scan network shares to deploy updates. Recognize these tools and whitelist their associated IP addresses or user accounts to prevent false positives. +- Internal network scanning tools used for security assessments can mimic adversarial behavior. Ensure these tools are documented and their activities are excluded from detection rules. +- Shared resources accessed by trusted third-party vendors might appear suspicious. Maintain a list of approved vendor IP addresses and exclude them from the rule to avoid unnecessary alerts. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or lateral movement by the adversary. +- Conduct a thorough review of the access logs to identify any unauthorized access attempts and determine the scope of the potential compromise. +- Change passwords for any accounts that were accessed or potentially compromised during the network share discovery attempt. +- Implement network segmentation to limit access to administrative shares and sensitive resources, ensuring only authorized users have access. +- Apply security patches and updates to all systems to mitigate vulnerabilities that could be exploited for network share discovery. +- Enhance monitoring and alerting for suspicious network share access attempts, focusing on unusual patterns or access from unexpected IP addresses. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional containment or remediation actions are necessary.""" [[rule.threat]] diff --git a/rules_building_block/discovery_of_accounts_or_groups_via_builtin_tools.toml b/rules_building_block/discovery_of_accounts_or_groups_via_builtin_tools.toml index 534e6b19c1c..bfa1b70ae95 100644 --- a/rules_building_block/discovery_of_accounts_or_groups_via_builtin_tools.toml +++ b/rules_building_block/discovery_of_accounts_or_groups_via_builtin_tools.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/11" integration = ["endpoint", "auditd_manager"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -40,6 +40,40 @@ process where event.type == "start" and event.action in ("exec", "exec_event", " (process.name == "getent" and process.args in ("passwd", "group")) ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Account or Group Discovery via Built-In Tools + +Built-in tools on Linux and macOS, such as `groups`, `id`, `dscl`, and `getent`, are essential for managing and querying user and group information. Adversaries exploit these tools to enumerate accounts and groups, gaining insights into system configurations and potential targets. The detection rule identifies suspicious use of these tools by monitoring process execution patterns and specific arguments, flagging potential unauthorized discovery activities. + +### Possible investigation steps + +- Review the process execution details, focusing on the process name and arguments, to determine if the usage aligns with typical administrative tasks or if it appears suspicious. +- Check the user account associated with the process execution to verify if the account has legitimate reasons to perform such actions, especially if it involves querying sensitive files like /etc/passwd or /etc/sudoers. +- Investigate the timing and frequency of the process execution to identify any unusual patterns or repeated attempts that could indicate malicious intent. +- Correlate the event with other security alerts or logs from the same host or user to identify any related suspicious activities or anomalies. +- Assess the system's recent login history and user activity to determine if there are any unauthorized access attempts or compromised accounts that could explain the alert. + +### False positive analysis + +- Routine administrative tasks may trigger the rule, such as system administrators using `groups`, `id`, or `getent` to verify user and group configurations. To manage this, create exceptions for known administrative accounts or specific times when these tasks are regularly performed. +- Automated scripts or system management tools that query user and group information for legitimate purposes can also cause false positives. Identify these scripts and whitelist their execution paths or specific arguments used. +- Security compliance checks often involve accessing files like `/etc/passwd` or `/etc/sudoers`. If these checks are part of regular audits, consider excluding the processes or users responsible for these checks from triggering alerts. +- Integration with directory services might involve legitimate use of `dscl` or `dscacheutil` commands. Review and exclude these processes if they are part of normal directory synchronization or querying activities. +- Regular system monitoring tools that perform discovery operations to maintain system health and inventory can be excluded by identifying their process names and arguments, ensuring they align with expected behavior. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, such as those involving `groups`, `id`, `dscl`, `dscacheutil`, or `getent` with unauthorized arguments. +- Conduct a thorough review of user and group accounts on the affected system to identify any unauthorized changes or additions, and revert them if necessary. +- Reset passwords for all accounts on the affected system, prioritizing those with elevated privileges, to mitigate potential credential compromise. +- Review and tighten access controls and permissions on sensitive files such as `/etc/passwd`, `/etc/master.passwd`, and `/etc/sudoers` to prevent unauthorized access. +- Escalate the incident to the security operations team for further investigation and to determine if the activity is part of a larger attack campaign. +- Implement enhanced monitoring and logging for the affected system and similar endpoints to detect any recurrence of the suspicious activity, ensuring logs are retained for future analysis.""" [[rule.threat]] diff --git a/rules_building_block/discovery_of_domain_groups.toml b/rules_building_block/discovery_of_domain_groups.toml index 6a1122dd0d6..6bbb7222cac 100644 --- a/rules_building_block/discovery_of_domain_groups.toml +++ b/rules_building_block/discovery_of_domain_groups.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/23" integration = ["endpoint", "auditd_manager"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -39,6 +39,41 @@ process where host.os.type == "linux" and event.type == "start" and event.action process.name in ("ldapsearch", "dscacheutil") or (process.name == "dscl" and process.args : "*-list*") ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Discovery of Domain Groups + +In Linux environments, commands like `ldapsearch`, `dscacheutil`, and `dscl` are used for querying domain groups and user accounts, aiding system administrators in managing network resources. Adversaries exploit these commands to gather intelligence on group memberships and permissions, which can inform their attack strategies. The detection rule identifies suspicious executions of these commands, flagging potential reconnaissance activities by monitoring specific process names and arguments, thus helping analysts to preemptively address threats. + +### Possible investigation steps + +- Review the alert details to identify the specific command executed, focusing on the process.name field to determine if it was ldapsearch, dscacheutil, or dscl. +- Examine the process.args field to understand the context of the command execution, especially if dscl was used with the -list argument, which may indicate an attempt to enumerate domain groups. +- Check the user account associated with the process execution to determine if the activity aligns with expected behavior for that user or if it appears suspicious. +- Investigate the source host identified by host.os.type to assess if it is a critical system or if it has a history of similar reconnaissance activities. +- Correlate this event with other recent alerts or logs from the same host or user to identify patterns or a sequence of reconnaissance activities that may suggest a larger attack strategy. +- Review network logs or endpoint monitoring data to identify any subsequent suspicious activities following the command execution, such as unauthorized access attempts or data exfiltration. + +### False positive analysis + +- System administrators frequently use commands like ldapsearch, dscacheutil, and dscl for legitimate network management tasks. Regularly review and whitelist these activities if they originate from known administrative accounts or IP addresses. +- Automated scripts or scheduled tasks may execute these commands as part of routine system audits or maintenance. Identify and document these scripts, then create exceptions in the detection rule to prevent unnecessary alerts. +- Security tools or monitoring solutions might use these commands for compliance checks or security assessments. Verify the source of such activities and exclude them if they align with authorized security operations. +- Development or testing environments may generate similar command executions as part of application testing. Ensure these environments are well-documented and consider excluding them from the rule to reduce noise. +- If a specific user or service account is known to perform these actions regularly, consider adding them to an exception list after confirming their legitimacy and necessity for business operations. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further reconnaissance or lateral movement by the adversary. +- Terminate any suspicious processes identified by the detection rule, specifically those involving `ldapsearch`, `dscacheutil`, or `dscl` with the `-list` argument. +- Conduct a thorough review of recent logs and system activities to identify any unauthorized access or changes to group memberships and permissions. +- Reset credentials and review permissions for any accounts that may have been exposed or compromised during the reconnaissance activity. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems have been affected. +- Implement enhanced monitoring on the affected system and similar environments to detect any recurrence of the suspicious activity. +- Review and update firewall and access control policies to limit unnecessary exposure of domain group information to unauthorized users.""" [[rule.threat]] diff --git a/rules_building_block/discovery_posh_generic.toml b/rules_building_block/discovery_posh_generic.toml index 99cc4afdb5d..deb61540a4b 100644 --- a/rules_building_block/discovery_posh_generic.toml +++ b/rules_building_block/discovery_posh_generic.toml @@ -4,7 +4,7 @@ integration = ["windows"] maturity = "production" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." min_stack_version = "8.14.0" -updated_date = "2024/10/28" +updated_date = "2025/01/10" [rule] @@ -140,6 +140,40 @@ event.category:process and host.os.type:windows and ) and not user.id : ("S-1-5-18" or "S-1-5-19" or "S-1-5-20") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 PowerShell Script with Discovery Capabilities + +PowerShell is a powerful scripting language and command-line shell used for task automation and configuration management in Windows environments. Adversaries exploit PowerShell's capabilities to perform reconnaissance, gathering information about users, network configurations, and system settings. The detection rule identifies suspicious PowerShell activity by monitoring specific cmdlets and methods associated with discovery tasks, filtering out benign processes, and focusing on potential threats. + +### Possible investigation steps + +- Review the PowerShell script block text to identify which specific cmdlets or methods were used, focusing on those related to discovery activities such as "Get-ADDomain" or "Get-Process". +- Check the user ID associated with the alert to determine if it belongs to a legitimate user or service account, ensuring it is not one of the excluded IDs like "S-1-5-18", "S-1-5-19", or "S-1-5-20". +- Investigate the context of the process execution by examining related process creation events, including parent processes, to understand how the PowerShell script was initiated. +- Correlate the alert with other security events or logs from the same host to identify any additional suspicious activities or patterns that might indicate a broader attack. +- Assess the risk and impact by determining if the discovered information could be used for further malicious activities, such as privilege escalation or lateral movement within the network. + +### False positive analysis + +- Administrative scripts and tools may trigger the rule when performing legitimate system audits or inventory tasks. To manage this, identify and exclude specific scripts or tools that are known to be safe and frequently used by IT staff. +- Scheduled tasks or automated processes that use PowerShell for system monitoring or maintenance can generate false positives. Review these tasks and exclude their associated user accounts or script names from the detection rule. +- Security software or system management tools that use PowerShell for configuration checks or updates might be flagged. Whitelist these tools by excluding their specific cmdlets or script block texts from the rule. +- PowerShell scripts used in software deployment or updates may match the rule's criteria. Exclude these scripts by adding exceptions for the user accounts or script paths involved in these operations. +- Developers or system administrators using PowerShell for testing or development purposes might inadvertently trigger the rule. Implement exclusions for known development environments or user accounts to reduce false positives. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing reconnaissance activities. +- Conduct a thorough review of user accounts and permissions on the affected system to identify any unauthorized changes or access. +- Reset passwords for potentially compromised accounts, especially those with elevated privileges, to mitigate the risk of further exploitation. +- Analyze PowerShell logs and other relevant system logs to identify any additional indicators of compromise or related malicious activity. +- Escalate the incident to the security operations team for further investigation and to determine if the threat has spread to other systems. +- Implement enhanced monitoring and alerting for PowerShell activities across the network to detect similar threats in the future.""" [[rule.filters]] [rule.filters.meta] diff --git a/rules_building_block/discovery_posh_password_policy.toml b/rules_building_block/discovery_posh_password_policy.toml index 3178120fd4f..102a6ef780b 100644 --- a/rules_building_block/discovery_posh_password_policy.toml +++ b/rules_building_block/discovery_posh_password_policy.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/12" integration = ["windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -91,6 +91,39 @@ event.category: "process" and host.os.type:windows and ) and not user.id : "S-1-5-18" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 PowerShell Script with Password Policy Discovery Capabilities + +PowerShell, a powerful scripting language in Windows, facilitates system management and automation. Adversaries exploit PowerShell to discover password policies, aiding lateral movement and privilege escalation. The detection rule identifies suspicious PowerShell activity by monitoring specific cmdlets and methods linked to password policy queries, filtering out benign scripts and known safe user IDs to pinpoint potential threats. + +### Possible investigation steps + +- Review the PowerShell script block text associated with the alert to identify any suspicious cmdlets or methods, such as "Get-ADDefaultDomainPasswordPolicy" or "ActiveDirectory.DirectorySearcher", that may indicate an attempt to discover password policies. +- Check the user ID associated with the alert to determine if it is a known and trusted user or if it is an unexpected or unauthorized account, especially since the rule excludes the system account "S-1-5-18". +- Investigate the source host of the PowerShell activity to determine if it is a critical system or a less monitored endpoint, which could provide context on the potential impact of the activity. +- Correlate the alert with other recent security events or logs from the same host or user to identify any patterns of suspicious behavior or potential lateral movement attempts. +- Assess the risk score and severity of the alert in conjunction with other security intelligence to prioritize the investigation and response efforts effectively. + +### False positive analysis + +- Scripts used by system administrators for legitimate password policy audits may trigger the rule. To manage this, identify and whitelist specific user IDs or script signatures that are known to perform these tasks regularly. +- Automated compliance checks or security tools that query password policies as part of their routine operations can be mistaken for threats. Exclude these tools by adding their unique identifiers or script block text to the exception list. +- PowerShell scripts executed by trusted applications or services that include password policy queries for configuration purposes might be flagged. Review and exclude these applications by their process names or associated user IDs. +- Development or testing environments where password policy scripts are frequently run for validation purposes can generate false positives. Implement exclusions for these environments by specifying their hostnames or IP addresses. + +### Response and remediation + +- Isolate the affected system from the network to prevent further lateral movement and potential data exfiltration. +- Terminate any suspicious PowerShell processes identified by the detection rule to halt ongoing malicious activities. +- Conduct a thorough review of user accounts and privileges, focusing on any accounts that may have been compromised or used for unauthorized access. +- Reset passwords for affected accounts and enforce a password policy that includes complexity and expiration requirements to mitigate future risks. +- Implement additional monitoring on the affected system and network for any signs of further suspicious activity, particularly related to PowerShell and WinRM usage. +- Escalate the incident to the security operations center (SOC) or incident response team for a comprehensive investigation and to determine the full scope of the breach. +- Review and update endpoint protection measures to ensure they are capable of detecting and blocking similar threats in the future.""" [[rule.threat]] diff --git a/rules_building_block/discovery_potential_memory_seeking_activity.toml b/rules_building_block/discovery_potential_memory_seeking_activity.toml index 5da12a7bb77..e8c32d38b53 100644 --- a/rules_building_block/discovery_potential_memory_seeking_activity.toml +++ b/rules_building_block/discovery_potential_memory_seeking_activity.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2024/02/01" integration = ["endpoint"] maturity = "production" -updated_date = "2024/10/18" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -49,6 +49,39 @@ process where host.os.type == "linux" and event.type == "start" and event.action process.args like "/var/tmp/dracut*" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Memory Seeking Activity + +In Linux environments, utilities like `tail`, `cmp`, `hexdump`, `xxd`, and `dd` are used for legitimate data processing tasks, including reading and manipulating file contents. However, adversaries can exploit these tools to probe memory addresses, potentially setting the stage for further exploitation. The detection rule identifies suspicious use of these utilities by monitoring specific command-line arguments indicative of memory-seeking behavior, while excluding known benign processes to reduce false positives. This approach helps in early detection of potential reconnaissance activities by attackers. + +### Possible investigation steps + +- Review the process details, including the process name and arguments, to confirm if the command usage aligns with typical memory-seeking behavior as outlined in the detection rule. +- Examine the parent process information, such as the parent name and command line, to determine if the process was initiated by a known benign source or if it appears suspicious. +- Check the execution context, including the user account and host details, to assess if the activity is expected for the given environment or user role. +- Investigate any related processes or activities around the same timeframe to identify potential patterns or additional suspicious behavior. +- Correlate the alert with other security events or logs to determine if there are signs of broader reconnaissance or exploitation attempts. + +### False positive analysis + +- Processes initiated by known benign scripts or applications such as error_monitor.sh, acme.sh, dracut, and leapp can trigger false positives. Users should consider adding these to the exclusion list if they are verified as non-threatening in their environment. +- Parent processes like cagefs_enter, nessus-service, platform-python, vdsmd, docker-entrypoint.sh, and lsinitrd-quick are often legitimate and can be excluded if they are part of routine operations. +- Command lines starting with sh and containing acme.sh or involving /var/tmp/dracut are typically benign. Users can exclude these patterns to reduce noise. +- Regularly review and update the exclusion list to ensure it reflects the current operational environment and does not inadvertently allow malicious activity. + +### Response and remediation + +- Isolate the affected system from the network to prevent potential lateral movement by the attacker and to contain the threat. +- Terminate any suspicious processes identified by the detection rule, specifically those involving the use of `tail`, `cmp`, `hexdump`, `xxd`, or `dd` with the flagged arguments. +- Conduct a memory dump and forensic analysis of the affected system to identify any unauthorized access or modifications to memory addresses. +- Review and analyze logs from the affected system to trace the origin of the suspicious activity and identify any other potentially compromised systems. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Apply patches and updates to the affected system to address any vulnerabilities that may have been exploited by the attacker. +- Implement enhanced monitoring and alerting for similar activities across the network to detect and respond to future attempts promptly.""" [[rule.threat]] framework = "MITRE ATT&CK" diff --git a/rules_building_block/discovery_process_discovery_via_builtin_tools.toml b/rules_building_block/discovery_process_discovery_via_builtin_tools.toml index d3826371012..49c59bb8d05 100644 --- a/rules_building_block/discovery_process_discovery_via_builtin_tools.toml +++ b/rules_building_block/discovery_process_discovery_via_builtin_tools.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/11" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -36,6 +36,40 @@ process where event.type == "start" and event.action in ("exec", "exec_event") a ) and not process.parent.name in ("amazon-ssm-agent", "snap") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Process Discovery via Built-In Applications + +Built-in applications like `ps`, `pstree`, `htop`, and `pgrep` are essential for system administrators to monitor and manage processes on Linux and macOS systems. However, adversaries can exploit these tools to gain insights into running processes, aiding in reconnaissance and lateral movement. The detection rule identifies suspicious use of these tools by monitoring process execution events, excluding legitimate parent processes like `amazon-ssm-agent` and `snap`, thus highlighting potential malicious activity. + +### Possible investigation steps + +- Review the alert details to identify the specific built-in application used (e.g., ps, pstree, htop, pgrep) and the associated process execution event. +- Examine the process tree to determine the parent process of the suspicious activity, ensuring it is not a legitimate process like amazon-ssm-agent or snap. +- Investigate the user account associated with the process execution to determine if it aligns with expected behavior or if it might be compromised. +- Check for any recent changes or anomalies in the system that could indicate unauthorized access or configuration changes. +- Correlate the event with other security alerts or logs to identify any patterns or additional suspicious activities that might suggest a broader attack or reconnaissance effort. + +### False positive analysis + +- System management scripts or automation tools may frequently use built-in applications like ps or pgrep for legitimate monitoring tasks. Consider reviewing these scripts and excluding them from the rule if they are verified as non-threatening. +- Developers and IT staff might use htop or pstree during routine system diagnostics. If these activities are common and verified as safe, add exceptions for specific user accounts or parent processes. +- Scheduled maintenance tasks or cron jobs might trigger these tools for system health checks. Identify these tasks and exclude them from the rule to prevent unnecessary alerts. +- Security software or monitoring agents might invoke these commands as part of their normal operation. Verify these processes and exclude them if they are part of trusted applications. +- Training or testing environments where users are learning system administration might generate alerts. Consider excluding these environments from the rule to avoid false positives. + +### Response and remediation + +- Immediately isolate the affected endpoint from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes identified by the alert that are not associated with legitimate parent processes. +- Conduct a thorough review of recent process execution logs to identify any unauthorized or unusual activity that may indicate further compromise. +- Reset credentials and review access permissions for any accounts that were active on the affected endpoint to prevent unauthorized access. +- Deploy endpoint detection and response (EDR) tools to monitor for any further suspicious activity and ensure comprehensive visibility. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if additional endpoints are affected. +- Implement additional monitoring rules to detect similar process discovery attempts, focusing on unusual parent-child process relationships.""" [[rule.threat]] diff --git a/rules_building_block/discovery_signal_unusual_user_host.toml b/rules_building_block/discovery_signal_unusual_user_host.toml index ac2bc337f90..e48a0a6ead2 100644 --- a/rules_building_block/discovery_signal_unusual_user_host.toml +++ b/rules_building_block/discovery_signal_unusual_user_host.toml @@ -2,7 +2,7 @@ bypass_bbr_timing = true creation_date = "2023/10/10" maturity = "production" -updated_date = "2024/09/01" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -39,6 +39,40 @@ host.os.type:windows and event.kind:signal and kibana.alert.rule.rule_id:( "1d72d014-e2ab-4707-b056-9b96abe7b511" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Discovery Activity by User + +In Windows environments, discovery activities involve querying system information, which adversaries exploit to gather intelligence for further attacks. This detection rule identifies anomalies by monitoring unique host and user identifiers linked to discovery actions. By leveraging alert data from foundational rules, it flags unusual patterns, aiding in early threat detection and response. + +### Possible investigation steps + +- Review the alert details to identify the specific host.id and user.id associated with the unusual discovery activity to understand the scope of the potential threat. +- Check the event logs on the identified Windows host for any related discovery activities or other suspicious events around the time of the alert to gather more context. +- Investigate the user account activity associated with the user.id to determine if there are any unauthorized or unexpected actions, such as logins from unusual locations or times. +- Correlate the alert with other security events or alerts involving the same host.id or user.id to identify any patterns or additional indicators of compromise. +- Assess the host's current state for any signs of compromise, such as unexpected processes, network connections, or changes in system configurations, to determine if further containment or remediation actions are necessary. + +### False positive analysis + +- Routine administrative tasks by IT staff may trigger alerts due to frequent system queries. To manage this, create exceptions for known IT user accounts and host identifiers that regularly perform these tasks. +- Automated scripts or monitoring tools that query system information for legitimate purposes can be mistaken for unusual activity. Identify these scripts and tools, and exclude their associated user and host identifiers from the rule. +- Software updates or installations that involve system checks might generate false positives. Review the timing and context of alerts to correlate them with scheduled updates, and exclude relevant identifiers if necessary. +- Security audits or compliance checks often involve extensive system discovery activities. Document these events and exclude the involved user and host identifiers to prevent unnecessary alerts. +- Training or testing environments where discovery activities are simulated can lead to false positives. Ensure these environments are recognized and excluded from the rule to avoid confusion. + +### Response and remediation + +- Isolate the affected host immediately to prevent further lateral movement or data exfiltration. Disconnect it from the network while maintaining power to preserve volatile data for forensic analysis. +- Conduct a thorough review of the user's recent activities and access logs to identify any unauthorized access or data manipulation. Focus on the specific user.id and host.id flagged in the alert. +- Reset the credentials of the affected user account and any other accounts that may have been compromised. Ensure that new credentials adhere to strong password policies. +- Scan the isolated host for malware or unauthorized software using updated antivirus and endpoint detection tools. Remove any malicious files or applications found. +- Restore the affected system from a known good backup if any unauthorized changes or malware are detected that cannot be remediated. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems or users are affected. +- Implement enhanced monitoring on the affected host and user account to detect any recurrence of unusual discovery activities, adjusting alert thresholds if necessary to improve detection accuracy.""" [[rule.threat]] diff --git a/rules_building_block/discovery_suspicious_proc_enumeration.toml b/rules_building_block/discovery_suspicious_proc_enumeration.toml index 5416dfa0a22..a33a57ee20b 100644 --- a/rules_building_block/discovery_suspicious_proc_enumeration.toml +++ b/rules_building_block/discovery_suspicious_proc_enumeration.toml @@ -2,7 +2,7 @@ creation_date = "2023/06/09" integration = ["auditd_manager"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -58,6 +58,40 @@ file.path : (/proc/*/cmdline or /proc/*/stat or /proc/*/exe) and not process.nam ps or netstat or landscape-sysin or w or pgrep or pidof or needrestart or apparmor_status ) and not process.parent.pid : 1 ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Suspicious Proc Pseudo File System Enumeration + +The proc pseudo file system in Linux provides a window into the kernel and running processes, offering critical insights for system management. Adversaries exploit this by rapidly querying files like cmdline, stat, and exe to gather intelligence on active processes, potentially for reconnaissance or privilege escalation. The detection rule identifies such suspicious activity by monitoring for rapid, atypical access patterns to these files, excluding benign processes, thus flagging potential threats. + +### Possible investigation steps + +- Review the process triggering the alert by examining the process.name field to identify any unfamiliar or suspicious processes that are not part of the excluded list. +- Investigate the parent process using the process.parent.pid field to determine if the process hierarchy appears legitimate or if it might be indicative of a compromised or malicious parent process. +- Analyze the frequency and pattern of file access in the /proc/*/cmdline, /proc/*/stat, and /proc/*/exe paths to assess whether the access pattern is consistent with typical system behavior or indicative of reconnaissance activity. +- Check for any recent changes or anomalies in the system logs around the time of the alert to identify any correlated suspicious activities or system changes. +- Cross-reference the process with known threat intelligence sources to determine if it matches any known malicious signatures or behaviors. + +### False positive analysis + +- System monitoring tools that frequently access proc files for legitimate purposes may trigger false positives. Users can mitigate this by adding these tools to the exclusion list in the rule configuration. +- Automated scripts or cron jobs that perform regular system checks might be flagged. Review these scripts and, if deemed safe, exclude their process names from the rule. +- Custom administrative tools developed in-house that perform process checks could be mistakenly identified as threats. Verify their behavior and add them to the exception list if they are benign. +- Security software that performs regular scans of system processes may also be detected. Confirm the legitimacy of such software and exclude it from the rule to prevent false alerts. +- Development or testing environments where processes are frequently started and stopped might generate false positives. Consider excluding these environments from monitoring or adjusting the rule sensitivity for these specific cases. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary. +- Terminate any suspicious processes identified as rapidly accessing the proc pseudo file system, especially those not whitelisted in the detection rule. +- Conduct a thorough review of the system's process tree to identify any unauthorized or unexpected parent-child process relationships, focusing on those not originating from init (PID 1). +- Analyze the system logs to trace the origin of the suspicious activity, identifying any potential entry points or vulnerabilities exploited by the adversary. +- Apply security patches and updates to the affected system to address any known vulnerabilities that may have been exploited. +- Restore the system from a known good backup if any signs of compromise or unauthorized changes are detected. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules_building_block/discovery_system_network_connections.toml b/rules_building_block/discovery_system_network_connections.toml index 146fae92b45..f6da04eaf41 100644 --- a/rules_building_block/discovery_system_network_connections.toml +++ b/rules_building_block/discovery_system_network_connections.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/11" integration = ["endpoint", "auditd_manager"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -35,6 +35,40 @@ query = ''' process where event.type == "start" and event.action in ("exec", "exec_event", "executed", "process_started") and process.name in ("netstat", "lsof", "who", "w") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 System Network Connections Discovery + +System network connections discovery involves tools like `netstat` and `lsof` to list active connections, aiding in network diagnostics. Adversaries exploit this to map network topology and identify potential targets. The detection rule identifies suspicious use of these tools by monitoring process execution events, flagging unusual activity patterns indicative of reconnaissance efforts. + +### Possible investigation steps + +- Review the process execution event details to confirm the process name is either "netstat", "lsof", "who", or "w", as these are the tools flagged by the rule. +- Check the user account associated with the process execution to determine if the activity aligns with expected behavior for that user or if it appears suspicious. +- Investigate the parent process of the flagged execution to understand the context in which the network discovery tool was launched, which may provide insights into whether the activity is part of a legitimate workflow or a potential threat. +- Analyze the timing and frequency of the process execution events to identify patterns that may suggest automated or scripted activity, which could indicate malicious intent. +- Correlate the event with other security alerts or logs from the same host or user to identify any additional indicators of compromise or related suspicious activities. +- Examine network logs or connection details to identify any unusual or unauthorized network connections that may have been established as a result of the network discovery activity. + +### False positive analysis + +- Routine administrative tasks may trigger the rule when system administrators use netstat or lsof for legitimate network diagnostics. To manage this, create exceptions for known administrator accounts or specific times when these tasks are regularly performed. +- Automated monitoring scripts that include network diagnostics commands like netstat or lsof can cause false positives. Identify and exclude these scripts by their process names or execution paths. +- System health checks or security tools that periodically run netstat or lsof as part of their operations can be mistaken for suspicious activity. Whitelist these tools by verifying their signatures and ensuring they are from trusted sources. +- Development or testing environments where network tools are frequently used for debugging purposes may generate alerts. Implement exclusions based on environment-specific identifiers or IP ranges to reduce noise. + +### Response and remediation + +- Isolate the affected system from the network to prevent further reconnaissance or lateral movement by the adversary. +- Terminate any suspicious processes identified as using `netstat`, `lsof`, `who`, or `w` that are not part of normal operations or expected administrative tasks. +- Conduct a thorough review of recent network connection logs to identify any unauthorized or unusual connections that may indicate further compromise or data exfiltration. +- Reset credentials and review access permissions for accounts on the affected system to ensure no unauthorized access persists. +- Apply security patches and updates to the affected system to mitigate any known vulnerabilities that could have been exploited. +- Enhance monitoring and logging on the affected system and network to detect any further suspicious activities or attempts to use similar discovery techniques. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules_building_block/discovery_system_service_discovery.toml b/rules_building_block/discovery_system_service_discovery.toml index c70601ed3a0..6fe45d6a859 100644 --- a/rules_building_block/discovery_system_service_discovery.toml +++ b/rules_building_block/discovery_system_service_discovery.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/01/24" integration = ["windows", "endpoint", "system"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -52,6 +52,40 @@ process where host.os.type == "windows" and event.type == "start" and (process.name : "psservice.exe" or process.pe.original_file_name == "psservice.exe") ) and not user.id : "S-1-5-18" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 System Service Discovery through built-in Windows Utilities + +System service discovery is a technique used to enumerate services running on a Windows system, often leveraging built-in utilities like `net.exe`, `sc.exe`, and `tasklist.exe`. Adversaries exploit these tools to gather information about services for privilege escalation or lateral movement. The detection rule identifies suspicious use of these utilities by monitoring specific command-line arguments and process behaviors, excluding known benign system accounts, to flag potential reconnaissance activities. + +### Possible investigation steps + +- Review the process details to confirm the execution of `net.exe`, `sc.exe`, `tasklist.exe`, or `psservice.exe` by checking the process name and original file name fields. Verify if the command-line arguments match those specified in the rule, such as "start", "use", "query", "q*", or "/svc". +- Investigate the user account associated with the process execution by examining the user.id field. Determine if the account is unusual or unauthorized for performing such actions, especially since the rule excludes the system account "S-1-5-18". +- Check the parent process of the flagged process to understand the context of execution. This can help identify if the process was spawned by a legitimate application or a potentially malicious script or tool. +- Analyze the timing and frequency of the detected activity. Determine if this is a one-time occurrence or part of a pattern, which could indicate automated or scripted reconnaissance. +- Correlate the alert with other security events or logs from the same host or user to identify any additional suspicious activities, such as failed login attempts, unusual network connections, or file modifications, that might suggest a broader attack campaign. + +### False positive analysis + +- System administrators or automated scripts may use net.exe, sc.exe, or tasklist.exe for legitimate system management tasks. To reduce false positives, consider excluding these processes when executed by known administrative accounts or service accounts. +- Scheduled tasks or maintenance scripts might invoke these utilities for routine checks. Identify and document such scripts, then create exceptions for their execution patterns to prevent unnecessary alerts. +- Some third-party software may use these utilities as part of their normal operation. Monitor and whitelist these applications if they are verified to be safe and necessary for business operations. +- Training and awareness for IT staff can help differentiate between legitimate and suspicious use of these utilities, reducing the likelihood of misidentifying benign activities as threats. +- Regularly review and update the list of excluded accounts and processes to ensure that only verified non-threatening behaviors are exempted from detection. + +### Response and remediation + +- Isolate the affected system from the network to prevent further lateral movement or data exfiltration by the adversary. +- Terminate any suspicious processes identified by the detection rule, such as instances of net.exe, sc.exe, or tasklist.exe, that are not associated with legitimate administrative tasks. +- Conduct a thorough review of user accounts and privileges on the affected system to identify any unauthorized changes or escalations, and revert any suspicious modifications. +- Reset passwords for potentially compromised accounts, especially those with administrative privileges, to prevent unauthorized access. +- Review and apply any necessary security patches or updates to the affected system to address potential vulnerabilities exploited by the adversary. +- Monitor network traffic and system logs for any signs of further reconnaissance or malicious activity, focusing on the use of built-in utilities and unusual command-line arguments. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected.""" [[rule.threat]] diff --git a/rules_building_block/discovery_system_time_discovery.toml b/rules_building_block/discovery_system_time_discovery.toml index d58b327e2a1..d813f41e5b8 100644 --- a/rules_building_block/discovery_system_time_discovery.toml +++ b/rules_building_block/discovery_system_time_discovery.toml @@ -5,7 +5,7 @@ integration = ["windows", "endpoint", "system"] min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." min_stack_version = "8.14.0" maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -52,6 +52,40 @@ process where host.os.type == "windows" and event.type == "start" and (process.name: "tzutil.exe" and process.args: "/g") ) and not user.id : ("S-1-5-18", "S-1-5-19", "S-1-5-20") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 System Time Discovery + +System time discovery involves querying a system's time settings, which adversaries exploit to synchronize attacks or evade detection. Attackers may use commands like `net time`, `w32tm`, or `tzutil` to gather time information. The detection rule identifies these activities by monitoring specific processes and arguments, excluding known system accounts, to flag potential reconnaissance efforts. + +### Possible investigation steps + +- Review the process details to confirm the presence of suspicious commands, such as "net time", "w32tm /tz", or "tzutil /g", and verify if these were executed by unexpected or unauthorized users. +- Check the user ID associated with the process to ensure it is not one of the excluded system accounts (S-1-5-18, S-1-5-19, S-1-5-20) and determine if the user is legitimate or potentially compromised. +- Investigate the parent process of the suspicious activity to understand the context of execution and identify if it was initiated by a legitimate application or a potentially malicious script or program. +- Correlate the event with other logs or alerts from the same host to identify any additional suspicious activities or patterns that might indicate a broader attack or reconnaissance effort. +- Assess the timing and frequency of the detected commands to determine if they align with normal operational procedures or if they suggest an anomaly that warrants further investigation. + +### False positive analysis + +- System maintenance tasks may trigger the rule when administrators use time-related commands for legitimate purposes. To manage this, create exceptions for known maintenance scripts or tools used by trusted administrators. +- Automated scripts or software that synchronize time settings across multiple systems can cause false positives. Identify these scripts and exclude their associated user accounts or process names from the rule. +- Scheduled tasks that involve time synchronization or adjustments might be flagged. Review scheduled tasks and exclude those that are part of routine system operations. +- Monitoring tools that check system time as part of their health checks can be mistaken for reconnaissance. Whitelist these tools by excluding their process names or user accounts from the detection rule. +- Training or testing environments where time-related commands are frequently executed for educational purposes can generate alerts. Exclude these environments by filtering based on specific hostnames or user accounts. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, such as instances of `net.exe`, `w32tm.exe`, or `tzutil.exe` running with unusual arguments. +- Conduct a thorough review of user accounts and privileges on the affected system to ensure no unauthorized changes have been made, focusing on accounts not excluded by the detection rule. +- Check for any signs of lateral movement or additional compromise on the network by reviewing logs and alerts from other systems. +- Restore the system time settings to their correct state if they have been altered, ensuring synchronization with a trusted time source. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement enhanced monitoring and logging for time-related commands and processes to detect similar activities in the future.""" [[rule.threat]] diff --git a/rules_building_block/discovery_userdata_request_from_ec2_instance.toml b/rules_building_block/discovery_userdata_request_from_ec2_instance.toml index 86698b83778..ad87e12cc59 100644 --- a/rules_building_block/discovery_userdata_request_from_ec2_instance.toml +++ b/rules_building_block/discovery_userdata_request_from_ec2_instance.toml @@ -2,7 +2,7 @@ creation_date = "2024/04/14" integration = ["aws"] maturity = "production" -updated_date = "2024/07/23" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -43,6 +43,40 @@ event.dataset:aws.cloudtrail and event.action:DescribeInstanceAttribute and aws.cloudtrail.request_parameters:(*attribute=userData* and *instanceId*) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Attempt to Retrieve User Data from AWS EC2 Instance + +AWS EC2 instances can store sensitive configuration data in user data scripts, which are executed during instance launch. Adversaries may exploit the `DescribeInstanceAttribute` API call to access this data, potentially exposing vulnerabilities or sensitive information. The detection rule monitors CloudTrail logs for such API calls, flagging attempts to access user data, thus serving as an early indicator of suspicious activity. + +### Possible investigation steps + +- Review the CloudTrail logs to identify the source IP address and user identity associated with the DescribeInstanceAttribute API call to determine if the request was made by an authorized user or system. +- Check the AWS IAM policies and roles associated with the user or service making the request to ensure they have the appropriate permissions and that there are no overly permissive policies in place. +- Investigate the instanceId specified in the request to understand the context of the EC2 instance, including its purpose, the data it handles, and any recent changes or activities associated with it. +- Examine the attribute userData in the request to assess what specific data or scripts might be exposed and evaluate the potential impact if this information were accessed by unauthorized parties. +- Correlate this event with other logs and alerts to identify any patterns or sequences of actions that might indicate a broader reconnaissance or attack attempt, such as multiple DescribeInstanceAttribute requests or other discovery-related activities. + +### False positive analysis + +- Routine administrative tasks may trigger the DescribeInstanceAttribute API call when checking instance configurations. To manage this, identify and whitelist known administrative accounts or roles that regularly perform these tasks. +- Automated scripts or monitoring tools might use the DescribeInstanceAttribute API call to verify instance settings. Review and document these tools, then create exceptions for their activity to prevent unnecessary alerts. +- Cloud management platforms often perform discovery operations that include DescribeInstanceAttribute calls. Ensure these platforms are recognized and their actions are excluded from triggering alerts by adding them to an exception list. +- Scheduled audits or compliance checks might involve DescribeInstanceAttribute requests. Coordinate with compliance teams to understand their schedules and exclude these activities from detection rules. +- Development and testing environments may frequently use DescribeInstanceAttribute for configuration validation. Segregate these environments and apply specific rules that account for their unique activity patterns. + +### Response and remediation + +- Immediately isolate the affected EC2 instance to prevent further unauthorized access or data exfiltration. This can be done by modifying the security group to restrict inbound and outbound traffic. +- Review the AWS CloudTrail logs to identify any unauthorized users or IP addresses that accessed the `DescribeInstanceAttribute` API call. Revoke any suspicious access keys or credentials associated with these users. +- Conduct a thorough audit of the user data scripts stored on the affected EC2 instance to identify any sensitive information that may have been exposed. Remove or encrypt sensitive data as necessary. +- Rotate any credentials or secrets that were stored in the user data scripts to prevent unauthorized use. +- Implement additional monitoring and alerting for similar API calls in CloudTrail to detect and respond to future attempts promptly. +- Escalate the incident to the security operations team for further investigation and to determine if additional instances or resources have been compromised. +- Review and update IAM policies to ensure that only authorized users have the necessary permissions to access sensitive EC2 attributes, following the principle of least privilege.""" [[rule.threat]] diff --git a/rules_building_block/discovery_win_network_connections.toml b/rules_building_block/discovery_win_network_connections.toml index dc1f9d25751..a7608781df8 100644 --- a/rules_building_block/discovery_win_network_connections.toml +++ b/rules_building_block/discovery_win_network_connections.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/07/14" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -48,6 +48,39 @@ process where event.type == "start" and (process.name : "nbtstat.exe" and process.args : "-s*") ) and not user.id : "S-1-5-18" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Windows System Network Connections Discovery + +Windows systems provide utilities like `netstat`, `net`, and `nbtstat` to manage and monitor network connections. Adversaries exploit these tools to map network connections, identifying potential targets. The detection rule monitors the execution of these utilities, focusing on specific arguments that suggest enumeration activities, while excluding benign system processes, to identify suspicious network discovery attempts. + +### Possible investigation steps + +- Review the process execution details to identify the user account associated with the alert, focusing on the user.id field to determine if it deviates from expected user behavior. +- Examine the parent process of the flagged command to understand the context of execution and assess whether it was initiated by a legitimate application or script. +- Investigate the command-line arguments used with the executed process (e.g., netstat.exe, net.exe, nbtstat.exe) to determine if they align with typical administrative tasks or suggest malicious intent. +- Check the historical activity of the involved user account and system to identify any patterns or anomalies that could indicate a broader compromise or unauthorized access. +- Correlate the alert with other security events or logs from the same timeframe to identify any related suspicious activities or indicators of compromise within the network. + +### False positive analysis + +- System administrators or network engineers may frequently use netstat, net, or nbtstat for legitimate network troubleshooting and monitoring tasks. To reduce false positives, consider excluding these users or specific user IDs from the rule, especially if they are known to perform these tasks regularly. +- Automated scripts or scheduled tasks that utilize these network utilities for system health checks or inventory purposes can trigger the rule. Identify and exclude these processes by their parent process name or specific command-line arguments that are consistently used in these scripts. +- Security software or network management tools might invoke these commands as part of their normal operations. Review the parent process names and user IDs associated with these tools and add them to the exclusion list to prevent unnecessary alerts. +- In environments where network configurations are frequently changed or updated, legitimate use of net and net1 commands with arguments like "use", "user", "session", and "config" might be common. Monitor and document these activities to distinguish between routine operations and potential threats, and adjust the rule to exclude these known benign activities. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, such as those involving netstat.exe, net.exe, net1.exe, or nbtstat.exe with suspicious arguments. +- Conduct a thorough review of recent network connections and communications from the affected system to identify any unauthorized access or data transfers. +- Reset credentials for any user accounts that were active on the affected system during the time of the alert to prevent further unauthorized access. +- Apply patches and updates to the affected system to address any vulnerabilities that may have been exploited by the adversary. +- Monitor the network for any further suspicious activity or attempts to use similar network discovery tools, adjusting network security policies as necessary. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are compromised.""" [[rule.threat]] diff --git a/rules_building_block/discovery_windows_system_information_discovery.toml b/rules_building_block/discovery_windows_system_information_discovery.toml index af6dab02a4d..feeb366feb8 100644 --- a/rules_building_block/discovery_windows_system_information_discovery.toml +++ b/rules_building_block/discovery_windows_system_information_discovery.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/07/06" integration = ["windows", "endpoint", "system"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -54,6 +54,39 @@ process.parent.executable : ( "?:\\ProgramData\\*" ) and not user.id : "S-1-5-18" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Windows System Information Discovery + +Windows system information discovery involves querying system details like OS version, hostname, and configuration, typically for legitimate administrative tasks. However, attackers exploit this to gain insights into a compromised system's environment, aiding in further attacks. The detection rule identifies suspicious use of system commands like `cmd.exe`, `systeminfo.exe`, and `wmic.exe` by filtering out benign processes and known safe parent executables, flagging potential malicious activity. + +### Possible investigation steps + +- Review the process details to confirm the execution of suspicious commands like cmd.exe, systeminfo.exe, hostname.exe, or wmic.exe, focusing on the arguments used, such as "ver*" or "os get". +- Examine the parent process executable path to determine if it deviates from typical benign paths, such as those within Program Files or ProgramData directories, which are excluded in the rule. +- Investigate the user account associated with the process execution, especially if the user ID is not "S-1-5-18", which indicates a non-system account, to assess if the activity aligns with the user's normal behavior. +- Check the historical activity of the involved processes and user account to identify any patterns or anomalies that could suggest malicious intent or compromise. +- Correlate the alert with other security events or logs from the same host to identify any preceding or subsequent suspicious activities that might indicate a broader attack campaign. + +### False positive analysis + +- Legitimate administrative scripts or tools may trigger the rule if they use commands like cmd.exe, systeminfo.exe, or wmic.exe. To handle this, identify and whitelist these known safe scripts by adding their parent executable paths to the exception list. +- Automated software updates or system management tools might execute these commands as part of their routine operations. Exclude these processes by specifying their parent executable paths, such as those located in Program Files or ProgramData directories. +- Developers or IT personnel using command-line tools for legitimate purposes can also cause false positives. Consider excluding user IDs associated with these roles if they are consistently triggering the rule without malicious intent. +- Custom scripts or batch files that perform system checks may inadvertently match the detection criteria. Review these scripts and, if deemed safe, add their specific paths or parent executables to the exclusion list to prevent unnecessary alerts. + +### Response and remediation + +- Isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate any suspicious processes identified by the detection rule, such as cmd.exe, systeminfo.exe, or wmic.exe, that are not associated with legitimate administrative tasks. +- Conduct a thorough review of the affected system's recent activity logs to identify any additional indicators of compromise or lateral movement attempts. +- Reset credentials for any user accounts that were active on the affected system during the time of the alert to prevent unauthorized access. +- Restore the system from a known good backup if any unauthorized changes or malware are detected. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Update endpoint detection and response tools to enhance monitoring for similar suspicious activities, ensuring that any gaps identified during this incident are addressed.""" [[rule.threat]] diff --git a/rules_building_block/execution_aws_lambda_function_updated.toml b/rules_building_block/execution_aws_lambda_function_updated.toml index 773ea2fdede..ed6bcd32b46 100644 --- a/rules_building_block/execution_aws_lambda_function_updated.toml +++ b/rules_building_block/execution_aws_lambda_function_updated.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2024/04/20" integration = ["aws"] maturity = "production" -updated_date = "2024/09/01" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -54,6 +54,40 @@ event.dataset: "aws.cloudtrail" and event.outcome: "success" and event.action: (CreateFunction* or UpdateFunctionCode*) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 AWS Lambda Function Created or Updated + +AWS Lambda allows execution of code without server management, offering flexibility and scalability. However, adversaries may exploit this by creating or updating functions to run malicious code, steal data, or gain elevated access. The detection rule monitors successful creation or updates of Lambda functions, signaling potential misuse by tracking specific actions in AWS CloudTrail logs. + +### Possible investigation steps + +- Review the AWS CloudTrail logs to identify the user or role that initiated the CreateFunction or UpdateFunctionCode actions. Check for any unusual or unauthorized users. +- Examine the source IP address and geolocation associated with the event to determine if it originates from an expected or suspicious location. +- Analyze the function code or configuration changes made during the update to identify any potentially malicious code or unexpected modifications. +- Check the permissions and roles associated with the Lambda function to ensure they are not overly permissive and do not allow unauthorized access or privilege escalation. +- Investigate any related AWS services or resources that interact with the Lambda function to assess potential lateral movement or data exfiltration risks. +- Correlate the event with other security alerts or logs to identify any patterns or additional indicators of compromise that may suggest a broader attack. + +### False positive analysis + +- Routine updates to Lambda functions by development teams can trigger the rule. To manage this, create exceptions for specific user roles or accounts that are known to perform regular updates. +- Automated deployment tools that update Lambda functions as part of a CI/CD pipeline may cause false positives. Exclude actions from these tools by identifying their specific IAM roles or user agents. +- Scheduled updates or maintenance activities that involve Lambda function modifications can be mistaken for suspicious activity. Document and exclude these scheduled events by correlating them with known maintenance windows. +- Third-party integrations that require Lambda function updates might trigger the rule. Identify and exclude these integrations by their unique identifiers or associated accounts. + +### Response and remediation + +- Immediately isolate the affected AWS Lambda function by disabling it to prevent further execution of potentially malicious code. +- Review the AWS CloudTrail logs to identify any unauthorized access or changes made to the Lambda function, focusing on the user or role that performed the action. +- Revert any unauthorized changes to the Lambda function by restoring it to a known good state using versioning or backups. +- Conduct a security review of the IAM roles and permissions associated with the Lambda function to ensure they follow the principle of least privilege. +- Notify the security operations team and relevant stakeholders about the incident for further investigation and potential escalation. +- Implement additional monitoring and alerting for changes to Lambda functions to detect similar activities in the future. +- Consider enabling AWS Config rules to continuously monitor and enforce compliance with security best practices for Lambda functions.""" [[rule.threat]] diff --git a/rules_building_block/execution_github_new_event_action_for_pat.toml b/rules_building_block/execution_github_new_event_action_for_pat.toml index e8ab2101ae1..201d28b232e 100644 --- a/rules_building_block/execution_github_new_event_action_for_pat.toml +++ b/rules_building_block/execution_github_new_event_action_for_pat.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/10/11" integration = ["github"] maturity = "production" -updated_date = "2024/12/10" +updated_date = "2025/01/10" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." @@ -35,6 +35,41 @@ event.dataset:"github.audit" and event.category:"configuration" and event.action:* and github.hashed_token:* and github.programmatic_access_type:("OAuth access token" or "Fine-grained personal access token") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 First Occurrence GitHub Event for a Personal Access Token (PAT) + +Personal Access Tokens (PATs) in GitHub provide a way to authenticate programmatic access to repositories, enabling automation and integration. Adversaries may exploit PATs to gain unauthorized access, execute code, or exfiltrate data. The detection rule identifies unusual PAT activity by flagging tokens not seen in recent history, helping to uncover potential misuse or unauthorized access attempts. + +### Possible investigation steps + +- Review the event details to identify the specific hashed token involved in the alert and determine if it corresponds to any known or expected activity. +- Check the GitHub audit logs for any recent configuration changes or actions associated with the identified token to understand its usage context. +- Investigate the user or application associated with the token to verify if they have a legitimate reason for accessing the repository or resources. +- Assess the scope of access granted by the token, especially if it is a fine-grained personal access token, to evaluate potential risks or exposure. +- Look for any other unusual or suspicious activities in the GitHub environment around the time of the alert to identify potential patterns or related incidents. +- Contact the owner of the token, if identifiable, to confirm whether the token usage was authorized and expected. + +### False positive analysis + +- New legitimate integrations or applications may trigger the rule when they first use a PAT. Users should review the source and purpose of the token and, if verified as non-threatening, add the token to an allowlist to prevent future alerts. +- Routine administrative tasks or updates that require new PATs can cause false positives. Document these tasks and create exceptions for known administrative activities to reduce unnecessary alerts. +- Developers frequently creating and rotating PATs for testing purposes might trigger the rule. Establish a process to track and approve these activities, and consider excluding tokens associated with specific development environments. +- Automated scripts or CI/CD pipelines that generate new PATs for each run can be mistaken for suspicious activity. Identify these scripts and pipelines, and configure the rule to recognize and exclude their expected behavior. +- Organizational changes, such as team restructuring or onboarding new team members, may lead to increased PAT creation. Monitor these changes and temporarily adjust the rule's sensitivity or add exceptions during transition periods. + +### Response and remediation + +- Immediately revoke the identified Personal Access Token (PAT) to prevent any unauthorized access or actions using the token. +- Review the access logs associated with the PAT to identify any suspicious activities or unauthorized access attempts that may have occurred. +- Notify the repository owner and relevant stakeholders about the potential security incident and provide details of the PAT usage and associated risks. +- Conduct a security review of the affected repositories to ensure no unauthorized changes or data exfiltration occurred during the period the PAT was active. +- Implement additional monitoring for any further unusual activities or access attempts related to the compromised PAT or associated accounts. +- Escalate the incident to the security team for a comprehensive investigation and to determine if further actions are necessary, such as notifying affected users or partners. +- Enhance security measures by enforcing stricter access controls and considering the use of more granular permissions for future PATs to minimize potential impact.""" [[rule.threat]] diff --git a/rules_building_block/execution_github_new_repo_interaction_for_pat.toml b/rules_building_block/execution_github_new_repo_interaction_for_pat.toml index af1fe749b4a..b7782edd786 100644 --- a/rules_building_block/execution_github_new_repo_interaction_for_pat.toml +++ b/rules_building_block/execution_github_new_repo_interaction_for_pat.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/10/11" integration = ["github"] maturity = "production" -updated_date = "2024/12/10" +updated_date = "2025/01/10" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." @@ -36,6 +36,41 @@ github.repo:* and github.hashed_token:* and github.programmatic_access_type:("OAuth access token" or "Fine-grained personal access token") and github.repository_public:false ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 First Occurrence of Private Repo Event from Specific GitHub Personal Access Token (PAT) + +GitHub Personal Access Tokens (PATs) enable programmatic access to repositories, facilitating automation and integration. However, adversaries can exploit compromised PATs to access private repositories, potentially exfiltrating sensitive data. This detection rule identifies unusual private repo interactions by monitoring for PAT activity not observed in the past 14 days, signaling potential unauthorized access attempts. + +### Possible investigation steps + +- Review the specific GitHub repository involved in the alert to determine its sensitivity and the potential impact of unauthorized access. +- Identify the user or system associated with the hashed_token in the alert to verify if the access was expected or authorized. +- Check the history of the GitHub Personal Access Token (PAT) usage to determine if there have been any other unusual activities or patterns. +- Investigate the OAuth access token or fine-grained personal access token to confirm its legitimacy and whether it has been compromised. +- Contact the repository owner or relevant team members to verify if the access aligns with any recent changes or integrations. +- Assess the event's context within the broader security environment to identify any related alerts or incidents that might indicate a larger security issue. + +### False positive analysis + +- Regularly scheduled automated tasks using PATs may trigger alerts. Identify and document these tasks to create exceptions for known, non-threatening activities. +- Developers frequently accessing private repositories for legitimate purposes might cause false positives. Maintain a list of authorized users and their expected access patterns to exclude them from alerts. +- Integration tools or CI/CD pipelines using PATs for routine operations can be mistaken for unauthorized access. Verify these tools and add them to an allowlist to prevent unnecessary alerts. +- Temporary access granted to external collaborators for specific projects may appear as unusual activity. Ensure these instances are logged and monitored, and create temporary exceptions as needed. +- Changes in team structure or roles leading to new PAT usage should be communicated to the security team to update monitoring rules accordingly. + +### Response and remediation + +- Immediately revoke the compromised GitHub Personal Access Token (PAT) to prevent further unauthorized access to private repositories. +- Notify the repository owner and relevant stakeholders about the potential breach to ensure they are aware and can take necessary precautions. +- Conduct a thorough review of recent activities associated with the compromised PAT to identify any unauthorized changes or data exfiltration. +- Reset credentials and access tokens for all affected users and services to mitigate the risk of further unauthorized access. +- Implement additional monitoring and alerting for unusual activities in private repositories to detect similar threats in the future. +- Escalate the incident to the security team for a comprehensive investigation and to determine if further actions are required. +- Review and update access controls and permissions for private repositories to ensure they follow the principle of least privilege.""" [[rule.threat]] diff --git a/rules_building_block/execution_github_new_repo_interaction_for_user.toml b/rules_building_block/execution_github_new_repo_interaction_for_user.toml index 5aabab32d3c..ac550245dee 100644 --- a/rules_building_block/execution_github_new_repo_interaction_for_user.toml +++ b/rules_building_block/execution_github_new_repo_interaction_for_user.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/10/11" integration = ["github"] maturity = "production" -updated_date = "2024/12/10" +updated_date = "2025/01/10" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." @@ -35,6 +35,41 @@ event.dataset:"github.audit" and event.category:"configuration" and github.repo:* and user.name:* and github.repository_public:false ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 First Occurrence of GitHub User Interaction with Private Repo + +GitHub is a platform for version control and collaboration, allowing users to manage and store code in repositories. Private repositories are restricted to specific users, making unauthorized access a security concern. Adversaries may exploit compromised credentials to access sensitive code. The detection rule identifies unusual user interactions with private repositories, flagging users who haven't accessed them in the past 14 days, which may indicate potential unauthorized access attempts. + +### Possible investigation steps + +- Review the specific GitHub audit event details to identify the user involved in the interaction by examining the user.name field. +- Verify the user's recent activity history on GitHub to determine if there are any other unusual or unauthorized actions, focusing on the last 14 days. +- Check the access permissions and roles assigned to the user for the private repository in question to assess if the access was legitimate or potentially unauthorized. +- Contact the user or their manager to confirm whether the interaction with the private repository was expected or authorized. +- Investigate any recent changes to the user's credentials or access rights, such as password resets or role modifications, that could indicate a compromise. +- Correlate this event with other security logs or alerts to identify any patterns or additional indicators of compromise related to the user's account. + +### False positive analysis + +- Users returning from vacation or leave may trigger the rule due to a lack of recent activity. Consider implementing a temporary exception for these users based on their leave schedule. +- New team members or contractors accessing private repositories for the first time can be flagged. Maintain a list of new users and exclude them from the rule for an initial period. +- Users involved in infrequent but legitimate projects may not access certain repositories regularly. Identify these projects and create exceptions for associated users. +- Scheduled maintenance or audits by IT staff might result in flagged interactions. Coordinate with IT to whitelist these activities during known maintenance windows. +- Automated scripts or tools that interact with repositories on behalf of users can cause false positives. Ensure these tools are properly documented and excluded from the rule. + +### Response and remediation + +- Immediately verify the legitimacy of the user interaction by contacting the user to confirm whether they initiated the access. If the user cannot be reached or denies the activity, proceed with containment steps. +- Temporarily revoke the user's access to the private repository to prevent further unauthorized actions while the investigation is ongoing. +- Conduct a thorough review of recent access logs and activities associated with the user's account to identify any other suspicious actions or potential compromise indicators. +- Reset the user's credentials and enforce multi-factor authentication (MFA) to secure the account against further unauthorized access. +- If unauthorized access is confirmed, perform a security audit of the affected repository to identify any data exposure or code alterations, and take necessary steps to mitigate any identified risks. +- Notify the security team and relevant stakeholders about the incident, providing details of the unauthorized access and actions taken, and escalate to higher management if sensitive data is involved. +- Update detection mechanisms and monitoring tools to enhance the identification of similar unauthorized access attempts in the future, leveraging insights from the incident.""" [[rule.threat]] diff --git a/rules_building_block/execution_github_repo_created.toml b/rules_building_block/execution_github_repo_created.toml index 40ab0a8d88b..1c6b3f48347 100644 --- a/rules_building_block/execution_github_repo_created.toml +++ b/rules_building_block/execution_github_repo_created.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/10/11" integration = ["github"] maturity = "production" -updated_date = "2024/12/10" +updated_date = "2025/01/10" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." @@ -33,6 +33,40 @@ type = "eql" query = ''' configuration where event.dataset == "github.audit" and event.action == "repo.create" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GitHub Repo Created +GitHub repositories are essential for code collaboration and version control in cloud environments. Adversaries may exploit this by creating repositories to host malicious code or scripts for execution. The detection rule monitors GitHub audit logs for repository creation events, flagging potential unauthorized or suspicious activities that align with execution tactics, thereby aiding in early threat identification. + +### Possible investigation steps + +- Review the GitHub audit logs to confirm the details of the repository creation event, including the timestamp and the user account responsible for the action. +- Verify the identity and role of the user who created the repository to determine if they have legitimate reasons and permissions to create new repositories. +- Check the contents of the newly created repository for any suspicious or malicious code, scripts, or files that could indicate unauthorized activity. +- Investigate any recent changes in user permissions or access levels that might have allowed unauthorized repository creation. +- Correlate the repository creation event with other security alerts or logs to identify any related suspicious activities or patterns. +- Contact the user or team responsible for the repository creation to confirm the legitimacy of the action and gather additional context if necessary. + +### False positive analysis + +- Routine repository creation by development teams can trigger false positives. To manage this, identify and whitelist repositories created by trusted team members or service accounts. +- Automated processes or CI/CD pipelines that create repositories as part of their workflow may be flagged. Exclude these known processes by setting up exceptions based on specific user agents or IP addresses. +- Educational or training sessions where multiple repositories are created for learning purposes can lead to alerts. Temporarily adjust the rule sensitivity or add exceptions during these sessions. +- Open-source project contributions where new repositories are frequently created by contributors can be excluded by verifying contributor identities and adding them to an allowlist. +- Internal hackathons or innovation days often result in a spike in repository creation. Coordinate with event organizers to anticipate these activities and adjust monitoring rules accordingly. + +### Response and remediation + +- Immediately review the newly created GitHub repository to determine if it contains any unauthorized or malicious code. If malicious content is identified, remove the repository to prevent further access or distribution. +- Revoke access for any users or tokens that were involved in the unauthorized creation of the repository to prevent further unauthorized actions. +- Conduct a thorough audit of recent GitHub activity logs to identify any other suspicious actions or patterns that may indicate a broader compromise. +- Notify the security team and relevant stakeholders about the incident, providing details of the repository creation and any identified malicious content for further analysis and response. +- Implement additional monitoring on GitHub activities, focusing on repository creation and access patterns, to detect similar unauthorized actions in the future. +- Review and update GitHub access controls and permissions to ensure that only authorized personnel have the ability to create repositories, reducing the risk of unauthorized actions. +- If the incident is part of a larger attack pattern, escalate to incident response teams for a comprehensive investigation and coordinated response.""" [[rule.threat]] diff --git a/rules_building_block/execution_github_repo_interaction_from_new_ip.toml b/rules_building_block/execution_github_repo_interaction_from_new_ip.toml index 46e625fe8c3..ab65cf80907 100644 --- a/rules_building_block/execution_github_repo_interaction_from_new_ip.toml +++ b/rules_building_block/execution_github_repo_interaction_from_new_ip.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/10/11" integration = ["github"] maturity = "production" -updated_date = "2024/12/10" +updated_date = "2025/01/10" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." @@ -35,6 +35,40 @@ event.dataset:"github.audit" and event.category:"configuration" and github.actor_ip:* and github.repo:* and github.repository_public:false ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 First Occurrence of GitHub Repo Interaction From a New IP + +GitHub repositories are crucial for code collaboration and management. Adversaries may exploit unauthorized access to private repos from unfamiliar IPs to execute malicious code or exfiltrate data. This detection rule identifies new IP interactions with private repos, flagging potential unauthorized access by monitoring IP changes over a 14-day period, thus aiding in early threat detection. + +### Possible investigation steps + +- Review the IP address flagged in the alert to determine if it is associated with known or trusted networks, or if it appears suspicious or unfamiliar. +- Check the GitHub actor associated with the IP address to verify if the user account has a history of legitimate access to the private repository. +- Investigate the specific private repository accessed to assess its sensitivity and the potential impact of unauthorized access. +- Analyze recent activity logs for the flagged IP address to identify any other unusual or unauthorized interactions with GitHub repositories. +- Correlate the event with other security alerts or logs to determine if this IP address has been involved in other suspicious activities across the network. + +### False positive analysis + +- Employees working remotely or traveling may trigger alerts when accessing repositories from new IP addresses. To manage this, maintain a list of known employee IPs and update it regularly to exclude these from triggering false positives. +- Use of VPNs or dynamic IP addresses can result in frequent IP changes. Implement a process to log and recognize these IPs, allowing for exceptions in the detection rule. +- Automated systems or CI/CD pipelines interacting with repositories from cloud environments may use different IPs. Identify and whitelist these systems to prevent unnecessary alerts. +- Collaborators from partner organizations accessing repositories might appear as new IPs. Establish a communication protocol to verify and whitelist these IPs as needed. +- Regularly review and update the list of known safe IPs in the detection system to minimize false positives while ensuring security measures remain effective. + +### Response and remediation + +- Immediately isolate the IP address identified in the alert to prevent further unauthorized access to the private GitHub repository. +- Review the access logs for the specific repository to determine the extent of the interaction and identify any potential data exfiltration or code changes. +- Revoke any access tokens or credentials associated with the suspicious IP address to prevent further unauthorized access. +- Notify the repository owner and relevant security teams about the unauthorized access attempt for further investigation and monitoring. +- Conduct a security review of the affected repository to ensure no malicious code or unauthorized changes have been introduced. +- Implement IP whitelisting or geofencing for accessing private repositories to limit access to known and trusted IP addresses. +- Enhance monitoring and alerting for similar unauthorized access attempts by integrating additional threat intelligence and anomaly detection capabilities.""" [[rule.threat]] diff --git a/rules_building_block/execution_linux_segfault.toml b/rules_building_block/execution_linux_segfault.toml index e1d006ca679..8109eb86a08 100644 --- a/rules_building_block/execution_linux_segfault.toml +++ b/rules_building_block/execution_linux_segfault.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/10/26" integration = ["system"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -53,6 +53,40 @@ type = "query" query = ''' host.os.type:linux and event.dataset:"system.syslog" and process.name:kernel and message:segfault ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Segfault Detected + +Segmentation faults occur when a program accesses restricted memory, often causing it to crash. While typically indicative of programming errors, adversaries can exploit these faults to execute unauthorized code, leveraging vulnerabilities like buffer overflows. The 'Segfault Detected' rule monitors Linux kernel logs for such faults, flagging potential exploitation attempts by correlating specific syslog events and process activities. + +### Possible investigation steps + +- Review the syslog entries around the time of the segfault event to gather additional context and identify any preceding or subsequent suspicious activities. +- Investigate the process that triggered the segfault by examining its command line arguments, parent process, and any associated files or network connections to determine if it was part of a legitimate operation or a potential attack. +- Check for any recent changes or updates to the system or software that might have introduced vulnerabilities or instability leading to the segfault. +- Correlate the segfault event with other security alerts or logs to identify patterns or indicators of compromise that might suggest a broader attack campaign. +- Assess the system for signs of exploitation, such as unexpected changes in file permissions, unauthorized user accounts, or unusual outbound network traffic, which could indicate successful code execution following the segfault. + +### False positive analysis + +- Kernel module crashes can generate segfault messages without indicating malicious activity. Review the specific module involved and consider excluding it if it is known to be unstable but non-threatening. +- Debugging activities by developers may intentionally cause segfaults to test error handling. Coordinate with development teams to identify and exclude these events during known testing periods. +- Certain legitimate applications may occasionally cause segfaults due to bugs or compatibility issues. Monitor these applications and, if they are verified as non-malicious, create exceptions for their segfault events. +- System updates or patches might temporarily cause segfaults as software adjusts to new configurations. Track update schedules and exclude related segfaults if they align with these periods. +- Custom scripts or automation tools that interact with system processes might inadvertently trigger segfaults. Validate these scripts and exclude their segfaults if they are part of routine operations. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent potential lateral movement or further exploitation. +- Conduct a memory dump and forensic analysis of the affected system to identify any unauthorized code execution or modifications. +- Review and update the system's software and libraries to patch any known vulnerabilities that could be exploited by buffer overflow attacks. +- Implement application whitelisting to restrict the execution of unauthorized or suspicious processes. +- Monitor for any additional segfault messages in the kernel logs across other systems to identify potential widespread exploitation attempts. +- Escalate the incident to the security operations center (SOC) for further investigation and to determine if the attack is part of a larger campaign. +- Enhance logging and alerting mechanisms to detect similar segmentation faults and potential exploitation attempts in the future.""" [[rule.threat]] diff --git a/rules_building_block/execution_settingcontent_ms_file_creation.toml b/rules_building_block/execution_settingcontent_ms_file_creation.toml index e359ebfef9c..ae63fa296f2 100644 --- a/rules_building_block/execution_settingcontent_ms_file_creation.toml +++ b/rules_building_block/execution_settingcontent_ms_file_creation.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/08/24" integration = ["endpoint", "windows"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -44,6 +44,40 @@ file where host.os.type == "windows" and event.type == "creation" and "\\Device\\HarddiskVolume*\\Windows\\WinSxS\\amd64_microsoft-windows-s..*\\*.settingcontent-ms" ) ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Creation of SettingContent-ms Files + +SettingContent-ms files are XML-based shortcuts used in Windows to link to specific settings pages. Adversaries exploit these files to execute malicious code by embedding harmful scripts, bypassing traditional security measures. The detection rule identifies unusual creation of these files outside typical directories, flagging potential threats by monitoring file creation events and filtering out known legitimate paths. + +### Possible investigation steps + +- Review the file creation event details to identify the specific path where the SettingContent-ms file was created, ensuring it is outside the known legitimate directories. +- Investigate the user account associated with the file creation event to determine if the activity aligns with their typical behavior or if it appears suspicious. +- Examine recent processes executed on the host around the time of the file creation to identify any potentially malicious activity or scripts that may have triggered the event. +- Check for any network connections or external communications from the host that could indicate data exfiltration or command and control activity. +- Look for other related alerts or events on the same host or user account to identify patterns or additional indicators of compromise. +- Assess the risk and impact of the event by considering the host's role within the organization and any sensitive data it may access. + +### False positive analysis + +- Legitimate software installations or updates may create SettingContent-ms files in non-standard directories. Monitor software installation logs to correlate these events and consider excluding these paths if they are consistently benign. +- Custom scripts or administrative tools used by IT departments might generate these files during configuration tasks. Verify the source of these scripts and, if deemed safe, add exceptions for these specific operations. +- User-initiated actions, such as creating shortcuts to settings for convenience, can trigger false positives. Educate users on the implications and review these actions to determine if they should be excluded. +- Automated system maintenance tasks or third-party management tools might create these files as part of their operations. Identify these tools and assess their behavior to decide on necessary exclusions. + +### 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 associated with the SettingContent-ms file creation to halt any ongoing malicious activity. +- Conduct a thorough scan of the affected system using updated antivirus or endpoint detection and response (EDR) tools to identify and remove any malicious files or scripts. +- Review and restore any altered system settings or configurations to their default or secure state to ensure system integrity. +- Collect and preserve relevant logs and artifacts for further analysis and to support potential forensic investigations. +- Escalate the incident to the security operations center (SOC) or incident response team for a deeper investigation and to determine the scope and impact of the threat. +- Implement additional monitoring and alerting for unusual SettingContent-ms file creation activities to enhance detection and prevent recurrence of similar threats.""" [[rule.threat]] diff --git a/rules_building_block/execution_unsigned_service_executable.toml b/rules_building_block/execution_unsigned_service_executable.toml index e6c2b4816cc..bf75bd637b2 100644 --- a/rules_building_block/execution_unsigned_service_executable.toml +++ b/rules_building_block/execution_unsigned_service_executable.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/07/14" integration = ["endpoint"] maturity = "production" -updated_date = "2024/05/21" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -38,6 +38,41 @@ process.parent.executable:"C:\\Windows\\System32\\services.exe" and (process.code_signature.exists:false or process.code_signature.trusted:false) and not process.code_signature.status : (errorCode_endpoint* or "errorChaining") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Execution of an Unsigned Service + +The Service Control Manager (SCM) in Windows is crucial for managing system services. Adversaries may exploit SCM to run unsigned executables, potentially deploying malware or gaining elevated privileges. The detection rule identifies such activities by monitoring processes initiated by SCM, specifically those lacking valid code signatures, thus flagging potential threats for further investigation. + +### Possible investigation steps + +- Review the process details, including the executable path and name, to determine if the unsigned executable is expected or known within the environment. +- Check the parent process, C:\\Windows\\System32\\services.exe, to confirm it is legitimate and not tampered with, as it is the parent process initiating the unsigned executable. +- Investigate the origin of the unsigned executable by examining file creation and modification timestamps, and cross-reference with recent changes or deployments in the system. +- Analyze the process execution context, such as user account and privileges, to assess if there is any indication of privilege escalation or unauthorized access. +- Correlate the event with other security alerts or logs to identify any related suspicious activities or patterns, such as network connections or file modifications, that might indicate malicious behavior. +- Consult threat intelligence sources to determine if the unsigned executable or its hash is associated with known malware or threat actors. + +### False positive analysis + +- Legitimate software updates or installations may trigger the rule if they involve unsigned executables. Users can create exceptions for known update processes by verifying the source and adding them to an allowlist. +- Custom in-house applications that are unsigned might be flagged. Ensure these applications are verified and trusted, then exclude them from the rule by specifying their executable paths. +- Some third-party software, especially older or niche applications, may not have valid code signatures. Confirm the legitimacy of these applications and consider excluding them if they are essential and trusted. +- Development or testing environments often run unsigned executables. To prevent unnecessary alerts, consider excluding these environments from the rule or creating specific exceptions for known development processes. +- Temporary or transitional software deployments might lack signatures. If these are part of a controlled process, document and exclude them during the deployment phase. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further spread of potential malware or unauthorized access. +- Terminate the suspicious unsigned service process identified by the alert to halt any malicious activity. +- Conduct a thorough scan of the affected system using updated antivirus and anti-malware tools to identify and remove any malicious files or software. +- Review and analyze recent changes to system services and scheduled tasks to identify unauthorized modifications or additions. +- Restore the system from a known good backup if malicious activity is confirmed and cannot be fully remediated through cleaning. +- Escalate the incident to the security operations team for further investigation and to determine if additional systems are affected. +- Implement stricter application whitelisting policies to prevent the execution of unsigned or untrusted executables in the future.""" [[rule.threat]] diff --git a/rules_building_block/execution_wmi_wbemtest.toml b/rules_building_block/execution_wmi_wbemtest.toml index 7e05911003e..db8c02b2ca8 100644 --- a/rules_building_block/execution_wmi_wbemtest.toml +++ b/rules_building_block/execution_wmi_wbemtest.toml @@ -2,7 +2,7 @@ creation_date = "2023/08/24" integration = ["endpoint", "windows", "system"] maturity = "production" -updated_date = "2024/10/28" +updated_date = "2025/01/10" min_stack_version = "8.14.0" min_stack_comments = "Breaking change at 8.14.0 for the Windows Integration." @@ -44,6 +44,41 @@ type = "eql" query = ''' process where host.os.type == "windows" and event.type == "start" and process.name : "wbemtest.exe" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 WMI WBEMTEST Utility Execution + +Windows Management Instrumentation (WMI) is a powerful framework for managing data and operations on Windows systems. The WBEMTEST utility is a diagnostic tool that allows users to interact with WMI, often used for legitimate administrative tasks. However, adversaries can exploit it to execute commands or gather information stealthily. The detection rule identifies instances of WBEMTEST execution, flagging potential misuse by monitoring process initiation events on Windows systems. + +### Possible investigation steps + +- Review the process start event details to confirm the execution of wbemtest.exe, focusing on the process name and event type fields. +- Identify the user account associated with the wbemtest.exe process initiation to determine if the execution aligns with expected administrative activity. +- Examine the parent process of wbemtest.exe to understand how it was launched and assess if it was initiated by a legitimate application or script. +- Check for any network connections or remote interactions initiated by wbemtest.exe to identify potential unauthorized access to remote endpoints. +- Investigate the historical activity of the user and host involved to identify any patterns of suspicious behavior or previous alerts related to WMI usage. +- Correlate this event with other security alerts or logs from the same host or user to determine if this is part of a broader attack pattern. + +### False positive analysis + +- Administrative tasks using wbemtest.exe can trigger alerts. Regularly review and document legitimate administrative activities to differentiate them from potential threats. +- Scheduled maintenance scripts or automated processes that utilize wbemtest.exe may cause false positives. Identify and whitelist these processes to prevent unnecessary alerts. +- Software installations or updates that interact with WMI might execute wbemtest.exe. Monitor and log these events to establish a baseline of expected behavior. +- Developers or IT staff using wbemtest.exe for troubleshooting or development purposes can be mistaken for adversarial activity. Implement user-based exceptions for known personnel conducting these tasks. +- Security tools or monitoring solutions that leverage WMI for data collection might inadvertently execute wbemtest.exe. Coordinate with security teams to ensure these activities are recognized and excluded from alerts. + +### Response and remediation + +- Immediately isolate the affected system from the network to prevent further unauthorized access or data exfiltration. +- Terminate the wbemtest.exe process if it is confirmed to be running without legitimate administrative purpose. +- Conduct a thorough review of recent WMI activity on the affected system to identify any unauthorized or suspicious actions performed using WMI. +- Reset credentials for any accounts that were used to execute wbemtest.exe, especially if they have administrative privileges, to prevent further misuse. +- Implement host-based firewall rules to restrict WMI access to only trusted IP addresses and systems, reducing the risk of remote exploitation. +- Escalate the incident to the security operations center (SOC) or incident response team for further investigation and to determine if additional systems are affected. +- Update and enhance monitoring rules to detect similar WMI misuse attempts, ensuring that alerts are generated for any unauthorized execution of wbemtest.exe in the future.""" [[rule.threat]] diff --git a/rules_building_block/impact_github_member_removed_from_organization.toml b/rules_building_block/impact_github_member_removed_from_organization.toml index 7153494eaa4..79e18cd5003 100644 --- a/rules_building_block/impact_github_member_removed_from_organization.toml +++ b/rules_building_block/impact_github_member_removed_from_organization.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/10/11" integration = ["github"] maturity = "production" -updated_date = "2024/12/10" +updated_date = "2025/01/10" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." @@ -33,6 +33,39 @@ type = "eql" query = ''' configuration where event.dataset == "github.audit" and event.action == "org.remove_member" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Member Removed From GitHub Organization + +GitHub Organizations manage collaborative access to repositories, where members can be added or removed. Adversaries might exploit this by removing legitimate members to disrupt operations or conceal malicious activities. The detection rule monitors audit logs for member removal actions, flagging potential unauthorized access removal, aligning with MITRE ATT&CK's impact tactics, ensuring timely threat detection and response. + +### Possible investigation steps + +- Review the GitHub audit logs to confirm the event dataset is "github.audit" and the action is "org.remove_member" to ensure the alert is based on the correct event. +- Identify the user who was removed from the organization and determine their role and access level to assess the potential impact of their removal. +- Investigate the user account that performed the removal action to verify if it was authorized and check for any unusual activity or anomalies associated with this account. +- Check the organization's recent activity logs for any other suspicious actions or changes that might indicate a broader security incident. +- Contact the removed member or relevant team leads to confirm whether the removal was expected or authorized, and gather any additional context or concerns they might have. + +### False positive analysis + +- Routine member management activities can trigger alerts when legitimate members are removed as part of regular organizational changes. To mitigate this, establish a baseline of expected member removal activities and create exceptions for these patterns. +- Temporary project members or contractors may be removed after project completion, leading to false positives. Implement a process to document and exclude these expected removals from triggering alerts. +- Automated scripts or integrations that manage user access might inadvertently remove members, causing false positives. Review and adjust the scripts to ensure they align with organizational policies and exclude these actions from monitoring. +- Organizational restructuring or mergers can result in bulk member removals, which may be flagged as suspicious. Coordinate with HR or management teams to anticipate these changes and temporarily adjust detection thresholds or rules. + +### Response and remediation + +- Immediately verify the legitimacy of the member removal by contacting the organization owner or admin to confirm if the action was authorized. +- If unauthorized, promptly re-add the removed member to the organization to restore their access and minimize disruption. +- Conduct a review of recent audit logs to identify any other suspicious activities or unauthorized changes within the organization. +- Temporarily restrict access to critical repositories and resources until the source of the unauthorized removal is identified and mitigated. +- Escalate the incident to the security team for further investigation and to assess potential impacts on the organization’s operations and data integrity. +- Implement additional access controls, such as multi-factor authentication, to prevent unauthorized access and account manipulation in the future. +- Update and reinforce incident response procedures to ensure rapid detection and response to similar threats in the future.""" [[rule.threat]] diff --git a/rules_building_block/impact_github_pat_access_revoked.toml b/rules_building_block/impact_github_pat_access_revoked.toml index 4dd48492420..d24ec95104c 100644 --- a/rules_building_block/impact_github_pat_access_revoked.toml +++ b/rules_building_block/impact_github_pat_access_revoked.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/10/11" integration = ["github"] maturity = "production" -updated_date = "2024/12/10" +updated_date = "2025/01/10" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." @@ -33,6 +33,39 @@ type = "eql" query = ''' configuration where event.dataset == "github.audit" and event.action == "personal_access_token.access_revoked" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GitHub PAT Access Revoked + +GitHub Personal Access Tokens (PATs) are used to authenticate API requests without a password, granting access to private resources. Adversaries may exploit compromised PATs to access sensitive data or disrupt operations. The detection rule monitors audit logs for revoked PAT access, indicating potential unauthorized use or security policy enforcement, helping to identify and mitigate such threats. + +### Possible investigation steps + +- Review the audit logs for the specific event where event.dataset is "github.audit" and event.action is "personal_access_token.access_revoked" to identify the user or system associated with the revoked PAT. +- Determine the scope of access that the revoked PAT had by reviewing the permissions and resources it was authorized to access. +- Investigate the reason for the PAT revocation by checking for any related security alerts or policy enforcement actions that might have triggered the revocation. +- Contact the user or team associated with the revoked PAT to verify if the revocation was expected or if there are any indications of unauthorized access or compromise. +- Assess the potential impact on operations or data security due to the revocation and determine if any further actions, such as additional access reviews or security measures, are necessary. + +### False positive analysis + +- Routine administrative actions such as regular audits or security policy updates may trigger PAT access revocations. To manage these, create exceptions for known administrative accounts or scheduled maintenance periods. +- Automated scripts or tools that rotate PATs for security reasons might cause frequent revocations. Identify these scripts and exclude their actions from triggering alerts by whitelisting their associated accounts or tokens. +- User-initiated PAT revocations for personal security hygiene can appear as false positives. Encourage users to document such actions and maintain a list of user-initiated revocations to cross-reference with alerts. +- Organizational policy changes that enforce stricter PAT usage guidelines may lead to mass revocations. Coordinate with policy enforcement teams to anticipate these changes and temporarily adjust detection thresholds or rules. + +### Response and remediation + +- Immediately revoke any remaining access for the compromised PAT to prevent further unauthorized access to private resources. +- Notify the affected user and relevant security teams about the incident to ensure awareness and initiate further investigation if needed. +- Conduct a review of recent activities associated with the compromised PAT to identify any unauthorized actions or data access. +- Reset credentials and generate a new PAT for the affected user, ensuring it follows best practices for security and access control. +- Implement additional monitoring for unusual activities related to the affected user's account to detect any further suspicious behavior. +- Escalate the incident to higher-level security management if sensitive data was accessed or if the breach impacts critical operations. +- Review and update access policies and token management practices to prevent similar incidents, ensuring that PATs are regularly rotated and have the least privilege necessary.""" [[rule.threat]] diff --git a/rules_building_block/impact_github_user_blocked_from_organization.toml b/rules_building_block/impact_github_user_blocked_from_organization.toml index 60fb77cb60d..66d1124f9c2 100644 --- a/rules_building_block/impact_github_user_blocked_from_organization.toml +++ b/rules_building_block/impact_github_user_blocked_from_organization.toml @@ -3,7 +3,7 @@ bypass_bbr_timing = true creation_date = "2023/10/11" integration = ["github"] maturity = "production" -updated_date = "2024/12/10" +updated_date = "2025/01/10" min_stack_version = "8.13.0" min_stack_comments = "Breaking change at 8.13.0 for the Github Integration." @@ -33,6 +33,40 @@ type = "eql" query = ''' configuration where event.dataset == "github.audit" and event.action == "org.block_user" ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 GitHub User Blocked From Organization + +GitHub is a platform for version control and collaboration, crucial for software development. Organizations use it to manage access to their repositories. Blocking a user can be a legitimate action to revoke access, but adversaries might exploit this to disrupt operations or remove access stealthily. The detection rule monitors audit logs for user blocks, identifying potential misuse by correlating specific actions with threat tactics, ensuring timely alerts for security teams. + +### Possible investigation steps + +- Review the audit logs for the specific event where event.dataset is "github.audit" and event.action is "org.block_user" to identify the user who was blocked and the timestamp of the action. +- Verify the identity and role of the blocked user within the organization to assess the potential impact of their access removal. +- Check for any recent changes or unusual activities in the repositories or organization settings that the blocked user had access to, which might indicate malicious intent or misuse. +- Investigate the user who performed the block action to ensure it was authorized and aligns with organizational policies. +- Look for any correlated events or alerts around the same timeframe that might suggest a coordinated attempt to disrupt operations or remove access stealthily. +- Communicate with the organization’s admin or security team to confirm whether the block was intentional and part of a legitimate security measure. + +### False positive analysis + +- Routine administrative actions may trigger alerts when an organization intentionally blocks users for maintenance or restructuring. To manage this, create exceptions for known administrative accounts performing these actions. +- Temporary access revocations for contractors or third-party collaborators can appear as user blocks. Implement a process to log and verify these temporary blocks to distinguish them from potential threats. +- Automated scripts or bots used for managing user access might inadvertently block users during updates or error handling. Ensure these scripts are well-documented and monitored, and consider excluding their actions from alerts if they are verified as non-threatening. +- High turnover in organizations can lead to frequent user blocks as part of offboarding processes. Establish a baseline for expected user block frequency and adjust alert thresholds accordingly to reduce noise from legitimate offboarding activities. + +### Response and remediation + +- Verify the legitimacy of the block by contacting the organization owner or admin to confirm whether the action was intentional or unauthorized. +- If the block was unauthorized, immediately unblock the user and restore their access to the necessary repositories, ensuring no critical work is disrupted. +- Conduct a review of recent audit logs to identify any other suspicious activities or unauthorized access attempts that may indicate a broader security issue. +- Implement additional access controls or two-factor authentication for organization admins to prevent unauthorized actions in the future. +- Notify the affected user about the incident, advising them to review their account security settings and change their password if necessary. +- Escalate the incident to the security team for further investigation and to assess whether additional security measures are required to protect the organization. +- Document the incident, including actions taken and lessons learned, to improve response strategies and prevent similar occurrences.""" [[rule.threat]] diff --git a/rules_building_block/initial_access_cross_site_scripting.toml b/rules_building_block/initial_access_cross_site_scripting.toml index 0ed9fe480fb..b487efe3dab 100644 --- a/rules_building_block/initial_access_cross_site_scripting.toml +++ b/rules_building_block/initial_access_cross_site_scripting.toml @@ -2,7 +2,7 @@ creation_date = "2023/07/12" integration = ["apm"] maturity = "production" -updated_date = "2024/09/01" +updated_date = "2025/01/10" [rule] author = ["Elastic"] @@ -31,6 +31,41 @@ any where processor.name == "transaction" and url.fragment : ("", "", "*onerror=*", "*javascript*alert*", "*eval*(*)*", "*onclick=*", "*alert(document.cookie)*", "*alert(document.domain)*","*onresize=*","*onload=*","*onmouseover=*") ''' +note = """## Triage and analysis + +> **Disclaimer**: +> This investigation guide was generated 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 Cross Site Scripting (XSS) + +Cross-Site Scripting (XSS) exploits vulnerabilities in web applications by injecting malicious scripts into trusted sites, often targeting users' browsers. Adversaries leverage this to execute scripts that can steal cookies, session tokens, or other sensitive data. The detection rule identifies suspicious script patterns in web transactions, such as `