BruteForceAI is a Python credential-testing tool that uses LLMs (Ollama/Groq) to auto-identify login form selectors before running multi-threaded brute-force and password-spray exercises against authorized targets.
| Tool | MorDavid/BruteForceAI — LLM-assisted credential testing tool with automated login form analysis |
| Category | Password attacks / web authentication testing |
| Primary Use | Authorized penetration tests and labs: identifying login form selectors with an LLM, then exercising credential lists in bruteforce or passwordspray modes |
| Safe Use | The README states the tool is for educational purposes and authorized penetration testing only; use exclusively against systems you own or have written permission to test |
| Telemetry Note | Despite jitter, User-Agent rotation, and proxy support, use leaves heavy failed-login traces and a local bruteforce.db SQLite log; defenders should see correlated failures from rotating User-Agent strings and Playwright/Chromium fingerprints |
BruteForceAI sits at the intersection of two trends that have dominated the tooling landscape recently: browser automation via Playwright and the push to bolt LLMs onto every stage of the offensive pipeline. Written in Python 3.8+, the tool's genuinely novel contribution is not the credential-guessing engine itself but the reconnaissance stage that precedes it. Instead of requiring an operator to hand-craft CSS selectors for a target login form, BruteForceAI feeds the page's HTML to a language model — either a local Ollama instance or a cloud-hosted Groq endpoint — and asks it to identify the form elements programmatically. The result is a two-stage workflow: analyze produces the selectors, and attack uses them.
Architecturally, the separation into analyze and attack subcommands is a sensible design. The analysis stage extracts what the README calls smart HTML content and passes it to the configured model, with retry behavior described as feedback learning — if the LLM returns selectors that fail, subsequent attempts presumably re-prompt with corrective context, up to a configurable --selector-retry limit of 10 by default. Analysis results are persisted in a SQLite database (bruteforce.db, table form_analysis), so re-running attacks against the same URL does not require re-invoking the model, which matters both for cost when using Groq and for speed when running llama3.2:3b locally.
The attack engine supports two modes that map to the two classic credential-testing strategies. bruteforce mode walks the full cross-product of usernames and passwords, while passwordspray mode tries each password against every username — the pattern used when lockout policies punish per-account failure counts. Threading is configurable from 1 to 100+ via --threads, with a deliberate caveat in the feature list: synchronized delays between attempts targeting the same user. That detail suggests the developers understand that naive thread pools will hammer a single account and trigger lockouts, which would undermine a spray campaign.
Success detection is handled through DOM change detection rather than HTTP status codes, which is the right call for modern web applications. The --dom-threshold parameter (default 100) defines how large a difference in the rendered document object model constitutes a successful login versus a failed one. Because BruteForceAI drives a real Playwright Chromium instance rather than firing raw HTTP requests, it observes what a browser actually renders — including JavaScript-driven redirects, toasts, and partial page updates that would be invisible to a requests-based tool. This also means it inherits realistic TLS and HTTP/2 fingerprints, though at the cost of being far heavier per attempt.
The evasion feature set is worth understanding from both sides of the fence. --user-agents rotates header strings from a supplied file, --delay and --jitter introduce randomized human-like timing between attempts, --proxy routes traffic through an intermediary, and browser visibility can be controlled so the Chromium window stays headless. For defenders, this is a useful checklist of what credential-guessing traffic looks like in 2026: rotating User-Agent strings combined with consistent Chromium-level TLS fingerprints, steady request cadence with statistical jitter, and — critically — the same source IP cycling through many accounts in spray mode.
The LLM provider abstraction is where operators should pay attention to operational security. Choosing Ollama with a local model like llama3.2:3b, llama3.2:1b, or qwen2.5:3b keeps target HTML entirely on the assessment workstation — appropriate for engagements with sensitive scoping. Choosing Groq sends that HTML to a third-party cloud API using --llm-api-key, which may violate data-handling clauses in some engagement contracts even though only form markup is transmitted, not credentials. The README's model guidance is unusually practical: it recommends llama-3.3-70b-versatile for quality, llama3-70b-8192 as a fast alternative, and explicitly warns against llama-3.1-8b-instant due to rate limiting forcing 3+ attempts.
Setup follows the standard pattern for Playwright-based tooling. After creating a virtual environment, dependencies come from requirements.txt (playwright, requests, PyYAML), and the bundled browser is installed with playwright install chromium. A minimal invocation of the analysis stage looks like python BruteForceAI.py analyze --urls targets.txt --llm-provider ollama, followed by python BruteForceAI.py attack --urls targets.txt --usernames users.txt --passwords passwords.txt for the exercise itself. The subcommand surface is completed by clean-db for database management and check-updates for version checks.
Operational hygiene features are more mature than in many hobbyist repos. Every attempt is logged to the brute_force_attempts table with results and metadata, duplicate attempts are skipped by default so a re-run resumes rather than repeats, and --force-retry overrides that when needed. --success-exit stops the campaign after the first valid credential, limiting noise exposure. Network errors trigger automatic retries up to --retry-attempts (default 3). Real-time notification webhooks for Discord, Slack, Teams, and Telegram mean an operator can monitor a long-running lab exercise without watching the terminal — though operators should think carefully before piping assessment results to a third-party chat platform.
One design choice that warrants scrutiny is the update mechanism. The tool checks https://mordavid.com/md_versions.yaml on every startup with a 3-second timeout, and while it can be suppressed with --skip-version-check, a version-checking beacon to the author's domain is exactly the kind of network artifact that makes opsec-conscious operators reach for egress filtering or DNS sinks during sensitive engagements. It is a common pattern in modern tooling, but the README is at least transparent about the endpoint and the timeout behavior.
The licensing situation deserves a flag before adoption: the repository metadata reports NOASSERTION, and the README badge indicates a Non-Commercial license, so commercial pentest shops should verify terms before embedding this in a paid engagement workflow. With roughly 1,900 stars and topics spanning ai, bruteforce, bugbounty, llm, and loginpages, the project has clearly struck a nerve — the idea of letting a model do the tedious selector work is a genuine ergonomic win for authorized testing.
From a defensive research perspective, BruteForceAI is a useful case study in what the next generation of credential attacks looks like. DOM-based success detection defeats naive HTTP-status canary honeypots, jittered timing defeats fixed-rate throttling, and User-Agent rotation defeats simplistic header-based blocking. The countermeasures that still hold are behavioral: per-source-IP correlation across accounts, device and TLS fingerprinting (which rotation does not change), progressive delays, and — most robustly — MFA and passwordless architectures that make guessed credentials insufficient on their own.
The README closes with an explicit legal disclaimer reserving the tool for educational purposes, authorized penetration testing, and security research, and that boundary should frame every deployment. In a lab or a properly scoped engagement, BruteForceAI is a well-engineered demonstration of LLM-assisted target analysis; pointed at infrastructure you do not own, it is straightforwardly illegal computer misuse. The tool's real lesson for the professional community may be architectural: the boring part of web authentication testing — figuring out which selectors matter — is now automatable, and both attackers and defenders should plan accordingly.
MorDavid/BruteForceAI.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.