Skip to content
HackIndex logo

HackIndex

Credential hunting in files

3 min read Feb 17, 2026

Start with high-signal locations and filename-based hits. Only widen the search when you have a reason.

High-yield paths

┌──(kali㉿kali)-[~]
└─$ ls -la /home 2>/dev/null
┌──(kali㉿kali)-[~]
└─$ ls -la /opt /srv /var/www 2>/dev/null
┌──(kali㉿kali)-[~]
└─$ ls -la /etc 2>/dev/null

What to do with results:

  • Custom app folders under /opt, /srv, /var/www usually contain configs and deploy artifacts with secrets.

  • /etc often contains service creds and integration tokens.

Find likely secret files by name

┌──(kali㉿kali)-[~]
└─$ find /home /opt /srv /var/www /etc -maxdepth 5 -type f 2>/dev/null \( -iname ".env" -o -iname "*.env" -o -iname "config.php" -o -iname "wp-config.php" -o -iname "settings.py" -o -iname "application.properties" -o -iname "application.yml" -o -iname "database.yml" -o -iname "config.yml" -o -iname ".git-credentials" -o -iname ".netrc" -o -iname ".npmrc" -o -iname ".pypirc" -o -iname "id_rsa" -o -iname "id_ed25519" -o -iname "*.pem" -o -iname "*.key" -o -iname "*kubeconfig*" \)

What you should see:

  • A short list of candidate files. Open them directly and look for reusable creds, tokens, endpoints, and internal hostnames.

Grep for secrets with a tight pattern set

Keep the pattern set focused to reduce junk.

┌──(kali㉿kali)-[~]
└─$ grep -RIn --binary-files=without-match -E "pass(word)?|passwd|pwd|token|secret|api[_-]?key|client[_-]?secret|bearer|authorization:|connectionstring|private[_-]?key" /etc /opt /srv /var/www /home 2>/dev/null | head -n 200

Interpretation that changes decisions:

  • Credentials plus a host or URL usually means immediate reuse. Note protocol and port, then test in the appropriate service phase later.

  • Connection strings often include database type, host, and credentials in one line. Pull them as-is and validate connectivity.

Git and deployment artifacts

┌──(kali㉿kali)-[~]
└─$ find /opt /srv /var/www /home -maxdepth 6 -type d -name ".git" 2>/dev/null

If you find a repo, look for secrets in committed history and configs:

┌──(kali㉿kali)-[~]
└─$ grep -RIn --binary-files=without-match -E "token|secret|pass(word)?|api[_-]?key" /opt /srv /var/www /home 2>/dev/null | head -n 200

Also check common CI/CD leftovers:

┌──(kali㉿kali)-[~]
└─$ find /opt /srv /var/www /home -maxdepth 6 -type f 2>/dev/null \( -iname "docker-compose*.yml" -o -iname "compose*.yml" -o -iname "Dockerfile" -o -iname "*.tf" -o -iname "*.tfvars" -o -iname "values*.yml" -o -iname "helmfile*.yml" \)

What to do next:

  • docker-compose and Helm values commonly carry DB/admin passwords and internal service names.

  • Terraform vars can include cloud keys. If you see cloud provider identifiers, pivot to the cloud metadata technique page if applicable.

Decision rule:

  • If the secret is for a local service, check whether that service is listening locally and whether the creds imply elevated roles.

  • If the secret is for a remote service, capture the full tuple: username, password or token, host, port, and any TLS hints.

References