Saturday, 26 October 2013

Kernel Drivers: Hiding True Identity

Hi,

Today I will be discussing a method to hide true identity of a Kernel Mode Driver. This method is not well known but exploited by ZeroAccess Trojan quite well. I will add my own "unique" touch to it in order to make it more effective. This is not for malicious purposes but for security researchers.
This trick does not only useful for Security Developer(s) but also may be somewhat use to Driver Developer especially because to test & run drivers quickly rather than getting it test signed or disabling Driver Signature Enforcement.

***NOTE*** This blog\post is only a method and does not involve code. 

ZeroAccess Trojan, a notorious trojan responsible for thousands of infection world wide, uses various methods in order to stay resilient and it does by placing Kernel detours on the system using a driver (*.SYS) . Normally, all we need to do is startup the driver using Windows API on x86 systems as there is no sort of protection which guards the Kernel except maybe few AV which again can be bypassed using custom load technique, however this trick would fail miserably on x64 Systems as PatchGuard protects the Kernel from loading "rouge" drivers, but circumventing this is pretty much easy.

If you analyse ZeroAccess Trojan you will see that on x86 systems it get's a driver and copies it to the ZeroAccess Trojan's installation directory then replaces the bytes\information with it's own rootkit code, this is a excellent technique - but this technique is never needed to load the driver on x86 as it has no protection on the kernel but just as a safety precaution to avoid prying eyes of the host user. This same method can be used to bypass patch guard on but to maintain more safety, you need to add garbage code EOF as if you write something on the EOF nothing can be destroyed or corrupted therefore it can bypass few run-time checks and in addition you can add a lot of NOPS on front of your driver in order to confuse and reduce the detection ratio. Then before hand feel free to use a crypter on it inorder to encrypt the file and DON'T ever pack the Driver as most AV solutions use their heuristic behaviour detection in order to detect this as most Malware tend to pack it. If you really want to pack it do not use famous packers such as UPX as these are mostly used by Malware authors.

Next, if your application is in sandbox and to bypass the sandbox, you can perform a far jump into 0x33:[$+5], this would simply change the code next code's into 0x64 code then re-form a far jump into 0x23:[$+5], this would change the following code back into 0x86. I realised the potential for this trick when trying to test a anti-debug trick I created, I tested this on VirusTotal and it is unable to scan\emulate the file in order to give me results as multi code-segment changes messed up the most AV sandboxes and Online File Scanning service. This is one of the brilliant tricks to implement in order to bypass most if not all proactives.

To conclude, there is many many more methods to bypass these security solutions and other protection software.
Keep Looking

Until Next Time,

1 comment: