Über Ostern 2025 brach bei Marks & Spencer das Chaos aus: Kartenzahlungen funktionierten nicht mehr, Click & Collect fiel aus, und ab dem 25. April ging online gar nichts mehr. 46 Tage lang konnte man bei einem der grössten britischen Einzelhändler nichts im Internet bestellen, und am Ende stand ein Schaden von rund 300 Millionen Pfund an entgangenem Gewinn. Die Angreifer waren dabei keine staatliche Hackereinheit, sondern eine Gruppe junger Leute zwischen 17 und 20 Jahren.
Der Anruf
Der Angriff auf M&S begann nicht mit einem Exploit und nicht mit einer Zero-Day Schwachstelle, sondern mit einem Telefonanruf. Irgendwann im Februar 2025 rief jemand beim IT Helpdesk an, der von Tata Consultancy Services (TCS) betrieben wird, und gab sich als M&S Mitarbeiter aus. Der Anrufer war überzeugend genug um ein Passwort-Reset für einen bestehenden Account zu bekommen, und damit hatte die Gruppe Scattered Spider einen Fuss in der Tür.
M&S Chairman Archie Norman hat den Angriffsvektor später öffentlich bestätigt: Social Engineering über den Service Desk, ohne technischen Durchbruch im eigentlichen Sinne, lediglich ein Telefon und eine überzeugende Geschichte.
Was danach passierte zeigt allerdings, dass die Angreifer technisch durchaus wussten was sie taten.
Von einem Passwort zum gesamten Netzwerk
Mit den zurückgesetzten Zugangsdaten konnten sich die Angreifer ins Active Directory einloggen und dort die Datei NTDS.dit stehlen, die sämtliche Passwort-Hashes aller Domain-Benutzer enthält. Wer diese Datei hat, kann die Hashes offline knacken (was bei schwachen Passwörtern in Minuten geht) und verfügt danach über Klartext-Passwörter für potenziell hunderte oder tausende Accounts.
Das ist der Punkt an dem aus einem einzelnen kompromittierten Konto eine vollständige Netzwerkübernahme wird; mit genug geknackten Credentials kann man sich lateral durch das gesamte Netzwerk bewegen, auf Server zugreifen, Berechtigungen eskalieren und am Ende praktisch alles kontrollieren. Die Angreifer haben genau das getan und schliesslich DragonForce Ransomware auf der VMware ESXi Infrastruktur von M&S deployt, wodurch alle Server verschlüsselt wurden.
DragonForce ist ein Ransomware-as-a-Service Anbieter aus Asien, bei dem Affiliates (in diesem Fall Scattered Spider) die Angriffe durchführen und 80 Prozent des Lösegeldes behalten, während DragonForce 20 Prozent kassiert.
Die Folgen
Die Auswirkungen waren erheblich: Online-Bestellungen waren 46 Tage lang nicht möglich (vom 25. April bis zum 10. Juni), in den Filialen mussten Mitarbeiter Bestandsführung und Temperaturüberwachung manuell erledigen weil die Systeme nicht verfügbar waren, und der Gesamtschaden belief sich auf geschätzte 300 Millionen Pfund an entgangenem operativem Gewinn.
Gestohlen wurden Namen, Adressen, E-Mail-Adressen, Telefonnummern, Geburtsdaten und Online-Bestellhistorien der Kunden. Kreditkartendaten und Passwörter wurden laut M&S nicht entwendet.
Am 10. Juli 2025 verhaftete die britische National Crime Agency vier Personen: eine 20-jährige Frau aus Staffordshire, zwei 19-jährige Männer (einen Briten und einen Letten) aus London und den West Midlands, und einen 17-jährigen Briten. Ob M&S Lösegeld bezahlt hat, wollte der Chairman auf Nachfrage nicht bestätigen und nicht dementieren. Der Gesamtschaden des „kombinierten Cyber-Events“ (M&S, Co-op und Harrods wurden im selben Zeitraum von der gleichen Gruppe angegriffen) wird auf 270 bis 440 Milionen Pfund geschätzt.
Angriffsweg und Kontrollen
Was diesen Fall besonders lehrreich macht: jeder einzelne Schritt im Angriff hätte durch eine etablierte Sicherheitskontrolle verhindert werden können, und zwar nicht durch exotische oder teure Technologie, sondern durch Massnahmen die zum Standardrepertoire jeder IT-Sicherheitsabteilung gehören sollten.
Schritt 1: Social Engineering am Helpdesk
Der Angreifer ruft an und gibt sich als Mitarbeiter aus. Eine strikte Identitätsverifikation (z.B Callback an die hinterlegte Nummer, persönliche Sicherheitsfragen, oder Bestätigung durch den Vorgesetzten) hätte den Angriff hier gestoppt. Viele Unternehmen haben solche Prozesse auf dem Papier, aber in der Praxis setzt der Helpdesk sie nicht konsequent um, weil der Druck gross ist, Tickets schnell zu schliessen.
Schritt 2: Passwort Reset
Für privilegierte Konten (oder eigentlich für alle Konten) sollte ein Passwort Reset eine zusätzliche Authentifizierung erfordern: MFA-Bestätigung, Manager-Approval, oder ein separater Verifizierungskanal. Wenn ein einzelner Helpdesk-Mitarbeiter ein Passwort ohne jede Gegenprüfung zurücksetzen kann, handelt es sich um ein systemisches Problem, das unabhängig von der Kompetenz des Mitarbeiters adressiert werden muss.
Schritt 3: Active Directory Zugriff
Privileged Access Management (PAM) Systeme beschränken wer auf das AD zugreifen darf und von welchen Geräten aus. Netzwerksegmentierung stellt sicher dass nicht jedes Konto auf die Domain Controller zugreifen kann. Beides hätte den Zugriff auf die NTDS.dit Datei erschwert oder verhindert.
Schritt 4: NTDS.dit gestohlen
Monitoring von ungewöhnlichen Zugriffen auf die NTDS.dit (z.B. über Volume Shadow Copy oder ntdsutil) ist ein bekannter Detection Use Case. Ein Tiered Admin Modell, bei dem Tier 0 Accounts (Domain Admins) nur auf Tier 0 Systemen verwendet werden, hätte den Blast Radius begrenzt.
Schritt 5: Hash Cracking
Komplexe Passwort-Richtlinien und regelmässige Rotation machen Offline-Cracking schwieriger (aber nicht unmögich). Managed Service Accounts und Group Managed Service Accounts eliminieren das Risiko für Service-Konten komplett.
Schritt 6: Lateral Movement
Zero Trust Architekturen und Mikrosegmentierung begrenzen die Möglichkeit, sich mit gestohlenen Credentials frei im Netzwerk zu bewegen. Wenn jeder Zugriff neu autorisiert werden muss, nützen geknackte Passwörter allein wenig.
Schritt 7: Ransomware Deployment
Endpoint Detection and Response (EDR) auf den ESXi Hosts, isolierte Backups die nicht vom gleichen AD abhängen, und Anwendungs-Whitelisting hätten die Ransomware entweder erkannt oder ihre Auswirkungen auf ein Minimum reduziert.
Schritt 8: Datenexfiltration
Data Loss Prevention (DLP) und Monitoring des ausgehenden Netzwerkverkehrs (Egress Filtering) erkennen wenn grosse Datenmengen das Netzwerk verlassen. In Kombination mit SIEM-Regeln die auf ungewöhnliche Datenübertragungen alertieren, wäre die Exfiltration aufgefallen bevor sie abgeschlossen war.
Fazit
Was an diesem Fall auffällt, ist nicht die technische Raffinesse der Angreifer, denn die war gar nicht besonders hoch, sondern die Einfachheit des Angriffsvektors: ein Anruf, ein Password Reset, und 46 Tage später steht ein 300-Millionen-Schaden. Scattered Spider hat gezeigt dass man kein staatlich finanzierter APT-Akteur sein muss um einen börsennotierten Konzern in die Knie zu zwingen, und dass die grösste Schwachstelle nach wie vor der Mensch ist, oder genauer: die Prozesse die den Menschen keine klaren Leitplanken geben.
Die vier Verhafteten waren zwischen 17 und 20 Jahre alt…
Möchten Sie wissen, ob Ihre Help Desk Prozesse einem Social Engineering Angriff standhalten würden? Kontaktieren Sie uns für ein Social Engineering Assessment.