Critical Unauthorized Execution of Sensitive RAS App ("Active Directory Users and Computers")

[ericw144]

Hello Support Team,
I'm reporting a critical security issue with a published app on RAS. The app "Active Directory Users and Computers" is executing under user account "z20xxx", to whom I have not granted access.
Details/Evidence:
A screen snippet shows a disconnected session for "z20xxx" running this app.
Clicking "Show User Processes" confirms the app is executing.
What I've verified:
An "Effective Access" test for "z20xxx" shows no access to this app.
This app is highly sensitive, with access strictly limited to a few IT staff. I need to understand how this occurred.

Question: Can you advise on steps to investigate why this user can execute the app (e.g., logs, audits, or configuration checks)?

 

[Thierry FRACHE]

Hi,

We tried to reproduce this behavior in our own Parallels RAS lab.
We published Active Directory Users and Computers using:
Program:
C:\Windows\System32\mmc.exe
Parameters:
C:\Windows\System32\dsa.msc

The application is correctly executed in the user context. When a user is not allowed to access the published application through RAS filtering, the shortcut is not visible and the user cannot launch the published resource from the RAS client/portal.
So, based on our test, RAS filtering seems to work as expected.
One important point is that ADUC is only an MMC snap-in. If the user has access to another published desktop or another application that allows launching mmc.exe, Explorer, cmd, PowerShell, or any kind of shell escape, they may still be able to open MMC manually and add the "Active Directory Users and Computers" snap-in from there.
In that case, the process will still appear as mmc.exe running inside the user session, but it does not necessarily mean that the restricted RAS published application was launched.

I would suggest checking:

• whether ADUC appears as a running published resource in RAS, or only as a Windows process
• the parent process of mmc.exe on the RDSH server
• Windows process creation events, especially Event ID 4688 with command line auditing enabled
• whether the user has access to a full desktop or another published application that allows starting MMC
• whether RSAT / ADUC is installed on RDSH servers used by standard users
  

From a security point of view, I would not rely only on RAS publishing rules for this kind of sensitive tool. ADUC should ideally be installed only on dedicated admin RDSH servers, with logon restricted to admin users. Alternatively, MMC and sensitive snap-ins should be restricted using GPO, AppLocker, or WDAC.
So my current understanding is: this may not be a RAS authorization bypass, but rather a Windows/MMC lockdown issue on the RDSH server.
That's all folks !

 

[ericw144]

Hi,

We tried to reproduce this behavior in our own Parallels RAS lab.
We published Active Directory Users and Computers using:
Program:
C:\Windows\System32\mmc.exe
Parameters:
C:\Windows\System32\dsa.msc

The application is correctly executed in the user context. When a user is not allowed to access the published application through RAS filtering, the shortcut is not visible and the user cannot launch the published resource from the RAS client/portal.
So, based on our test, RAS filtering seems to work as expected.
One important point is that ADUC is only an MMC snap-in. If the user has access to another published desktop or another application that allows launching mmc.exe, Explorer, cmd, PowerShell, or any kind of shell escape, they may still be able to open MMC manually and add the "Active Directory Users and Computers" snap-in from there.
In that case, the process will still appear as mmc.exe running inside the user session, but it does not necessarily mean that the restricted RAS published application was launched.

I would suggest checking:

• whether ADUC appears as a running published resource in RAS, or only as a Windows process
• the parent process of mmc.exe on the RDSH server
• Windows process creation events, especially Event ID 4688 with command line auditing enabled
• whether the user has access to a full desktop or another published application that allows starting MMC
• whether RSAT / ADUC is installed on RDSH servers used by standard users

From a security point of view, I would not rely only on RAS publishing rules for this kind of sensitive tool. ADUC should ideally be installed only on dedicated admin RDSH servers, with logon restricted to admin users. Alternatively, MMC and sensitive snap-ins should be restricted using GPO, AppLocker, or WDAC.
So my current understanding is: this may not be a RAS authorization bypass, but rather a Windows/MMC lockdown issue on the RDSH server.
That's all folks !

Thank you, Thierry.
ADUC is delibrately installed and published as single app via RAS console by RAS admin, I'm relieved domain admin confirmed me and varifyed that domain users are explicitly blocked to access ActiveDirectory information earlier. Just curious why app record appears though, you hinted me that user may directly RDP into the windows RDSH where ADUC is installed, we will enhanced the access on the RDSH: Block mmc.exe by GPO, block directly rdp to RDSH, allow only RAS Gateway. I'll monitor the environment and confirm whether the records continue to appear.