Secret & Credential Extraction
Extract hardcoded credentials, API keys, cryptographic material, certificates, configuration secrets, and sensitive data from compiled binaries. This skill covers the full pipeline: string extraction, pattern matching, entropy analysis, crypto identification, format-specific extraction, and anti-analysis bypass.
Why This Matters
Hardcoded secrets in binaries are among the highest-impact findings in both penetration testing and malware analysis. A single embedded AWS key grants cloud access. A hardcoded database password opens the entire backend. An extracted C2 encryption key lets you decrypt all traffic. Developers embed secrets assuming compilation hides them -- it does not.
Methodology Overview
Execute these phases in order. Each phase feeds the next.
Phase 1 — Triage and Hash
Before touching strings, identify what you have. File type determines extraction strategy.
file <binary>
sha256sum <binary>
node ${CLAUDE_PLUGIN_ROOT}/scripts/binary-hasher.js hash <binary>
Record the hash. Check if this binary was already analyzed:
node ${CLAUDE_PLUGIN_ROOT}/scripts/analysis-tracker.js check <sha256> string-extraction
Phase 2 — Static String Extraction
Extract all readable strings. Start broad, then filter.
# ASCII strings, 6+ chars (reduces noise vs default 4)
strings -a -n 6 <binary> > strings_ascii.txt
# UTF-16 LE (Windows wchar_t, most common for Windows binaries)
strings -a -n 6 -el <binary> > strings_utf16.txt
# Combine and deduplicate
cat strings_ascii.txt strings_utf16.txt | sort -u > strings_all.txt
Count and triage:
wc -l strings_all.txt
# < 500 lines: review manually
# 500-5000: filter with patterns below
# > 5000: use targeted extraction only
Phase 3 — Obfuscated String Recovery
FLOSS recovers strings that strings cannot see: stack-built strings, tight loops, and runtime-decoded strings. This is where the real secrets hide.
# Full analysis (slow but thorough)
floss <binary>
# Stack strings only (fast, catches char-by-char construction)
floss --only stack <binary>
# Decoded strings (emulation-based, slowest, highest value)
floss --only decoded <binary>
# JSON output for automated processing
floss -j <binary> > floss_output.json
Phase 4 — Pattern Matching
Apply regex patterns to extracted strings. See references/credential-patterns.md for the full pattern library.
Critical patterns to always check:
# Cloud provider keys
grep -E 'AKIA[0-9A-Z]{16}' strings_all.txt # AWS Access Key
grep -E 'AIza[0-9A-Za-z_-]{35}' strings_all.txt # GCP API Key
grep -E 'AZURE[A-Za-z0-9+/=]{30,}' strings_all.txt # Azure tokens
# Authentication
grep -iE '(password|passwd|pwd)\s*[=:]\s*\S+' strings_all.txt
grep -E 'eyJ[A-Za-z0-9_-]+\.eyJ[A-Za-z0-9_-]+\.' strings_all.txt # JWT
grep -iE 'bearer\s+[A-Za-z0-9_\-\.]+' strings_all.txt
# Connection strings
grep -iE '(mysql|postgres|mongodb|redis)://[^"'\'']+' strings_all.txt
grep -iE 'Server=.*;.*Password=' strings_all.txt
# Private keys
grep -E 'BEGIN.*(PRIVATE KEY|RSA|EC|DSA|OPENSSH)' strings_all.txt
# API tokens (service-specific)
grep -E 'xox[bpsar]-[0-9a-zA-Z-]+' strings_all.txt # Slack
grep -E 'ghp_[0-9a-zA-Z]{36}' strings_all.txt # GitHub PAT
grep -E 'sk_live_[0-9a-zA-Z]{24,}' strings_all.txt # Stripe
Phase 5 — Entropy Analysis
High-entropy regions indicate encrypted data, compressed payloads, or embedded keys. Entropy above 7.5 bits/byte in a data section signals crypto material or packed content.
# Section-level entropy (radare2)
r2 -qc 'iS' <binary>
# Look for: .data or .rdata sections with entropy > 7.0
# Binwalk entropy visualization
binwalk -E <binary>
# Generates entropy graph — look for flat high-entropy plateaus (embedded encrypted blobs)
# Byte frequency analysis for specific offsets
r2 -qc 'p= 256 @ <offset>' <binary>
Entropy interpretation:
- 0-1: Null/zero-filled regions
- 1-4: Structured data, code, ASCII text
- 4-6: Compressed data or moderately random content
- 6-7.5: Likely compressed or encrypted
- 7.5-8.0: Strong encryption, truly random data, or crypto keys
Phase 6 — Cryptographic Material Identification
Find embedded crypto keys, constants, and algorithm signatures. See references/crypto-material.md for comprehensive constant tables.
# FindCrypt (radare2 plugin) — identifies crypto constants in binary
r2 -qc '/cr' <binary>
# YARA rules for crypto detection
yara -r crypto_signatures.yar <binary>
# Signsrch — finds known crypto/hash/compression signatures
signsrch <binary>
# Manual AES S-Box search (first 16 bytes of forward S-Box)
r2 -qc '/x 637c777bf26b6fc53001672bfed7ab76' <binary>
# Manual RSA public exponent search
r2 -qc '/x 010001' <binary>
Phase 7 — Binary Format-Specific Extraction
Different binary formats store secrets in different locations. See references/binary-format-extraction.md.
PE (Windows):
# Extract resources (configs, certs, embedded files)
r2 -qc 'ir' <binary>
# .rsrc section often contains XML configs, embedded binaries, certificates
# .rdata contains read-only strings, vtables, and often crypto constants
# Overlay data (appended after PE) may contain encrypted payloads
binwalk <binary> # Shows overlay and embedded file signatures
ELF (Linux):
# .rodata section contains string literals and constants
r2 -qc 'iS~.rodata' <binary>
# Extract .rodata content
objcopy -O binary --only-section=.rodata <binary> rodata.bin
strings -a -n 6 rodata.bin
Firmware:
# Extract embedded filesystems, certificates, configs
binwalk -e <binary>
# Recursively scan extracted directories for secrets
find _<binary>.extracted/ -type f | xargs strings -a -n 6 | grep -iE 'password|secret|key|token'
Phase 8 — Anti-Analysis Bypass
When secrets are encrypted or obfuscated at rest in the binary, you must defeat the protection layer. See references/anti-analysis-bypass.md.
Common approaches:
- XOR encoding: Try single-byte XOR brute force (256 iterations) looking for known plaintext
- Custom encryption: Identify the decryption function in disassembly, extract the key
- Runtime decryption: Set breakpoints after decryption routines to capture plaintext
- Config blobs: Locate the encrypted config block, find the decryption routine, extract key + IV
# XOR brute force with known plaintext
r2 -qc 'woF 0x00 0xff @ <offset> !<size>' <binary>
# Find XOR loops in disassembly
r2 -qc 'aaa; /ai xor' <binary>
Recording Findings
Log every extracted secret immediately. Use severity guidelines to classify.
# Add a secret finding
node ${CLAUDE_PLUGIN_ROOT}/scripts/findings-tracker.js add \
"<binary-name>" "<type>" "<value>" "<severity>" "<title>" --db secrets
Finding Types
| Type | Use For |
|---|---|
api-key | Cloud provider keys, service API keys, access tokens |
credential | Usernames + passwords, connection strings, auth pairs |
crypto-key | AES/RSA/EC keys, IVs, salts, HMAC secrets |
token | JWT, OAuth, bearer, session tokens |
url | C2 endpoints, callback URLs, API endpoints |
ip | Hardcoded IP addresses (especially non-RFC1918) |
filepath | Paths revealing internal infrastructure |
registry-key | Windows registry persistence or config keys |
wallet | Cryptocurrency wallet addresses |
certificate | Embedded X.509 certs, PEM blocks, PKCS bundles |
Severity Classification
| Severity | Criteria | Examples |
|---|---|---|
CRITICAL | Direct access to systems/data, no additional auth needed | Private keys, admin passwords, DB connection strings with creds, cloud root keys |
HIGH | Significant access, may need context to exploit | API keys with broad permissions, JWT signing secrets, encryption keys, service account creds |
MEDIUM | Li |