Acht Monate nach dem Angriff bleibt der Einbruch bei Red Hat eines der lehrreichsten Sicherheitsereignisse der jüngeren Zeit. Am 1. Oktober 2025 meldete sich eine bis dahin kaum bekannte Erpressergruppe namens Crimson Collective und behauptete, eine interne GitLab-Instanz des weltgrößten Anbieters von Open-Source-Unternehmenssoftware geplündert zu haben. Die Zahlen, die sie nannte, waren gewaltig: rund 570 Gigabyte komprimierte Daten aus über 28.000 Repositories, darunter etwa 800 sogenannte Customer Engagement Reports. Red Hat bestätigte den Vorfall einen Tag später. Für IT-Sicherheitsverantwortliche in Deutschland, Österreich und der Schweiz ist dieser Fall mehr als eine US-Schlagzeile. Er zeigt, wie verwundbar die Berater- und Lieferketten hinter kritischer Infrastruktur sind.

Diese Analyse ordnet den Red-Hat-Vorfall ein: Was bestätigt ist, was nur behauptet wird, welche DACH-Unternehmen betroffen sein könnten und warum der Diebstahl von Beratungsdaten ein systemisches Risiko für die Software-Lieferkette darstellt. Das Red Hat Datenleck markiert einen Wendepunkt in einer Welle von Quellcode- und Datendiebstahl-Erpressungen, die 2025 und 2026 die Branche prägt.

Was beim Red Hat Datenleck genau geschah

Am 1. Oktober 2025 veröffentlichte Crimson Collective auf einem Leak-Kanal die Behauptung, in ein GitLab-System von Red Hat eingedrungen zu sein. Einen Tag später, am 2. Oktober 2025, bestätigte Red Hat in einer offiziellen Sicherheitsmitteilung den Vorfall. Betroffen war nach Angaben des Unternehmens keine öffentliche, kundenseitige Plattform, sondern eine interne GitLab-Instanz, die das Beratungsteam Red Hat Consulting für ausgewählte Projekte nutzte.

Der Unterschied ist entscheidend. GitLab-Instanzen für Beratungsprojekte enthalten selten fertige Produkte. Sie enthalten etwas Sensibleres: Aufzeichnungen darüber, wie die Systeme der Kunden tatsächlich aufgebaut sind. Genau diese Aufzeichnungen, die Customer Engagement Reports, standen im Zentrum des Diebstahls. Red Hat erkannte den unbefugten Zugriff, entzog der Gegenseite den Zugang, isolierte die Instanz und schaltete Behörden ein. Die Untersuchung lief zum Zeitpunkt der ersten Mitteilung noch.

Red Hat formulierte vorsichtig. Das Unternehmen sprach von einem unbefugten Dritten, der Daten aus dieser Instanz abgerufen und kopiert habe. Eine konkrete Datenmenge oder Zahl betroffener Repositories nannte Red Hat in seiner Mitteilung nicht. Alle großen Mengenangaben, die seither kursieren, stammen von den Angreifern selbst.

Die Zahlen hinter dem Angriff

Crimson Collective bezifferte die Beute auf rund 570 Gigabyte komprimierte Daten aus mehr als 28.000 internen Repositories. Dazu kamen nach Darstellung der Gruppe etwa 800 Customer Engagement Reports. Komprimiert bedeutet, dass die entpackte Datenmenge deutlich größer ausfallen dürfte. Bei textlastigen Quellcode- und Konfigurationsdaten sind Kompressionsraten von fünf zu eins oder mehr üblich, was auf mehrere Terabyte Rohdaten hindeutet.

Die folgende Tabelle fasst die zentralen Kennzahlen zusammen und trennt strikt zwischen bestätigten Fakten und Angreiferangaben. Diese Trennung ist die wichtigste Lesehilfe für den gesamten Fall.

KennzahlWertStatus
Bekanntgabe durch Angreifer1. Oktober 2025Crimson Collective
Bestätigung durch Red Hat2. Oktober 2025Red Hat offiziell
Betroffenes SystemInterne GitLab-Instanz (Red Hat Consulting)Red Hat bestätigt
Komprimierte Datenmengerund 570 GBAngreiferangabe
Repositoriesüber 28.000Angreiferangabe
Customer Engagement Reportsrund 800Angreiferangabe
Inhalt der CERsInfrastruktur, Konfigurationen, Tokensberichtet, nicht von Red Hat beziffert
Auswirkung auf Software-Lieferkettekeine festgestelltRed Hat-Einschätzung

Konservativ gelesen steht damit nur eines zweifelsfrei fest: Ein interner Speicher mit Beratungsdaten wurde kompromittiert. Die genaue Dimension bleibt eine Behauptung der Täter, die Red Hat weder bestätigt noch widerlegt hat.

Warum Customer Engagement Reports so brisant sind

Ein Customer Engagement Report ist die schriftliche Bilanz eines Beratungsprojekts. Wenn Red Hat Consulting einem Kunden hilft, eine OpenShift-Plattform, eine Kubernetes-Umgebung oder eine Linux-Flotte aufzubauen, dokumentieren die Berater Architektur, Netzwerktopologie, Konfigurationsentscheidungen und oft auch Zugangsdaten. Genau diese Berichte sollen sich nach Darstellung der Angreifer unter der Beute befunden haben.

Für einen Angreifer ist ein solches Dokument eine Landkarte. Es verrät, wo die wertvollen Systeme stehen, welche Authentifizierungstoken gültig sind und welche Schwachstellen in der Konfiguration lauern. Wer eine CER besitzt, muss das Zielnetz nicht erst mühsam auskundschaften. Er kennt es bereits, mitunter besser als die internen Mitarbeiter des Kunden.

Damit verschiebt sich das Risiko vom Hersteller zum Kunden. Selbst wenn Red Hats eigene Produkte unberührt bleiben, könnten Hunderte Kundenorganisationen plötzlich detaillierte Beschreibungen ihrer eigenen Infrastruktur in den Händen einer Erpressergruppe wissen. Das ist die eigentliche Sprengkraft des Vorfalls.

Wer ist die Crimson Collective?

Crimson Collective tauchte 2025 als Erpressergruppe auf, die auf Datendiebstahl statt auf klassische Verschlüsselung setzt. Das Muster folgt einem Trend, der sich seit zwei Jahren durchsetzt: Statt Systeme lahmzulegen, stehlen Angreifer große Datenmengen und drohen mit Veröffentlichung. Diese Taktik heißt Double Extortion ohne den Verschlüsselungsteil, oft auch reine Daten-Erpressung.

Die Gruppe veröffentlichte Verzeichnislisten und Stichproben der angeblich gestohlenen Daten, um Druck aufzubauen. Diese Methode ist kalkuliert. Ein öffentliches Leck signalisiert anderen Opfern, dass die Drohung echt ist, und erhöht die Zahlungsbereitschaft. Über Größe, Standort oder Mitgliederzahl von Crimson Collective gibt es keine bestätigten Angaben. Die Gruppe definiert sich über ihre Taten, nicht über eine Marke wie frühere Ransomware-Kartelle.

Die mögliche Verbindung zu Scattered Lapsus$ Hunters

Sicherheitsforscher berichteten, dass Crimson Collective offenbar mit dem lockeren Bündnis Scattered Lapsus$ Hunters kooperiert, einem Zusammenschluss aus Akteuren im Umfeld von ShinyHunters, Scattered Spider und Lapsus$. Eine formale Fusion oder eine behördliche Bestätigung dieser Verbindung gibt es nicht. Es handelt sich um eine Einschätzung aus der Forschungsgemeinschaft, nicht um eine erwiesene Tatsache.

Bedeutsam ist die mögliche Verbindung trotzdem. ShinyHunters gehört zu den produktivsten Datendieben der Gegenwart. Tauchen neue Gruppen im selben Umfeld auf, deutet das auf ein arbeitsteiliges Ökosystem hin, in dem Zugänge gekauft, Daten weitergereicht und Erpressungen gemeinsam orchestriert werden. Für Verteidiger bedeutet das: Ein einzelner Einbruch ist selten ein isoliertes Ereignis, sondern Teil einer Kampagne.

Red Hats offizielle Reaktion im Wortlaut

Red Hat veröffentlichte am 2. Oktober 2025 eine Stellungnahme, die in der Branche viel beachtet wurde. Die folgenden Aussagen sind Übersetzungen aus der offiziellen englischsprachigen Sicherheitsmitteilung des Unternehmens.

“Wir haben kürzlich unbefugten Zugriff auf eine GitLab-Instanz festgestellt, die für die interne Zusammenarbeit von Red Hat Consulting in ausgewählten Projekten genutzt wird.”

Red Hat, offizielle Sicherheitsmitteilung, 2. Oktober 2025

Zur Frage der Lieferkette, die für Anwender von Red Hat Enterprise Linux und OpenShift weltweit zentral ist, äußerte sich das Unternehmen ebenfalls deutlich.

“Wir haben derzeit keinen Grund zu der Annahme, dass dieses Sicherheitsproblem andere Red-Hat-Dienste oder -Produkte betrifft, einschließlich unserer Software-Lieferkette oder des Bezugs von Red-Hat-Software über offizielle Kanäle.”

Red Hat, offizielle Sicherheitsmitteilung, 2. Oktober 2025

Red Hat differenzierte außerdem zwischen Beratungskunden und übrigen Anwendern. Wer kein Red-Hat-Consulting-Kunde sei, für den gebe es derzeit keinen Hinweis auf eine Betroffenheit, erklärte das Unternehmen. Für Beratungskunden laufe die Analyse weiter. Diese Abgrenzung ist juristisch sauber, beruhigt die breite Anwenderbasis und konzentriert das Risiko auf einen klar umrissenen Kreis.

Welche Kunden betroffen sein sollen

In den von Crimson Collective veröffentlichten Verzeichnislisten und in der anschließenden Berichterstattung tauchten zahlreiche prominente Organisationen auf. Wichtig: Red Hat hat keine Kundenliste bestätigt. Die folgenden Namen stammen aus den Leak-Stichproben und aus Sekundärberichten von Sicherheitsmedien, nicht aus einer offiziellen Quelle. Sie sind als gemeldete Beispiele zu verstehen, nicht als gesicherter Nachweis eines Datenabflusses.

Genannt wurden unter anderem große Finanzinstitute wie Bank of America, HSBC, Citigroup, American Express und PNC Bank. Aus dem DACH-Raum und Europa erschienen in einzelnen Listen Namen wie Commerzbank, Credit Suisse, ING Bank und Vodafone. Hinzu kamen Beispiele aus Handel, Luftfahrt, Gesundheitswesen und öffentlichem Sektor. Da diese Aufstellungen aus Sekundärquellen stammen, sollte jede einzelne Nennung mit Vorsicht behandelt werden, bis die betroffenen Organisationen selbst Stellung beziehen.

Für DACH-Sicherheitsteams ergibt sich daraus eine klare Handlungsempfehlung: Wer in den vergangenen Jahren Red-Hat-Consulting-Leistungen bezogen hat, sollte unabhängig von Listengerüchten davon ausgehen, dass Beratungsdokumentation kompromittiert sein könnte, Zugangsdaten rotieren und Konfigurationen überprüfen.

Warum der Vorfall ein Lieferkettenrisiko ist

Der klassische Lieferkettenangriff manipuliert ein Software-Update, um Tausende Kunden gleichzeitig zu infizieren. Der Red-Hat-Fall funktioniert anders, ist aber verwandt. Statt Schadcode auszuliefern, wurde Wissen abgeschöpft. Der Hersteller selbst bleibt sauber, doch die bei ihm gelagerten Kundendaten werden zur Waffe gegen die Kunden.

Dieses Muster ist schwer zu verteidigen, weil es eine Vertrauensbeziehung ausnutzt. Unternehmen geben Beratern bewusst tiefe Einblicke, damit diese überhaupt helfen können. Jede Beratungsfirma, jeder Managed-Service-Provider und jeder Systemintegrator wird damit zum potenziellen Single Point of Failure für seine gesamte Kundenbasis. Der Angriff auf einen Dienstleister ersetzt Hunderte Einzelangriffe.

Die ENISA, die Cybersicherheitsagentur der EU, weist in ihrem Threat Landscape 2025 seit Längerem darauf hin, dass Lieferketten- und Drittparteienrisiken zu den prägenden Bedrohungen für europäische Organisationen zählen. Der Red-Hat-Vorfall ist die praktische Illustration dieser Warnung.

Markt- und Reputationsfolgen für Red Hat und IBM

Red Hat gehört seit 2019 zu IBM und ist eine der wichtigsten Wachstumssäulen des Konzerns. Ein Sicherheitsvorfall trifft hier nicht nur die Marke, sondern ein Geschäftsmodell, das vollständig auf Vertrauen beruht. Open-Source-Unternehmenssoftware verkauft sich über die Zusicherung von Stabilität, Auditierbarkeit und Lieferketten-Integrität. Genau diese Zusicherung stellte Red Hat in seiner Mitteilung in den Mittelpunkt, indem es betonte, dass die Software-Lieferkette unberührt sei.

Die Schadensbegrenzung war erkennbar darauf ausgerichtet, die Produktbasis zu schützen und den Vorfall auf das Beratungsgeschäft einzugrenzen. Diese Strategie ist nachvollziehbar, verlagert die Last aber auf die betroffenen Beratungskunden. Für den Markt sendet der Fall ein unbequemes Signal: Selbst ein Anbieter mit erstklassiger Sicherheitskultur kann über die weiche Flanke des Beratungsgeschäfts getroffen werden. Wettbewerber wie SUSE oder Canonical dürften daraus weniger Häme als Wachsamkeit ziehen, denn dasselbe Risiko gilt für jeden Dienstleister mit privilegiertem Kundenzugang.

Historischer Kontext: die Welle der Quellcode-Erpressung

Der Red-Hat-Fall steht nicht allein. Er reiht sich in eine Serie von Vorfällen ein, bei denen Angreifer nicht Endkunden-Datenbanken, sondern die Entwicklungs- und Beratungsinfrastruktur großer Anbieter ins Visier nahmen. Die folgende Tabelle stellt den Red-Hat-Vorfall den Behauptungen der Angreifer gegenüber und macht sichtbar, wie weit Anspruch und bestätigte Realität auseinanderliegen.

AspektCrimson Collective behauptetRed Hat bestätigt
Zugriff auf GitLab-Instanzvollständiger Zugriffja, unbefugter Zugriff
Datenmengerund 570 GB komprimiertnicht beziffert
Repositoriesüber 28.000nicht beziffert
Customer Engagement Reportsrund 800nicht beziffert
Betroffene KundenBanken, Telekom, Behördenkeine Liste bestätigt
Software-Lieferkette betroffenimpliziertausdrücklich verneint
Datenkopie erfolgtja, veröffentlichtja, Daten kopiert

Parallel dazu erschütterte 2025 eine breit angelegte Kampagne im Umfeld von ShinyHunters die Branche, bei der über kompromittierte SaaS- und Integrationsplattformen Daten zahlreicher Großkonzerne abgeflossen sein sollen. Die genauen Zahlen dieser Kampagne sind umstritten und teils nicht belastbar bestätigt, weshalb sie hier bewusst nicht beziffert werden. Klar ist die Richtung: Angreifer zielen zunehmend auf die Knotenpunkte, an denen sich Daten vieler Organisationen bündeln.

Was das Red Hat Datenleck für DACH-Unternehmen bedeutet

Für Unternehmen in Deutschland, Österreich und der Schweiz fällt der Vorfall in eine Phase verschärfter regulatorischer Anforderungen. Die EU-Richtlinie NIS2 verpflichtet Betreiber wesentlicher und wichtiger Einrichtungen zu striktem Risikomanagement in der Lieferkette und zu kurzen Meldefristen bei Sicherheitsvorfällen. Wer Beratungsdienstleister einsetzt, muss deren Sicherheitsniveau künftig nachweisbar bewerten.

Hinzu kommt der Cyber Resilience Act, der Hersteller digitaler Produkte zu Sicherheitsstandards und Meldepflichten verpflichtet. Ein Vorfall wie bei Red Hat verdeutlicht, dass diese Pflichten nicht an der Werkstür enden. Die Sicherheit der Beratungs- und Dokumentationsdaten gehört genauso dazu wie die Integrität des ausgelieferten Codes.

Konkret sollten DACH-Sicherheitsteams drei Dinge tun: erstens alle Beratungs- und Dienstleisterbeziehungen inventarisieren, in denen Dritte Zugriff auf Infrastrukturdokumentation hatten. Zweitens Zugangsdaten und Tokens rotieren, die in solchen Projekten verwendet wurden. Drittens vertragliche Sicherheitszusagen und Meldepflichten der Dienstleister überprüfen, damit ein Vorfall beim Partner nicht zur eigenen Compliance-Lücke wird.

Einordnung durch Behörden und Forschung

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) beschreibt die Bedrohungslage in Deutschland seit Jahren als angespannt. In seinem Lagebericht 2024 dokumentierte das BSI durchschnittlich rund 309.000 neue Schadprogramm-Varianten pro Tag und bezeichnete die Lage der IT-Sicherheit als besorgniserregend. Ransomware und Datenerpressung gelten dem Amt als gravierendste Bedrohungen für Wirtschaft und Verwaltung.

Auf europäischer Ebene ordnet die ENISA in ihrem Threat Landscape 2025 Deutschland als eines der am stärksten von Ransomware und Datendiebstahl betroffenen Mitgliedsländer ein. Die Agentur betont, dass datengetriebene Erpressung ohne Verschlüsselung an Bedeutung gewinnt, exakt das Muster, das Crimson Collective bei Red Hat anwandte. Sicherheitsforscher von Anbietern wie Google Threat Intelligence und Mandiant verfolgen das Umfeld von ShinyHunters und verbündeten Gruppen seit Längerem und warnen vor einer zunehmenden Professionalisierung der Daten-Erpressung.

Die Botschaft dieser Stellen ist konsistent: Der Schwerpunkt der Bedrohung verschiebt sich von der Verschlüsselung einzelner Systeme zur Erpressung mit gestohlenen Daten. Der Red-Hat-Vorfall ist ein Musterbeispiel dieser Verschiebung.

Fünf Prognosen für die kommenden Monate

Aus dem Verlauf des Vorfalls und der Marktreaktion lassen sich mehrere Entwicklungen ableiten. Diese Prognosen sind analytische Einschätzungen, keine bestätigten Fakten.

  • Beratungsdaten werden zum eigenen Schutzgut. Anbieter und Dienstleister werden CER-ähnliche Dokumentation verschlüsseln, segmentieren und mit kurzen Aufbewahrungsfristen versehen, statt sie unbegrenzt vorzuhalten.
  • Lieferketten-Audits werden zur Pflichtübung. Getrieben durch NIS2 werden DACH-Unternehmen Sicherheitsnachweise von Beratern und Integratoren vertraglich einfordern, ähnlich wie heute Datenschutzvereinbarungen.
  • Daten-Erpressung verdrängt klassische Verschlüsselung weiter. Reine Datendiebstahl-Erpressung ist schneller und schwerer zu verteidigen, weshalb mehr Gruppen diesem Modell folgen werden.
  • Token-Hygiene wird zur Kernkennzahl. Da in CERs und Repositories oft langlebige Zugangstoken stecken, werden kurzlebige Credentials und automatische Rotation zum Standard in Beratungsprojekten.
  • Weitere Anbieter mit Beratungsarm geraten ins Visier. Das erfolgreiche Muster wird Nachahmer finden, große Integratoren und Cloud-Beratungen werden zu bevorzugten Zielen.

Wie sich Organisationen jetzt schützen

Die wirksamste Verteidigung gegen Vorfälle wie das Red Hat Datenleck setzt nicht erst beim Einbruch an, sondern bei der Datenhaltung davor. Wer weniger sensible Dokumentation vorhält und Zugänge konsequent kurzlebig hält, verkleinert die Beute, die ein Angreifer überhaupt erbeuten kann.

  • Zugangsdaten und API-Tokens niemals im Klartext in Repositories oder Berichten speichern, sondern in dedizierten Secret-Management-Systemen.
  • Beratungs- und Projektdaten nach Abschluss konsequent löschen oder archivieren, nicht dauerhaft in aktiven Systemen belassen.
  • Mehr-Faktor-Authentifizierung für jeden Zugang zu Entwicklungs- und Kollaborationsplattformen erzwingen.
  • Lieferanten und Dienstleister vertraglich zu Sicherheitsstandards und Meldefristen verpflichten.
  • Nach einem bekannt gewordenen Dienstleister-Vorfall alle in gemeinsamen Projekten genutzten Tokens umgehend rotieren.

Diese Maßnahmen verhindern keinen entschlossenen Angreifer vollständig. Sie reduzieren aber den Wert eines erfolgreichen Einbruchs drastisch und verkürzen das Zeitfenster, in dem gestohlene Daten missbraucht werden können.

Häufig gestellte Fragen zum Red Hat Datenleck

Wann fand das Red Hat Datenleck statt?

Die Erpressergruppe Crimson Collective machte den Einbruch am 1. Oktober 2025 öffentlich. Red Hat bestätigte den Vorfall am 2. Oktober 2025 in einer offiziellen Sicherheitsmitteilung.

Wie viele Daten wurden gestohlen?

Die Angreifer behaupten, rund 570 Gigabyte komprimierte Daten aus über 28.000 Repositories sowie etwa 800 Customer Engagement Reports erbeutet zu haben. Red Hat hat diese Mengenangaben nicht bestätigt und keine eigenen Zahlen genannt.

Ist die Software-Lieferkette von Red Hat betroffen?

Nach Angaben von Red Hat nicht. Das Unternehmen erklärte, es gebe keinen Grund zu der Annahme, dass andere Produkte oder Dienste betroffen seien, einschließlich der Software-Lieferkette und des offiziellen Software-Bezugs.

Welche Daten enthalten Customer Engagement Reports?

CERs dokumentieren Beratungsprojekte und können Infrastrukturdetails, Konfigurationsdaten und Authentifizierungstoken von Kunden enthalten. Genau das macht sie für Angreifer so wertvoll, weil sie als Landkarte fremder Netzwerke dienen.

Sind deutsche oder DACH-Unternehmen betroffen?

In Leak-Listen und Sekundärberichten tauchten europäische Namen wie Commerzbank, Credit Suisse, ING Bank und Vodafone auf. Diese Nennungen sind nicht von Red Hat bestätigt und sollten als gemeldete Beispiele behandelt werden, nicht als gesicherter Nachweis.

Was sollten Red-Hat-Consulting-Kunden jetzt tun?

Betroffene Beratungskunden sollten in gemeinsamen Projekten genutzte Zugangsdaten und Tokens rotieren, Konfigurationen überprüfen und die offiziellen Hinweise von Red Hat verfolgen. Vorsorglich gilt das auch ohne Bestätigung einer konkreten Betroffenheit.

Wer steckt hinter dem Angriff?

Verantwortlich zeichnet die Erpressergruppe Crimson Collective. Sicherheitsforscher sehen mögliche Verbindungen zum Umfeld von Scattered Lapsus$ Hunters und ShinyHunters, eine formale oder behördlich bestätigte Verbindung gibt es jedoch nicht.