RootKits Part 2
RootKits Part 2
ghost | 4929 Reads | As I promised I will wrap up what is left to explain about binary rootkits from my first article Rookits Part 1. I will also explain Kernel rootkits. Sorry for the long wait so lets jump into it.
As I said trojaned binaries are used for the following functionalities: remote access, local access, process hiding and connection hiding. What I didn’t explain was what else it provides. There are 2 more things it provides and here they are:
- File hiding. A kit may Trojan many file-browsing tools, such as ls, dir, and cat to hide certain files from detection. Some rootkits contains global configuration file that list what connections, files and process should be hidden using expression syntax.
- User activity hiding. If a system admin logs into a compromised system, who and finger trojaned binaries will make sure that the attacker’s user entry is not displayed.
Other binary Trojans will hide evidence of running network sniffers. When the kit is installed, its own tools deploy in some hidden directory. Integrity checking tools could easily find the hidden directory, provide they were installed before the break-in. The system command ls will likely be trojaned to not show this directory by the attacker.
Common location to install rootkit files: · /dev/.hdd · /dev/.lib · /etc/“..“ · /etc/… · /etc/rc.d/arch/alpha/lib/.lib · /etc/rc.d/rsha · /usr/info/.t0rn · /usr/lib/.egcs · /usr/pop/.poop · /usr/pop/.puta · /usr/linux/arch/alpha/lib/.lib/.1proc
Invisible special characters are also often used in the directory names to make their discovery and make deletion harder.
That some up what a binary rootkit is and what it can do. Now I will give a little history on Kernel rootkits.
Kernel Rootkits
Kernel rootkits first came into being a malicious kernel module. It was unknown when the first Loadable Kernel Module (LKM) lit was coded. It was made public in Bugtraq post by Runar Jensen in October 1997. Unlike regular rootkits LKM kits hook into the system kernel module and modify some of the system calls. Most Unix modules separate between kernel-mode and user-mode.
If an application needs a certain access to a hardware piece, it requests the access via system call. The application executes a system call and a kernel provides access to a file on a disk. Each operating system has a slightly different list of system calls. They can be found in /usr/include/system/sys/syscall/.h or /usr/include/syscall.h. The LKM, which runs in kernel mode has the capabilities to modify this code to change the functionally of the call.
Details on the implementation of malicious LKM rootkits are available at http://rs.sans.org/threats/rootkits.php and http://rs.sans.org/linux/kernel_mods.php. LKM kits take hiding above and beyond the next level. More advance malicious LKMs attempt to combat detection attempts by the known anti-LKM-rootkits tools and provide users with additional functionalities, such as root on demand or in-kernel network backdoors.
Admins may defeat most LKM kits by simply disabling the loading of modules within the Unix/Linux kernel. Several kits since have turn these research into production codes. SucKit is a user-friendly package that installs in the kernel and allows covert remote login, without a need to insert any modules and with no user mod components.
This concludes Rootkits Part 2. There will be more articles I will write over rootkits in the upcoming days so keep checking in
even though this is not where i got my info i did not rip it i will state the sites yall found