The Virtual Account that rocks the EPM!

Last Updated on September 9, 2023 by rudyooms

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 have a little peek at the “virtual account” which is 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 is NOT going to be a level 100 blog or an introduction to Endpoint Privilege Management but more like level 400+.

I will divide this blog into multiple parts

  1. Introduction
  2. The famous MSPaint flow
  3. Explaining that weird flow
  4. The simple “flow”

1. Introduction

When you have activated and are using Endpoint Privilege Management in your tenant I bet you also read my other blogs 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.

Afbeelding met tekst, Lettertype, schermopname

Automatisch gegenereerde beschrijving

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

Afbeelding met tekst, schermopname, menu, Lettertype

Automatisch gegenereerde beschrijving

As shown above, inside your c:\users folder a new user folder pops up with a nice $ behind it. Almost sounds like a hidden share, right? I got intrigued by this hidden account a bit 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 a little bit about the process and why the EPM uses a virtual account.

The moment EPM gets installed, a new virtual admin account will be created. Besides this virtual account, also a virtual domain group will 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 apparently NOT a SID we need to transform some SIDs to a funny domain and username

So with the help of the LsaManageSidNameMapping, the SID will be translated into a virtual domain name and username. This LsaManageSidNameMapping function will 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

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.

Afbeelding met tekst, schermopname, Lettertype, lijn

Automatisch gegenereerde beschrijving

So now with these SIDs mapped to a domain and username, the logonuserexex is almost ready to start the actual logon process. But before we could logon in and start the creation of 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.

In the same picture, we will notice the unknown (not documented LOGON32_PROVIDER_VIRTUAL). That not documented virtual logon 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

Afbeelding met tekst, software, Multimediasoftware, Computerpictogram

Automatisch gegenereerde beschrijving

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.

Afbeelding met tekst, Lettertype, lijn, nummer

Automatisch gegenereerde beschrijving

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

Afbeelding met tekst, schermopname, Lettertype, lijn

Automatisch gegenereerde beschrijving

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 come up with a new kind of storytelling to make sure everyone could understand what I was trying to show you all.

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 a lot of new and cool details. I hope this blog showed you some details about how nice (or complicated) EPM is and how the virtual account is created!

Leave a Reply

Your email address will not be published. Required fields are marked *

  +  88  =  89