Enumeration of Kernel Modules
Loadable Kernel Modules (or LKMs) are pieces of code that can be loaded and unloaded into the kernel upon demand. They extend the functionality of the kernel without the need to reboot the system. This identifies attempts to enumerate information about a kernel module.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2020/04/23"
3integration = ["endpoint"]
4maturity = "production"
5updated_date = "2025/01/24"
6
7[rule]
8author = ["Elastic"]
9description = """
10Loadable Kernel Modules (or LKMs) are pieces of code that can be loaded and unloaded into the kernel upon demand. They
11extend the functionality of the kernel without the need to reboot the system. This identifies attempts to enumerate
12information about a kernel module.
13"""
14false_positives = [
15 """
16 Security tools and device drivers may run these programs in order to enumerate kernel modules. Use of these programs
17 by ordinary users is uncommon. These can be exempted by process name or username.
18 """,
19]
20from = "now-9m"
21index = ["logs-endpoint.events.*", "endgame-*"]
22language = "kuery"
23license = "Elastic License v2"
24name = "Enumeration of Kernel Modules"
25risk_score = 47
26rule_id = "2d8043ed-5bda-4caf-801c-c1feb7410504"
27setup = """## Setup
28
29This rule requires data coming in from Elastic Defend.
30
31### Elastic Defend Integration Setup
32Elastic Defend is integrated into the Elastic Agent using Fleet. Upon configuration, the integration allows the Elastic Agent to monitor events on your host and send data to the Elastic Security app.
33
34#### Prerequisite Requirements:
35- Fleet is required for Elastic Defend.
36- To configure Fleet Server refer to the [documentation](https://www.elastic.co/guide/en/fleet/current/fleet-server.html).
37
38#### The following steps should be executed in order to add the Elastic Defend integration on a Linux System:
39- Go to the Kibana home page and click "Add integrations".
40- In the query bar, search for "Elastic Defend" and select the integration to see more details about it.
41- Click "Add Elastic Defend".
42- Configure the integration name and optionally add a description.
43- Select the type of environment you want to protect, either "Traditional Endpoints" or "Cloud Workloads".
44- Select a configuration preset. Each preset comes with different default settings for Elastic Agent, you can further customize these later by configuring the Elastic Defend integration policy. [Helper guide](https://www.elastic.co/guide/en/security/current/configure-endpoint-integration-policy.html).
45- We suggest selecting "Complete EDR (Endpoint Detection and Response)" as a configuration setting, that provides "All events; all preventions"
46- Enter a name for the agent policy in "New agent policy name". If other agent policies already exist, you can click the "Existing hosts" tab and select an existing policy instead.
47For more details on Elastic Agent configuration settings, refer to the [helper guide](https://www.elastic.co/guide/en/fleet/8.10/agent-policy.html).
48- Click "Save and Continue".
49- To complete the integration, select "Add Elastic Agent to your hosts" and continue to the next section to install the Elastic Agent on your hosts.
50For more details on Elastic Defend refer to the [helper guide](https://www.elastic.co/guide/en/security/current/install-endpoint.html).
51"""
52severity = "medium"
53tags = [
54 "Domain: Endpoint",
55 "OS: Linux",
56 "Use Case: Threat Detection",
57 "Tactic: Discovery",
58 "Data Source: Elastic Defend",
59 "Data Source: Elastic Endgame",
60 "Resources: Investigation Guide",
61]
62timestamp_override = "event.ingested"
63type = "new_terms"
64
65query = '''
66event.category:process and host.os.type:linux and event.type:start and event.action:(exec or exec_event) and (
67 (process.name:(lsmod or modinfo)) or
68 (process.name:kmod and process.args:list) or
69 (process.name:depmod and process.args:(--all or -a))
70) and
71not (
72 process.parent.name:(
73 mkinitramfs or cryptroot or framebuffer or dracut or jem or thin-provisioning-tools or readykernel or lvm2 or
74 vz-start or iscsi or mdadm or ovalprobes or bcache or plymouth or dkms or overlayroot or weak-modules or zfs or
75 systemd or whoopsie-upload-all or kdumpctl or apport-gtk or casper or rear or kernel-install or newrelic-infra
76 ) or
77 process.parent.executable:/var/lib/dpkg/info/linux-modules*-generic.post*
78)
79'''
80note = """## Triage and analysis
81
82> **Disclaimer**:
83> 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.
84
85### Investigating Enumeration of Kernel Modules
86
87Loadable 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.
88
89### Possible investigation steps
90
91- 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.
92- 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.
93- Investigate the user account associated with the process to determine if the activity aligns with expected behavior or if it might indicate unauthorized access.
94- 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.
95- 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.
96
97### False positive analysis
98
99- 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.
100- 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.
101- 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.
102- 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.
103- 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.
104
105### Response and remediation
106
107- Immediately isolate the affected system from the network to prevent potential lateral movement by the adversary.
108- Terminate any suspicious processes identified by the detection rule, specifically those involving unauthorized use of lsmod, modinfo, kmod, or depmod commands.
109- Conduct a thorough review of recent system logs and process execution history to identify any unauthorized access or changes made to the system.
110- Restore the system from a known good backup if any unauthorized modifications to kernel modules or system files are detected.
111- Update and patch the system to the latest security standards to mitigate any known vulnerabilities that could be exploited through kernel modules.
112- Implement stricter access controls and monitoring for kernel module management, ensuring only authorized personnel can load or unload modules.
113- Escalate the incident to the security operations team for further investigation and to assess the potential impact on other systems within the network."""
114
115[[rule.threat]]
116framework = "MITRE ATT&CK"
117
118[[rule.threat.technique]]
119id = "T1082"
120name = "System Information Discovery"
121reference = "https://attack.mitre.org/techniques/T1082/"
122
123[rule.threat.tactic]
124id = "TA0007"
125name = "Discovery"
126reference = "https://attack.mitre.org/tactics/TA0007/"
127
128[rule.new_terms]
129field = "new_terms_fields"
130value = ["process.executable", "process.parent.executable"]
131
132[[rule.new_terms.history_window_start]]
133field = "history_window_start"
134value = "now-14d"
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 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.
Related rules
- Pluggable Authentication Module (PAM) Version Discovery
- Security File Access via Common Utilities
- Polkit Version Discovery
- ESXI Discovery via Find
- ESXI Discovery via Grep