Der DIVD-Einbruch über Zammad: was ein agentischer Angreifer anders macht – und was das für Ihre Reaktionszeit heißt

/01Was beim DIVD am 21. September passiert ist

Das Dutch Institute for Vulnerability Disclosure (DIVD) ist eine niederländische, überwiegend von Freiwilligen getragene Organisation, die Schwachstellen findet, Betroffene warnt und dafür seit Jahren das Internet scannt. Am 21. September 2026 wurde sie selbst Opfer. Ein Angreifer übernahm die Instanz des Open-Source-Ticketsystems Zammad, über die das DIVD seine Ticket-Kommunikation abwickelt – alle Mails an csirt@divd.nl und die übrigen Adressen unter @csirt.divd.nl.

Der Weg hinein führte laut Fallakte DIVD-2026-00014 über zwei bis dahin öffentlich unbekannte Lücken in Zammad: CVE-2026-102489, eine Session-Übernahme mit Codeausführung als Benutzer zammad, und CVE-2026-102490, eine Rechteausweitung von diesem Benutzer auf root. „After elevating to root on the system, the actor used AI agents for the further attack", schreibt das DIVD. Am 24. September machte es den Einbruch öffentlich und schrieb von einem Angriffsmuster, das es so noch nicht gesehen habe – „an agentic AI powered attack".

Zwei Dinge machen den Fall für Betreiber eigener KI- und IT-Systeme lehrreich. Erstens ist er außergewöhnlich gut dokumentiert: Das DIVD veröffentlicht Zeitachse, Kennzahlen, Meldewege und eine Fallakte zu den Lücken. Zweitens ist es einer der ersten öffentlich belegten Fälle, in dem ein Opfer aus der Sicherheitsbranche selbst beschreibt, woran es den Einsatz von KI-Agenten auf Angreiferseite erkannt hat. Dieser Artikel ordnet beides ein. Die allgemeine Warnung des BSI, dass KI das Zeitfenster zwischen Veröffentlichung und Ausnutzung verkürzt, steht im Artikel zum Patch-Fenster; hier geht es um einen konkreten Fall und um das Verhalten des Angreifers.

/02Zeitachse: vom ersten Zugriff bis zur Strafanzeige

Die folgende Zeitachse folgt den beiden Fallakten des DIVD (DIVD-2026-00014 zum Einbruch, DIVD-2026-00015 zu den Lücken) sowie den Hinweisen von Zammad und der CISA. Die rechte Spalte ist unsere Einordnung: was ein Verteidiger an diesem Tag sehen oder tun konnte.

Was die Zeitachse zeigt: Zwischen erstem Zugriff und vollständigem Fix für die Rechteausweitung lagen 17 Tage. Der Angreifer brauchte für seinen Teil laut DIVD einen kurzen Zeitraum mit hohem Volumen. Die Verteidigung brauchte für Erkennung 19 Minuten, für die Entscheidung 19 Stunden.

/03Die zwei Lücken: Session-Übernahme und root über das Paket

CVE-2026-102489 beschreibt NVD so: Zammad 6.3.0 bis 6.5.4 ist anfällig für eine Session-Übernahme, die zu Codeausführung als Benutzer zammad führt. Der Fehler steckt auch in 7.0.0 bis 7.1.2 (die DIVD-Fallakte nennt 7.1.3), ist dort aber wegen der geänderten Laufzeitumgebung nicht ausnutzbar. NVD bewertet mit CVSS 3.1 9,8, das DIVD mit CVSS 4.0 9,4. Zammad schreibt in seinem Hinweis vom 5. Oktober, man habe einen ersten Bericht zu diesem Problem bereits im August 2026 erhalten und analysiert; ausnutzbar sei es nur auf 6.5 und älter, und diese Versionen bekämen seit einiger Zeit keine Sicherheitsupdates mehr. 7.2.0 enthält eine zusätzliche Härtung des betroffenen Codes.

CVE-2026-102490 ist die Rechteausweitung. Laut GitHub-Advisory des Herstellers starteten Dienstprozesse der DEB- und RPM-Pakete (gebaut mit packager.io) als root und führten Dateien aus, die dem Dienstkonto zammad gehörten und von ihm beschreibbar waren, bevor sie die Identität wechselten. Wer bereits Code als zammad ausführen konnte, wurde „within seconds" root, weil die Dienste nach einem Stopp automatisch neu starteten. Betroffen waren alle paketierten Versionen bis 7.2.1; die offiziellen Docker-Images und Quellinstallationen nicht. Behoben in 7.2.2. NVD bewertet mit CVSS 3.1 7,8, lokal; Zammad selbst mit CVSS 4.0 8,5, das DIVD als CNA mit 9,4. Die Fallakte DIVD-2026-00015 nennt für diese Lücke noch einen älteren Versionsbereich; maßgeblich für den Fix ist das Hersteller-Advisory.

Zur Offenlegung gibt es zwei Sichten, und beide stehen öffentlich. Das DIVD veröffentlichte am 26. September eine begrenzte Offenlegung, um andere Betreiber zu warnen. Zammad schreibt, Informationen zu CVE-2026-102490 seien öffentlich geworden, bevor die technischen Details zur Reproduktion vorlagen. Für Betreiber ist das weniger ein Streit als ein Hinweis: In einem echten Vorfall läuft die Warnung schneller als der Fix. Wer erst handelt, wenn ein Patch da ist, hat in diesem Fall zwölf Tage verloren – die Empfehlung des DIVD lautete von Anfang an „upgrade to version 7 of Zammad or to take it offline".

/04Woran das DIVD den agentischen Angreifer erkannte

Das DIVD nennt in seiner Fallakte zwei Gründe, warum es von KI-Agenten ausgeht: „The shear volume of the attack and the number of artifacts generated, in a relative short period" und „the fact that attack scripts are commented and documented, and that the attack agents seem to be talking to each other in the comments of the scripts". BleepingComputer zitiert das DIVD zusätzlich mit der Beschreibung „loud and very, very messy", mit einem Agenten, der seine nächsten Schritte selbst wählte, und damit, dass sich der Vorfall rekonstruieren ließ, weil der Agent Erklärungen seiner Entscheidungen hinterließ. Diese Zitate stammen aus einer Sekundärquelle.

Das ist bemerkenswert, weil es die übliche Erwartung umdreht. Ein erfahrener menschlicher Angreifer arbeitet leise, sparsam und räumt auf. Ein Agent, wie ihn das DIVD beschreibt, arbeitet laut, breit und dokumentiert sich selbst – die Gedankenkette landet als Kommentar im Skript. Die Tabelle stellt das gegenüber; die linke Spalte ist eine verallgemeinerte Einschätzung, die rechte stützt sich auf die Beschreibung des DIVD.

Daraus folgt nicht, dass agentische Angriffe immer laut sind. Ein Agent, dessen Betreiber auf Unauffälligkeit optimiert, kann auch leise arbeiten. Aber der Fall zeigt, wo die Stärke dieser Angreifer liegt: nicht in Raffinesse, sondern in Geschwindigkeit und Breite. Ein Multi-Agenten-System, das parallel Zugangsdaten sucht, Dienste abtastet und Daten sammelt, schafft in einer Stunde, wofür ein Mensch einen Arbeitstag braucht. Für die Verteidigung heißt das: Die Anomalieerkennung hat gute Chancen, weil der Angreifer Lärm macht. Die Reaktion hat schlechte Chancen, wenn sie auf Menschen wartet, die erst zusammenkommen müssen.

/0519 Minuten, 19 Stunden, 9 Stunden: wo die Zeit verloren geht

Das DIVD veröffentlicht drei Kennzahlen: Mean Time to Detect 19 Minuten, Mean Time to Respond 19 Stunden, Mean Time to Contain 9 Stunden. Es kommentiert sie selbst nüchtern: Verbesserungsbedarf, aber für eine ehrenamtliche Organisation „not too shabby". Die 9 Stunden enthielten die Anreise des Teams in einen Hackerspace und die vorsichtige Isolation der Systeme im Rechenzentrum, ohne sich selbst vom Netz abzuschneiden.

Die Zahlen sind ehrlich und lehrreich, weil sie die Lage vieler Mittelständler spiegeln. Die Erkennung funktionierte. Was fehlte, war die Befugnis und Bereitschaft, sofort zu handeln. Gegen einen menschlichen Angreifer, der sich Zeit lässt, sind 19 Stunden bis zur Reaktion oft genug. Gegen einen Agenten, der in Sekunden arbeitet, ist die Zeit zwischen Alarm und Eindämmung der Zeitraum, in dem der Schaden entsteht.

Drei Fragen, die jedes Haus vorab beantworten sollte:

1. Wer darf nachts isolieren? Eine Person mit Bereitschaft, die ohne Rückfrage einen Host vom Netz nehmen, ein Dienstkonto sperren oder eine Firewall-Regel setzen darf – und weiß, dass sie dafür nicht kritisiert wird, wenn es ein Fehlalarm war.
2. Was genau wird isoliert? Ein vorbereitetes Verfahren je kritischem System: welche Netzsegmente, welche Konten, welche Schlüssel. Das DIVD brauchte 9 Stunden auch deshalb, weil es sich nicht selbst aussperren wollte.
3. Wo liegen die Protokolle? Außerhalb des Systems, das angegriffen wird. Ein Angreifer mit root auf dem Ticketsystem kann dessen lokale Logs ändern; eine zentrale Ablage nicht.

/06Was das für Patchfenster und Erkennung heißt

Der Fall verschiebt die Frage nach dem richtigen Patchfenster an eine unerwartete Stelle. Das Problem war hier nicht ein zu langsamer Patch, sondern eine Version, für die es keinen Patch mehr gab. Zammad 6.5 war laut Hersteller seit einiger Zeit ohne Sicherheitsupdates; das DIVD hatte, wie es selbst schreibt, nicht auf den Zweig 7 gewechselt und ließ sich danach Aufkleber drucken: „Stop yapping, start patching."

Daraus ergibt sich eine Reihenfolge, die vor jedem Zeitziel kommt: Zuerst die Systeme finden, deren Version außerhalb der Herstellerpflege liegt. Für sie gibt es kein Patchfenster, nur einen Migrationsplan. Danach gelten Zeitziele nach Erreichbarkeit und Ausnutzungslage. Zwei Behördenquellen helfen dabei unterschiedlich. Das BSI verlangt im IT-Grundschutz-Baustein OPS.1.1.3 (Anforderung A15), Patches „zeitnah“ einzuspielen, nennt aber keine Tage – und schreibt: Produkte ohne Herstellerunterstützung, die sich nicht sicher betreiben lassen, „DÜRFEN … NICHT mehr verwendet werden“. Konkrete Fristen setzt die CISA mit BOD 26-04 vom 10. Juni 2026, die BOD 22-01 abgelöst hat: Kalendertage nach vier Merkmalen – aus dem Internet erreichbar, im KEV-Katalog, automatisiert ausnutzbar, volle oder teilweise Kontrolle. Die Spalte „Zielzeit“ ist unsere Empfehlung, keine Norm; die rechte Spalte zeigt den CISA-Wert für US-Bundesbehörden.

Für Zammad selbst lässt sich der Stand in einer Minute feststellen. Die Befehle unterscheiden sich nach Installationsart; die Rechteausweitung betraf nur Paketinstallationen.

# Installationsart und Version
dpkg -l zammad 2>/dev/null | awk '/^ii/{print "DEB", $3}'
rpm -q zammad 2>/dev/null
docker ps --format '{{.Image}}' | grep -i zammad          # Container-Installation

# Version aus der Anwendung (Paketinstallation)
zammad run rails r 'puts Version.get'

# Erwartung: 7.2.2 oder neuer. 6.x: außerhalb der Herstellerpflege -> Migration.

# Unter welchem Konto laufen die Dienste, und wem gehört das Installationsverzeichnis?
ps -eo user,pid,etime,args | grep -E '[z]ammad|[p]uma|[s]idekiq' | head
stat -c '%U:%G %a %n' /opt/zammad /opt/zammad/bin 2>/dev/null

# Spurensuche: kürzlich geänderte ausführbare Dateien im Installationsverzeichnis
find /opt/zammad -xdev -type f -perm -u+x -mtime -60 -not -path '*/tmp/*' -not -path '*/log/*' | head -50

Deutung: Eine Version unter 7 bedeutet Handlungsbedarf unabhängig von allem anderen. Eine Paketinstallation unter 7.2.2 bedeutet, dass ein Angreifer mit Zugriff als zammad root werden konnte. Ausführbare Dateien im Installationsverzeichnis, die nach dem letzten Update geändert wurden und die niemand erklären kann, sind ein Fall für die Forensik. Das DIVD bietet laut Fallakte ein Skript an, das Zammad-Logdateien auf seine Kompromittierungsindikatoren prüft.

/07Grenzen: was man aus einem Fall nicht schließen kann

Ehrlich: Ein einzelner, gut dokumentierter Vorfall ist ein Datenpunkt, keine Statistik. Drei Einschränkungen gehören zu jeder Lehre, die man daraus zieht.

• Die KI-Zuschreibung ist eine Einschätzung des Opfers. Das DIVD begründet sie nachvollziehbar, aber die Ermittlungen laufen noch, und ein Angreifer könnte Kommentare in Skripten auch absichtlich setzen. Ob die kommentierte Begründung echt ist oder Tarnung, lässt sich von außen nicht prüfen. Welches Modell oder welches Werkzeug benutzt wurde, ist nicht veröffentlicht.
• Der Einstieg war klassisch. Die beiden Lücken in Zammad hat nach öffentlichem Stand kein Agent gefunden; der Agent kam nach dem root-Zugriff. Wer daraus ableitet, KI-Angreifer fänden Zero-Days auf Knopfdruck, liest mehr hinein, als dasteht.
• Laut ist kein Naturgesetz. Die gute Erkennbarkeit in diesem Fall hing am Verhalten dieses Angreifers. Ein Betreiber, der Agenten auf Unauffälligkeit trimmt, erzeugt andere Spuren.

Und die Gegenseite für Leser, die kein Zammad betreiben: Die konkreten Befehle betreffen Sie nicht, die Lehren schon. Jedes selbst betriebene System mit E-Mail-Eingang, Webzugriff und Paketinstallation – Ticketsystem, Wiki, Chat-Oberfläche für Sprachmodelle – hat dieselben drei Fragen: Ist die Version in der Herstellerpflege? Läuft der Dienst mit mehr Rechten als nötig? Wer darf im Alarmfall sofort isolieren? Für ein Haus, dessen einzige Systeme in der Hand eines Dienstleisters mit vertraglichen Reaktionszeiten liegen, verschiebt sich die Frage auf den Vertrag: Was steht dort zur Reaktionszeit, und gilt sie auch nachts?

/08Entscheidung: was ein Haus welcher Größe jetzt tun sollte

Die Lehren aus dem DIVD-Fall übersetzen sich je nach Größe und Aufstellung in unterschiedliche Schritte. Allen gemeinsam ist die Inventur der Versionen außerhalb der Herstellerpflege – sie kostet einen Nachmittag und hätte im DIVD-Fall den ersten Schritt der Kette verhindert.

• Bis etwa 50 Mitarbeiter, kein eigenes SOC: Inventur aller aus dem Internet erreichbaren Dienste mit Version und Pflegestatus; Dienste ohne Pflege vom Internet trennen. Eine benannte Person mit Abschaltbefugnis und Telefonnummer. Protokolle zentral, nicht nur lokal. Wenn ein Dienstleister betreibt: Reaktionszeit für kritische Störungen vertraglich festhalten.
• 50 bis 500 Mitarbeiter, IT-Team ohne 24/7-Bereitschaft: Zusätzlich vorbereitete Isolationsverfahren je kritischem System, einmal im Jahr geübt. Zielzeiten aus Abschnitt /06 als interne Regel. Erkennung so einstellen, dass sie hohes Volumen und viele neue Dateien in kurzer Zeit meldet – das ist bei agentischen Angreifern das stärkste Signal.
• Größere Häuser mit SOC oder MDR-Dienst: Prüfen, ob die Reaktionskette ohne Human-in-the-Loop bis zur ersten Eindämmung kommt, etwa durch automatische Kontosperre bei bestimmten Mustern. Den eigenen Ablauf gegen einen schnellen, lauten Angreifer testen lassen, nicht nur gegen einen leisen.

Für wen das Thema nicht vorrangig ist: Häuser ohne selbst betriebene, aus dem Internet erreichbare Systeme. Dort liegt die Arbeit beim Dienstleister – die Frage nach dessen Reaktionszeiten bleibt trotzdem. Bei ki·spezial beträgt die Reaktionszeit bei kritischen Störungen 15 Minuten ab Service-Klasse Business; die Standard-Klasse hat keine zugesicherte Vor-Ort-Reaktion.

/09Was Verteidiger vom Angreifer übernehmen können

Der unbequeme Teil der Geschichte: Die Werkzeuge, die der Angreifer eingesetzt hat, stehen auch Verteidigern zur Verfügung. Ein Agent, der in Minuten hunderte Prüfungen fährt und seine Schritte dokumentiert, ist für ein Red-Teaming genauso nützlich wie für einen Einbruch. Der Unterschied liegt in der Erlaubnis, im Ziel und in den Leitplanken: welche Systeme, welche Aktionen, welche Abbruchbedingungen.

Drei Einsatzfelder, in denen agentischen KI auf Verteidigerseite heute realistisch ist:

• Inventur und Abgleich. Ein Agent mit lesendem Zugriff auf Paketlisten, Container-Images und Herstellerhinweise kann täglich melden, welche Systeme eine Version außerhalb der Pflege oder mit KEV-Eintrag fahren. Das ist Werkzeugaufrufe mit geringem Risiko, weil nur gelesen wird.
• Triage von Alarmen. Ein lokal betriebenes Modell fasst die ersten Minuten eines Alarms zusammen – welche Prozesse, welche Dateien, welche Verbindungen – und legt sie der Bereitschaft vor. Die Entscheidung bleibt beim Menschen, die Vorarbeit nicht.
• Angriffssimulation. Agentische Pentest-Werkzeuge mit klar begrenztem Auftrag zeigen, ob die eigene Erkennung einen lauten, schnellen Angreifer sieht. Das ersetzt keinen erfahrenen Pentester, ergänzt ihn aber dort, wo Breite zählt. Wie gut ein solcher Agent ist, zeigt erst eine Evaluation gegen eine Testumgebung mit bekannten Schwachstellen – nicht das Datenblatt.

Für alle drei gilt: Ein Agent, der Sicherheitsdaten liest, sollte On-Premise laufen, nicht bei einem externen Dienst. Protokolle, Konfigurationen und Alarmdetails sind genau die Daten, die ein Angreifer sucht. Ein lokales Modell mit begrenzten Werkzeugen und vollständiger Protokollierung jedes Aufrufs ist hier keine Stilfrage, sondern Teil der Sicherheitsarchitektur.

Das ist keine Formsache: Das DIVD hat seine Erkennung in 19 Minuten geschafft und seine Reaktion in 19 Stunden. Gegen einen Angreifer, der in Sekunden handelt, entscheidet die zweite Zahl. Die lässt sich nicht kaufen, nur vorbereiten und üben.