Am Abend des 7. Mai 2026 sass Marco Bredendiek, seit drei Jahren CISO der Voelker & Sennlaub Industrieautomatik GmbH in Hagen, vor seinem dritten Espresso und einer SIEM-Konsole, die ihm Sorgen machte. Voelker & Sennlaub baut seit 1978 Steuerungstechnik fuer Walzwerke und Foerderanlagen, beschaeftigt 284 Mitarbeitende, hat einen Umsatz von 71 Millionen Euro und betreibt eine On-Premise-Infrastruktur, in der sich – gewachsen aus zwei Jahrzehnten – ein dichtes Geflecht aus VMware, ein paar Linux-VMs fuer das Engineering-Team und einer Reihe von Web-basierten Verwaltungswerkzeugen findet. Eines davon war der Anlass seiner Unruhe.

Ueber das Wochenende hatten sich auf einem internen System-Administrations-Tool, das die VPN-Konfiguration und Maschinenfreischaltungen verwaltete, drei merkwuerdige 2FA-Anmeldeversuche gehaeuft. Nicht von typischen Login-Pages, sondern direkt gegen den Token-Verifikations-Endpunkt. Die User-Konten existierten, das Passwort musste also irgendwie bekannt gewesen sein – und doch waren die zweiten Faktoren falsch. Aber: jeder Versuch wurde nach exakt 312 Millisekunden mit einem unerwarteten HTTP 200 beantwortet. Bredendiek wusste, dass das nicht stimmen konnte – ein erfolgreicher Login musste eigentlich an einer anderen Stelle der Session-Logik landen. Was er noch nicht wusste: Die Anomalie, die er gerade sah, war die operative Vorlauf-Phase einer Angriffswelle, die Google Threat Intelligence vier Tage spaeter weltweit oeffentlich machen sollte.

Was Google am 11. Mai 2026 dokumentierte

Am 11. Mai 2026 veroeffentlichte die Google Threat Intelligence Group (GTIG) einen Bericht, der eine Schwelle markiert: zum ersten Mal hat ein Anbieter mit konkretem Beweismaterial einen Zero-Day-Exploit dokumentiert, dessen Quellcode mit hoher Wahrscheinlichkeit von einem Large Language Model generiert wurde – nicht nur unterstuetzt, sondern weitgehend autonom. Der Exploit zielte auf eine logische Schwachstelle in einem weit verbreiteten Open-Source-Tool zur System-Administration ab und ermoeglichte einen 2FA-Bypass: Wer gueltige Anmeldedaten besass – etwa aus einer Credential-Stuffing-Kampagne oder einem Infostealer-Leak – konnte den zweiten Faktor anhand einer Logik-Annahme im Vertrauenspfad des Tools umgehen.

Technisch handelte es sich nicht um eine klassische Memory-Corruption, nicht um eine Injection im engeren Sinne, sondern um eine semantische Schwachstelle: das Tool ging an einer bestimmten Stelle davon aus, dass eine intern erzeugte Session-Variable nur durch den 2FA-Verifikations-Pfad gesetzt werden koenne – was nicht stimmte. Wer den richtigen API-Endpoint in der richtigen Reihenfolge mit korrekt strukturierten Parametern aufrief, setzte die Variable selbst und durfte fortan als „2FA-validiert" gelten.

Diese Klasse von Schwachstellen ist fuer klassische statische Code-Analyse besonders schwer zu finden, weil sie nur in der Komposition mehrerer korrekt funktionierender Codepfade sichtbar wird. Und genau das ist es, wofuer ein LLM mit Zugriff auf den vollstaendigen Quellcode des Tools praedestiniert ist: das Lesen von viel Code, das Erkennen von Annahmen, die mehrere Dateien spannen, und das Generieren eines Aufruf-Skripts, das diese Annahmen geziehlt umgeht.

GTIG fand den Exploit in einem Python-Skript, dessen Stilmerkmale – ausfuehrliche Docstrings, ueberkonsistente Type-Hints, ein leicht kuenstlich wirkender Mix aus formaler und umgangssprachlicher Kommentierung – die fuer LLM-Output typischen Spuren trug. Google bewertet mit hoher Konfidenz, dass das Skript ueberwiegend von einer KI generiert wurde, mit minimalem menschlichem Schliff. Der Vendor wurde verstaendigt, ein Patch ausgeliefert, und GTIG arbeitete mit dem Vendor zusammen, um den Patch zu verteilen, bevor die Angriffsgruppe ihre geplante Massenausnutzung starten konnte. Die Angreifer haben den Exploit also entwickelt – aber sie haben ihn nicht in grosser Breite einsetzen koennen.

Warum das fuer den Mittelstand mehr ist als nur eine Schlagzeile

Der unmittelbare Reflex eines IT-Verantwortlichen, der diese Nachricht ueberfliegt, ist „glaubwuerdig, beunruhigend, betrifft Google – nicht mich". Diese Lesart greift zu kurz. GTIG dokumentiert in derselben Berichtsfamilie naemlich auch das deutlich breitere Bild: polymorphe Malware-Familien, die ihre Codepfade zur Laufzeit von einem LLM erzeugen lassen, autonome Schadcode-Frameworks wie das von Google PROMPTSPY genannte System, das Befehlssequenzen aus Modell-Outputs ableitet, und ein Anstieg sogenannter Model-Distillation-Angriffe, mit denen Angreifer aus Anfragen an kommerzielle LLM-APIs eigene, lokal nutzbare Modellkopien gewinnen. Attribution: Beobachtetes Interesse an AI-getriebener Schwachstellenfindung wird von GTIG insbesondere staatlichen Akteuren aus der Volksrepublik China und der Demokratischen Volksrepublik Korea zugeschrieben.

Fuer den deutschen Mittelstand bedeutet das drei harte operative Konsequenzen:

Erstens: die Angreifer-Geschwindigkeit steigt. Wer bisher davon ausging, dass eine neu veroeffentlichte Schwachstelle erst nach Tagen oder Wochen waffenfaehig wird, weil Angreifer manuell einen Exploit schreiben muessen, irrt. Mit LLM-Unterstuetzung schrumpft das Zeitfenster auf Stunden. Die Patch-Window-Annahme, auf der viele Mittelstands-IT-Konzepte beruhen – „wir patchen am naechsten Wartungsfenster" – ist damit nicht mehr tragfaehig fuer alles, was internetexponiert ist.

Zweitens: die Detection-Annahme stimmt nicht mehr. Klassische signaturbasierte Erkennung – das Modell, auf dem die meisten EDR- und AV-Loesungen weiterhin grossen Wert legen – funktioniert nur dann, wenn Schadcode wiederkehrende Muster hat. Wenn ein Angreifer-Framework seine Codepfade bei jedem Lauf neu generiert, sind keine Signaturen mehr da, gegen die man matchen koennte. Behavior-Based Detection, basierend auf Prozess-, Netzwerk- und Identitaets-Verhalten, wird vom „Nice to have" zur Grundvoraussetzung.

Drittens: die Angriffs-Oekonomie skaliert. Wer 2024 ein Pentest-Team von 6 Personen einsetzte, um in zwei Wochen ein Mittelstandsnetz durchzuspielen, kann 2026 dasselbe mit zwei Personen plus drei Agenten in drei Tagen. Auf der Angreiferseite gilt dasselbe. Das bedeutet: die marginalen Kosten eines Angriffs sinken, und damit wird die schlichte „wir sind zu klein, wir lohnen nicht" -Annahme endgueltig falsch.

Bredendieks Wochenende: was er dann tat

Marco Bredendiek hat in der Nacht zum 8. Mai eine Entscheidung getroffen, die viele seiner Kollegen erst eine Woche spaeter trafen: Er hat das System-Administrations-Tool, von dem die Anomalie kam, sofort hinter eine separate Bastion-Authentifizierung gezogen und alle bestehenden Sessions invalidiert. Er hat um 23:47 Uhr seine zwei Senior-Admins ueber das Notfall-Telefon erreicht, eine halbe Stunde spaeter die Geschaeftsfuehrung. Die Geschaeftsfuehrung wiederum hatte – aufgrund einer Empfehlung aus einem NIS2-Vorbereitungs-Workshop, den Voelker & Sennlaub Anfang 2025 mit externer Unterstuetzung durchlaufen hatte – ein klares Mandat: bei begruendetem Verdacht auf laufende Kompromittierung darf der CISO Systeme aus dem Internet nehmen, ohne formale Genehmigung.

Am Morgen des 8. Mai hat Bredendiek dann drei Dinge parallel angegangen:

Spurensicherung. Die Logfiles des betroffenen Tools wurden in eine schreibgeschuetzte Forensik-Umgebung kopiert. Jeder Request mit auffaelliger Timing-Signatur (genau 312 ms Antwortzeit, derselbe User-Agent, derselbe IP-Block aus einem osteuropaeischen Hosting-Provider) wurde isoliert. Bredendiek dokumentierte alles in einem zeitlich versionsstabilen Ablage-Mechanismus, weil er wusste, dass diese Daten im Zweifel als Nachweis Richtung BSI und Versicherung gehen mussten.

Hypothese-Test. Mit dem im selben Workshop trainierten Team fuehrte Bredendiek eine kurze Replay-Analyse durch: Konnten die Angreifer mit den von ihnen verwendeten Requests tatsaechlich einen 2FA-Bypass schaffen? Antwort: Ja – aber das Tool war in einem Netzsegment isoliert, das keinen direkten Zugriff auf SAP, auf die OT-Steuerung oder auf die Engineering-Datenbanken hatte. Der laterale Sprung waere nicht trivial gewesen. Voelker & Sennlaub hatte hier das Glueck einer halbwegs ordentlichen Netzsegmentierung.

Geschaeftsfuehrungs-Briefing. Um 11:00 Uhr stand Bredendiek in einer Vorstandssitzung und legte den Tatbestand offen. Die Geschaeftsfuehrung – im Mittelstand oft im Detail noch nicht NIS2-trainiert – hatte zwei Fragen: „Mussten wir das melden?" und „Was kostet das jetzt?" Beide Fragen lassen sich nur dann ruhig beantworten, wenn vorher eine Meldekette und ein Budget definiert wurden. Bei Voelker & Sennlaub war das der Fall.

Technische Analyse: Was am Exploit neu war – und was nicht

Es ist verfuehrerisch, den GTIG-Bericht als reines AI-Marketing zu lesen. Das wuerde ihm nicht gerecht. Die technische Substanz des Exploits lag in drei Dingen, die einzeln nicht neu waren, in der Kombination aber bemerkenswert:

1. Semantische Logik-Schwachstellen sind die naechste Angriffsklasse. Speicherfehler – Buffer Overflows, Use-After-Frees, Format-String-Bugs – sind in modernen Stacks mit Rust, sicheren C++-Subsets und harten Mitigations wie Control-Flow-Integrity zwar nicht ausgestorben, aber teurer auszunutzen. Logik-Fehler dagegen liegen flach im Anwendungscode jedes Web-Frameworks und jedes Workflow-Tools, das es gibt. Wer eine API-Architektur mit 30 Endpunkten und 14 verschiedenen Vertrauenszustaenden betreibt, hat eine offene Angriffsflaeche fuer genau diese Klasse. LLMs sind gut darin, diese Zustandsmaschinen zu erfassen und Aufruf-Sequenzen zu generieren, die in legitimen Pfaden nicht vorkommen.

2. Der Angriff war LLM-gepraegt, nicht LLM-getragen zur Laufzeit. Der ausgefuehrte Exploit-Code lief auf einem klassischen Python-Interpreter – kein LLM-Inference zur Angriffszeit, kein Online-Zugriff auf ein Modell. Die KI hat den Code geschrieben, die Operationalisierung lief konventionell. Das ist wichtig, weil es bedeutet: Netzwerkbasierte LLM-Anomalie-Erkennung (etwa „warum spricht dieser Endpoint mit OpenAI?") hilft hier nicht. Die Verteidigung muss vom resultierenden Verhalten ausgehen, nicht von der Build-Pipeline der Angreifer.

3. Mass-Exploitation war vorbereitet, aber nicht durchgefuehrt. Aus den begleitenden Operations-Tools der Angreifer ging hervor, dass die Gruppe Listen mit ueber 14.000 Zielen vorbereitet hatte – Unternehmen, die das verwundbare Administrations-Tool oeffentlich exponiert betrieben. Hier liegt die wichtigste praktische Botschaft: AI-Exploit-Entwicklung ist nicht teurer geworden, sie ist billiger. Wo frueher ein 0-Day fuer einen Hochwert-Akteur kuratiert wurde, wird er heute genutzt, um auf einen Schlag mittelgrosse Kohorten anzugreifen. Wer glaubt, „das ist Spionage-Schwerstgewicht, das trifft uns nicht", verkennt die Demokratisierung der Offensive.

Wider die Reflexe: was jetzt nicht zu tun ist

Die haeufigste Fehlreaktion im Mittelstand wird in den naechsten Wochen lauten: „Wir verbieten alle KI-Tools". Das ist verstaendlich und falsch zugleich. Verstaendlich, weil die Schlagzeile Angst macht. Falsch, weil die KI-Nutzung im Unternehmen unabhaengig von der Bedrohungslage einen Produktivitaetsvorteil bringt, den sich der Markt nicht mehr nehmen lassen wird – und weil sich gleichzeitig defensive KI-Werkzeuge entwickeln, die kuenftig genauso unentbehrlich sind, wie es Antivirus in den 90ern war.

Die richtige Lesart ist: KI ist ein Faktor, kein Feind. Sie ist in der Hand des Angreifers ein Beschleuniger, in der Hand des Verteidigers ein gleicher Beschleuniger. Wer das eine ohne das andere zulaesst, faellt zurueck. Eine vertiefende Darstellung der defensiven KI-Strategie finden Sie unter unserer KI-Seite und insbesondere zur Integration in bestehende Architekturen unter KI-Strategie und Integration.

Handlungsempfehlungen: was IT-Verantwortliche jetzt strukturell anpacken muessen

1. Detection Engineering vor Signature-Care. Wer in seinem SIEM oder XDR-System primaer Signature-Detection laufen hat, sollte das Budget der naechsten zwei Quartale auf Verhaltensanalysen umlenken. Sysmon-basierte Process-Trees, EDR-Rules ueber Eltern-Kind-Beziehungen, ungewoehnliche Netzwerk-Pfade. Nicht „was ist die Binary", sondern „was tut sie". Das ist nicht neu – aber es ist nun unverzichtbar.

2. Identity-First-Architektur. Die GTIG-Schwachstelle griff am 2FA-Layer. Das ist kein Zufall. Wer Identity Provider, Sessions und Vertrauensgrenzen als verteilte, unzentrierte Eigenschaften seines Stacks hat, hat genau die Klasse von Schwachstelle, die LLM-getriebene Angreifer suchen. Empfehlung: alle Authentication-Pfade unter einem zentralen IdP zusammenfuehren (Entra ID, Keycloak, Okta), Step-Up-Authentication bei Privilegien-Eskalation, und kontinuierliche Risiko-Bewertung der Sessions.

3. Anomalie-Detection auf Login-Flows. Bredendieks Glueck war, dass ihm die 312 ms Antwortzeit aufgefallen sind. Das war ein zufaelliger menschlicher Befund. Strukturell brauchen Sie ein UEBA-Tool oder zumindest eine SIEM-Regel, die Latenz-Anomalien und Sequence-Anomalien in Authentication-Endpunkten erkennt. Solche Regeln zu bauen, ist machbar – und gehoert in jeden Detection-Engineering-Backlog der naechsten 90 Tage.

4. AI Red Teaming und Adversarial Simulation. Wer 2026 keine externen Penetrationstester einsetzt, die LLM-gestuetzte Angriffsketten simulieren, testet seine Defense gegen einen Angreifer von 2023. Empfehlung: bei der naechsten Pen-Test-Ausschreibung explizit nach AI-augmentierten Testszenarien fragen und die Reports auf Detection-Luecken bei semantischen Logik-Angriffen pruefen.

5. Build-Pipelines und Quellcode-Schutz. Wenn LLMs gut darin sind, aus Quellcode Schwachstellen abzuleiten, wird Quellcode zu einem Asset, das mindestens so streng zu schuetzen ist wie Datenbank-Backups. Source-Code-Repositories gehoeren hinter IdP, Audit-Logging, Branch-Protection, und – fuer kritische Code-Anteile – hinter ein dediziertes Geheimhaltungs-Setup. Wer SBOMs als Anhang im NIS2-Audit fuehrt, sollte 2026 auch eine Code-Repo-Inventur ergaenzen.

6. NIS2- und CRA-Bezug nicht vergessen. Wer 2026 ein meldepflichtiges Sicherheits-Ereignis hat, muss innerhalb von 24 Stunden eine Erstmeldung an das BSI absetzen. Wer als Hersteller digitaler Produkte – und das umfasst im CRA auch viele Maschinenbau-Konfiguratoren, die Software an Endkunden liefern – eine ausnutzbare Schwachstelle entdeckt, hat ab 11. September 2026 eine 24-Stunden-Meldepflicht an ENISA. Lesen Sie zur Vorbereitung unsere Empfehlungen unter Compliance-Software. Die Geschwindigkeitsannahmen dort verbinden sich direkt mit den hier beschriebenen Detection-Anforderungen: Wer den Angriff nicht in Stunden erkennt, kann auch die Meldepflicht in Stunden nicht erfuellen.

7. Software-Entwicklung mit Threat Modeling. Die Schwachstelle in GTIGs Bericht war semantisch – sie haette in einem Threat-Modeling-Workshop moeglicherweise gefunden werden koennen. Wer im eigenen Haus Software entwickelt, sollte Threat Modeling zur Pflichtkomponente jedes Release-Zyklus machen. Wir unterstuetzen mit konkreten Methoden und Templates – mehr unter Softwareentwicklung und Projektmanagement.

Voelker & Sennlaub vier Wochen spaeter

Bredendiek hat in der Folge sechs Wochen damit verbracht, die Lehren strukturell umzusetzen. Konkret heisst das bei Voelker & Sennlaub heute:

  • Alle internetexponierten Administrations-Tools sind hinter eine Zero-Trust-Reverse-Proxy-Schicht gezogen, mit Conditional Access aus dem zentralen Entra-ID-Mandant.
  • Die SIEM-Logik wurde um sieben neue Regeln erweitert, die Latenz-, Sequenz- und Geo-Anomalien in Authentication-Endpunkten erkennen.
  • Ein externer AI-Red-Team-Partner laeuft seit Anfang Juni 2026 in einem rollierenden Auftrag und prueft monatlich gegen LLM-augmentierte Angriffsmuster.
  • Die Geschaeftsfuehrung hat die NIS2-Meldekette in die Notfall-Telefonliste aufgenommen, und das Pflicht-Training fuer alle Verantwortlichen ist seit Mitte Mai vereinbart.
  • Das Budget fuer Detection Engineering wurde fuer 2026 und 2027 verdoppelt – als bewusste Investition in Erkennungs-Geschwindigkeit, nicht in Praevention.

Bredendieks groesste Lehre, die er bei jedem internen Vortrag wiederholt: „Wir haben Glueck gehabt, weil ich am Sonntagabend einen Espresso zu viel hatte und auf die Konsole geschaut habe. Glueck ist keine Strategie. Die naechste Anomalie wird ein Agent sehen muessen, kein Mensch."

Ausblick: Was im zweiten Halbjahr 2026 zu erwarten ist

Wir gehen davon aus, dass der GTIG-Bericht nicht ein Einzelfall bleibt, sondern der Auftakt einer Serie aehnlich gelagerter Disclosures ist. Vier Entwicklungen sind in den naechsten sechs Monaten plausibel:

Erstens: Weitere AI-built Zero-Days werden in beobachteten Angriffsketten dokumentiert, mit zunehmender Dichte aus dem Bereich Open-Source-Web-Applikationen und Identity-Tools.

Zweitens: Defensive AI-Werkzeuge – also LLM-gestuetzte Schwachstellen-Scanner, Threat-Hunting-Assistenten und Detection-Rule-Generatoren – kommen in den Mainstream. Wer hier 2026 nicht anfaengt, hat 2028 einen schwer aufzuholenden Rueckstand. Lesen Sie zur strategischen Einbettung unsere Hinweise zur KI-Strategie.

Drittens: Versicherungen werden ihre Cyber-Policen umstellen und auf nachweisbare Detection-Faehigkeit hin pruefen. Wer im Schadensfall nur Praeventionsmassnahmen nachweisen kann, aber keine ausreichende Detection, wird hoehere Selbstbehalte bekommen.

Viertens: Das BSI und ENISA werden in ihren Empfehlungen zunehmend von einem „Annahme-Default: Angreifer nutzt KI" ausgehen. Das wird die Anforderungen an Detection-Geschwindigkeit, an Logging-Tiefe und an Meldekette in den nationalen NIS2-Konkretisierungen heben.

Voelker & Sennlaub hat es geschafft, mit relativ moderaten Mitteln – einem aufmerksamen CISO, einer halbwegs geordneten Netzsegmentierung und einer Geschaeftsfuehrung, die Notfall-Mandate vorab geklaert hatte – einen Vorfall zu adressieren, der drei Monate frueher das Unternehmen massiv geschaedigt haette. Das ist kein Zufallsgluek. Das ist das Ergebnis einer Vorbereitung, die heute in jedem Mittelstandsunternehmen moeglich, leistbar und – nach dem GTIG-Bericht – schlicht nicht mehr aufschiebbar ist.

Wenn Sie wissen wollen, wie weit Ihr Haus auf diese neue Bedrohungslage vorbereitet ist, sprechen Sie uns an: /kontakt. Wir analysieren mit Ihnen den Status, definieren die naechsten drei Schritte und begleiten Sie bei der Umsetzung.