PH_Rule_TH_Linux_27
Enabled
Identifies loadable kernel module modification, which may indicate indicative of potential persistence attempts. Security tools and device drivers may run these programs in order to load legitimate kernel modules. Use of these programs by ordinary users is uncommon. This requires process monitoring via FortiSIEM Linux agent.
7
Security
Persistence
Persistence consists of techniques that adversaries use to keep access to systems across restarts, changed credentials, and other interruptions that could cut off their access. Techniques used for persistence include any access, action, or configuration changes that let them maintain their foothold on systems, such as replacing or hijacking legitimate code or adding startup code.
https://attack.mitre.org/tactics/TA0003T1547.006
Boot or Logon Autostart Execution: Kernel Modules and Extensions
Adversaries may modify the kernel to automatically execute programs on system boot. Loadable Kernel Modules (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. When used maliciously, LKMs can be a type of kernel-mode [Rootkit](https://attack.mitre.org/techniques/T1014) that run with the highest operating system privilege. Adversaries can use LKMs and Kernel Extensions to covertly persist on a system and elevate privileges.
https://attack.mitre.org/techniques/T1547/006Server
Linux Process Monitoring via FortiSIEM Agent
Correlation
No remediation guidance specified
If the following pattern or patterns match an ingested event within the given time window in seconds, trigger an incident.
300 seconds
If the following defined pattern/s occur within a 300 second time window.
Filter
This is the named definition of the event query, this is important if multiple subpatterns are defined to distinguish them.
This is the query logic that matches incoming events
eventType = "LINUX_PROCESS_EXEC" AND procName IN ("insmod", "kmod", "modprobe", "rmod")
This defines how matching events are aggregated, only events with the same matching attribute values are grouped into one unique incident ID
hostName, user, procName
This is most typically a numerical constraint that defines when the rule should trigger an incident
COUNT(*) >= 1
This section defines which fields in matching raw events should be mapped to the incident attributes in the resulting incident.
The available raw event attributes to map are limited to the group by attributes and the aggregate event constraint fields for each subpattern
hostName = Filter.hostName,
user = Filter.user,
procName = Filter.procName