Extracting Encrypted Credentials from Common Tools

Getting your Trinity Audio player ready...

Overview

During our day to day research, we face the question of what can be extracted from a  compromised machine in order to move laterally or extract sensitive information.

Organizations use multiple tools to authenticate to servers and databases using SSH, FTP, TELNET or RDP protocols. These tools offer a way to save credentials in order to authenticate more quickly.

In this blog post, we will show how an attacker can extract non cleartext credentials in order to authenticate to databases and servers.

We will cover the following tools:

• WinSCP
• RoboMongo
• MobaXterm

Note

We used reverse engineering techniques to understand how the credentials are decrypted by the different tools. The methods described here do not involve exploitation of vulnerabilities.

WinSCP

The first tool we looked at was WinSCP. It offers the option to save the credential details used to connect to remote machines via SSH. WinSCP obfuscates the credentials and saves them in the Windows registry. The credentials are not encrypted at all, and anyone who knows the algorithm used to obfuscate can gain access to the credentials. 

The credentials saved in the registry:

Computer\HKEY_CURRENT_USER\SOFTWARE\Martin Prikryl\WinSCP 2\Sessions

WinSCP’s source code is available on GitHub, and we found the obfuscation algorithm used:

https://github.com/winscp/winscp/blob/master/source/core/Security.cpp

We used a tool that implemented the same algorithm to de-obfuscate the credentials, and we gained access to the credentials in cleartext:

Implementing an obfuscation algorithm to secure credentials stored is not best practice, as it can be easily reversed and lead to credentials theft. Let’s see if the next tool analyzed uses a better approach to secure credentials storage.

RoboMongo

RoboMongo is a MongoDB client used to connect to Mongo database servers. When you save your credentials, they are encrypted and saved in a JSON file:

%USERPROFILE%\.3T\robo-3t\1.4.4\robo3t.json

However, the secret key used to encrypt the credentials is also saved in a file, in cleartext:

%USERPROFILE\.3T\robo-3t\robo3t.key: 

That means that an attacker who gains access to a machine can use the key saved in cleartext to decrypt the credentials. 

RoboMongo is open source, so we decided to look at the source code, which is available on GitHub to understand how the key is used to encrypt the password. We found that the  SimplCrypt lib from Qt is used to encrypt and decrypt the credentials:

https://github.com/Studio3T/robomongo/blob/master/src/robomongo/utils/SimpleCrypt.cpp

This library is accessible to everyone, so we can use it to decrypt the credentials:

RoboMongo uses encryption to securely store credentials, but the secret key is saved in cleartext, which is also not best practice. The key is stored in cleartext and any user with access to the workstation can decrypt the credentials. Let’s see another tool and analyze how the credentials are saved.

MobaXterm

MobaXTerm is a powerful tool to connect to remote machines using various protocols such as SSH, Telnet, RDP, FTP and so on. A user who wants to save credentials within MobaXTerm will be asked to create a Master Password to protect their sensitive data. 

The default option is that MobaXTerm will ask to enter this Master Password only on a new computer:

That means that the Master Password is saved somewhere, and MobaXTerm will retrieve it to access the credentials saved encrypted. We used Procmon from the Sysinternals Suite to map all the registry key and files accessed by MobaXTerm, and we found that the Master Password is saved in the following registry entry:

Computer\HKEY_CURRENT_USER\SOFTWARE\Mobatek\MobaXterm\M

Credentials and Passwords are saved in the C and P registry keys respectively, while the M registry key contains the Master Password.

The Master Password seems to be encrypted using DPAPI, but we failed to decrypt it. 

After decoding it with base64, and comparing it with a standard encrypted password with DPAPI, we understood that the first twenty DPAPI bytes, which are always the same, have been removed. 

You can see below, the first line is a cipher that we have encrypted using DPAPI and the second line is the encrypted value found in the registry.

After shifting it to the right, we can see that the bytes are identical. Effectively, encrypted data with DPAPI consistently has has first constant ~60 bytes metadata.

We added the first twenty bytes, and we succeeded in decrypting the DPAPI cipher, and it corresponds to the SHA512 hash of the Master Password. This hash is used to encrypt and decrypt credentials. 

We wrote a tool that can decrypt the saved credentials using the methods described above:

Here, the encryption key used to securely store the credentials is saved using DPAPI. That means that only the user who saved the credentials can access them. However, a user with administrator access, or an attacker who gains access to the victim’s session can also decrypt the credentials stored on the machine.

Open Source Tool

All the tools used above are available in open source on our Github repo. Just run it and you will get all the credentials saved in cleartext.
Keep updated with the tool – we’ll be adding more capabilities in the future!

https://github.com/XMCyber/XMCredentialsDecryptor

Summary

Developers, DevOps and IT use various tools to connect to remote machines and manage these access details. Vendors have to store this sensitive information in the most secure way. However, encryption is always on the client side, and an attacker can replicate the tool behavior in order to decrypt the credentials.

References:

https://docs.microsoft.com/en-us/sysinternals/

https://github.com/AlessandroZ/LaZagne

https://medium.com/xm-cyber/decrypting-vmware-workstation-passwords-for-fun-f34284c5b9cd