# Credential hunting in files

> Techniques for locating stored credentials in Linux files, configs, logs, and history files during post-exploitation to escalate privileges or move laterally.

- **URL:** https://hackindex.io/platforms/linux/post-exploitation/credentials/credential-hunting-in-files
- **Path:** Linux > Post-Exploitation > Credentials
- **Up:** [Credentials](https://hackindex.io/platforms/linux/post-exploitation/credentials.md)
- **Published:** 2026-02-17
- **Updated:** 2026-08-11

> [!WARNING]
> Run these techniques only on systems you are explicitly authorized to test. Treat any recovered credentials and copied config files as sensitive data and follow the engagement’s rules for storage, transfer, and deletion.

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

## High-yield paths

```bash
ls -la /home 2>/dev/null
ls -la /opt /srv /var/www 2>/dev/null
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

```bash
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.

```bash
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

```bash
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:

```bash
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:

```bash
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

- [GNU grep manual](https://www.gnu.org/software/grep/manual/grep.html) - Pattern and recursion behavior
- [find(1) manual](https://man7.org/linux/man-pages/man1/find.1.html) - Filename filters and predicates