Erkennung von Tycoon 2FA AiTM-Angriffen über Entra ID und Google Workspace

Tycoon 2FA ist derzeit die am weitesten verbreitete Phishing-as-a-Service (PhaaS)-Plattform unter den AiTM-Phishing-Kits. Das Kit wurde erstmals im August 2023 beobachtet und Storm-1747 zugeordnet (laut Microsoft Threat Intelligence). Es bietet sofort einsatzbereite Adversary-in-the-Middle (AiTM)-Funktionen, die die Multi-Faktor-Authentifizierung umgehen und authentifizierte Sitzungstoken von Microsoft 365 und Google Workspace-Konten stehlen. In Spitzenzeiten war Tycoon 2FA für rund 62 % der von Microsoft blockierten Phishing-Versuche verantwortlich und erreichte monatlich über 500.000 Organisationen.

Trotz einer koordinierten Aktion im März 2026 angeführt von Microsoft und Europol, mit Unterstützung von Cloudflare, SpyCloud, eSentire und anderen Partnern, die über 300 Domains beschlagnahmten, passten sich die Betreiber innerhalb weniger Wochen an. Bis Ende April 2026 dokumentierte eSentire Kampagnen, die Tycoon-Techniken mit Phishing-Abläufen über OAuth-Gerätecodes kombinierten, und das Kit ist nach wie vor der Eintrag Nr. 1 im Malware-Trend-Tracker von ANY.RUN.

So funktioniert die Zwei-Faktor-Authentifizierung bei Tycoon

Der AiTM-Mechanismus

Tycoon 2FA fungiert als umgekehrter Proxy zwischen dem Opfer und dem legitimen Identitätsanbieter (Entra ID oder Google). Es handelt sich nicht um einen statischen Credential Harvester. Es bildet den eigentlichen Anmeldevorgang in Echtzeit nach:

1. Das Opfer erhält eine Phishing-E-Mail, die einen Link oder QR-Code enthält, der in einem PDF-, SVG-, HTML- oder PPTX-Anhang eingebettet ist.
2. Der Link durchläuft eine mehrschichtige Umleitungskette. Das Kit führt Browser-Fingerprinting, CAPTCHA-Herausforderungen und Anti-Analyse-Prüfungen durch, bevor die Anmeldeseite angezeigt wird.
3. Das Opfer sieht eine pixelgenaue Nachbildung der Anmeldeseite von Microsoft oder Google, die oft auch das Branding der Zielorganisation enthält, das dynamisch vom echten Dienst abgerufen wird.
4. Die Anmeldeinformationen werden in Echtzeit an den legitimen Identitätsanbieter weitergeleitet. Die eigentliche MFA-Herausforderung wird ausgelöst und über einen Proxy an das Opfer zurückgeleitet.
5. Das Opfer schließt die MFA normal ab. Der Identitätsanbieter stellt ein Sitzungstoken aus. Der Proxy fängt dieses Token ab, bevor es den Browser des Opfers erreicht.
6. Der Angreifer besitzt nun ein vollständig authentifiziertes Zugriffstoken.

Der Session-Cookie ist der Wert, den der Betreiber monetarisiert. Sobald die Token erfasst sind, ist die Zwei-Faktor-Authentifizierung (MFA) irrelevant, da der Betreiber die nach der MFA erzeugten Token erneut ausgibt.

Zwei Strukturvarianten in aktueller Rotation

Zwei verschiedene Kit-Varianten, die wir analysiert haben, waren im aktiven Einsatz:

WebSocket AiTM (der "klassische" Tycoon 2FA-Ablauf): Das Opfer authentifiziert sich über einen vom Kit gehosteten Proxy, der den Datenverkehr über WebSocket (Socket.IO) an Microsoft oder Google weiterleitet und den Post-MFA-Session-Cookie erfasst. Der JavaScript-Client-Controller des Kits unterhält einen bidirektionalen Echtzeitkanal zum C2-Server und leitet Anmeldeinformationen und Authentifizierungsantworten weiter, während das Opfer tippt. Diese Antworten beinhalten generierte Zugriffs- und Aktualisierungstoken zur Verwendung.

Missbrauch von Gerätecodes (nur Microsoft): Das Kit-Relay bezieht einen Gerätecode vom Microsoft-Endpunkt oauth2/devicecode mit dem Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e) als Client, zeigt ihn dem Opfer unter dem Vorwand eines „Verifizierungscodes“ an und tauscht den Code gegen Zugriffs-/Aktualisierungstoken ein, nachdem sich das Opfer auf der legitimen Website microsoft.com/devicelogin angemeldet hat. Endpunkt.

Ausweichtechniken

Das Kit verwendet mehrschichtige Anti-Analyse-Mechanismen, die durch JavaScript-Dekompilation bestätigt wurden:

• IP-basierte Forscherfilterung: Bevor Inhalte angezeigt werden, ruft das Kit api.ipapi.is (oder einen gleichwertigen Dienst) auf, um die IP-Adresse des Besuchers mit einer Sperrliste von Cloud-/Hosting-Anbietern (Leaseweb, M247, DigitalOcean, Linode, Amazon, OVH, Hetzner, Google, Microsoft, Cloudflare, Akamai, Fastly, gespeichert als umgekehrte Zeichenketten, um statische Scans zu umgehen) abzugleichen. Besucher, die sich auf Cloud-Infrastrukturen befinden, werden auf eine harmlose Köderseite umgeleitet.
• Bot-/Tool-Erkennung: Prüft auf navigator.webdriver (Selenium), window.callPhantom / window._phantom (PhantomJS) und "Burp" im User-Agent-String. Die Erkennung löst eine Weiterleitung zu about:blank aus.
• DevTools-Blockierung: Fängt Tastenkombinationen für Entwicklertools ab (F12, Strg+Umschalt+I/J/C, Strg+U, macOS-Äquivalente) und deaktiviert Kontextmenüs per Rechtsklick.
• Debugger-Trap: Eine setInterval- Schleife, die alle 100 ms ausgeführt wird, fügt eine Debugger-Anweisung ein und misst die Ausführungszeit. Wenn die Entwicklertools geöffnet sind (Ausführungspausen >100ms), wird das Opfer auf eine Köderseite umgeleitet.
• DOM-Verschwinden: Bösartiger JavaScript-Code entfernt sich nach der Ausführung selbst aus dem DOM und hinterlässt somit keine Spuren für eine statische Überprüfung.
• Opferspezifische Verschlüsselung: Die Nutzdaten verwenden eine benutzerdefinierte zweistufige Chiffre (Caesar-Shift + XOR mit einem PRNG-generierten Schlüsselstrom), die mit sitzungsspezifischen Werten initialisiert wird. Seed, Schlüssel und verschlüsselter Blob werden für jedes Opfer serverseitig generiert, wodurch eine statische Signaturerkennung unmöglich wird.
• Plattformausrichtung: Auf Linux-Desktops wird eine leere Zeichenkette ausgegeben, um die Seite zu leeren. Dies geht wahrscheinlich davon aus, dass Linux-Benutzer eher Sicherheitsforscher sind.
• Gefälschtes CAPTCHA: In der aktuellen Variante wird Cloudflare Turnstile durch ein benutzerdefiniertes Bildraster-CAPTCHA ersetzt. Die von Unsplash stammenden Bilder sind in einem 3×3-Raster angeordnet und dienen der menschlichen Überprüfung, bevor die Phishing-Seite geladen wird.

Bei Kampagnen, die auf Google abzielen, erfolgt der erste Köder häufig auf legitimer Google-Infrastruktur, wie Google Storage oder Google Sites, wobei aber auch von Betreibern kontrollierte oder kompromittierte Domains beobachtet werden. Bei Verwendung des eigenen Hostings von Google bietet der Ursprung storage.googleapis.com oder sites.google.com einen integrierten Reputationsschutz, bevor das Opfer das AiTM-Relay erreicht.

In anderen Fällen wird die E-Mail-Adresse des Opfers automatisch ausgefüllt und die Schaltfläche „Weiter“ automatisch angeklickt: Das Opfer landet direkt auf der Passwortseite, wodurch es so aussieht, als sei es bereits teilweise authentifiziert (was das Vertrauen erhöht):

var emailcheck = "victim@email.corp";
// ...
function tryfindingele(email) {
   emailinputcheck.value = email;
   emailsectionelecheck.querySelector(".btn-blue-next-btn").click();
}
if (emailcheck !== "0") { tryfindingele(emailcheck); }

Microsoft 365 / Entra-ID

Eine zweistufige Betriebsarchitektur

Das aktuelle Betriebsmodell von Tycoon 2FA ist in zwei unterschiedliche Infrastrukturebenen unterteilt, von denen jede über ein eigenes ASN, eine eigene Rolle und eine eigene Verhaltenssignatur verfügt. Verteidiger, die nach einem einzigen Angriffsmuster suchen, werden die eine Ebene erfassen und die andere verpassen.

Stufe 1 - Kit-Staffel

Das automatisierte Backend, das die Token-Akquise und -Erneuerung abwickelt. Eigenschaften:

• Cloud-VPS-Ausgangs-IPs von Hosting-Anbietern (Alibaba Cloud, ähnliche günstige VPS-ASNs), die während eines einzigen Engagements über mehrere IPs in verschiedenen /16-Blöcken rotieren.
• Node.js HTTP-Client-User-Agents: node (bare, Standard-Node.js-UA), axios/1.15.2, node-fetch/1.0, undici.
• Client-App: Microsoft Authentication Broker (29d9ed98-a469-4536-ade2-f981bc1d605e), später verwendet mit Device Registration Service (DRS) zur Generierung eines primaryRefreshToken (PRT).
• Token-Typ-Progression: incomingTokenType: none (initiale Opferauthentifizierung) > refreshToken (Kit-Relay-Erneuerungsschleife, wiederholt über rotierende IPs) > Rogue-Geräteregistrierung > primaryRefreshToken (PRT-Replay, größerer Geltungsbereich).
• Nicht-interaktive Anmeldungen: Nach der ersten interaktiven Gerätecode-Abfrage erfolgen alle nachfolgenden Token-Operationen als Server-zu-Server-Aktualisierungen.

Stufe 2 - Bedienerkonsole

Der Mensch (oder das menschenähnliche Werkzeug), der die Aufklärung nach einer Kompromittierung durchführt. Eigenschaften:

• Residential-ähnlicher ISP- oder Proxy-Ausgang, typischerweise eine kleine ASN, die in gängigen Bedrohungsfeeds von Hosting-Anbietern nicht vorhanden ist. Mehrere IPs in einem einzigen /24-Netz, die alle koordiniert zusammenarbeiten.
• Ein einziger Browser-User-Agent (z. B. Firefox unter Windows) ist für alle IPs im Cluster festgelegt. Ein konfiguriertes Tool, keine unabhängigen Benutzer.
• Browserbasierte interaktive Anmeldungen bei Microsoft-Webanwendungen: Mein Profil, Meine Anmeldungen, Microsoft Approval Management, Outlook Web und OfficeHome.
• Eine einzige c_sid (Client-Sitzungs-ID in Graph-Aktivitätsprotokollen) wird über alle IPs hinweg geteilt, was bestätigt, dass eine einzelne Sitzung über den Pool verteilt ist.
• Betriebstempo: Tritt typischerweise 10-20 Minuten nach der ersten erfolgreichen Tokenausgabe des Kit-Relays auf. Die Lücke stellt das Übergabefenster vom Kit an den Bediener dar.

Das dauerhafte Cross-Tier-Erkennungssignal: Zwei unterschiedliche ASNs (eines Cloud-VPS, eines Residential-Modells) authentifizieren sich innerhalb von Minuten als derselbe Benutzerprinzipal. Die Regeln für eine einzelne ASN erfassen eine Ebene; der ebenenübergreifende Pivot ist der Indikator mit hoher Konfidenz.

Aufzählung der Graph-API nach dem Kompromittierungsfall

Sobald die Bedienerkonsole über ein gültiges Token verfügt, folgt eine rasche Flut von Microsoft Graph API-Aufrufen, typischerweise Dutzende von Anfragen innerhalb von 30-60 Sekunden, die wichtige Aufklärungsendpunkte erreichen:

Wichtige Telemetrieindikatoren für die automatisierte Aufklärung nach einer Kompromittierung:

• Volumen und Geschwindigkeit: 20-30+ Anrufe innerhalb eines Zeitfensters von 30-60 Sekunden, wobei jeder Anruf einen anderen Endpunkt erreicht.
• Gemischte HTTP-Methoden: GET für die meisten Endpunkte, POST für Aktionen wie getResourceTenants.
• Strukturierte Abfrageparameter: $select, $top=999, $count=true - optimiert für maximale Datenextraktion pro Aufruf.
• /beta/ API-Nutzung: Wird unverhältnismäßig häufig von offensiven Tools im Vergleich zur normalen Portalnavigation genutzt.
• Gemischter Erfolg/Misserfolg: Einige Endpunkte geben 400 oder 403 zurück (das Kit prüft trotzdem alles), während die meisten den Statuscode 200 zurückgeben. Auch fehlgeschlagene Aufklärungsversuche sind noch Aufklärung.
• Leere C_DeviceId: Das Token wurde einem nicht verwalteten, nicht registrierten Gerät ausgestellt.
• Erstanbieter-Apps mit umfassenden, vorab erteilten Berechtigungen: Tokens für Mein Profil enthalten Berechtigungen wie RoleManagement.ReadWrite.Directory, MailboxSettings.ReadWrite, UserAuthenticationMethod.ReadWrite und User.RevokeSessions.All – alle vorab erteilt, sodass keine OAuth-Zustimmungsabfrage erforderlich ist.

Geräte-PRT-Persistenz

Wie bereits erwähnt, kann das Kit eine dauerhafte Geräteregistrierung gewährleisten, die auch Standard-Sitzungswiderrufs-Playbooks übersteht. Der Mechanismus:

1. Der MAB-Refresh-Token wird bei oauth2/token gegen einen Zugriffstoken ausgetauscht, dessen aud urn:ms-drs:enterpriseregistration.windows.net lautet (gleiche Client-ID, neue Zielgruppe, keine Zustimmungsabfrage).
2. Das Kit verwendet das Zugriffstoken urn:ms-drs:enterpriseregistration.windows.net, um den Endpunkt EnrollmentServer/device mit einem lokal generierten PKCS#10 CSR, synthetischen Gerätemetadaten und einem Transportschlüssel-Blob per POST zu erreichen. DRS erstellt ein Geräteobjekt, weist eine Geräte-ID zu, signiert und gibt ein Gerätezertifikat zurück.
3. Das Kit erstellt ein JWT, das das Aktualisierungstoken des Benutzers enthält, signiert es mit dem privaten Schlüssel des Geräts gemäß RS256 und bettet das Gerätezertifikat in den JWT-Header ein. Es sendet diese POST-Anfrage an login.microsoftonline.com/common/oauth2/token. als JWT-Trägerzuwendung. Entra validiert die Signatur anhand des Zertifikats und gibt die PRT sowie einen verschlüsselten Sitzungsschlüssel (JWE) zurück.
4. Wenn ein Verteidiger revokeSignInSessions auslöst (wodurch alle Benutzer-Token und Aktualisierungstoken ungültig werden), bleibt das Geräte-PRT gültig, da das Gerät in Entra ID ein separater Principal ist.
5. Ausgehend von den neuen Relay-IPs verwendet das Kit den PRT plus Sitzungsschlüssel, um HMAC-SHA256 -Assertions pro Anfrage an /oauth2/token zu signieren und Zugriffstoken für alle darin genannten First-Party- client_id (Teams, Outlook, OneDrive, Office, Intune) zu vermitteln.

Warum wird die Zwei-Faktor-Authentifizierung von Tycoon nicht durch das Widerrufen von Sitzungen unterbrochen?

Dies bedeutet, dass die standardmäßige Vorgehensweise bei Sicherheitsvorfällen, nämlich „Sitzungen widerrufen > Passwort zurücksetzen“, nicht ausreicht. Die Verteidiger müssen registrierte Geräte auflisten und löschen, bevor sie Sitzungen widerrufen können, um die Geräte-PRT-Kette atomar zu unterbrechen.

Erkennungsnuancen – Microsoft

Der Identitätsschutz kennzeichnet möglicherweise nicht die Kit-Infrastruktur. Die aktuellen ausgehenden IPs von Tycoon 2FA werden häufig gewechselt und befinden sich möglicherweise nicht im Risikokorpus von Microsoft. Verteidiger, die sich ausschließlich auf Entra ID-Risikosignale zur Erkennung von AiTM verlassen, werden nichts feststellen.

c_sid in den Graph-Aktivitätsprotokollen ist NICHT die Benutzerobjekt-ID. Es handelt sich um eine Sitzungs-/Sicherheitskontextkennung. Analysten, die Graph Activity Logs nach c_sid == user_object_id filtern, erhalten leere Ergebnisse und schließen daraus, dass der Angreifer keine Graph-Token verwendet hat. Der korrekte Hunt-Pivot besteht aus Quell-IP + App-ID, abgeglichen mit den Anmeldeprotokollen, um die IP dem Benutzer zuzuordnen.

Die Geolokalisierung ist für IP-Adressen von Cloud-Anbietern unzuverlässig. Mit demselben Kit-Relay-IP kann innerhalb derselben Anmeldesitzung der Standort in verschiedenen Städten ermittelt werden. ASN ist die einzige zuverlässige Anreicherung für Erkennungsregeln.

Sichtbarkeit der Token-Erstellung. Die Erstellung oder Ausgabe von Token wird nicht protokolliert; Authentifizierungsereignisse, die diese Token nutzen, erzeugen ein reaktiveres Suchsignal.

Entra ID Protection Risikostatus für Benutzer. Der Entra ID-Schutz analysiert Anmeldeereignisse, Sitzungen, Tokens und mehr, um Benutzern ein Risikoniveau und einen Status zuzuweisen. Während der Stufe 2 wurde aiConfirmedSafe beobachtet, was bedeutet, dass der Benutzer keinem Risiko ausgesetzt ist. Anschließend wurden Anomalien im Benutzerrisiko anhand des AnomalousTokens identifiziert, wodurch der Benutzer wieder in die Kategorie „mittleres Risiko“ eingestuft wurde. Einfach Ereignisse ausschließen, bei denen aiConfirmedSafe Organisationen für falsch-negative Ergebnisse der Microsoft-Kennzeichnung blind machen kann.

Google Workspace

Einstufiges Kit-Staffel

Die Google-Variante fungiert als einstufiges Kit-Relay ohne die separate Bedienerkonsolenebene, die auf der Microsoft-Seite zu finden ist. Mehrere Kit-Relay-IPs (typischerweise von günstigen Hosting-ASNs wie Clouvider, Host Telecom oder ähnlichen) authentifizieren denselben Benutzer innerhalb von Minuten, wobei jede die gleiche Sequenz von vier Ereignissen ausführt:

1. login_success Passwort validiert (T+0,000s)
2. login_verification mit is_second_factor: true - Kit leitet den TOTP/SMS/Push-Code in Echtzeit weiter und schließt 2SV ab (T+0,000s)
3. Token: Autorisierung für den Chrome OAuth-Client von Google (77185425430) (T+0,4 bis 0,6s)
4. DEVICE_REGISTER_UNREGISTER_EVENT (Das neue Gerät wird aufgrund der Profilauthentifizierung von Google registriert) (T+0,6 bis 1,2s)

Diese Komprimierung von etwa einer Sekunde ist ein Indiz für automatisierte Anmeldevorgänge.

Das Kit autorisiert in jeder Relay-Sitzung konsistent denselben OAuth-Client:

Der OAuthLogin- Bereich ist der interne Bootstrap-Anmeldebereich von Chrome. Es handelt sich nicht um einen Datenebenenbereich (es gewährt von sich aus keinen Zugriff auf Gmail, Drive oder Kalender). Der Wirkungsbereich des Kits ist von diesem einen Ziel aus auf eine dauerhafte Anmeldung beschränkt, die zu einer Chrome-Sync-Sitzung führen kann, nicht aber auf den direkten Zugriff auf Mailboxen oder Dateien ohne weitere Token-Austausch-Aufrufe.

Das token.authorize- Ereignis einer VPS-ASN bestätigt, dass die Autorisierung serverseitig während des Relays erfolgt und nicht auf dem Gerät des Opfers, was unabhängig von der Absicht des Betreibers verdächtig ist.

Kit JavaScript-Architektur (Google-Variante)

Die Dekompilation der für Google entwickelten WebSocket-Variante offenbart eine 5-schichtige Architektur:

Die 15 Eingabefelder erfassen alle Google 2FA-Methoden: Passwort, TOTP, SMS, Sprachanruf, Backup-Codes, Wiederherstellungs-E-Mail, Telefonverifizierung, Sicherheitsschlüssel-Fallback, mobile Aufforderung und erzwungene Passwortänderung. Der Socket.IO-Ereignisname „receiveid“ (beachten Sie den Tippfehler) ist ein konsistenter Kit-Fingerabdruck.

Erkennungsnuancen – Google

Das Google Alert Center bleibt möglicherweise stumm. Selbst wenn sich ein Benutzer innerhalb weniger Minuten von mehreren ASNs aus anmeldet, werden die Alert Center-Datensätze möglicherweise nicht an die Alert API übermittelt. Die Sicherheitswarnungs-E-Mails von Google, die an das Postfach des Opfers gesendet werden, sind kein Ersatz, da sie im Posteingang des kompromittierten Nutzers und nicht auf der Administratoroberfläche landen.

is_suspicious wird möglicherweise nicht ausgelöst. Kit-Relay-IPs von günstigen Hosting-ASNs sind möglicherweise nicht im Risikokorpus von Google enthalten. Verteidiger, die sich auf dieses Feld als primäres Signal verlassen, werden tote Winkel haben. Im Canary-Test war is_suspicious bei jedem login_success von allen vier Kit-IPs sowohl bei Clouvider als auch bei Host Telecom falsch.

Kein User-Agent bei Anmeldeereignissen: Die Anmeldeereignisse der Reports API enthalten keine User-Agent- oder Geräte-Fingerabdruckdaten. Die UA-basierten Erkennungsmechanismen, die auf der Entra-Seite (node / axios / undici) funktionieren, haben kein direktes Google-Äquivalent.

Die Sichtbarkeit des OAuth-Workflows ist gering: Das token.authorize- Ereignis von Google gibt client.id preis. app_name, client.type, und scope.value, Und das ist das komplette Set. Es gibt keine resource_id, die sich vom scope unterscheidet, kein grant-type-Feld und kein incoming-token-type-Feld.

Die meisten Hilfsstreams bleiben stumm: kein Zugriff auf google_workspace.context_aware_access Es wurden Ereignisse ausgelöst (trotz fünf neuer Gerätedatensätze für den Benutzer) und es erreichten keine Alert Center-Datensätze die Alert API. Der Kit-Footprint beschränkt sich auf drei Datenströme: Login, Token und Gerät. Jagden, die auf einen anderen Datenstrom angewiesen sind, werden dieses Kit nicht erkennen.

Tycoon 2FA für Entra ID und Google Workspace

Die Variante M365 ist im Betrieb aufwändiger, und die Protokollierung liefert umfangreiche Details vor und nach der Kompromittierung der Identität. Die Google Workspace-Variante ist schlanker (es wurden nur Anmeldungen beobachtet), aber die Standardprotokollierung lässt wichtige Kontextinformationen vermissen.

Tycoon 2FA-Verhaltenserkennungsregeln

Wir haben Erkennungsregeln für Microsoft- und Google-Telemetriequellen implementiert, die die gesamte Angriffskette abdecken: vom anfänglichen AiTM-Phishing über die Tokenweiterleitung und die Aufklärung über die Bedienerkonsole bis hin zur Persistenz auf dem Gerät.

Microsoft - Kit-Relaiserkennung

Potenzielle AiTM-Anmeldung über OfficeHome (Tycoon2FA) - Dies ist eine Erkennung mit hoher Signalstärke, die bei Anmeldungen über den Auth Broker oder OfficeHome bei Graph/Exchange mit Node.js-basierten Benutzeragenten ausgelöst wird (node, axios, undici). Erfasst die serverseitigen Token-Operationen der Kit-Relay-Ebene.

M365 Potential AiTM UserLoggedIn via Office App (Tycoon2FA) - Gleiche Erkennungslogik wie die Entra-Anmelderegel, jedoch anhand des M365 Unified Audit Log für Mandanten, die o365.audit anstelle (oder zusätzlich zu) Entra-Anmeldeprotokollen erfassen.

Entra ID OAuth Device Code Phishing via AiTM : Erkennt erfolgreiche interaktive Geräte-Code-Flow-Anmeldungen über den Auth Broker, die auf Exchange, Graph oder SharePoint abzielen. Erfasst speziell die Missbrauchsvariante der Geräte-Code-Gewährung.

Entra ID Microsoft Authentication Broker Sign-In to Unusual Resource : Erkennt erfolgreiche Anmeldungen beim Auth Broker, bei denen die Zielressource außerhalb des üblicherweise beobachteten First-Party-Sets liegt. Erkennt den Austausch von FOCI-Token an unerwartete APIs oder Unternehmensanwendungen.

Microsoft – Persistenzerkennung

Entra ID Register Device with Unusual User Agent (Azure AD Join) : Erkennt erfolgreiche Geräteregistrierungsereignisse, bei denen der Benutzeragent keiner der bekannten nativen Registrierungsclients ist (Dsreg, DeviceRegistrationClient, Dalvik). Erfasst auch das Device-PRT-Persistenz-Play des Kits, das vom Axios-User-Agent ausgeht:

Post-Compromise Graph API-Enumeration (ES|QL)

Für die Aufklärung nach einer Kompromittierung auf Ebene der Bedienerkonsole haben wir eine ES|QL- Regel erstellt, die jede Microsoft Graph API-Anfrage in eine von fünf Aufklärungskategorien einordnet und ausgelöst wird, wenn innerhalb des Aggregationsfensters (<= 60 Sekunden) 4 oder mehrere verschiedene Kategorien getroffen werden:

Microsoft Graph Multi-Category Reconnaissance Burst erfasst systematische Aufzählungen nach einer Kompromittierung und filtert gleichzeitig die organische Portalnutzung heraus. Bei normaler Benutzeraktivität kann es vorkommen, dass eine oder zwei dieser Kategorien berührt werden. Das Auftreten von 4 oder mehr unterschiedlichen Aufklärungskategorien in einer einzigen Sitzung innerhalb eines kurzen Zeitfensters (33 Sekunden) ist der Fingerabdruck der automatisierten Werkzeuge.

Google - Kit-Relay- und Persistenzerkennung

Google Workspace Anmeldung bei unmöglichen Reisen - ES|QL-Regel unter Verwendung von *st_distance()* Geodatenfunktionen, um erfolgreiche Anmeldungen von Orten zu erkennen, die eine Reisegeschwindigkeit von mehr als 800 km/h und eine Entfernung von mindestens 500 km implizieren. Erkennt das Multi-ASN-Kit-Relay-Muster, bei dem mehrere IPs an verschiedenen geografischen Standorten denselben Benutzer innerhalb von Minuten authentifizieren:

Google Workspace-Benutzeranmeldung von atypischer ASN - neue Terminierungsregel , die erkennt, wann sich ein Google Workspace-Benutzer zum ersten Mal erfolgreich von einer bestimmten Quell-ASN innerhalb eines 14-tägigen historischen Fensters anmeldet.

Google Workspace Geräteregistrierung nach OAuth von verdächtiger ASN : EQL-Sequenzregel erkennt OAuth-Autorisierung für den Chrome-Client (77185425430.apps.googleusercontent.com) von einer billigen Hosting-ASN, gefolgt innerhalb von 30 Sekunden von einer Geräteregistrierung mit Kontostatus REGISTERED.

Google Workspace Geräteregistrierungs-Burst für einen einzelnen Benutzer - Erkennt Häufungen von Google Workspace Geräteregistrierungsereignissen für denselben Benutzer, bei denen innerhalb eines einminütigen Zeitfensters drei oder mehr unterschiedliche
google_workspace.device.id Werte ausgegeben werden:

Automatisierung der Eindämmung mit elastischen Workflows

Sobald die Erkennungsinhalte vorhanden sind, besteht die nächste Herausforderung in der Zeitspanne zwischen Alarmierung und Reaktion. Das von uns zuvor dokumentierte Übergabefenster des Tycoon 2FA M365 Kits an den Operator beträgt 10-20 Minuten. Dies ist die Zeitspanne zwischen der ersten erfolgreichen Token-Ausgabe des Kit-Relays und dem Beginn der Graph-Recon-Sitzung auf Operator-Ebene nach der Kompromittierung.

Eine manuelle SOC-Reaktion dauert in der Regel länger als dieses Zeitfenster, weshalb der Bediener vor dem Eindämmungseinsatz Aufklärungsarbeiten durchführen lässt. Erst durch das Schließen dieser Lücke wird die Erkennung handlungsfähig.

Elastic Workflows, das mit dem Stack ausgeliefert wird (9.4+), ermöglicht es Erkennungsregeln, bei jeder Warnung benutzerdefinierte Workflows mit einer in YAML definierten Pipeline von Schritten aufzurufen.

Als Proof of Concept haben wir einen benutzerdefinierten Workflow erstellt, der mit einer Entra ID Potential AiTM Sign-In via OfficeHome (Tycoon2FA) Erkennungsregel verknüpft ist, die die erforderlichen Reaktionsaktionen widerspiegelt.

Bei jeder Benachrichtigung wird folgender Workflow ausgeführt:

1. Erwirbt einen Graph-Bearer über client_credentials (einmal pro Ausführung).
2. Der kompromittierte UPN wird mit accountEnabled: false gepatcht, um neue Authentifizierungen zu verhindern.
3. Listet die registrierten Geräte und die Geräte im Besitz des Benutzers auf.
4. LÖSCHT jedes Geräteprinzipal, wodurch ein gerätegebundenes PRT tatsächlich ungültig wird.
5. POST-Anfragen an revokeSignInSessions werden gesendet, um benutzerbezogene Aktualisierungstoken und Sitzungscookies zu ungültig zu machen.
6. Öffnet einen Kibana-Fall, der mit dem Alarmkontext für die Nachbearbeitung des Incident Response (IR) (Passwortzurücksetzung, Überprüfung der Authentifizierungsmethode, OAuth-Grant-Audit) gefüllt ist.

Die Kette wird in weniger als 10 Sekunden von Anfang bis Ende gegen Microsoft Graph ausgeführt, also deutlich innerhalb des 10-20-minütigen Tycoon 2FA-Übergabefensters. Die Sitzung auf Bedienerebene erhält nie die Möglichkeit, mit der Aufklärung zu beginnen.

Das Muster lässt sich über diese eine Regel hinaus erweitern. Der gleiche Workflow eignet sich für jede Cloud-Identitätserkennung, die von einer sofortigen Eindämmung profitiert: AiTM-Anmeldungen, unmögliche Reisen, unzulässige OAuth-Zustimmungserteilungen, Rollenausweitung, MFA-Müdigkeit, anomale Geräteregistrierung. Verknüpfen Sie die Regel mit einem Workflow, der die entsprechende Cloud-API aufruft, und das SOC erhält eine Eindämmung auf Sekundenebene.

Verteidigung gegen Tycoon 2FA AiTM-Angriffe

• Setzen Sie auf phishingresistente MFA: FIDO2-Sicherheitsschlüssel und Passkeys sind die einzigen Methoden, die gegen AiTM-Sitzungsdiebstahl immun sind. TOTP, SMS und Push-basierte MFA können alle über einen Proxy abgewickelt werden.
• Gerätekonformität durch bedingten Zugriff erzwingen: Für die Token-Ausgabe müssen verwaltete, konforme Geräte erforderlich sein. Dies ist die mit Abstand wirksamste Kontrollmaßnahme gegen den Diebstahl von AiTM-Token.
• Codeflüsse für Blockgeräte: Die Block device code flow -Richtlinie für bedingten Zugriff weist das Kit-Relay in der Gewährungsphase sauber zurück (Fehler 53003). Aktivieren Sie diese Funktion für alle Benutzer außer in explizit genehmigten Kiosk-/Headless-Szenarien.
• Token-Schutz aktivieren (Token-Bindung): Bindet Token an das Gerät, für das sie ausgestellt wurden. Ein gestohlener Token, der von einem anderen Gerät aus wiedergegeben wird, wird zurückgewiesen.
• Kontinuierliche Zugriffsbewertung aktivieren (CAE): Tokenwiderruf nahezu in Echtzeit bei Änderung der Risikobedingungen.
• Sicherheitsvorgaben in Entra ID aktivieren (nur für Mandanten ohne benutzerdefinierten bedingten Zugriff): Veraltete Authentifizierungsmethoden wie ROPC werden standardmäßig abgelehnt und der Gerätecodefluss blockiert. Durch das Aktivieren von Sicherheitsstandardeinstellungen werden benutzerdefinierte CA-Richtlinien deaktiviert. Dies ist daher nicht auf Mandanten anwendbar, die bereits eine granulare CA verwenden.

MITRE ATT&CK-Mapping

Referenzen

• Microsoft Security Blog – Einblick in Tycoon2FA: Wie ein führendes AiTM-Phishing-Kit in großem Umfang operierte (März 2026)
• Tycoon 2FA Malware-Analyse, Übersicht von ANY.RUN
• Cloudflare – Tycoon 2FA-Abschaltung (März 2026)
• SpyCloud – Tycoon 2FA-AbschaltungEinblick in die globale Störung der Phishing-Infrastruktur (März 2026)
• eSentire - Tycoon 2FA-Betreiber setzen auf OAuth-Gerätecode-Phishing (Mai 2026)
• Sekoia - Tycoon 2FA: Eine detaillierte Analyse der neuesten Version des AiTM-Phishing-Kits (März 2024)