ROOTKIT TEST PART A

Rootkit prevention and detection



A) Detection and prevention protection:


Also for prevention (service/driver instalation, phisical memory access) see the part 1 (behaviour tests).

Here we use Agony rootkit to hide file, registry key and active process.
We also use a commercial program designed to hide files and folders and various tools for hiding processes.
We use an hooker tool to hook the SSDT, and a "kernel toolbox" for the hidden driver installation test.


1) hidden file detection/prevention:


a1) with Agony:






We hide a zip file (Crypter.zip)

Detection with McAfee Rootkit detective:



Detection with Rootkit Revealer:





a) detection: F1/F2


b) prevention: P1/P2 (prevents service/driver installation).


a2) with a commercial program:

Here we choose to hide coma backdoor filles (original and encrypted ones).


a) detection:

b) prevention: Not rated (safe and legal program)

a3) Hidden driver test: P1/P2


a) detection: P1/P2


b) prevention: P1/P2

2) hidden registry key detection/prevention:

Here we create a hidden service that we call attila (related to SnifferDoor), and we hide the registry key related to this service with Oddysee rootkit.

Hidden registry detection:

Hidden service detection:

a) detection: F1/F2 (the registry scan based black list is ineffective in this case).


b) prevention: P1/P2 (since the PDM can detect and block the service from being registred and the driver from being loaded, we consider that the result is "Pass").


3) hidden process detection/prevention:


a1) We hide a screenshot tool (Savescreen) with Agony Rootkit:

Detection with IceSword:




Detection via GDI table:



Detection of image files taken by Savescreen:





a) detection: P1/P2



b) prevention: P1/P2



a2) with a command line tool designed to hide processes via Direct Kernel Object Manipulation method)¹: we hide srip32.exe for our example:

Detection via IceSword:

a) detection: P1/P2



b) prevention: P1/P2 (service/driver installation detected).

a3) with a task process hider tool:

In this example we choose to hide a backdoor (kotilla.exe):



Detection of the hidden process by IceSword:

a) detection: P1/P2


b) prevention: P1/P2 (service/driver installation detected).


a4) with another task process hider tool:

Here we choose to hide a simple sniffer:

a) detection: P1/P2


b) prevention: P1/P2 (service/driver installation detected).

4) Hooking methods:

a) SSDT hooking:

This is here a classical method used by many rootkits.
Most anti-rootkits display SSDT hooks, legitimate (security programs), or suspicious (malwares).

Via a kernel driver, we hook an important function of the SSDT: ZwQuerySystemInformation

This is an imprtant function, used to list processes for instance.

NB: It's important to note that this function is already hooked by Kaspersky driver as it is displayed by SEEM and RKU the next image:

Via this test, this function will be "re-hooked" by our driver.


a) detection: F1/F2: the anti-rootkit module of Kaspersky is different from other antivirus beta tools: this is not a scanner or a kind of task manager, so it does not display hooked functions.

Here's the detection with IceSword, Seem, RKU and RHA

b) prevention: P1/P2 (service/driver installation detection).


b) IRP Hooking

NB.Credit goes to "Cardmagic" for the method, and to "Ivan the Mad" for the Poc.












a) detection: F1/F2

b) prevention: P1/P2







 

5) Physical memory access with IDTGuard: Passed (see also part 1): P1/P2



With the PDM enabled, the tool can't have access to physical memory:





6) Rootkit removal

Test file: we choose an automated rootkit (malware) with "vicious" features:

As it is shown in the newt image, IE and svchost.exe are hidden.
Our goal is to forget totally our knowledge and experience, and to take the point of view of a normal user.



For this test we create a full system database (files, registry, ads etc).
After the removal procedure, we compare the new visible files (the rootkit should not be active, and its files are not hidden anymore) with the previous hidden files (while rootkit is active): by this way, we can test the ability of the removal procedure in:

-deactivation of the rootkit (quarantine, termination, service stooping, SSDT unhooking, files renaming etc...it depends on each product): is it effective or not?

-files and registry: are hidden objects completly removed?

-ease of use: does the procedure requires user's intervention and skill?





We run the rootkit with KAV protection disabled (only avp.exe service is active).

We enable the full protection after 10 minutes:

the anti-rootkit proactive module (seted for all tests from 20 minutes to 1 minute in the configuration) does its job: the hidden objects are detected:

svchost.exe:

We click on the quarantine button for all hidden objects, but it does not work: hidden objects are still hidden!
Even if the quarantine area displays "svchost.exe", it appears difficult for the normal user to known if it is the legitimate process or malicious one...

As there is frequent pop up alert about the hidden objects, then we click on the terminate button (unappropriately translated as "quit" in french): nothing happens.
Hidden objects are still hidden (verfication by anti-rootkits like IceSword).

Finally we run a scan, but here again the scanner does not see the hidden items (driver, process):

We have put into quarantine IEXPLORE.EXE and svchost.exe, and our computer does not work properly after the reboot.
We need to restore these objects.

Conclusion: the removal procedure is ineffective for this example of rootkit.
The quarantine is an interesting option for "classical malwares", but rootkits are a particular class of "malwares".

Put into quarantine a hidden object is like put in jail the invisible man: the first step for rootkit removal is to make "visible the invisible" by an hunding procedure wich restores to its original state the changes done by the rootkit: that can be done by stopping the service, unhooking the modified SSDT functions etc...

As it is illustrated by this example, the removal procedure of rootkits is not as ideal as tries to show the marketing (even legitimate) of Kaspersky partners and resellers like the pdf "PDM vs Rootkits" here.

But this marketing is normal: not excessive and pretentious.
Unlike Symantec which claims to be the best AV in rootkit removal.
We suggest to Symantec to respect their consummers First by providing antivirus which install and uninstall PROPERLY...
Then after, we'll be able to talk about the wonderfull, merveilleuse, wunderbar Norton's rootkit removal features...

For comparison, we have done the test with McAfee Rootkit Detective: the results are not perfect, but much more effective and exhaustive.

We launch the scanner which detects all hidden objects (processes, service/drivers, registry keys, files) and SSDT modifications (hooks).
As we take the point of view of normal users, we choose to check all boxes, IEXPLORE.EXE and svchost.exe included!







At the reboot, most rootkits objects are renamed and removed (reg keys), except a few files and one key which must be deleted manually.






But we need to restore our test environement (svchost.exe and IEXPLORE.EXE are unfunctional).


We have shown that automated rootkit removal is not as simple without a minimum of user's knowledge and interaction.



1. For technical info about this method, there is this pdf paper of Jamie Butler.

NEXT