Vendors using kernel-mode software should be taking precautions to keep their work safe against external usage.
For example, when handling IOCTL implementation, the device driver should always check what the caller process is by calling IoGetCurrentProcess routine and ensuring it's their own process via reliable authentication check techniques. For example, file-name, file-path, digital certificate and even custom byte pattern signatures embedded into the user-mode components which communicate with that kernel-mode component. For optimization purposes, the kernel-mode software can intercept process creation via PsSetCreateProcessNotifyRoutineEx and wait until a new process spawns with the process name of their user-mode image which will communicate with the kernel-mode software, and then perform checks and keep track of the right Process Identifiers for their own processes.
This would allow them to only allow requests to their kernel-mode software via techniques like IOCTL for processes with the right Process ID and would be strong against impersonation bypasses. They should also use IoCreateDeviceSecure instead of using the usually used IoCreateDevice routine and restrict IOCTL usage with their symbolic link to elevated processes only as another precaution.
Alternative methods would be secure named pipes implementation from kernel-mode (you can still create named pipes in a normal kernel-mode device driver via IoCreateFile which NtCreateNamedPipeFile calls) or secure ports IPC implementation. And enforce administrator rights to use the IPC method at-least as a minimum and still verify the requester....
All memory allocation should be done with the required and minimal memory protection. I see a lot of vendors setting NonPagedPool in kernel-mode for a unicode-encoded buffer, like what? You don't need executable rights for that for god sake, you only need RW minimum. I doubt Process Hacker does this one though, it's just something I noticed recently with some vendors products. Microsoft themselves even recommend to use NonPagedPoolNx now, they even flag warnings sometimes with WDK. For backwards compatibility when working on a driver for Windows 7 and below, just use a macro. Problem solved.
I don't see any verification of the caller making the IOCTL request in the above source code, unless this is outdated or I am blind and haven't realized where the authentication check is being performed (which is unlikely).
At-least if NtOpenProcess or NtTerminateProcess is hooked in user-mode you could do IOCTL to the device driver with KPH_OPENPROCESS and KPH_TERMINATEPROCESS IOCTL codes instead of bothering to do a direct system call yourself.
I just checked it. They're using the same lousy kprocesshacker.sys. I happen to use Process Hacker because it offers a more convenient networking infos than Process Explorer - which buries the networking infos on a tab buried in a sub-GUI.