This note documents detection patterns related to Kernel Module Tampering on Linux systems.

Direct Indicators

Source	Grep Pattern / Artifact	Meaning	Forensic Value	Notes
Shell history	`insmod`	Manual kernel module insertion	Critical	Strong privilege-level activity.
Shell history	`modprobe`	Module load request	Critical	Common legitimate tool, context critical.
Shell history	`rmmod`	Module removal	Critical	Can indicate cleanup or stealth tampering.
Shell history	`lsmod`	Module inspection before/after tampering	High	Often precedes malicious load.
Shell history	`depmod`	Dependency rebuild	High	Persistence prep after module drop.
Shell history	`modinfo`	Module inspection	Medium	Context dependent.
`/lib/modules/`	new `.ko` file	Kernel object dropped	Critical	Primary module artifact.
`/etc/modules`	added module name	Boot persistence	Critical	Persistent module loading.
`/etc/modules-load.d/`	custom load file	Persistent module load	Critical	Modern persistence path.
File timestamps	recent `.ko` creation	Timeline anchor	Critical	Correlates with privilege window.
`dmesg`	module load messages	Runtime kernel evidence	Critical	Strong truth source.
`journalctl`	kernel module events	Runtime clue	High	Often preserved.
`auditd`	write to module paths	Process attribution	Critical	Best attribution if enabled.
Hidden `.ko` name	camouflage module	Critical	Often mimics legit names.

Indirect Indicators

Indicator	What To Look For	Forensic Value	Notes
Module load after sudo/root shell	Privilege exploitation	Critical	Strong hostile sequence.
New module not matching installed kernel package	Foreign module	Critical	Very strong anomaly.
Module loaded from temp path	Highly suspicious	Critical	Strong malicious signal.
Module removed after short runtime	Cleanup attempt	Critical	Possible stealth rootkit behavior.
Module plus hidden file	Concealed persistence	Critical	Strong operator discipline.
`/etc/modules` modified recently	Boot persistence	Critical	High-value persistence clue.
Module name mimics network driver	Camouflage	High	Common stealth pattern.
Kernel logs gap around load	Possible anti-forensics	High	Context matters.
Root-owned new `.ko` outside package baseline	Critical	Strong compromise indicator.
Module linked to outbound callback	Rootkit-level C2	Critical	Highest severity.

Common Tools

Tool	Usage
`insmod`	Direct kernel object insertion.
`modprobe`	Dependency-aware module load.
`rmmod`	Remove loaded module.
`lsmod`	Inspect active modules.
`depmod`	Rebuild module dependencies.

Relevant Artifacts

Artifact	Path / Command	Forensic Value	Notes
Module tree	`/lib/modules/`	Critical	Primary module storage.
Boot modules	`/etc/modules`	Critical	Persistent load path.
Modules-load config	`/etc/modules-load.d/`	Critical	Persistent load path.
Kernel logs	`dmesg`	Critical	Load evidence.
Journald	`journalctl -k`	Critical	Kernel timeline.
Shell history	`.bash_history`, `.zsh_history`	Critical	Operator commands.
Audit logs	`/var/log/audit/audit.log`	Critical	File write attribution.

MITRE ATT&CK References

T1547 Boot or Logon Autostart Execution
T1547.006 Kernel Modules and Extensions
T1014 Rootkit

Decision Tree

Was module inserted or removed?
- Search shell history and kernel logs.
Is .ko file legitimate?
- Compare against package baseline.
Is persistence configured?
- Check /etc/modules and modules-load configs.
Did module run recently?
- dmesg, journal kernel logs.
Is module linked to hidden payload?
- File names, timestamps, related binaries.
Pivot
- Module → hash / strings.
- Timestamp → privilege timeline.
- User → sudo/root path.
Confirm tampering
- New module + suspicious load path + intrusion context = strong kernel tampering finding.

Example Detection Templates

Grep

grep -R "insmod\|modprobe\|rmmod\|depmod" /home/*/.bash_history /root/.bash_history 2>/dev/null

find /lib/modules -name "*.ko" -printf '%TY-%Tm-%Td %TT %p\n' 2>/dev/null | sort

grep -R "." /etc/modules /etc/modules-load.d 2>/dev/null

Journalctl

journalctl -k | grep -E "module|insmod|modprobe"

File Inspection

dmesg | grep -i module

lsmod

Sigma

title: Linux Kernel Module Tampering
id: linux-kernel-module-tampering
status: experimental
description: Detects suspicious kernel module insertion or persistence activity
logsource:
  product: linux
detection:
  selection_keywords:
    message|contains:
      - 'insmod'
      - 'modprobe'
      - 'rmmod'
      - '.ko'
  condition: selection_keywords
fields:
  - message
  - hostname
falsepositives:
  - Legitimate driver installation
level: high
tags:
  - attack.persistence
  - attack.t1547.006

Mitigation & Hardening

Control Area	Mitigation	Effectiveness	Notes
Module signing	Enforce signed modules	Critical	Blocks arbitrary module insertion.
Auditd	Track module load commands	Critical	Strong attribution.
Baseline modules	Inventory expected `.ko` files	High	Unknown modules stand out.
Restrict root	Limit module load privileges	High	Core prevention.
Kernel log retention	Preserve `dmesg` / journald	High	Needed for timeline proof.

Fast Triage Checks

Question	Command / Artifact	Why It Matters
Was insmod/modprobe used?	grep history	Immediate module check.
Any new `.ko` files?	find modules	Artifact discovery.
Is module persistent?	inspect `/etc/modules`	Boot persistence clue.
Did kernel log load event?	dmesg / journalctl -k	Runtime proof.
Is module name suspicious?	compare baseline	Anomaly scoring.
Is module linked to other persistence?	inspect nearby artifacts	Full chain view.

High Value Grep Strings

Pattern	Why It Matters
`insmod`	Direct module insertion.
`modprobe`	Standard module load.
`rmmod`	Module removal.
`.ko`	Kernel object file.
`/etc/modules`	Boot persistence path.
`depmod`	Dependency rebuild clue.

Analyst Notes

Scenario	Interpretation
`.ko` loaded from temp path	Very strong malicious signal.
New module plus hidden config	Rootkit-style persistence possible.
Module removed quickly	Cleanup or stealth attempt.
Module name mimics legit driver	Camouflage likely.
`/etc/modules` modified after root shell	Persistent kernel tampering.
Outbound callback near module load	Highest severity investigation.