Recently, we found a Kernel logic bug in Viper RGB software version 1.0 which is used to manage Viper Gaming DRAM memory modules. The affected component of said software was MsIo64.sys/MsIo32.sys driver which was then utilized to achieve Local Privilege Escalation. The following is the process used to identify and exploit the security vulnerability. Let’s start off by examining the device permissions.

​GeForce Experience is the companion application to your GeForce GTX graphics card. It keeps your drivers up to date, automatically optimizes your game settings, and gives you the easiest way to share your greatest gaming moments with friends. It also regularly downloads new game profiles which are essentially collections of settings that control what your graphics driver does when it loads specific games. In this blog post, we will walkthrough identifying and exploiting a Local Privilege Escalation vulnerability we found in GeForce Experience version 3.20.0.118 (the latest as of this writing) and older.

​With the notable increase in the number of symbolic link elevation of privileges vulnerabilities on Windows platforms as of late, we at ACTIVELabs have set a goal for ourselves to find a new one. This blog post will detail finding and exploiting said vulnerability in Netwrix Auditor version 9.7 and earlier. Please note, abusing symbolic links has been leveraged for years now, particularly in the *nix world to achieve local privilege escalation and as such we’ll assume you know the idea behind it and most importantly how it can be abused. Let’s start by examining the problematic log file permissions for the effected software.

While conducting research on insecure Windows Communication Foundation (WCF) endpoints we stumbled upon SolarWinds fleet of products for two reasons; first, they have handful of software that you can test and secondly, most of the services were built using .NET Framework which makes it a strong candidate for our research.

​To continue our journey in the realm of bypassing UAC (see previous work here), we’ve decided to investigate Windows Server 2019. Please note this blog post is not a UAC primer but if you need to learn more about the subject, we think Wikipedia is a good place to start. The following is the process used to find a new UAC bypass in systemreset.exe binary using DLL Hijacking method. The technique was tested on Windows Server 2019 Version 1809 (OS Build 17763.404) and its still valid as of this writing.

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