Testing for Rootkits

[Joeythedude]

Do Rootkits have to include a driver / *sys file ?

http://www.wilderssecurity.com/showpost.php?p=1530311&postcount=34

[BrendanK.]

-{ Quote: "Hypervisor level

These rootkits work by modifying the boot sequence of the machine to load themselves as a hypervisor under the original operating system. By exploiting hardware features such as Intel VT or AMD-V, the rootkit is able to load the original operating system as a virtual machine, thereby enabling it to intercept all hardware calls made by the original operating system, which is now a guest. The "SubVirt" laboratory rootkit, developed jointly by Microsoft and University of Michigan researchers, is an academic example of a virtual machine based rootkit (VMBR),[11] while Blue Pill is another.
Kernel level

Kernel-level rootkits add additional code and/or replace portions of an operating system, including both the kernel and associated device drivers. Most operating systems support kernel-mode device drivers, that execute with the same privileges as the operating system itself.[12] As such, many kernel mode rootkits are developed as device drivers or loadable modules, such as loadable kernel modules in Linux or device drivers in Microsoft Windows. This class of rootkit is perceived as dangerous simply because of the unrestricted security access the code has obtained, regardless of the features the rootkit may employ. Any code operating at the kernel level may have serious impacts on entire system stability if bugs are present in the code. The first and original rootkits did not operate at the kernel level, but were simple replacements of standard programs at the user level. One of the first widely known kernel rootkit was developed for Windows NT 4.0 and released in Phrack issue 55

in the mid-1990s by Greg Hoglund.[13]

Kernel rootkits can be especially difficult to detect and remove, because they operate at the same level as the operating system itself, and are thus able to intercept or subvert any operation made by the operating system. Any software, such as antivirus software, running on the comprised system is equally easily subverted. In a situation such as this, the whole system can no longer be trusted while it is running. One response in such a case is to perform system offline analysis by booting a second known good or 'trusted' system from removable media such as a live CD. Investigation and rootkit removal actions can then be performed safely from a trusted operating system without requiring another physical computer system, as the hard drive of the infected system can be mounted as a secondary resource without executing anything on the untrusted volume. Alternatively, the volume can simply be formatted and the operating system re-installed from trusted media.

Library level

Library rootkits commonly patch, hook, or replace system calls with versions that hide information about the attacker. They can be found, at least theoretically, by examining code libraries (under Windows the term is usually DLL) for changes or against the originally distributed (and so presumably rootkit free) library package; this approach may not succeed however if the code is patched in memory only, or if the rootkit presents the unmodified version to any utility performing a scan. Digital signatures help to detect unauthorized changes to code libraries.[14]

Application level

Application level rootkits may replace regular application binaries with Trojan fakes, or they may modify the behavior of existing applications using hooks, patches, injected code, or other means.

There are unscrupulous companies whose business consists of disseminating rootkits for the purpose of generating paid involuntary page referrals. Such programs would redirect a visit to a popular website like Google to that of a client of the distributor of the rootkit." }-

A search of Wiki can give you many answers :)

[Joeythedude]

had a look at that but it doesn't answer my question :)

[StevieO]

As far as i'm aware, Rootkits require a Driver/SYS file to run, in the Kernel-mode anyway. Here's a couple of User-mode Rootkit examples though that " appear " not to.


Here's what my infamous hxdef100.exe says in it's Read Me file

211678

-

These switches are available:

-:installonly - only install service, but not run
-:refresh - use to update settings from inifile
-:noservice - doesn't install services and run normally
-:uninstall - removes hxdef from the memory and kills all
running backdoor connections
stopping hxdef service does the same now

-

No mention of .SYS etc in this User-mode AFX Rootkit test

-


" User-mode rootkits on Windows systems generally operate by overwriting files on the system itself, as well as by using techniques such as DLL injection and API hooking. These rootkits operate in the same fashion and context as a user on the system, hence the moniker "user-mode. "

" To develop a better understanding of some of these user-mode rootkits, we'll take a look at how an example rootkit is configured and employed, as well as what effect it has on the "victim" system. This way, we'll know what to look for when we suspect that there may be a rootkit on a system. "


" Before we launch our rootkit, we're going to run InControl5 so that we can see what changes this rootkit makes to the system when it is installed. "

Figure 7-11. InControl5 report showing files added by afx_example.exe installation. - http://www.ubookcase.com/book/Addison.Wesley/Windows.Forensics.and.Incident.Recovery/0321200985/ch07lev1sec4.html

211679

-

There are 8 file types with the "SYS" extension name - http://www.file-extensions.org/sys-file-extension-system-device-driver

[Joeythedude]

Very interesting. Thanks.

[nick s]

-{ Quote: "-:noservice - doesn't install services and run normally" }-
Hi StevieO,

Just noticed this and wanted to clarify the -:noservice switch usage. It's an on-demand switch. All files, including hxdefdrv.sys and hackerdefenderdrv100.sys, are written to the system. When activated, it only runs until the system is restarted. When it is activated, the drivers are active...

8/30/2009 22:16:32 Create new process Permitted
Process: c:\windows\system32\cmd.exe
Target: c:\test\hxdef100.exe
Cmd line: hxdef100.exe -:noservice
Rule: [App]*

8/30/2009 22:16:33 Load kernel driver Permitted
Process: c:\test\hxdef100.exe
Target: c:\windows\system32\drivers\hackerdefenderdrv100.sys
Rule: [App]*

8/30/2009 22:16:38 Create file Permitted
Process: c:\test\hxdef100.exe
Target: C:\test\hxdefdrv.sys
Rule: [File Group]All Executable Files -> [File]*; *.sys

8/30/2009 22:16:39 Create registry key Permitted
Process: c:\test\hxdef100.exe
Target: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HackerDefenderDrv100
Rule: [Registry Group]Autostarts Locations -> [Registry]HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services

8/30/2009 22:16:39 Set registry value Permitted
Process: c:\test\hxdef100.exe
Target: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HackerDefenderDrv100\ImagePath
Data: \??\C:\test\hxdefdrv.sys
Rule: [Registry Group]Autostarts Locations -> [Registry]HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\*; ImagePath

8/30/2009 22:16:39 Load kernel driver Permitted
Process: c:\test\hxdef100.exe
Target: c:\test\hxdefdrv.sys
Rule: [App]*

Playing with Hacker Defender again brings back some good memories. It was an awesome "tool" in its time and triggered serious Windows HIPS development.

[StevieO]

nick s

Hi there.

Thanx for that.

Yes indeed, Holy Father and his Hacker Defender RK's definately gave the security world a much needed big kick up the rear, and long over due too ! It's never been the same since, or ever will be either.

Regards,

S