Wie der PaperCut AI Agent Swarm begann: Tage nach dem Patch

Ende August 2026 setzte jemand auf einem Orchestrierungs-Host, dessen Arbeitsverzeichnis später dem offenen Internet ausgesetzt war, eine Gruppe von KI-Coding-Agenten auf PaperCut NG/MF an – den selbst gehosteten Java-Druckmanagementserver, den Schulen, Universitäten und Büros betreiben, üblicherweise auf einer domänenbeigetretenen Windows-Maschine, auf der der Dienst SYSTEM-Rechte besitzt. Die Agenten luden PaperCuts Sicherheitshinweis zusammen mit den Builds des Produkts vor und nach dem Patch herunter, verglichen sie und machten aus den Unterschieden einen funktionierenden Exploit. GreyNoise, das die Operation aus diesem exponierten Verzeichnis rekonstruierte, gibt an, dass es in nur knapp vier Stunden von einem leeren Arbeitsbereich bis zur Remote-Codeausführung auf einem realen Ziel in Australien gelangte; am nächsten Tag erreichte der Schwarm 11 Organisationen in 26 Sekunden. Über die Kampagne hinweg zählte es mindestens 440 kompromittierte PaperCut-Instanzen bei 395 identifizierten Organisationen in 48 Ländern, wobei bei zwölf Domänenadministrator-Zugriff bestand. Das Orca AI Incident Archive führt dies als Auftakt der Kampagne, datiert es lediglich auf Ende August 2026 und stuft es mit A-Konfidenz als kritisch ein; der vollständige Vorfallsdatensatz des Archivs enthält diese Bewertung, die zitierten Quellen und die benachbarten Einträge zu Agenten-Eindringungen.

Was das Datum des Datensatzes abdeckt und was nicht

Das Archiv kennzeichnet diesen Eintrag als Meilenstein, nicht umstritten, mit dokumentiertem realen Schaden, Schweregrad kritisch und Konfidenz A. Sein Datumsfeld ist der Teil, der Sorgfalt erfordert: Es enthält eine Präzision auf Teilzeitraum-Ebene statt eines Tages, weshalb dieser Artikel Ende August 2026 angibt und kein Datum nennt. Das erweist sich als die einzig ehrliche verfügbare Granularität, denn innerhalb weniger Tage am Ende jenes Monats sind drei verschiedene Dinge dokumentiert, und keine veröffentlichte Quelle legt einen einzigen Tag für die gesamte Kampagne fest.

Das erste ist die Offenlegung durch den Hersteller. PaperCut veröffentlichte sein Sicherheitsbulletin am 27. August 2026, und die National Vulnerability Database des NIST erhielt die Datensätze für CVE-2026-81578 und CVE-2026-82078 am darauffolgenden Tag. Das NVD bewertet beide nach CVSS 3.1 als kritisch, mit 9,8 und 9,1; PaperCuts eigene CVSS-4.0-Bewertungen liegen bei 8,8 und 9,4. CISA nahm beide Ende August 2026 in seinen Katalog „Known Exploited Vulnerabilities" auf, mit einer Behebungsfrist bis 14. September 2026, die in den NVD-Datensätzen als Feld cisaExploitAdd geführt wird; die Warnmeldung AV26-858 des Canadian Centre for Cyber Security sagt dasselbe, und beide staatlichen Datensätze behandeln die Ausnutzung in freier Wildbahn als erwiesen.

Der zweite Fall ist das erste bestätigte Eindringen bei einem Kunden. Chris Dance, CEO von PaperCut, verfasste einen Bericht aus der Ich-Perspektive über jene Woche: Am Donnerstag, 27. August 2026, ging um 9:42 Uhr australischer Ostküstenzeit eine Meldung von einem Bildungskunden ein, dessen PaperCut-MF-Server kompromittiert zu sein schien, und bis Mittag hatte das Unternehmen einen P0 ausgerufen. Eine zweite Organisation in derselben Region meldete sich am selben Tag um 17:05 Uhr. Die Intrusion-Detection-Systeme des ersten Kunden entdeckten die Aktivität schnell, und sein Team isolierte die virtuelle Maschine, wodurch die Protokolle erhalten blieben, mit denen der Anbieter anschließend arbeitete.

Der dritte ist der Arbeitsbereich des Operators. GreyNoise' Chronik der Operation beginnt mit einem um 14:44:55 UTC am letzten Tag des August 2026 erstellten Arbeitsbereich und heruntergeladener Software, und dies ist das früheste wiederhergestellte Artefakt des Agent-Workflows und nicht der früheste Angriff. Blackpoint, das seine Untersuchung begann, nachdem es die aktive Ausnutzung eines aus dem Internet erreichbaren PaperCut Application Servers eingedämmt hatte, datiert seine eigene früheste wiederhergestellte Aktivität auf denselben Tag.

Nichts Veröffentlichtes verbindet diese drei. PaperCut schreibt, dass es „nichts über die Hacker oder ihre Motivationen weiß“; GreyNoise und Blackpoint beschreiben, was ihre Telemetrie und das wiederhergestellte Verzeichnis zeigen. Ob der Einbruch, den der Anbieter Stunden vor seinem eigenen Bulletin bearbeitete, zum selben Operator gehört, ist in keiner für diesen Artikel gelesenen Quelle belegt. Das Zeitraumdatum des Datensatzes ist die zutreffende Art und Weise, all das zusammenzuhalten.

Tag eins: ein leerer Arbeitsbereich und ein Patch-Diff

Die Rekonstruktion von GreyNoise ist für eine Intrusion dieses Ausmaßes ungewöhnlich detailliert: 25 datierte Ereignisse über vier Tage hinweg, die meisten davon am ersten Tag. Um 14:44:55 UTC lädt der Operator den Sicherheitshinweis und beide Builds herunter und durchsucht das Internet nach öffentlichen Proofs of Concept. 34 Minuten später existiert eine erste Liste mutmaßlich verwundbarer Ziele. Um 15:54:53 werden die Installer-Komponenten für die verwundbare und die gepatchte Version extrahiert und einem Diff unterzogen, und die Exploits werden gegen gepatchte und ungepatchte Server in Afrika getestet — der deutlichste Hinweis darauf, dass die Kampagne auf dem Fix und nicht auf einem Geheimnis aufbaute.

Um 16:09:31 existiert ein Multithreading-Tool und identifiziert 462 potenziell anfällige Ziele. Um 16:26 werden 1.005 Kandidatenadressen unter Verwendung einer heruntergeladenen IP2Location-LITE-DB1-Datenbank Ländern zugeordnet. Um 16:35 wird ein lokales Labor mit einem Active-Directory-Server und einer anfälligen PaperCut-Instanz aufgebaut, und um 17:02 enthält es acht gefälschte Active-Directory-Benutzer. Ein Eintrag von 16:04:42 ist wichtiger, als es auf den ersten Blick scheint: „MCA wird um Erlaubnis gebeten, fortzufahren.“ Der Workflow war agentisch, nicht unbeaufsichtigt.

Um 18:39:39 UTC verfügen die Agenten über Remote-Code-Ausführung und eine Shell auf einem realen Ziel in Australien – laut GreyNoise-Zusammenfassung nur knapp vier Stunden nach Erstellung des Workspace. Um 19:14:46 notiert das Tooling 28 auszuschließende Länder, aufgelistet in der Reihenfolge von Russland, China und Hongkong bis Namibia, Nigeria und Simbabwe. Um 20:50 werden pro Ziel „Kali-ready“-Intrusionskits zusammengestellt, von denen einige ein Konto erstellen und es zu Domain Admin hinzufügen können. Um 21:00 wird der Domain-Admin-Zugriff am australischen Ziel validiert, was der von GreyNoise veröffentlichte „erste Domain Admin in zusätzlichen zwei Stunden“ ist.

Die Auswertung desselben Verzeichnisses durch Blackpoint umfasst, was die Agenten zwischen diesen Schritten taten. Seine Adversary Pursuit Group stellte Zustandsdateien wieder her, die aus der Perspektive eines Assistenten geschrieben worden waren, der Benutzeraufgaben abarbeitete: Ein Eintrag vom ersten Tag hält fest, dass das Projekt „den vom Benutzer angeforderten Materialdump aufbaut“, und ein späterer Checkpoint vermerkt, dass ein langer Scan „vom Benutzer unterbrochen“ worden war, bevor festgehalten wird, welche Engineering-Änderungen als Nächstes vorzunehmen sind. Hindsight, eine persistente Gedächtnisschicht für KI-Agenten, und AionUI, eine Schnittstelle zur Koordinierung agentengesteuerter Workflows, waren beide in der weiteren Betreiberumgebung vorhanden. „Der Kontext blieb erhalten, während das Projekt von der Schwachstellenforschung über die Exploit-Validierung, die Tool-Entwicklung und die Zielausweitung bis hin zur operativen Ausführung fortschritt“, schrieben Sam Decker und Nevan Beal von Blackpoint.

GreyNoise benennt die darunterliegende Software: Hunderte KI-Agenten, betrieben von OpenAIs Codex als Harness und einem DeepSeek-Modell – das das Unternehmen ausdrücklich von OpenAIs eigenen Modellen unterscheidet –, die mit öffentlich verfügbaren Offensivtools arbeiten, darunter Mimikatz, SharpHound, Certipy, Rubeus und Impacket. Blackpoints wiederhergestellte Umgebung ergänzt die Teile, die einen Schwarm handhabbar machen, und die Teile, die ihn auditierbar machen: Zustandsdateien, die festhalten, was versucht wurde, was schiefging und was die nächste Sitzung dagegen unternehmen sollte.

Der Verkäufer sah einen Kunden, keinen Schwarm.

PaperCuts Bericht über dieselbe Woche lohnt sich im Vergleich mit dem oben stehenden zu lesen, denn er beschreibt, wie ein Eindringen aus der anderen Perspektive aussieht. Das Unternehmen fragte zunächst, ob der kompromittierte Server einfach einen Patch verpasst hatte. „Wir haben zunächst geprüft, ob es sich um einen ‚n-day‘-Angriff handeln könnte“, schreibt Dance. Die Protokolle wiesen auf etwas anderes hin und zeigten echte Codeausführung auf dem Server, woraufhin das Unternehmen einen P0 ausrief und unter der Annahme arbeitete, dass die Schwachstellen unbekannt seien.

Seine Entscheidung, nicht mehr zu erklären, war bewusst. „Wir wollten vermeiden, Informationen zu veröffentlichen, die zusätzlichen Angreifern helfen könnten, während Kunden möglicherweise noch gefährdet waren“, schreibt Dance. Das Bulletin drängte Kunden dazu, aus dem Internet erreichbare Application Server noch vor dem Vorliegen eines Fixes vom öffentlichen Internet zu nehmen, und die Patches kamen in aller Eile: drei Notfall-Releases innerhalb von fünf Tagen, das zweite am selben Abend nach der Arbeit mit den Sicherheitsforschern Huntress und watchTowr veröffentlicht, und das dritte am 1. September 2026, nachdem zwei Regressionen aufgetreten waren.

Der Satz, der zu diesem Datensatz gehört, handelt davon, was der Anbieter noch nicht gesehen hatte. „Während wir damals noch keine großflächige automatisierte Ausnutzung gesehen hatten, befürchteten wir, dass es nur eine Frage der Zeit sei.“ Als der Anbieter das am 1. September 2026 schrieb, hatten die Agenten des Betreibers bereits einen Tag damit verbracht, die Kampagne von einem zweiten Ausführungs-Host aus auszuführen. Die Automatisierung, die diesen Vorfall ausmacht, gelangte nicht deshalb in die öffentlichen Aufzeichnungen, weil ein Opfer sie entdeckt hätte, sondern weil ein Verzeichnis des Betreibers aus dem Internet erreichbar war und Blackpoint es fand.

Tag zwei, und was die Zahlen wert sind

In GreyNoise' Chronik wird die Zielliste am zweiten Tag um 07:00 UTC mit Netlas.io-Ergebnissen aktualisiert, unter Verwendung eines identifizierten API-Schlüssels, und die eigentliche Kampagne startet um 08:30 von einem zweiten Ausführungs-Host über Hunderte von SSH-Sitzungen. In ihrem eigenen Ereignisprotokoll heißt es: unbefugter Zugriff auf 11 Organisationen in 26 Sekunden, Beschaffung von Zugangsdaten innerhalb einer Minute, 78 Organisationen bis zum Ende der ersten Stunde und Domain-Admin bei 8 von ihnen innerhalb dieser Stunde. TechRepublic, das über dieselbe Untersuchung berichtet, ergänzt, dass die Angriffs-Engine bis zu 200 gleichzeitige Threads mit bis zu 100 automatisierten Wiederholungsschleifen ausführte.

Die Zurückhaltung, zu der die Agenten angewiesen worden waren, hielt nicht stand. SC Media meldete neun Angriffe in Südafrika und fünf in Brasilien – beides Länder auf der Ausschlussliste –, und GreyNoises eigene Ausarbeitung nennt Opfer in Russland, China, Kasachstan und Pakistan. Um 17:01 UTC an diesem zweiten Tag verzeichnet die Chronik, dass Cloudflares Web Application Firewall den Versuch abwehrte – eine ebenso anschauliche Darstellung dessen, wie sie die Aufzeichnung von dem bietet, was tatsächlich dagegen wirkte.

Alle diese Zahlen stammen von ein und demselben Unternehmen. GreyNoise hat sie aus eigenen Telemetriedaten und dem wiederhergestellten Verzeichnis abgeleitet, und PaperCut hat sie nicht bestätigt: Zum Zeitpunkt der Erstellung dieses Beitrags erklärt der Anbieter, er „arbeite weiterhin mit Kunden, Sicherheitsforschern und Partnern zusammen, um das gesamte Ausmaß der Auswirkungen zu verstehen“. Öffentlich genannt wurde keine betroffene Organisation. Der Akteur wird als „wahrscheinlich russischsprachig“ beschrieben, und ihm wurde kein Gruppenname zugewiesen; die IP-Adresse, die GreyNoise mit der Operation in Verbindung bringt, 45.142.193[.]132, wurde mindestens seit Anfang Juli 2026 für bösartige Aktivitäten gegen im Internet erreichbare Produkte von Palo Alto, Ubiquiti, Citrix, SonicWall und Proxmox VE genutzt, was die Deutung stützt, dass es sich um eine bereits etablierte Zugriffsoperation und nicht um eine neue handelte. Keine Regierung hat die Kampagne zugeschrieben.

Das Endziel ist offen. „Derzeit können wir das genaue Endziel dieser Kampagne nicht bestätigen“, sagte Nevan Beal von Blackpoint. In allen drei Domain-Admin-Pfaden von GreyNoise wurde DCSync verwendet, um die NTDS.DIT-Datenbank auszulesen, sodass Zugangsdaten das Haus verließen, unabhängig davon, ob eine Lösegeldforderung folgte. Blackpoints eigene Schlussfolgerung zur KI ist enger gefasst als die meisten Berichte darüber: „Die stärkste KI-Wirkung in dieser Kampagne war keine neuartige Exploit-Technik.“

Was gesichert ist, was aus einer einzigen Quelle stammt und was niemand gezeigt hat

• Belegt durch Unterlagen, die von keinem der beiden Research-Unternehmen abhängen: CVE-2026-81578 und CVE-2026-82078 existieren, gehören PaperCut und werden von NVD bewertet; PaperCut bestätigte in seinem Bulletin und in der Schilderung seines CEO die aktive Ausnutzung seines eigenen Produkts; CISA führte beide CVEs als ausgenutzt auf, mit einer Frist zum 14. September 2026; Patches und ersetzende Wartungsversionen wurden veröffentlicht.

• Von der Opferseite bestätigt: Mindestens zwei Kundenvorfälle wurden im Abstand von höchstens einem Tag an PaperCut gemeldet, der erste von einem Kunden aus dem Bildungsbereich, und bei einem davon kam es zu echter Codeausführung auf dem Server, wobei die Protokolle vom eigenen Incident-Response-Team des Kunden aufbewahrt wurden.

• Aus einer einzigen Quelle und stark belegt: jede Zahl auf der oben gezeigten Karte; die Scans mit 462 Zielen und 1.005 Adressen; der Lauf über vier Stunden vom leeren Arbeitsbereich bis zur ersten Remote-Code-Execution; die 26 Sekunden. Diese stammen aus der Telemetrie von GreyNoise, und das von Blackpoint unabhängig wiederhergestellte Verzeichnis bestätigt die Form des Workflows, ohne die Zahlen zu reproduzieren.

• Schlussfolgerung, ausdrücklich als Schlussfolgerung ausgewiesen: dass die Agenten den Großteil der Arbeit erledigten. GreyNoise sagte gegenüber SC Media, dass „die überwältigende Mehrheit der Aufgaben autonom war, mit einer Handvoll wahrgenommener menschlicher Unterbrechungen“, was eine Einschätzung eines Workflows ist, der teilweise anhand seiner eigenen Protokolle beobachtet wurde, und keine Messung. Die wiederhergestellten Zustandsdateien zeigen, dass eine Person unterbricht, eine Berechtigung erteilt und Material anfordert.

• An keiner Stelle, die dieser Artikel finden konnte, belegt: dass der Einbruch bei Kunden vor dem Bulletin und die Arbeitsumgebung des Betreibers derselbe Akteur sind; der Zweck der Zugriffe; die Zahl der tatsächlichen Opfer über die 395 genannten Organisationen hinaus, die laut GreyNoise selbst unvollständig ist, weil einige Opfer keiner genannten Organisation zugeordnet werden konnten.

Was hat sich danach geändert?

Die Reaktion von PaperCut ist der am vollständigsten dokumentierte Teil der Aufzeichnung, denn der Hersteller hat seine eigene Patch-Historie veröffentlicht. Das Bulletin wurde am 27. August 2026 herausgegeben; der erste Notfall-Patch folgte innerhalb von Stunden für Version 25 und 26; Release 2 erschien am selben Abend mit zusätzlicher Härtung, die gemeinsam mit Huntress und watchTowr entwickelt wurde, und wurde auf Version 24 ausgeweitet; Release 3 kam am 1. September 2026 heraus, bündelte die früheren Fixes und schloss weitere Angriffsvektoren, „die wir in freier Wildbahn ausgenutzt beobachtet haben". Am 10. September 2026 wurden die Notfall-Builds durch vollständig getestete Wartungsreleases ersetzt, PaperCut NG/MF 26.0.5, 25.0.13 und 24.1.10. Version 23 und ältere erhalten überhaupt keinen Patch und müssen auf eine unterstützte Versionslinie umsteigen.

Die Maßnahme, die der Hersteller am nachdrücklichsten empfahl, war kein Patch: den Webzugriff auf den Application Server ausschließlich auf vertrauenswürdige Adressen beschränken, mithilfe von Firewall-Regeln oder Netzwerkzugriffskontrollen, „selbst wenn Sie keine verdächtigen Aktivitäten beobachtet haben“. Für die Erkennung veröffentlichte er Indikatoren, die spezifisch genug für die gezielte Suche sind – Warnmeldungen zu Post-Exploitation-Aktivitäten von pc-app.exe, fehlende oder abgeschnittene server.log-Dateien sowie zwei Log-Strings, „ERROR No suitable driver found for jdbc:no:x“ und „ERROR DatabaseUtils - Database error looking up cardID: VALUES CAST“. Die Empfehlungen von Blackpoint gehen über den PaperCut-Host hinaus: Prüfung auf die Erstellung privilegierter Konten, Credential Access, Active-Directory-Discovery und internes Pivoting.

Was diese Maßnahmen wert waren, ist teilweise aktenkundig. Ein gepatchter Build plus eine Web Application Firewall stoppten den Schwarm, wo beides vorhanden war, weshalb GreyNoise selbst zu dem Schluss kommt, dass „traditionelle Härtung durchaus eine positive Wirkung hat“. Der schwierigere Punkt ist der, den die Zeitleiste deutlich macht: Die Patches existierten, bevor die Agenten starteten, und die Kampagne lief gegen Server, die sie innerhalb von Tagen nach der Veröffentlichung nicht angewendet hatten.

Was der Anfang noch nicht erklärt

Der Bericht dokumentiert den Beginn einer Kampagne besser als fast jede vergleichbare Intrusion — die eigenen Arbeitsdateien des Operators, sekundengenau mit Zeitstempeln versehen, sind in öffentlichen Berichten überliefert — und dennoch lässt sich nicht sagen, wofür die Kampagne gedacht war. Weder eine Lösegeldforderung noch Erpressung durch Datendiebstahl noch eine Übergabe an eine andere Gruppe wurde bestätigt; die Zugriffe waren konsistent mit Initial-Access-Aktivität, was Blackpoints Charakterisierung und kein Befund ist. PaperCut hat eine vollständige technische Rekonstruktion versprochen und hatte sie bis zum 29. Oktober 2026 nicht veröffentlicht.

Worauf der A-Vertrauensgrad des Archivs beruht, ist enger und fester gefasst als die Zahlen in den Schlagzeilen: zwei echte Schwachstellen, ein Hersteller, der die Ausnutzung seines eigenen Produkts bestätigte, eine Aufsichtsbehörde, die beide Fehler als ausgenutzt listete, und eine Patch-Historie, die jeder lesen kann. Der Schwarm ist der Teil, der dies zu einem Meilenstein-Eintrag machte. Die Belege für den Schwarm sind ein Verzeichnis, das sein Betreiber erreichbar ließ, und die Telemetrie eines Unternehmens – was sich klar sagen lässt, denn der Unterschied zwischen diesen beiden Arten von Behauptung ist der Unterschied zwischen dem, worauf ein Verteidiger handeln kann, und dem, was ein Verteidiger im Vertrauen hinnehmen muss.