Overview

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.

What is the Text Services Framework?

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.

What is CTFTool?

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.

How can CTFTool.exe be used in the real world?

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:

• An attacker could use a standard user’s logon to escalate to SYSTEM privileges on a workstation and use this workstation to pivot for lateral movement or upload tools to the system for further compromise.
• If an attacker found a system that multiple users are logged into, they could use CTFTool to open a child process as a different user account which, in most cases, would lead to the attacker gaining more privileges and access to file shares which may contain sensitive data, etc.

Prerequisites needed to run CTFTool

There are some prerequisites that CTFTool.exe requires which are currently undocumented:

• Visual C++ Redistributable x86 (Issue already open which will hopefully result in the DLL’s required to be added to CTFTool.exe itself)
• A language pack that uses an IME (I have used Japanese)
• Disable Windows Defender Realtime Protection and scans
• Do not update to the August Updates (https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-1162)

Running the Exploit in Various Ways

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.

UAC Secure Desktop and Consent.exe

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!

Executing the payload

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

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:

• Event ID = 4688
• Process Information/New Process Name = C:Windowssystem32cmd.exe
• Process Information/Creator Process Name != C:WindowsExplorer.exe

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:

1. Click in the start menu search box and type “Exploit Protection” and click on the option that comes up
2. Click on “Program Settings”
3. Click “Add program to customize”
4. Type in consent.exe
5. Scroll down to “Do not allow child processes”
6. Check Override settings
7. Flip the switch to turn it on
8. Click Audit Only
9. Click Apply

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!

Mitigations

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).

1. Ensure your system has the August updates on it. This is currently a breaking change and stops the tool from running its critical scan command and the exploit from running.
2. Ensure Windows Defender Realtime protection is on.
3. Ensure that any AntiVirus on the machine is up to date.
   • Ideally, use a NextGen AV to get more information on processes and how it came to be there. This will greatly help with Incident Response.
4. Only use a language that does not require this interaction with CTF. I have only managed to confirm it doesn’t work with a default image that only has the English (United Kingdom) language on it.
   • We tried this also with a US image and didn’t have success with this mitigation, so if you are attempting this, make sure to test this yourself.
5. Windows Defender SmartScreen is configurable from group policy to stop users bypassing the warning, which effectively blocks the software from running.

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!

Conclusion

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.