In this post, I will be looking at a new exploit that leverages a weakness in Microsoft Windows Text Services Framework to launch a child process that allows for the escalation of privileges. I will give a brief overview of what the Text Services Framework service does, what the exploit is, and how it could be used. Then, I will go into more detail about how to run the exploit and different methods that can be used for detection and mitigation of the exploit.
Microsoft Windows Text Services Framework is, simply put, a framework that allows enabled applications to receive text input without the application having to be aware of the details of the text input device. This could be a keyboard, speech, or a handwriting tool, for instance.
The Text Services Framework is run by the ctfmon.exe process.
CTFTool is a custom exploit that has been made to exploit a weakness in the Text Services Framework (TSF) that allows a user to spawn a process launched under a different security context (e.g. NT AuthoritySYSTEM or another user who is running a process). These processes must connect to TSF to be able to be exploited.
CTFTool is located on GitHub here.
The exploit is in its early days and a little unreliable, but I would be surprised if this isn’t developed further to make it more stable.
If an attacker was able to get CTFTool onto an enterprise network, it would be easily possible for them to compromise accounts. I will quickly detail a few possible ways they could do this:
There are some prerequisites that CTFTool.exe requires which are currently undocumented:
When I was initially looking at this, I didn’t quite understand how the different exploit paths worked, but soon figured it out. The author of this exploit, Tavis Ormandy, included two easy-to-run exploits. So far, I have only managed to actually get one working. You can execute the exploit itself on your own, but it’s a little more complicated.
The exploit using consent.exe to elevate to NT AUTHORITYSystem was the first exploit script I tried to run. It was very simple to do using the readme.md on the Github Repository.
The steps required to execute are:
Connect Scan Script .scriptsctf-consent-system.ctf
Once you have run the last script command, the system will copy a dll to C:TEMPWindows and then self-launch the command prompt as an administrator. The UAC consent.exe dialog box will then prompt you to enter the password of an Administrator. The payload is subsequently executed, which waits for consent.exe to connect itself to the CTF Port and then runs the exploit against it.
Once the payload has run, you should be presented with a new command prompt window. To check whether the exploit has worked, type in “whoami” to see who it is running as, and it shows NT AUTHORITYSystem!
To execute the payload yourself, there are a couple of steps you need to perform. The instant benefits I could see of doing this is to compromise other users who have sessions on the machine. This is the scarier approach for enterprise IT as you could compromise administrator accounts, which could be highly privileged depending on their setup if you were able to do this.
In my lab, I set up a quick and easy Domain Admin account to act as an admin and a user account who will be the one to run the exploit to get a command prompt window as the Domain Admin. So here, I started on some simple things that a desktop support engineer may do to help an end user. Install software, change network settings, etc. to see what exe’s may actually connect to the CFT Client.
The first thing I attempted was an Office install (and modify and uninstall) and found that the OfficeClickToRun.exe shown below using the scan command was there and was running as the PROD_DA account after being elevated.
To then execute the attack on the OfficeClickToRun.exe, you need to connect to the thread specifically. I found the easiest way to do this was to use the WAIT command which will wait for an EXE to be in the scan list and connect to that thread (you may notice the thread in Figure 5 is different from Figure 6. That is because I ran this again to get the screenshots). Given I’m using Windows 10, I used the Windows 10 exploit script to run the exploit on the OfficeClickToRun.exe process.
Once the exploit was run, a command prompt window popped up. Using “whoami”, I checked the Window and it was indeed running as the PROD_DA account from my lab.
To check the permissions were there, I used the DIR command to connect to the C drive of the LAB’s domain controller.
There were multiple other ways I found to do this using common support methods (e.g. elevating to change network settings exposed dllhost.exe and computer management also worked exposing mmc.exe for compromise).
Detections for this are not particularly simple, as an attacker could do this for almost any process. To do so, turn on Process Creation Auditing for all clients. The process creation events would ideally be forwarded to a SIEM or to a central server using Windows Event Forwarding for interrogation. From indications we have seen so far, look for events that match the below criteria:
Using the Windows 10 Exploit Protection Settings, it is possible to audit two of the specific attacks – consent.exe and logonUI.exe specifically. To do this, follow the below steps:
To then look at the logs for this, you must use the Security-Mitigation logs which are located in Event Viewer at Applications and Services Logs/Microsoft/Windows/Security-Mitigations. Log Name is: Microsoft-Windows-Security-Mitigations/Kernel Mode
I would then do the same setup for the LogonUI.exe to detect the exploit that opens up a command prompt window on the lock screen as system. I didn’t actually manage to get this one working as it would just crash the LogonUI, but I am sure it will work in future releases of the tool!
Although not official, there are some things you can do to mitigate this from working in your environment at the time of writing (Release V1.3).
You can specifically choose to mitigate the LogonUI.exe and Consent.exe exploits by blocking them from spawning child processes using the same method for detection as shown previously by unticking the box for “Audit Only”. I have found in practice this doesn’t leave any trace when execution fails though, so you lose the ability to detect that someone is trying to exploit the system. To deploy these in an enterprise environment, you can use Group Policy as documented here. Caution: If you choose to do this, please ensure you test it fully before deploying, just in case it affects client computers in any way!
I have found this to be simple to mitigate with Windows Defender and Smart Screen, but as for the general exploit (if it has gotten around defender and smart screen), it was only detectable by looking at cmd.exe processes that were not spawned from explorer.exe, which would require setup of a SIEM tool or native Windows Event Forwarding (WEF) to then be interrogated.
Start a Free Stealthbits Trial!
No risk. No obligation.