I asked to control which Client's module called our ALPC Server End Point.
In the ALPC Server acceptor I have Client's PID and TID.
My algorithm simply checks that client's thread start point lies inside our, not strange module...
Algorithm works fine, even for Services (after AdjustTokenPrivileges).
Currently I try to receive same information for PID==4, Kernel.
I scaned Internet and did not find information how to issue OpenProcess() or OpenThread() for kernel objects.
My attempts to play with AdjustTokenPrivileges() did not help too.
Question: Is it possible to access Module and Thread information for Kernel Objects from application layer?
How?
When you say ALPC, you mean a local version of RPC used for inter-process communication?
Assuming that's right, what I gather is that in addition or instead of the security descriptor on the endpoint, you want to make sure that only calls from your own software can make these calls?
And since the calls are being made locally, thread / process information is readily available for UM callers of your end point, so you use that to somehow verify that it was your software?
And you want to extend this scheme to KM callers?
It should first be pointed out that this kind of scheme is simple to defeat from an attacker's point of view. If you rely on the name or path of the .exe, it's very easy to change my.exe to your.exe. If you rely on a digital signature, it is also very easy to create my own certificate with your name, and add the root of its trust. If all of that fails, I can hook up a debugger and bypass your check. Protecting your software against a local attacker with admin privileges is a waste of time.
But to answer your actual question (assuming I have understood it). No, it is not possible to get equivalent information about KM RPC callers
You right, ALPC is the local version of RPC, over more, RPC is working over ALPC. Local is garanty me that PID and TID are local too and acceptable. By the way, the same information (PID+TID+other) has RPC call too. You may find about it a bit more in my blog: https://www.crfilter.com/
It's not so simple to defeat, because it's security product and obviosly it has hard anti tampering.
The problem that beside our own components we have a lot of drivers, and injections which worked in a strange context. And they use ALPC for communication.
I would like to avoid to write new driver for this purpose.
I have worked with RPC for many years. I can't remember exactly, but since the mid-1990's.
You can believe me or not about how easy or difficult a scheme like this is to defeat, but it isn't one that I would depend on, or bother to implement.
All drivers run in a single address space, and as a single security principal. Many functions are called in arbitrary thread context, and even a 'dedicated' thread doesn't run only your code. You can't implement a scheme like this for a KM RPC client, but even if you could, any other driver loaded on the same machine can simply read / write the memory used by your driver, so can get any data that you are trying to protect, or make any RPC call that your driver can - even using the same endpoint. And if necessary, 'bounce' the call through the code in your driver by calling functions compiled into it. Including any function that is 'private'.
I complitely agree with you about drivers.
But I dream that access to Kernel modules may be the same, that I realized for application. I suspected that exist AdjastPriviledge(), probably with undocumented parameters opens me access to kernel too. Unofrtunatly, no references here...
About RPC. I did not used RPC, but I reseached how it works inside. It was one of the tools which I used for controlling SCM. Windows administrative tools - SCM, Registry are achivabe via RPC. It means that stranger with admin password may achive it even remotely and, for example, stop Antivirus service...
In my blog referenced above part of this my old job.
Currently, when I saw ALPC task in my current firm, I understood that my old knowladge are applcable here too.
