Administrators typically use Remote Desktop Protocol (RDP) in order to manage Windows environments remotely. It is also typical RDP to be enabled in systems that act as a jumpstation to enable users to reach other networks. However even though this protocol is widely used most of the times it is not hardened or monitor properly.
From red teaming perspective dumping credentials from the lsass process can lead either to lateral movement across the network or directly to full domain compromise if credentials for the domain admin account have been stored. Processes which are associated with the RDP protocol can also be in the scope of red teams to harvest credentials. These processes are:
The above processes can be targeted as an alternative method to retrieve credentials without touching lsass which is a heavily monitored process typically by endpoint detection and response (EDR) products.
The service host (svchost.exe) is a system process which can host multiple services to prevent consumption of resources. When a user authenticates via an RDP connection the terminal service is hosted by the svchost process. Based on how the Windows authentication mechanism works the credentials are stored in memory of the svchost process in plain-text according to the discovery of Jonas Lyk. However, looking at the process list, there are multiple svchost processes so identification of which process, hosts the terminal service connection can be achieved by executing one of the following commands.
Querying the terminal service:
Querying which task has loaded the rdpcorets.dll:
Running netstat:
Looking at the memory strings of the process the password is displayed below the username.
Process dump from Sysinternals can be used also to dump the memory by specifying the PID and the directory which the .dmp file will be written.
The .dmp file can be transferred to another host for offline analysis. Performing a simple grep will identify the password stored in the memory file below the username.
The above method doesn’t consider fully reliable and it is still unknown in which conditions the credentials are maintained in the svchost process. However, Mimikatz support the retrieval of credentials from existing RDP connections by executing the following:
The mstsc.exe process is created when a user opens the remote desktop connection application in order to connect to other systems via the RDP protocol. API hooking could be used to intercept the credentials provided by the user and use them for lateral movement. Rio Sherri has developed a proof of concept tool called RdpThief which attempts to hook the functions used by mstsc process (CredIsMarshaledCredentialW & CryptProtectMemory) in order to retrieve the credentials and write them into a file on the disk. Details of the tool can be found in an article in the MDSec website.
From a system that has been compromised and the mstsc.exe is running the DLL needs to be injected into the process.
Once the user enter the credentials for authentication to the destination host these will be captured and written into a file on the C:temp folder.
The file creds.txt will include also the IP address. This information could be utilized to move laterally across the network or even to escalate privileges if an elevated account is used.
The tool has been rewritten in C# by Josh Magri. However comparing to RdpThief, SharpRDPThief uses an IPC server in order to receive the credentials from the mstsc.exe process. In the event that the mstsc.exe is terminated the server will continue to run and when the process is initiated again will attempt to perform the hooking. This removes the limitation that RdpThief had that the process should already exist.
RDP Files
Users that tend to authenticate multiple times to a particular host via an RDP connection they might save the connections details for quick authentication. These credentials are stored in an encrypted form in the Credential Manager of Windows by using the Data Protection API.
The location of the Windows Credentials on the disk is the following:
The file can be viewed through the Mimikatz binary:
The “pbData” field contains the information in an encrypted form. However the master key for decryption is stored in the lsass and can be retrieved by executing the following Mimikatz module. The “guidMasterKey” is also important as multiple entries might exist when the lsass is queried and it is needed to match the GUID with the Master Key.
Executing again the dpapi::cred module with the master key switch will have as a result the decryption of the contents and the RDP credentials to be disclosed in plain-text.
Executing the following command will provide the details in which server these credentials belong.
This content was originally published here.