Scan for loaded RootKit Kernel Modules

[juergenc]

Feature Request

Description

I compiled and installed the following fake rootkit kernel modules on a test agent:

lsmod 
Module                  Size  Used by
wkmr26                  1191  0 
strings                 1192  0 
xC                      1187  0 
rpldev                  1191  0 
p2                      1187  0 
vlogger                 1192  0 
phide_mod               1194  0 
mod_klgr                1193  0 
modhide                 1192  0 
flkm                    1189  0 
bkit_adore              1195  0 
cleaner                 1192  0 
adore                   1190  0 
knark                   1190  0

I did not install the corresponding patched binaries of the corresponding rootkits, just some self-compiled fake modules which do nothing. Even if rootkits would be recognised by the occurrence of the installed patched binaries (netstat, ps, ls, lsmod, ... and friends) and Wazuh would recognise them by FIM checks, it is notwithstanding a good idea also to check for the existence the of loaded kernel modules triggering an alert on specific loaded modules.

User Acceptance Criteria

1. Check also for loaded kernel modules filtering for the names of the well known rootkit kernel modules
2. Do not use the lsmod binary for the examination since it could be replaced by the rootkit hiding its own kenel module, use /proc/modules itself.
3. generate an alert if one of the modules is loaded

Side Note

For testing with fake kernel modules you might consult this web page

Solution Suggestion

I implemented a solution which works and I detected in this connection a bug with CDB-lists.

1. Add this to agent's ossec.conf. The logger pipes the output into into syslog. I do not use the <full_command> tag for it generating syscheck events which aren't fully parsable as regular events:

   <ossec_config>
   ...
   <localfile>
   <log_format>full_command</log_format>
   <command>cat /proc/modules | logger -t loaded-kmod</command>
   <alias>kmod</alias>
   <frequency>14400</frequency>
   </localfile>
   ...
   </ossec_config>

2. I created a decoder for that specific events (it's my first self-written decoder, feedback would be appreciated if there is optimisation potential):

   
   <!--
   Here some output examples generated by <command>cat /proc/modules | logger -t loaded-kmod</command>
   ---------------------------------------------------------------------------------------------------
   Oct 29 19:11:07 bkpnodemass01 loaded-kmod: drm 246395 4 radeon,drm_kms_helper,ttm, Live 0xffffffffa037e000
   Oct 29 19:11:07 bkpnodemass01 loaded-kmod: syscopyarea 3006 1 drm_kms_helper, Live 0xffffffffa0361000
   Oct 29 19:11:07 bkpnodemass01 loaded-kmod: psmouse 88843 0 - Live 0xffffffffa0149000
   Oct 29 19:11:07 bkpnodemass01 loaded-kmod: knark 1190 0 - Live 0xffffffffa0a39000 (O)
   -->

ossec ^loaded-kmod kmod-detect ossec (\w+)\s+(\d+)\s+(\d+)\s+(\S+)\s+(\w+)\s+(0x\w+) module,memsize,instance,depend,state,memoffset

3. Here the rule, it generates `level 12` alerts if a `rootkit` kernel module is loaded. I used `CDB lists` with the blacklisted `rootkit` kernel modules which works impeccable with the `ossec-logtest` tool but not in real live (see bug report #1774). I replaced it by the enumeration of the `ROOTKIT_LKM` variable and the `match` tag which works in live. Since it is a `level 12` rule it should send an e-mail if a `rootkit` kernel module is present which works with the `<match>` but **NOT** with the `<list field="abc">` tag. Now, the rule:
```XML
<group name="kmod,">
  <var name="ROOTKIT_LKM">adore|afhrm|bkit_adore|cleaner|diamorphine|flkm|itf|kis|knark|kstat|modhide|mod_klgr|p2|phide_mod|Rial|strings|Synapsis|rootkit|rpldev|vlogger|wkmr26|xC</var>

  <rule id="112000" level="0">
    <category>ossec</category>
    <decoded_as>kmod-detect</decoded_as>
    <description>Grouping of loaded kernel rules.</description>
  </rule>

  <rule id="112001" level="12">
    <if_sid>112000</if_sid>
    <!-- <list field="module" lookup="match_key">etc/lists/rootkit/linux-rootkit-lkm</list> -->
    <match>$ROOTKIT_LKM</match>
    <description>Loaded kernel rootkit module found!</description>
  </rule>
</group>

And yes, feedback about how the decoder and the rule is written is highly welcome!

[Lopuiz]

Hello @juergenc,

First, sorry for the late answer. These rules are very interesting. If you want to contribute with our repository you can create PR with your rules and decoders.

Kind regards, Eva.