By Nik Seetharaman
An old Microsoft tool is able to be weaponized in several ways and reportedly used by at least one nation state actor. I explore ways for defenders to detect it’s abuse.
As I was perusing MITRE’s ATT&CK framework the other day to learn about techniques I’m less familiar with, I came across the ambiguous-sounding CMSTP (T1191 in ATT&CK) which MITRE states can be used for UAC Bypass and code execution. Being that it’s also allegedly been used by a nation-state actor recently, I wanted to research potential detection strategies and wrap my head around possible blind spots.
Initial research yielded that CMSTP is an old remote access configuration tool that comes with a config wizard called the Config Manager Admin Kit. This wizard spits out, among other things, an INF configuration file that’s able to be weaponized along various dimensions.
Invoking the weaponized INF with CMSTP results in the ability to run both arbitrary scripts (local and remote) and bypass User Account Control to elevate security contexts from medium to high integrity.
Being that CMSTP is a legitimate signed Microsoft binary living in the System32 directory, the implication is an attacker could land on a system, utilize CMSTP to bypass poorly configured application whitelisting, and obtain elevated command shells or pull down arbitrary code remotely via WEBDAV.
For more background reading, Oddvar Moe wrote up some great research into how CMSTP works, which gave me a good baseline to build on.
This post will explore various considerations in trying to detect CMSTP exploitation along these various axes using Windows Sysinternals’ Sysmon tool configured with Swift on Security’s baseline configuration, found here.
CMSTP Abuse Vectors
I investigated detection strategies for three different categories of CMSTP abuse, all of which involve arbitrary code execution and two of which allow for code execution with UAC bypass:
- Invoking weaponized .INF setup files to run local or remote .SCT scripts containing malicious VBScript or JScript code.
- Invoking weaponized .INF files to run local executables while enabling UAC bypass / elevating integrity levels, allowing for spinup of elevated command shells.
- Direct utilization of the COM interfaces that CMSTP hooks into allowing for (slightly) stealthier UAC bypass.
Let’s dive into the detections considerations for each of these methods.
Method 1 – INF-SCT Launch
Bohops wrote a great article with some background and context around INF-SCT fetch and execute techniques here.
The gist is that the ‘UnRegisterOCXSection’ in the malicious INF file can be modified to invoke scrobj.dll and have it execute either a local or remotely fetched .SCT script containing malicious VBScript or JScript code.
Let’s take a look at an example (T1191.inf) pulled from the Atomic Red Team repo that maps to the CMSTP Mitre Technique (T1191):
Executing the command “cmstp.exe /s t1191.inf” will pull down and execute the SCT script located at https://raw.githubusercontent.com/redcanaryco/atomic-red-team/master/atomics/T1191/T1191.sct
That script (spawning what looks to be an Advanced Persistent Calculator) looks like so:
Digging into the Sysmon logs in Event Viewer after running the command, we see several Sysmon events generated. Notice that the spawned calc.exe has c:\windows\system32\cmstp.exe as the ParentImage and that the IntegrityLevel is Medium, i.e. no integrity elevation occurred.
Let’s now take a look at the Sysmon 3 Network Connections. One of the connections looks to be to localhost over a high number port. The other shows cmstp.exe as the Image calling out to 18.104.22.168 (Github) over 443.
It follows then, that potential Sysmon detection rules for Method 1 could be:
- Sysmon Event 1 where ParentImage contains cmstp.exe
- Sysmon Event 3 where Image contains cmstp.exe and DestinationIP is external
Method 2 – UAC Bypass via INF RunPreSetupCommandSection
As Odvar Moe found in his research, it turns out that the RegisterOCXSection of the INF file is not the only section susceptible to weaponization. Looking at a different INF file generated by the Connection Manager Admin Kit, it’s possible to insert arbitrary binaries for execution under the RunPreSetupCommandSection. In this case, we’re spawning a command shell and then subsequently killing the cmstp executable.
Getting this method to work on the command line is slightly different than in Method 1, requiring some new options, making sure “All Users” is checked in a dialog box that pops up, and hitting OK.
Once done, we have our command shell. Notice that unlike the previous method, executables run in this fashion elevate their security context with no notice to the user, resulting in UAC Bypass. We’ll look at a stealthier way to do this in Method 3 that doesn’t involve a popup.
Note the Sysmon 12 and Sysmon 13 registry value add and value set events:
Dllhost.exe is creating the object cmmgr32.exe in the Sysmon 12 then setting the ProfileInstallPath value to C:\ProgramData\Microsoft\Network\Connections\Cm in the subsequent Sysmon 13.
Let’s take a look at the Sysmon 1 event where the cmd.exe was actually spawned:
Unlike Method 1 where cmstp.exe was the ParentImage and the target binary was the child, here Dllhost.exe is the parent.
We see in the ParentCommandLine field that Dllhost.exe utilizes a ProcessID option with what appears to be some kind of GUID. To understand what that GUID is doing there, we’re going to rerun the attack but this time using a modified Sysmon configuration that allows us to obtain Sysmon Event 10s (Process Access).
To limit the collection aperture for the Event 10s and avoid grinding the system to a halt, we’re going to follow Tim Burrell’s great writeup here and set up Sysmon such that we’re pulling only those Sysmon 10 events requesting highly privileged levels of process access or containing an “unknown” string in the CallTrace:
We’ll need to let Sysmon know to use the updated configuration by running:
sysmon -c <modified_config.xml>
Re-running the attack, we see several additional Sysmon 10 events. One of them in particular, where Dllhost.exe accesses the TargetImage cmd.exe, is interesting.
Note the CallTrace data. One of the DLLs called was cmlua.dll – which @hFireF0X has called out as containing an autoelevated COM interface called CMLUAUTIL. We’ll see CMLUAUTIL again when we get to Method 3. For now, let’s recap our potential detections for Method 2:
- Sysmon 1 where ParentImage contains dllhost.exe and Image contains cmd.exe (a strategy which may produce lots of noise and not bracket you to a CMSTP exploit)
- Sysmon 10 where CallTrace contains cmlua.dll
- Sysmon 12 or 13 where TargetObject contains cmmgr32.exe
Method 3 – UAC Bypass via Direct Utilization of COM Interfaces.
As @hFireF0X stated in his tweet, cmlua.dll references the autoelevated COM interfaces CMLUAUTIL and CMSTPLUA via cmlua.dll and cmstplua.dll respectively. In his UAC Bypass project UACME (https://github.com/hfiref0x/UACME) there are several methods enumerated to execute bypass, however #41 contains a proof of concept to execute the same attack we saw in Method 2, except instead of dealing with the cmstp.exe executable, it’s popup dialog, and relying on the DLLs to interface with the COM interfaces, we interface with them directly.
What’s the potential impact on our Sysmon visibility if one were to utilize this method?
To execute this UACME-powered attack as of July 2018, we’ll need to grab a previous commit of the UACME repo with the “Compiled” and “Source” directories still in place (he’s removed the executable we need for whatever reason – so grab a commit from May or June of 2018). Under the Compiled directory, let’s run “Akagi32.exe 41.”
If we navigate back to the Sysmon 10 event that we analyzed in Method 2 where Dllhost.exe accessed cmd.exe and look at the CallTrace, there is NO mention of cmlua.dll. Also note that there are NO Sysmon 12 or 13 events. This indicates that looking for cmlua.dll or registry adds / mods is potentially brittle:
Let’s revisit the Sysmon 1 event where dllhost.exe spawned cmd.exe. It turns out that the GUID we see in the ParentCommandLine field is actually the Class ID for the COM object we’re hooking into, in this case autoelevate-capable CMSTPLUA.
A potential way forward then for detecting both Method 2 and 3 is to alert on dllhost.exe in the ParentCommandLine along with the GUID of CMSTPLUA:
- Sysmon 1 where ParentCommandLine contains dllhost.exe and contains GUID for CMSTPLUA COM object (3E5FC7F9-9A51-4367-9063-A120244FBEC7)
I’ll need to do further research to figure out how this might be further obfuscated by an adversary but it could be a good base.
To summarize, CMSTP and it’s dependencies are capable of facilitating a few different methods of code execution and UAC bypass, each with it’s own detection nuances and footprint. Note that before deploying any of these detections to production, it’s important to baseline what’s happening on your network and develop a hypothesis around why implementing any of these will produce high signal / low false positive rate for you.