
Originally Posted by
nullptr_t
[SIZE=3
This requires no interfering with the target process from user mode; no opening handles, or any other sketchy stuff besides the ProcessId lookup (which can be done from kernel mode with PsSetLoadImageNotifyCallback if needed, or by just manually typing it to the controlling program.)
Actually, you do open a handle known as a "kernel handle". Kernel Object Handle Table is what would keep track of your kernel-level object such as process / driver.
As I assume you utilize KeStackAttackProcess for your memory rundown technique? Also, your device has something called a "symbolic link" aswell, it's known as a "symbolic link" for that aswell.
"
A symbolic link is a file-system object that points to another file system object. The object being pointed to is called the target. Symbolic links are transparent to users; the links appear as normal files or directories, and can be acted upon by the user or application in exactly the same manner."
VAC can also access the handle table if wanting to, it's tedious and easy to look up any created symbolic links too.
Also VAC can if it wants, find the ObjectName of the device. It can also detect your driver via NtQuerySymbolicLinkObject function to retrieve your handle and target driver name.
So I mean, you're just throwing tantrums and guesses on what VAC is able to detect or not. User-mode rights doesn't essentially mean zero rights. VAC is also able to retrieve your device via Object Security Descriptor for each object created as all objects has one.
I mean, there are tons of attack vectors, a driver is sticky without protection.