/credential-attack

name: credential-attack
description: Password spray methodology for bug bounty — when to do it vs web-vuln hunting, the wordlist-gen + breach-check + osint-employees + spray pipeline, mode selection (http-form / oauth / o365 / okta), rate-limit + lockout tactics, BBP legal guardrails, success detection, and the spray → authenticated /hunt chain pattern. Use when assessing whether credential attack is worth running on a target, picking the right mode, or recovering from common pitfalls.

CREDENTIAL ATTACK PIPELINE

Real-world initial-access vector. Verizon DBIR consistently ranks Stolen Credentials in the top 3 incident types. Most BB hunters skip this because they only try `rockyou.txt` and get rate-limited.

**Core principle:** humans pick lazy passwords. `{CompanyName}{Year}!`, `{ProductName}{Season}`, `{City}123`. Harvesting company-specific vocabulary (product names, office cities, internal project codes) before spraying is what makes the hit-rate go from 0.01% to 1%+.

This skill covers WHEN to use credential attack, HOW to chain the 4 commands, and the legal/operational guardrails.

---

WHEN TO RUN CREDENTIAL ATTACK

Credential attack is a **parallel branch** to `/hunt`, not a replacement. Both come after `/recon`:

/recon ──┬──▶ /hunt (web vuln scan)         ──┐
         │                                     ├──▶ /validate ──▶ /report
         └──▶ /wordlist-gen → ... → /spray  ──┘

**Run it when:**

• Target has a discoverable login endpoint (web form / O365 / Okta / OAuth)
• Program scope **explicitly permits** authentication testing or credential testing
• You can stomach a 30-min-to-multi-hour run (with conservative defaults)

**Skip it when:**

• Program policy lists "credential stuffing", "brute force", or "password attacks" as out-of-scope (this is the majority)
• Target only has SSO via a provider you don't control (e.g., "Login with Google")
• The login endpoint is rate-limited so aggressively that even 1 attempt/30min triggers alerts

**KILL signals (don't even start):**

• No login surface in recon output
• WAF (Cloudflare with Bot Management, Akamai) on every auth endpoint
• Program runs an active red-team — they'll see your spray immediately
• You don't have a clean wordlist yet (running rockyou.txt is a waste of lockouts)

---

THE 4-STAGE PIPELINE

/wordlist-gen     ──▶  /breach-check     ──▶  /osint-employees   ──▶  /spray
(company words)        (rank by HIBP)         (real usernames)         (live attempts)

You can run stages 1+2 in parallel with stage 3 (they share no inputs).

Stage 1 — `/wordlist-gen <target>`

Crawls the target website with `cewler`, deduplicates, applies hashcat rules to mutate (`flexdemo` → `flexdemo!`, `Flexdemo`, `flexdemo123`, `flexdemo2025`...).

**Mode selection:**

| Mode | Rules | When | |---|---|---| | `minimal` | top10_2025 (10 rules) | Cautious spray, paranoid program | | `balanced` *(default)* | best66 (66 rules) | Standard — best signal/noise | | `aggressive` | OneRuleToRuleThemAll (52k) | **Offline cracking only**, NOT spray (too many candidates) |

**Filter selection:**

| Filter | When | |---|---| | `strict` *(default)* | API-doc-heavy sites (Twilio, Stripe). Drops CSS hex colors, URL slugs, random API tokens that cewler harvests as "words" | | `loose` | Marketing sites without API examples — keeps everything cewler found |

**Output:** `recon/<target>/wordlists/ranked.txt` — typically 50k-500k candidates depending on site size.

---

Stage 2 — `/breach-check <wordlist>`

Sends only first 5 chars of SHA-1 to HIBP (k-anonymity), enriches each password with its real-world breach count. **Free, no API key, full passwords never leave your machine.**

**Breach-count interpretation:**

| Range | Meaning | Spray strategy | |---|---|---| | **0** | Never leaked | Could be company-specific OR truly random | | **1-1000** | "Sweet spot" — proven human use, not yet in every spray list | **Prioritize** | | **1k-1M** | Mainstream | Usually already tried by previous attackers | | **>1M** | Generic (`password`, `123456`) | Skip — every WAF expects these |

**Standard filter for spray prep:** `--max-count 1000000` drops the boring generic stuff while keeping the sweet spot.

**Performance:** ~5 minutes for 10k passwords, ~50 minutes for 100k. Use `--limit N --shuffle` to sample if your wordlist is huge.

---

Stage 3 — `/osint-employees <target>`

`theHarvester` (search engines + CT logs) → derive names from email local-parts → `username-anarchy` permutations.

**Default mode is conservative:**

• Sources: `duckduckgo,brave,yahoo,mojeek,crtsh,certspotter,hackertarget,otx`
• No LinkedIn-specific scraping
• No paid OSINT (DeHashed, IntelX, Shodan)

**Opt-in flags:**

• `--with-linkedin` — adds CrossLinked (Google/Bing dorks against `site:linkedin.com`). **Read program policy first** — some BBPs forbid employee identification.
• `--with-pydictor-social` — pydictor generates name-derived password candidates (`john2025`, `john!2024`).

**Realistic expectations:**

| Target type | Expected emails | Expected names | |---|---|---| | US/EU SaaS (Twilio, Stripe) | 5-50 | depends — many CTOs are public | | State utility (Taipower, etc.) | **0** | 0 (no English-named LinkedIn profiles) | | Local SME | 0-10 | 0-5 |

For mature security-conscious targets, expect very few emails. The CT-log hostnames theHarvester finds are **separate value** — feed them back into `/recon` for more attack surface (this happened in our Taipower run: 0 emails but 59 new subdomains).

---

Stage 4 — `/spray <login-url> --mode <mode>`

The **most dangerous** command. Real auth attempts against live accounts. Read [HARD GUARDS](#hard-guards) before running.

**Mode selection:**

| Mode | Use case | Engine | |---|---|---| | `http-form` | Custom login page (most BB targets) | Pure Python urllib | | `oauth` | OAuth password grant (`grant_type=password`) | Pure Python urllib | | `o365` | Microsoft 365 / Azure AD | `trevorspray` | | `okta` |