Adobe, 13 Millionen exfiltrierte Tickets: Der "Mr. Raccoon"-Breach und die Lektion, die niemand über die Support-Lieferkette lernen will

Am 12. April 2026 postete ein Akteur namens "Mr. Raccoon" in einem Cybercrime-Forum die Behauptung, 13 Millionen Adobe-Support-Tickets gestohlen zu haben, zusammen mit den personenbezogenen Daten der Kunden, die diese geöffnet hatten. Der beanspruchte Datensatz umfasst auch 15.000 Adobe-Mitarbeiterdatensätze, das gesamte Archiv von HackerOne-Bug-Bounty-Einreichungen, interne Dokumente verschiedener Ebenen und eine Reihe von Screenshots, die — falls authentisch — einen längeren Zugriff auf die Support-Umgebung des Anbieters bestätigen würden. Adobe hat zum Redaktionsschluss keine öffentliche Bestätigung veröffentlicht.

Die typische Reaktion auf solche Nachrichten ist, sich auf die Zahl zu konzentrieren — 13 Millionen macht Schlagzeilen — oder auf die Blamage der betroffenen Marke. Wir denken, die nützliche Lesart ist eine andere. Der Adobe-Breach, wenn in den behaupteten Bedingungen bestätigt, ist eine besonders saubere Fallstudie zu drei Themen, die jede italienische Organisation bereits auf ihrer Threat-List haben sollte: (1) ausgelagerte Support-Lieferketten als bevorzugter Angriffsvektor, (2) Infostealer als Enterprise-Breach-Enabler, (3) fehlende Ratenbegrenzung und Genehmigung bei Massendatenexporten als fatale Architekturschwäche.

Die Angriffskette: Laterales Phishing und BPO als Einstiegspunkt

Das erste, was festzuhalten ist: Mr. Raccoon hat Adobe nicht im klassischen Sinne gehackt — keine Kompromittierung einer Adobe-Active-Directory-Domäne, kein Fuß in der Kerninfrastruktur des Anbieters. Er hat einen indischen Business-Process-Outsourcing-Anbieter gehackt, der Teile des Adobe-Kundensupports betreibt, und von dort den legitimen Zugriff dieses Anbieters auf das Adobe-Ticketing-System ausgenutzt, um alles zu exfiltrieren, was das System ihm zu sehen erlaubte. Dies ist eine entscheidende Unterscheidung: Die tatsächliche Angriffsfläche von Adobe endet nicht an Adobes Perimeter, sondern erstreckt sich auf jeden Mitarbeiter jedes externen Partners mit einem authentifizierten Konto auf Adobe-Systemen.

Die rekonstruierte technische Kette ist folgende. Erstens: bösartige E-Mail an einen BPO-Mitarbeiter mit Anhang oder Link, der einen Infostealer oder ein Remote Access Tool auf dem Endpoint installierte. Zweitens: vom kompromittierten Endpoint aus Beobachtung des Workflows, Sammlung gespeicherter Credentials, Mapping interner Kontakte. Drittens: laterales Phishing vom kompromittierten Gerät an den Manager des Mitarbeiters. Viertens: nach Kompromittierung des Managers Ausweitung des Zugriffs auf höhere Privilegienstufen im Adobe-Support-System, bis zu einem Agent-Account mit Export-Berechtigungen.

Der große Fisch: Der Designfehler des Massenexports

Der Rest der Kette — Infostealer, laterales Phishing, Privilege Escalation — ist schmerzhaft, aber gewöhnlich. Was danach passiert, macht diesen Fall zu einer Musterstunde, was im Design eines Enterprise-Ticketing-Systems nicht zu tun ist. Laut Cybernews und SecurityOnline konnte ein auf der Adobe-Ticketing-Plattform authentifizierter Support-Agent den Export aller Systemtickets in einer einzigen Operation anfordern, ohne Volumenbegrenzungen, ohne Ratenbegrenzung, ohne Supervisor-Genehmigung, ohne Alerting-Schwelle für anomale Volumen.

Dies ist ein Designfehler, kein Implementierungsfehler. Es ist eine Architekturentscheidung: "Ein autorisierter Agent kann alle Tickets lesen, also kann er sie auch alle auf einmal exportieren." Das fehlende Prinzip heißt "operational least astonishment": Eine Operation, die, wenn erfolgreich, eine Größenordnung an Daten weit jenseits der täglichen Arbeit eines Benutzers kompromittiert, darf nicht mit demselben Klick verfügbar sein, mit dem man auf ein Ticket antwortet.

Die bittere Überraschung: HackerOne-Einreichungen

Unter den von Mr. Raccoon beanspruchten Daten befindet sich ein Element, das die Vulnerability-Disclosure-Community aufhorchen lassen sollte: das gesamte Archiv der HackerOne-Einreichungen aus Adobes Bug-Bounty-Programm. Wenn das HackerOne-Archiv tatsächlich exfiltriert wurde, ist der Wert für Drittangreifer enorm: Jede noch offene Schwachstelle wird mit vollständigen technischen Details sofort ausnutzbar, unter Umgehung der Discovery-Phase, die normalerweise die teuerste ist.

Warum dieser Fall auch italienische Unternehmen betrifft

Die erste Reaktion vieler italienischer Security-Teams auf solche Nachrichten ist: "wir sind nicht Adobe, wir haben keine 13 Millionen Tickets". Die zweite, schärfere: "aber wir haben den Kundensupport an Infosys / TCS / Wipro / Accenture ausgelagert, und sie haben Zugriff auf unsere Systeme". Die Wahrheit ist, dass das Adobe-Breach-Modell perfekt auf mittlere und große italienische Organisationen anwendbar ist, die mindestens eine operative Funktion an einen BPO, einen IT-Partner oder einen Managed Service Provider ausgelagert haben.

Der italienische öffentliche Sektor weist eine erhebliche Exposition auf. AGID, MEF, INPS, Agenzia delle Entrate betreiben ein dichtes Netzwerk externer Anbieter mit authentifiziertem Zugriff. Der Equalize-Fall (AEGIDA 10. April) zeigte, was passiert, wenn dieses Vertrauen von innen missbraucht wird. Der Adobe-Fall zeigt die schlimmere Variante: Vertrauen nicht von innen missbraucht, sondern von außen ausgenutzt.

Was zu tun ist: Sieben Kontrollen, die heute zu überprüfen sind

1. 1.Aktuelle Bestandsaufnahme externer Partner mit authentifiziertem Zugriff, mit für jeden: Zugriffsbereich, Anzahl Konten, Privilegienstufe, zugängliche Datenflüsse.
2. 2.Überprüfung der Massenexport-Berechtigungen auf jedem System mit personenbezogenen oder kommerziell sensiblen Daten: CRM, Ticketing, DMS, Data Warehouse.
3. 3.Überarbeitung der BPO- und IT-Partnerverträge mit spezifischen Verpflichtungen: Enterprise-EDR auf allen Endpoints, phishing-resistente MFA, Benachrichtigung bei Einzel-Endpoint-Kompromittierung innerhalb von 24 Stunden.
4. 4.Segregation der Vulnerability-Management-Umgebungen (Bug Bounty, VDP, Security-Tickets) vom Rest der Support-Plattformen.
5. 5.Dediziertes Threat Hunting auf BPO-Breach-Muster: Anmeldungen aus bekannten BPO-Geografien zu Nicht-Schichtzeiten, Export-Queries mit überdurchschnittlichem Volumen, laterale Bewegungen von BPO-Konten zu internen Manager-Konten.
6. 6.Spezifisches Training für Partnermitarbeiter mit Zugriff auf Kundensysteme.
7. 7.Partner-Incident-Response-Plan: Viele italienische Incident-Response-Pläne fehlen spezifische Runbooks für den Fall "der Anbieter hat einen Infostealer auf einem Endpoint mit Zugriff auf unsere Systeme".

Die verborgene Fragilität des modernen BPO-Modells

Das Wirtschaftsmodell des Business Process Outsourcing, insbesondere das indische, ist auf Kostenoptimierung pro Ticket aufgebaut. Enge Margen, hohe Fluktuation, standardisierte Schulung, mitarbeiterseitige Sicherheitskontrollen typischerweise niedriger als die der Direktmitarbeiter des Auftraggebers. Wenn der Kundenanbieter — Adobe hier — dem BPO eine Funktion mit authentifiziertem Zugriff auf seine Systeme delegiert, überträgt er einen substantiellen Teil seiner Angriffsfläche in eine Umgebung, deren Sicherheitshaltung für ein anderes Risikoprofil ausgelegt ist.

Fazit: Das ist nicht Adobes Breach. Es ist Ihr nächster Breach.

Die Versuchung beim Lesen solcher Nachrichten ist, sie als Beobachterereignis zu behandeln. Die Realität: Das Mr.-Raccoon-Angriffsprofil ist ein Schema, das auf praktisch jede Organisation gewisser Größe mit ausgelagertem Support, IT-Management oder einer administrativen Funktion mit Zugriff auf interne Systeme anwendbar ist. Die Wahrscheinlichkeit, dass der nächste Fall die Initialen eines italienischen Unternehmens trägt, ist nicht vernachlässigbar.

Die gute Nachricht: Die sieben aufgelisteten Kontrollen sind weder exotisch noch besonders kostspielig. Die schlechte: Deren Umsetzung braucht Zeit, und die verfügbare Zeit vor dem nächsten italienischen Fall dieser Kategorie ist wahrscheinlich kurz.