Angriffe mit KI: Was sich ändert und was weiter schützt

Seit 2025 ist belegt, dass Angreifer Sprachmodelle nicht mehr nur für äusserst glaubwürdige Phishing-Mails nutzen, sondern auch durchaus ernstzunehmende Angriffe von ihnen ausführen lassen. Für den Betrieb von Websites und Servern ändert das allerdings weniger, als viele Schlagzeilen suggerieren — an einer Stelle jedoch ändert es einiges: und zwar beim Tempo.

Was belegt ist

Im November 2025 beschrieb Anthropic, der Hersteller des Sprachmodells Claude, die erste dokumentierte Angriffskampagne, die zum grössten Teil von einer KI ausgeführt wurde. Eine staatlich unterstützte Gruppe griff rund 30 Organisationen an. Darunter Technologiefirmen, Finanzinstitute und Behörden. Die KI erledigte nach Anthropics Auswertung 80 bis 90 Prozent der Arbeit, wobei Menschen nur gelegentlich Entscheidungen trafen. In einer kleinen Zahl von Fällen gelang der Einbruch tatsächlich.¹

Ein knappes Jahr später ist das kein Einzelfall mehr. Anthropics Bericht vom September 2026 beschreibt Einbrüche, die innerhalb von Stunden abgeschlossen waren, und einzelne Täter, die Dutzende Ziele parallel verfolgten. Ein Fall betrifft Websites unmittelbar: Ein einzelner Täter entwickelte mit KI-Hilfe einen Angriff auf eine bis dahin unbekannte Schwachstelle, die die Neuinstallation von WordPress betrifft. Dabei schaffte er es, ein Administratorkonto ohne gültige Zugangsdaten anzulegen — erfolgreich bei mindestens vier Websites. Ausserdem manipulierte er die Backups eines Opfers so, dass eine Wiederherstellung ihm sofort wieder einen Zugang zum System ermöglicht hätte.²

Googles Threat Intelligence Group fand im Mai 2026 erstmals eine Zero-Day-Lücke, die nach ihrer Einschätzung mit KI entwickelt worden war: eine Umgehung der Zwei-Faktor-Anmeldung in einem verbreiteten, quelloffenen Werkzeug zur Systemverwaltung über den Browser, vorgesehen für einen Massenangriff. Abgefangen wurde dieser Angriffscode noch in der Planungsphase, bevor er zum Einsatz kam. Was Google in diesen beiden Berichten beschreibt, ist Autonomie in Teilschritten — Agenten, die Lücken selbstständig finden, und Schadsoftware, die auf einem bereits übernommenen Gerät eigenständig weiterarbeitet —, nicht ein vollständiger Angriff, den niemand mehr steuert.^{3, 4}

Dieselbe Fähigkeit steht aber auch den Verteidigern zur Verfügung. Googles KI-Agent Big Sleep fand 2025 eine kritische Lücke in der Datenbank SQLite, die nach Googles Angaben nur Angreifern bekannt war. Das hilft allerdings nur dem, der die Korrektur danach auch einspielt.⁵

Was sich ändert: Tempo und Menge

Ein Angriff besteht aus vielen kleinen Schritten: Dienste finden, Versionen erkennen, eine passende Lücke suchen, den Angriffscode anpassen, Antworten auswerten, weitermachen. Für die meisten davon brauchte es bisher Menschen mit Erfahrung und Zeit. Ein Sprachmodell erledigt viele davon in Sekunden, rund um die Uhr und gegen viele Ziele gleichzeitig.

Am deutlichsten zeigt sich das an der Zeit zwischen dem Bekanntwerden einer Lücke und ihrer Ausnutzung. Mandiant, die Incident-Response-Sparte von Google, mass dafür 2018 und 2019 im Durchschnitt 63 Tage, 2023 noch fünf. Im Bericht M-Trends 2026 liegt der geschätzte Mittelwert bei minus sieben Tagen: Ausgenutzt wird regelmässig, bevor es überhaupt einen Patch gibt. Die Entwicklung hat vor der KI begonnen, aber KI beschleunigt sie.^{6, 7}

Das deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI) hält im Juni 2026 fest, dass sich mit KI innert Minuten bis Stunden aus einem veröffentlichten Patch ableiten lässt, wie ein Angriff aussehen muss. Seine Folgerung: Organisationen müssen Schwachstellen innert Minuten bis höchstens wenigen Stunden sichten, bewerten und bei Bedarf Patches einspielen können. Wenige Tage seien keine angemessene Reaktionszeit.⁸

Die zweite Änderung betrifft die Auswahl der Ziele. Kostet ein Angriff weniger Arbeit, lohnen sich auch Ziele, die bisher zu klein waren — genau diese Verschiebung beschreibt Anthropic. Die Annahme, eine kleine Website sei für Angreifer uninteressant, war schon immer gewagt. Heute ist sie schlicht falsch: Automatisierte Angriffe wählen nicht unbedingt nach Bedeutung aus, sondern nach Erreichbarkeit.²

Was sich nicht ändert: Woran Angriffe gelingen

Bemerkenswert ist, was in diesen Berichten fehlt: neue Angriffstechniken. Anthropic schreibt ausdrücklich, keine der beschriebenen Operationen habe auf einer Technik beruht, die Verteidiger noch nie gesehen hätten. Es sind die bekannten Einfallstore — gestohlene Zugangsdaten, nicht aktualisierte Geräte am Netzrand, offen erreichbare Dienste, eingeschleuster Datenbankcode (SQL-Injection), Phishing. Mandiant kommt für 2025 zum selben Schluss: Die grosse Mehrheit erfolgreicher Einbrüche gehe weiterhin auf grundlegende menschliche und systemische Fehler zurück, nicht auf KI selbst.^{2, 7}

Für Websites ist eine Zahl besonders aufschlussreich: Content-Management-Systeme machten im ersten Halbjahr 2026 laut VulnCheck ein Drittel aller Schwachstellen aus, die VulnCheck neu in seine Liste aktiv ausgenutzter Lücken aufgenommen hat. Jede Erweiterung, die installiert ist, aber nicht gebraucht wird, vergrössert die Angriffsfläche, ohne etwas zu leisten.⁹

Daraus folgt die Kernaussage dieses Beitrags: Gegen Angriffe mit KI braucht es nicht unbedingt eine neue Art von Schutz. Es hilft, was immer geholfen hat. Nur müssen wir Security heutzutage neu denken: lückenlos, automatisiert und konsequent überwacht.

Schichten statt einer Wunderwaffe

Leider können wir an dieser Stelle nicht eine einzige Massnahme nennen, nach deren Umsetzung alle Probleme behoben und alle Systeme sicher sind. Wir bauen daher auf ein Schichtenmodell: Jede Schicht fängt einen Teil ab, und jede geht davon aus, dass die davor versagt hat. So betreiben wir die Websites und Anwendungen, die wir für Kundinnen und Kunden hosten, und unsere eigenen. In den folgenden Abschnitten gehen wir auf diese Schichten im Detail ein.

Der „Edge“: Web Application Firewall und CrowdSec

Jede Anfrage an einen unserer öffentlich erreichbaren Webdienste läuft zunächst durch eine Web Application Firewall (WAF): ModSecurity mit dem OWASP Core Rule Set, einer gemeinsam (durch eine globale Community) gepflegten Regelsammlung gegen die gängigen Angriffsmuster — eingeschleuster Datenbankcode, fremde Skripte, Zugriffe auf Dateien ausserhalb des erlaubten Bereichs. Die Regeln erkennen Muster, nicht konkret die einzelne Schwachstelle. Sie halten deshalb auch einen Teil der Angriffe auf Schwachstellen auf, für die es noch keinen Patch gibt. Damit verschaffen wir uns Zeit, von der wir nicht einmal wussten, dass wir sie brauchen werden.

Daneben wertet CrowdSec die Protokolle aus und erkennt Verhalten statt einzelner Anfragen: wer systematisch nach Verwaltungsoberflächen sucht, Passwörter durchprobiert oder Server nach bekannten Lücken abtastet. Solche Adressen werden gesperrt, bevor sie die Website erreichen. Dazu kommt das Netz: Wer CrowdSec betreibt, teilt erkannte Angriffe und erhält im Gegenzug eine gemeinsam gepflegte Sperrliste. Eine Adresse, die anderswo angreift, kann so bei uns gesperrt sein, bevor sie die erste Anfrage stellt.

Gegen Automatisierung wirkt das besonders gut, weil Automatisierung Spuren hinterlässt. Wer Tausende Anfragen in kurzer Zeit stellt, erzeugt ein Muster — unabhängig davon, ob dahinter ein Mensch mit einem Skript oder ein Sprachmodell steckt.

Auf dem Server: Nur, was nötig ist

SSH-Zugriffe auf unsere Server sind nicht möglich mit Passwörtern, nicht als „root“ und nicht mit irgendwelchen Benutzern. Möglich sind sie nur mit einem kryptografischen Schlüssel und nur für die wenigen, fest definierten Benutzer, die sich überhaupt anmelden dürfen; Adressen, die anderswo durch Angriffe aufgefallen sind, verwirft die Firewall schon davor. Und sie lässt grundsätzlich mal gar nichts herein: Offen ist nur, was wirklich gebraucht wird. Zugänge verwalten wir zentral, und wer nicht mehr dazugehört, verliert sie auf allen Servern. All das wird bereitgestellt als Infrastructure as Code (IaC) und wird auf jedem Server gleich eingerichtet, niemals manuell.

Gegen das Durchprobieren von Passwörtern — eine der ersten Aufgaben, die sich an eine Maschine abgeben lassen — hilft also nicht ein besseres Passwort, sondern gar keines.

Im Container: So wenig Rechte wie möglich

Die Anwendungen selbst laufen jeweils isoliert in Containern, und jeder davon hat nur die Rechte, die er zum Arbeiten braucht: Das Dateisystem ist schreibgeschützt bis auf die Verzeichnisse, in denen Daten liegen müssen. Der Container läuft grundsätzlich niemals mit root-Rechten, hat eine feste Obergrenze für den Arbeitsspeicher und befindet sich in einem eigenen Netz, getrennt von den Containern anderer Kunden. Wer eine Lücke in der Anwendung ausnutzt, kann den Programmcode nicht überschreiben und hat auch keine direkte Möglichkeit, mit den Containern anderer Kunden zu kommunizieren und diese zu kompromittieren.

Ebenso wichtig ist, was gar nicht erst im Container liegt. Werkzeuge, die zum Bauen gebraucht werden, aber nicht zum Betrieb, haben dort nichts verloren. Allein das Entfernen des Paketmanagers und seiner Hilfsprogramme aus dem Image unserer eigenen Website hat im September 2026 38 kritische und hohe Befunde des Schwachstellenscanners beseitigt. Ganz zu schweigen von der Tatsache, dass fehlende Tools die Kompromittierungsversuche behindern oder gar verhindern. Weil nicht ausgenutzt werden kann, was nicht verfügbar ist.

Im Betrieb: Wissen statt annehmen

Ein Server ist nicht deshalb sicher, weil er bei der Einrichtung sicher war. Jede Nacht prüft ein Scanner (Trivy) die installierten Pakete aller Server und alle laufenden Container-Images auf bekannte Schwachstellen. Sicherheitsupdates für die Server spielen sich täglich automatisch ein; bleibt eines länger als einen Durchlauf liegen, meldet sich die Überwachung.

So haben wir im September 2026 das Image unserer eigenen Website von 5 kritischen und 51 hohen Schwachstellen auf null gebracht — gemessen, nicht geschätzt.

Ein Zeitfenster bleibt trotzdem: zwischen der Veröffentlichung einer Lücke und dem nächsten Update, und erst recht davor. Ganz schliessen lässt es sich mit keinem Updateprozess. Für genau dieses Fenster sind die anderen Schichten da — die WAF, die Angriffsmuster erkennt, ohne die Lücke zu kennen, und die knappen Rechte, die begrenzen, was ein erfolgreicher Angriff anrichten kann.

Für den Ernstfall: Backups, die ein Angreifer nicht löschen kann

Wer einen Server übernommen hat, versucht als Nächstes oft, die Backups zu löschen oder zu verändern; der WordPress-Fall oben zeigt, wie das aussieht. Unsere Backups sind verschlüsselt, liegen auf einem anderen Server und werden im Modus „append-only“ geschrieben: Ein gesicherter Server kann neue Sicherungen hinzufügen, aber keine bestehenden löschen oder überschreiben. Ältere Stände bleiben damit erhalten, auch wenn ein Angreifer diesen Server vollständig kontrolliert.

Das allein genügt nicht, man muss auch wissen, welcher Stand sauber ist. Dafür laufen die Protokolle von Edge, Servern und Anwendungen auf einem eigenen Server zusammen; sie zeigen, seit wann jemand da war. Und die Wiederherstellung haben wir geprobt. Sicherungen, die nie wirklich vollständig validiert werden, sind mehr eine Hoffnung als Absicherung.

Schutz, der die Falschen trifft

Jede dieser Schichten kann auch echte Besucher treffen. Im August 2026 sperrte die Schutzschicht am Edge auf unserer eigenen Website einzelne Besucher jeweils für einen ganzen Tag aus. Der Grund war eine einzige fehlende Datei: Das kleine Symbol im Browser-Tab (Favicon) fehlte, jeder Seitenaufruf erzeugte deshalb eine Fehlermeldung bzw. gab einen 404 zurück, und eine voreingestellte Regel wertete genug Vorkommen von 404-Fehlern innerhalb einer bestimmten Zeitspanne als Angriff. Diese Regel ist mittlerweile so angepasst worden, dass hier und da ein 404er nicht mehr direkt zu einem Block eines unbescholtenen Website-Besuchers führt.

In derselben Woche zeigte die erste Auswertung, wer die von uns betriebenen Websites eigentlich aufruft. Eine mitgelieferte Sperrliste wies praktisch alle Abrufe von KI-Diensten ab — an einem einzigen Tag rund 370 davon von Clients, die sich als ChatGPT auf Nachfrage eines Menschen ausgaben: kein Crawler, der Inhalte einsammelt, sondern ein Dienst, der für eine Antwort eine dieser Seiten lesen wollte. Für eine Firma, die ihre Kundinnen und Kunden in KI-Antworten sichtbar machen will, war das definitiv der falsche Schutz. Ob KI-Dienste eine Website lesen dürfen, entscheiden wir seitdem pro Website selbst: gar nicht, nur auf Anfrage eines Menschen oder vollständig (inkl. Crawler).

Beides sind keine Randnotizen. Ein Schutz, der echte Besucher aussperrt, ist kontraproduktiv und wird irgendwann ganz abgeschaltet, um keine Kunden mehr zu verlieren. Das ist nicht der Sinn der Sache. Und pauschal alles zu sperren, was nach Maschine aussieht, ist keine Sicherheitsstrategie, sondern eine Entscheidung gegen die eigene Sichtbarkeit und Auffindbarkeit.

Was Sie selbst prüfen können

Ob die eigenen Systeme gut aufgestellt sind, lässt sich mit den folgenden Fragen abschätzen. Jede Frage, die sich nicht sofort oder nicht wirklich präzise beantworten lässt, ist ein Hinweis auf Handlungsbedarf.

• Was ist von aussen erreichbar? Hauptsächlich intern genutzte Verwaltungsoberflächen, Datenbanken und sonstige Anmeldungen per Passwort gehören nicht offen ins Internet.
• Wie erkennen Sie, dass eines Ihrer Systeme eine Sicherheitslücke aufweist?
• Wie schnell kommt ein Sicherheitsupdate tatsächlich auf Ihre Systeme — und woher wissen Sie, dass es angekommen ist?
• Steht vor der Anwendung etwas, das Angriffsmuster erkennt und eingreift, bevor die Anwendung selbst erreicht wird?
• Mit welchen Rechten läuft die Anwendung, und benötigt sie diese wirklich?
• Gibt es ein Backup, das auch jemand mit vollen Rechten auf dem Server nicht löschen kann? Wann wurde zuletzt daraus wiederhergestellt?
• Wer wird alarmiert, wenn etwas auffällt — und wer entscheidet, was dann passiert?

KI hat Angriffe schneller und billiger gemacht, nicht unaufhaltsam. Was gegen sie hilft, ist dasselbe wie vorher. Es muss nur lückenlos umgesetzt und überwacht werden.