secret-extraction

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:

1. XOR encoding: Try single-byte XOR brute force (256 iterations) looking for known plaintext
2. Custom encryption: Identify the decryption function in disassembly, extract the key
3. Runtime decryption: Set breakpoints after decryption routines to capture plaintext
4. 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