KI-Bots greifen Webseiten an: Sie wollen nicht deine Texte, sondern deinen Login

Wenn ich die Logs meiner eigenen Webseiten und die Logs meiner Kunden durchgehe, sehe ich seit Monaten dasselbe Bild: KI-Bots greifen Webseiten an, und mit dem Einsammeln von Trainingsdaten hat das wenig zu tun. Sie probieren Logins durch, suchen nach verwundbaren Plugins und schicken SQL-Fragmente in Kommentare, Formulare und Chatbots.

Meine These: Das Scraping ist der kleinere Teil des Problems, der größere heißt Zugang. Nach diesem Artikel weißt du, was diese Bots konkret versuchen, warum eine kleine Seite kein Schutz ist und welche acht Maßnahmen du diese Woche setzen kannst. Ich arbeite seit 1989 in der Kommunikationsbranche und berate heute EPU und KMU in der DACH-Region, deshalb schaue ich besonders auf die Seiten, die keine IT-Abteilung haben. Schauen wir mal, was in den Logs steht.

KI-Bots greifen Webseiten nicht an, um deine Texte zu lesen, sondern um sich einzuloggen, Plugin-Lücken zu finden und Eingabefelder zu missbrauchen. Wer nur seine robots.txt pflegt, verteidigt sich gegen das falsche Problem.

Alex Januschewsky

Wie läuft so ein Angriff in 50 Sekunden ab?

Das Video zeigt es als Schleife in drei Türen: erst der Login, dann die Plugins, dann die Eingabefelder. Die Bots versuchen immer dieselbe Reihenfolge, und am Ende siehst du, welche Maßnahme welche Tür schließt.

Die drei Türen bilden auch das Gerüst dieses Artikels: Zugangsdaten, veraltete Software, ungeprüfte Eingaben.

Was steht in meinen Logs, und was lese ich daraus ab?

Ich sehe vier Dinge: Login-Versuche, Anfragen, die nach verwundbaren Plugins suchen, SQL-Fragmente in Kommentaren und Formularen und dieselben Fragmente im Eingabefeld des Chatbots. Einen Fall habe ich schon beschrieben: drei fehlgeschlagene Logins in 47 Sekunden aus Singapur, New Jersey und Bratislava, der erste Versuch mit meinem echten Namen. Den größeren Zusammenhang habe ich in meiner Bestandsaufnahme zu KI als Angriffswerkzeug aufgearbeitet.

Ich bin mir nicht sicher, ob hinter jedem dieser Treffer ein Sprachmodell steckt. Aus einer Log-Zeile lese ich das nicht ab, ein altes Skript sieht genauso aus. Ablesen kann ich das Verhalten: breit, schnell und auf Eingabefelder und Zugänge gerichtet, nicht auf Inhalte. Die Sicherheitsfirmen sehen dieselbe Richtung.

Laut dem Thales Bad Bot Report 2026, der früheren Imperva-Studie, kam 2025 rund 53 Prozent des Web-Traffics von Automaten, 40 Prozent der Gesamtmenge stuften die Autoren als bösartig ein. KI-getriebene Bot-Angriffe stiegen um das 12,5-Fache, und etwa 27 Prozent der Angriffe zielten auf APIs und Identitätssysteme, also auf Logins. Der Threat Report 2026 von Cloudflare kommt bei den Anmeldungen auf 94 Prozent Bot-Anteil in seinem Netzwerk. Cloudflares Beschreibung des Trends trifft es: Angreifer brechen seltener ein, sie melden sich einfach an.

DataDome zählt in seinem State of Bot & Agent Security Report 2026 auf den Login-Seiten seiner Kunden eine Verachtfachung der monatlichen Anfragen durch KI-Bots, von 11,9 Millionen im Jänner auf 99,7 Millionen im Juni 2026. DataDome räumt selbst ein, dass ein Teil davon legitime Assistenten sein kann, die für echte Nutzer arbeiten. Das ist eine Einzelquelle, ich zitiere die Zahl deshalb als Richtung und nicht als Beweis.

Warum loggen sich Bots ein, statt Schlösser zu knacken?

Weil es billiger ist. Ein gestohlenes Passwort kostet fast nichts, eine unbekannte Sicherheitslücke kostet viel. Cloudflare nennt das den Measure of Effectiveness: das Verhältnis aus Aufwand und Ergebnis. Wer wie ein Angreifer rechnet, nimmt den Login.

Dazu kommt ein Rhythmus, den du kennen solltest. Laut DataDome stiegen die Credential-Stuffing-Wellen im Sommer 2025, brachen binnen drei Monaten um fast 90 Prozent ein und erreichten im April 2026 neue Tageshöchstwerte. Die Betreiber pausieren, frischen ihre Listen auf, wechseln die Infrastruktur und kommen mit voller Stärke zurück. Ist dein Log zwei Wochen ruhig, heißt das nicht, dass es vorbei ist.

Die Bots tarnen sich dabei als Menschen. Laut DataDome laufen viele davon über Browser-Automatisierung wie Playwright, die sich für echte Browser ausgibt und bei Fake-Registrierungen und Credential-Tests zum Einsatz kommt. Ein CAPTCHA allein ist deshalb eine Hürde, keine Mauer.

Wie schnell finden Bots eine Plugin-Lücke?

Schneller, als du ein Update einspielst. Patchstack zählt in seinem Bericht State of WordPress Security 2026 für das Jahr 2025 insgesamt 11.334 neue Lücken im WordPress-Umfeld, 42 Prozent mehr als im Jahr davor, 91 Prozent davon in Plugins. Bei den am stärksten angegriffenen Lücken lag die mittlere Zeit bis zur Massenausnutzung bei fünf Stunden. Etwa 20 Prozent griffen die Angreifer binnen sechs Stunden an, 45 Prozent binnen 24 Stunden, rund 70 Prozent binnen sieben Tagen. Und 46 Prozent der Lücken hatten bei der Veröffentlichung noch gar keinen Patch.

Wie voll die Pipeline ist, sieht man bei Wordfence. In den acht Wochenberichten, die ich mir von Jänner bis August 2026 angesehen habe, standen zwischen 89 und 289 neue Schwachstellen pro Woche, fast alle in Plugins und Themes. Mein Eindruck dazu: Ein Patch zeigt, wo die Lücke saß. Wer den Code vor und nach dem Update vergleicht, hat den Bauplan, und genau diese Fleißarbeit lässt sich automatisieren.

Warum darfst du dem User-Agent in deinem Log nicht trauen?

Weil ihn jeder fälschen kann. GreyNoise hat zwischen 28. Juli und 23. August 2026 Scanner von 824 IP-Adressen beobachtet, die 13 Crawler-Namen von acht KI-Firmen vortäuschten. Sie fragten nach .env-Dateien, Cloud-Zugangsschlüsseln, privaten Schlüsseln und Passwortspeichern. Keiner der sechs gleichzeitig auftretenden Namen rief je die robots.txt ab. Der echte Crawler von Anthropic tut das laut GreyNoise bei 12 Prozent seines Traffics und fragt nie nach Zugangsdaten. GreyNoise hat die Analyse samt allen 824 Adressen veröffentlicht, damit Betreiber ihre Logs prüfen können.

Ein Bild dazu, das leicht hinkt, aber den Kern trifft: Du hängst ein Schild an die Tür, auf dem steht, wer hereindarf, und jeder Einbrecher schreibt sich einfach denselben Namen aufs Hemd.

Was passiert bei SQL Injection in Kommentaren, Formularen und Chatbots?

Im Juli 2026 hat sich gezeigt, dass SQL Injection kein Relikt aus 2008 ist. Die Lücke wp2shell sitzt im WordPress-Kern: eine SQL Injection im Parameter author__not_in von WP_Query, kombinierbar mit einem Fehler in der REST-API zu Remote Code Execution ohne Login. WordPress hat am 17. Juli 2026 die Versionen 6.9.5 und 7.0.2 veröffentlicht. Binnen zwei Tagen lag öffentlicher Exploit-Code vor, der beide Fehler zu Code-Ausführung ohne Login verkettet, und die Scans darauf setzten schon am nächsten Tag ein.

Dass Sprachmodelle solche Schritte selbst können, haben Forscher 2024 gezeigt. Ein GPT-4-Agent mit einfachen Werkzeugen nutzte in einer Studie zu One-Day-Schwachstellen 87 Prozent der getesteten bekannten Lücken aus, darunter eine SQL Injection über ein WordPress-Plugin. GPT-3.5 und die getesteten Open-Source-Modelle scheiterten damals komplett. Eine frühere Arbeit zeigte, dass solche Agenten selbständig Datenbank-Schemata auslesen und SQL Injections durchführen. Das ist ein Laborwert von 2024, kein Beleg dafür, wie oft das in freier Wildbahn passiert. Es zeigt nur: Die Fähigkeit existiert, und seither sind die Modelle besser geworden.

Der Chatbot ist die dritte Eingabemaske, nur antwortet sie freundlich. 2023 überzeugte jemand den ChatGPT-basierten Verkaufsbot eines Chevrolet-Händlers in Kalifornien, jede Kundenforderung als rechtsverbindliches Angebot zu bestätigen, und der Bot stimmte einem Auto für einen Dollar zu. Das war ein Mensch mit einem Satz Text, kein Bot-Schwarm. Aber der Mechanismus ist derselbe. OWASP führt Prompt Injection in seiner Liste für LLM-Anwendungen auf Platz eins, und ein zweites Risiko wird gern übersehen: Baut ein Chatbot aus der Eingabe eine Datenbankabfrage, kann ein manipuliertes Modell selbst eine SQL Injection erzeugen. Bei SQL gibt es mit parametrisierten Abfragen eine saubere Gegenmaßnahme. Bei Prompts gibt es keine Entsprechung, weil das Modell Anweisung und Daten nicht strukturell trennt. Wie indirekte Prompt Injection funktioniert, habe ich am Beispiel von KI-Agenten beschrieben.

Was kann ich als Webseitenbetreiber heute tun?

Das sind die acht Maßnahmen, die ich meinen Kunden zuerst empfehle:

1. Updates automatisch, aber mit Backup. Lass Sicherheitsupdates für Core und Plugins selbst laufen. Bei wp2shell hat WordPress automatische Updates für betroffene Versionen sogar erzwungen. Lösch Plugins, die du nicht brauchst. Fallstrick: Ein Backup, das du nie zurückgespielt hast, ist eine Hoffnung.
2. Virtual Patching oder WAF davor. Weil 46 Prozent der Lücken ohne Patch erscheinen, hilft Updaten allein nicht. Eine Firewall mit WordPress-Regeln (Patchstack, Wordfence oder die WAF von Cloudflare) blockt bekannte Angriffe, bis der Hersteller nachzieht. Frag nach einer Regel für die konkrete Lücke, statt auf generische SQL-Filter zu vertrauen.
3. Login härten. NCSC und CISA empfehlen Passkeys, wo ein Dienst sie anbietet, sonst Multi-Faktor-Authentifizierung und ein einzigartiges Passwort pro Konto aus einem Passwortmanager. Fallstrick: Infostealer wie LummaC2 klauen aktive Session-Tokens und umgehen damit sogar MFA. Ein verseuchter Rechner macht jede Login-Härtung wertlos.
4. Login-Endpunkte bremsen. Setz ein Rate Limit am Webserver (bei nginx mit limit_req), begrenze Fehlversuche und schalte XML-RPC ab, wenn du es nicht brauchst. Tipps dazu stehen auch in meinem Artikel über KI-Agenten in Wikipedia. Fallstrick: Reine IP-Sperren halten nicht lange, weil die Betreiber ihre Infrastruktur rotieren.
5. Geheimnisse raus aus dem Web-Root. .env, .git, Schlüsseldateien und Backup-ZIPs gehören nicht ins öffentliche Verzeichnis. Ruf deine-domain.at/.env und deine-domain.at/.git/config einmal selbst auf. Antwortet der Server, hast du ein Problem, bevor es ein Bot findet.
6. Bots per IP prüfen, nicht per Name. Gleich echte Crawler mit den veröffentlichten IP-Listen der Anbieter ab. Cloudflare verifiziert Bots genauso, über IP-Listen oder Reverse DNS. Eine robots.txt ist eine Bitte, kein Schutz.
7. Eingaben und Datenbank richtig bauen. In eigenem Code gehören parametrisierte Abfragen hinein, in WordPress heißt das $wpdb->prepare(). OWASP nennt Prepared Statements die erste Verteidigung. Prüf Code, den ein KI-Tool geschrieben hat, wie fremden Code. Gib dem Datenbank-Benutzer nur die Rechte, die WordPress braucht. Bei Kommentaren und Formularen helfen Honeypot-Felder, Moderation und Limits, das CAPTCHA kommt dazu.
8. Den Chatbot einsperren. Gib ihm nur lesenden Zugriff auf freigegebene Inhalte, keine Kundendaten im Prompt und keine Schreibrechte auf die Datenbank. Behandle jede Modell-Ausgabe als unsicher, bevor sie in SQL, HTML oder eine Shell wandert. Begrenze die Anfragen pro Nutzer, protokollier die Eingaben und lass bei riskanten Aktionen einen Menschen freigeben. Die fünf Prinzipien für vertrauenswürdige KI-Agenten helfen als Checkliste.

Was machst du mit Logs, Backups und der Meldepflicht?

Heb deine Logs auf, mindestens ein paar Wochen, und schau hinein, nicht nur ins Analytics-Tool. Wer keine Logs hat, kann im Ernstfall nicht belegen, was passiert ist. Behandle außerdem den Verdachtsfall wie einen Ernstfall: Sind personenbezogene Daten betroffen, etwa Kommentar-E-Mails oder Formulareinträge, meldest du die Verletzung nach Art. 33 DSGVO unverzüglich und möglichst binnen 72 Stunden der Datenschutzbehörde, außer sie führt voraussichtlich nicht zu einem Risiko. Meldest du später, brauchst du eine Begründung für die Verzögerung.

Was würde ich an deiner Stelle heute noch tun?

Öffne deine Logs und such nach drei Dingen: Zugriffen auf /.env und /.git, Login-Versuchen in Serie und SQL-Zeichen wie UNION SELECT in Kommentaren, Formularen und Chatbot-Eingaben. Das dauert zehn Minuten. Findest du etwas, setz Maßnahme 1 bis 3 noch heute. Du kannst warten, bis dein Kunde anruft, weil seine Seite Werbung für Pillen zeigt. Oder du schaust jetzt nach.

Häufige Fragen