Credentials, Passwords & Initial Access

Offline cracking is dual-use. In professional work you crack hashes obtained under authorization to demonstrate weak password policy, reuse, or storage failures. You do not attack personal dumps from breaches for fun, and you do not retain client credentials longer than the engagement policy allows. Store loot in controlled folders; redact samples in reports.

The usual professional goal is evidence: 'X of Y service accounts used passwords recoverable within Z minutes using public wordlists and common rules' or 'the single domain admin hash recovered was Password1!, proving policy enforcement gaps.' Cracking everything in a 50,000-user dump is rarely necessary and often unethical if it expands personal data exposure without need.

Authorized lab only for skill building: known hash sets from training platforms, passwords you set yourself in lab AD/web apps, and CTF challenges. Never crack hashes from systems outside scope.

Wrong mode wastes hours. Use haiti, name-that-hash, or hashcat's example hashes documentation to classify MD5, NTLM, bcrypt, sha512crypt, Kerberos etypes, and application-specific formats. Note salts and iterations: bcrypt and modern KDF slow cracking dramatically — that is itself a positive control when reporting.

Normalize input files: one hash per line, correct username:hash formats for john when needed, remove junk prefixes carefully. A single corrupted line can abort or skew a run. Keep an uncracked and cracked potfile discipline so results are reproducible.

Record mode numbers and tool versions in notes. Retests and teammates must be able to replay the methodology, not guess which -m flag you used.

Start cheap: straight dictionary with rockyou or a quality base list. Next apply rules (best64, OneRule) that model human mutations (years, !, capitalization). Hybrid attacks append/prepend digits. Masks (-a 3) encode policy guesses: ?u?l?l?l?l?l?d?d?s for 'common corporate shapes' when you know length and complexity requirements.

Do not jump to huge keyspaces first. Measure: if 30% crack under dictionary+rules in minutes on NTLM, you already have a policy finding. Spend remaining budget on high-value accounts (admins, service accounts) with targeted masks and custom lists.

hashcat shines with GPUs and large parallelizable hashes (NTLM, MD5). john is convenient for odd formats, automated format detection, and CPU-friendly workflows. Both benefit from --show / potfile hygiene. Pause and resume long runs rather than losing state.

Generic lists miss org-specific passwords: product names, city+year, merger names, sports teams. CeWL spiders an authorized site to build a custom base list; combine with rules. Employee naming patterns and season/event themes appear constantly in real assessments — still only against authorized hash sets.

SecLists and specialized lists (for Wi-Fi, defaults, common service accounts) expand coverage. Curate a personal library with dates and sources. Quality beats quantity when GPU time is limited.

For service accounts, also try username-as-password, season+year, and well-known defaults from vendor docs — again only in lab or authorized internal tests. Document default credential findings separately because the fix is configuration, not user training.

Metrics matter: percentage cracked within time budget, distribution of password length/complexity among cracked set (aggregated), examples of patterns (not full username:password tables in the main report). Provide a few redacted examples to prove weakness, keep full cracked material in secure evidence storage.

Connect to controls: lack of banned-password lists, missing MFA on high-value accounts, reversible storage or weak hash algorithms, shared local admin passwords (ties to AD modules). Recommend fine-grained password policies, MFA, secret vaults for services, and monitoring for password-spray patterns.

If hashes were unsalted MD5 from an application, the finding is primarily storage/crypto failure; cracking ease is the impact proof. If bcrypt hashes still cracked heavily, the finding is policy and user behavior under a good algorithm.

Never upload client hashes to public cracking websites. Use your own hardware or approved private infrastructure. Be aware of cloud GPU legal/policy constraints and data residency.

Watch thermal and power limits on lab rigs; long runs fail silently when devices throttle. Verify cracked passwords against a sample authentication in lab only when needed — production verification of cracked user passwords can lock accounts or violate RoE if not planned.

Close the loop: after the engagement, destroy or return hash material per contract. Personal practice pots should not contain real client secrets.

Offline cracking hammers your GPU; online testing hammers the client's authentication services and user accounts. Failed logons trigger SOC alerts, lockouts, and helpdesk load. Professionals get explicit permission for spraying, agree on user lists, timing windows, and max attempts, and often coordinate with blue teams so alerts are expected.

Prefer offline analysis when you already have hashes. Prefer single-account careful tests or default-credential checks on appliances before enterprise-wide sprays. When sprays are allowed, one password across many users (spray) is usually safer than many passwords against one user (classic brute), but both can lock environments if misconfigured.

Authorized lab only for learning hydra/medusa/kerbrute patterns. Production-like labs (GOAD, HTB Academy AD, your own domain) teach timing and noise without harming real users.

Before any spray: learn lockout thresholds (if discoverable from policy docs, client interview, or careful lab enumeration — not by locking real users). Set tool attempt rates below thresholds with margin. Stagger attempts, avoid overnight unmanaged runs against production, and maintain a kill switch.

MFA changes the game. Password-only success against a portal that also needs a second factor may still be a finding if legacy protocols (IMAP, older VPN, basic auth APIs) bypass MFA. Map which pathways enforce MFA and which do not. Phishing-resistant MFA (FIDO2) differs from SMS OTP in attacker cost; report accurately.

Stop conditions: unexpected mass lockouts, degraded auth service, RoE window end, or discovery that accounts are shared break-glass identities. Document stops in the timeline; continuing for ego is unprofessional.

HTTP forms need correct failure signatures, CSRF tokens, and success detection strings — hydra/http-post modules fail silently when configured wrong. Always validate with a known good and known bad lab account first. SSH, FTP, RDP (crowbar/hydra), and SMB each have different rate and lockout behaviors.

Kerberos pre-auth spraying (kerbrute) is popular on internal Windows estates: it can be quieter or different in logs than SMB logons, but it is still noisy and still requires authorization. Understand that failed pre-auth is a detectable event on modern monitoring.

Default credentials on printers, SAN UIs, dev tools, and monitoring stacks remain high-value, low-attempt wins. Check vendor defaults only against in-scope appliances. One success with admin/admin is often more impactful than a 10,000-attempt spray that finds nothing.

Initial access in real networks often looks like: phished password reused on VPN; spray hits a service account exempt from MFA; default community string or web UI on a jump host; credential from a public Git leak still valid. Your online tests should be designed to simulate plausible attacker paths allowed by RoE — not every theoretical brute force.

When you gain a session, immediately note MFA presence, password age signals if available, and whether the account is privileged. That context drives whether the finding is 'external password spray possible' versus 'Domain Admin with Password123 on RDP open to the internet' — wildly different risk stories.

Coordinate with Module 7: a cracked or sprayed domain user may enable Kerberoasting or BloodHound collection. Do not race into post-ex without updating notes and confirming scope for internal pivoting.

hydra and medusa are flexible; wrong flags cause false negatives. Prefer small controlled lists. Use -t low thread counts for auth services. Log successes and failures to files for evidence. For web, Burp Intruder with collab-free careful throttling is sometimes safer than fire-and-forget CLI tools.

kerbrute userenum vs passwordspray are different operations with different ethics: username enumeration may be allowed when password guessing is not, or vice versa. Read the RoE. In labs, practice both and compare Windows event noise.

Never point these tools at random internet hosts, shared cloud tenants outside scope, or third-party IdPs that are not explicitly authorized — even if a client 'uses' them. Scope is the control.

Good findings specify protocol, endpoint, whether MFA applied, attempt rate used, and proof of success with a test account or redacted session evidence. Remediation: enforce MFA on all internet-facing auth, block legacy auth, implement smart lockout and CAPTCHA where appropriate, ban common passwords, monitor spray patterns, close unused external listeners.

Avoid recommending 'longer passwords only' when the real issue is password-only RDP on 0.0.0.0/0. Align remediation with architecture. Include detection opportunities for purple-team minded clients: which events should fire when sprays occur.

If testing was limited by lockout risk, say so in limitations — honesty about coverage builds trust.