Detection techniques for each rootkit type } Command-level rootkits
} Library-level rootkits
Approaches to detecting command-level rootkits
1. If a rootkit listens for connections, the network port will be visible to
an external network port scanner
2. Some tools can reveal the names of all directory entries, including
hidden or deleted files
3. Corrupted versions of ps and similar hide malware processes, but
these can still be found using, e.g., the /proc file system
4. Deleted login/logout records in the wtmp file leave behind holes
that can be detected using an appropriate tool
5. Ifconfig might report that a network interface is not in sniffer mode,
but we can query the kernel for the interface status
6. CRC checksums reported by compromised cksum, can be detected
using MD5 or SHA1
Example of exposing a command-level rootkit1/7
} We examine two utilities of the T0rn rootkit for Linux
} This rootkit was in widespread use in 2001
} First, search the /bin/ls executable file using strings and grep
Example of exposing a command-level rootkit2/7
} If we try to list the /usr/src/.puta directory, the ls
command hides the name, as we would expect:
} However, the directory name still shows up when we
use the echo command, together with the .* wildcard expansion feature that is built into the command shell
Example of exposing a command-level rootkit3/7
} File .puta/.1file is a rootkit configuration file
} Has list of file and directory names that must remain hidden
Example of exposing a command-level rootkit4/7
} To detect modified process status check against /proc
Example of exposing a command-level rootkit5/7
} The system utilities that were replaced by the rootkit
do a good job of hiding process 153
} Not only it is censored by process status tools like ps, but also
it does not show up with network status tools such as netstat
} However, it does not replace the lsof command, which
Example of exposing a command-level rootkit6/7
} File name /usr/sbin/nscd suggests that it is a system
program, but comparison with uncompromised systems shows this program exists only in later Linux versions
Example of exposing a command-level rootkit7/7
} Connecting with telnet to TCP port 47017 on the local
machine confirms it is a backdoor process
} In this case we are welcomed by the opening banner of what
appears to be an SSH server
} Find more about the T0rn rootkit at:
Automated approaches for detection
} Each rootkit differs slightly in its approach to hiding the
presence of malware and therefore requires us to take a slightly different approach to detect it
} An example of software that automates the search for known
rootkits is the Chkrootkit toolkit
} Runs on a dozen different UNIX platforms
} Recognizes more that fifty different rootkits
} Looks for deleted login / logout records, signatures of replaced system
utilities, rootkit configuration files and directories, missing processes, and signs of kernel-level subversion
Detection techniques for each rootkit type } Command-level rootkits
} Library-level rootkits
Detection of library-level rootkits } Strawman: check library hashes. But, would an MD5 or
SHA-1 hash reveal library modifications?
} Not necessarily: while the runtime linker uses the low-
level open() system call when it accesses the modified library file, md5sum use the fopen() library routine
} Therefore, can be redirected to the unmodified library file
} Workaround: rootkit detection tools need to carry their
Detection techniques for each rootkit type } Command-level rootkits
} Library-level rootkits
Detection of kernel-level rootkits } Kernel rootkits may be exposed because they
introduce little inconsistencies into a system
} Some may show up externally, in the results from
system calls that manipulate processes, files, kernel modules, etc.
} Others show up only internally, in the contents of kernel
data structures
} E.g., hidden objects occupy some storage even though the
Inconsistencies that may reveal kernel rootkits
} Output of tools that bypass the file system can reveal
information that is hidden by compromised FS code
} E.g., TSK
} Oversight
} E.g., the modification time of an important system directory is
changed, not to the contents of that directory
} Inconsistencies in the results from process-manipulating
system calls and from the /proc file system
Inconsistencies that may reveal kernel rootkits
} Unexpected behavior of some system calls
} E.g., when the Adore rootkit is installed, setuid() – change process
privileges – will report success for some parameter value even though the user does not have sufficient privileges
} E.g., when the Knark rootkit is installed, settimeofday() – set the
system clock – will report suffess for some parameter values even though is should always fail when invoked by an unprivileged user
} Directory hard link count inconsistencies
} The hard link count of a directory, as reported by stat(), should
Inconsistencies that may reveal kernel rootkits
} Modifications to kernel tables, such as system call
table or the virtual FS table
} May be detected after the fact by reading kernel memory
via /dev/kmem
} Or by examining kernel memory from inside with a forensic
kernel module such as Carbonite
} Modifications to kernel tables or kernel code may be
detected using a kernel module that samples critical data structures periodically
Inconsistencies that may reveal kernel rootkits
} Checking against raw data sources
} Modifications that hide files can show up as inconsistencies
between information from the raw disc device and information returned by the kernel file system code
} Modifications that hide network ports, processes, or kernel
modules may be exposed by reading kernel memory and comparing the contents of kernel data structures with results from system calls
Example of kernel toolkit detector tool } Findrootkit: examines kernel mem through /dev/kmem
and checks consistency from multiple sources:
} The /dev/ksyms symbol table, with kernel function and data
addresses and sizes
} The in-kernel module list, with executable code and data
segment addresses and sizes of loaded kernel modules
} The in-kernel “text arena” table, with executable code
segment addresses and sizes
} The function addresses in the system call jump tables and in
file system operation jump tables
Example of kernel toolkit detector tool
} Findrootkit can produce modification reports
} Report example for a Solaris kernel
} Changes to (a) the file system operations table, and (b) the system-
Conclusions } Many attacks to operating systems are performed
through rootkit software
} There are three different types of rootkits depending
on the OS layer targeted by the rootkit: command-, library-, and kernel-level rootkits
} Depending on the rootkit, the forensic analyst needs to
References } Primary bibliography
Next class } Mobile forensics: Android