DC0031: Kernel Module Load
The process of loading a kernel module into the operating system kernel. Kernel modules are object files that extend the kernel’s functionality, such as adding support for device drivers, new filesystems, or additional system calls. This action can be legitimate (e.g., loading a driver) or malicious (e.g., adding a rootkit).
*Data Collection Measures:*
- Linux: - Auditd: Enable auditing of kernel module loading. Example rule: `-a always,exit -F arch=b64 -S init_module,delete_module`. - Syslog: Monitor `/var/log/syslog` or `/var/log/messages` for entries related to kernel module loads. - Systemd Journal: Use `journalctl` to query logs for module loading events: `journalctl -k | grep "Loading kernel module"` - macOS: - Unified Logs: Use the `log` command to query kernel module events: `log show --predicate 'eventMessage contains "kextload"' --info` - Endpoint Security Framework (ESF): Monitor for `ES_EVENT_TYPE_AUTH_KEXTLOAD` (kernel extension loading events). - Kernel-Specific Tools: - Lsmod: Use `lsmod` to list loaded kernel modules in real-time. - Kprobe/eBPF: Use extended Berkeley Packet Filter (eBPF) or Kernel Probes (kprobes) to monitor kernel events, including module loading. Example using eBPF tools like BCC: `sudo python /path/to/bcc/tools/kprobe -v do_init_module` - Enable EDR Monitoring: - Configure alerts for: Suspicious kernel module loads from non-standard paths (e.g., /tmp). Unexpected or unsigned kernel modules. - Review detailed telemetry data provided by the EDR for insight into who initiated the module load, the file path, and whether the module was signed.
Analyst context for executives and security teams
Kernel module load telemetry matters because code loaded into the operating system kernel can legitimately support drivers and filesystems, but the same event class can also indicate high-risk tampering such as a rootkit. For leaders, this is a coverage question: can the organization prove who initiated kernel-level changes, from where, and whether the module was expected or signed?
Executive priority
Prioritize this data component where system integrity and operational resilience are important. Kernel-level changes can affect incident scope, trust in endpoint evidence, and recovery decisions. Security leaders should ask whether SOC and IR teams have reliable kernel module load records, whether those records are retained centrally, and whether exceptions for legitimate drivers are documented for audit and response use.
Technical view
MITRE provides collection guidance but no analytic detection logic for DC0031. Defenders should validate collection of kernel module load events from supported local sources such as Linux auditd, syslog, systemd journal, lsmod snapshots, kprobe/eBPF-based monitoring, macOS Unified Logs, macOS Endpoint Security Framework kext-load events, and EDR telemetry where available. Triage should focus on initiator, module path, signing status, timing, and whether the module aligns with expected administration, driver, or filesystem activity.
Likely telemetry
- Linux auditd events for init_module and delete_module system calls
- Linux syslog or /var/log/messages entries related to module loading
- Linux systemd journal kernel messages related to module loading
- Current loaded-module inventory from lsmod or equivalent tooling
- Kernel event telemetry from kprobe/eBPF-based monitoring
Detection direction
- Confirm that kernel module load events are collected centrally and retained long enough for incident response.
- Tune alerts for suspicious kernel module loads from non-standard paths, including temporary locations, when supported by telemetry.
- Review unexpected or unsigned kernel modules, while accounting for legitimate driver, filesystem, and administrative activity to reduce false positives.
- Correlate module-load events with the initiating user/process and surrounding endpoint activity rather than treating every load as malicious.
- Identify blind spots where local logs exist but are not forwarded, where EDR does not expose signing/path details, or where real-time loaded-module state is not periodically validated.
Mitigation priorities
- Establish a known-good baseline of expected kernel modules and kernel extensions for critical systems.
- Require operational justification and change tracking for new drivers, filesystems, or kernel extensions.
- Centralize and protect kernel module load logs so responders can rely on them during compromise assessment.
- Use EDR or native logging configuration to capture module path, initiator, and signing status where available.
- Periodically compare current loaded modules against expected inventory, especially on systems with high integrity or availability requirements.
Analyst notes and limits
This object is a data component, not a technique, and no ATT&CK relationships were supplied. The strongest decision value is telemetry readiness: whether endpoint, SOC, and IR teams can observe and explain kernel-level changes. Local baselining is essential because legitimate kernel module activity is common in normal administration and device support.
ATT&CK does not provide official detection logic, tactics, platforms, or relationship context for this object in the supplied fields. The OS-specific collection examples support Linux and macOS telemetry discussion, but local architecture, logging configuration, EDR capability, and retention policy determine actual coverage.
Kernel Module Load
The process of loading a kernel module into the operating system kernel. Kernel modules are object files that extend the kernel’s functionality, such as adding support for device drivers, new filesystems, or additional system calls. This action can be legitimate (e.g., loading a driver) or malicious (e.g., adding a rootkit).
*Data Collection Measures:*
- Linux: - Auditd: Enable auditing of kernel module loading. Example rule: `-a always,exit -F arch=b64 -S init_module,delete_module`. - Syslog: Monitor `/var/log/syslog` or `/var/log/messages` for entries related to kernel module loads. - Systemd Journal: Use `journalctl` to query logs for module loading events: `journalctl -k | grep "Loading kernel module"` - macOS: - Unified Logs: Use the `log` command to query kernel module events: `log show --predicate 'eventMessage contains "kextload"' --info` - Endpoint Security Framework (ESF): Monitor for `ES_EVENT_TYPE_AUTH_KEXTLOAD` (kernel extension loading events). - Kernel-Specific Tools: - Lsmod: Use `lsmod` to list loaded kernel modules in real-time. - Kprobe/eBPF: Use extended Berkeley Packet Filter (eBPF) or Kernel Probes (kprobes) to monitor kernel events, including module loading. Example using eBPF tools like BCC: `sudo python /path/to/bcc/tools/kprobe -v do_init_module` - Enable EDR Monitoring: - Configure alerts for: Suspicious kernel module loads from non-standard paths (e.g., /tmp). Unexpected or unsigned kernel modules. - Review detailed telemetry data provided by the EDR for insight into who initiated the module load, the file path, and whether the module was signed.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | d0063dd99d6d… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DC0031Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.