Extracting Encrypted Credentials From Common Tools

The majority of cyberattacks rely on stolen credentials — obtained by either tricking employees and end-users into sharing them, or by harvesting domain credentials cached on workstations and other systems on the network. These stolen credentials give attackers the ability to move laterally within the environment as they pivot from machine to machine — both on-premises and cloud — until they reach business-critical assets.

In the Uber breach back in September, attackers found the credentials in a specific PowerShell script. But there are plenty of less flashy, yet just as damaging, ways attackers can find credentials that would allow them access to the environment. These include common local credentials, local users with similar passwords, and credentials stored within files on network shares.

In our research, we faced the question of what kind of information can be extracted from a compromised machine — without exploiting any vulnerabilities — in order to move laterally or extract sensitive information. All the tools we used here are available on our GitHub repository.

Organizations rely on several tools to authenticate to servers and databases using SSH, FTP, Telnet, or RDP protocols — and many of these tools save credentials in order to speed up authentication. We look at three such tools — WinSCP, Robomongo, and MobaXterm — to show how an attacker could extract non-cleartext credentials.

WinSCP: Obfuscated Credentials

When a domain controller is not available, a user can access system resources using cached credentials that were saved locally after a successful domain logon. Because the user previously was authorized, the user can log into the machine using the domain account via cached credentials even if the domain controller that authenticated the user in the past is not available.

WinSCP offers the option to save the credential details used to connect to remote machines via SSH. While the credentials are obfuscated when saved in the Windows registry (Computer\HKEY_CURRENT_USER\SOFTWARE\Martin Prikryl\WinSCP 2\Sessions), they are not encrypted at all. Anyone who knows the algorithm used to obfuscate can gain access to the credentials.

Since WinSCP’s source code is available on GitHub, we were able to find the obfuscation algorithm. 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.

Robomongo: Not a Secret Key

Robomongo (now Robo 3T) is a MongoDB client used to connect to Mongo database servers. When you save your credentials, they are encrypted and saved in a robo3t.json JSON file. The secret key used to encrypt the credentials is also saved locally, in cleartext, in a robo3t.key file.

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

We looked at Robomongo’s source code on GitHub to understand how the key is used to encrypt the password and learned that it uses the SimpleCrypt lib from Qt. While Robomongo uses encryption to securely store credentials, the fact that the secret key is saved in cleartext is not best practice. Attackers could potentially read it, because any user with access to the workstation can decrypt the credentials. Even if the information is encoded in a way that humans cannot read, certain techniques could determine which encoding is being used, then decode the information.

MobaXterm: Decrypting the Password

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. By default, MobaXterm requests the master password only on a new computer.

That means that the master password is saved somewhere, and MobaXterm will retrieve it to access the encrypted credentials. We used Procmon from the Sysinternals Suite to map all the registry keys and files accessed by MobaXterm, and we found the master password saved in the Windows registry (Computer\HKEY_CURRENT_USER\SOFTWARE\Mobatek\MobaXterm\M). Credentials and passwords are saved in the C and P registry keys, respectively.

Initially, we were unable to decrypt the master password, which was encrypted using DPAPI. We eventually figured out that the first 20 DPAPI bytes, which are always the same when using DPAPI, had been removed. When we added the first 20 bytes, we were able to decrypt the DPAPI cipher to obtain the SHA512 hash of the master password. This hash is used to encrypt and decrypt credentials.

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.

Know the Risks

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.

As always, there isn’t a magic solution that can solve every problem we’ve discussed here. Organizations might, however, begin by examining the services they are now using. They can construct an accurate risk matrix and be better prepared for data breaches by having a stronger understanding of the types of sensitive data and credentials they are storing.