While exploring the DCOM objects for the “SilverPotato” abuse, I stumbled upon the “ShellWindows” DCOM application. This, along with “ShellBrowserWindows”, is well-known in the offensive security community for performing lateral movements by instantiating these objects remotely with admin privileges.
However, I was curious to understand if they could be abused locally by a standard user.
The DCOM Application “ShellWindows” with Application ID {9BA05972-F6A8-11CF-A442-00A0C90A8F39} is configured to run under the Identity of the “Interactive” User:
The permissions set on this application are the default ones, meaning that the interactive user can at least launch and activate the DCOM application locally:
Let’s take a look at how the DCOM application is configured, and thanks to the Type Library, we can get a lot of useful info:
The class is registered by explorer.exe, and the activator will use this one. Several methods are exposed:
The ShellExecute() is what we are looking for, given that it allows the execution of an external command or application.
Now, with the help of Oleview tool, let’s see what are the Access Security in the explorer.exe process:
Looks promising, Authenticated Users have execute permissions (!!!???)
So, just to recap, we have this DCOM application impersonating the interactive user. It is hosted by the explorer process, which grants execute access to authenticated users.
Now, if we could perform a cross-session activation, a non-privileged user could activate the object on behalf of another user connected in a different session and invoke the **ShellExecute()** method to perform arbitrary execution?
Let’s do this quick & dirty in PowerShell 😉
We are user1 and an administrator is connected in session 2. We can just activate the DCOM object in session 2 using the BindToMoniker() call and execute the ShellExecute() method.. and, for example, get back a reverse shell from Administrator:
It worked! 🙂
$obj = [System.Runtime.InteropServices.Marshal]::BindToMoniker("session:2!new:9BA05972-F6A8-11CF-A442-00A0C90A8F39")
$p=$obj.item(0).document.application
$p.ShellExecute("c:\temp\reverse.bat", "", "c:\windows", $null, 0)
Now comes the funny part: I tried this method on another user without admin privileges… and guess what happened?
Access denied! This is really strange, but a quick check on Access Security explains why we get access denied:
Authenticated Users permissions on the explorer process are missing in this case. If processes run in Medium Integrity Level, which is the standard behavior for users – even those who are members of the Administrators group, because UAC is enabled – they will lack permissions for this group.
However, the real Administrator, with UAC disabled, has all processes running under High Integrity Level (High IL) and in this case, these permissions are set!
This clearly seems to be a bug. The question is, how long has this been around? Is it possible that no one discovered it before? Perhaps due to the constraints of a high IL?
Hard to say…
There are other registered classes in explorer.exe that could potentially be abused:
I played with the Desktop Wallpaper and was able to change the desktop background image of Adminstrator 🙂
The case was (obviously) submitted to MSRC, and the security bug was fixed in July 2024 Patch Tuesday with CVE-2024-38100 marked as Important LPE.
Now the right settings on explorer.exe process are also applied in high IL.
You might be wondering why I called it the “Fake” Potato. Initially, I thought it could be exploited using the same techniques as the *Potato families, but it turned out to be different and much simpler in this case 🙂
Side note: this bug is similar to the one James Forshaw reported in 2018, which was fixed in CVE-2019-0566
That’s all 😉