AN1243: Analytic 1243
Monitor kernel module load/unload activity via modprobe, insmod, rmmod, or direct manipulation of /lib/modules. Correlate with installation of kernel headers, compilation commands, or downloads of .ko files. Detect anomalies in unsigned module loading or repeated module load attempts under non-root users.
Analyst context for executives and security teams
This analytic focuses on Linux kernel module activity: loading, unloading, or manipulating modules and related files. For leaders, the practical value is that kernel modules can affect the deepest layer of a Linux system, so visibility here helps validate whether critical servers have enough monitoring to spot suspicious low-level changes before they undermine trust in the host.
Executive priority
Prioritize this where Linux systems support business-critical workloads, regulated environments, or incident response evidence collection. The key business question is not only whether endpoint tools are deployed, but whether they can produce reliable evidence of kernel module changes, module compilation or download activity, and unusual load attempts. This supports resilience, auditability, and faster IR decisions when host integrity is in question.
Technical view
For SOC and detection teams, validate monitoring for Linux module load and unload activity involving modprobe, insmod, rmmod, and changes under /lib/modules. Correlate module events with installation of kernel headers, compilation commands, and downloads of .ko files. Tune for anomalous unsigned module loading and repeated module load attempts, especially where activity appears under non-root users. Because no ATT&CK tactic or relationship context is supplied, treat this as a focused Linux host-integrity analytic rather than mapping it to a broader campaign behavior.
Likely telemetry
- Linux process execution telemetry for modprobe, insmod, rmmod, compilers, package managers, and download utilities
- File system monitoring for /lib/modules and .ko file creation, modification, or deletion
- Package installation logs showing kernel headers or module build dependencies
- Kernel, audit, or endpoint logs that record module load/unload events
- User and privilege context for module-related commands, including non-root attempts
Detection direction
- Confirm that module load/unload events are collected on Linux systems, not only generic process starts.
- Correlate module activity with nearby kernel header installation, compilation, or .ko downloads to distinguish routine administration from unusual preparation activity.
- Tune expected baselines for approved drivers, virtualization agents, and maintenance workflows to reduce false positives.
- Review visibility gaps where direct /lib/modules manipulation may not generate the same signals as modprobe, insmod, or rmmod execution.
- Flag repeated failed or unusual module load attempts under non-root users for investigation.
Mitigation priorities
- Establish an inventory or baseline of expected kernel modules on critical Linux hosts.
- Restrict administrative access and module-management permissions to authorized users and workflows.
- Harden change-management and monitoring around /lib/modules and kernel-header installation on sensitive systems.
- Ensure incident response playbooks include preservation and review of kernel module, process, package, and file-system evidence.
- Use this analytic as a validation point for Linux EDR/audit logging coverage rather than assuming default telemetry is sufficient.
Analyst notes and limits
The supplied ATT&CK object is a detection analytic for Linux and provides descriptive detection intent but no separate official detection field, tactics, relationships, aliases, or labels. The strongest use is as a coverage-validation checklist for Linux kernel module monitoring.
No relationship context, ATT&CK tactic, procedure examples, or attribution are supplied. Local baselines are required because legitimate administrative, driver, virtualization, and maintenance activity can also load or modify kernel modules. This take does not assert active exploitation or guaranteed detectability.
Analytic 1243
Monitor kernel module load/unload activity via modprobe, insmod, rmmod, or direct manipulation of /lib/modules. Correlate with installation of kernel headers, compilation commands, or downloads of .ko files. Detect anomalies in unsigned module loading or repeated module load attempts under non-root users.
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 | 1.0 | Current bundle | c4ad2e0966ac… |
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 AN1243Open 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.