Das Wichtigste in Kürze
ASOS wurde nicht über eine Software-Lücke angegriffen: Ein einziger gephishter Mitarbeiter-Login öffnete die Tools externer Dienstleister, in denen Kundendaten liegen und über die Kunden angeschrieben werden. Am 8. Oktober 2026 bestätigte der britische Modehändler, dass sich Angreifer als vertrauenswürdiger Kontakt ausgegeben, die Zugangsdaten erbeutet und auf Dienstleister-Plattformen genutzt hatten – zwei Tage nachdem die App eine gefälschte Warnung verschickt hatte.
Kartendaten und Passwörter wurden laut ASOS nicht abgegriffen. Die Schwachstelle lag in der Schicht, von der heute fast jede E-Commerce- und Retail-Plattform abhängt: Marketing-, Personalisierungs- und Messaging-Dienste, die außerhalb des Kernsystems laufen, aber umfangreiche Kundenprofile halten und jedes Smartphone der Nutzer erreichen können.
Wie kamen die Angreifer an die Kundendaten von ASOS?
Laut der Mitteilung von ASOS begann der Angriff mit Social Engineering, nicht mit Schadsoftware. Jemand gab sich als vertrauenswürdiger Kontakt aus und brachte einen Mitarbeiter dazu, den Login für ein Arbeitskonto herauszugeben. Mit diesen Zugangsdaten kamen die Angreifer auf Drittplattformen, die der Händler zur Speicherung von Kundendaten und zur Kommunikation mit Kunden nutzt.
Genau diese zweite Fähigkeit machte den Vorfall öffentlich. Statt Daten still abzuziehen, verschickten die Angreifer über den Messaging-Zugang eine Meldung in der offiziellen ASOS-App – adressiert an den Datenschutzbeauftragten und das IT-Team, mit der Aufforderung, „mit uns in Kontakt zu treten“. Die Kunden erfuhren vom Vorfall also Stunden vor der ersten Stellungnahme des Unternehmens von den Angreifern selbst. Laut Malwarebytes gab die Gruppe ASOS zwei Wochen Zeit, auf eine Zahlungsforderung zu reagieren.
Die Nachricht der Angreifer machte eine kompromittierte Snowflake-Instanz verantwortlich. Snowflake fand nach eigenen Angaben keine Kompromittierung seiner Plattform, und TechCrunch weist darauf hin, dass unklar bleibt, ob das betroffene Konto mit Multi-Faktor-Authentifizierung geschützt war. Das Muster gleicht der Welle von Snowflake-Kundenvorfällen 2024: gültige Zugangsdaten, keine MFA an der entscheidenden Tür und ein Data Warehouse, das jedem bereitwillig Daten lieferte, der sich anmeldete.
Warum sind Personalisierungs- und Messaging-Dienstleister so verwundbar?
Marketing- und Personalisierungstools werden meist außerhalb der Entwicklung eingekauft und verwaltet. Sie bekommen umfangreiche Kundenexporte, damit Modelle Produkte sortieren und Zielgruppen bilden können, und sie bekommen Versandrechte, damit Kampagnen ohne Release rausgehen. Logins werden oft je Dienstleister angelegt statt über das Unternehmens-SSO und deutlich seltener überprüft als Produktionszugänge.
Das Ergebnis ist eine zweite Kundendatenbank mit schwächeren Schlössern. Im Fall ASOS enthalten die gemeldeten Daten auch Suchanfragen der Kunden – genau der Kontext, den ein Phisher für eine überzeugende Folgenachricht braucht. Die Übernahme von Simon AI durch Monetate im Juli zeigt ein weiteres typisches Risiko: Bei Integrationen nach Firmenübernahmen können sich Kontoinhaberschaft und Zugriffsregeln ändern, ohne dass der Kunde es bemerkt.
Was das für Software-Teams in den USA und der EU bedeutet
Erstens: Dienstleister-Konsolen wie Produktion behandeln. Jedes Drittanbieter-Tool, das Kundendaten hält oder Kunden anschreiben kann, gehört hinter Ihren Identity Provider – mit phishing-resistenter MFA (Passkeys oder Hardware-Schlüssel), Conditional Access und automatischem Deprovisioning. Ein Passwort, das irgendwo in dieser Kette allein funktioniert, ist genau die Lücke, die dieser Angriff genutzt hat.
Zweitens: „Daten lesen“ und „an alle Nutzer senden“ trennen. Massenversand per Push, SMS und E-Mail ist eine Fähigkeit mit hoher Tragweite. Verlangen Sie für Sendungen an die gesamte Zielgruppe eine zweite Freigabe, begrenzen Sie das Volumen pro Nutzer und Stunde und lösen Sie Alarme bei Kampagnen aus, die außerhalb üblicher Arbeitsmuster angelegt werden. Mobile-Teams sollten zudem prüfen, dass ihre Push-Provider-Schlüssel nicht zwischen Tools geteilt werden.
Drittens: Nur das herausgeben, was nötig ist. Personalisierungsdienste brauchen selten vollständige Namen, Wohnadressen und rohe Suchhistorie zusammen. Pseudonyme IDs und eng begrenzte, ablaufende Datenfreigaben verringern, was ein einziger gestohlener Login preisgeben kann. Für Geschäfte in der EU und im Vereinigten Königreich ist das zugleich gelebte Datenminimierung nach DSGVO – und eine meldepflichtige Datenpanne muss innerhalb von 72 Stunden, nachdem das Unternehmen davon Kenntnis erlangt hat, bei der Aufsichtsbehörde eingehen.
Was bedeutet der Fall für Onlinehändler im DACH-Raum?
Der Fall trifft ein Muster, das im deutschsprachigen Onlinehandel weit verbreitet ist: Newsletter-, Personalisierungs-, CDP- und Push-Tools werden häufig vom Marketing oder von Agenturen eingeführt, mit eigenen Logins statt Firmen-SSO, und tauchen in keiner Architekturübersicht der IT auf. Für mittelständische Shops und Marken mit eigener App ist das Risiko nicht kleiner als bei ASOS – nur bekommt es weniger Aufmerksamkeit. Eine gefälschte Push-Meldung an die eigene Kundschaft wäre für einen Händler, der vom Vertrauen in seine Marke lebt, ein Reputationsschaden, der schwerer wiegt als der Datenabfluss selbst.
Rechtlich ist die Hebelwirkung klar: Wer Kundendaten an einen solchen Dienstleister gibt, braucht einen Auftragsverarbeitungsvertrag nach Art. 28 DSGVO und muss dessen technische und organisatorische Maßnahmen prüfen; ein Login ohne MFA ist dort ein schwacher Punkt. Eine Datenpanne ist nach Art. 33 DSGVO binnen 72 Stunden der zuständigen Datenschutzaufsicht zu melden – in Deutschland je nach Sitz der Landesdatenschutzbehörde, in Österreich der Datenschutzbehörde, in der Schweiz gelten zusätzlich die Meldepflichten des revidierten DSG gegenüber dem EDÖB. Praktisch heißt das: Dienstleisterliste aus Buchhaltung und SSO-Logs abgleichen, Zugänge mit Versandrechten priorisieren und den Melde-Ablauf vorab üben.
Was sollten Teams diese Woche prüfen?
- Jedes SaaS-Tool mit Kundendaten oder Versandrechten auflisten. Dazu gehören Personalisierung, CDP, CRM, Push, E-Mail und Support-Plattformen – jeweils mit dem Verantwortlichen für das Admin-Konto.
- Einzel-Logins abschaffen. Jedes Tool hinter SSO mit phishing-resistenter MFA stellen oder, wo SSO fehlt, per IP- und Netzwerkrichtlinie einschränken.
- Massenversand absichern. Freigabeschritte und Volumenlimits für app-weite Push-, SMS- und E-Mail-Sendungen einführen und das Security-Team bei ungewöhnlichen Kampagnen alarmieren.
- Datenfreigaben ausdünnen. Die an jeden Dienstleister exportierten Felder prüfen und alles entfernen, was der Anwendungsfall nicht braucht – vor allem Adressen und rohe Suchhistorie.
- Die erste Stunde proben. Kundenmitteilung, einen selbst kontrollierten In-App-Kanal und eine Checkliste für die Meldung an die Aufsichtsbehörde vorbereiten, bevor Sie sie brauchen.
Häufige Fragen
Was ist beim ASOS-Datenleck passiert?
Am 6. Oktober 2026 erhielten ASOS-App-Nutzer von Angreifern eine Push-Benachrichtigung, das Unternehmen sei gehackt worden. Am 8. Oktober bestätigte ASOS, dass sich jemand als vertrauenswürdiger Kontakt ausgegeben, den Login eines Mitarbeiters erlangt und damit auf bestimmte vom Händler genutzte Drittplattformen zugegriffen hatte. Dabei wurden Namen, Kontaktdaten und einige kontobezogene Informationen abgegriffen.
Wurden Zahlungskartendaten oder Passwörter gestohlen?
ASOS zufolge wurden weder Zahlungskartendaten noch Kontopasswörter abgerufen, und Website und App waren durchgehend sicher nutzbar. Berichten über eine der BBC vorliegende Datenstichprobe zufolge enthalten die gestohlenen Datensätze Wohnadressen, Telefonnummern, E-Mail-Adressen und Suchanfragen auf der Website.
Wurde Snowflake gehackt?
Dafür gibt es keine Belege. Die Angreifer behaupteten, eine bei Snowflake gehostete Instanz kompromittiert zu haben, doch Snowflake fand keine Kompromittierung seiner Plattform. Der Zugriff erfolgte über einen gestohlenen Mitarbeiter-Login auf Drittplattformen, nicht über eine Schwachstelle in Snowflake.
Welche Rolle spielt Simon AI?
Die Angreifer gaben an, über Simon AI an die Daten gelangt zu sein – eine auf Snowflake aufbauende Personalisierungsplattform, die ASOS nutzt. Monetate hat Simon AI im Juli 2026 übernommen. Zum Zeitpunkt der Berichterstattung hatte sich keines der beiden Unternehmen öffentlich dazu geäußert; die Verbindung zum Dienstleister bleibt daher eine Behauptung der Angreifer.
Was sollten Onlinehändler und SaaS-Anbieter jetzt tun?
Jede Dienstleister-Konsole mit Kundendaten oder Versandrechten hinter Firmen-SSO mit phishing-resistenter MFA stellen, Einzel-Logins entfernen, die an Marketing- und Personalisierungstools übermittelten Kundendaten minimieren, Push- und E-Mail-Kampagnen mit Freigaben und Volumenlimits absichern und die Krisenkommunikation üben, damit Kunden zuerst vom eigenen Unternehmen hören.
Quellen
TechCrunch — Asos confirms breach of customer data after hackers send rogue app notification
Bloomberg — Hackers tricked Asos employee to steal work account login
Bloomberg — Asos shares slump after app users receive hack notification
The Record — ASOS: Hackers tricked way into employee account before sending rogue push notification
Malwarebytes — ASOS breach update: hackers stole customer details and shopping searches