64 bit systems and HIPS

[shmu26]

I did not wrote anything about file modification...I wrote that it procect perfectly according to my tests exploit svchost in memory.

fine. let it be. I will allow others who are more familiar with the kind of tests you performed to pursue this issue further.

 

[_CyberGhosT_]

I did not wrote anything about file modification...I wrote that it procect perfectly according to my tests exploit svchost in memory.

Then would you mind testing to show us proof of concept and posting the video ?

 

[ExoGen CyberSecurity]

To be able to do that you need to load the driver (with the payload) so you can have low level attacks.

 

[koletz]

Then would you mind testing to show us proof of concept and posting the video ?

No success to brake into svchost
From other things: Wallpaper was changed, I guess registry key for wallpaper is not monitored at all....need to ask or debug it

All in all classic HIPS can protect from dangerous system modifications but rather little more advanced user is needed to operate that.
Still classic good AV could be better option there for average user.
However user can scan suspicious file like CTBLocker with Jotti vir scan and Terminate it before it will do anything danger.

 

[koletz]

To be able to do that you need to load the driver (with the payload) so you can have low level attacks.

Unfortunately if any HIPS app will allow (actually user) to load malware driver than good protection is not possible in practice.
Most of good HIPS monitor loading/registering drivers, SpS firewall also do that AFAIK, Comodo, Emsisoft can do that as well.

 

[ExoGen CyberSecurity]

Yes, that's why the user needs to know what he's doing.

 

[shmu26]

View attachment 115817

No success to brake into svchost

thanks
I think we need to get @hjlbx back into the discussion for his input on this one. Clearly, an attack attempt was blocked. the question is whether it was process hollowing.

 

[Wave]

I've just read through this thread and thought I will clear everything up...

Before Windows Vista, most security companies worked with kernel-patching techniques such as SSDT (System Service Dispatch Table) hooking to deal with their self-protection mechanisms and other BB/HIPS features - they also used hooking techniques to monitor things like process creation, also. The problem with this is that if such actions were abused or went wrong, it can cause problems on the system since when a crash occurs in kernel-mode it will result in a Blue Screen of Death crash (which can then proceed to cause data-loss/corruption) and in the case of malicious software using these techniques, it can mess a lot of things up for the user. Due to this, Microsoft was not a fan of kernel-patching and they didn't want people doing this.

At the start of Windows Vista, Microsoft introduced a new feature into the OS (for x64 versions only) called PatchGuard. PatchGuard has many features within it; two of these features is to prevent the loading of unsigned device drivers and the second feature is to prevent the patching of the kernel. Microsoft already knew that a lot of software was already dependant on kernel-patching techniques and therefore they introduced an alternate feature known as kernel-mode callbacks, which they documented themselves.

Kernel-mode callbacks can be used for a lot of things and are very useful, they are essentially a method of a function being invoked by a trigger (e.g. notification of an event occurring and some callbacks support notifications before the action successfully completes and after a specific action has completed). These kernel-mode callbacks are used for a wide variety of things: process creation/termination monitoring, self-protection (will explain this further below), driver/user image loading monitoring, registry modification monitoring (and registry protection features), and so on. However, there is obviously not a callback for everything and for this reason, a lot of protection features incorporated on x86 HIPS cannot be shifted across to x64 versions with the same security level, due to the x64 limitations to kernel-mode callbacks.

On x64 systems most security products will work with kernel-mode callbacks such as PsSetCreateProcessNotifyRoutineEx, ObRegisterCallback, CmRegisterCallback/Ex, PsSetLoadImageNotifyRoutine, etc. I will explain the purposes of some of these callbacks I've just listed and the hooking alternate method which security products may use on x86/at user-mode level on x64 below.

Firstly, PsSetCreateProcessNotifyRoutineEx callback can be used for monitoring process creation/termination – however the execution can be blocked if wanted. When you start up a program the Windows Loader will do a bunch of things for its execution to memory and many APIs are called before the main function of the executable is actually called, and somewhere along this line a notification will be sent to the registered callback about the process creation/termination… Meaning the function assigned to handle the callback notifications within the loaded kernel-mode driver will be invoked (called), and so the code will be executed within this function to handle the notification. From there on, the security product can perform scans on the program trying to be started up (or which was terminated) and then decide if it wants to grant continuation to the execution or just entirely block it. I should quickly note that the code executed within this callback function is finished before the program continues execution, it essentially has the program execution “paused” until the callback has finished handling it’s Pre function (e.g. before the action has completed).

Secondly, ObRegisterCallback callback can be used for process self-protection for security products and believe it or not, the security product you are using now most likely uses it… The way it works is that when a process (or even a driver) attempts to open a handle to any process, the function which was assigned for the PreOperation of the callback registration will be invoked and from that function you can perform checks to see if the handle attempting to be opened is the same process you want protected – and if the process being protected is the target then you can simply remove all access rights from being granted which will result in Access Denied (0xC0000022) being returned to the caller process trying to open the handle. There is also a Post operation function which is called after the handle has been created, but that can just be ignored. Without a doubt, ObRegisterCallback is one of the best self-protection methods for protecting a process on x64 systems and this is why it’s used by so many popular AV/security products – however like anything, it’s not bullet-proof and if it’s not implemented properly then it can be easily bypassed from user-mode (handle duplication techniques, although if the callback is used properly then this can be patched up also and even used to protect the threads in a process too).

I won’t go into detail for the CmRegisterCallback/Ex or the PsSetLoadImageNotifyRoutine callbacks but to put simple brackets around the uses of them, the CmRegisterCallback/Ex is used for registry monitoring/protection and the latter one is for DLL/EXE loading monitoring (but from kernel-mode callbacks).

On x86 systems these callbacks can be used as well (they are for both x86 and x64 systems from Windows Vista and onwards), however on x86 systems you can freely perform real patching of the kernel techniques to make the protection much stronger (even if hooking causes instability problems, and I will explain why it’s unstable later on in this post).

Spoiler: ”My definitions of hooking”

Hooking is essentially the practise of manipulating execution flow/instructions in memory to alter the behaviour to how you want it.

To explain this better, let’s pretend we have a program called “MalwareTips.EXE” which when opened called a function called “startMT” which then launched a web browser with the URL domain set for malwaretips.com. However, if we hooked it, we can intercept the call to the startMT function so our own function (e.g. “startGoogle”) is called instead. This would be done by modifying the address of the function to our own one, meaning when the original function is called it will jump to our own one, since the address would be relocated to our own function as opposed to the original one.

In the case of SSDT (System Service Dispatch Table) hooking, we would modify the address of specific functions so it targets back to the functions in our own device drivers. SSDT is a kernel-patching technique.

IAT hooking is an example of a user-mode hooking technique. The IAT stands for the Import Address Table. To briefly explain this, IAT hooking evolves around modifying the address for the function in the IAT to the address of your own function, so when the target function is called, the address is looked up in the IAT however it points to your own function so your function ends up being called as opposed to the original one. I have written up a Malware Analysis thread on imports which goes in-depth about the IAT a bit more: https://malwaretips.com/threads/malware-analysis-2-pe-imports-static-analysis.62135/

On x86 systems instead of security products having to use kernel-mode callbacks (although they may still use them for the same things as they do on x64 as it causes them less work and is still compatible) they can hook the functions in kernel-mode (e.g. via SSDT) to have the equivalent effects of using the kernel-mode callbacks, the difference being it’s harder to bypass and more secure overall.

To explain this better, I will use self-protection (since this is one of the easiest ones for me to use to explain this): As we know from earlier, most security products work with the ObRegisterCallback callback to remove access rights to a handle being opened to the process they want to protect (e.g. the AV processes), and this can be relatively easily bypassed if the handle rights duplication wasn’t patched. However, if a kernel-mode driver is loaded, it causes less work to bypass this callback than if it was hooked via kernel-patching techniques… To bypass ObRegisterCallbacks, all the malicious rogue driver needs to do is make some calls to functions like ObOpenObjectByPointer to bypass the access checks and then just use the standard and commonly known function ZwTerminateProcess to terminate the process, or just suspend it with ZwSuspendProcess (or then go and inject into it from kernel-mode and so on), and an alternate bypass would be to just register the same callback to trick the product into thinking its own callback is still active, but it isn’t. Alternatively, with the use of kernel-patching, the functions which bypass access checks like ObOpenObjectByPointer can be hooked, meaning they cannot be used to bypass the self-protection… And all the other functions such as: ZwTerminateProcess, ZwSuspendProcess, ZwOpenProcess, ZwAllocateVirtualMemory, ZwUnmapViewOfSection, PsLookupProcessByProcessId can all be hooked too! Therefore, it’s much more bullet-proof compared to the callbacks… And for malware to bypass this, it would need access to the SSDT to replace the addresses back to the original functions so they are no longer hooked, but the security product can check if its hooks are in place (and reset them if needed) and also block drivers from being loaded via hooking ZwLoadDriver/ZwSetSystemInformation for example, which makes things much more tough. Of course patching of the kernel isn’t bullet-proof since nothing is, it’s just much tougher to bypass than the kernel-mode callbacks, thus giving the security products much more potential on x86 systems.

Since kernel-patching cannot be done on x64 systems, security products work with user-mode hooking techniques (such as IAT/EAT hooking). Normally, they use a Dynamic Link Library (DLL) which contains their code to set the hooks (and then send notifications to the GUI process via Inter-Process Communication (IPC) for showing alerts and returning back results) for their BB/HIPS/Dynamic Heuristic analysis and then they stick to kernel-mode drivers for using the callbacks for things like process/registry protection. An alternate but stealthier method they could use for user-mode hooking would be via code injection techniques, and by this I am referring to the security products injecting code into the untrusted (non-whitelisted/low reputation rated) programs without the use of additional files such as a *.DLL (and then that injected code performs the hooking and other things for monitoring).

Spoiler: ”Examples of how security products can incorporate BB/HIPS features regardless of the x64 limitations”

An example of how a security product may incorporate DLL injection protection to external processes would be for it to hook functions like: CreateRemoteThread, ZwAllocateVirtualMemory, RtlCreateUserThread, ZwCreateThreadEx, and so on… And then in the hook callback they can check the process being targeted and look at more details and decide whether to block it (e.g. returning back 0xC0000022 which stands for STATUS_ACCESS_DENIED) or allowing it via a trampoline to call the original function with the original parameters.

An example of how a security product may incorporate basic keylogger protection would be for it to hook functions like SetWindowsHookEx and SetWinEventHook. This method would not be practical for the real keyloggers so the best bet would be a driver to encrypt the keys being typed on the system (and having them decrypted for the target process the keys are being entered onto only – I believe this is what Zemana AntiLogger does for its anti-keylogging capabilities).

An example of how a security product may incorporate device driver protection (e.g. preventing them from loading/unloading without permission) could be via hooking ZwLoadDriver/ZwSetSystemInformation (this method is more undocumented and stealthier but does not always work – depends on the OS version also). To make things even better, service functions can be hooked to watch for service installations for device drivers.

An example of how a security product may incorporate real-time protection may be via a file system mini-filter driver, as opposed to hooking. File system mini-filter drivers can be used for the protection against the actual files of the security product, also!

Whereas, for things like self-protection, the callbacks can just be used as they are a better bet and more secure than the user-mode hooking. Since using a callback like ObRegisterCallbacks can protect against a handle being opened to the target processes with specific rights, this eliminates the need to patch up usage for functions like ZwTerminateProcess/ZwSuspendProcess and so on, since none of these functions can be used without a handle to use them with!

However, it is true that user-mode hooking is much more vulnerable compared to kernel-mode hooking and if someone has enough experience they can easily bypass any user-mode based hooks without a problem. All it takes is a direct system call for the NTAPI function to bypass the hook, or directly calling the instructions from the function stub itself… As an example, let’s pretend we have a security product which has hooked ZwTerminateProcess. No problem, we can use a system call to bypass this IAT/EAT hook, meaning the ZwTerminateProcess stub is never called in user-mode (which is hooked), but it transitions into kernel-mode anyway and continues the work there (since all NTAPI functions point to kernel-mode and follow on there, and WINAPI functions like TerminateProcess end up tracing back to their NTAPI functions (e.g. ZwTerminateProcess)).

All in all, security products could just bypass PatchGuard and perform kernel-patching techniques on x64 if they really wanted too, but this is highly unethical and would leave the system in a very unstable state, more vulnerable to malicious attacks. Therefore, they would never do this, and even if they did this then Microsoft would patch it, causing their products to not perform correctly until next updated again. The problem is with malware, since the attackers couldn’t care less, they can do these things and have an upper advantage, but they require lots of skill and cannot just be done by anyone (e.g. you’d need the SeDescriptorTable to be exported to access the SSDT, not to mention that these sort of exploits cost a lot of money to be produced).

At the end of the day, security products have the potential to do much more on x86 systems due to the limitations not being there, but at the same time, the limitations are put on x64 with the best interest being for the end-user… Since kernel-patching is very unstable and can cause problems, and if security products can do it easily then so can malicious software!

Now I will quickly go through some of the comments and quote them with a reply… before I sign off.

Kaspersky work with restrictions on 64-bit-systems.
I don't know what happen with other antivirus.

All security products will be limited on x64 unless they didn't use anything on the x86 version which isn't naturally supported on x64 also. This means any usage of kernel-patching on x86 won't work on x64 without very unethical practises which would leave the system unstable and more vulnerable.

Some HIPS cannot detect process hollowing on 64 bit system - like SpyShelter.

I do not know about SpyShelter specifically but it seems there are many products which cannot identify and block such activity and for this day and age you'd expect it'd be covered by at least most main security products by now... For example, all they would have to do for basic identification and protection against it is to monitor the usage of these functions: ZwUnmapViewOfSection, ZwGetContextThread, ZwSetContextThread, ZwReadVirtualMemory, ZwWriteVirtualMemory (just to name a few).

I was not talking about whether Sandboxie was penetrable (it is much more penetrable than its users think, I suppose) or not, but rather specifically about as to what purpose the hooking occurs. Do you know that in detail? So once again, if the hooking exists to prevent stuff, it's a weakness, I completely agree, especially in the case of user-mode hooks. Yet if its only purpose is to make the restricted process function at all, then removing the hooks probably won't make things easier for an attacker.

The hooking exists so when specific functions are called they become intercepted by Sandboxie and they are either completely redirected elsewhere or just blocked altogether. For example, if I tried to create a registry key and the function NtCreateKeyEx had been hooked, instead of creating the key it can redirect the key creation to another area, so the key is made but just redirected elsewhere so if it was in AutoRun, it couldn't actually start at boot as it wouldn't be in the area it was meant to be.

You're definitely right about it being a weakness, all it takes is some experience with unhooking to do some byte comparisons and perform some unhooking. However, some hooking methods are more secure than others, examples of un-secure user-mode hooks would be IAT/EAT...

So, What antivirus can we use on x64?.

Most security products from popular companies have versions supporting x64... While they will be more limited compared to their x86 version, they will still try to do the job and protection components like real-time protection will still work the same. However, for BB/HIPS, Emsisoft does a pretty good job based on the x64 limitations it has to work with. (it utilises user-mode hooking via DLL injection in case you didn't know, but most HIPS does this on x64... excluding ReHIPS of course).

@hjblx, I noticed a post you made, mentioning the processes

• lsass
  csrss
  smss
  spoolsvc

are these processes being actively abused to write code? Or is it just a potential for abuse?

On previous versions of Windows the Windows processes were much more vulnerable but Microsoft have really toughened up the security now. You cannot just enable debugging rights from a process which has been granted administrative rights and then inject into csrss.exe anymore (which used to be a method of bypassing AV self-protection since csrss.exe contains the handles to all running processes, regardless of it being a "protected process" or not).

As for Windows processes like smss.exe, they are much harder to attack than you'd think. You cannot just inject into smss.exe, it's not a Win32 application like a lot of the other Windows processes - believe it or not, it's actually a Native application (which means that only NTAPI functions can be called from it, otherwise it would result in a process crash).

what about anti-exe programs like NVT ERP and Voodoo -- they don't use hooks, so they work better?

I doubt that these Anti-Exe software will use hooks to monitor things like process creation since this will have a bigger negative impact on the system speed (and doing this is not as secure). They most likely work with kernel-mode callbacks, maybe even the one I mentioned earlier in this post (PsSetCreateProcessNotifyRoutineEx).

Unfortunately if any HIPS app will allow (actually user) to load malware driver than good protection is not possible in practice.
Most of good HIPS monitor loading/registering drivers, SpS firewall also do that AFAIK, Comodo, Emsisoft can do that as well.

What do you expect from BB/HIPS? The best bet apart from asking the user for their decision is auto-blocking if the driver is unsigned, which is what PatchGuard already does on x64, since the BB/HIPS cannot just identify if the device driver is malicious or not, down to it not relying on the standard scanning techniques (e.g. static analysis). There's only so much BB/HIPS can do and this is why it is necessary for the user to know what he/she is doing when making decisions!

Beside what other people here said, Windows 64 will always be vulnerable, the only way to fix this is to remove the ParchGuard made by Microsoft and let AV companies to "hook".
You need to create a handle and you can use it for any of the functions you want => ZwTerminateProcess, ZwSuspendProcess injection and it's over

I’m sorry but you’re wrong, x64 versions of Windows are more secure than x86, however nothing is bullet-proof. Why is x64 more secure? Better protection against rogue drivers have been incorporated and kernel-patching has been blocked off by default. If security software can perform kernel-patching then malware can rid of this protection and do it too, and if malware was faster than the AV onto the system then it can be harder to rid of also.

But what about malware bypassing PatchGuard? Easier said than done, and Microsoft do try to patch all of this up. Only the experienced people with lots of knowledge on the internals of Windows, user-mode/kernel-mode development and experience with handling exploits could begin on this properly and make some progress… For example, an old PatchGuard bypass involved a boot-up process so the work was done before PatchGuard was even loaded up, but this was patched (I believe it was used in either a sophisticated rootkit or ransomware sample a few years back).

As well as this, you cannot just open a handle to any process and then call some Native API functions and have all the work magically done for you. Most security products work with kernel-mode callbacks which block handles being opened to their process with rights which can be used for things like process termination, suspension and injection. The best bet aside from finding ways to bypass these callbacks (which can be entirely impossible from user-mode itself if the security vendor was clever and literally patched everything up) would be to find a way to somehow crash the process based on a dynamic factor (e.g. it may have a bug where depending on a file it’s scanning can cause a crash, or attempting to send data to its device driver to cause a crash).

In the case of security products using user-mode hooking to block off usage of these functions, a system call can be made to bypass the self-protection. But like I said, most popular products use kernel-mode callbacks (e.g. ObRegisterCallbacks – for both the process (creation + duplication) and the process’ threads protection), therefore what you suggested really won’t work like you’re making out.

Make the driver (.sys file), use what function you want (kill, inject and so on), load the driver (osr driver loader or something like that) and done. If you need help just check msdn.

It’s not as simple as this either. If a kernel-mode callback is being used then you’d have to bypass the access checks (even if you are executing code within kernel-mode), and this could be done via functions like ObOpenObjectByPointer. If a callback like ObRegisterCallbacks is in place, you cannot just call ZwOpenProcess and then ZwTerminateProcess and expect it to work, because it won’t, regardless of being in kernel-mode.

As for loading system drivers, on x64 a device driver is required which is not hard to get hold of but still slows down the publishing from the malware developer, and security products can do their best to prevent the loading of rogue drivers via kernel-mode callbacks which can monitor driver loading (and then they can try to unload the driver aft wards) or user-mode hooks (unless of course these are bypassed in advance).

If you’re referring to x86 then it still isn’t as simple like you said, since security products can toughen up even more and hook the functions used to bypass the access checks. Then you are dealing on a whole new level, where you’ll need to work with ntoskrnl.exe and work with finding hooked functions and sorting them out, then preventing the security product from setting the hooks back in place, and so on. It’s like teaching a Llama to drive.

/end of quote replies (they were more detailed until I got disconnected and lost a lot of my draft work, thankfully MT saved the main post parts).

I’ve tried to explain this best I can and I do apologise if anything is badly explained or typed wrong but hopefully this helped clear some things up though… So the answer to the original question is YES, security products have limitations on x64 systems for things like BB/HIPS protection.

Hope this helped and enjoy this post which is the size of a book... (hopefully it literally answered all the questions).

 

[_CyberGhosT_]

I've just read through this thread and thought I will clear everything up...

Before Windows Vista, most security companies worked with kernel-patching techniques such as SSDT (System Service Dispatch Table) hooking to deal with their self-protection mechanisms and other BB/HIPS features - they also used hooking techniques to monitor things like process creation, also. The problem with this is that if such actions were abused or went wrong, it can cause problems on the system since when a crash occurs in kernel-mode it will result in a Blue Screen of Death crash (which can then proceed to cause data-loss/corruption) and in the case of malicious software using these techniques, it can mess a lot of things up for the user. Due to this, Microsoft was not a fan of kernel-patching and they didn't want people doing this.

At the start of Windows Vista, Microsoft introduced a new feature into the OS (for x64 versions only) called PatchGuard. PatchGuard has many features within it; two of these features is to prevent the loading of unsigned device drivers and the second feature is to prevent the patching of the kernel. Microsoft already knew that a lot of software was already dependant on kernel-patching techniques and therefore they introduced an alternate feature known as kernel-mode callbacks, which they documented themselves.

Kernel-mode callbacks can be used for a lot of things and are very useful, they are essentially a method of a function being invoked by a trigger (e.g. notification of an event occurring and some callbacks support notifications before the action successfully completes and after a specific action has completed). These kernel-mode callbacks are used for a wide variety of things: process creation/termination monitoring, self-protection (will explain this further below), driver/user image loading monitoring, registry modification monitoring (and registry protection features), and so on. However, there is obviously not a callback for everything and for this reason, a lot of protection features incorporated on x86 HIPS cannot be shifted across to x64 versions with the same security level, due to the x64 limitations to kernel-mode callbacks.

On x64 systems most security products will work with kernel-mode callbacks such as PsSetCreateProcessNotifyRoutineEx, ObRegisterCallback, CmRegisterCallback/Ex, PsSetLoadImageNotifyRoutine, etc. I will explain the purposes of some of these callbacks I've just listed and the hooking alternate method which security products may use on x86/at user-mode level on x64 below.

Firstly, PsSetCreateProcessNotifyRoutineEx callback can be used for monitoring process creation/termination – however the execution can be blocked if wanted. When you start up a program the Windows Loader will do a bunch of things for its execution to memory and many APIs are called before the main function of the executable is actually called, and somewhere along this line a notification will be sent to the registered callback about the process creation/termination… Meaning the function assigned to handle the callback notifications within the loaded kernel-mode driver will be invoked (called), and so the code will be executed within this function to handle the notification. From there on, the security product can perform scans on the program trying to be started up (or which was terminated) and then decide if it wants to grant continuation to the execution or just entirely block it. I should quickly note that the code executed within this callback function is finished before the program continues execution, it essentially has the program execution “paused” until the callback has finished handling it’s Pre function (e.g. before the action has completed).

Secondly, ObRegisterCallback callback can be used for process self-protection for security products and believe it or not, the security product you are using now most likely uses it… The way it works is that when a process (or even a driver) attempts to open a handle to any process, the function which was assigned for the PreOperation of the callback registration will be invoked and from that function you can perform checks to see if the handle attempting to be opened is the same process you want protected – and if the process being protected is the target then you can simply remove all access rights from being granted which will result in Access Denied (0xC0000022) being returned to the caller process trying to open the handle. There is also a Post operation function which is called after the handle has been created, but that can just be ignored. Without a doubt, ObRegisterCallback is one of the best self-protection methods for protecting a process on x64 systems and this is why it’s used by so many popular AV/security products – however like anything, it’s not bullet-proof and if it’s not implemented properly then it can be easily bypassed from user-mode (handle duplication techniques, although if the callback is used properly then this can be patched up also and even used to protect the threads in a process too).

I won’t go into detail for the CmRegisterCallback/Ex or the PsSetLoadImageNotifyRoutine callbacks but to put simple brackets around the uses of them, the CmRegisterCallback/Ex is used for registry monitoring/protection and the latter one is for DLL/EXE loading monitoring (but from kernel-mode callbacks).

On x86 systems these callbacks can be used as well (they are for both x86 and x64 systems from Windows Vista and onwards), however on x86 systems you can freely perform real patching of the kernel techniques to make the protection much stronger (even if hooking causes instability problems, and I will explain why it’s unstable later on in this post).

Spoiler: ”My definitions of hooking”

Hooking is essentially the practise of manipulating execution flow/instructions in memory to alter the behaviour to how you want it.

To explain this better, let’s pretend we have a program called “MalwareTips.EXE” which when opened called a function called “startMT” which then launched a web browser with the URL domain set for malwaretips.com. However, if we hooked it, we can intercept the call to the startMT function so our own function (e.g. “startGoogle”) is called instead. This would be done by modifying the address of the function to our own one, meaning when the original function is called it will jump to our own one, since the address would be relocated to our own function as opposed to the original one.

In the case of SSDT (System Service Dispatch Table) hooking, we would modify the address of specific functions so it targets back to the functions in our own device drivers. SSDT is a kernel-patching technique.

IAT hooking is an example of a user-mode hooking technique. The IAT stands for the Import Address Table. To briefly explain this, IAT hooking evolves around modifying the address for the function in the IAT to the address of your own function, so when the target function is called, the address is looked up in the IAT however it points to your own function so your function ends up being called as opposed to the original one. I have written up a Malware Analysis thread on imports which goes in-depth about the IAT a bit more: https://malwaretips.com/threads/malware-analysis-2-pe-imports-static-analysis.62135/

On x86 systems instead of security products having to use kernel-mode callbacks (although they may still use them for the same things as they do on x64 as it causes them less work and is still compatible) they can hook the functions in kernel-mode (e.g. via SSDT) to have the equivalent effects of using the kernel-mode callbacks, the difference being it’s harder to bypass and more secure overall.

To explain this better, I will use self-protection (since this is one of the easiest ones for me to use to explain this): As we know from earlier, most security products work with the ObRegisterCallback callback to remove access rights to a handle being opened to the process they want to protect (e.g. the AV processes), and this can be relatively easily bypassed if the handle rights duplication wasn’t patched. However, if a kernel-mode driver is loaded, it causes less work to bypass this callback than if it was hooked via kernel-patching techniques… To bypass ObRegisterCallbacks, all the malicious rogue driver needs to do is make some calls to functions like ObOpenObjectByPointer to bypass the access checks and then just use the standard and commonly known function ZwTerminateProcess to terminate the process, or just suspend it with ZwSuspendProcess (or then go and inject into it from kernel-mode and so on), and an alternate bypass would be to just register the same callback to trick the product into thinking its own callback is still active, but it isn’t. Alternatively, with the use of kernel-patching, the functions which bypass access checks like ObOpenObjectByPointer can be hooked, meaning they cannot be used to bypass the self-protection… And all the other functions such as: ZwTerminateProcess, ZwSuspendProcess, ZwOpenProcess, ZwAllocateVirtualMemory, ZwUnmapViewOfSection, PsLookupProcessByProcessId can all be hooked too! Therefore, it’s much more bullet-proof compared to the callbacks… And for malware to bypass this, it would need access to the SSDT to replace the addresses back to the original functions so they are no longer hooked, but the security product can check if its hooks are in place (and reset them if needed) and also block drivers from being loaded via hooking ZwLoadDriver/ZwSetSystemInformation for example, which makes things much more tough. Of course patching of the kernel isn’t bullet-proof since nothing is, it’s just much tougher to bypass than the kernel-mode callbacks, thus giving the security products much more potential on x86 systems.

Since kernel-patching cannot be done on x64 systems, security products work with user-mode hooking techniques (such as IAT/EAT hooking). Normally, they use a Dynamic Link Library (DLL) which contains their code to set the hooks (and then send notifications to the GUI process via Inter-Process Communication (IPC) for showing alerts and returning back results) for their BB/HIPS/Dynamic Heuristic analysis and then they stick to kernel-mode drivers for using the callbacks for things like process/registry protection. An alternate but stealthier method they could use for user-mode hooking would be via code injection techniques, and by this I am referring to the security products injecting code into the untrusted (non-whitelisted/low reputation rated) programs without the use of additional files such as a *.DLL (and then that injected code performs the hooking and other things for monitoring).

Spoiler: ”Examples of how security products can incorporate BB/HIPS features regardless of the x64 limitations”

An example of how a security product may incorporate DLL injection protection to external processes would be for it to hook functions like: CreateRemoteThread, ZwAllocateVirtualMemory, RtlCreateUserThread, ZwCreateThreadEx, and so on… And then in the hook callback they can check the process being targeted and look at more details and decide whether to block it (e.g. returning back 0xC0000022 which stands for STATUS_ACCESS_DENIED) or allowing it via a trampoline to call the original function with the original parameters.

An example of how a security product may incorporate basic keylogger protection would be for it to hook functions like SetWindowsHookEx and SetWinEventHook. This method would not be practical for the real keyloggers so the best bet would be a driver to encrypt the keys being typed on the system (and having them decrypted for the target process the keys are being entered onto only – I believe this is what Zemana AntiLogger does for its anti-keylogging capabilities).

An example of how a security product may incorporate device driver protection (e.g. preventing them from loading/unloading without permission) could be via hooking ZwLoadDriver/ZwSetSystemInformation (this method is more undocumented and stealthier but does not always work – depends on the OS version also). To make things even better, service functions can be hooked to watch for service installations for device drivers.

An example of how a security product may incorporate real-time protection may be via a file system mini-filter driver, as opposed to hooking. File system mini-filter drivers can be used for the protection against the actual files of the security product, also!

Whereas, for things like self-protection, the callbacks can just be used as they are a better bet and more secure than the user-mode hooking. Since using a callback like ObRegisterCallbacks can protect against a handle being opened to the target processes with specific rights, this eliminates the need to patch up usage for functions like ZwTerminateProcess/ZwSuspendProcess and so on, since none of these functions can be used without a handle to use them with!

However, it is true that user-mode hooking is much more vulnerable compared to kernel-mode hooking and if someone has enough experience they can easily bypass any user-mode based hooks without a problem. All it takes is a direct system call for the NTAPI function to bypass the hook, or directly calling the instructions from the function stub itself… As an example, let’s pretend we have a security product which has hooked ZwTerminateProcess. No problem, we can use a system call to bypass this IAT/EAT hook, meaning the ZwTerminateProcess stub is never called in user-mode (which is hooked), but it transitions into kernel-mode anyway and continues the work there (since all NTAPI functions point to kernel-mode and follow on there, and WINAPI functions like TerminateProcess end up tracing back to their NTAPI functions (e.g. ZwTerminateProcess)).

All in all, security products could just bypass PatchGuard and perform kernel-patching techniques on x64 if they really wanted too, but this is highly unethical and would leave the system in a very unstable state, more vulnerable to malicious attacks. Therefore, they would never do this, and even if they did this then Microsoft would patch it, causing their products to not perform correctly until next updated again. The problem is with malware, since the attackers couldn’t care less, they can do these things and have an upper advantage, but they require lots of skill and cannot just be done by anyone (e.g. you’d need the SeDescriptorTable to be exported to access the SSDT, not to mention that these sort of exploits cost a lot of money to be produced).

At the end of the day, security products have the potential to do much more on x86 systems due to the limitations not being there, but at the same time, the limitations are put on x64 with the best interest being for the end-user… Since kernel-patching is very unstable and can cause problems, and if security products can do it easily then so can malicious software!

Now I will quickly go through some of the comments and quote them with a reply… before I sign off.


All security products will be limited on x64 unless they didn't use anything on the x86 version which isn't naturally supported on x64 also. This means any usage of kernel-patching on x86 won't work on x64 without very unethical practises which would leave the system unstable and more vulnerable.


I do not know about SpyShelter specifically but it seems there are many products which cannot identify and block such activity and for this day and age you'd expect it'd be covered by at least most main security products by now... For example, all they would have to do for basic identification and protection against it is to monitor the usage of these functions: ZwUnmapViewOfSection, ZwGetContextThread, ZwSetContextThread, ZwReadVirtualMemory, ZwWriteVirtualMemory (just to name a few).


The hooking exists so when specific functions are called they become intercepted by Sandboxie and they are either completely redirected elsewhere or just blocked altogether. For example, if I tried to create a registry key and the function NtCreateKeyEx had been hooked, instead of creating the key it can redirect the key creation to another area, so the key is made but just redirected elsewhere so if it was in AutoRun, it couldn't actually start at boot as it wouldn't be in the area it was meant to be.

You're definitely right about it being a weakness, all it takes is some experience with unhooking to do some byte comparisons and perform some unhooking. However, some hooking methods are more secure than others, examples of un-secure user-mode hooks would be IAT/EAT...


Most security products from popular companies have versions supporting x64... While they will be more limited compared to their x86 version, they will still try to do the job and protection components like real-time protection will still work the same. However, for BB/HIPS, Emsisoft does a pretty good job based on the x64 limitations it has to work with. (it utilises user-mode hooking via DLL injection in case you didn't know, but most HIPS does this on x64... excluding ReHIPS of course).


On previous versions of Windows the Windows processes were much more vulnerable but Microsoft have really toughened up the security now. You cannot just enable debugging rights from a process which has been granted administrative rights and then inject into csrss.exe anymore (which used to be a method of bypassing AV self-protection since csrss.exe contains the handles to all running processes, regardless of it being a "protected process" or not).

As for Windows processes like smss.exe, they are much harder to attack than you'd think. You cannot just inject into smss.exe, it's not a Win32 application like a lot of the other Windows processes - believe it or not, it's actually a Native application (which means that only NTAPI functions can be called from it, otherwise it would result in a process crash).


I doubt that these Anti-Exe software will use hooks to monitor things like process creation since this will have a bigger negative impact on the system speed (and doing this is not as secure). They most likely work with kernel-mode callbacks, maybe even the one I mentioned earlier in this post (PsSetCreateProcessNotifyRoutineEx).


What do you expect from BB/HIPS? The best bet apart from asking the user for their decision is auto-blocking if the driver is unsigned, which is what PatchGuard already does on x64, since the BB/HIPS cannot just identify if the device driver is malicious or not, down to it not relying on the standard scanning techniques (e.g. static analysis). There's only so much BB/HIPS can do and this is why it is necessary for the user to know what he/she is doing when making decisions!


I’m sorry but you’re wrong, x64 versions of Windows are more secure than x86, however nothing is bullet-proof. Why is x64 more secure? Better protection against rogue drivers have been incorporated and kernel-patching has been blocked off by default. If security software can perform kernel-patching then malware can rid of this protection and do it too, and if malware was faster than the AV onto the system then it can be harder to rid of also.

But what about malware bypassing PatchGuard? Easier said than done, and Microsoft do try to patch all of this up. Only the experienced people with lots of knowledge on the internals of Windows, user-mode/kernel-mode development and experience with handling exploits could begin on this properly and make some progress… For example, an old PatchGuard bypass involved a boot-up process so the work was done before PatchGuard was even loaded up, but this was patched (I believe it was used in either a sophisticated rootkit or ransomware sample a few years back).

As well as this, you cannot just open a handle to any process and then call some Native API functions and have all the work magically done for you. Most security products work with kernel-mode callbacks which block handles being opened to their process with rights which can be used for things like process termination, suspension and injection. The best bet aside from finding ways to bypass these callbacks (which can be entirely impossible from user-mode itself if the security vendor was clever and literally patched everything up) would be to find a way to somehow crash the process based on a dynamic factor (e.g. it may have a bug where depending on a file it’s scanning can cause a crash, or attempting to send data to its device driver to cause a crash).

In the case of security products using user-mode hooking to block off usage of these functions, a system call can be made to bypass the self-protection. But like I said, most popular products use kernel-mode callbacks (e.g. ObRegisterCallbacks – for both the process (creation + duplication) and the process’ threads protection), therefore what you suggested really won’t work like you’re making out.


It’s not as simple as this either. If a kernel-mode callback is being used then you’d have to bypass the access checks (even if you are executing code within kernel-mode), and this could be done via functions like ObOpenObjectByPointer. If a callback like ObRegisterCallbacks is in place, you cannot just call ZwOpenProcess and then ZwTerminateProcess and expect it to work, because it won’t, regardless of being in kernel-mode.

As for loading system drivers, on x64 a device driver is required which is not hard to get hold of but still slows down the publishing from the malware developer, and security products can do their best to prevent the loading of rogue drivers via kernel-mode callbacks which can monitor driver loading (and then they can try to unload the driver aft wards) or user-mode hooks (unless of course these are bypassed in advance).

If you’re referring to x86 then it still isn’t as simple like you said, since security products can toughen up even more and hook the functions used to bypass the access checks. Then you are dealing on a whole new level, where you’ll need to work with ntoskrnl.exe and work with finding hooked functions and sorting them out, then preventing the security product from setting the hooks back in place, and so on. It’s like teaching a Llama to drive.

/end of quote replies (they were more detailed until I got disconnected and lost a lot of my draft work, thankfully MT saved the main post parts).

I’ve tried to explain this best I can and I do apologise if anything is badly explained or typed wrong but hopefully this helped clear some things up though… So the answer to the original question is YES, security products have limitations on x64 systems for things like BB/HIPS protection.

Hope this helped and enjoy this post which is the size of a book... (hopefully it literally answered all the questions).

Amazingly accurate, this needs read carefully.
Thank you @Wave for this high quality reply

 

[ExoGen CyberSecurity]

The "NTAPI function to bypass the hook" is not new.

 

[DardiM]

I've just read through this thread and thought I will clear everything up...

Before Windows Vista, most security companies worked with kernel-patching techniques such as SSDT (System Service Dispatch Table) hooking to deal with their self-protection mechanisms and other BB/HIPS features - they also used hooking techniques to monitor things like process creation, also. The problem with this is that if such actions were abused or went wrong, it can cause problems on the system since when a crash occurs in kernel-mode it will result in a Blue Screen of Death crash (which can then proceed to cause data-loss/corruption) and in the case of malicious software using these techniques, it can mess a lot of things up for the user. Due to this, Microsoft was not a fan of kernel-patching and they didn't want people doing this.

At the start of Windows Vista, Microsoft introduced a new feature into the OS (for x64 versions only) called PatchGuard. PatchGuard has many features within it; two of these features is to prevent the loading of unsigned device drivers and the second feature is to prevent the patching of the kernel. Microsoft already knew that a lot of software was already dependant on kernel-patching techniques and therefore they introduced an alternate feature known as kernel-mode callbacks, which they documented themselves.

Kernel-mode callbacks can be used for a lot of things and are very useful, they are essentially a method of a function being invoked by a trigger (e.g. notification of an event occurring and some callbacks support notifications before the action successfully completes and after a specific action has completed). These kernel-mode callbacks are used for a wide variety of things: process creation/termination monitoring, self-protection (will explain this further below), driver/user image loading monitoring, registry modification monitoring (and registry protection features), and so on. However, there is obviously not a callback for everything and for this reason, a lot of protection features incorporated on x86 HIPS cannot be shifted across to x64 versions with the same security level, due to the x64 limitations to kernel-mode callbacks.

On x64 systems most security products will work with kernel-mode callbacks such as PsSetCreateProcessNotifyRoutineEx, ObRegisterCallback, CmRegisterCallback/Ex, PsSetLoadImageNotifyRoutine, etc. I will explain the purposes of some of these callbacks I've just listed and the hooking alternate method which security products may use on x86/at user-mode level on x64 below.

Firstly, PsSetCreateProcessNotifyRoutineEx callback can be used for monitoring process creation/termination – however the execution can be blocked if wanted. When you start up a program the Windows Loader will do a bunch of things for its execution to memory and many APIs are called before the main function of the executable is actually called, and somewhere along this line a notification will be sent to the registered callback about the process creation/termination… Meaning the function assigned to handle the callback notifications within the loaded kernel-mode driver will be invoked (called), and so the code will be executed within this function to handle the notification. From there on, the security product can perform scans on the program trying to be started up (or which was terminated) and then decide if it wants to grant continuation to the execution or just entirely block it. I should quickly note that the code executed within this callback function is finished before the program continues execution, it essentially has the program execution “paused” until the callback has finished handling it’s Pre function (e.g. before the action has completed).

Secondly, ObRegisterCallback callback can be used for process self-protection for security products and believe it or not, the security product you are using now most likely uses it… The way it works is that when a process (or even a driver) attempts to open a handle to any process, the function which was assigned for the PreOperation of the callback registration will be invoked and from that function you can perform checks to see if the handle attempting to be opened is the same process you want protected – and if the process being protected is the target then you can simply remove all access rights from being granted which will result in Access Denied (0xC0000022) being returned to the caller process trying to open the handle. There is also a Post operation function which is called after the handle has been created, but that can just be ignored. Without a doubt, ObRegisterCallback is one of the best self-protection methods for protecting a process on x64 systems and this is why it’s used by so many popular AV/security products – however like anything, it’s not bullet-proof and if it’s not implemented properly then it can be easily bypassed from user-mode (handle duplication techniques, although if the callback is used properly then this can be patched up also and even used to protect the threads in a process too).

I won’t go into detail for the CmRegisterCallback/Ex or the PsSetLoadImageNotifyRoutine callbacks but to put simple brackets around the uses of them, the CmRegisterCallback/Ex is used for registry monitoring/protection and the latter one is for DLL/EXE loading monitoring (but from kernel-mode callbacks).

On x86 systems these callbacks can be used as well (they are for both x86 and x64 systems from Windows Vista and onwards), however on x86 systems you can freely perform real patching of the kernel techniques to make the protection much stronger (even if hooking causes instability problems, and I will explain why it’s unstable later on in this post).

Spoiler: ”My definitions of hooking”

Hooking is essentially the practise of manipulating execution flow/instructions in memory to alter the behaviour to how you want it.

To explain this better, let’s pretend we have a program called “MalwareTips.EXE” which when opened called a function called “startMT” which then launched a web browser with the URL domain set for malwaretips.com. However, if we hooked it, we can intercept the call to the startMT function so our own function (e.g. “startGoogle”) is called instead. This would be done by modifying the address of the function to our own one, meaning when the original function is called it will jump to our own one, since the address would be relocated to our own function as opposed to the original one.

In the case of SSDT (System Service Dispatch Table) hooking, we would modify the address of specific functions so it targets back to the functions in our own device drivers. SSDT is a kernel-patching technique.

IAT hooking is an example of a user-mode hooking technique. The IAT stands for the Import Address Table. To briefly explain this, IAT hooking evolves around modifying the address for the function in the IAT to the address of your own function, so when the target function is called, the address is looked up in the IAT however it points to your own function so your function ends up being called as opposed to the original one. I have written up a Malware Analysis thread on imports which goes in-depth about the IAT a bit more: https://malwaretips.com/threads/malware-analysis-2-pe-imports-static-analysis.62135/

On x86 systems instead of security products having to use kernel-mode callbacks (although they may still use them for the same things as they do on x64 as it causes them less work and is still compatible) they can hook the functions in kernel-mode (e.g. via SSDT) to have the equivalent effects of using the kernel-mode callbacks, the difference being it’s harder to bypass and more secure overall.

To explain this better, I will use self-protection (since this is one of the easiest ones for me to use to explain this): As we know from earlier, most security products work with the ObRegisterCallback callback to remove access rights to a handle being opened to the process they want to protect (e.g. the AV processes), and this can be relatively easily bypassed if the handle rights duplication wasn’t patched. However, if a kernel-mode driver is loaded, it causes less work to bypass this callback than if it was hooked via kernel-patching techniques… To bypass ObRegisterCallbacks, all the malicious rogue driver needs to do is make some calls to functions like ObOpenObjectByPointer to bypass the access checks and then just use the standard and commonly known function ZwTerminateProcess to terminate the process, or just suspend it with ZwSuspendProcess (or then go and inject into it from kernel-mode and so on), and an alternate bypass would be to just register the same callback to trick the product into thinking its own callback is still active, but it isn’t. Alternatively, with the use of kernel-patching, the functions which bypass access checks like ObOpenObjectByPointer can be hooked, meaning they cannot be used to bypass the self-protection… And all the other functions such as: ZwTerminateProcess, ZwSuspendProcess, ZwOpenProcess, ZwAllocateVirtualMemory, ZwUnmapViewOfSection, PsLookupProcessByProcessId can all be hooked too! Therefore, it’s much more bullet-proof compared to the callbacks… And for malware to bypass this, it would need access to the SSDT to replace the addresses back to the original functions so they are no longer hooked, but the security product can check if its hooks are in place (and reset them if needed) and also block drivers from being loaded via hooking ZwLoadDriver/ZwSetSystemInformation for example, which makes things much more tough. Of course patching of the kernel isn’t bullet-proof since nothing is, it’s just much tougher to bypass than the kernel-mode callbacks, thus giving the security products much more potential on x86 systems.

Since kernel-patching cannot be done on x64 systems, security products work with user-mode hooking techniques (such as IAT/EAT hooking). Normally, they use a Dynamic Link Library (DLL) which contains their code to set the hooks (and then send notifications to the GUI process via Inter-Process Communication (IPC) for showing alerts and returning back results) for their BB/HIPS/Dynamic Heuristic analysis and then they stick to kernel-mode drivers for using the callbacks for things like process/registry protection. An alternate but stealthier method they could use for user-mode hooking would be via code injection techniques, and by this I am referring to the security products injecting code into the untrusted (non-whitelisted/low reputation rated) programs without the use of additional files such as a *.DLL (and then that injected code performs the hooking and other things for monitoring).

Spoiler: ”Examples of how security products can incorporate BB/HIPS features regardless of the x64 limitations”

An example of how a security product may incorporate DLL injection protection to external processes would be for it to hook functions like: CreateRemoteThread, ZwAllocateVirtualMemory, RtlCreateUserThread, ZwCreateThreadEx, and so on… And then in the hook callback they can check the process being targeted and look at more details and decide whether to block it (e.g. returning back 0xC0000022 which stands for STATUS_ACCESS_DENIED) or allowing it via a trampoline to call the original function with the original parameters.

An example of how a security product may incorporate basic keylogger protection would be for it to hook functions like SetWindowsHookEx and SetWinEventHook. This method would not be practical for the real keyloggers so the best bet would be a driver to encrypt the keys being typed on the system (and having them decrypted for the target process the keys are being entered onto only – I believe this is what Zemana AntiLogger does for its anti-keylogging capabilities).

An example of how a security product may incorporate device driver protection (e.g. preventing them from loading/unloading without permission) could be via hooking ZwLoadDriver/ZwSetSystemInformation (this method is more undocumented and stealthier but does not always work – depends on the OS version also). To make things even better, service functions can be hooked to watch for service installations for device drivers.

An example of how a security product may incorporate real-time protection may be via a file system mini-filter driver, as opposed to hooking. File system mini-filter drivers can be used for the protection against the actual files of the security product, also!

Whereas, for things like self-protection, the callbacks can just be used as they are a better bet and more secure than the user-mode hooking. Since using a callback like ObRegisterCallbacks can protect against a handle being opened to the target processes with specific rights, this eliminates the need to patch up usage for functions like ZwTerminateProcess/ZwSuspendProcess and so on, since none of these functions can be used without a handle to use them with!

However, it is true that user-mode hooking is much more vulnerable compared to kernel-mode hooking and if someone has enough experience they can easily bypass any user-mode based hooks without a problem. All it takes is a direct system call for the NTAPI function to bypass the hook, or directly calling the instructions from the function stub itself… As an example, let’s pretend we have a security product which has hooked ZwTerminateProcess. No problem, we can use a system call to bypass this IAT/EAT hook, meaning the ZwTerminateProcess stub is never called in user-mode (which is hooked), but it transitions into kernel-mode anyway and continues the work there (since all NTAPI functions point to kernel-mode and follow on there, and WINAPI functions like TerminateProcess end up tracing back to their NTAPI functions (e.g. ZwTerminateProcess)).

All in all, security products could just bypass PatchGuard and perform kernel-patching techniques on x64 if they really wanted too, but this is highly unethical and would leave the system in a very unstable state, more vulnerable to malicious attacks. Therefore, they would never do this, and even if they did this then Microsoft would patch it, causing their products to not perform correctly until next updated again. The problem is with malware, since the attackers couldn’t care less, they can do these things and have an upper advantage, but they require lots of skill and cannot just be done by anyone (e.g. you’d need the SeDescriptorTable to be exported to access the SSDT, not to mention that these sort of exploits cost a lot of money to be produced).

At the end of the day, security products have the potential to do much more on x86 systems due to the limitations not being there, but at the same time, the limitations are put on x64 with the best interest being for the end-user… Since kernel-patching is very unstable and can cause problems, and if security products can do it easily then so can malicious software!

Now I will quickly go through some of the comments and quote them with a reply… before I sign off.


All security products will be limited on x64 unless they didn't use anything on the x86 version which isn't naturally supported on x64 also. This means any usage of kernel-patching on x86 won't work on x64 without very unethical practises which would leave the system unstable and more vulnerable.


I do not know about SpyShelter specifically but it seems there are many products which cannot identify and block such activity and for this day and age you'd expect it'd be covered by at least most main security products by now... For example, all they would have to do for basic identification and protection against it is to monitor the usage of these functions: ZwUnmapViewOfSection, ZwGetContextThread, ZwSetContextThread, ZwReadVirtualMemory, ZwWriteVirtualMemory (just to name a few).


The hooking exists so when specific functions are called they become intercepted by Sandboxie and they are either completely redirected elsewhere or just blocked altogether. For example, if I tried to create a registry key and the function NtCreateKeyEx had been hooked, instead of creating the key it can redirect the key creation to another area, so the key is made but just redirected elsewhere so if it was in AutoRun, it couldn't actually start at boot as it wouldn't be in the area it was meant to be.

You're definitely right about it being a weakness, all it takes is some experience with unhooking to do some byte comparisons and perform some unhooking. However, some hooking methods are more secure than others, examples of un-secure user-mode hooks would be IAT/EAT...


Most security products from popular companies have versions supporting x64... While they will be more limited compared to their x86 version, they will still try to do the job and protection components like real-time protection will still work the same. However, for BB/HIPS, Emsisoft does a pretty good job based on the x64 limitations it has to work with. (it utilises user-mode hooking via DLL injection in case you didn't know, but most HIPS does this on x64... excluding ReHIPS of course).


On previous versions of Windows the Windows processes were much more vulnerable but Microsoft have really toughened up the security now. You cannot just enable debugging rights from a process which has been granted administrative rights and then inject into csrss.exe anymore (which used to be a method of bypassing AV self-protection since csrss.exe contains the handles to all running processes, regardless of it being a "protected process" or not).

As for Windows processes like smss.exe, they are much harder to attack than you'd think. You cannot just inject into smss.exe, it's not a Win32 application like a lot of the other Windows processes - believe it or not, it's actually a Native application (which means that only NTAPI functions can be called from it, otherwise it would result in a process crash).


I doubt that these Anti-Exe software will use hooks to monitor things like process creation since this will have a bigger negative impact on the system speed (and doing this is not as secure). They most likely work with kernel-mode callbacks, maybe even the one I mentioned earlier in this post (PsSetCreateProcessNotifyRoutineEx).


What do you expect from BB/HIPS? The best bet apart from asking the user for their decision is auto-blocking if the driver is unsigned, which is what PatchGuard already does on x64, since the BB/HIPS cannot just identify if the device driver is malicious or not, down to it not relying on the standard scanning techniques (e.g. static analysis). There's only so much BB/HIPS can do and this is why it is necessary for the user to know what he/she is doing when making decisions!


I’m sorry but you’re wrong, x64 versions of Windows are more secure than x86, however nothing is bullet-proof. Why is x64 more secure? Better protection against rogue drivers have been incorporated and kernel-patching has been blocked off by default. If security software can perform kernel-patching then malware can rid of this protection and do it too, and if malware was faster than the AV onto the system then it can be harder to rid of also.

But what about malware bypassing PatchGuard? Easier said than done, and Microsoft do try to patch all of this up. Only the experienced people with lots of knowledge on the internals of Windows, user-mode/kernel-mode development and experience with handling exploits could begin on this properly and make some progress… For example, an old PatchGuard bypass involved a boot-up process so the work was done before PatchGuard was even loaded up, but this was patched (I believe it was used in either a sophisticated rootkit or ransomware sample a few years back).

As well as this, you cannot just open a handle to any process and then call some Native API functions and have all the work magically done for you. Most security products work with kernel-mode callbacks which block handles being opened to their process with rights which can be used for things like process termination, suspension and injection. The best bet aside from finding ways to bypass these callbacks (which can be entirely impossible from user-mode itself if the security vendor was clever and literally patched everything up) would be to find a way to somehow crash the process based on a dynamic factor (e.g. it may have a bug where depending on a file it’s scanning can cause a crash, or attempting to send data to its device driver to cause a crash).

In the case of security products using user-mode hooking to block off usage of these functions, a system call can be made to bypass the self-protection. But like I said, most popular products use kernel-mode callbacks (e.g. ObRegisterCallbacks – for both the process (creation + duplication) and the process’ threads protection), therefore what you suggested really won’t work like you’re making out.


It’s not as simple as this either. If a kernel-mode callback is being used then you’d have to bypass the access checks (even if you are executing code within kernel-mode), and this could be done via functions like ObOpenObjectByPointer. If a callback like ObRegisterCallbacks is in place, you cannot just call ZwOpenProcess and then ZwTerminateProcess and expect it to work, because it won’t, regardless of being in kernel-mode.

As for loading system drivers, on x64 a device driver is required which is not hard to get hold of but still slows down the publishing from the malware developer, and security products can do their best to prevent the loading of rogue drivers via kernel-mode callbacks which can monitor driver loading (and then they can try to unload the driver aft wards) or user-mode hooks (unless of course these are bypassed in advance).

If you’re referring to x86 then it still isn’t as simple like you said, since security products can toughen up even more and hook the functions used to bypass the access checks. Then you are dealing on a whole new level, where you’ll need to work with ntoskrnl.exe and work with finding hooked functions and sorting them out, then preventing the security product from setting the hooks back in place, and so on. It’s like teaching a Llama to drive.

/end of quote replies (they were more detailed until I got disconnected and lost a lot of my draft work, thankfully MT saved the main post parts).

I’ve tried to explain this best I can and I do apologise if anything is badly explained or typed wrong but hopefully this helped clear some things up though… So the answer to the original question is YES, security products have limitations on x64 systems for things like BB/HIPS protection.

Hope this helped and enjoy this post which is the size of a book... (hopefully it literally answered all the questions).

Thanks a lot for your post (I liked it , clear, complete)

 

[hjlbx]

View attachment 115821

No success to brake into svchost
From other things: Wallpaper was changed, I guess registry key for wallpaper is not monitored at all....need to ask or debug it

All in all classic HIPS can protect from dangerous system modifications but rather little more advanced user is needed to operate that.
Still classic good AV could be better option there for average user.
However user can scan suspicious file like CTBLocker with Jotti vir scan and Terminate it before it will do anything danger.

That alert is for code injection into svchost - and not for hollow process.

Code injection and hollow process are two different things. In a nutshell, hollow process is when a child process is launched in a suspended state by a parent process, and then the parent process replaces the child process with a different process.

SpyShelter HIPS does not detect nor prevent hollow process. You can confirm this directly with developer - Datpol. It is known issue on 64 bit system.

 

[hjlbx]

Do you have even single proof of that?
I have other opinion information basing on my debugging knowledge, for example based on CTBLocker it perfectly detect attempt scvhost modification (tested in Ask User mode)
So this ransomware can "only" compromise users files
(But user can protect his any Files with spyshelter using option Settings - Security - User defined protected files)
+ change wallpaper (nothing really dangerous) then after blocking all actions virus crashes

Point is that it detect attempt to hollowing svchost similar to for example ESET do.

I have to make a correction. Early CTBLocker did not use hollow process; it injected code to svchost. Hollow process and code injection are not the same.

Later CTBLocker hollows Windows Explorer.

There are so many variants of CTBLocker I can't keep track of them.

You will get an alert for the Explorer modification, but if you select Block the hollow process will still occur.

 

[LabZero]

Thanks @Wave!

This thread has become very technical, and I believe that at this point, some specific considerations about the hooking.

Hooking is basically the ability to intercept the execution of a particular function: in this way it is possible to trace the calls to certain functions by collecting the values of the parameters to each call, but also change the behavior of these functions.

For a more in-depth analysis, you can find a lot of info freely available on the web but these are very complex information that require years of studies and analysis but in this case it is quite simple.

Why user mode hooking is more vulnerable compared to kernel mode ?

Advaced mode [ON]

Well, a fairly simple technique ( but greatly effective ) for the realization of Hooking in User Mode and how it is easily vulnerable.

If, for example, we have a original function : the function which I want to intercept the execution and a custom function : the function that is called in the moment in which it detects a call to the original function. So when the system is calling the original function, the hooking redirects the flow of the program to the custom function. (changing for example the behavior of the Windows API).

Simply by using the CopyMemory function (Delphi), it is raised an exception in correspondence of the execution of the CopyMemory.
Then VirtualProtect (Win32 API) change the security level in a region of memory pages residents in the memory space of the calling process. In particular, all of the adjacent pages present in that memory region must belong to the same region of reserved memory that is allocated through a call to the win32 API VirtualAlloc or VirtuaAllocEx with the parameter MEM_RESERVE.
It is not valid for a call to VirtualProtect inherent memory pages that are adjacent to covering the overall regions of reserved memory in different ways (i.e. allocated by different calls to the Win32 api VirtualAlloc or VirtualAllocEx using the parameter MEM_RESERVE).
Across the region, the affected memory should be allocated from the same call to the VirtualAlloc or VirtualAllocEx.
At this point, it is easy to modify a function intercepting the execution and redirecting the program flow to our custom function.

The game is done.

 

[_CyberGhosT_]

Thanks @Wave!

This thread has become very technical, and I believe that at this point, some specific considerations about the hooking.

Hooking is basically the ability to intercept the execution of a particular function: in this way it is possible to trace the calls to certain functions by collecting the values of the parameters to each call, but also change the behavior of these functions.

For a more in-depth analysis, you can find a lot of info freely available on the web but these are very complex information that require years of studies and analysis but in this case it is quite simple.

Why user mode hooking is more vulnerable compared to kernel mode ?

Advaced mode [ON]

Well, a fairly simple technique ( but greatly effective ) for the realization of Hooking in User Mode and how it is easily vulnerable.

If, for example, we have a original function : the function which I want to intercept the execution and a custom function : the function that is called in the moment in which it detects a call to the original function. So when the system is calling the original function, the hooking redirects the flow of the program to the custom function. (changing for example the behavior of the Windows API).

Simply by using the CopyMemory function (Delphi), it is raised an exception in correspondence of the execution of the CopyMemory.
Then VirtualProtect (Win32 API) change the security level in a region of memory pages residents in the memory space of the calling process. In particular, all of the adjacent pages present in that memory region must belong to the same region of reserved memory that is allocated through a call to the win32 API VirtualAlloc or VirtuaAllocEx with the parameter MEM_RESERVE.
It is not valid for a call to VirtualProtect inherent memory pages that are adjacent to covering the overall regions of reserved memory in different ways (i.e. allocated by different calls to the Win32 api VirtualAlloc or VirtualAllocEx using the parameter MEM_RESERVE).
Across the region, the affected memory should be allocated from the same call to the VirtualAlloc or VirtualAllocEx.
At this point, it is easy to modify a function intercepting the execution and redirecting the program flow to our custom function.

The game is done.

Another well formed reply, you make that look too easy LabZero
Thank you my friend.

 

[Deleted member 178]

@Wave long time i didn't read such a good and detailed post. Thank you.

Most security products from popular companies have versions supporting x64... While they will be more limited compared to their x86 version, they will still try to do the job and protection components like real-time protection will still work the same.

indeed, some very potent softs like Defensewall (awesome product) were abandoned , the author saying an x64 version can't protect the system properly.

Then when came Win8 with the improved Patchguard, most kernel-hooking softs , lost their efficiency for a while (Sandboxie lost its "experimental feature" which as quite good; Zemana AL couldn't even fully protect an x64 OS, etc...).

it becomes worst in Win10, most of those kernel-hooking based softs had to find a workaround to protect efficiently on x64 system. Workarounds giving them some hard time and need several fixes.

However, for BB/HIPS, Emsisoft does a pretty good job based on the x64 limitations it has to work with. (it utilises user-mode hooking via DLL injection in case you didn't know, but most HIPS does this on x64... excluding ReHIPS of course).

yes Emsisoft did well, one of the Best BB for me , however i jumped right away on the ReHIPS wagon, as i see it as the best approach in term of protection and stability. Not saying it has (HIPS + Sandboxing) what i waited for years, filling the vacuum left by Defensewall on x64 compatible.

 

[ExoGen CyberSecurity]

There is a document about PatchGuard bypass, it's a little old but still relevant.

Library for kernel and user mode splicing for Windows (x86 and x64)

 

[shmu26]

That alert is for code injection into svchost - and not for hollow process.

will ReHIPS block code injection and hollow process?

 

[_CyberGhosT_]

will ReHIPS block code injection and hollow process?

Very good question lets hope lord @Umbra can answer this

 

[Deleted member 178]

@shmu26 From ReHIPS devs :

Separate desktops concept was introduced to avoid some attacks like DLL injection or printscreening.

what is Hollow Processing

What is Process Hollowing?
Process hollowing is a technique used by some malware in which a legitimate process is loaded on the system solely to act as a container for hostile code. At launch, the legitimate code is deallocated and replaced with malicious code. The advantage is that this helps the process hide amongst normal processes better. If you inspect the process and its imports using conventional tools, they all look legit. The PEB is untouched, but the actual code and data of the process have been changed.

If you have a bit of experience with ReHIPS, you should observed that it ask for all processes modifications , Parent and Childrens.