Download our Capabilities Brief

Schedule a Call

7 Locations for Unsecured Credentials

Home Blog

7 Locations for Unsecured Credentials

Table of Contents

Low Hanging Fruit

Secured’s Cybersecurity Case Study explains that malicious actors often target easily exploitable or “low hanging fruit” vulnerabilities. We call these vulnerabilities “The Three P’s”:  

  • Patch Management 
  • Policies and Procedures 
  • Passwords 

Each of these “Three P’s” have their own list of common areas to check for vulnerabilities. Password vulnerabilities are wide ranging, and can include default or weak passwords, which can expose a variety of remote access services like SMB, RDP, FTP, SQL, and SSH. Unsecured credentials are typically targeted by attackers that have already gained access to a network. Attackers can use unsecured credentials to gain higher user privileges, access different services, and pivot within a network. Malicious actors and penetration testers typically target 7 common areas to gather unsecured credentials:

  1. Credentials in Files 
  2. Credentials in Registry 
  3. Command History  
  4. Private Keys 
  5. Cloud Instance Metadata API 
  6. Container API 
  7. Group Policy Preferences 
This list is based off techniques listed in the MITRE ATT&CK knowledge base.
Each section provides examples on how to verify that your credentials are not stored in easily accessible locations. The final example, Group Policy Preferences, includes a guided example that demonstrates how an open SMB share with a saved password in Group Policy Preferences can be accessed.

Credentials in Files

After an initial network compromise, attackers can search for files that store passwords. These files could be backup files, configurations files and web application files. For example, an attacker could gain access to a web server and search for passwords to a database that is used by the web server. 

The findstr Windows command searches for text patterns in files. Findstr can be set to search the current directory and all subdirectories (/s) and ignore character case (/i) while searching for the string “password”. The wildcard character * can be used to match any character, which allows for searching for all files names with specific file extensions: 

     findstr /si ‘password’ *.txt *.xml *.docx  
Linux’s find and grep commands can search for passwords either by targeting filenames or strings in files.  
A Linux search for “password” string in .conf files: 
     grep “password” /etc/*.conf 2> /dev/null 
A Linux search for files of .txt extension with password in their name: 
     find / -name password*.txt 2> /dev/null 
Grep can also filter following a cat command. This example targets an Apache web server’s access logs: 
     cat /var/log/apache/access.log | grep –E “^user|^pass” 
Attackers also utilize tools like LaZagne, an open-source tool that gathers credentials from a variety of applications. 

Credentials in Windows Registry

Windows Registry, as Microsoft explains, “contains information that Windows continually references during operation, such as profiles for each user, the applications installed on the computer and the types of documents that each can create, property sheet settings for folders and application icons, what hardware exists on the system, and the ports that a being used.”

MITRE highlights two example commands:  
     Local Machine Hive: reg query HKLM /f password /t REG_SZ /s 
This searches for the HKLM: HKEY_LOCAL_MACHINE. The HKEY, or Hive Key, for a local machine includes configuration information for that computer. This is a regular query. The /f specifies the pattern to search is password. The /t specifies the registry type to search. REG_SZ is a registry type used by Windows registry to store string data. The /s specifies searching recursively.  
     Current User Hive: reg query HKCU /f password /t REG_SZ /s 
HKCU stands for HKEY_CURRENT_USER. This configuration information targets the user who is currently logged on. It also recursively searches for the string “password”.

Command History

MITRE lists bash command history, but this category can also include Windows PowerShell console history. In Unix systems Bash saves command-line input in a .bash_history file, which is erased when a user logs out. Users often type their credentials in cleartext in command-line when accessing different services or during failed password attempts.  
Example Unix system commands include attempting to read admin (root) or other users’ bash history.  
Check permissions of root’s .bashrc and other dot files/directories: 
     ls –las /root/.* 
Read root’s .bash_history file: 
     cat /root/.bash_history 
Search for history files: 
     find /* -name *.*history* -print 2> /dev/null 
Read any other users’ .bash_history files: 
     find /home/* -name *.*history* – print 2> /dev/null 
Window’s users can view their PowerShell command history and locate cleartext credentials in the ConsoleHost_history.txt file.  
Change to PSReadLine:  
     PS C:\> cd $env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ 
The type command can be used read the file ConsoleHost_history.txt.  
This file can also be located with the PowerShell command:  
     (Get-PSReadlineOption).HistorySavePath  
To practice, check out HackTheBox’s retired machine Archetype.  

Private Keys

Private keys and certificates include: .key, .pgp, .gpg, .ppk., .p12, .pem, .pfx, .cer, .p7b, .asc. Attackers can search by file extension or specifically target SSH key directories. In Linux, SSH keys are stored in  ~/.ssh and in Windows:  C:\Users\(username)\.ssh\. These various keys and certificates can be used for remote access and to decrypt files.  
Check for access to users’ .ssh directories using Linux command-line: 
     ls –la /home/*/.ssh 
Read users’ SSH keys using Linux command-line: 
     cat /home/*/.ssh/id*   

Cloud Instance Metadata API

MITRE explains: “Most cloud service providers support a Cloud Instance Metadata API which is a service provided to running virtual instances that allows applications to access information about the running virtual instance. Available information generally includes name, security group, and additional metadata including sensitive data such as credentials and UserData scripts that may contain additional secrets.”  
Attackers can target the API and search for credentials or also target a web proxy through Server-Side Request Forgery (SSRF). 
The Instance Metadata service uses the IPv4 address: 169.254.169.254 
For AWS EC2 instances over IPv6, the address would be: fd00:ec2::254. 
AWS issues a clear warning that states anyone with access to the cloud instance can view metadata. AWS specifically warns, “you should not store sensitive data, such as passwords or long-liven encryption keys, as user data”: 

Container API

Attackers can also target Container APIs for credentials. Common targets include Docker and Kubernetes APIs.  Attackers can target the Docker API to collect logs with credentials.  Attackers could initially compromise a machine and gather Kubernetes token and configurations from ~/.kube which would allow them to connect to the API server and gather more credentials from the server.  
One example tool is Peirates which is a post-exploitation Kubernetes exploitation framework.  

Group Policy Preferences

Group Policy Preferences (GPP) allow Windows administrators to create domain policies with embedded credentials. These policies include modifying users and groups across the network and are stored in in SYSVOL directory on a domain controller in a file called Groups.xml The password is AES encrypted but in 2012 the key was published by Microsoft  and can be easily decrypted. In 2014 Microsoft released a security bulletin (MS14-025) about this privilege escalation vulnerability. This bulletin listed these potentially vulnerable Windows editions: Windows Vista, Windows 7, Windows 8, Windows 8.1, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2. The security update removed “the ability to configure and distribute passwords that use certain Group Policy preferences extensions.”

MITRE mentions these three tools and scripts: 

  • Metasploit’s post exploitation module: post/windows/gather/credentials/gpp 
  • Get-GPPPassword 
  • gpprefdecrypt.py 

The Linux command line tool gpp-decrypt can also be used to decrypt the GPP password. The Groups.xml file can be searched for in SYSVOL using the command:  dir /s * .xml 

Walkthrough: Group Policy Preferences

This walkthrough uses the retired HackTheBox machine Active. In this scenario an open SMB share includes a GPP password in the Groups.xml file. This password can be decrypted with gpp-decrypt.

The target IP is 10.10.10.100. Smbmap, smbclient, enum4linux, and crackmapexec can be used to check for open access and guest access:

enum4linux -a  -u “” -p “” 10.10.10.100 && enum4linux -a -u “guest” -p “” 10.10.10.100

This shows the Replication share can be accessed with no authentication required. In this scenario, the Replication share is a copy of the SYSVOL directory, which includes GPP. 

Smbclient can be used connect to Replication share:

After locating the Groups.xml, the file can be downloaded with the get command. The tool smbget can also be used to download files from SMB: smbget smb://<host>/<PATHtoFILE>/Groups.xml

The cat command shows the encrypted password for SVC_TGS:

Finally the gpp-decrypt tool decrypts the password into plaintext:

Attackers can use these credentials to gain further access and privileges. Some common next steps include further enumeration of SMB shares, using bloodhoud, kerberoasting, enumerating DNS, enumerating Active Directory Certificate Services, and targeting known privilege escalation vulnerabilities for printers, Kerberos KDC, and  Active Directory.