BruteForceAI: LLM-Assisted Login Form Analysis Before Credential Attacks

The selector problem BruteForceAI is trying to remove

Most login brute force tooling asks you to describe the target form before it can do anything. You supply the username field name, the password field name, the submit button, the failure string. That work is per-target and it breaks the moment a page renames an input or wraps the form in a component that generates random attribute values. On an engagement with a handful of targets this is a morning of manual inspection. On a bug bounty programme where the login page is one of many endpoints, it is the reason people skip the login page entirely. BruteForceAI's stated goal is to move that step to a language model. The README describes two stages: an analyze stage where an LLM reads HTML content and identifies the login form elements and selectors, and an attack stage that executes the credential attempts using whatever the model returned. The intended user is a penetration tester or bug bounty hunter working through a list of URLs in a text file. The tool is written in Python, drives a real browser, and ships no release artefacts according to the repository metadata.

Two stages, a YAML config, and a SQLite ledger

The pipeline is deliberately split so that the expensive and unreliable part runs once. In stage one, the analyze command loads each URL, extracts HTML content, and sends it to an LLM provider. The README lists Ollama for local inference and Groq for a hosted API. The model is asked to return the selectors for the login form, and the README mentions automatic retry with feedback learning, which suggests a failed parse is fed back to the model rather than discarded. Stage two, the attack command, reads the stored selectors and drives Playwright Chromium to fill and submit the form. Success detection is described as DOM change detection, meaning the tool compares page state rather than searching for a fixed string such as "Invalid password". That is a real design decision: it survives localisation and custom error copy, but it also means a page that re-renders a CSRF token on every attempt could look like a change. Attempts are written to a SQLite database, which the README credits with duplicate prevention and a skip-existing-attempts behaviour, plus a clean-db command for managing the tables. That ledger is the part I would actually rely on during a long run, because it makes a resumed session possible without replaying every credential.

Getting it running: venv, Playwright, and one model pull

The README gives a concrete install path. Create an isolated environment with python -m venv .venv, activate it (source .venv/bin/activate on macOS or Linux, .venv\Scripts\Activate.ps1 in PowerShell), then pip install -r requirements.txt and playwright install chromium. The listed dependencies are playwright, requests and PyYAML. For local inference the README suggests curl -fsSL https://ollama.ai/install.sh | sh followed by ollama pull llama3.2:3b. The basic two-command workflow is python BruteForceAI.py analyze --urls urls.txt --llm-provider ollama, then python BruteForceAI.py attack --urls urls.txt --usernames users.txt --passwords passwords.txt --threads 10. Beyond those, the attack command accepts --mode passwordspray, --delay, --jitter, --success-exit, --user-agents, --verbose and --output, and the README shows a webhook flag for Discord with Slack, Teams and Telegram listed as notification targets. The command surface is a single script with four subcommands: analyze, attack, clean-db and check-updates. Note that check-updates reaches out to mordavid.com, which the README presents as automatic update checking. On a segmented network that call will fail, and the README does not describe an offline flag for it.

The model choice does more work than the tool does

BruteForceAI does not ship a model. It ships a prompt and a parser, so analysis quality tracks whatever you point it at. The README's own model table is unusually blunt about this. For Groq it recommends llama-3.3-70b-versatile as the default and best option at one attempt, lists llama3-70b-8192 and gemma2-9b-it as alternatives also at one attempt, and marks llama-3.1-8b-instant as not recommended because of rate limiting issues requiring three or more attempts. For Ollama it offers llama3.2:3b as the default, llama3.2:1b as the fastest option, and qwen2.5:3b as an alternative. Read that as a warning about retry cost. Every retry is another round trip carrying page HTML, and with a hosted provider that is both latency and, depending on your plan, money. A three-attempt model on a hundred URLs is three hundred API calls before a single credential is tried. The local Ollama path avoids the per-call cost but moves the constraint to your hardware, and the README does not state memory or GPU requirements for the listed models.

Where the two-stage design breaks down

The obvious failure mode is a login page that is not one page. Multi-step flows (username screen, then password screen), JavaScript-rendered forms that populate after the HTML snapshot, and iframes all sit outside what a single HTML extraction can describe. The README does not claim to handle them, and the analyze stage as described reads HTML content rather than driving the flow. A second problem is staleness. Selectors are discovered once and stored, but nothing in the README describes re-validation before an attack run, so a form that changes between the analyze and attack stages, or between two attack runs, will fail in a way that looks like bad credentials rather than a broken selector. Third, the evasion features are timing and header features, not detection features. User-Agent rotation, delay with jitter, and proxy support change the shape of traffic. They do not change the fact that a browser automation tool with many threads produces a request pattern no human produces, and the README's own advice to use synchronized delays between attempts on the same user is an acknowledgement that concurrency and lockout policies interact. Finally, the licence is unresolved in the material provided: the README badge reads Non-Commercial, the repository metadata reports NOASSERTION, and there is no LICENSE text in what I was given. Treat that as a blocker until you read the file yourself.

How this differs from Hydra and Burp Intruder

Hydra is the reference point for credential testing, and the difference is where the intelligence sits. Hydra is a protocol-level tool: you tell it the service module, the target, and the credential lists, and it speaks the protocol directly with high throughput and no browser. BruteForceAI drives Chromium through Playwright, which means it can execute JavaScript, follow client-side redirects, and submit a form the way a browser would. That is slower per attempt and heavier per thread, and it is the reason the selector discovery step exists at all: a browser-driven tool needs to know which element to type into, while Hydra needs to know which protocol field to set. Burp Intruder sits elsewhere again, as a manual tool inside a proxy, where you build the request once and vary payload positions. It gives you full control and a human in the loop, and it does not attempt to infer the form for you. BruteForceAI trades that control for automation across a URL list. If your targets are HTTP basic auth or an API endpoint, Hydra is the smaller and faster answer. If they are JavaScript-heavy login pages you cannot easily script, the browser approach has a real justification.

Maintenance, licence, and what to verify first

There are no releases in the repository metadata, so there is no versioned artefact to pin and no changelog to read before upgrading. The README references v1.0.0 in a badge and describes automatic update checking against mordavid.com, which means the update path is a network call to a project homepage rather than a package manager. Upgrading is therefore a git pull plus pip install -r requirements.txt, and the risk is that a dependency bump in playwright or requests changes browser behaviour under an attack run. The three dependencies are common and well maintained, which limits that risk, but nothing in the material describes a lockfile or pinned versions. On licensing: a non-commercial restriction, if that is what the LICENSE file says, rules out using this inside paid client work, which is precisely the context the README's framing (penetration testing, bug bounty) implies. I am not giving legal advice; the point is that the licence text, not the badge, is the thing to read. Before running anything, verify three things: the LICENSE file contents, whether your target list is covered by written authorisation, and whether your chosen model returns usable selectors on your specific form by running analyze against a single URL first.

Editorial conclusion

BruteForceAI is worth reading if you already run authorised credential testing against your own login pages and you want to stop hand-writing CSS selectors for every form. It is the wrong tool for anyone without written authorisation, anyone who needs a maintained licence they can point a legal team at, or anyone expecting a project with release history and issue traffic behind it. Before running it, read the LICENSE file in the repository, since the badge says Non-Commercial while the repository metadata reports NOASSERTION, and confirm which one governs.

Official sources

1. Issues
2. MorDavid/BruteForceAI on GitHub
3. Project website
4. README