Explain the purpose of SeDebugPrivilege for the DLL injection?
In terms of DLL injection, what's the use of SeDebugPrivilege? A blog that I recently read had some lines - Privileges are an important native security control in Windows. As the name suggests, privileges grant rights for accounts to perform privileged operations within the operating system: debugging, impersonation, etc. Defenders who understand privileges and how attackers may abuse them can enhance their detection and attack surface reduction capabilities.
In this blog post, we give a brief introduction to privileges and share our recommendations for detecting and preventing their abuse. We walk through the key concepts a defender needs to understand to protect privileges, and provide an example on how to improve security through auditing, detection strategies, and targeted privilege removal.
From the MSDN documentation for OpenProcess
dwDesiredAccess [in]
The access to the process object. This access right is checked against
the security descriptor for the process. This parameter can be
one or more of the process access rights.
If the caller has enabled the SeDebugPrivilege privilege, therequested access is granted regardless of the contents of the security
descriptor.
And then if you look at the process access rights documentation you'll see that one of the access rights you can request is PROCESS_VM_WRITE which is needed to call WriteProcessMemory.
Again from the MSDN documentation for CreateRemoteThread
A common use of this function is to inject a thread into a process that is being debugged to issue a break. However, this use is not recommended, because the extra thread is confusing to the person debugging the application and there are several side effects to using this technique:
It converts single-threaded applications into multithreaded applications. It changes the timing and memory layout of the process. It results in a call to the entry point of each DLL in the process. Another common use of this function is to inject a thread into a process to query heap or other process information. This can cause the same side effects mentioned in the previous paragraph. Also, the application can deadlock if the thread attempts to obtain ownership of locks that another thread is using. Even though the documentation recommends against it. I've most often seen CreateRemoteThread used in debuggers or other types of profiling/api logging applications.