Powered by ACTIVECYBER, LLC
Powered by ACTIVECYBER, LLC
**Update** - 9/13/2019
Metasploit has added a module for the UAC Bypass in Windows! Most of Metasploit modules are built by community contributors for free (i. e. modules that are worth the effort to be included to make Metasploit users life easier). This UAC bypass was chosen due to the fact it a) does not require user interaction and b) it’s file-less (no dropping files on disk is needed). It’s common practice to give credit when its due when creating modules hence the reference to ACTIVELabs for the discovery. Find the module here.
**Update** - 5/23/2019
Please note Microsoft has released a behavioral detection for this attack vector in Windows Defender Antivirus with an alert level of “SEVERE." We can confirm it works as expected. See the link here.
Based on the increased interest in User Account Control (UAC) bypass research as of late, we've decided to read more on the subject and attempt to identify some sort of a pattern which ultimately led to finding our first UAC (still valid as of this writing) bypass. The following is a walkthrough of said finding. Please note we will not discuss UAC internals as there are plenty of well-written posts out there. In addition, will be using Windows 10 Version 1803 (OS Build 17134.590) as an example.
The problematic binary is WSReset.exe, the Microsoft signed executable is used to reset Windows Store settings according to its manifest file but most importantly has “autoElevate” property set to true.
Now, let’s set Procmon64.exe with the following self-explanatory filters.
Running WSReset.exe (medium-integrity) shows the missing parameter for verb open under the HKEY_CLASSES_ROOT (HKCR) virtual registry hive which if found will be run in (high-integrity) context.
Now according to Microsoft documentation here there are two characteristics that we need to be aware of in regards to HKEY_CLASSES_ROOT (HKCR) virtual registry hive:
The Component Object Model (COM) leverages HKEY_CLASSES_ROOT (HKCR) to maintain information about all of the COM objects installed on a computer, which allows for both per-user and per-machine object registration. In other words, the current user can write to HKEY_CURRENT_USER\Software\Classes (HKCU) which will effectively end up in HKEY_CLASSES_ROOT (HKCR) virtual registry hive. Here's the proof-of-concept code using PowerShell:
And the obligatory demonstration of the attack:
For what it's worth, we did report this to MSRC and received the following response:
Although we haven’t tested it ourselves, this particular technique can be remediated by setting the UAC level to “Always Notify” or taking away local administrative rights. We hope this post was worth your time and feel free to reach out at firstname.lastname@example.org if you have any questions.
3/16/2019 05:50:22 pm
i wish you had rss, but otherwise, excellent post!
4/2/2019 12:41:13 pm
We've added an RSS feed for your convenience. Thanks for the feedback.
3/16/2019 07:39:10 pm
Nicely done. One day UAC will be a security boundary.
4/2/2019 12:46:31 pm
Thanks for bringing this to our attention and we will keep that in mind for the future.
3/18/2019 01:58:45 pm
Great write up.
Your comment will be posted after it is approved.
Leave a Reply.
ACTIVELabs was created in 2018 to hunt and research undiscovered vulnerabilities, report them to vendors via responsible disclosure programs, publish advisories, develop and validate new patches, and to share this information for the advancement of the cybersecurity community. ACTIVELabs was established with the mission of securing our ever-growing client base, partnerships, and the technology community as a whole.
We are actively providing the community with verified findings and research that leads to the creation of new Common Vulnerabilities and Exposures (CVEs) and updates to the National Vulnerability Database (NVD). For a full listing of all of our Advisories, visit our GitHub page here.
888 Bestgate Road, Suite 316
Annapolis, MD 21401 202.499.3774