But, in Windows 10 64-bit the hooking in the kernel is well protected by the PatchGuard, so the vendors avoid this by using other well-documented techniques, like for example mini-filter drivers.
Mini-filter device drivers interact with the Filter Manager - fltMgr.sys. They allow you to filter file system events because the Filter Manager will invoke registered callback routines at the appropriate time. When registering with the Filter Manager, you provide registration information which specifies which file system events you want to intercept - specified through an IRP Major Function code - and whether you want to intercept the event for Pre and/or Post operations.
The Windows kernel officially supports filtering of process creation and termination requests, registry requests and object manager requests. All of these can be done from a driver using the normal kernel-mode driver framework model, so a file system mini-filter isn't mandatory for anything other than file system filtering. Commonly, people tend to use a file system mini-filter driver and include everything into it, because it's usually convenient for management to have all of the filtering in one place... and when recorded information needs to be referenced by code belonging to filtering of something else in the future, it's simpler if everything is under one driver because it prevents the need for additional overhead by implementing communication channels between multiple drivers.
PatchGuard does not prevent patching of the Windows kernel. PatchGuard cannot stop you from doing it. PatchGuard is running at the same privilege level as the culprit it wants to stop, which already means it is game over. Anything PatchGuard can do, someone with the same privilege level can undo. Microsoft already knew this and it is why PatchGuard mainly survived on obfuscation to try and thwart reverse engineers from reverse engineering it and then defeating it... and as they likely would have expected, it didn't work, because it was closely examined and then documented by third-party reverse engineers and security researchers... and subsequently bypassed.
PatchGuard is a code integrity feature targeting the Windows kernel. It doesn't stop anything. It detects things which it is programmed to detect using various algorithms and when it detects something it doesn't like, it forces a BSOD. The BSOD will be carried out by the
KeBugCheckEx kernel routine, which was actually hooked once upon a time to block the forced BSOD and act as a PatchGuard bypass.
"Some kernel registered callbacks to be notified of process creating, images loaded, … " are probably still used.
Sandboxie still does this but that isn't the unsafe part about it. In fact, that is the good part about it. It's a good thing that Sandboxie does this over alternative routes because it is a documented and officially supported thing to do.
I am not sure about "direct hooks on kernel objects".
Technically, they can still do this, but it depends on what they are doing with the kernel objects - PatchGuard can detect DKOM but not every use of it. It's a technique called Direct Kernel Object Manipulation (DKOM) and it works by modifying kernel objects - it's a rootkit-like technique from the early-on rootkit books and was commonly abused to hide processes, registry keys and files.
Anyway, is the widely accepted opinion about using by Sandboxie the rootkit methods really true in the year 2019?
Yes, because it isn't just about the Windows kernel.
My main issue with Sandboxie is:
a). It messes with the memory of other people's processes. We're not talking about one or two chances. We're talking of non-stop extreme manipulation.
b). Everything happens on the real host environment.
Sometimes, you have no viable alternate to API hooking. API hooking is fine when it is done by people who know what they are doing in a responsible manner. Sandboxie have no choice other than to do what they are doing unless they use the design model of ReHIPS (which doesn't have to hook as much) or Microsoft's sandbox technology (which is powered by work of Intel and AMD). However, due to Sandboxie's chosen design, they get carried away with the hooking and end up causing more harm than good.
If you use Sandboxie to isolate your web browser then you've tarnished several important layers of defense for anti-exploit on your web browser, for example. Realistically, those anti-exploit features you've just tarnished are more important than Sandboxie in the real world, and they genuinely get on the nerves of threat actors. There's a good reason that the level of browser escapes have plummeted over the last decade - secure guidelines being followed, safer client-side scripting run-times and exploit mitigations like ASLR, DEP, Control Flow Guard, blocking of Win32k system calls, etc.
You cannot properly defend against a culrpit which is running at the same privilege level as you. Sandboxie's design is security through obscurity for a large portion of it nowadays.
But, in Windows 10 64-bit the hooking in the kernel is well protected by the PatchGuard
If you're wondering about some other AV vendors as well... some of them evade PatchGuard by doing what Microsoft is doing but differently.
For AMD:
1. Use the CPUID instruction from the IA-32 (AMD64 has backwards compatibility, Intel and AMD made a deal when AMD invented AMD64 which allows AMD to support IA-32 and Intel to use AMD64) instruction set with the code 0x80000001 and then check the ECX register.
2. Use the Virtual Machine Control Register MSR to check whether the SVMDIS bit is clear - if it is set, then AMD SVM is disabled.
3. You can do an extended check depending on #1 and #2 to see if AMD SVM is unlockable via the BIOS or if it requires an administrator key to remove the disable.
4. Use the Extended Feature Enable Register to set the SVME bit on every processor which is going to be included for virtualization.
5. Setup the Virtual Machine Control Block (VMCB) for the host and guest state.
6. Use the VMRUN instruction from the AMD64 instruction set to enter the guest environment and when an exception occurs for the host to become involved again, a #VMEXIT will occur.
That is roughly all you have to do.
Reference:
https://www.amd.com/system/files/TechDocs/24593.pdf (See Chapter 15).
#VMEXIT can cause a lot of system overhead when it is happening a lot so a better design would be implementing Nested Page Tables (NPT) (also referred to as Rapid Virtualization Indexing) which is Second Level Address Translation. Intel have Extended Page Tables (EPT) as their Second Level Address Translation feature.
Anyway, the guest state will mimic the host state, meaning when you enter the guest environment... it's the same as the host environment. The difference is that you're in full control of the guest environment which is based on the host environment. With this design model, you can push the end user into a virtual environment which will appear and behave the same as the host environment to them, and they won't even be aware unless you notify them (or unless they are technical enough and paranoid enough to be running tests, which can also be subverted). It's a simultaneous transition.
You don't have to mimic the host environment, but this is the model that sandbox systems from vendors like Comodo use as well. This is why Comodo can patch the Windows kernel on x64 systems. Kaspersky uses the hyper-visor for some things as well, probably for banking protection.
Microsoft's technology works a bit differently. Hyper-V doesn't mimic the host environment. It sets up a guest environment with it's own resources as well. VMware works like Hyper-V in the sense that it doesn't mimic the host environment either - it uses its own OS media source and reserves host resources for the guest based on the configuration. Same for VirtualBox but VirtualBox also supports a compatibility software-level emulation mode for those who do not have supported hardware to use the virtualization features which will use Ring 1 to host the guest OS kernel (since on Windows at least, Ring 1 is unused and thus available).
Hyper-visors aren't bullet-proof either though. Nothing is 100%.
For example, VMware's backdoor channel can be exploited to leak host information (e.g. the clipboard of the host) if the guest kernel is subverted and also from user-mode of Guest Additions is installed. But, it's all still better than Sandboxie.
