BruteForceAI: LLM-gestützte Formularanalyse vor dem Login-Angriff

Zwei Stufen statt einer Selektor-Konfigurationsdatei

Die meisten Brute-Force-Werkzeuge erwarten, dass man ihnen vorher sagt, welche Felder im Login-Formular stehen. Das ist bei eigenen Zielen machbar, bei einer Liste fremder Login-Seiten wird es mühsam. BruteForceAI dreht die Reihenfolge um. Der Befehl analyze liest die HTML-Inhalte der Ziele und lässt ein Sprachmodell die Login-Elemente und ihre Selektoren benennen. Erst danach greift der Befehl attack auf die so gefundenen Selektoren zurück. Das Werkzeug richtet sich damit an Personen, die autorisierte Login-Tests durchführen und dabei viele unterschiedlich gebaute Formulare abdecken müssen. Die Zielgruppe ist eng: Wer nur ein einzelnes, bekanntes Formular testet, gewinnt durch den LLM-Schritt wenig und zahlt ihn mit Wartezeit.

Was das Modell sieht und was es zurückgibt

Aus der Beschreibung geht hervor, dass der HTML-Inhalt extrahiert und an das Modell übergeben wird. Das Modell liefert Selektoren für Benutzername, Passwort und Absende-Element. Die README nennt zusätzlich eine Wiederholung mit Feedback-Lernen, wenn der erste Versuch nicht passt, sowie eine Erkennung von DOM-Änderungen, um einen erfolgreichen Login zu bestätigen. Diese Rückkopplung ist der eigentlich interessante Teil, denn ein Selektor allein sagt nichts darüber, ob der Angriff gewirkt hat. Die zweite Stufe läuft über Playwright, also über einen echten Browser, nicht über rohe HTTP-Aufrufe. Genau deshalb funktioniert die DOM-Änderungserkennung. Wer Seiten mit reinem requests-Code angreift, sieht diese Änderungen nicht. Der Preis ist ein höherer Ressourcenbedarf pro Thread, weil jeder Browserkontext Speicher belegt.

Installation: venv, Playwright, Modell

Die README beschreibt den Ablauf in drei Schritten. Zuerst eine virtuelle Umgebung mit python -m venv .venv und anschließender Aktivierung, je nach System über .venv\Scripts\Activate.ps1, .venv\Scripts\activate.bat oder source .venv/bin/activate. Danach pip install -r requirements.txt und playwright install chromium. Als Abhängigkeiten nennt die README playwright, requests und PyYAML. Für das Modell stehen zwei Wege offen. Lokal über Ollama mit ollama pull llama3.2:3b, oder in der Cloud über Groq mit einem API-Schlüssel, der über --llm-api-key übergeben wird. Ein vollständiger Aufruf der Analyse sieht so aus: python BruteForceAI.py analyze --urls targets.txt --llm-provider ollama --llm-model llama3.2:3b. Der Angriff folgt getrennt: python BruteForceAI.py attack --urls targets.txt --usernames users.txt --passwords passwords.txt --threads 20 --delay 5 --jitter 2.

Angriffsmodi, Drosselung und Nebenwirkungen

Der Befehl attack kennt laut README zwei Modi: bruteforce, also alle Kombinationen aus Benutzernamen und Passwörtern, und passwordspray, bei dem jedes Passwort gegen alle Benutzernamen getestet wird. Dazu kommen --threads im Bereich von 1 bis über 100, --delay und --jitter für die Pausen zwischen Versuchen, eine Rotation der User-Agent-Zeichenkette, Proxy-Unterstützung und eine Steuerung der Browser-Sichtbarkeit. --success-exit bricht nach dem ersten gültigen Zugangsdatensatz ab. Für die Drosselung ist wichtig, dass die README von synchronisierten Verzögerungen zwischen Versuchen für denselben Benutzer spricht. Das ist eine andere Größe als eine globale Rate. Bei vielen Benutzernamen und hoher Thread-Zahl kann die Gesamtlast auf dem Ziel trotzdem deutlich über dem liegen, was der Wert von --delay vermuten lässt. Wer Sperrmechanismen nicht vorher mit dem Zielbetreiber abgestimmt hat, riskiert, dass Konten gesperrt werden, bevor der Test aussagekräftige Ergebnisse liefert.

Protokollierung, Webhooks und der Update-Aufruf

Treffer und Versuche landen laut README in einer SQLite-Datenbank, zusätzlich gibt es eine Ausgabe in Dateien über --output und eine ausführliche Terminal-Ausgabe mit --verbose. Bei einem Erfolg können Webhooks an Discord, Slack, Teams oder Telegram ausgelöst werden. Der Befehl clean-db räumt Datenbanktabellen auf, und die README erwähnt ein Überspringen bereits versuchter Kombinationen, das sich mit einer Option zum erzwungenen Wiederholen abschalten lässt. Ein Punkt verdient Aufmerksamkeit: Die Funktionsliste nennt eine automatische Prüfung auf Aktualisierungen von mordavid.com, und der Befehl check-updates gehört zur Kommandooberfläche. Ein Werkzeug, das während eines laufenden Tests eine externe Domain kontaktiert, gehört in eine Umgebung, in der ausgehender Verkehr kontrolliert wird. Ob der Aufruf Abschaltmöglichkeiten bietet, lässt sich aus dem vorliegenden Material nicht beantworten.

Wann das LLM nur Umwege schafft

Die Analyse ist der Engpass. Bei lokalen Modellen wie llama3.2:3b hängt die Laufzeit an der Hardware, und die README empfiehlt selbst kleinere Varianten für schnelle Analysen, was ein Zugeständnis an die Genauigkeit ist. Bei Groq nennt die README für llama-3.1-8b-instant ausdrücklich Probleme mit Ratenbegrenzungen und mehr als einen Versuch, während sie für llama-3.3-70b-versatile einen Versuch angibt. Wer viele Ziele in kurzer Zeit analysiert, stößt dort an Grenzen des Anbieters, nicht an Grenzen des Werkzeugs. Der zweite wunde Punkt ist die Erfolgsprüfung über DOM-Änderungen. Eine Seite, die nach dem Absenden nur eine Fehlermeldung per JavaScript einblendet oder das Formular an derselben Stelle stehen lässt, liefert kaum unterscheidbare Zustände. In diesem Fall ist BruteForceAI das falsche Werkzeug, und ein Skript, das den HTTP-Status und die Antwortlänge auswertet, ist die bessere Wahl.

Alternative: Hydra und der Unterschied im Ansatz

Der naheliegende Vergleich ist Hydra. Hydra arbeitet mit Modulen pro Protokoll und Dienst, etwa HTTP-Formulare über einen Modulaufruf, und erwartet, dass die Formularparameter und die Bedingung für einen Fehlschlag von Hand angegeben werden. Der Unterschied liegt nicht im Tempo, sondern im Ort der Anpassung. Bei Hydra schreibt man die Zielbeschreibung einmal und bekommt dafür reproduzierbare, sehr schnelle Läufe ohne Browser und ohne Modellaufruf. Bei BruteForceAI verschiebt sich die Arbeit in den Modellaufruf und in die Erkennung. Das zahlt sich aus, wenn sich das Markup zwischen Zielen stark unterscheidet und Handarbeit pro Ziel teuer wäre. Es zahlt sich nicht aus, wenn ein einziges Formular ohnehin bekannt ist. Ein zweiter Unterschied ist die Nachvollziehbarkeit: Ein Hydra-Aufruf lässt sich als Zeile in ein Testprotokoll kopieren. Bei BruteForceAI hängt das Ergebnis zusätzlich davon ab, welches Modell in welcher Version geantwortet hat.

Lizenz und Wartungskosten

Die Lizenzangabe des Repositorys lautet NOASSERTION, das heißt, es wurde keine von der Plattform erkannte Standardkennung hinterlegt. Die Badges in der README zeigen Non-Commercial, und der Abschnitt zur Lizenz ist im vorliegenden Material abgeschnitten. Damit ist die entscheidende Frage offen: Ob der kommerzielle Einsatz in einem beauftragten Pentest zulässig ist, lässt sich hier nicht beantworten, und das sollte vor jedem Einsatz im Repository selbst geprüft werden. Zur Wartung: Releases wurden nicht abgerufen, und ob es eine Versionskontrolle mit Changelog gibt, geht aus dem Material nicht hervor. Die Abhängigkeiten sind überschaubar, aber Playwright bringt einen eigenen Chromium-Build mit, der regelmäßig aktualisiert werden muss. Dazu kommt die Kopplung an Modellnamen, die bei Cloud-Anbietern schneller wechseln als die Software selbst. Ein Upgrade kann daher an einer Zeile in einem Aufruf scheitern, nicht am Code.

Redaktionelles Fazit

Für autorisierte Pentests an bekannten Login-Seiten mit uneinheitlichem Markup ist BruteForceAI ein nachvollziehbar aufgebautes Werkzeug, weil die Selektorenerkennung nicht handgeschrieben werden muss. Wer ohne schriftliche Freigabe arbeitet, sollte es nicht einsetzen. Zuerst zu prüfen sind der Lizenztext im Repository, das Verhalten von check-updates gegen mordavid.com und ob die gewählte LLM-Konfiguration die Formulare überhaupt zuverlässig erkennt.

Offizielle Quellen

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