The Virtual Account that rocks the EPM!

Are you using Intune Endpoint Privilege Management (EPM) and wondering what is “needed” when you launch a process with elevated access? In this blog, I will take a peek at the “virtual account” created during the EPM installation. The process you elevated will be run in the context of this virtual account.

I need to warn you…. This will NOT be a level 100 blog or an introduction to Endpoint Privilege Management but more like level 400+.

1. Introduction

When you have activated and are using Endpoint Privilege Management in your tenant, I bet you also read my other blogs about what happens before the EPM agent is installed.

MMPC | Dual Enrollment | Microsoft Managed Platform Cloud (call4cloud.nl)

This time, I am NOT going to look at how your device is being enrolled into Intune version 2 (MMP-C) but in which context or, let’s say, account the elevated process is going to be executed.

You could be asking yourself, what in God’s name is Rudy talking about (a question I am getting a lot lately) … Well, let me show you. If you had allowed PowerShell to be elevated with EPM, you could have noticed a nice hidden user account that looks like your own user.

As shown above, inside your c: users folder, a new user folder pops up with a nice $ behind it. It almost sounds like a hidden share, right? I was intrigued by this hidden account, so I decided to figure out what it was.

Before describing all the stuff I noticed… Prepare yourself to be blown away by a funny MSPaint flow

2. The famous MSPaint flow

The preview version is a JPG. When clicking on it, you can save it as a BMP (110MB)

Please Note: I don’t work at Microsoft! So this is just me looking at the flow and having a wild guess of how “it” works

3. Explaining the weird flow

When you have taken a good look at the MSPaint flow (or not..) you will have learned by now what happens when EPM is installed. If not please let me explain briefly about the process and why the EPM uses a virtual account.

When EPM is installed, a new virtual admin account will be created. In addition to this virtual account, a virtual domain group will also be fixed!

A Domain group on a 100% pure AADJ device…let’s say it out loud again…. A Domain Group on an AADJ device 🙂

To create the virtual account, it will use the LsaManageSidNameMapping and the LogonuserExExW functions from the advapi32.dll (Advanced Windows 32 Base API) and sspiCli.dll (Security Support Provider). So, the first step in this process would be to load the advapi32.dll.

With the advapi32.dll loaded, the LogonuserExExW function is going to obtain a user access token by specifying the desired virtual account name and domain name, but as it looks, it can only handle a string and NOT a SID. We need to transform some SIDs to a funny domain and username.

So, the LsaManageSidNameMapping function will translate the SID into a virtual domain name and username and allow us to manage the mapping between the SID and the account name.

Let’s take a look at how it looks at EPM first when those SIDs are mapped.

We will find the $ hidden Virtual Account with the SID shown above. If we look at which groups this user is a member of, we will spot two funny things. First, we will notice that the Virtual Account is a member of a Domain group called MEM\MEM.

UPDATE 03-04-2024:

It seems that Specterops was also aware of this and started a bug journey. After submitting this bug, Microsoft released a patch to remove the builtin\administrators group membership. (Clicking on the picture will get you to the spectorsops blog)

Just for fun, I tried to do the same! By using the LSAManageSidNameMapping function and the setsidmappingtool. With that wonderful tool, I could practically do the same.

So now, with these SIDs mapped to a domain and username, the logonuserexex is almost ready to start the actual login process. But before we can log in and start creating the virtual account/profile, we need to specify some logon permissions/rights.

When looking at the DLL, it looks like the account will get the logon32_logon_interactive (SeInteractiveLogonRight) permissions.

Did you notice the NULL part in the lpszPassword? NO password management is needed for virtual accounts.

We will notice the unknown (not documented LOGON32_PROVIDER_VIRTUAL) in the same picture. That undocumented virtual login provider will now be used to actually log on to the virtual account that is going to be used for the elevation.

Again with the use of some nice tool called NtObjectManager (Defender doesn’t like it!!), we could play around with it

When logging in for the first time with the virtual account, it will create the required user profile and of course the hidden user folder itself. After the user profile is created, Microsoft changes the folder attributes to hide the profile from the c:\users folder.

With the profile created, the virtual admin account is ready for duty and to start some elevation.

But if you have also looked at the last picture in the flow, it is obvious that the elevated process doesn’t get SSO.! As shown below, the virtual account doesn’t have an Azure Ad Primary Refresh token and the domain prefix is scrambled!

4. The Simple Flow

I decided to use a new kind of storytelling to ensure everyone could understand what I was trying to show you.

So this is the famous MS plaint flow converted to something simpler! Hope you like it

Conclusion

I love looking at new stuff and learning about many new and cool details. I hope this blog has shown you some details about how nice (or complicated) EPM is and how the virtual account is created!