Suspicious Kernel Feature Activity
This rule detects the modification and reading of kernel features through built-in commands. Attackers may collect information, disable or weaken Linux kernel protections. For example, an attacker may modify ASLR protection by disabling kernel.randomize_va_space, allow ptrace by setting kernel.yama.ptrace_scope to 0, or disable the NMI watchdog by setting kernel.nmi_watchdog to 0. These changes may be used to impair defenses and evade detection.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2025/04/29"
3integration = ["endpoint", "crowdstrike"]
4maturity = "production"
5updated_date = "2025/10/17"
6
7[rule]
8author = ["Elastic"]
9description = """
10This rule detects the modification and reading of kernel features through built-in commands. Attackers may collect
11information, disable or weaken Linux kernel protections. For example, an attacker may modify ASLR protection by
12disabling kernel.randomize_va_space, allow ptrace by setting kernel.yama.ptrace_scope to 0, or disable the
13NMI watchdog by setting kernel.nmi_watchdog to 0. These changes may be used to impair defenses and evade detection.
14"""
15from = "now-9m"
16index = [
17 "logs-endpoint.events.process*",
18 "logs-crowdstrike.fdr*",
19]
20language = "eql"
21license = "Elastic License v2"
22name = "Suspicious Kernel Feature Activity"
23note = """ ## Triage and analysis
24
25> **Disclaimer**:
26> 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.
27
28### Investigating Suspicious Kernel Feature Activity
29
30Kernel features in Linux systems are critical for maintaining security and stability. They control various system behaviors, such as memory randomization and process tracing. Adversaries may exploit these features to weaken defenses, for instance, by disabling address space layout randomization (ASLR) or enabling unrestricted process tracing. The detection rule identifies suspicious activities by monitoring command executions that modify or read kernel settings, focusing on unusual patterns or contexts that suggest malicious intent.
31
32### Possible investigation steps
33
34- Review the process command line to identify which specific kernel feature was accessed or modified, focusing on entries like kernel.randomize_va_space or kernel.yama.ptrace_scope.
35- Examine the parent process executable and name to determine the context in which the suspicious command was executed, checking for unusual or unauthorized parent processes.
36- Investigate the user account associated with the process execution to assess whether the activity aligns with expected behavior for that user.
37- Check for any recent changes in the /etc/sysctl.conf or /etc/sysctl.d/ directories that might indicate unauthorized modifications to kernel settings.
38- Analyze the system's process execution history to identify any patterns or sequences of commands that suggest a broader attack or compromise.
39- Correlate the alert with other security events or logs to determine if this activity is part of a larger attack campaign or isolated incident.
40
41### False positive analysis
42
43- System administrators or automated scripts may frequently modify kernel settings for legitimate purposes such as performance tuning or system maintenance. To handle these, identify and whitelist known administrative scripts or processes that regularly perform these actions.
44- Security tools or monitoring solutions might execute commands that read kernel settings as part of their normal operation. Review and exclude these tools from triggering alerts by adding them to an exception list based on their process names or command patterns.
45- Developers and testers might disable certain kernel features temporarily during debugging or testing phases. Coordinate with development teams to document these activities and exclude them from detection by specifying the relevant process names or command lines.
46- Some system management tools may use commands like sysctl to apply configuration changes across multiple systems. If these tools are verified as non-threatening, exclude their specific command patterns or parent processes from triggering the rule.
47- Regular system updates or configuration management processes might involve reading or modifying kernel settings. Identify these processes and add them to an exception list to prevent unnecessary alerts.
48
49### Response and remediation
50
51- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
52- Review and revert any unauthorized changes to kernel settings, such as ASLR, ptrace scope, or NMI watchdog, to their secure defaults using sysctl or by editing configuration files.
53- Conduct a thorough examination of the system for signs of compromise, including checking for unauthorized access, unusual processes, or modifications to critical files.
54- Restore the system from a known good backup if the integrity of the system is compromised and cannot be reliably remediated.
55- Implement additional monitoring and logging for kernel feature modifications to detect similar activities in the future, ensuring alerts are configured for immediate response.
56- Escalate the incident to the security operations center (SOC) or relevant security team for further investigation and correlation with other potential threats across the network.
57- Review and update security policies and configurations to prevent unauthorized kernel modifications, including enforcing stricter access controls and auditing procedures.
58"""
59risk_score = 21
60rule_id = "3aff6ab1-18bd-427e-9d4c-c5732110c261"
61severity = "low"
62tags = [
63 "Domain: Endpoint",
64 "OS: Linux",
65 "Use Case: Threat Detection",
66 "Tactic: Defense Evasion",
67 "Tactic: Discovery",
68 "Data Source: Elastic Defend",
69 "Resources: Investigation Guide",
70 "Data Source: Crowdstrike",
71]
72timestamp_override = "event.ingested"
73type = "eql"
74query = '''
75process where host.os.type == "linux" and event.type == "start" and event.action in ("exec", "ProcessRollup2") and
76process.command_line : (
77 "*/etc/sysctl.conf*", "*/etc/sysctl.d/*", "*/proc/sys/kernel/nmi_watchdog*",
78 "*/proc/sys/vm/nr_hugepages*", "*/proc/sys/kernel/yama/ptrace_scope*",
79 "*/proc/sys/kernel/randomize_va_space*", "*/proc/sys/vm/drop_caches*",
80 "*/proc/sys/kernel/sysrq*", "*grsecurity*", "*exec-shield*",
81 "*kernel.randomize_va_space*", "*kernel.yama.ptrace_scope*",
82 "*kernel.nmi_watchdog*", "*vm.nr_hugepages*", "*vm.drop_caches*",
83 "*kernel.sysrq*"
84) and
85?process.parent.executable != null and
86(
87 (process.name == "tee" and process.args like "-*a*") or // also detects --append
88 (process.name == "cat" and not process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")) or
89 (process.name == "grep" and process.args_count == 3 and not process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")) or
90 (process.name == "sysctl" and process.args like ("*-w*", "*--write*", "*=*")) or
91 (process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and process.args : "*echo *")
92)
93'''
94
95[[rule.threat]]
96framework = "MITRE ATT&CK"
97
98[rule.threat.tactic]
99name = "Defense Evasion"
100id = "TA0005"
101reference = "https://attack.mitre.org/tactics/TA0005/"
102
103[[rule.threat.technique]]
104name = "Impair Defenses"
105id = "T1562"
106reference = "https://attack.mitre.org/techniques/T1562/"
107
108[[rule.threat.technique.subtechnique]]
109name = "Indicator Blocking"
110id = "T1562.006"
111reference = "https://attack.mitre.org/techniques/T1562/006/"
112
113[[rule.threat.technique]]
114name = "Subvert Trust Controls"
115id = "T1553"
116reference = "https://attack.mitre.org/techniques/T1553/"
117
118[[rule.threat]]
119framework = "MITRE ATT&CK"
120
121[[rule.threat.technique]]
122id = "T1082"
123name = "System Information Discovery"
124reference = "https://attack.mitre.org/techniques/T1082/"
125
126[rule.threat.tactic]
127id = "TA0007"
128name = "Discovery"
129reference = "https://attack.mitre.org/tactics/TA0007/"
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 Suspicious Kernel Feature Activity
Kernel features in Linux systems are critical for maintaining security and stability. They control various system behaviors, such as memory randomization and process tracing. Adversaries may exploit these features to weaken defenses, for instance, by disabling address space layout randomization (ASLR) or enabling unrestricted process tracing. The detection rule identifies suspicious activities by monitoring command executions that modify or read kernel settings, focusing on unusual patterns or contexts that suggest malicious intent.
Possible investigation steps
- Review the process command line to identify which specific kernel feature was accessed or modified, focusing on entries like kernel.randomize_va_space or kernel.yama.ptrace_scope.
- Examine the parent process executable and name to determine the context in which the suspicious command was executed, checking for unusual or unauthorized parent processes.
- Investigate the user account associated with the process execution to assess whether the activity aligns with expected behavior for that user.
- Check for any recent changes in the /etc/sysctl.conf or /etc/sysctl.d/ directories that might indicate unauthorized modifications to kernel settings.
- Analyze the system's process execution history to identify any patterns or sequences of commands that suggest a broader attack or compromise.
- Correlate the alert with other security events or logs to determine if this activity is part of a larger attack campaign or isolated incident.
False positive analysis
- System administrators or automated scripts may frequently modify kernel settings for legitimate purposes such as performance tuning or system maintenance. To handle these, identify and whitelist known administrative scripts or processes that regularly perform these actions.
- Security tools or monitoring solutions might execute commands that read kernel settings as part of their normal operation. Review and exclude these tools from triggering alerts by adding them to an exception list based on their process names or command patterns.
- Developers and testers might disable certain kernel features temporarily during debugging or testing phases. Coordinate with development teams to document these activities and exclude them from detection by specifying the relevant process names or command lines.
- Some system management tools may use commands like sysctl to apply configuration changes across multiple systems. If these tools are verified as non-threatening, exclude their specific command patterns or parent processes from triggering the rule.
- Regular system updates or configuration management processes might involve reading or modifying kernel settings. Identify these processes 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 exploitation or lateral movement by the adversary.
- Review and revert any unauthorized changes to kernel settings, such as ASLR, ptrace scope, or NMI watchdog, to their secure defaults using sysctl or by editing configuration files.
- Conduct a thorough examination of the system for signs of compromise, including checking for unauthorized access, unusual processes, or modifications to critical files.
- Restore the system from a known good backup if the integrity of the system is compromised and cannot be reliably remediated.
- Implement additional monitoring and logging for kernel feature modifications to detect similar activities in the future, ensuring alerts are configured for immediate response.
- Escalate the incident to the security operations center (SOC) or relevant security team for further investigation and correlation with other potential threats across the network.
- Review and update security policies and configurations to prevent unauthorized kernel modifications, including enforcing stricter access controls and auditing procedures.
Related rules
- Base64 Decoded Payload Piped to Interpreter
- Git Hook Command Execution
- GitHub Authentication Token Access via Node.js
- Kubectl Permission Discovery
- Node.js Pre or Post-Install Script Execution