Home | @unixist | unixist@freenode

>: Detecting hidden files


After system compromise, the attacker’s goal is almost invariably to maintain access for a given period of time. This is usually true even if the attacker only intends to exfiltrate data or perform some form of sabotage. In order to operate undetected for as long as possible, the attacker must limit anomalous behavior: this includes stealthy network communication, judicious use of system resources, hiding any disk presence, and more. I’m herein concerned with detecting an attacker’s disk presence, with a focus on hidden files on an otherwise normal and accessible filesystem. I don’t consider protected or regularly inaccessible portions of storage devices.

Rootkits come in many forms to accomplish the above. Some function as binary replacements for system utilities such as ls, ps, netstat, lsof, df, etc. Some function as userspace in-memory patches of services such as sshd or apache. Still others live in the kernel. Kernel kits are not necessarily the most interesting to an attacker, but are by far the most powerful as operations are carried out with ring 0 privileges. While the replacement of system utilities cannot fool file integrity checkers and in-memory binary patching is limited by process scope and userspace power, the kernel is near-limitless in its stealth abilities.

What

inodeyou is a tool that detects some forms of kernel rootkit file hiding. It detects when certain linux system calls are hooked, replaced by modified versions that shield files from view. It evaluates the disk’s view of the filesystem (via read(2)) and the user’s view of the mounted filesystem (via getdents(2), stat(2), etc.) by comparing the inodes present from both points of view.

I have tested with private kernel modules that hook system calls to hide files, but you can test on kits like Adore or Suckit.

Why

The main reason it’s necessary to take a look at the raw storage device instead of using tools like ls, or find is due to abstractions. The filesystem placed on top of a storage device or volume allows you to easily reference files and directories and hierarchies on it. Reading a filesystem only requires that you speak ls to list directories; reading a raw device requires you to speak filesystem, e.g. EXT2/3/4, FAT, NTFS.

The filesystem gives a user friendly view to the device by way of system calls like read(2) to read file contents, stat(2) to read file metadata, getdents(2) to read directory contents/entries. If certain system calls are hooked, you may receive an incomplete list of files that reside in a directory when you ls it. But if you skip right down to open(2)ing and read(2)ing the storage device, then you access the bytes directly and can interpret them as fs data structures. This is a more difficult problem for the rootkit writer to defend against.

Another reason to employ a file detection technique of this sort is that up-to-date rkhunter and chkrootkit fail to find these files.

Notes

Dependencies

Examples

Tool

Project: inodeyou
Repo: git clone https://bitbucket.org/unixist/inodeyou.git

Catch me on twitter if you’d like to chat about other ways to hide files and try to detect that they’re hidden.