Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linux kernel rootkit techniques #998

Open
mike-hunhoff opened this issue Feb 15, 2025 · 6 comments
Open

Linux kernel rootkit techniques #998

mike-hunhoff opened this issue Feb 15, 2025 · 6 comments
Labels
good first issue Good for newcomers help wanted Extra attention is needed rule idea

Comments

@mike-hunhoff
Copy link
Collaborator

https://inferi.club/post/the-art-of-linux-kernel-rootkits

@mike-hunhoff mike-hunhoff added good first issue Good for newcomers help wanted Extra attention is needed rule idea labels Feb 15, 2025
@dhruvak001
Copy link
Contributor

dhruvak001 commented Mar 8, 2025

Some of the rule ideas I thought of is:

  1. Detect rootkits that intercept readdir to hide processes by filtering /proc entries.
  2. Identify rootkits that manipulate VFS functions (e.g., vfs_readdir, filldir) to hide files.
  3. Detect rootkits that use Netfilter hooks (e.g., nf_register_net_hook) to intercept/modify packets.
  4. Detect modification of the system call table (sys_call_table) to redirect syscalls.
  5. Identify rootkits that hide their presence by unlinking from the kernel module list.
  6. Detect rootkits that escalate privileges by modifying struct cred (e.g., UID/GID overwrite).
  7. Detect rootkits that capture keystrokes by intercepting input handlers (e.g., input_register_handler).

@hafizfarhad
Copy link
Contributor

Hi @mike-hunhoff , I have gone through the mentioned blog post and it covers so many techniques like ftrace, kprobes/kretprobes, and eBPF hooks. It also discusses some other approaches other than direct hooking i.e like hidden module entries, modifications in sysfs/procfs, and logs manipulations.

I would be grateful if you could please give me a starting point.

Thank you.

@mike-hunhoff
Copy link
Collaborator Author

@dhruvak001 @hafizfarhad we've had the most success with capa rules that leverage api, number, and string features. I'd recommend picking technique(s) that could be matched by one or more of these features.

@hafizfarhad
Copy link
Contributor

Got It! Thank you so much @mike-hunhoff

@dhruvak001
Copy link
Contributor

@mike-hunhoff According to me 5. Unlinking a module from the kernel’s module list to avoid detection and 6. Modifying struct cred to escalate privileges (e.g., root UID), would be good to start with for capa rules?

@mike-hunhoff
Copy link
Collaborator Author

@mike-hunhoff According to me 5. Unlinking a module from the kernel’s module list to avoid detection and 6. Modifying struct cred to escalate privileges (e.g., root UID), would be good to start with for capa rules?

Those sound reasonable to me, although, based on your description here these rules will require offset features so you'll need a good example file to use as a guide for your rule development.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers help wanted Extra attention is needed rule idea
Projects
None yet
Development

No branches or pull requests

3 participants