Do I need to configure token privileges to successfully call CreateRemoteThread?

Question

I am developing a debugging tool for my application to help me diagnose deadlocks. The application runs on my client machines, so I expect a wide range of operating systems, security policies, etc.

The technique I use is to implement a function in the target application that generates stack traces for all threads along with other diagnostic data. This is then written to a memory mapped file. I also create a utility application that is used to start creating a diagnostic report, and then reads it from a memory mapped file.

Since it is expected that the target application will be dead, the utility program cannot send him a message to start the diagnostic collection. Instead, I use CreateRemoteThread so that I can get a live thread to get the job done.

Note that this is different from DLL injection methods, which typically use LoadLibrary as the thread stream for CreateRemoteThread . My proc stream is the entry point to the target application. Therefore, I do not need to call WriteProcessMemory .

I implemented this and it works well in my test environments. According to the CreateRemoteThread documentation, I need a process handle with the following permissions:

PROCESS_CREATE_THREAD , PROCESS_QUERY_INFORMATION , PROCESS_VM_OPERATION , PROCESS_VM_WRITE and PROCESS_VM_READ

So, I passed these flags when calling OpenProcess .

Now, finally, to my question: for what privileges do I need my token to defeat the OpenProcess call?

In my test environment (Windows 7, UAC enabled, user admin) I had no problems with the default token only. I saw a different code example that gets SE_DEBUG_NAME privilege before calling OpenProcess . I assume that this is necessary for WriteProcessMemory when executing the DLL injection and that I do not need this privilege. Are there any scenarios in which I will need to configure my token privileges?

I definitely don’t know about Windows security, so I would be very grateful for the wise words from anyone who does this!

Answer 1

Typically, if the target process is running in the same context (that is, the same user) as the debugger, privileges are not required for OpenProcess or CreateRemoteThread.

If the target process is started as another user or if the process permissions have been changed, you may need to enable SE_DEBUG_NAME before calling OpenProcess. This privilege allows you to open any process, bypassing the security permissions assigned to the process. (This is similar to how backup / restore privileges circumvent security permissions for files and directories.)

Some applications change their own process permissions so that, for example, the user cannot use the task manager to kill the process. In this case, this is your own code, so this is not a problem. Basically, for some other programs (for example, antivirus software) you can modify permissions for your process, but I never heard about it, so you probably don't need to worry about enabling SE_DEBUG_NAME.