{"id":8666,"date":"2021-06-04T01:13:03","date_gmt":"2021-06-03T23:13:03","guid":{"rendered":"https:\/\/tajdini.net\/blog\/?p=8666"},"modified":"2021-06-04T01:18:12","modified_gmt":"2021-06-03T23:18:12","slug":"dumping-rdp-credentials","status":"publish","type":"post","link":"https:\/\/tajdini.net\/blog\/governance-risk-and-compliance\/dumping-rdp-credentials\/","title":{"rendered":"Dumping RDP Credentials"},"content":{"rendered":"\n

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.<\/p>\n\n\n\n

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:<\/p>\n\n\n\n

  1. svchost.exe<\/li>
  2. mstsc.exe<\/li><\/ol>\n\n\n\n

    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.<\/p>\n\n\n\n

    svchost<\/h2>\n\n\n\n

    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<\/a>. 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.<\/p>\n\n\n\n

    Querying the terminal service:<\/p>\n\n\n\n

    sc queryex termservice<\/code><\/pre>\n\n\n\n
    \"\"
    svchost Identification \u2013 Service Query<\/figcaption><\/figure>\n\n\n\n
    Querying which task has loaded the rdpcorets.dll:<\/p>\n\n\n\n
    tasklist \/M:rdpcorets.dll<\/code><\/pre>\n\n\n\n
    \"\"
    svchost Identification \u2013 RDP Core DLL<\/figcaption><\/figure>\n\n\n\n
    Running netstat:<\/p>\n\n\n\n
    netstat -nob | Select-String TermService -Context 1<\/code><\/pre>\n\n\n\n
    \"\"
    svchost Identification \u2013 netstat<\/figcaption><\/figure>\n\n\n\n
    Looking at the memory strings of the process the password is displayed below the username.<\/p>\n\n\n\n
    \"\"
    Memory Strings<\/figcaption><\/figure>\n\n\n\n
    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.<\/p>\n\n\n\n
    procdump64.exe -ma 988 -accepteula C:\\Users\\mahyarLab<\/code><\/pre>\n\n\n\n
    \"\"
    Memory Dumping \u2013 Process Dump<\/figcaption><\/figure>\n\n\n\n
    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.<\/p>\n\n\n\n
    strings -el svchost* | grep Password123 -C3<\/code><\/pre>\n\n\n\n
    \"\"
    Discovery of Password in Memory Dump<\/figcaption><\/figure>\n\n\n\n
    The above method doesn\u2019t 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:<\/p>\n\n\n\n
    privilege::debug\nts::logonpasswords<\/code><\/pre>\n\n\n\n
    \"\"
    Mimikatz \u2013 RDP Credentials<\/figcaption><\/figure>\n\n\n\n
    mstsc<\/h2>\n\n\n\n
    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<\/a> has developed a proof of concept tool called RdpThief<\/a> 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<\/a> in the MDSec website.<\/p>\n\n\n\n
    From a system that has been compromised and the mstsc.exe is running the DLL needs to be injected into the process.<\/p>\n\n\n\n
    SimpleInjector.exe mstsc.exe RdpThief.dll<\/code><\/pre>\n\n\n\n
    \"\"
    RdpThief.dll \u2013 DLL Injection<\/figcaption><\/figure>\n\n\n\n
    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.<\/p>\n\n\n\n
    \"\"
    CredPrompt<\/figcaption><\/figure>\n\n\n\n
    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.<\/p>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    The tool has been rewritten in C# by Josh Magri<\/a>. However comparing to RdpThief, SharpRDPThief<\/a> 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.<\/p>\n\n\n\n
    \"\"
    SharpRDPThief<\/figcaption><\/figure>\n\n\n\n
    RDP Files<\/h2>\n\n\n\n
    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.<\/p>\n\n\n\n
    \"\"
    Credential Manager<\/figcaption><\/figure>\n\n\n\n
    The location of the Windows Credentials on the disk is the following:<\/p>\n\n\n\n
    C:\\Users\\username\\AppData\\Local\\Microsoft\\Credentials<\/code><\/pre>\n\n\n\n
    \"\"
    Windows Credentials Location<\/figcaption><\/figure>\n\n\n\n
    The file can be viewed through the Mimikatz binary:<\/p>\n\n\n\n
    dpapi::cred \/in:C:\\Users\\mahyarLab\\AppData\\Local\\Microsoft\\Credentials\\ACC240EEE479C1B634EC496F9838074B<\/code><\/pre>\n\n\n\n
    \"\"
    DPAPI Credentials \u2013 Mimikatz<\/figcaption><\/figure>\n\n\n\n
    The \u201cpbData<\/em>\u201d 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 \u201cguidMasterKey<\/em>\u201d 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.<\/p>\n\n\n\n
    sekurlsa::dpapi<\/code><\/pre>\n\n\n\n
    \"\"
    Mimikatz \u2013 DPAPI Master Key<\/figcaption><\/figure>\n\n\n\n
    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.<\/p>\n\n\n\n
    dpapi::cred \/in:C:\\Users\\mahyarLab\\AppData\\Local\\Microsoft\\Credentials\\ACC240EEE479C1B634EC496F9838074B\n\/masterkey:05d8e693421698148d8a4692f27263201f1c65e0b3ac08e3be91ea75f43e71e9b398e2418ba0f0c62ea70a317bdba88f11da3adebd07d65d2b349f933eab85e1<\/code><\/pre>\n\n\n\n
    \"\"
    DPAPI \u2013 Decrypting Credentials<\/figcaption><\/figure>\n\n\n\n
    Executing the following command will provide the details in which server these credentials belong.<\/p>\n\n\n\n
    vault::list<\/code><\/pre>\n\n\n\n
    \"\"
    Mimikatz \u2013 Vault List<\/figcaption><\/figure>\n","protected":false},"excerpt":{"rendered":"
    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 […]<\/p>\n","protected":false},"author":1,"featured_media":8687,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[225,229,235],"tags":[250,259,204,180,275,176],"class_list":["post-8666","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-governance-risk-and-compliance","category-network-and-protocol-security","category-windows-and-server","tag-grc","tag-network-security","tag-nist","tag-rdp","tag-threat-detection","tag-windows"],"_links":{"self":[{"href":"https:\/\/tajdini.net\/blog\/wp-json\/wp\/v2\/posts\/8666","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/tajdini.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/tajdini.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/tajdini.net\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/tajdini.net\/blog\/wp-json\/wp\/v2\/comments?post=8666"}],"version-history":[{"count":2,"href":"https:\/\/tajdini.net\/blog\/wp-json\/wp\/v2\/posts\/8666\/revisions"}],"predecessor-version":[{"id":8689,"href":"https:\/\/tajdini.net\/blog\/wp-json\/wp\/v2\/posts\/8666\/revisions\/8689"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/tajdini.net\/blog\/wp-json\/wp\/v2\/media\/8687"}],"wp:attachment":[{"href":"https:\/\/tajdini.net\/blog\/wp-json\/wp\/v2\/media?parent=8666"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/tajdini.net\/blog\/wp-json\/wp\/v2\/categories?post=8666"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/tajdini.net\/blog\/wp-json\/wp\/v2\/tags?post=8666"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}