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"]
4maturity = "production"
5updated_date = "2025/07/07"
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]
19language = "eql"
20license = "Elastic License v2"
21name = "Suspicious Kernel Feature Activity"
22note = """ ## Triage and analysis
23
24> **Disclaimer**:
25> 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.
26
27### Investigating Suspicious Kernel Feature Activity
28
29Kernel 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.
30
31### Possible investigation steps
32
33- 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.
34- 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.
35- Investigate the user account associated with the process execution to assess whether the activity aligns with expected behavior for that user.
36- Check for any recent changes in the /etc/sysctl.conf or /etc/sysctl.d/ directories that might indicate unauthorized modifications to kernel settings.
37- Analyze the system's process execution history to identify any patterns or sequences of commands that suggest a broader attack or compromise.
38- Correlate the alert with other security events or logs to determine if this activity is part of a larger attack campaign or isolated incident.
39
40### False positive analysis
41
42- 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.
43- 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.
44- 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.
45- 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.
46- 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.
47
48### Response and remediation
49
50- Immediately isolate the affected system from the network to prevent further exploitation or lateral movement by the adversary.
51- 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.
52- Conduct a thorough examination of the system for signs of compromise, including checking for unauthorized access, unusual processes, or modifications to critical files.
53- Restore the system from a known good backup if the integrity of the system is compromised and cannot be reliably remediated.
54- Implement additional monitoring and logging for kernel feature modifications to detect similar activities in the future, ensuring alerts are configured for immediate response.
55- 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.
56- Review and update security policies and configurations to prevent unauthorized kernel modifications, including enforcing stricter access controls and auditing procedures.
57"""
58risk_score = 21
59rule_id = "3aff6ab1-18bd-427e-9d4c-c5732110c261"
60severity = "low"
61tags = [
62 "Domain: Endpoint",
63 "OS: Linux",
64 "Use Case: Threat Detection",
65 "Tactic: Defense Evasion",
66 "Tactic: Discovery",
67 "Data Source: Elastic Defend",
68 "Resources: Investigation Guide",
69]
70timestamp_override = "event.ingested"
71type = "eql"
72query = '''
73process where host.os.type == "linux" and event.type == "start" and event.action == "exec" and
74process.command_line : (
75 "*/etc/sysctl.conf*", "*/etc/sysctl.d/*", "*/proc/sys/kernel/nmi_watchdog*",
76 "*/proc/sys/vm/nr_hugepages*", "*/proc/sys/kernel/yama/ptrace_scope*",
77 "*/proc/sys/kernel/randomize_va_space*", "*/proc/sys/vm/drop_caches*",
78 "*/proc/sys/kernel/sysrq*", "*grsecurity*", "*exec-shield*",
79 "*kernel.randomize_va_space*", "*kernel.yama.ptrace_scope*",
80 "*kernel.nmi_watchdog*", "*vm.nr_hugepages*", "*vm.drop_caches*",
81 "*kernel.sysrq*"
82) and
83process.parent.executable != null and
84(
85 (process.name == "tee" and process.args like "-*a*") or // also detects --append
86 (process.name == "cat" and not process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")) or
87 (process.name == "grep" and process.args_count == 3 and not process.parent.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish")) or
88 (process.name == "sysctl" and process.args like ("*-w*", "*--write*", "*=*")) or
89 (process.name in ("bash", "dash", "sh", "tcsh", "csh", "zsh", "ksh", "fish") and process.args == "-c" and process.args : "*echo *")
90)
91'''
92
93[[rule.threat]]
94framework = "MITRE ATT&CK"
95
96[rule.threat.tactic]
97name = "Defense Evasion"
98id = "TA0005"
99reference = "https://attack.mitre.org/tactics/TA0005/"
100
101[[rule.threat.technique]]
102name = "Impair Defenses"
103id = "T1562"
104reference = "https://attack.mitre.org/techniques/T1562/"
105
106[[rule.threat.technique.subtechnique]]
107name = "Indicator Blocking"
108id = "T1562.006"
109reference = "https://attack.mitre.org/techniques/T1562/006/"
110
111[[rule.threat.technique]]
112name = "Subvert Trust Controls"
113id = "T1553"
114reference = "https://attack.mitre.org/techniques/T1553/"
115
116[[rule.threat]]
117framework = "MITRE ATT&CK"
118
119[[rule.threat.technique]]
120id = "T1082"
121name = "System Information Discovery"
122reference = "https://attack.mitre.org/techniques/T1082/"
123
124[rule.threat.tactic]
125id = "TA0007"
126name = "Discovery"
127reference = "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
- Kernel Seeking Activity
- Kernel Unpacking Activity
- Kubeconfig File Creation or Modification
- Kubeconfig File Discovery
- Kubectl Permission Discovery