Social Engineering am Helpdesk und MFA-Reset in Okta

TL;DR. Der Angreifer ruft als Opfer beim Servicedesk an und verlangt ein Zurücksetzen von Passwort oder MFA. Im System Log ist das ein user.mfa.factor.reset_all, user.mfa.factor.deactivate oder user.account.reset_password, dessen Akteur nicht das Ziel ist, gefolgt innerhalb weniger Stunden von einem user.mfa.factor.activate für das Ziel, meist aus einem Netz, das dieser Benutzer nie verwendet hat. Zurücksetzen plus neuer Faktor verdient einen Blick; Zurücksetzen plus neuer Faktor aus einer neuen ASN, von einem Hosting-Anbieter oder einem Proxy ist ein Vorfall. Ist das Opfer Administrator, gehen Sie davon aus, dass als Nächstes Rechtemissbrauch und ein bösartiger Identity Provider folgen.

Warum das so gut funktioniert

Starke MFA schützt die Anmeldung, nicht den Wiederherstellungsprozess drumherum. Wenn ein Anrufer überzeugend behauptet, ein Mitarbeiter mit verlorenem Telefon zu sein, tut ein hilfsbereiter Helpdesk-Mitarbeiter, was der Prozess erlaubt: Er setzt die Faktoren zurück, damit der „Mitarbeiter“ ein neues Gerät registrieren kann. Der Angreifer registriert dann sein Gerät und besitzt das Konto, samt MFA.

Das ist nicht hypothetisch. 2023 berichtete Okta Security von Angreifern, die IT-Servicedesks anriefen, um alle MFA-Faktoren hochprivilegierter Benutzer zurücksetzen zu lassen, und diese Konten dann nutzten, um Super-Administrator-Zugriff zu übernehmen (Okta Security: Cross-Tenant Impersonation). Die Warnung von CISA und FBI zu Scattered Spider beschreibt, wie sich die Gruppe bei Anrufen an Helpdesks als Beschäftigte und IT-Personal ausgab (CISA AA23-320A). MITRE ATT&CK deckt die Bausteine als T1656 Impersonation, T1098.005 Device Registration und T1556.006 Multi-Factor Authentication ab.

Die Abfolge im System Log

Für sich genommen sind die Schritte 2 und 3 nicht von legitimem Support zu unterscheiden: Faktor-Zurücksetzungen sind Routine. Die Schritte 4 und 5 verraten den Angriff, genauer gesagt woher sie kommen.

Ein weiteres Indiz: Der echte Benutzer merkt es meist später, wenn sein Passwort nicht mehr funktioniert. Einige fehlgeschlagene user.session.start mit INVALID_CREDENTIALS aus dem üblichen Netz des Benutzers, Stunden nach dem Zurücksetzen, sind das Opfer, das sich anzumelden versucht.

Wie der Analyzer es erkennt

Der Okta-Forensics-Analyzer hat für dieses Muster zwei Regeln:

Die niedrige Regel sorgt dafür, dass die Zeitleiste immer zeigt, wer wen zurückgesetzt hat; allein ändert sie das Urteil nicht. Das erledigt die Sequenzregel. „Nie zuvor verwendet“ wird aus dem Export selbst berechnet, deshalb macht ein längerer Export (Wochen vor dem Zurücksetzen) die Hochstufung zuverlässiger. Siehe Grenzen und Feinabstimmung.

Angriff und Support-Arbeit unterscheiden

Beantworten Sie für jeden Treffer vier Fragen:

1. Gibt es ein Ticket? Ein echtes Zurücksetzen hat ein Ticket, eine Anrufer-ID und einen Mitarbeiter, der sich an den Anruf erinnert. Fragen Sie, wie die Identität geprüft wurde.
2. Woher kam die Registrierung? Prüfen Sie client.ipAddress, securityContext.asOrg und client.userAgent.rawUserAgent beim user.mfa.factor.activate. Vergleichen Sie mit den Anmeldungen des Benutzers in den Wochen davor. Ein VPS-Anbieter, ein Land, aus dem der Benutzer nie gearbeitet hat, oder ein Linux-Desktop bei jemandem, der immer einen verwalteten Windows-Laptop nutzt, ist eindeutig.
3. Was hat das Konto danach getan? SSO-Ziele, Zugriff auf die Admin Console, Admin-Aktionen. Ein normaler Benutzer, der Mail und HR-App öffnet, beruhigt. Ein Admin, der sofort Rollen vergibt, nicht.
4. Bestätigt es der Benutzer? Rufen Sie ihn unter einer Nummer aus dem HR-System an, nicht unter der, die der Anrufer genannt hat.

Wenn das Opfer Administrator ist

Behandeln Sie es bis zum Beweis des Gegenteils als Kompromittierung des Tenants. Pivotieren Sie ab der Registrierung auf das Opfer als Akteur und suchen Sie nach:

• user.account.privilege.grant / group.privilege.grant, vor allem Super Administrator (Super Administrator);
• system.api_token.create;
• system.idp.lifecycle.create und Änderungen an Routing-Regeln;
• Änderungen an Richtlinien, Authenticators und Netzwerkzonen.

Das Durchspielen des fiktiven Vorfalls zeigt genau diese Kette: ein Helpdesk-Zurücksetzen für eine IT-Administratorin, eine Registrierung von einem VPS, dann eine Super-Administrator-Vergabe und ein neuer Identity Provider.

Eindämmung

1. Beenden Sie die Sitzungen des Opfers; widerrufen Sie Tokens.
2. Entfernen Sie den Faktor des Angreifers; setzen Sie Passwort und Faktoren zurück; registrieren Sie den echten Benutzer persönlich oder über einen stark verifizierten Kanal neu.
3. Prüfen Sie jede Admin-Zuweisung, jedes Token und jeden Identity Provider, die nach dem Zurücksetzen angelegt wurden.
4. Untersuchen Sie die in der Sitzung des Angreifers geöffneten Anwendungen.

Den Helpdesk härten

Oktas Empfehlungen nach der Kampagne von 2023 umfassen, die Befugnisse des Helpdesk-Personals einzuschränken und die Identitätsprüfung vor Zurücksetzungen zu verschärfen (Okta Security). In der Praxis:

• Eine Prüfung, die ein Anrufer nicht recherchieren kann: Rückruf unter einer Nummer aus dem HR-System, Freigabe durch die Führungskraft oder eine persönliche bzw. Video-Prüfung mit Ausweis. Persönliche Angaben aus sozialen Netzwerken sind keine Prüfung.
• Strengerer Ablauf für Administratoren: niemals ein Zurücksetzen nur per Telefon für Admin-Konten.
• Alarm auf die Abfolge, nicht auf Zurücksetzungen allein: Zurücksetzen durch jemand anderen plus Registrierung aus einem neuen Netz, an jemanden weitergeleitet, der den Benutzer anrufen kann.
• Phishing-resistente Authenticators für Admins, gebunden an verwaltete Geräte, damit ein Zurücksetzen allein dem Angreifer nicht erlaubt, beliebige Geräte zu registrieren.

Weiterführende Links

• Okta Security: Cross-Tenant Impersonation, Prävention und Erkennung
• CISA: Scattered Spider (AA23-320A)
• MFA-Fatigue erkennen, der andere Weg an einem Push vorbei