What problem does this solve?
Credential testing is currently sequential — each attempt waits for the previous one to complete before starting the next. For large user/password lists, especially over TCP where connection setup dominates, this makes runs unnecessarily slow. A 10,000-user spray with 15-second timeouts on unreachable hosts could take days sequentially.
Proposed solution
Add thread-based or async parallelism with a configurable concurrency level (e.g. --threads N, default 1 for backwards compatibility). Each worker would independently pull user/secret pairs from a shared queue and test them against the target. Results would still be written to output in a thread-safe manner.
Key considerations:
- The
--delay and --jitter options should apply per-thread to maintain rate limiting guarantees
- The
--max-lockouts consecutive revoked counter needs to be thread-safe (atomic or locked)
- The
--stop-on-success flag needs to signal all workers to stop
- Salt caching for Kerberos AES should be shared across threads (one salt fetch per user regardless of thread count)
- Connection failure and clock skew should halt all threads immediately
Alternatives considered
- GNU
parallel or xargs -P wrapping multiple credwolf invocations — works but loses salt caching, lockout tracking, and stop-on-success coordination across instances
- asyncio — possible but impacket's socket operations are synchronous, so would require
run_in_executor wrappers
What problem does this solve?
Credential testing is currently sequential — each attempt waits for the previous one to complete before starting the next. For large user/password lists, especially over TCP where connection setup dominates, this makes runs unnecessarily slow. A 10,000-user spray with 15-second timeouts on unreachable hosts could take days sequentially.
Proposed solution
Add thread-based or async parallelism with a configurable concurrency level (e.g.
--threads N, default 1 for backwards compatibility). Each worker would independently pull user/secret pairs from a shared queue and test them against the target. Results would still be written to output in a thread-safe manner.Key considerations:
--delayand--jitteroptions should apply per-thread to maintain rate limiting guarantees--max-lockoutsconsecutive revoked counter needs to be thread-safe (atomic or locked)--stop-on-successflag needs to signal all workers to stopAlternatives considered
parallelorxargs -Pwrapping multiple credwolf invocations — works but loses salt caching, lockout tracking, and stop-on-success coordination across instancesrun_in_executorwrappers