HKU\%SID% not remaining mounted when launching as different user to a sandbox

[Syrinx2024]

Describe what you noticed and did

For this example I used a VM with Windows 10 x64 & Sandboxie 1.14.6 x64 with brand new 'default install' settings
This test method only relies on existing binaries (CMD, NET, POWERSHELL, REG & RUNAS...aka LOLBins) to (kind-of?) simplify the example and hopefully prevent possible misconceptions about it being related to a specific program...

Only CMD and REG are used INSIDE the sandbox while testing

1. Create a new (secondary) user account (and prevent it from asking user to change the password upon use)

SET BOXNAME=Test
SET PASSWORD=Test
NET USER %BOXNAME% %PASSWORD% /ADD /Y
POWERSHELL -Command "Set-LocalUser -Name %BOXNAME% -PasswordNeverExpires $true"
NET USER %BOXNAME% /PASSWORDCHG:NO

2. Initialize (create) the 'New User' defaults by trying to launch a non-existent program via RUNAS, PSEXEC etc... (or just launch something small like notepad as the 'New User' then close it)
   IF NOT EXIST "%SYSTEMDRIVE%\Users\%BOXNAME%" (RUNAS /SaveCred /User:%BOXNAME% NotReal.exe)
   Input Password if needed

3. Mount the 'New User' Hive and create a new key along with a value and some data we can search for later (This is the equivalent of a program which has already stored information in the real Users HKCU)

REG LOAD "HKEY_USERS\%BOXNAME%" "%SYSTEMDRIVE%\Users\%BOXNAME%\NTUSER.DAT"
REG ADD "HKEY_USERS\%BOXNAME%\Software\Test" /V "Test" /T REG_DWORD /D "1" /F
REG UNLOAD "HKEY_USERS\%BOXNAME%"

4. Launch the CMD prompt as the 'New User' running OUTSIDE the sandbox
   RUNAS /SaveCred /User:Test CMD

5. From the CMD prompt running as the 'New User' attempt to read the data from the value that we added above
   REG QUERY "HKEY_CURRENT_USER\Software\Test" /V "Test"
   Result should succeed and return the data stored in the value 'Test':
   "Test REG_DWORD 0x1"

6. Close All programs currently running as the 'New User' so that the hive is properly unmounted and 'free'

7. Use RUNAS, PSEXEC etc... to launch the same program inside a sandbox via Start.exe etc...
   RUNAS /SaveCred /User:Test "\"C:\Program Files\Sandboxie-Plus\Start.exe\" /BOX:DefaultBox CMD"
   Input Password if needed

8. Attempt to read the data from the value that we added (and double-checked) above via the CMD prompt running INSIDE the Sandbox
   REG QUERY "HKEY_CURRENT_USER\Software\Test" /V "Test"
   Results should mirror my own and return an error:
   "ERROR: The system was unable to find the specified registry key or value."
   The NTUSER.DAT registry hive for the User isn't mounted and programs inside sandboxie are unable to access anything existing outside of the sandboxes own REGHIVE copy under 'user\current' resulting in 'default settings' or 'crashing programs' and a number of other spiraling potential issues depending on the quality of said software currently running as another user inside SBIE+.

Actual Results:
When ran as the Test-User OUTSIDE the Sandbox the Users registry IS properly readable returning SUCCESS in ProcMon
When ran as the Test-User INSIDE the Sandbox the Users registry IS NOT properly readable returning NOT FOUND in ProcMon

Update:
Further testing using a virgin OS VM shows some inconsistent results when launching as other users but for the most part can be relied upon to reflect:
RunAs via Start.exe = Fails to load user hive
RunAs via Start.exe & OpenIpcPath=\RPC Control\SECLOGON = Fails to load user hive
RunAs via Forced Program = Fails to load user hive
RunAs via Forced Program & OpenIpcPath=\RPC Control\SECLOGON = Fails to load user hive
RunAs via Forced Folder = Fails to run program as user at all
RunAs via Forced Folder & OpenIpcPath=\RPC Control\SECLOGON = Works The hive is mounted and readable!

Oddly, attempting to pre-mount the hive for said user to its standard HKEY_USERS\SID location still results in it being 'ignored' (NOT FOUND) by the program in the sandbox in cases where it normally fails to load the hive anyway potentially indicating a deeper issue...? (or flawed tests on my part¿)

My current Workaround, as I do not like the idea of opening up "\RPC Control\SECLOGON" without understanding the implications more, basically just mirrors existing HKCU data into the target sandboxies registry by:

Collecting a copy of an almost blank REGHIVE from each box (and cleaning it manually)
Export Data from Users NTUSER.DAT to .reg
"Replace All" key paths inside .reg to reflect the Sandboxed path where I mount it to in the next step
Mount the REGHIVE
Add the fully modified .reg (including the extra 'user\current' so that all data now actually resides inside the sandboxie registry copy at the expected path)
UnMount the REGHIVE
Create a 'backup' or 'parent' copy of REGHIVE for use in a bat file prior to EVERY launch which starts by creating the sandboxes directory (As they are set to Auto-Delete *! ) and copy the backup\parent REGHIVE to the new folder, update NTFS security for the new folder (as SBIE won't do it if it doesn't create it [Thanks btw!]), then launch said program as another user into the target sandbox.
Programs ran as 'another user' can now read their needed HKCU keys\values\data from Sandboxies own registry copy and finally work as expected....

*! When set to Auto-Delete the UI fails to delete the proper "RunAs User" sandbox for the program unless you edit the Sandbox root path to NOT use the %USER% variable as it seems to use the variable for which the 'UI' runs as and not anything based off which user was actually running inside each sandbox prior to exit.
Using something like the following works around THAT problem...
\??\%SystemDrive%\Sandbox\%SANDBOX%

Another workaround could be to make a 'Default' snapshot within Sandboxie+ and have it revert itself each time but then the UI Info area never properly reflects the 'Empty' state as it contains data for the snapshot. [If 'Info' said something along the lines of 'Snapshot: blah' instead of "" (aka blank in the UI) after the snapshot gets applied (and hasn't been ran yet) it might help in other cases] but it'd still retain the problem of not having the pre-existing data from the users NTUSER.DAT unless manually added or otherwise changed via the programs own settings while running in the sandbox as 'another user'. Perhaps this is a more realistic option for those who 'install' the programs into the Sandbox and not things already existing on the host in this case?

Update2:
Checking more logs using ProcMon (and looking above areas I had bothered with before) has shown me that the hive does actually get mounted for a brief time, so the real issue seems to be that for some reason it's getting unmounted while the program is still running in a sandbox afterward... /Confused
Turns out that was due to my being lazy and using Forced Program (so it was the originally launched pid, not the one that was re-started inside the sandbox)
When using Start.exe like in the example above the 'New User' hive does also get mounted but after the target program has started in the sandbox but almost right after Start.exe exits the ProfSvc begins the process to unmount the related user hive(s). I currently still have no ideas as to why or what to try checking next. =(

Update3:
Thankfully it seems that we can run something else as the user OUTSIDE of sandboxie and the ProfSvc will, then, NOT unmount the hive and it is actually readable by the program in sandboxie. I'm guessing that my initial test of pre-mounting the NTUSER.dat to the normal HKU\SID location (and the UsrClass.dat to _Classes) failed due to it being done manually and the ProfSvc didn't reflect or share that. (The ProfSvc is still fairly opaque to me atm)
I'm toying with the idea of using a stub script that does nothing but 'sleep'
The gist being to launch the stub as the intended user first (OUTSIDE of the sandbox) and 'hold the door open' so that the issue is avoided while the target program is still running. This would also prevent the need to export\edit\re-import to mirror the existing data like in my initial workaround (Which I would have needed to re-do anytime something was changed).

OK, stub complete and integrated into my scripts. I can now have my cake and eat it too (in this regard anywho). Programs launched as other users into a sandbox can now retrieve what they need from their pre-existing-hives and behave as expected without any other manual intervention.

I'd love to get a better understanding of WHY it's happening if anyone has any ideas?

How often did you encounter it so far?

Anytime a program is launched as another user inside a sandbox

Expected behavior

The Secondary Users registry hive should be mounted & readable thus being able to return the requested values data if they actually exist (assuming there are no rules enabled which would prevent that)

Affected program

ANYTHING

Download link

Nothing Required

Where is the program located?

The program is installed only outside the sandbox.

Did the program or any related process close unexpectedly?

Not in this example but results varied depending on the program and what it needed on the real system (and how well it's written)

Crash dump

No response

What version of Sandboxie are you running now?

1.14.6 x64

Is it a new installation of Sandboxie?

I recently did a new clean installation.

Is it a regression from previous versions?

No response

In which sandbox type you have this problem?

In a standard isolation sandbox (yellow sandbox icon).

Can you reproduce this problem on a new empty sandbox?

I can confirm it also on a new empty sandbox.

What is your Windows edition and version?

Windows 10 x64

In which Windows account you have this problem?

The built-in Administrator account tested with "Admin Approval Mode for the Built-in Administrator account" both Enabled\Disabled (yes I rebooted) launching a Standard User in the Sandbox

Please mention any installed security software

Just Sandboxie in the VMs (Unless you count Windows Defender on the virgin install after the added 'Update:' section above). The first test VM (same one that had GP settings applied) had Defender disabled.

Did you previously enable some security policy settings outside Sandboxie?

Yes, even this VM had various GP settings applied, I have not yet tested on a VIRGIN install.
The tests after the 'Update:' above were done on a virgin install without any GP settings (or even any Windows Updates) and I noticed no real changes in behavior

Trace log

No response

Sandboxie.ini configuration

No response