Hijacking COM. Abusing COM classes to hijack user sessions

Long ago, when the sky was bluer, the trees were taller, and the girls were sweeter, I published an article called Insecurity provider. How Windows leaks user passwords. It discussed in detail the user login stage: from turning the workstation on to gaining access to its desktop.

Today I am going to present another attack type: session hijacking. And to implement it, I will use COM!

Logon Sessions

Let’s start with the basics. A Logon Session (or just session) is similar to a browser cookie. The system uses it to determine which user is accessing it.

Each session has a unique number called LUID (Locally Unique IDentifier). In fact, that’s all what is required for Windows to identify a user session.

where:

• LowPart contains the required numerical value; and 
• HighPart is usually NULL.

The existing Logon Sessions can be examined using the LsaEnumerateLogonSessions() function. Let’s see how it looks in C#.

In the above code, you can see a standard import of required functions with PInvoke and their subsequent calls performed in a certain order.

To get a list of sessions from a device remotely, you can use the NetSessionEnum() and NetrSessionEnum()functions. An example of their usage can be found on GitHub.

Alternatively, the netview.py tool can be used.

Finally, you can use built-in command line tools.

There are plenty of other ways to search for target user sessions, including Invoke-UserHunter from PowerView and its numerous analogs in C#, but these tools are beyond the scope of this article. Therefore, let’s finish with reconnaissance and move on to actual hijacking.

Similar to Elevation Monikers, Windows also uses Session Monikers. To remind: a moniker is a string representation of a COM object. And a session moniker can be used to instantiate a COM class in a specific session.

For example, if you have a COM class, and one of its methods enables you to execute commands, you can hijack a user’s session by instantiating this COM class inside that user’s session using a Session Moniker.

In reality, it’s not that simple since Microsoft has imposed certain restrictions (to be addressed a bit later). But first, let’s examine the Session Moniker operation principle using slides published by James Forshaw.

Initially, there are several objects.

There is a session assigned to user Alice (your session) and a session assigned to user Bob (to be hijacked). There is also the RPCSS service (Service Control Manager for COM and DCOM servers) responsible for activating COM objects.

So, you request activation of a COM object in Bob’s session.

This request is submitted to the RPCSS service because SCM manages the activation of COM objects. The RPCSS service sees that a Session Moniker is being used, locates Bob’s session, and creates a COM object inside it.

After the successful activation of the COM object, the client (i.e. yourself in session 1) receives a pointer to the interface of this COM object and can interact with it (e.g. call a method to execute a command).

To use a Session Moniker, all you have to do is prepare a string in the following format:

where digits is the ID of the session where a COM class should be created identified by the CLSID value in the class id field.

Using this function, you can create COM objects in other people’s sessions.

If anyone could instantiate COM classes in other people’s sessions using Session Moniker, this would mean a severe security hole in Windows. Its exploitation could result in horizontal privilege escalation (vertical privilege escalation occurs in the case of an admin session).

But it’s not all that bad. In many cases, it’s impossible to instantiate a COM class in the target user’s session using Session Moniker. The target COM class must be registered to run under an interactive user. This value is specified in a separate registry key: RunAs. If the value is empty or the running user, system, or service is specified, Session Moniker won’t work. The Checker tool can be used to extract a list of all objects: it generates a report in the CSV or XLSX format. After that, all you have to do is apply a filter to the required field.

Then restrictions are imposed in the following priority. They don’t have official names (or I am not aware of them).

1. SeDebug – if you have SeDebug, you can hijack other people’s sessions (e.g. using IHxExec);

2. Patch fixing CVE-2024-38100 (FakePotato) – if you don’t have local admin rights, you won’t be able to instantiate interactive (the RunAs field is set to The Interactive User) COM objects inside the explorer.exe process. In fact, the developers simply fixed Access Permissions in this patch. If you don’t have such permissions for the process, you won’t be able to access COM objects running inside it. If Access Permissions for a specific AppID aren’t defined, then the default ones are used. You can use the OleViewDotNet tool to view your permissions.

   

   

   

3. Patch fixing the COM Session Moniker EOP exploit. The capabilities of Session Monikers have been known for a long time, but their exploitation isn’t very popular. As soon as security experts started researching them, an exploit was created almost immediately: it allows you to start a certain object inside someone else’s session, which results in privilege escalation. The fix adds an integrity level check prior to accessing the object. If someone tries to access an object in someone else’s session from a process with a medium integrity level, the access is blocked.

Starting a process in someone else’s session

First, let’s test the IHxExec exploit. It enables you to run an executable file inside somebody else’s session. Its implementation in C# and PowerShell is also available on GitHub.

Both tools abuse Session Monikers to execute code. If you have local admin rights (or the SeDebug privilege), then you can execute code in other users’ sessions this way. On older systems that haven’t been updated since 2017, this trick would work even on behalf of a low-privileged user. A detailed analysis of the exploit can be found on Medium.

Technically, two undocumented COM interfaces are exploited: IStandardActivator and ISpecialSystemProperties; under normal conditions, these interfaces are accessed when Session Monikers are instantiated. The first one is required to activate objects; while the second one includes an interesting method called SetSessionId() that can be used to specify the target session where a COM object has to be started.

As you can see, the exploit successfully instantiates the required COM object, and you can execute an arbitrary file inside someone else’s session.

Password hash leak as a result of changing desktop wallpaper

Another exploit was released quite recently: it also abuses Session Monikers, but now the instantiated COM object makes it possible not to start a process, but to change the wallpaper. One might ask: Where is the vulnerability? But if you review the article Gone to the Dogs by Elad Shamir, you’ll see that the wallpaper change function can be used to extract the NetNTLM hash from a computer. So, I thought: what happens if an attacker instantiates an interactive COM object inside someone else’s session, then calls the wallpaper change method, and specifies the UNC Path to gain the NetNTLM hash?

This idea was nagging me for a while, but then a hint appeared on decoder.cloud, and I managed to find a suitable COM object.

The object features the IDesktopWallpaper interface and the SetWallpaper() method whose logic seemed to be suitable for my purposes.

The first argument is used to pass the ID of the monitor where a new wallpaper should be set; while the second one, to pass the path to this wallpaper. The point is: if you specify a UNC Path in the second argument, this would cause an NetNTLM hash leak. But where to get the monitor ID?

According to MSDN, the GetMonitorDevicePathAt() method can be used for this purpose. To call it, the monitorIndex parameter is required, and it can be obtained using GetMonitorDevicePathCount().

The resulting kill chain looks as follows:

• GetMonitorDevicePathCount([out] int a);
• GetMonitorDevicePathAt([in] a, [out] index); and 
• SetWallpaper([in] index, [in] UNCPath).

To leak the NetNTLM hash of the target user, you have to instantiate the COM class for wallpaper management inside that user’s session. This can be done using the CoCreateInstanceInSession() function.

After the successful instantiation, you can access methods of this COM class.

After leaking the hash, you can take it a step further and deliver a relay attack. Such attacks were discussed in detail in the series of publications “Your guide to NTLM relay” (Part 1 and Part 2).

Conclusions

One again, undocumented Windows features enable hackers to deliver efficient and elegant attacks. The hardest part about it is to crystallize an abstract concept into a fully-functional exploit.

Good luck in your pentesting endeavors!