Bei Eye Security suchen wir ständig nach neuen Bedrohungen und Erkennungsmethoden, um unsere Kunden zu schützen. In den vergangenen Monaten konnten wir einen steigenden Trend bei Business Email Compromises (BECs) beobachten. In diesem Fall verwenden Bedrohungsakteure Attacker-in-the-Middle (AITM)-Phishing-Kits, die Benutzer über Links in E-Mail-Nachrichten auf Phishing-Seiten locken. Diese Phishing-Seiten sind Pixel für Pixel identisch mit den regulären Microsoft-Anmeldeseiten. Die Benutzerinteraktionen werden jedoch über einen Server geleitet, der von einem Bedrohungsakteur kontrolliert wird. Auf diese Weise kann der Bedrohungsakteur nicht nur den Benutzernamen und das Kennwort, sondern auch das Sitzungstoken abgreifen, wodurch wiederum die Multi-Faktor-Authentifizierung (MFA) umgangen wird. Lesen Sie weiter und erfahren Sie, wie Sie geschützt bleiben.
Wir schützen Kunden nicht nur durch Prävention, sondern auch durch das Erkennen und Reagieren auf verdächtige Anmeldungen. Um dies im großen Maßstab zu erreichen, setzen wir Microsoft Sentinel für unsere Microsoft 365-Kunden ein. Dieser Ansatz ermöglicht eine enge Integration mit dem Microsoft-Ökosystem und bietet gleichzeitig die Flexibilität, benutzerdefinierte Regeln zu erstellen und im großen Maßstab nach Bedrohungen zu suchen.
Sneaky 2FA: Neue Bedrohung nutzt Schwachstellen in Microsoft 365-Konten aus
Wir sind kürzlich auf ein neues Attacker-in-the-Middle (AITM)-Phishing-Kit mit dem treffenden Namen Sneaky2FA aufmerksam geworden. Wir haben schnell eine Sentinel-KQL-Abfrage entwickelt und eine rückwirkende Bedrohungssuche im großen Maßstab durchgeführt. Dabei haben wir Hunderte von Sentinel-Arbeitsbereiche in weniger Zeit durchsucht, als man braucht, um eine gute Tasse Kaffee zu trinken. Tatsächlich sind wir auf Business Email Compromises (BECs) gestoßen, die nun Sneaky2FA zugeschrieben werden können. Alle diese BECs wurden jedoch von den unzähligen anderen Erkennungsregeln erkannt, die wir in den Sentinel-Arbeitsbereichen unserer Kunden bereitstellen. Eine dieser Erkennungsregeln betraf ein AITM-Phishing-Kit namens W3LL. Quellen wie Sekoia legen nahe, dass Sneaky2FA von W3LL abgeleitet ist.
Das Interessante an Sneaky 2FA ist unserer Meinung nach die Art und Weise, wie es beim Anmeldevorgang die Benutzeragenten durchläuft, wenn ein Benutzer Opfer eines Phishing-Angriffs wird. Sneaky 2FA verwendet einen Satz von fünf gängigen und leicht veralteten, aber dennoch eindeutigen Benutzeragenten. Hier ist ein Beispiel:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/115.0
Das Erkennen der Anwesenheit eines dieser Benutzeragenten kann ein wirksamer Indikator sein. Dies führt jedoch häufig zu einer hohen Rate an falsch positiven Ergebnissen und kann zu einer Alarmmüdigkeit im SOC führen. Gleichzeitig bietet uns das Verhalten selbst eine Möglichkeit zur Entdeckung. Da wir unsere SOC-Analysten mögen, False Positives jedoch nicht, haben wir uns vorgenommen, eine generische Abfrage zu erstellen, um dieses Verhalten mit hoher Genauigkeit zu erkennen.
Entwickeln einer KQL-Abfrage zum Erkennen verdächtiger Gerätewechsel während der Anmeldung
Wir haben eine allgemeine KQL-Abfrage geschrieben, die, wie Sekoia es nennt, „einen unmöglichen Gerätewechsel“ während der Anmeldung erkennt. Diese Abfrage kann in Sentinel-Arbeitsbereichen als geplante Suche mit einem kurzen Rückblickfenster bereitgestellt werden. Wir teilen das gerne mit der Community. Unsere interne Version fügt einige KQL-Tricks hinzu, um die bereits niedrige Falsch-Positiv-Rate weiter zu senken. Darüber hinaus kann der Parameter jaccardIndex angepasst werden, um False Positives aufgrund von Browserversion-Updates auszusortieren.
Hier ist die KQL-Abfrage in ihrer ganzen Pracht:
// Eye Security 2025
let suspiciousSignins = SigninLogs
| where DeviceDetail.deviceId == ''
| summarize userAgents = make_set(UserAgent) by CorrelationId
| where array_length(userAgents) > 2;
let correlationIds = suspiciousSignins
| mv-expand i = range(0, array_length(userAgents) - 2)
| mv-expand j = range(i + 1, array_length(userAgents) - 1)
| extend userAgent1 = tostring(userAgents[toint(i)])
| extend userAgent2 = tostring(userAgents[toint(j)])
| extend array1 = to_utf8(userAgent1)
| extend array2 = to_utf8(userAgent2)
| extend jaccardIndex = jaccard_index(array1, array2)
| where jaccardIndex < 0.8
| summarize by CorrelationId;
SigninLogs
| where ResultType == 0
| where CorrelationId in (correlationIds)
Aufschlüsselung der Abfrage
Lassen Sie uns die Abfrage aufschlüsseln. Zunächst greift die Abfrage auf die SigninLogs zu, in denen kein bei Entra registriertes Gerät vorhanden ist:
let suspiciousSignins = SigninLogs
| where DeviceDetail.deviceId == ''
Das machen wir, weil ein Bedrohungsakteur während des ersten Angriffs nicht auf ein bei Entra registriertes oder verbundenes Gerät zugreifen kann. Dadurch wird die Rate falsch positiver Ergebnisse enorm reduziert.
Anschließend übernimmt die Abfrage alle UserAgents, die mit derselben CorrelationId verknüpft sind, und behält nur die Zeilen mit drei oder mehr UserAgents bei:
| summarize userAgents = make_set(UserAgent) by CorrelationId
| where array_length(userAgents) > 2;
Microsoft beschreibt die CorrelationId wie folgt:
Anmeldeprotokolle enthalten mehrere eindeutige Kennungen, die weitere Einblicke in den Anmeldeversuch bieten. Correlation ID: Die Correlation ID gruppiert Anmeldungen aus derselben Anmeldesitzung. Der Wert basiert auf Parametern, die von einem Client übergeben werden. Daher kann Microsoft Entra ID dessen Genauigkeit nicht garantieren.
Wir beobachten tatsächlich Ausreißer in Bezug auf die CorrelationId. Beispielsweise wird in einigen Fällen die gleiche CorrelationId an mehrere Cloud-Identitäten angehängt, was nicht passieren sollte. Die Ursache dieser Diskrepanz müssen wir noch herausfinden. Darüber hinaus liefert dieser Teil der Abfrage auch Ergebnisse, bei denen Chrome/130 auf Chrome/131 aktualisiert wird. Wir müssen diese herausfiltern, um falsch positive Meldungen zu vermeiden. Das ist die Aufgabe des nächsten Teils der Anfrage.
Verwenden der Jaccard-Index-KQL-Funktion
Der erste Teil der Abfrage ergibt ein Array von UserAgents pro CorrelationId. Wir nehmen diese Informationen und transformieren sie, sodass sie in eine KQL-Funktion namens jaccard_index eingespeist werden können. Mit diesem Jaccard-Index kann die Ähnlichkeit zweier Mengen quantifiziert werden.
Die Abfrage erreicht dies, indem sie alle paarweisen Kombinationen der User Agents generiert und dabei zunächst zwei Hilfsspalten generiert:
let correlationIds = suspiciousSignins
| mv-expand i = range(0, array_length(userAgents) - 2)
| mv-expand j = range(i + 1, array_length(userAgents) - 1)
Anschließend holt sie sich die entsprechenden Benutzeragenten aus dem Array userAgents:
| extend userAgent1 = tostring(userAgents[toint(i)])
| extend userAgent2 = tostring(userAgents[toint(j)])
Als ich das einem Kollegen zeigte, war seine Antwort: „In einer SQL-ähnlichen Sprache hätte ich diese for i / for j-Schleife anders geschrieben. Sie funktioniert zwar ohne Probleme, aber es wirkt, als würde jemand C in eine KQL-Abfrage schreiben wollen.“ Schuldig im Sinne der Anklage!
Das Ergebnis sind zwei Zeichenfolgen, aber die Funktion jaccard_index arbeitet mit Mengen. Daher wandeln wir die Zeichenfolgen mithilfe von to_utf8 von KQL in ein Array von Bytewerten um:
// create inputs for jaccard_index function
| extend array1 = to_utf8(userAgent1)
| extend array2 = to_utf8(userAgent2)
Schließlich können wir den Jaccard-Index berechnen und die Werte herausfiltern, die zu ähnlich sind (z. B. Chrome/130 und Chrome/131). Dadurch erhalten wir eine Liste von correlationIds, die wir mit den SigninLogs abgleichen können:
| extend jaccardIndex = jaccard_index(array1, array2)
| where jaccardIndex < 0.8 // cut-off
| summarize by CorrelationId; // leave only suspicious correlationIds
Der Grenzwert von 0,8 wird ermittelt, indem die von Sneaky 2FA verwendeten Benutzeragenten herangezogen und die entsprechenden Jaccard-Indizes berechnet werden:
let userAgents = dynamic([
"Mozilla/5.0 (iPhone; CPU iPhone OS 13_2_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.3 Mobile/15E148 Safari/604.1",
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36",
"Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/115.0",
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 Edg/128.0.0.0 OS/10.0.22635",
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36 Edg/129.0.0.0"]
);
print dummy = 0
| mv-expand i = range(0, array_length(userAgents) - 2)
| mv-expand j = range(i + 1, array_length(userAgents) - 1)
| extend userAgent1 = tostring(userAgents[toint(i)])
| extend userAgent2 = tostring(userAgents[toint(j)])
| extend array1 = to_utf8(userAgent1)
| extend array2 = to_utf8(userAgent2)
| extend jaccardIndex = jaccard_index(array1, array2)
| project userAgent1, userAgent2, jaccardIndex
Bild 1. Sneaky 2FA: Jaccard-Indizes des Benutzeragenten
Basierend auf diesen Jaccard-Indizes haben wir 0,8 als geeigneten Schwellenwert angenommen.
Sneaky 2FA: Und jetzt fügen wir alle Teile zusammen
Das letzte Puzzleteil besteht darin, die verdächtigen correlationIds zu nehmen und diese mit den SigninLogs abzugleichen, bei denen die Authentifizierung erfolgreich war:
Based on these Jaccard indices, we took 0.8 as an appropriate threshold value.
[...]
SigninLogs
| where ResultType == 0 // authentication succeeded
| where CorrelationId in (correlationIds)
Diese Abfrage weist bereits eine überraschende Genauigkeit auf, wir haben sie jedoch intern optimiert, um die Anzahl der falsch positiven Meldungen mithilfe von Erkenntnissen aus verschiedener interner und externer Research weiter zu senken.
Hier sehen Sie sie in voller Aktion, wo sie eine Sneaky 2FA-Anmeldung korrekt identifiziert. Beachten Sie, dass die Abfrage den verdächtigen Firefox/115-Benutzeragent korrekt erkennt, ohne dass er hartkodiert in der Abfrage stehen muss.
Bild 2. Sneaky 2FA: Anzeige der Abfrageergebnisse
Schlussfolgerung
Wir hoffen, dass diese KQL-Abfrage Unternehmen im ständigen Kampf gegen AITM-Phishing hilft, insbesondere bei neuen Bedrohungen wie Sneaky2FA.
Um Unternehmen im Kampf gegen Login-Spoofing-Seiten zu unterstützen, haben wir das Eye Anti-Spoofing Tool (EAST) entwickelt. Es ist unser fortschrittliches Cybersicherheitstool, das speziell für die Bekämpfung von Microsoft-Login-Spoofing entwickelt wurde. EAST kann als separate Maßnahme verwendet werden, um Benutzer zu warnen, wenn sie ihre Anmeldeinformationen auf bestimmten Phishing-Seiten eingeben.
Wenn Sie wissen möchten, wie Eye Security Ihnen beim Schutz Ihres Unternehmens helfen kann, kontaktieren Sie uns über das untenstehende Formular:
FAQ
Was ist Sneaky 2FA?
Sneaky 2FA ist ein hochentwickeltes Phishing-Kit, das gezielt Microsoft-365-Konten angreift, die Zwei-Faktor-Authentifizierung (2FA) umgeht und Benutzeranmeldedaten stiehlt. Dieses Phishing-Kit wird als Phishing-as-a-Service (PhaaS)-Plattform über Telegram angeboten und ist somit einer breiten Palette von Bedrohungsakteuren zugänglich. Durch diese fertige Lösung können selbst weniger technisch versierte Angreifer Phishing-Kampagnen durchführen, ohne ein eigenes Phishing-Kit entwickeln zu müssen. Diese einfache Zugänglichkeit erhöht die Bedrohungslage erheblich und macht es für Organisationen unerlässlich, wachsam zu bleiben und robuste Sicherheitsmaßnahmen zu implementieren.
Welche Taktiken nutzt Sneaky 2FA in seinen Phishing-Kampagnen?
Sneaky 2FA setzt eine Vielzahl von Taktiken ein, um der Erkennung zu entgehen und Opfer zur Preisgabe ihrer Anmeldedaten zu verleiten. Eine besonders auffällige Methode ist die automatische Voreingabe der E-Mail-Adresse des Opfers auf der Phishing-Seite, was den Eindruck einer legitimen Anmeldeseite erweckt. Dadurch steigt die Wahrscheinlichkeit, dass das Opfer sein Passwort eingibt, da die Seite authentisch wirkt. Darüber hinaus verwendet das Phishing-Kit anpassbaren Code, um Sicherheitslösungen zu umgehen, und nutzt häufig Wordpress-Websites sowie andere von Angreifern kontrollierte Domains. Diese Techniken machen Sneaky 2FA zu einer ernstzunehmenden Bedrohung, da es sich leicht als legitime Website tarnen und herkömmliche Sicherheitsmaßnahmen umgehen kann.
Welche Verschleierungstechniken verwendet Sneaky 2FA?
Um der Erkennung durch Sicherheitslösungen zu entgehen, setzt Sneaky 2FA mehrere ausgeklügelte Verschleierungstechniken ein. Eine dieser Methoden besteht darin, Sicherheitswerkzeuge auf Wikipedia-Seiten umzuleiten, sodass die Anfragen harmlos und legitim wirken. Diese Umleitung verwirrt Sicherheitssysteme und verhindert, dass Phishing-Seiten identifiziert werden. Zusätzlich nutzt Sneaky 2FA den kostenlosen Firewall-Dienst von Cloudflare, um Web-Security-Crawler zu blockieren und somit eine weitere Schutzschicht gegen Erkennung zu schaffen. Diese Verschleierungstechniken erschweren es Sicherheitslösungen erheblich, die Phishing-Seiten zu erkennen und zu blockieren, und ermöglichen es den Bedrohungsakteuren, weitgehend unbehelligt zu agieren.
Welche Abwehrstrategien gibt es?
Um die Risiken durch Sneaky 2FA zu minimieren, sollten Organisationen phishing-resistente Authentifizierungsmethoden wie Microsoft Authenticator einsetzen. Dieses Tool bietet eine zusätzliche Sicherheitsebene und erschwert es Angreifern, die Zwei-Faktor-Authentifizierung zu umgehen. Echtzeit-URL-Scanning und die Erkennung neu registrierter Phishing-Domains können ebenfalls helfen, Phishing-Angriffe zu verhindern, bevor sie Nutzer erreichen. Darüber hinaus ist die Aufklärung der Nutzer über Phishing-Risiken und die Erkennung legitimer Websites von entscheidender Bedeutung. Durch Sensibilisierung und Schulungen können Organisationen ihre Mitarbeiter befähigen, Phishing-Versuche zu erkennen und zu vermeiden.
Wie lassen sich solche Phishing-Angriffe verhindern?
Die Verhinderung von Phishing-Angriffen erfordert einen mehrschichtigen Ansatz. Organisationen sollten folgende Maßnahmen in Betracht ziehen:
-
Sensibilisieren Sie Ihre Nutzer für die Risiken von Phishing und schulen Sie sie darin, legitime Websites zu erkennen.
-
Implementieren Sie phishing-resistente Authentifizierungsmethoden wie Microsoft Authenticator, um eine zusätzliche Sicherheitsebene zu schaffen.
-
Nutzen Sie Echtzeit-URL-Scanning, um Phishing-Seiten zu erkennen, bevor sie Schaden anrichten können.
-
Erkennen und blockieren Sie neu registrierte Phishing-Domains, um zu verhindern, dass Angreifer frische Domains für ihre Kampagnen nutzen.
-
Setzen Sie Sicherheitslösungen ein, die ungewöhnliche Gerätewechsel und andere von Sneaky 2FA verwendete Verschleierungstechniken erkennen können.
Durch die Umsetzung dieser Maßnahmen können Organisationen das Risiko, Opfer von Sneaky 2FA und ähnlichen Phishing-Angriffen zu werden, erheblich reduzieren. Ein proaktiver und umfassender Sicherheitsansatz ist entscheidend im Kampf gegen Phishing-Bedrohungen.
Wenn Sie erfahren möchten, wie Eye Security Ihr Unternehmen schützen kann, kontaktieren Sie uns über das untenstehende Formular.
