Verfolgung von Fehlern bei der passwortlosen Anmeldung in Azure

Böswillige Anmeldeversuche zu verfolgen ist nicht einfach

Kürzlich untersuchten wir verdächtiges Verhalten in einer Umgebung, in der die kennwortlose Azure-Authentifizierung eingerichtet war. Auslöser für die Untersuchungen war, dass mehrere Benutzer mit unerwarteten Aufforderungen der Authenticator-App konfrontiert wurden. Glücklicherweise fiel keiner der Benutzer auf den Trick herein oder ließ den Angreifer herein.

Diese Art von Ereignis, bekannt als MFA-Müdigkeit, ist Routine und wird von großen und kleinen Unternehmen erwartet. Angreifer nutzen diese Social-Engineering-Technik, um Benutzer dazu zu verleiten, Aufforderungen zur Push-Authentifizierung zu akzeptieren (was bei den jüngsten Angriffen, einschließlich Uber, erfolgreich war).

Das Szenario erwies sich als besonders schwierig zu untersuchen, da die fehlgeschlagenen passwortlosen Aufforderungen in den Protokollen verzeichnet sind.

Eingeschränkte Protokollierungsmöglichkeiten erschweren Ermittlungen

Das Aufspüren böswilliger Anmeldeversuche ist für den Schutz von cloud Umgebungen von entscheidender Bedeutung und nur durch die Überwachung der verfügbaren cloud Protokolle möglich. Microsoft und andere cloud Anbieter veröffentlichen zwar Protokollschemata und bieten Service-Level-Agreements (SLAs) für die Bereitstellung von Protokollen, aber es gibt immer noch einige Probleme, die cloud Protokolle plagen:

• Die Arten von Aufzeichnungsereignissen sind oft nicht gut dokumentiert und manchmal überhaupt nicht dokumentiert.
• Einige der protokollierten Werte und IDs sind intern beim Anbieter cloud und ihre Bedeutung ist unklar.
• Neue Datensatztypen werden hinzugefügt, Datensatztypen werden aus dem Verkehr gezogen und Datensatzformate werden ohne Vorankündigung für die Verbraucher geändert.

All dies erschwert die Überwachung und Reaktion auf Vorfälle und führt dazu, dass die Benutzer von cloud unsicher sind, ob die Protokollaufzeichnungen vollständig sind, und dass sie unangekündigte Änderungen nachholen müssen - so wird es schwierig, fehlgeschlagene passwortlose Aufforderungen anhand der protokollierten Daten zu untersuchen.

Ein genauerer Blick auf die Aufdeckung und Entschärfung von passwortlosen Anmeldefehlern in Azure

Passwortlose Authentifizierung

Für diejenigen, die damit nicht vertraut sind, ist die kennwortlose Authentifizierung eine robuste Option, um das Risiko zu mindern, dass Benutzer unsichere Kennwörter erstellen. Es gibt mehrere Möglichkeiten, die kennwortlose Authentifizierung in Azure zu aktivieren. In der untersuchten Umgebung wurde die Microsoft Authenticator App verwendet.

Um sich für die kennwortlose Authentifizierung anzumelden, müssen Endbenutzer die folgenden detaillierten Konfigurationsschritte ausführen. Sobald der Benutzer für diese Methode angemeldet ist, kann er seinen Benutzernamen in die Azure-Anmeldeaufforderung eingeben und dann die Option "Stattdessen eine App verwenden" auswählen:

‍

Der Nutzer erhält dann eine Nummer, die er in der mobilen App eingeben muss, um den Vorgang abzuschließen:

Wenn die Zahl übereinstimmt, ist der Benutzer authentifiziert. Diese Methode ist zwar einigermaßen sicher, aber die Benutzer müssen sich nicht mehr mit dem Erstellen und Merken guter Passwörter beschäftigen, was die Benutzerfreundlichkeit erheblich verbessert.

Untersuchung

In der Vergangenheit haben wir verschiedene Möglichkeiten zur Einrichtung von MFA in Azure überwacht, einschließlich der Verwendung der passwortlosen Anmeldung mit Microsoft Authenticator als zweitem Faktor (d. h., wenn der Benutzer in der App nach Eingabe des richtigen Passworts aufgefordert wird). Bei Microsoft Authenticator als zweitem Faktor beobachten wir einen der beiden folgenden Fehler in den Protokollen, wenn Authenticator-Aufforderungen abgebrochen werden oder der Code falsch ist:

• 50074 Eine starke Authentifizierung ist erforderlich.
• 500121 Authentifizierung bei starker Authentifizierungsanforderung fehlgeschlagen.

Daher wurden unsere Erkennungs- und Suchabfragen so eingerichtet, dass sie nach diesen Fehlercodes suchen.

Wenn die Microsoft Authenticator App jedoch als Einzelfaktor eingerichtet ist, wie es bei der kennwortlosen Authentifizierung der Fall ist, wurde der folgende Fehler angezeigt, als die Aufforderung abgebrochen wurde

• {"errorCode":1003033,"failureReason":"The remote NGC session was denied."}

Dieser Fehlercode war neu, so etwas hatten wir noch nie gesehen, und eine Suche im Internet ergab praktisch keine Informationen über seinen Ursprung. Auch die Fehlermeldung war kryptisch und enthielt keine Erklärung, was "NGC" ist. Nach einiger Suche stellten wir fest, dass er der GUID D6886603-9D2F-4EB2-B667-1971041FA96B entspricht, die als "PIN Credential Provider" dokumentiert ist.

Bei der Untersuchung des Protokolls fielen uns weitere Ungereimtheiten auf (siehe Screenshot unten):

• Standort- und Gerätedetails (in rot) werden nicht ausgefüllt.
• Die App und die Ressourceninformationen (in blau) fehlen.
• Die Benutzerinformationen (in lila) sind begrenzt. UserPrincipalName und UserDisplayName sind nicht mit den erwarteten Werten gefüllt (E-Mail-Adresse und vollständiger Name des Benutzers). Stattdessen steht der Wert UserId in allen drei Feldern.

Der ungewöhnliche Fehlercode und die fehlenden Daten in den Protokollen erschweren es, auf solche Ereignisse aufmerksam zu machen und sie richtig zu untersuchen.

Milderung

Angesichts der Schwierigkeiten, die wir bei der Untersuchung dieses Vorfalls hatten, wollten wir die Details, die wir gesammelt haben, mit der Sicherheits-Community teilen, damit Sicherheitsexperten ihre Suchanfragen anpassen können, um diesen Zustand zu erfassen. Wir von Vectra haben unsere Produkte bereits aktualisiert, um dieses Szenario abzudecken.

Die Suchabfrage könnte so einfach sein wie das folgende Kusto-Snippet, das alle fehlgeschlagenen passwortlosen Anmeldeversuche der letzten 30 Tage findet:

SigninLogs | where TimeGenerated > ago(30d) | where ResultType == 1003033

Einige andere Fehlercodes im Zusammenhang mit NGC könnten ebenfalls von Interesse sein:

Mitbringsel:

• Wenn Sie neue Methoden zur Authentifizierung in Ihrer Umgebung einführen, bewerten Sie die Protokolle, die sich aus den Interaktionen mit diesen neuen Mechanismen ergeben. Achten Sie auf neue Fehlercodes und Protokolldatentypen, die bei der Überwachung und Alarmierung berücksichtigt werden müssen.
• Organisationen, die nach Fehlern bei der passwortlosen Anmeldung suchen, sollten in Erwägung ziehen, den Code 1003033 zu ihren Suchanfragen hinzuzufügen. Beachten Sie die begrenzten Informationen, die mit diesem Datensatz verfügbar sind - Sie können den UserPrincipalName oder andere Informationen, die normalerweise in den Anmeldeprotokollen verfügbar sind, nicht verwenden.
• Ein Aufruf an die Anbieter von cloud (einschließlich Microsoft): Bitte fangen Sie an, Protokolle als ein wichtiges Sicherheitsmerkmal zu behandeln, auf das viele Akteure angewiesen sind. Bitte dokumentieren Sie die Protokolle gründlich, ergänzen Sie fehlende Informationen und geben Sie alle Änderungen bekannt, die Sie vornehmen. Dies wird Ihren Kunden und Sicherheitsanbietern in ihrem Kampf für die Sicherheit aller helfen.

Der Autor dankt Peter Schaub und Rey Valero für ihre Hilfe bei der Recherche zu diesem Vorfall.