Was viele über den MGM-Hack falsch verstanden haben

Es wirkte wie eine Szene aus einem Casino-Heist-Film – nur ohne George Clooneys Gelassenheit, die das Chaos etwas abgemildert hätte.

Zahlreiche Systeme in den MGM-Casinos fielen aus: von Spielautomaten über Hotel-Schlüsselkarten bis hin zu Rolltreppen. Gäste konnten ihre Zimmer nicht mehr betreten, während Hotelangestellte improvisieren mussten – Essensbestellungen wurden mit Stift und Papier aufgenommen und Glücksspielgewinne aus einer Bauchtasche ausgezahlt. Ein Gast sagte: „Ich habe gefragt, wie lange das dauern wird. Sie meinten: Es könnte ein Tag sein – oder drei Wochen.“

Quelle

MGM Resorts, Betreiber einiger der bekanntesten Hotels und Casinos am Las Vegas Strip, war Opfer eines Cyberangriffs geworden. Und was in Vegas passiert, blieb diesmal nicht in Vegas: Alle MGM-Resorts-Hotels und Casinos waren betroffen. Systeme in weit entfernten Bundesstaaten wie New York, Ohio und Michigan fielen durch dieselbe Sicherheitsverletzung aus.

Ein Angriff, der mit einem einfachen Vishing-Anruf – also Phishing über das Telefon – beim IT-Helpdesk begann, entwickelte sich zu einem der bekanntesten Ransomware-Angriffe des Jahres 2023. Cybersecurity-Journalisten prognostizierten sofort, dass der MGM-Hack künftig in einem Atemzug mit großen Datenpannen wie den Uber- oder Marriott-Leaks genannt werden würde.

Bei einer so spektakulären Geschichte – mit spektakulären Aktionen sowohl der Angreifer als auch der Betroffenen – ist es schwer zu erkennen, worauf man sich konzentrieren sollte. Wenn man jedoch hinter das Glitzerlicht von Las Vegas blickt, wird klar: Der MGM-Hack ist kein Einzelfall. Vielmehr steht er im Zentrum mehrerer aktueller Entwicklungen in der Cybersicherheit.

Zum einen verschaffen sich Angreifer immer häufiger Zugang zu Unternehmensnetzwerken über Helpdesk-Anrufe. Dabei werden sie immer raffinierter. Es wäre jedoch zu einfach, IT-Mitarbeitende dafür verantwortlich zu machen. Stattdessen sollten wir die Sicherheitslücken betrachten, die solche Social-Engineering-Angriffe überhaupt erst ermöglichen.

Wie der MGM-Hack ablief

Wie bei fast jedem großen Cyberangriff wird vermutlich nie vollständig bekannt werden, was genau bei MGM passiert ist. Das Unternehmen hat ein starkes Interesse daran, viele Details geheim zu halten – so sehr, dass es sogar gegen eine Untersuchung der US-Behörde FTC klagte.

Selbst die verfügbaren Berichte enthalten widersprüchliche Informationen über die beteiligten Gruppen und Methoden. Zusätzlich verwirrend ist, dass der Casino-Konzern Caesars ungefähr zur gleichen Zeit einen ähnlichen Angriff erlebte – möglicherweise jedoch durch andere Hacker.

Um zu verstehen, was passiert ist, lohnt sich ein Blick auf bekannte Fakten und ungeklärte Aspekte des Angriffs.

Ein Teil der Informationen stammt aus Berichten von Medien wie dem Wall Street Journal. Weitere Details gehen auf eine Erklärung zurück, die mutmaßliche Mitglieder der Ransomware-Gruppe ALPHV (auch BlackCat genannt) veröffentlichten. Darin übernahmen sie die Verantwortung für den Angriff und beschrieben ihre Vorgehensweise.

Natürlich müssen solche Aussagen mit Vorsicht betrachtet werden: Cyberkriminelle haben ein Interesse daran, ihre Aktivitäten zu verschleiern oder zu übertreiben. Dennoch liefert die Beschreibung eine plausible Darstellung, wie der Angriff technisch ablief.

Teil 1: Der Vishing-Anruf

Der Angriff auf MGM begann, als Social Engineers beim IT-Helpdesk des Unternehmens anriefen.

Das Wall Street Journal berichtete dazu: „Die Person am Telefon sagte, sie sei ein Mitarbeiter, habe aber ihr Passwort vergessen … Sie gab einige persönliche Informationen am Telefon an. Alles schien zu stimmen.“

Doch was genau mit „einigen persönlichen Informationen“ gemeint war, zeigt ein Bericht von Bloomberg: MGM verließ sich bei Passwort-Resets offenbar weitgehend auf ein Vertrauenssystem.

„Ein ehemaliger MGM-Mitarbeiter, der mit den Cybersicherheitsrichtlinien des Unternehmens vertraut war, sagte, dass Angestellte für einen Passwort-Reset lediglich grundlegende persönliche Informationen angeben mussten – ihren Namen, ihre Mitarbeiter-ID und ihr Geburtsdatum. Details, die für eine kriminelle Hackergruppe relativ leicht zu beschaffen sind.“ - Andrew Martin, Ryan Gallagher, und Katrina Manson – Bloomberg, Sep 15, 2023

Das Wall Street Journal berichtete weiter: „Ein paar Minuten später erhielt der echte MGM-Mitarbeiter eine Benachrichtigung, dass sein Passwort zurückgesetzt worden war, und meldete dies der IT-Abteilung. Doch da war es bereits zu spät.“

Teil 2: MGM versucht, die Angreifer auszusperren

Der ursprüngliche Vishing-Angriff fand an einem Freitag statt. Berichte unterscheiden sich darüber, wann MGM die Kompromittierung bemerkte – vermutlich spätestens am Samstagabend.

Erst am Sonntag reagierte das Unternehmen.

Zunächst schaltete MGM seine Okta-Synchronisationsserver ab, die die Verbindung zwischen Okta- und Azure-Systemen herstellen. Doch zu diesem Zeitpunkt hatten die Angreifer laut eigenen Aussagen bereits Administratorrechte in beiden Systemen.

Um die Eindringlinge auszusperren, begann MGM schließlich, Teile der eigenen IT-Infrastruktur abzuschalten – was wiederum zu massiven Störungen im Betrieb führte.

Die Hacker setzen Ransomware ein

Nach Angaben der Gruppe ALPHV wurde zunächst keine Ransomware eingesetzt. In ihrer Stellungnahme behaupten die Angreifer, dass MGM zunächst selbst Teile der eigenen IT-Infrastruktur abgeschaltet habe, nachdem der Angriff entdeckt worden war. Erst als keine Kommunikation mit dem Unternehmen zustande kam, hätten die Hacker Ransomware eingesetzt und mehr als 100 ESXi-Hypervisoren in der MGM-Umgebung verschlüsselt.

Ob diese Darstellung vollständig korrekt ist, lässt sich nicht unabhängig bestätigen. Unbestritten ist jedoch, dass MGM sich entschied, kein Lösegeld zu zahlen. Der Casino-Konkurrent Caesars traf bei einem ähnlichen Angriff wenige Tage zuvor eine andere Entscheidung und zahlte Berichten zufolge rund 15 Millionen US-Dollar, um zu verhindern, dass Kundendaten veröffentlicht werden.

In ihrer Erklärung behauptet ALPHV außerdem, MGM habe das Lösegeld nicht aus Prinzip verweigert, sondern aus wirtschaftlichen Motiven. Die Gruppe deutet an, dass Insiderhandel dafür gesorgt habe, dass Führungskräfte keine finanziellen Verluste befürchten mussten. Ob an dieser Behauptung etwas dran ist, müssen Finanz- und Wirtschaftsjournalisten bewerten. Klar ist jedoch: Die Angriffe auf MGM und Caesars haben die Debatte darüber neu entfacht, ob Unternehmen bei Ransomware-Attacken Lösegeld zahlen sollten oder nicht.

Auswirkungen des MGM-Cyberangriffs

Nach rund zehn Tagen mit anhaltenden Systemausfällen erklärte MGM, dass „alle unsere Hotels und Casinos wieder normal arbeiten“. Diese Aussage steht jedoch im Widerspruch zu einer späteren Meldung an die Aufsichtsbehörden: Dort gab das Unternehmen etwa 25 Tage nach dem ursprünglichen Angriff zu, dass einige kundenbezogene Systeme noch immer wiederhergestellt wurden.

Drei Wochen nach dem Vorfall erklärte MGM-CEO Bill Hornbuckle, der Angriff liege inzwischen „vollständig hinter uns“.

Für viele Kunden galt das jedoch nicht. MGM bestätigte später, dass bei dem Angriff auch personenbezogene Daten entwendet wurden. Dazu gehörten unter anderem:

• Namen

• Führerscheinnummern

• Geburtsdaten

• sowie bei einer kleineren Zahl von Kunden auch Sozialversicherungs- und Passnummern

Das Unternehmen bot den betroffenen Personen anschließend Kreditüberwachung und Schutz vor Identitätsdiebstahl an.

Auch Mitarbeitende könnten von dem Angriff betroffen gewesen sein. Ein Blogger aus Nevada berichtete, dass ein MGM-Angestellter ihm mitgeteilt habe, die Angreifer hätten Zugriff auf interne Personalunterlagen erhalten – darunter Sozialversicherungsnummern und Bankinformationen.

Finanziell rechnet MGM mit rund 100 Millionen US-Dollar Umsatzverlust infolge des Vorfalls. Ein Großteil dieses Schadens soll jedoch durch Cyber-Versicherungen abgedeckt werden. Angesichts des Angriffs scherzte Hornbuckle später bei einer Branchenveranstaltung, er könne sich gut vorstellen, wie hoch die Versicherungsrechnung im kommenden Jahr ausfallen werde – und kritisierte zugleich den „dramatischen“ Anstieg der Cyber-Versicherungskosten.

Scattered Spider und ALPHV

Um den Angriff auf MGM – und den ähnlichen Vorfall bei Caesars – besser zu verstehen, lohnt sich ein kurzer Blick auf die Gruppen, die dahinter vermutet werden. Diese Akteure tragen erheblich zur aktuellen Welle von Angriffen auf IT-Helpdesks bei.

In manchen Berichten heißt es, ein „zehnminütiger Telefonanruf“ habe ausgereicht, um MGM lahmzulegen. Diese Darstellung unterschätzt jedoch deutlich, wie komplex der Angriff tatsächlich war. In Wirklichkeit handelte es sich um eine Kombination aus Social Engineering und Ransomware, die sich als äußerst wirksam erwies.

Eine der Gruppen, die häufig für den MGM-Hack verantwortlich gemacht wird, ist Scattered Spider. Die Bedrohungsakteure sind auch unter anderen Namen bekannt oder werden mit ihnen in Verbindung gebracht, darunter Scattered Swine, Oktapus oder Octo Tempest. Die Gruppe gilt als sehr aktiv und flexibel und besteht überwiegend aus englischsprachigen Mitgliedern. Besonders bekannt ist sie für ihre Fähigkeiten im Social Engineering sowie bei SIM-Swapping-Angriffen.

Neben Scattered Spider wird auch die Gruppe ALPHV, auch bekannt als BlackCat, mit dem Angriff in Verbindung gebracht. Dabei handelt es sich um eine bekannte osteuropäische Ransomware-Organisation, die weltweit bereits Hunderte Unternehmen ins Visier genommen hat – darunter auch Plattformen wie Reddit. Ihre Ransomware-as-a-Service-Software (RaaS) gehört laut IBM zu den am häufigsten eingesetzten Ransomware-Varianten.

Die beiden Gruppen verfügen über sehr unterschiedliche Fähigkeiten. Genau deshalb bereitet die Möglichkeit einer Zusammenarbeit vielen Sicherheitsexperten Sorgen.

Microsoft berichtete 2023 über eine Reihe von Angriffen, bei denen Hacker zunächst über ausgefeilte Social-Engineering-Methoden Zugang zu einem Netzwerk erhalten. Anschließend sichern sie sich dauerhaft Zugriff und nutzen schließlich sogar Sicherheitswerkzeuge ihrer Opfer – etwa EDR- oder MDM-Systeme –, um Ransomware im Netzwerk zu verbreiten.

Microsoft vermutet, dass diese neue Angriffsmethode aus einer Zusammenarbeit zwischen Mitgliedern von Scattered Spider und ALPHV entstanden sein könnte. Laut Reuters bezeichnet sich eine Gruppe von Angreifern, die an den Casino-Angriffen beteiligt gewesen sein soll, selbst als „Star Fraud“ – ein seltenes Beispiel dafür, dass Hacker tatsächlich einen eigenen Namen verwenden.

Trotz der Festnahme eines britischen Jugendlichen, der mit dem Angriff in Verbindung gebracht wird, ist über die Struktur der Gruppe noch immer wenig bekannt. Sicher ist jedoch, dass die Angreifer weiterhin neue Ziele ins Visier nehmen.

Unabhängig davon, ob und wie eng die Gruppen zusammenarbeiten, bleibt die Einschätzung vieler Experten dieselbe. Wie der Journalist Joseph Cox von 404 Media es formuliert: „Diese ungewöhnlichen Partner bilden gemeinsam ein äußerst wirkungsvolles kriminelles Team.“

Das wachsende Muster von Helpdesk-Angriffen

Einer der belastendsten Aspekte der Casino-Angriffe ist, dass die betroffenen Unternehmen im Vorfeld gewarnt worden waren. Kurz vor dem Angriff auf MGM berichtete Okta von „einem beständigen Muster von Social-Engineering-Angriffen auf Mitarbeitende von IT-Service-Desks“.

Und tatsächlich steckt genau diese Art von Angriff hinter einer ganzen Reihe jüngerer, öffentlich stark beachteter Sicherheitsvorfälle:

• Caesars bestätigte, dass der Angriff auf das Unternehmen mit seinem externen IT-Helpdesk begann. Danach eskalierte der Vorfall zu einem Ransomware-Angriff – und zu einer Zahlung von 15 Millionen US-Dollar.

• Der Quellcode-Leak bei Electronic Arts im Jahr 2021 entstand, als Angreifer „das Konto eines bereits eingeloggten EA-Mitarbeiters imitierten … und anschließend einen EA-IT-Support-Mitarbeiter dazu brachten, ihnen Zugriff auf das interne Unternehmensnetzwerk zu gewähren.“

• Es wird außerdem vermutet, dass auch der jüngste Clorox-Hack – ein Vorfall, den nicht einmal Bleichmittel bereinigen konnten – mit Social Engineering begann und möglicherweise von derselben Gruppe durchgeführt wurde, die auch MGM angegriffen hat.

IT-Service-Desks sind ein besonders naheliegendes Ziel für Social-Engineering-Angriffe. Die Natur ihrer Arbeit bedeutet schließlich, dass sie über außergewöhnlich weitreichenden Zugriff und erhebliche Befugnisse verfügen.

Vor allem aber halten sie die Schlüssel zur Authentifizierung in der Hand: Mehr als 40 % aller Helpdesk-Tickets hängen mit Passwort-Zurücksetzungen zusammen. Und obwohl allgemein anerkannt ist, dass Passwörter unsicher sind – was umso mehr für den Einsatz eines Enterprise Password Managers spricht – kann die IT Angreifern auch dabei helfen, stärkere Authentifizierungsverfahren zu umgehen. Okta beobachtete, dass Angreifer IT-Mitarbeitende dazu aufforderten, für die Konten, die sie kompromittieren wollten, „alle Multi-Faktor-Authentifizierungsfaktoren (MFA) zurückzusetzen“.

Wenn man solche Geschichten hört, liegt die Frage nahe, warum die IT-Mitarbeitenden nicht misstrauischer waren. Doch Vishing-Angriffe können äußerst überzeugend sein. In einem riesigen Unternehmen kennt die Person am Helpdesk schließlich nicht jede andere Person im Unternehmen persönlich. Hinzu kommt, dass IT-Helpdesks oft unter erheblichem Druck stehen, Probleme schnell zu lösen. Sie haben nicht immer den Luxus, sich besonders viel Zeit zu nehmen, wenn jemand anruft und Hilfe verlangt.

Das eigentliche Problem reicht daher weit über Helpdesk-Mitarbeitende hinaus, die einfach nur ihre Arbeit machen. Das Urteil einer einzelnen Person sollte niemals die einzige Sicherheitsbarriere sein. Und wenn es darum geht, solche Angriffe zu verhindern, sichern Unternehmen oft die falschen Schwachstellen ab.

Die gängige Sichtweise zur Verhinderung von Phishing-Angriffen

Viele Beobachter machen mangelhafte Verfahren zur Identitätsprüfung für den MGM-Hack verantwortlich. Im Fall von MGM ist diese Kritik durchaus nachvollziehbar, denn offenbar bestand die einzige Verifizierung aus Informationen, die sich leicht durch Phishing beschaffen lassen.

Um zu verstehen, wie ein sichererer Prozess aussehen kann, haben wir mit einem Ingenieur eines externen IT-Helpdesk-Dienstleisters gesprochen.

„Bei allem, was Passwort-Resets, Berechtigungsänderungen oder Zugriff auf sensible Daten betrifft, verlangen wir eine Verifizierung. Ich habe eine Integration mit DUO entwickelt, sodass wir eine Duo-Push-Verifizierung verwenden können, wenn der Nutzer diese eingerichtet hat. Wenn nicht, greifen wir auf SMS zurück (in unseren Kontaktdaten sind bei allen Nutzern Mobilnummern hinterlegt). Wenn auch das nicht möglich ist, wenden wir uns in der Regel an den zuständigen Ansprechpartner im Unternehmen, bitten ihn, den Nutzer zu kontaktieren, und lassen uns anschließend bestätigen, dass alles korrekt ist. Außerdem dokumentieren wir im Ticket, wie wir die Identität des Nutzers überprüft haben.“ - Ryan W, Security Automation Engineer

Das ist sicherlich besser, aber noch weit von perfekt entfernt. Der Prozess greift letztlich wieder auf SMS zurück („davon kommen wir einfach nicht weg“, beklagt Ryan), und SMS ist anfällig für SIM-Swapping und andere Man-in-the-Middle-Angriffe (MITM). Beides sind bekannte Taktiken der Angreifer, die auch MGM angegriffen haben.

Okta und Microsoft empfehlen eine ganze Reihe von Maßnahmen, um Mitarbeiteridentitäten zuverlässiger zu überprüfen. Dazu gehören unter anderem:

1. Multi-Faktor-Authentifizierung implementieren. Das ist eine sinnvolle Empfehlung, auch wenn sie heute eher als Grundvoraussetzung für eine sichere Organisation gilt. Wenn möglich, sollten schwache Faktoren wie Sicherheitsfragen oder SMS nicht aktiviert werden.

2. Passwortlose Authentifizierung prüfen. Passwörter gehören zu den unsichersten Authentifizierungsmethoden und gelten zunehmend als Auslaufmodell. Selbst wenn sie sich nicht sofort im gesamten Unternehmen abschaffen lassen, sollten zumindest Super-Administratoren sicherere Methoden wie biometrische Verfahren oder einen YubiKey verwenden.

3. Die Zahl der Super-Administratoren begrenzen. Microsoft empfiehlt außerdem, „die Anzahl der Nutzer mit dauerhaft zugewiesenen kritischen Rollen zu reduzieren“. Berechtigungen kontinuierlich zu überprüfen und nach dem Prinzip des Least Privilege zu vergeben, ist nicht einfach – aber ein zentraler Bestandteil von Zero-Trust-Sicherheit.

4. Stärkere Authentifizierung für besonders sensible Daten verwenden. Okta empfiehlt beispielsweise, dass „privilegierte Anwendungen“ bei jeder Anmeldung eine erneute Authentifizierung verlangen sollten.

Es überrascht daher nicht, dass sich viele dieser Empfehlungen auf Benutzeridentität und Authentifizierung konzentrieren. Der Zugriff auf Super-Administrator-Konten sollte selbstverständlich mehr erfordern, als nur das Geburtsdatum einer Person zu kennen.

Dennoch wurden zahlreiche Unternehmen Opfer solcher Angriffe – darunter auch Organisationen, die bereits strengere Sicherheitsmaßnahmen wie MFA eingesetzt haben.

Wie Paul Martini auf DarkReading schrieb:

„Viele Analysten haben sich auf die Vorstellung fixiert, dass MGM den Vorfall hätte verhindern können, wenn das Unternehmen bessere Identitätslösungen oder stärkere Methoden zur Verifizierung von Benutzeridentitäten eingesetzt hätte … die Realität ist jedoch, dass Identitätsprodukte allein diesen Angriff nicht verhindert hätten.“ - Paul Martini - DarkReading, Nov 07, 2023

Auch unsere eigene Lösung 1Password Extended Access Management schützt Benutzeridentitäten, etwa durch passwortlose Authentifizierung und Einblicke in App-Zugriffe. Doch die Diskussion rund um den MGM-Hack ist Teil einer langen Tradition in der IT-Sicherheit: Fachleute konzentrieren sich stark auf die Identität des Nutzers – und übersehen dabei eine andere entscheidende Perspektive: das Gerät des Nutzers.

Wie Device Trust Phishing verhindern kann

Es ist offensichtlich, dass Angreifer sehr gut darin sind, sich als Mitarbeitende auszugeben – sie nutzen deren Namen, persönliche Informationen und sogar ihre Stimmen. Doch eines können sie nicht ohne Weiteres imitieren: das Gerät des Mitarbeiters. Genau hier setzt Device Trust an.

Device Trust basiert auf der Idee, dass das Gerät eines Nutzers bekannt sein und sich in einem sicheren Zustand befinden muss, bevor es auf sensible Unternehmensressourcen zugreifen darf.

Schauen wir uns diese Definition genauer an. Device Trust ist auch ein zentraler Bestandteil von 1Password Extended Access Management, daher verwenden wir unsere eigene Lösung als Beispiel:

• „Bekannt“ bedeutet, dass ein Gerät registriert wird, wenn der 1Password Extended Access Management Agent installiert wird. Während dieser Registrierung richtet der Agent eine geheime und eindeutige Methode ein, um das Gerät bei jeder Anmeldung zu identifizieren. Entscheidend ist, dass diese Kennung nicht fälschbar ist – Angreifer können sie weder durch Phishing stehlen noch imitieren. (Eine technisch detailliertere Erklärung dazu finden Sie in unserer Dokumentation.)

• „In einem sicheren Zustand“ bedeutet, dass das Gerät die Sicherheitsanforderungen des Unternehmens erfüllt. Dazu kann beispielsweise gehören, dass das Gerät im MDM-System des Unternehmens registriert ist, eine Endpoint-Detection-and-Response-Lösung (EDR) installiert hat oder weitere Sicherheitsrichtlinien erfüllt. Die Device-Trust-Lösung von 1Password Extended Access Management ermöglicht es Administratoren, aus einer Bibliothek von über 100 Richtlinienprüfungen zu wählen, anhand derer bestimmt wird, ob ein Gerät als sicher gilt.

• „Zugriff auf sensible Unternehmensressourcen“ wird gesteuert, indem 1Password Extended Access Management in den Authentifizierungsprozess integriert wird. Wenn ein Gerät den Agent nicht installiert hat oder die Sicherheitsprüfungen nicht besteht, kann es sich nicht authentifizieren.

Hätte MGM 1Password Extended Access Management eingesetzt, hätte der Angriff möglicherweise so ausgesehen:

1. Die Angreifer rufen beim IT-Helpdesk an und erreichen einen Passwort- oder MFA-Reset. (Bis hierhin läuft der Angriff noch erfolgreich.)

2. Wenn sie anschließend versuchen, sich mit dem kompromittierten Konto anzumelden, werden sie gestoppt. Ihr Gerät hat keinen 1Password Extended Access Management Agent installiert und kann daher nicht authentifizieren.

3. Die Angreifer versuchen, den Agent zu installieren. Doch ohne Zustimmung der IT kann ihr Gerät nicht registriert werden.

4. Selbst wenn es ihnen gelingen würde, den Agent zu installieren, müssten sie anschließend zahlreiche Compliance-Prüfungen bestehen. Dieser Prozess wäre zeitaufwendig – und jede zusätzliche Minute erhöht die Wahrscheinlichkeit, dass jemand (vermutlich der impersonierte Mitarbeiter) die verdächtigen Aktivitäten bemerkt.

Sowohl Microsoft als auch Okta erwähnen Device Trust in ihren Empfehlungen zur Verhinderung von Angriffen wie dem MGM-Hack – allerdings nur am Rande.

Microsoft nennt zwei gerätebezogene Maßnahmen:

• „Registrierung für MFA nur von vertrauenswürdigen Standorten aus erlauben und nur von Geräten, die den organisatorischen Anforderungen entsprechen.“

• „Kürzlich registrierte Geräteidentitäten überprüfen.“

Okta widmet dem Thema lediglich einen Satz:

• „Benachrichtigungen für neue Geräte und verdächtige Aktivitäten für Endnutzer aktivieren und testen.“

Das sind Schritte in die richtige Richtung – doch sie gehen nicht weit genug. Sie reagieren auf Angriffe, anstatt sie von vornherein zu verhindern.

Beispielsweise kann es für Organisationen mit verteilten oder vollständig remote arbeitenden Teams schwierig sein, eine zuverlässige Liste „vertrauenswürdiger Standorte“ zu pflegen. Zudem nutzen Angreifer häufig VPNs, um ihren tatsächlichen Standort zu verschleiern.

Benachrichtigungen an Endnutzer – etwa bei neuen Geräten oder kompromittierten Passwörtern – können hilfreich sein. Doch wenn jemand seine E-Mails prüft, kann es bereits zu spät sein. Und wenn ein Unternehmen bereits registrierte Geräte überprüft, ist es definitiv zu spät.

Einfach gesagt: Ein unbekanntes Gerät sollte sich gar nicht erst authentifizieren können.

 Quelle

Dass Microsoft und Okta Device Trust nur beiläufig unter einer Vielzahl von Empfehlungen zur Benutzerverifikation erwähnen, zeigt, wie stark dieser Aspekt der Sicherheit bislang unterschätzt wird. Device Trust ist weit mehr als eine hilfreiche Ergänzung oder eine Randnotiz, die man „auch erwähnen sollte“. Es ist ein zentraler Bestandteil moderner Multi-Faktor-Authentifizierung.

Und genau dieser Faktor hätte viele der Angriffe verhindern können, über die wir gesprochen haben – einschließlich des Angriffs auf MGM.

Extended Access Management als nächste Sicherheitsstufe

Bühnenmagier und Social Engineers nutzen dieselbe grundlegende Technik: Ablenkung.

Sie wollen, dass das Publikum oder ihre Opfer auf das flauschige weiße Kaninchen oder den „dringenden Anruf“ eines hochrangigen Mitarbeiters schauen – auf alles, nur nicht auf ihren eigentlichen Trick.

Im Fall des MGM-Hacks konzentrierte sich die Aufmerksamkeit vor allem auf den Telefonanruf und den überforderten Helpdesk-Mitarbeiter. Doch die eigentliche Geschichte handelt von einem Unternehmen, das seiner eigenen IT-Abteilung nicht die nötigen Werkzeuge gegeben hatte, um einen Angreifer zu erkennen – oder den Schaden zu begrenzen, sobald dieser einmal im System war.

Schwache Identitätsprüfung ist nicht der Kern jedes Social-Engineering-Angriffs. Wenn man den Blick von den Schlagzeilen löst, erkennt man, dass oft etwas Offensichtliches übersehen wird – das Gerät, auf dem Sie diesen Artikel gerade lesen.

Möchten Sie erfahren, wie Device Trust Ihr Team vor Phishing-Angriffen schützen kann? Vereinbaren Sie eine Demo.