security-tools/sigma-rules
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Prep 8.19/9.1 (#4869)

Browse Source 
* Prep 8.19/9.1 Release

* Download Beats Schema

* Download API Schema

* Download 8.18.3 Beats Schema

* Download Latest Integrations manifest and schema

* Comment old schemas

* Update Patch version
This commit is contained in:
shashank-elastic
2025-07-07 20:57:48 +05:30
committed by GitHub
parent 782605ae07
commit 9b292b97ea
189 changed files with 10651 additions and 2888 deletions
Download Patch File Download Diff File Expand all files Collapse all files
rules/linux/defense_evasion_selinux_configuration_creation_or_renaming.toml
+45 -44
View File
@@ -2,22 +2,56 @@
creation_date = "2024/08/28"
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/24"
updated_date = "2025/07/02"
[rule]
author = ["Elastic"]
description = """
This rule detects the creation or renaming of the SELinux configuration file. SELinux is a security module that
provides access control security policies. Modifications to the SELinux configuration file may indicate an attempt to
impair defenses by disabling or modifying security tools.
This rule detects the creation or renaming of the SELinux configuration file. SELinux is a security module that provides
access control security policies. Modifications to the SELinux configuration file may indicate an attempt to impair
defenses by disabling or modifying security tools.
"""
from = "now-9m"
index = ["logs-endpoint.events.file*", "endgame-*", "logs-sentinel_one_cloud_funnel.*"]
language = "eql"
license = "Elastic License v2"
name = "SELinux Configuration Creation or Renaming"
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating 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."""
risk_score = 21
rule_id = "7b981906-86b7-4544-8033-c30ec6eb45fc"
setup = """## Setup
@@ -55,65 +89,32 @@ tags = [
"Data Source: Elastic Endgame",
"Data Source: Elastic Defend",
"Data Source: SentinelOne",
"Resources: Investigation Guide"
"Resources: Investigation Guide",
]
timestamp_override = "event.ingested"
type = "eql"
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" and not process.name in ("dockerd", "platform-python")
'''
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating 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"
[[rule.threat.technique]]
id = "T1562"
name = "Impair Defenses"
reference = "https://attack.mitre.org/techniques/T1562/"
[[rule.threat.technique.subtechnique]]
id = "T1562.001"
name = "Disable or Modify Tools"
reference = "https://attack.mitre.org/techniques/T1562/001/"
[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
rules/linux/defense_evasion_var_log_file_creation_by_unsual_process.toml
+17 -18
View File
@@ -2,16 +2,14 @@
creation_date = "2025/03/11"
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/04/07"
updated_date = "2025/07/02"
[rule]
author = ["Elastic"]
description = """
This rule detects the creation of files in the /var/log/ directory via process executables located in
world-writeable locations or via hidden processes. Attackers may attempt to hide their activities by
creating files in the /var/log/ directory, which is commonly used for logging system events.
This rule detects the creation of files in the /var/log/ directory via process executables located in world-writeable
locations or via hidden processes. Attackers may attempt to hide their activities by creating files in the /var/log/
directory, which is commonly used for logging system events.
"""
from = "now-9m"
index = ["logs-endpoint.events.file*", "logs-sentinel_one_cloud_funnel.*", "endgame-*"]
@@ -95,48 +93,48 @@ tags = [
]
timestamp_override = "event.ingested"
type = "new_terms"
query = '''
event.category:file and host.os.type:linux and event.action:(creation or file_create_event or file_rename_event or rename) and
(process.executable:(/tmp/* or /var/tmp/* or /dev/shm/* or ./* or /boot/*) or process.name:.*) and
file.path:/var/log/* and not file.extension:*
'''
[[rule.threat]]
framework = "MITRE ATT&CK"
[[rule.threat.technique]]
id = "T1564"
name = "Hide Artifacts"
reference = "https://attack.mitre.org/techniques/T1564/"
[[rule.threat.technique.subtechnique]]
id = "T1564.001"
name = "Hidden Files and Directories"
reference = "https://attack.mitre.org/techniques/T1564/001/"
[rule.threat.tactic]
id = "TA0005"
name = "Defense Evasion"
reference = "https://attack.mitre.org/tactics/TA0005/"
[[rule.threat]]
framework = "MITRE ATT&CK"
[rule.threat.tactic]
name = "Execution"
id = "TA0002"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[rule.threat.technique]]
id = "T1059"
name = "Command and Scripting Interpreter"
reference = "https://attack.mitre.org/techniques/T1059/"
[[rule.threat.technique.subtechnique]]
name = "Unix Shell"
id = "T1059.004"
name = "Unix Shell"
reference = "https://attack.mitre.org/techniques/T1059/004/"
[rule.threat.tactic]
id = "TA0002"
name = "Execution"
reference = "https://attack.mitre.org/tactics/TA0002/"
[[rule.threat]]
framework = "MITRE ATT&CK"
@@ -148,7 +146,8 @@ reference = "https://attack.mitre.org/tactics/TA0003/"
[rule.new_terms]
field = "new_terms_fields"
value = ["file.path", "process.executable"]
[[rule.new_terms.history_window_start]]
field = "history_window_start"
value = "now-10d"
rules/linux/privilege_escalation_potential_suid_sgid_exploitation.toml
+40 -40
View File
@@ -2,9 +2,7 @@
creation_date = "2024/06/17"
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 = "2025/02/04"
updated_date = "2025/07/02"
[rule]
author = ["Elastic"]
@@ -19,6 +17,41 @@ index = ["logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Privilege Escalation via SUID/SGID"
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating 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."""
references = [
"https://gtfobins.github.io/#+suid",
"https://www.elastic.co/security-labs/primer-on-persistence-mechanisms",
@@ -62,6 +95,7 @@ tags = [
]
timestamp_override = "event.ingested"
type = "eql"
query = '''
process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and (
(process.user.id == "0" and process.real_user.id != "0") or
@@ -96,45 +130,10 @@ 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 created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating 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"
[[rule.threat.technique]]
id = "T1068"
name = "Exploitation for Privilege Escalation"
@@ -144,17 +143,17 @@ reference = "https://attack.mitre.org/techniques/T1068/"
id = "T1548"
name = "Abuse Elevation Control Mechanism"
reference = "https://attack.mitre.org/techniques/T1548/"
[[rule.threat.technique.subtechnique]]
id = "T1548.001"
name = "Setuid and Setgid"
reference = "https://attack.mitre.org/techniques/T1548/001/"
[rule.threat.tactic]
id = "TA0004"
name = "Privilege Escalation"
reference = "https://attack.mitre.org/tactics/TA0004/"
[[rule.threat]]
framework = "MITRE ATT&CK"
@@ -162,3 +161,4 @@ framework = "MITRE ATT&CK"
id = "TA0003"
name = "Persistence"
reference = "https://attack.mitre.org/tactics/TA0003/"
rules/linux/privilege_escalation_sudo_token_via_process_injection.toml
+36 -38
View File
@@ -2,9 +2,7 @@
creation_date = "2023/07/31"
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 = "2025/02/04"
updated_date = "2025/07/02"
[rule]
author = ["Elastic"]
@@ -20,6 +18,41 @@ index = ["logs-endpoint.events.process*"]
language = "eql"
license = "Elastic License v2"
name = "Potential Sudo Token Manipulation via Process Injection"
note = """## Triage and analysis
> **Disclaimer**:
> This investigation guide was created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating Potential 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."""
references = ["https://github.com/nongiach/sudo_inject"]
risk_score = 47
rule_id = "ff9bc8b9-f03b-4283-be58-ee0a16f5a11b"
@@ -66,41 +99,6 @@ 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 created using generative AI technology and has been reviewed to improve its accuracy and relevance. While every effort has been made to ensure its quality, we recommend validating the content and adapting it to suit your specific environment and operational needs.
### Investigating Potential 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]]