The COM session moniker allows a user to specify the interactive session that’s to be used when a DCOM object is registered with an AppID with RunAs of “Interactive User”. As switching sessions is not something a normal user can do you’d assume that this would be only accessible to administrators (or at least with Impersonate/Assign Primary Token privilege). It turns out however that there’s no such restriction, this allows one user to instantiate a DCOM object inside another user’s session on the same machine (think Terminal Server or Fast User Switching).
The only restriction on the user then accessing that instantiated server is the specified Access DACL. The default Access DACL on a modern system only allows the user identity the server is running as as well as Administrators to access the created object. However there are a number of statically registered servers which allow the interactive user group (and who knows how many dynamically allowed ones through CoInitializeSecurity). I already described one these in my blog post of resurrecting dead processes, HxHelpPaneServer. With this object we can execute an arbitrary process in the context of the other user in their session.
Fortunately at least it's not possible to create an object in Session 0 (as far as I can tell) as that's not an interactive session.
#### Proof of Concept:
I’ve attached a proof of concept in C#. To test PoC use the following steps.
1) Create two users on the same machine.
2) Log on to both users to ensure account setup has completed.
3) As one of the users execute the PoC, ensure it prints that it’s going to start a new process. Switch to the other user (without logging out the one running the PoC).
4) After about 20 seconds a copy of notepad should start on the other user’s desktop. Of course this could be any process including an arbitrary executable from the other user.
NOTE: Make sure these user’s are not administrators, or at least are split token administrators. If they’re the Administrator user which doesn’t run by default with a filtered token then the user will not be able to access the DCOM object due to High IL and executing the process will fail. That’s not to say it’s impossible to exploit that scenario, just more difficult.
#### Expected Result:
Using a session moniker for a session outside the current one should fail if not an administrator.
#### Actual Result:
DCOM object created in the specified session an arbitrary executable run as that user.