Ein Bedrohungsakteur, der unter dem Pseudonym 'LAPSUS-GROUP' operiert und tiefe Verbindung auf Affiliate-Ebene zur Scattered Lapsus$ Hunters-Gruppe hat, beansprucht, etwa 815.000 Zeilen Daten vom Adidas Extranet exfiltriert zu haben. Dies ist ein eingeschränktes webgestütztes Portal, das von Geschäftspartnern, Lieferanten und lizenzierten Distributoren genutzt wird. Der Vorfall hat Kunden-PII offengelegt, darunter Vor- und Nachnamen, E-Mail-Adressen, Passwörter, Geburtsdaten, Unternehmensinformationen sowie ein erhebliches Volumen technischer Daten.

Adidas hat die Kompromittierung bestätigt, fügte jedoch hinzu, dass sie nicht aus der eigenen Kern-IT-Infrastruktur stammt. Stattdessen wurde die Verletzung mit einem unabhängigen Lizenzpartner und spezifischen Produkthersteller verbunden. Diese Entität ist ein Drittanbieter, der seine eigenen IT-Systeme betreibt und einen gewissen Zugriff auf das partnerorientierte Portal von Adidas hat.

Adidas hat in der Vergangenheit ähnliche Sicherheitsverletzungen erlebt. Im Mai 2025 führte ein unbefugter Zugriff auf einen Drittanbieter-Kundendienstanbieter zum Leck von Kontaktdaten von Adidas-Kunden. Die anhaltenden Herausforderungen, mit denen Unternehmen durch Dritte konfrontiert sind, werden zunehmend zu einem Anliegen, wie wir es bereits bei den Einbruch bei Nissan Red Hat und beim Vorfall bei Korean Air gesehen haben. 

Bevor wir weitermachen, vergessen Sie nicht, unseren vorherigen Blogbeitrag zu lesen: „die CIRCIA-Town-Halls könnten ein Wendepunkt für kritische Infrastrukturen sein“ hier.

Wie kam es zu dem Vorfall? Rekonstruktion des Angriffswegs

Das Extranet als Angriffsziel

Ein Extranet ist per Design eine kontrollierte Erweiterung des internen Netzwerks eines Unternehmens, das ausschließlich ausgewählten externen Parteien zugänglich ist. Im Fall von Adidas erhielten lizenzierte Partner, Lieferanten und Distributoren bedarfsbasierten Zugang zu diesem Portal. Diese Portale sind betrieblich notwendig, um eine tiefere Zusammenarbeit sicherzustellen. Lieferanten müssen beispielsweise auf Produktkataloge, Bestellsysteme und Logistikdaten zugreifen. Einzelhändler benötigen rechtzeitige Bestandsfeeds. Lizenznehmer benötigen Design-Assets und Compliance-Dokumentationen. Das Problem ist, je mehr Zugangspunkte Sie externen Parteien anbieten, desto mehr Angriffsfläche entsteht. Diese Fläche ist nur so stark wie ihr schwächster Teilnehmer (oder deren Sicherheitspraktiken).

Die angebliche Sicherheitsverletzung betraf nicht das verbraucherorientierte E-Commerce-Plattform von Adidas oder einen Teil seiner zentralen IT-Umgebung. Stattdessen war der Einstiegspunkt des Angreifers eine IT-Umgebung eines Drittanbieters mit Lizenz, die privilegierten Zugang zum Adidas-Extranet erhalten hatte. Dies ist ein Paradebeispiel eines Angriffsvektors in der Lieferkette. Jedoch nicht durch eine Software-Schwachstelle im traditionellen Sinne gesehen, sondern durch Vertrauensmissbrauch. Der Angreifer musste nicht direkt in Adidas eindringen. Stattdessen musste er nur jemanden kompromittieren, der bereits die Schlüssel hatte und die Schlüssel von ihm nehmen.

Das Lapsus$-Vorgehen verstehen: Social Engineering statt Ausnutzung von Schwachstellen

Die Gruppe hinter diesem Vorfall, die mit dem breiteren Lapsus$-Ansatz in Verbindung steht, hat eine gut dokumentierte Erfolgsbilanz, bei der sie in der Vergangenheit Social Engineering und Anmeldeinformationen-Diebstahl bevorzugte. Diese Gruppe betrachtet Social Engineering als eine bevorzugte Abkürzung gegenüber technischen Zero-Day-Exploits. Lapsus$ historische Kampagnen, einschließlich der Einbrüche bei Microsoft, Okta, Nvidia, Samsung und Uber, haben einen gemeinsamen Faden.  Sie zielen oft auf Menschen und Prozesse und nicht auf Code-Schwachstellen.

Der Lapsus$-Ansatz umfasst normalerweise mindestens eine oder mehrere der folgenden Taktiken: SIM-Swapping, um mobile Authentifizierung zu kapern, das Kaufen oder Phishing von Anmeldeinformationen von Insidern und externen Auftragnehmern, das Anwerben von Mitarbeitern innerhalb der Zielorganisationen für direkten Zugriff, das Ausspielen von MFA-Müdigkeit durch wiederholte Push-Benachrichtigungen, bis ein Benutzer versehentlich genehmigt, und das Zugreifen auf schlecht gesicherte interne Portale, bei denen Anmeldedaten-Wiederverwendung von anderen Verstößen Zugang bietet.

Im Adidas-Vorfall ist dies das wahrscheinlichste Szenario (im Einklang mit der Lapsus$-Methodik). Die Anmeldeinformationen des Drittanbieters für das Adidas Extranet wurden durch einen Social Engineering-Angriff gestohlen und genau diese Anmeldeinformationen wurden verwendet, um auf das Portal zuzugreifen.  

Wo die Governance möglicherweise versagt hat

Wenn einem Drittanbieter ein Zugang zu einem Extranet gewährt wird, werden implizit mehrere Sicherheitsannahmen getroffen. Es wird angenommen, dass der Partner starke Authentifizierung durchsetzt, Zugriffsanmeldeinformationen schützt und diese nicht weitergibt, sicherstellt, dass seine IT-Umgebung einem Mindestmaß an Sicherheitsniveau entspricht und dass der Partner die primäre Organisation über Sicherheitsvorfälle informiert, die ihr System betreffen.

In der überwiegenden Mehrheit von Unternehmenspartnerprogrammen sind solche Annahmen bestenfalls erstrebenswert und schlimmstenfalls eine Übersehen der Realität. Partner unterschreiben häufig Nutzungsrichtlinien, aber sehr wenige Organisationen führen laufend technische Überprüfungen der Sicherheitsstruktur ihrer Partner durch (nicht einmal im Rahmen einer Risikound Sicherheitsbewertung). Ein Lizenzpartner für eine bestimmte Produktlinie ist kein Cybersicherheitsunternehmen und deren IT-Reifegrad, Authentifizierungsrichtlinien und Vorfallreaktionsbereitschaft können weit unter dem liegen, was von Adidas' eigenem Sicherheitsteam intern erwartet würde.  

Was bedeutet der Anspruch von '420GB Französisch-Markt'?

Der Anspruch des Bedrohungsakteurs, ungefähr 420 GB an Daten von Adidas direkt im Zusammenhang mit dem französischen Markt zu besitzen, verdient besondere Aufmerksamkeit. Wenn sich dies als zutreffend erweist, deutet dies darauf hin, dass die Exfiltration kein schneller Raub war. Stattdessen handelte es sich um eine langwierige und gezielte Entnahme. Datenexfiltration dieser Art erfordert typischerweise über einen längeren Zeitraum anhaltenden Zugriff. Dies wiederum legt nahe, dass der Einbruch möglicherweise wochen- oder monatelang unentdeckt in der Umgebung des Drittanbieters blieb, bevor die Verletzung entdeckt wurde. Es wirft auch die Frage auf, ob das Adidas-Extranet angemessene Mechanismen zur Überwachung des Datenabflusses hatte, um anomale Datenübertragungsmuster von Partneraccounts zu erkennen.

Lehren für die Branche: Was uns die Adidas-Panne lehrt

Lektion 1: Drittrisiko ist kein sekundäres Anliegen mehr

Viele etablierte Unternehmen haben Jahrzehnte damit verbracht, Perimeter und einige interne Kontrollen zu verstärken. Doch der Perimeter hat sich mehr oder weniger aufgelöst. Heute liegt das schwächste Glied in einer großen Organisation der Sicherheitskette fast nie innerhalb der Organisation, sondern in der Lieferkette, im Partnerökosystem, im Lieferantennetzwerk. Der Shieldworkz Bedrohungsbericht zeigt immer wieder, dass Verstöße mit Beteiligung Dritter zu den häufigsten und zerstörerischsten gehören. Die aufeinanderfolgenden Zwischenfälle bei Adidas im Jahr 2025 und 2026 sind keine Anomalien. Sie sind stattdessen die Norm für viele Organisationen, die das Management von Drittrisiken noch nicht zur Priorität gemacht haben.

Lektion 2: Extranets sind häufig untergeschützte Hochwertziele

Extranet-Portale aggregieren den Zugriff und Daten für Dutzende oder Hunderte externer Partner. Sie befinden sich an der Grenze zwischen einer vom Unternehmen kontrollierten Umgebung und der weniger vorhersehbaren Sicherheitslage des Partnerökosystems. Dennoch behandeln viele Organisationen Extranets als IT-Komfort statt als sicherheitskritisches System oder sogar als erweiterte Umgebung. Authentifizierungsanforderungen sind oft viel schwächer als bei internen Systemen. Es gibt keinen Einzelfaktor oder ältere MFA, keine Geräte-Haltungsprüfungen, keine anomalen Zugriffskontrollen und unzureichende Protokollierung. Für einen Angreifer kann ein kompromittiertes Partneranmeldedaten für ein Extranet wertvoller sein als ein direkter Einbruch, denn es kommt vorkonfiguriert und vorautorisiert mit geringeren Chancen auf Entdeckung.

Lektion 3: MFA allein ist unzureichend gegen modernes Social Engineering

In vielerlei Hinsicht ist die Effektivität der Lapsus$-Gruppe trotz der weit verbreiteten MFA-Annahme in der Branche ein Weckruf. Auf Push-Benachrichtigungen basierende MFA, SMS-basierte OTP und sogar TOTP-Codes können alle durch Social Engineering besiegt werden. Entweder indem Benutzer dazu verleitet werden, bösartige Push-Anfragen zu genehmigen, indem OTPs per SIM-Swapping abgefangen werden, oder durch Echtzeit-Phishing-Proxy-Server, die Anmeldedaten weiterleiten, wenn das Opfer sie eingibt. Phishing-resistente MFA, die speziell Hardware-Sicherheitsschlüssel (FIDO2/WebAuthn) oder Passkeys umfasst, ist die einzige Form der Authentifizierung, die gegen solche Techniken standhalten kann. Organisationen, die Extranet-Portale mit SMS oder Push-basierter MFA betreiben, sollten solche Portale als aktives Risiko behandeln.

Lektion 4: Datenminimierung ist eine Sicherheitskontrolle, nicht nur eine Compliance-Anforderung

Die angebliche Verletzung hat Geburtstermine, Passwörter, Unternehmensdaten und das, was der Bedrohungsakteur als „beträchtliche technische Daten“ beschrieb, offengelegt. Einige dieser Informationen werfen sofort Fragen zur Notwendigkeit auf. Warum werden Passwörter in einem Format gespeichert, das als lesbare Daten exfiltriert werden kann? Richtig gehashte Passwörter unter Verwendung von bcrypt, Argon2 oder scrypt sollten rechnerisch unmöglich umzukehren sein. Wenn Passwörter in einer nutzbaren Form kompromittiert wurden, deutet dies entweder auf unzureichende Hashing-Praktiken hin oder darauf, dass das, was zugegriffen wurde, ein Anmelde-Puffer war, anstelle eines richtig gesicherten Passwort-Speichers. Darüber hinaus wirft die Präsenz von Geburtstagen in einem Partner-Extranet-Datensatz die Frage auf: War diese Daten notwendig für die Partnerbeziehung oder wurde sie über ihren nützlichen Zweck hinaus behalten?

Lektion 5: Ein Muster von Vorfällen Dritter weist auf eine strukturelle Lücke hin

Ein Verstoß eines Drittanbieters ist ein Vorfall. Zwei Verstöße mit Beteiligung von Drittanbietern innerhalb von neun Monaten sind ein Muster. Der Kompromiss einer Kundenservice-Anbieters im Mai 2025 und der Extranet-Vorfall im Februar 2026 teilen eine strukturelle Grundursache: Die Sicherheitshaltung von Adidas gegenüber Dritten verhinderte keinen der beiden. Dies bedeutet nicht, dass die interne Sicherheit von Adidas schwach ist. Es bedeutet, dass die Sicherheitskontrollen für Drittanbieterbeziehungen nicht ausreichend waren. Die Lektion für andere große Unternehmen ist, dass die Überprüfung der eigenen Sicherheitslage unzureichend ist. Sie müssen die Sicherheitslage aller überprüfen, die Ihre Daten berühren.

Wie man es verhindert: Ein Framework für Praktiker

Drittanbieterrisikomanagement: Vom Papier zur technischen Verifikation übergehen

Die meisten Programme zum Management von Drittanbieterrisiken sind fragebogengestützt. Ein Partner füllt jährlich ein Sicherheitsbewertungsformular aus und das Ergebnis wird abgelegt. Dieser Ansatz ist grundsätzlich unzureichend, da er sich ausschließlich auf Selbstauskunft stützt und ein momentanes Schnappschuss aufnimmt. Die Abhilfe erfordert eine Umstellung auf ein kontinuierliches, evidenzbasiertes Management von Drittanbieterrisiken.

• Erfordern Sie technische Belege, nicht nur die Anerkennung von Richtlinien: Fordern Sie Penetrationstestergebnisse, Schwachstellenscan-Berichte und SOC 2 / ISO 27001-Zertifizierungen an und prüfen Sie diese.

• Klassifizieren Sie Ihre Partner nach Zugriffslevel und Datenempfindlichkeit: Ein Partner mit Extranet-Zugang zu Produktdaten verdient eine höhere Überprüfungsstufe als ein Marketinganbieter. Wenden Sie angemessene Kontrollen an.

• Verwenden Sie Plattformen für Cyber-Risiko-Intelligenz, um die externe Sicherheitslage von Partnern mit erhöhtem Zugriff kontinuierlich zu überwachen. Ein Partner, dessen Domain-Infrastruktur Anzeichen eines Kompromisses zeigt, sollte eine sofortige Überprüfung des Zugriffs auslösen.

• Vertraglich verankern, dass Ereignismeldungen zeitnah erfolgen müssen: Wenn die Systeme eines Partners kompromittiert sind, sollten Sie innerhalb von 24-48 Stunden darüber informiert werden, nicht erst nach Wochen. Machen Sie dies zu einem bindenden vertraglichen Erfordernis mit definierten Konsequenzen bei Nichtoffenlegung.

Stärken Sie das Extranet-Authentifizierungsmodell

Partnerportale sollten keine schwächere Authentifizierung haben als interne Mitarbeiter-Systeme. In vielen Organisationen ist das Gegenteil der Fall. Die folgenden Kontrollen sollten für jedes Extranet unverhandelbar sein, das sensiblen Daten führt:

• Erzwingen Sie FIDO2/WebAuthn-Hardware-Schlüssel oder Passkeys für alle Partnerkonten und nicht SMS OTP, nicht Push-Benachrichtigungen.

• Implementieren Sie Bedingungsgesteuerten Zugriff oder adaptive Authentifizierung: Lehnen Sie Anmeldungen aus unerwarteten geografischen Standorten, unbekannten Geräten oder außerhalb der Geschäftszeiten ohne verstärkte Verifizierung ab.

• Führen Sie Gerätehaltungsprüfungen bei der Anmeldung durch: Partner, die auf sensible Extranet-Funktionen zugreifen, sollten dies nur von verwalteten oder zertifizierten Geräten aus tun, nicht von beliebigen persönlichen Maschinen.

• Erzwingen Sie Sitzungszeitlimits und gleichzeitig parallele Sitzungsbegrenzungen: Eine aktive Sitzung, die stundenlang unbeaufsichtigt bleibt, ist eine offene Tür.

• Implementieren Sie just-in-time-Zugangsbereitstellung (JIT): Der Partnerzugang sollte nur während vereinbarter Betriebszeiten aktiv sein, nicht dauerhaft 24/7.

Instrumentalisieren Sie das Extranet zur Anomalieerkennung

Ein Angreifer, der 815.000 Datenzeilen oder 420 GB von einem Portal exfiltriert, hinterlässt verhaltensbezogene Signaturen. Das Datenübertragungsvolumen, die Timing-, Abfrage- und Zugriffssequenzen, die mit Massenexfiltration verbunden sind, unterscheiden sich erkennbar von normaler Partneraktivität. Dies ist jedoch nur erkennbar, wenn die richtigen Telemetriedaten gesammelt und analysiert werden.

• Protokollieren Sie alle Zugriffereignisse auf der Extranet-Ebene: wer authentifiziert hat, von wo, was sie abgerufen haben, wie viel Daten übertragen wurden und wann.

• Etablieren Sie Verhaltensgrundlinien pro Partnerkonto und lösen Sie Alarmmeldungen bei Abweichungen aus: Ein Distributor, der normal 50 Datensätze am Tag abruft, sollte nicht in der Lage sein, 800.000 unbemerkt abzurufen.

• Integrieren Sie Extranet-Logs in Ihr SIEM und wenden Sie Benutzer- und Entitätsverhaltensanalysen (UEBA) an speziell auf Partnerportal-Missbrauchsmuster abgestimmte Regeln an.

• Tools wie Shieldworkz, die Anomalieerkennung, heuristische Analysen und schnelle Risikoreduzierung bieten, sind hier direkt anwendbar, um die Art plötzlicher, hochvolumiger oder ungewöhnlicher Kommandos zu erkennen, die charakteristisch für Anmeldeinformationen-basierte Massenexfiltration sind.

• Implementieren Sie Data Loss Prevention (DLP)-Kontrollen auf der API- und Datenexportebene: Begrenzen Sie Download-Volumen pro Sitzung, verlangen Sie Begründungen für Massendatenanfragen und begrenzen Sie die Rate.

Das Prinzip des geringstmöglichen Zugriffs anwenden

Jedes Partnerkonto in einem Extranet sollte Zugang zu den minimal notwendigen Daten haben, die für ihre spezifische Geschäftsaufgabe erforderlich sind. Dies klingt offensichtlich, wird aber in der Praxis häufig verletzt, da ein breiter Zugang einfacher zu konfigurieren ist und weniger wahrscheinlich betriebliche Beschwerden hervorruft.

• Ordnen Sie die Geschäftsaufgabe jedes Partners einem spezifischen Datenzugriffsbereich zu und erzwingen Sie dies technisch, nicht nur durch Richtlinien.

• Trennen Sie Lese- und Schreibberechtigungen explizit: Ein Distributor, der den Bestand prüft, sollte nicht auch Zugriff auf Kunden-PII haben.

• Überprüfen Sie die Zugriffsberechtigungen für alle Partnerkonten mindestens vierteljährlich und sofort bei jeder Änderung der Partnerbeziehung.

• Entfernen Sie den Zugriff sofort nach Vertragsablauf, personellen Veränderungen im Partnerunternehmen oder bei jeglichen Anzeichen eines Sicherheitsvorfalls beim Partner.

Lösen Sie das Passwort- und PII-Hygieneproblem

Die gemeldete Exfiltration von Passwörtern in einem Format, das ausnutzbar erscheint, ist ein grundlegendes Sicherheitsversäumnis, das unabhängig von der Ursache des Verstoßes angegangen werden muss.

• Überprüfen Sie alle Anmeldeinformationsspeicher: Stellen Sie sicher, dass Passwörter mit einem modernen adaptiven Algorithmus gehasht werden.  

•  Erzwingen Sie Passwortrichtlinien für Rotation und Einzigartigkeit für alle Partnerkonten.

• Wenden Sie Prinzipien der Datenminimierung auf alle partnerbezogenen Daten an: Wenn ein Feld betrieblich nicht erforderlich ist, sammeln oder bewahren Sie es nicht auf. Die Bekanntgabe von Geburtsdaten in einem B2B-Partnerportal ist ein Warnsignal für unnötige Datensammlung.

• Verschlüsseln Sie sensible Felder ruhezustandsspezifisch, nicht nur auf Datenbankebene, sodass selbst ein Datenbankabzug keine Klartext-Sensibeldaten liefert.

Erstellen Sie ein Einsatzleitfaden für Vorfälle Dritter

Die meisten Organisationen haben Vorfallreaktionspläne für ihre eigene Umgebung. Sehr wenige haben einen getesteten Leitfaden für Vorfälle, die von Dritten ausgehen, welche, wie dieser Fall zeigt, fundamentale Unterschiede in Untersuchung und Reaktion haben. Sie kontrollieren die kompromittierte Umgebung nicht. Sie können keine Forensik auf den Servern Ihres Partners durchführen. Sie sind abhängig von deren Zusammenarbeit und Offenheit.

• Definieren Sie ein Verfahren zur Reaktion auf Sicherheitsvorfälle Dritter: Wer wird intern informiert, wie wird der Partnerzugang ausgesetzt, wie wird das Ausmaß der Datenweitergabe bestimmt und wie werden betroffene Personen benachrichtigt.

• Stellen Sie Kommunikationsprotokolle mit hochriskanten Partnern für Eskalation von Sicherheitsvorfällen im Voraus her.

• Führen Sie Tabletop-Übungen durch, die ein von einem Partner stammendes Einbruchsszenario spezifisch simulieren – nicht nur einen direkten Einbruch.

• Führen Sie ein Partner-Zugriffsregister, das sofort verwendet werden kann, um alle Konten und Berechtigungen aufzulisten, die mit einem kompromittierten Partner verbunden sind.

Die Adidas-Extranetpanne ist keine Geschichte über eine gescheiterte Firewall oder eine unbehandelte Schwachstelle. Es ist eine Geschichte über Vertrauen. Genauer gesagt, die Sicherheitsannahmen, die große Unternehmen über die Partner machen, denen sie Zugang zu ihren Systemen gewähren. In einem hypervernetzten Geschäftsumfeld erstreckt sich Ihre Angriffsfläche auf jeden Dritten, der Ihre Daten, Ihre Portale und Ihre Systeme berührt.

Die Lapsus$-Gruppe und ihre angeschlossenen Kollektive haben wiederholt gezeigt, dass technische Kontrollen allein gegen gut ausgeführtes Social Engineering unzureichend sind. Die Unternehmen, die in dieser Bedrohungslandschaft besser abschneiden werden, sind diejenigen, die rigoroses Drittanbietersicherheitsmanagement, phishing-resistente Authentifizierung, kontinuierliche Verhaltensüberwachung und die organisatorische Demut kombinieren, um zu erkennen, dass ihre Sicherheit nur so stark ist wie der am wenigsten sichere Partner in ihrem Netzwerk.

Für Adidas muss die sofortige Priorität eine umfassende Überprüfung aller Drittzugangsbeziehungen sein und nicht nur das Extranet, sondern jedes partnerorientierte Portal und jede API. Das Muster der Vorfälle erfordert eine strukturelle Reaktion, keine reaktive Lösung.

Sprechen Sie mit Shieldworkz für ein umfassendes Risiko- und Sicherheitsaudit

Herunterladbare Ressourcen

OT-/ICS-Cybersecurity-Betriebssicherheits-Checkliste

Bericht über den Stand der OT-Sicherheit

Strategische Implementierung von ISA/IEC 62443-3-2

Verbesserung der OT-Cybersicherheit und Resilienz für einen führenden Versorgungsanbieter