EnyeLKM is a loadable kernel module virus that inserts jumps in both the system_call and sys_enter functions to massage output.

I did some research on the specifics of how this particular rootkit works and will be releasing my complete findings in the near future.

One interesting thing about the way that EnyeLKM works is that it cloaks processes based on their GID. A process with a particular "magic" GID will be hidden from the process list. It's network connections will also be hidden from /proc. While there is a default "magic" GID that EnyeLKM is compiled with, changing this is as easy as changing a define in config.h. I got to thinking it would be neat on a system known to be infected with Enye to be able to find the "magic" GID. The absence of one would also indicate that EnyeLKM is not running on the system. I wrote the code and tested it, but found out that it will take an amazingly long time to run from user space. The code is posted here as an example of what to look for.

The program tries the default EnyeLKM is compiled with first, followed by anything in the colon separated list in the environment variable ENYEGIDS. After that, it just brute forces its way through the 32 bit value. If it doesn't return right away, go take lunch (and dinner). If EnyeLKM isn't running (the process isn't hidden with any GID) that will be reported too. This is useful both for confirming that EnyeLKM is (or isn't running on the system) and what special GID is used for hiding processes. For sustained investigations you can use the rootkit against the attacker smile

Another program written below uses the readdir() and stat() calls on the /proc filesystem to locate hidden processes. It does not need to know the magic GID. I suspect that this will work for discovering hidden processes on other rootkits, but so far I've only tested against EnyeLKM (up to 1.2). This needs some work, but I'm on to another project and will close the loop on this code later to make it more bombproof. Right now it could possibly provide false negatives if pid and processor starvation are occurring simultaneously. Also, the max pid should be read rather than hardcoded. I'd still trust it on a production system with no issues. FYI, for false negatives to be occurring the machine would be in an almost unusable state (probably so unusable that the application wouldn't run).

-- JakeWilliams - 22 Sep 2008

Topic revision: r3 - 07 Oct 2008 - 01:57:59 - JakeWilliams
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors and Jake Williams.
Ideas, requests, problems regarding TWiki? Send feedback