Hi guys,
This one is just for fun and for me learning to know Windows a little better:
I finally managed to create a working userland rootkit based on AppInit_DLLs DLL injection.
First, after launching an arbitrary x86/x64 executable which must be linked statically against kernel32.dll and user32.dll (only a few exes are not) the suitable rootkit image is injected into the target process.
After injection of the image both the ".text" and following section of in memory mapped image are copied into dynamically allocated RWX memory and a few well known APIs in ntdll.dll of the target process are patched to point to the hooked functions stored in newly allocated memory.
If these actions were completed successfully three (or six in case of x64 image) required registry entries regarding AppInit_DLLs are (re)written.
If the rootkit has been compiled into the x64 version, the image name in LDR_DATA_TABLE_ENTRY structure of the DLL
is patched to OLEAUT32.dll and structure's image size is changed to size of OLEAUT32.dll, so no evidence would be given if someone tried to enumerate the unloaded modules in e.g. WinDbg.
Now, the DllMain routine returns deliberately a "false" which again leads to unloading the DLL from target process.
This ensures that tools like Process Hacker or Process Explorer can't show my DLL, as it doesn't exist anymore.
The main part is coded in C with some dummy inline assembler in it (in case of 32bit) and is based on "Agony ring 0 rootkit".
The hooking code was taken from libsplice_um and was fairly shortened (as long as the NTAPI stubs look all the same there is no need for a fully featured disasm engine).
The code for walking a linked list in order to find my DLL's LDR_DATA_TABLE_ENTRY is based on an example in Hoglund and Butlers "Rootkits Subverting the Windows Kernel".
The rootkit was tested on Win7SP1 and Win8.1 and prevents all applications it has been injected into from displaying all files, registry keys, registry values and processes
containing 'blacklisted' strings such as "r00tk!t" and so on as long as the application uses the usermode NTAPI or a higher API (I cannot block if the application executes a direct "syscall" instruction with a suitable number)
However, kernelland detectors don't use userland NTAPI for obvious reasons and can't be fooled that easily.
As this could be particulary dangerous for the rootkit, any touching of ".sys" files is prohibited by a further hook, namely of NtCreateFile.
Since I have noticed the ability of some ARKs to read the raw registry values, I also have blacklisted "*\\software" as well as "*\\system".
GMER was still able to display the hidden files by performing raw file operations by communicating with the internal filesystem drivers, so I had to refuse the sending of a specific IOCTL (0x006D0008) via NtDeviceIoControlFile API.
Tools like HookShark64 or WinDbg don't need to load a driver to be able to display differences between a function of ntdll.dll image in memory and on disk.
By denying any access to files containing "ntdll.dll" these tools have no longer a base for comparison and are unable to scan for hooks and patches.
Additionally, in order to prevent a (deliberate) overwriting of the AppInit_DLLs values these values are rewritten almost each time NtCreateFile is called by any patched process.
I followed up by creating a simple installer which cloaks as keygen for Adobe. This installer simply decompresses the x64 and x86 images, gathers SeDebugPrivilege and injects the x64 image into all x64 processes unless they are marked as protected ones.
Since the "keygen" would need to write-access the Adobe directory in C:\Program Files (x86), it requires obviously to be launched with full rights... ;)
Since I read something of filename spoofing in Windows two days ago, I wanted to give it a try by using the Right to Left Override unicode character.
So I ended up with having created a binary with a textfile icon called "shipment_fed{RLO char}.txt.Exe" which reads as "shipment_fedexE.txt" even if file extensions are shown but is executed if double-clicked though.
However, this has nothing to do with the installer function itself, but is funny though.
So, despite the skiddy look of ring 3 "rootkits" I was surprised how much was possible to do while still maintaining a quite small file and avoiding both the need of code signing and messing around with patchguard.
The rootkit is currently far away from being "perfect", but at least it's running more or less reliable for now.
Of course there might be even more possible while remaining in ring 3, but I would need lots of time and knowledge I currently not have.
And I know that kernelmode rootkits are being much more powerful, however I would need even more time and knowledge for successfully bypassing the need of patching patchguard, by perfectly exploiting the filter driver and callback routines concept of Microsoft.
If anyone is interested in the complete source code - no problem at all. Just tell me.
Please find the binary attached. (I hope it's ok if the zip is not secured by a password)
Best Regards
Microwave89
This one is just for fun and for me learning to know Windows a little better:
I finally managed to create a working userland rootkit based on AppInit_DLLs DLL injection.
First, after launching an arbitrary x86/x64 executable which must be linked statically against kernel32.dll and user32.dll (only a few exes are not) the suitable rootkit image is injected into the target process.
After injection of the image both the ".text" and following section of in memory mapped image are copied into dynamically allocated RWX memory and a few well known APIs in ntdll.dll of the target process are patched to point to the hooked functions stored in newly allocated memory.
If these actions were completed successfully three (or six in case of x64 image) required registry entries regarding AppInit_DLLs are (re)written.
If the rootkit has been compiled into the x64 version, the image name in LDR_DATA_TABLE_ENTRY structure of the DLL
is patched to OLEAUT32.dll and structure's image size is changed to size of OLEAUT32.dll, so no evidence would be given if someone tried to enumerate the unloaded modules in e.g. WinDbg.
Now, the DllMain routine returns deliberately a "false" which again leads to unloading the DLL from target process.
This ensures that tools like Process Hacker or Process Explorer can't show my DLL, as it doesn't exist anymore.
The main part is coded in C with some dummy inline assembler in it (in case of 32bit) and is based on "Agony ring 0 rootkit".
The hooking code was taken from libsplice_um and was fairly shortened (as long as the NTAPI stubs look all the same there is no need for a fully featured disasm engine).
The code for walking a linked list in order to find my DLL's LDR_DATA_TABLE_ENTRY is based on an example in Hoglund and Butlers "Rootkits Subverting the Windows Kernel".
The rootkit was tested on Win7SP1 and Win8.1 and prevents all applications it has been injected into from displaying all files, registry keys, registry values and processes
containing 'blacklisted' strings such as "r00tk!t" and so on as long as the application uses the usermode NTAPI or a higher API (I cannot block if the application executes a direct "syscall" instruction with a suitable number)
However, kernelland detectors don't use userland NTAPI for obvious reasons and can't be fooled that easily.
As this could be particulary dangerous for the rootkit, any touching of ".sys" files is prohibited by a further hook, namely of NtCreateFile.
Since I have noticed the ability of some ARKs to read the raw registry values, I also have blacklisted "*\\software" as well as "*\\system".
GMER was still able to display the hidden files by performing raw file operations by communicating with the internal filesystem drivers, so I had to refuse the sending of a specific IOCTL (0x006D0008) via NtDeviceIoControlFile API.
Tools like HookShark64 or WinDbg don't need to load a driver to be able to display differences between a function of ntdll.dll image in memory and on disk.
By denying any access to files containing "ntdll.dll" these tools have no longer a base for comparison and are unable to scan for hooks and patches.
Additionally, in order to prevent a (deliberate) overwriting of the AppInit_DLLs values these values are rewritten almost each time NtCreateFile is called by any patched process.
I followed up by creating a simple installer which cloaks as keygen for Adobe. This installer simply decompresses the x64 and x86 images, gathers SeDebugPrivilege and injects the x64 image into all x64 processes unless they are marked as protected ones.
Since the "keygen" would need to write-access the Adobe directory in C:\Program Files (x86), it requires obviously to be launched with full rights... ;)
Since I read something of filename spoofing in Windows two days ago, I wanted to give it a try by using the Right to Left Override unicode character.
So I ended up with having created a binary with a textfile icon called "shipment_fed{RLO char}.txt.Exe" which reads as "shipment_fedexE.txt" even if file extensions are shown but is executed if double-clicked though.
However, this has nothing to do with the installer function itself, but is funny though.
So, despite the skiddy look of ring 3 "rootkits" I was surprised how much was possible to do while still maintaining a quite small file and avoiding both the need of code signing and messing around with patchguard.
The rootkit is currently far away from being "perfect", but at least it's running more or less reliable for now.
Of course there might be even more possible while remaining in ring 3, but I would need lots of time and knowledge I currently not have.
And I know that kernelmode rootkits are being much more powerful, however I would need even more time and knowledge for successfully bypassing the need of patching patchguard, by perfectly exploiting the filter driver and callback routines concept of Microsoft.
If anyone is interested in the complete source code - no problem at all. Just tell me.
Please find the binary attached. (I hope it's ok if the zip is not secured by a password)
Best Regards
Microwave89
Attachments
no password
(18.02 KiB) Downloaded 71 times
(18.02 KiB) Downloaded 71 times
