What is it & Why it matters?
That is a User Account Control prompt, home users with an admin account would have seen this prompt at some point in time. For windows sys-admins, there are risks of running malicious payloads that bypass UAC & execute malicious tasks (eg. a ransomware).
At the time of writing, there were 44 bypass methods consolidated into one single test tool from UACme project.
There were “unfix” 15 occurrences on UACme README page. This means there are no fixes for those 15 methods because Microsoft does not consider them as vulnerabilities.
The source codes of these bypass methods are open-sourced & reusing these bypass codes is highly probable. As such, it is worthwhile to understand the differences between legitimate UAC elevation & a bypass.
What to look for?
Look out for:
- Process start & end timing of consent.exe, a bypass happens very quickly within the same second (in the order of milliseconds), while a legitimate elevation involving a human user will typically be two (without typing credentials, just click [Yes]) or more seconds apart. Let’s say a user could have cancelled the consent prompt very quickly, then we have to look at the other two aspects.
- Cross-process activities (eg. creation of remote threads, changes in rights) between & after the start & end of consent.exe. Bypasses tend to have complex sequences but legit UAC elevations are simpler.
- The consequent process that is elevated with higher process integrity level but owned by user (& NOT SYSTEM which is typical of kernel-related exploits). For “living-off-the-land” MO, the elevated process could be various Microsoft signed binaries that load arbitrary DLLs or equivalent, or scripting with CMD, Powershell, C/WScript, MSHTA. For drop-&-execute cases, it could be a executable file with a hash checksum that is first seen (or rare) in the environment.
How?
I ran the UACme test harness (akagi64.exe) on a Virtual Machine installed with Carbon Black Response for this analysis. This is NOT a sponsored post but permission was sought from Carbon Black.
We can observe all these with tools like Procmon, Windows Audit & Sysmon logs but it is a matter of productivity, budget, learning curve (I can’t remember event-IDs), effort to deploy & configure different tools just to connect the dots together. In my case, I had the luxury of using Carbon Black Response which significantly shortened my time to gather these insights.
Where to begin?
With the shortage of security folks to keep up with offensive techniques, threat intelligence in the form of vetted queries are useful. Note the source column (cbcommunity, sans & bit9endpointvisibility) of the alerts listed below:
Although we can argue that attackers may not run a stock (unmodified) akagi64.exe, the subsequent alerts gave me good starting points for digging further. We can click on the Source Report links (eg. MSCFile Regmod for UAC bypass) to read & further understand some technical background.
Look for Commonalities…
After running through all the bypass methods & studying the related event time-lines, I noticed two things with the SVCHOST event time-line:
Observation 1 — A number of activities happen between start & end of consent.exe
In this case, the method abuses sdbinst.exe, there are other methods using different Windows system components (typically with manifest that had AutoElevated attribute set to true). Other methods have more complex sequences, like the next one.
Observation 2 — One or more consent.exe process(es) start & end happened within a short span of time
In this case, consent.exe was started twice but notice the time stamps on the left, most of the events happen within the same second, the first 3 rows with 02:25:25 & subsequent 02:25:26.
It’s all about timing…
After running the various bypass methods, it was a matter of a few clicks within Carbon Black Response to review all the consent.exe timings related to UACme executions:
Having seen the timings of bypasses, one will be inclined to ask: how does a legit UAC elevation look like? Let’s look at some common UAC elevation use-cases.
Regedit
First, an elevated Regedit from Windows 10:
This differs from Windows 7 which has explorer.exe as parent process of regedit, but the focus is still on SVCHOST’s timeline:
Notice the timestamps highlighted in the red box; 2 seconds apart. A user (in this case me) will take some time to click the UAC prompt. The sequence is quite straight forward.
Admin CMD Console (Windows client)
How about the Run As Administrator for CMD.exe use-case?
Again, the time difference between process start & end was 2 seconds.
For both cases Regedit and Cmd, the sequence was short & simple, when consent.exe ended, thread injections from SVCHOST to the target processes are observed.
Program Installer
How about running an program installer (with that little shield icon) after UAC elevation?
Just like CMD & Regedit, the process was owned by admin user (q in this case) & not SYSTEM.
Again, SVCHOST injected new thread into setup_timefreeze.exe. Consent started at 05:32:32 & ended at 05:32:34, two seconds apart.
Maybe someone can click [Yes] faster than me but it is unlikely to be in the order of milliseconds. If one has to type in credentials (with fingers), it will take longer than 2 seconds.
Generalised Detection
Over time, more bypass methods will surface but regardless of the system tools & execution sequences involved, the “common denominator” is the very short time span of start & end of consent.exe. This insight will be useful for SIEM content & EDR queries development for automating detection.
