A Linux rootkit tutorial - an introduction

I haven't really done a lot with this blog since starting it - mainly because I became swamped with other things. However, I recently visited a webpage from Volatility Labs detailing detection of the KBeast rootkit.

Well - challenge accepted. I'm going to provide a tutorial on how to create a Linux rootkit that can hide from the methods detailed in the page above - and show you how we interact with the kernel to accomplish this.  All the code featured will be made publish on github here: https://github.com/nnewson/km

We'll go through it in various stages:

1. Create our build environment.
   This will involve detailing the creation of a very basic device driver and the Makefile that will produce it.  It'll also go into loading and unloading the driver.  This is important - as this is a development project any change made by the rootkit should be reversible and allow you to unload it and return your system to it's previous state.
2. Generate a symbols file.  
   While some of the symbols (functions, global variables etc.) are exported by the kernel, most aren't - and we're going to need a few of those to ensure we activate and deactivate our functionality in the correct way.  As such we're going to have to look some of these symbols up.  I'll show you how you can do this and integrate this process into the Makefile to auto-generate a symbols header file.
3. Add a basic /proc control entry.
   For the sake of simplicity we're going to add a simply entry to allow us to pass commands to rootkit, allowing us to hide or show it when we want to.  Later we'll change this to something more covert, but for ease of understanding this will do for now.  This will provide a basic level of 'command and control'.
4. Hide our rootkit from lsmod, /proc/modules and /sys/module.
   Our rootkit should be able to hide itself from this listing mechanisms (I'll also explain why our rootkit appeared in these lists in the first place).  Of course it should also be able to reappear in these list - so we can properly unload it as a normal device driver.
5. Provide the ability to hook various function calls.
   Once a rootkit is hidden, one the most obvious things for to do is to intercept or filter functions calls.  It's this mechanism that allows you to add the hidden functionality of the rootkit.  The hooking needs to be done in such a way as to minimise detection without causing an exceptions. Again - we should be able to roll-back any changes made.
6. Use a covert network communication channel.
   Once we've got the system hidden and doing work, the next obvious thing is to provide an ability to communicate with a remote source - for command and control.  This will allow us to take instructions and export any date collected.

The code on github already provides the first four stages, and we'll be adding to this as we go along - but each stage will be detailed in turn and we'll build on them one step at a time.

In the next update, I'll write about what a rootkit actually is, why we use the insmod command to load it a device driver (and the various problems this creates) and how we'd ideally like to do this.

Hopefully, eventually I'll be able to get around to talking about the really interesting stuff - namely covertly loading our rootkit, remotely providing code updates and patching as well as dealing with anti -forensics.

All the work for this will be done on the latest kernel on the development machine I'm using - namely 3.8.0-19.