A forum for reverse engineering, OS internals and malware analysis 

Forum for discussion about kernel-mode development.
 #23732  by Microwave89
 Sun Aug 31, 2014 1:25 am
Hi Community,

After long time experimenting and messing around with a lot of problems and bugs I would like to present my second small rootkit.
The rootkit solely consists of a kernel driver loaded at system start time.

After it has been loaded it copies itself into executable nonpaged memory, removes its path from unloaded module list and throws an error leading to unloading it.
Before unloading again, two threads are started, one of them will later set a read IRP hook on kbdclass.sys and initialize the read dispatch routines.
It also tries to detect a shutdown, so it can install itself in both registry and filesystem again. This installation is performed using a different random name for service key and file.
The service name is written into the safeboot keys too, so the driver will be loaded in safe mode too.

The service file itself is hidden by NTFS driver by misusing the C:\$Extend\$RmMetadata\ path for storing the file.
This prevents the driver from too easily being detected when not loaded / analyzed when offline.

The second thread, a worker thread, simply opens a log file in order to save the intercepted keystrokes into. The log file is hidden by ntfs.sys too.
Whether logging should be on or off can simply be controlled by using a file named "LOGGING_ON" in your C:\ root.

Issues:
- With certain keyboards you will have problems using IRP hooks, say the keyboard won't be working correctly anymore.
- I had to made a lots of compromises between not being detectable and not being removable as I'm not using sophisticated techniques such as direct registry file editing and so on.
- Some unnecessary debug output...
Hence, I cannot guarantee for the rootkit to be fully undetectable, but at least I tried so.


Best regards

Microwave89

P.S. Some code taken from KLOG rootkit by Clandestiny

P.P.S. I know that hooking is lolkit technique, but for this job I've found it more suitable than creating a fake driver and device object and building a real filter driver
Attachments
Password: phoenixKit_64
(9.59 KiB) Downloaded 196 times
 #23776  by myid
 Thu Sep 04, 2014 2:29 am
Could you release the source code? :D
I am so interested on "copies itself into executable nonpaged memory, removes its path from unloaded module list".
 #23777  by maximusdecimer
 Thu Sep 04, 2014 3:43 am
Microwave89 wrote: After it has been loaded it copies itself into executable nonpaged memory, removes its path from unloaded module list and throws an error leading to unloading it.
The logic is kind of "Hello world" DbgPrint driver. You can return 'STATUS_UNSUCCESSFUL' to make driver unload while service installation.
Correct me if I am wrong.
 #23964  by Microwave89
 Sun Sep 21, 2014 9:30 pm
Sorry for the late reply, I had some issues finding the appropriate source for the currently uploaded binary.
So I had to fix the source, and try if it can be compiled into a valid .sys file.
Finally I succeeded, here is the source code.

Added a few more tricks as well to hinder tool based offline analysis...

@TETYYSs: IRP hooks are not that often scanned (if not in atapi.sys or disk.sys or others), but almost each tool lists Filter Drivers.
Besides that, when placing an IRP hook I have to write only a few lines of code, compared with many lines of code needed for creating a fake driver, a fake device and properly attaching those to the keyboard device. So the hook approach seemed more lightweight in my opinion.


Best Regards

Microwave89
Attachments
password: none
(26.01 KiB) Downloaded 224 times
 #23970  by myid
 Mon Sep 22, 2014 5:02 pm
Microwave89 wrote:Sorry for the late reply, I had some issues finding the appropriate source for the currently uploaded binary.
So I had to fix the source, and try if it can be compiled into a valid .sys file.
Finally I succeeded, here is the source code.

Added a few more tricks as well to hinder tool based offline analysis...

@TETYYSs: IRP hooks are not that often scanned (if not in atapi.sys or disk.sys or others), but almost each tool lists Filter Drivers.
Besides that, when placing an IRP hook I have to write only a few lines of code, compared with many lines of code needed for creating a fake driver, a fake device and properly attaching those to the keyboard device. So the hook approach seemed more lightweight in my opinion.


Best Regards

Microwave89
Very nice code!
 #24775  by Microwave89
 Tue Dec 30, 2014 6:42 pm
Hi Community

I slightly improved my driver. Changes include:
- Major overhaul of function principle. It was too tedious being removable by simply crashing your PC and the NTFS metadata directory was seemingly a nice place to stay undetected even if the driver file wouldn't get deleted each time, hence, I removed driver deletion. As I also managed to "hide" from regedit and simple service scanners I also removed those deletion routines.

- Improved version of kbd hook using a "dynamical" approach which exploits the overall working principle of the keyboard stack. This also avoids failure of certain keyboards.
- Targeted removal-of-testsigning issue by writing a modified testsigning entry which is interpreted before the legitimate one. Micro$oft: Why is " 16000049" a legitimate entry, too?? (And why aren't those specific element numbers changed with each Windows release?)
- Safemode start now implemented by Group entry "System Bus Extender".


Tested & should be working on Windows 7 SP1, Win 2008 RC2, Windows 8.1 and Windows 10 Build 9901. Not tested on public TP10 and Windows 8.

Best Regards and Happy New Year

Microwave89

P.S. Source will be added soon (if commented out more).
Attachments
infected
(9.31 KiB) Downloaded 78 times
 #24788  by myid
 Thu Jan 01, 2015 6:13 am
Microwave89 wrote:Hi Community

I slightly improved my driver. Changes include:
- Major overhaul of function principle. It was too tedious being removable by simply crashing your PC and the NTFS metadata directory was seemingly a nice place to stay undetected even if the driver file wouldn't get deleted each time, hence, I removed driver deletion. As I also managed to "hide" from regedit and simple service scanners I also removed those deletion routines.

- Improved version of kbd hook using a "dynamical" approach which exploits the overall working principle of the keyboard stack. This also avoids failure of certain keyboards.
- Targeted removal-of-testsigning issue by writing a modified testsigning entry which is interpreted before the legitimate one. Micro$oft: Why is " 16000049" a legitimate entry, too?? (And why aren't those specific element numbers changed with each Windows release?)
- Safemode start now implemented by Group entry "System Bus Extender".


Tested & should be working on Windows 7 SP1, Win 2008 RC2, Windows 8.1 and Windows 10 Build 9901. Not tested on public TP10 and Windows 8.

Best Regards and Happy New Year

Microwave89

P.S. Source will be added soon (if commented out more).
I am really looking forward to your source code!
 #24851  by Munsta
 Mon Jan 05, 2015 8:41 pm
I hope you release source but I must say SafeMode survival you used isn't so kewl. See, you play alot with keyboards on this one so why not patch NTLDR/BCD (EP_X0FF should give correct file name in BCD case :)) as <XP/2003 NTLDR file was the one to be patched with 3 bytes but I never reversed/tried this on Vista+. This patch would make it impossible to use arrow keys for navigation and return (on Safe Mode option). All time favourite.
XP diff:
Code: Select all
CD 16 0F 85 09 -> CD 16 90 90 90