Zum wiederholten Mal steht Accenture im Zentrum eines Sicherheitsvorfalls. Diesmal geht es nicht um Personaldaten, sondern um Infrastruktur-Secrets: Schlüssel, Token, Quellcode. Für Unternehmen, die mit dem Beratungsriesen arbeiten, beginnt die eigentliche Arbeit jetzt.
Am 6. Juli erschien in einem einschlägigen Darknet-Forum ein Verkaufsangebot. Der Verkäufer nennt sich „888", bezahlt wird in Monero, die Ware: rund 35 Gigabyte Daten, die aus dem Inneren von Accenture stammen sollen. Nicht irgendwelche Daten. Quellcode. RSA-Schlüssel. SSH-Schlüssel. Persönliche Azure-Zugangstoken. Azure-Storage-Keys. Konfigurationsdateien. Es ist die Sorte Beute, mit der man keine Identitäten stiehlt, sondern Infrastrukturen öffnet.
Accenture brauchte für eine Antwort gerade mal zwei Sätze. „Wir sind uns dieser isolierten Angelegenheit bewusst und haben ihre Quelle behoben", ließ Sprecher Peter Soh gegenüber Cybersecurity Dive ausrichten. Es gebe „keine Auswirkungen auf den Betrieb und die Leistungserbringung von Accenture". Nachfragen zu möglichen Folgen für Kunden? Wollte der Konzern nicht beantworten.
Das ist eine bemerkenswerte Kommunikationsleistung für ein Unternehmen, das die überwiegende Mehrheit der Fortune Global 500 berät – und das Cybersicherheit als eigenes Geschäftsfeld verkauft. Wer bei Accenture Security-Expertise einkauft, bekommt Incident-Response-Playbooks, Krisenkommunikationstrainings und Vorträge über Transparenz gegenüber Stakeholdern. Wer Accenture hingegen nach dem eigenen Vorfall fragt, bekommt zwei Sätze und Schweigen.
Was der Angreifer behauptet – und was davon belegt ist
Zunächst die nüchterne Bestandsaufnahme: Verifiziert ist das Angebot nicht. Die Zahl von 35 Gigabyte stammt vom Angreifer selbst. Ob die Daten aktuell sind, ob die Schlüssel und Token noch funktionieren, ob Kundendaten betroffen sind, wie der Zugriff überhaupt gelang – all das ist offen. Das Threat-Intelligence-Unternehmen SOCRadar, dass das Forenlisting am Tag seines Erscheinens fand, stuft den Fall entsprechend ein: ernst, aber nur teilweise bestätigt.
Nur: Accenture selbst hat den Vorfall bestätigt. Die Formulierung „wir haben die Quelle behoben" ist kein Dementi, sondern das Eingeständnis, dass es eben diese eine Quelle gab. Der Konzern bestreitet nicht den Vorfall selbst – er bestreitet lediglich dessen Relevanz. Und genau diese Frage der Relevanz beantwortet Accenture an der falschen Stelle. „Keine Auswirkungen auf den Betrieb" heißt: Die Berater arbeiten weiter, die Rechnungen gehen raus. Die Frage, die CISOs und Geschäftsführer auf Kundenseite tatsächlich umtreibt, lautet anders: Steckt in den 35 Gigabyte Code, der für uns geschrieben wurde? Sind Token darunter, die in unsere Umgebungen führen?
Warum dieser Vorfall anders wiegt als ein Datenleck
Ein gestohlener Kundendatensatz ist ein Schaden. Gestohlene Infrastruktur-Zugänge sind ein Werkzeug. Das ist der Unterschied, der diesen Fall von der üblichen Breach-Meldung abhebt.
SOCRadar erklärt in seiner Analyse aus, was die angebotenen Datentypen im Ernstfall bedeuten. Quellcode verrät Angreifern die interne Logik von Anwendungen, schwache Implementierungsmuster und – ein Klassiker – hart gecodete Zugangsdaten. SSH- und RSA-Schlüssel sowie Azure-Token öffnen, sofern noch aktiv, Repositories, Cloud-Speicher und CI/CD-Pipelines. Wer in einer Build-Pipeline sitzt, kann nicht nur lesen, sondern manipulieren: Deployment-Logik verändern, Abhängigkeiten austauschen, Signierprozesse kompromittieren.
Und damit ist man beim eigentlichen Thema: der Kaskade. „Quellcode und Konfigurationsdateien könnten Angreifern helfen, Schwachstellen in Software zu identifizieren, die von Kunden oder Partnern genutzt wird", schreiben die SOCRadar-Analysten. Accenture entwickelt, betreibt und integriert Systeme für Konzerne weltweit – auch für zahlreiche deutsche Unternehmen. Jede Zeile kundenspezifischen Codes, jede Konfigurationsdatei aus einem Kundenprojekt, die in diesem Datenpaket steckt, dient einem potenziellen Bauplan für den nächsten Angriff. Nicht auf Accenture. Sondern auf deren Kunden.
Ob es so weit kommt, hängt von diversen Faktoren ab, die derzeit niemand außerhalb von Accenture beurteilen kann: Wie aktuell sind die Daten, wurden Keys rotiert, gab es verdächtige Zugriffe vor der Bereinigung. Genau deshalb wäre Transparenz jetzt keine PR-Kür, sondern Risikomanagement für die eigene Kundschaft.
Ein Wiederholungstäter trifft auf einen Wiederholungsgeschädigten
Der Handle „888" ist in Accentures Geschichte kein Unbekannter. Im Juni 2024 behauptete ein Akteur unter demselben Alias, über einen Drittanbieter-Breach an Daten von mehr als 32.000 aktuellen und ehemaligen Accenture-Mitarbeitern gelangt zu sein. Accenture konterte damals, der Hacker übertreibe maßlos – betroffen seien Informationen zu genau drei Mitarbeitern. Wer damals recht hatte, wurde nie wirklich geklärt. Sicher ist nur: Derselbe Name taucht zwei Jahre später wieder auf, diesmal mit einem qualitativ anderen Angebot.
Und Accenture selbst? Hat eine Vorgeschichte, die zur aktuellen Zwei-Sätze-Rhetorik in unangenehmem Kontrast steht. 2021 drang die Ransomware-Gruppe LockBit in die Systeme des Konzerns ein und drohte mit der Veröffentlichung gestohlener Daten. 2017 dokumentierten Sicherheitsforscher von UpGuard falsch konfigurierte AWS-Buckets, in denen Accenture sensible Daten offen ins Netz gestellt hatte – darunter fast 40.000 Passwörter im Klartext und Zugangsschlüssel für weitere Cloud-Dienste. Drei größere Vorfälle in neun Jahren, dazu die umstrittene Episode von 2024: Das ist keine einfache Panne mehr, das ist eine Serie. Für einen Konzern, dessen Geschäftsmodell auf dem Versprechen beruht, die IT anderer besser zu machen, ist das mehr als ein Schönheitsfehler.
Was deutsche Entscheider daraus lernen sollten
Man kann den Fall als amerikanisches Problem abheften. Sollte man aber nicht. Wer Accenture – oder irgendein anderes große Beratungs- und Integrationshaus – im Haus hat, hat dessen Sicherheitsniveau im Haus. Dienstleister mit privilegierten Zugängen, gemeinsamen Repositories und geteilten Cloud-Umgebungen sind längst der bevorzugte Umweg für Angreifer, die das eigentliche Ziel direkt nicht knacken.
Regulatorisch ist das keine Grauzone mehr. NIS2 und DORA verlangen von betroffenen Unternehmen explizit, Risiken in der Lieferkette zu steuern – und dazu gehört die Frage, was passiert, wenn der Dienstleister kompromittiert wird und anschließend mauert. Ein Anbieter, der auf Nachfragen zu möglichen Kundenfolgen nicht antwortet, liefert das Argument für schärfere Vertragsklauseln gleich mit: Auskunftspflichten binnen definierter Fristen, Nachweis von Schlüsselrotationen, Auditrechte im Vorfall.
Operativ gilt für Unternehmen mit laufenden oder früheren Accenture-Engagements das übliche, aber selten konsequent umgesetzte Programm: gemeinsam genutzte Credentials und Token rotieren, Zugriffe des Dienstleisters auf eigene Repositories und Cloud-Ressourcen prüfen, Logs auf ungewöhnliche Aktivität seit Anfang Juli durchsehen. Nicht weil bewiesen ist, dass die eigenen Daten im Paket stecken – sondern weil niemand derzeit das Gegenteil belegen kann. Genau das ist der Preis von Accentures Schweigen: Die Beweislast liegt jetzt bei den Kunden.
Die falsche Routine
Es gibt eine Lesart, in der Accenture alles richtig gemacht hat: Vorfall erkannt, Quelle geschlossen, Betrieb läuft. Nach dieser Logik ist der Fall erledigt. Es ist die Logik eines Unternehmens, das seinen Aktienkurs schützt.
Es gibt eine zweite Lesart, und sie ist die relevante: Ein Angreifer bietet Material an, das – falls echt und aktuell – Zugänge zu Entwicklungsumgebungen und Cloud-Ressourcen eines Konzerns öffnet, der für die halbe Weltwirtschaft Systeme baut. Das Unternehmen bestätigt den Vorfall, verweigert aber weitere Auskünfte zu betroffenen Kunden. Nach dieser Logik fängt der Fall gerade erst an.
Accenture hat sich für die erste Lesart entschieden. Die Kunden sollten mit der Zweiten arbeiten.