Microsoft 365: Angreifer umgehen MFA mit gestohlenen Anmelde-Token — so prüfen und schützen Sie Ihr Unternehmen
· Matthias Tichý
Das Wichtigste in 60 Sekunden
Was ist passiert?
Der Ablauf in vier Phasen
1. 14. Juli bis 3. August: Skriptgesteuerte Anmeldungen von einer einzelnen Adresse. Bis zum Ende dieser Phase waren 37 Organisationen betroffen und 37 gefälschte Geräte registriert. 2. Ab 17. August: Nach zwei Wochen Pause kamen Gerätecode-Phishing und das Löschen fremder MFA-Methoden hinzu. 3. 11. bis 14. September: Ein Ausbruch von einer neuen Adresse mit 303 erfolgreichen Anmeldungen in 29 Organisationen in vier Tagen. Gleichzeitig wurden 1.052 Versuche durch Richtlinien für bedingten Zugriff blockiert — aber nur in vier Organisationen. Dort, wo die Richtlinien passten, lief der Angriff ins Leere. 4. 2. bis 22. September: Anmeldungen über einen ganz normal aussehenden Browser, die im Protokoll kaum auffallen. Die letzte bekannte Übernahme am 22. September: Das Opfer bestätigte um 20:46 Uhr die MFA über die gefälschte Seite, um 20:50 Uhr nutzten die Angreifer die Sitzung. Die Angriffe kamen überwiegend aus dem Adressbereich193.26.115.0/24, den ein Hosting-Anbieter mit Sitz in Hamburg vermietet. Dass der Anbieter selbst beteiligt war, behauptet niemand — seine Server wurden genutzt. Einer bekannten Tätergruppe hat Huntress die Kampagne nicht zugeordnet. Bereits im Juni hatte Huntress eine ähnliche Token-Spraying-Welle über einen anderen Anbieter gemeldet. Das Muster ist also nicht einmalig.Ein Fall im Detail
Am 21. Juli um 17:18 Uhr meldete sich ein Opfer über die gefälschte Seite an. Zwölf Minuten später nutzten die Angreifer die Sitzung, um 17:43 Uhr ein zweites Mal von einer anderen Adresse. Um 18:08 Uhr war eine neue Authenticator-App mit dem Namen „iPhone 13“ als MFA-Methode des Opfers registriert. Ab diesem Moment konnten sich die Angreifer jederzeit selbst anmelden — auch nach einem Passwortwechsel.Wie Token-Replay funktioniert und warum MFA hier nicht reicht
Weg 1: Die gefälschte Anmeldeseite in der Mitte
Fachleute nennen das Adversary-in-the-Middle (AiTM). Das Opfer erhält eine Mail mit einem Link, etwa zu einem „geteilten Dokument“ oder einer „Rechnung“. Der Link führt auf eine Seite, die wie die Microsoft-Anmeldung aussieht und im Hintergrund tatsächlich mit Microsoft spricht: 1. Das Opfer gibt Benutzername und Passwort ein. Die Seite reicht beides an Microsoft weiter. 2. Microsoft verlangt den zweiten Faktor. Das Opfer bestätigt die Push-Nachricht oder tippt den Code ein — alles wirkt normal. 3. Microsoft stellt die Token aus. Die gefälschte Seite leitet das Opfer weiter, behält aber eine Kopie. Die MFA hat funktioniert — nur eben auch für den Angreifer.Weg 2: Der Gerätecode-Trick
Der Gerätecode-Fluss (Device Code Flow) ist für Geräte ohne Tastatur gedacht, etwa Konferenzraum-Systeme: Das Gerät zeigt einen Code an, den man auf einem anderen Gerät unter microsoft.com/devicelogin eingibt. Angreifer drehen das um. Sie erzeugen selbst einen Code und schicken ihn dem Opfer, zum Beispiel mit der Bitte, sich „für ein Teams-Meeting zu verifizieren“. Das Opfer gibt den Code auf der echten Microsoft-Seite ein, meldet sich korrekt mit MFA an — und autorisiert damit das Gerät des Angreifers. Da die Seite wirklich von Microsoft stammt, hilft hier auch der geschulte Blick auf die Adresszeile nicht.Token-Spraying: viele gestohlene Sitzungen auf einmal
Huntress nennt die Kampagne „Token-Spraying“: dasselbe Muster wie beim Password-Spraying, nur mit gestohlenen Token statt erratener Passwörter. Die Angreifer spielten gesammelte Token automatisiert gegen viele Firmen-Tenants ein und wechselten dabei zwischen sechs Adressen. Eine einzelne Adresse zu sperren, hätte höchstens eine Phase gestoppt. Huntress unterscheidet zwei Werkzeuge: • Skript: User-Agentnode oder nur Mozilla/5.0, Anmeldung über die Microsoft-Office-App oder den Microsoft Authentication Broker, Ziele Microsoft Graph, Exchange Online, SharePoint Online und der Geräteregistrierungsdienst.
• Browser: aktueller Chrome oder Edge unter Windows, Ziel OfficeHome und Exchange Online. Im Protokoll kaum von normaler Nutzung zu unterscheiden.Warum ein neues Passwort allein nicht hilft
Ein Passwort-Reset ändert nichts an den Geräten und MFA-Methoden, die der Angreifer inzwischen registriert hat. Mit seiner eigenen Authenticator-App kommt er wieder herein. Erst wenn auch die Sitzungen widerrufen und die fremden Methoden und Geräte entfernt sind, ist die Tür zu. Beim Widerruf hilft Microsofts kontinuierliche Zugriffsevaluierung (Continuous Access Evaluation, CAE): Exchange Online, SharePoint Online und Teams werden über Sperrungen, Passwortwechsel und widerrufene Sitzungen informiert und setzen sie laut Microsoft nahezu in Echtzeit um — mit bis zu 15 Minuten Verzögerung. Andere Dienste akzeptieren ein bereits ausgestelltes Zugriffstoken bis zu seinem Ablauf, in der Regel eine Stunde.Was die Angreifer nach der Übernahme tun
DESKTOP- plus acht Hex-Zeichen (zum Beispiel DESKTOP-54521F46) wurden im Entra-Verzeichnis angemeldet. Windows selbst vergibt standardmäßig sieben Zeichen — die acht sind ein brauchbares Unterscheidungsmerkmal.
• MFA übernehmen: Die vorhandenen MFA-Methoden wurden gelöscht und durch eine eigene Authenticator-App ersetzt. In einem Fall nutzten die Angreifer eine bereits vorhandene, keinem Gerät zugeordnete Authenticator-Registrierung.
• Mails verstecken: Inbox-Regeln mit Namen wie ., ,., s, d, ss, sss, iT oder ........ verschoben Mails in selten geöffnete Ordner wie „RSS-Feeds“, „RSS-Abonnements“ oder „Unterhaltungsverlauf“ oder löschten sie. Gezielt abgefangen wurden Mails mit Begriffen wie Gehalt, Lohn, Einzahlung oder Bonus. Angelegt wurden die Regeln teils über VPN-Dienste und gemietete Server, teils über die Outlook-Programmierschnittstelle.
• Betrug vorbereiten: In einem Fall verbarg eine Regel alle Mails eines externen Steuerberaters, an den die Angreifer dann eine Lohn-bezogene Mail schickten. In einem anderen registrierten sie eine Domain, die der eines Geschäftspartners zum Verwechseln ähnlich sah.
• Spam versenden: Ein Postfach verschickte Spam an Hunderte externe Empfänger, bevor Microsoft das Konto als hochriskant markierte.
Das Ziel ist selten das Postfach selbst, sondern das Geld: geänderte Bankverbindungen auf Rechnungen, umgeleitete Gehaltszahlungen, gefälschte Zahlungsanweisungen.Vorbereitung: Was Sie für die Prüfung brauchen
Module und Rechte
Wir empfehlen PowerShell 7 (winget install Microsoft.PowerShell). Die Befehle verwenden Module von Microsoft aus der PowerShell Gallery. Statt des riesigen Gesamtpakets Microsoft.Graph installiert der folgende Block nur die Teilmodule, die für die Prüfung gebraucht werden — und nur, wenn sie noch fehlen. Administratorrechte auf dem PC sind dafür nicht nötig:$module = @(
'Microsoft.Graph.Authentication'
'Microsoft.Graph.Users'
'Microsoft.Graph.Users.Actions'
'Microsoft.Graph.Identity.DirectoryManagement'
'Microsoft.Graph.Identity.SignIns'
'Microsoft.Graph.Reports'
'Microsoft.Graph.Applications'
'Microsoft.Graph.Beta.Reports'
'ExchangeOnlineManagement'
)
foreach ($m in $module) {
if (-not (Get-Module -ListAvailable -Name $m)) {
Install-Module -Name $m -Scope CurrentUser -Repository PSGallery -Force
}
}
Get-InstalledModule -Name 'Microsoft.Graph.*' | Format-Table Name, Version -AutoSizeName Version
---- -------
Microsoft.Graph.Applications 2.32.0
Microsoft.Graph.Authentication 2.32.0
Microsoft.Graph.Beta.Reports 2.32.0
Microsoft.Graph.Identity.DirectoryManagement 2.32.0
Microsoft.Graph.Identity.SignIns 2.32.0
Microsoft.Graph.Reports 2.32.0
Microsoft.Graph.Users 2.32.0
Microsoft.Graph.Users.Actions 2.32.0Typische Stolperfallen bei der Installation
• Unterschiedliche Versionen: Sind ältere Graph-Module vorhanden, meldetConnect-MgGraph oft Fehler wie „Could not load file or assembly“. Dann alle Module mit Update-Module -Name 'Microsoft.Graph.*' auf denselben Stand bringen und PowerShell neu starten.
• Windows PowerShell 5.1: Dort blockiert die Ausführungsrichtlinie oft das Laden der Module. Abhilfe schafft einmalig Set-ExecutionPolicy -Scope CurrentUser RemoteSigned — oder eben PowerShell 7.
• Die Versionsnummer in der Beispielausgabe ändert sich laufend; entscheidend ist nur, dass sie überall gleich ist.
Jeder Befehlsblock in den folgenden Schritten lädt seine Module selbst und meldet sich mit genau den Rechten an, die er braucht. Sie können die Schritte also einzeln und in beliebiger Reihenfolge ausführen. Beim ersten Connect-MgGraph öffnet sich ein Anmeldefenster; einmalig müssen Sie (oder ein Globaler Administrator) den angeforderten Berechtigungen für „Microsoft Graph Command Line Tools“ zustimmen.
Als Rolle genügt für die Graph-Abfragen „Globaler Leser“ (Global Reader). Für die Inbox-Regeln in Exchange Online brauchen Sie einen Exchange-Administrator — Get-InboxRule funktioniert laut Microsoft ausdrücklich nicht mit der Rolle „Globaler Leser“.Lizenzen und Aufbewahrungsfristen
Das ist der Punkt, den viele übersehen: • Anmeldeprotokolle per PowerShell abrufen geht nur mit Microsoft Entra ID P1 oder P2, enthalten zum Beispiel in Microsoft 365 Business Premium, E3 und E5. In Business Basic und Business Standard sehen Sie die Protokolle nur im Portal. • Anmelde- und Audit-Protokolle von Entra bewahrt Microsoft ohne P1 sieben Tage auf, mit P1 oder P2 dreißig Tage. • Das einheitliche Überwachungsprotokoll (Unified Audit Log) mit Exchange-Aktivitäten wie neuen Inbox-Regeln reicht in der Standardversion 180 Tage zurück. Die Kampagne endete laut Huntress am 22. September. Ihre Anmeldungen sind in den meisten Tenants also schon aus den Entra-Protokollen verschwunden — es sei denn, Sie leiten die Protokolle in einen Log-Analytics-Arbeitsbereich oder ein SIEM weiter. Die Spuren, die die Angreifer hinterlassen haben, bleiben aber: registrierte Geräte, fremde Authenticator-Apps und Inbox-Regeln. Darauf liegt deshalb der Schwerpunkt.Sind wir betroffen? Tenant mit PowerShell prüfen
name@firma.de durch Ihre eigenen.Schritt 1: Gefälschte Geräte finden
Sucht nach Geräten, deren Name genau dem MusterDESKTOP- plus acht Hex-Zeichen entspricht, und zeigt den registrierten Besitzer:Import-Module Microsoft.Graph.Authentication, Microsoft.Graph.Identity.DirectoryManagement
Connect-MgGraph -Scopes 'Device.Read.All' -NoWelcome
Get-MgDevice -All -Property Id,DisplayName,RegistrationDateTime,TrustType,OperatingSystem |
Where-Object { $_.DisplayName -cmatch '^DESKTOP-[0-9A-F]{8}$' } |
Sort-Object RegistrationDateTime |
ForEach-Object {
$owner = Get-MgDeviceRegisteredOwner -DeviceId $_.Id | Select-Object -First 1
[pscustomobject]@{
Geraet = $_.DisplayName
Registriert = $_.RegistrationDateTime
Typ = $_.TrustType
Besitzer = $owner.AdditionalProperties['userPrincipalName']
}
} | Format-Table -AutoSizeGeraet Registriert Typ Besitzer
------ ----------- --- --------
DESKTOP-BAF88EF4 21.07.2026 18:02:17 Workplace buchhaltung@firma.deWorkplace bedeutet „registriert“, also kein von Ihnen eingerichteter Firmenrechner. Keine Ausgabe heißt: kein Gerät mit diesem Muster.
Für die Gegenprobe lohnt ein Blick auf alle Geräte, die in den letzten 120 Tagen registriert wurden:Import-Module Microsoft.Graph.Authentication, Microsoft.Graph.Identity.DirectoryManagement
Connect-MgGraph -Scopes 'Device.Read.All' -NoWelcome
$seit = (Get-Date).AddDays(-120)
Get-MgDevice -All -Property DisplayName,RegistrationDateTime,TrustType,OperatingSystem |
Where-Object { $_.RegistrationDateTime -ge $seit } |
Sort-Object RegistrationDateTime |
Format-Table DisplayName, RegistrationDateTime, TrustType, OperatingSystem -AutoSizeSchritt 2: Fremde Authenticator-Apps finden
Listet für alle aktiven Benutzer die registrierten Microsoft-Authenticator-Apps auf, neueste zuerst. Bei vielen Benutzern dauert das einige Minuten:Import-Module Microsoft.Graph.Authentication, Microsoft.Graph.Users, Microsoft.Graph.Identity.SignIns
Connect-MgGraph -Scopes 'User.Read.All','UserAuthenticationMethod.Read.All' -NoWelcome
Get-MgUser -All -Filter 'accountEnabled eq true' -Property Id,UserPrincipalName |
ForEach-Object {
$upn = $_.UserPrincipalName
Get-MgUserAuthenticationMethodMicrosoftAuthenticator -UserId $_.Id |
Select-Object @{n='Benutzer';e={$upn}}, DisplayName, CreatedDateTime
} |
Sort-Object CreatedDateTime -Descending |
Format-Table -AutoSizeBenutzer DisplayName CreatedDateTime
-------- ----------- ---------------
buchhaltung@firma.de iPhone 13 21.07.2026 18:08:50
chefin@firma.de Pixel 9 03.05.2026 09:14:02
buchhaltung@firma.de Galaxy S24 12.01.2026 08:41:10DisplayName ist der Gerätename, den die App bei der Einrichtung meldet. Auffällig sind Geräte, die der Mitarbeiter nicht besitzt, und mehrere Apps beim selben Benutzer — wie hier bei der Buchhaltung.Schritt 3: Gelöschte und neu registrierte MFA-Methoden
Das typische Muster der Kampagne: Methoden werden gelöscht und kurz darauf wird eine neue registriert. Dieser Befehl liest die Audit-Einträge der letzten 30 Tage und meldet jeden Benutzer, bei dem innerhalb von drei Stunden nach einer Löschung eine neue Methode hinzukam:Import-Module Microsoft.Graph.Authentication, Microsoft.Graph.Reports
Connect-MgGraph -Scopes 'AuditLog.Read.All' -NoWelcome
$seit = (Get-Date).ToUniversalTime().AddDays(-30).ToString('yyyy-MM-ddTHH:mm:ssZ')
$filter = "activityDateTime ge $seit and (activityDisplayName eq 'User deleted security info' or activityDisplayName eq 'Admin deleted security info' or activityDisplayName eq 'User registered security info')"
$events = Get-MgAuditLogDirectoryAudit -All -Filter $filter
$events | Group-Object { $_.TargetResources[0].UserPrincipalName } | ForEach-Object {
$benutzer = $_.Name
$geloescht = $_.Group | Where-Object ActivityDisplayName -like '*deleted security info'
$neu = $_.Group | Where-Object ActivityDisplayName -eq 'User registered security info'
foreach ($d in $geloescht) {
foreach ($r in $neu) {
$minuten = ($r.ActivityDateTime - $d.ActivityDateTime).TotalMinutes
if ($minuten -ge 0 -and $minuten -le 180) {
[pscustomobject]@{
Benutzer = $benutzer
Geloescht = $d.ActivityDateTime
Neu = $r.ActivityDateTime
Minuten = [int]$minuten
IP = $r.InitiatedBy.User.IPAddress
}
}
}
}
} | Format-Table -AutoSizeBenutzer Geloescht Neu Minuten IP
-------- --------- --- ------- --
buchhaltung@firma.de 17.09.2026 14:02:11 17.09.2026 14:09:47 8 193.26.115.16Schritt 4: Anmeldungen von bekannten Angreifer-Adressen
Der wichtigste Unterschied zu vielen Anleitungen im Netz: Die Graph-Schnittstelle in Version 1.0 liefert nur interaktive Anmeldungen und kennt weder User-Agent noch Anmeldeprotokoll. Token-Replay taucht aber vor allem bei den nicht-interaktiven Anmeldungen auf. Deshalb nutzt dieser Befehl die Beta-Schnittstelle und fragt beide Arten ausdrücklich ab:Import-Module Microsoft.Graph.Authentication, Microsoft.Graph.Beta.Reports
Connect-MgGraph -Scopes 'AuditLog.Read.All' -NoWelcome
$seit = (Get-Date).ToUniversalTime().AddDays(-30).ToString('yyyy-MM-ddTHH:mm:ssZ')
$adressen = '193.26.115.', '124.198.132.33', '45.83.31.44', '192.159.99.172', '185.238.2.195', '167.148.41.96'
foreach ($a in $adressen) {
$filter = "createdDateTime ge $seit and startsWith(ipAddress,'$a') and signInEventTypes/any(t: t eq 'interactiveUser' or t eq 'nonInteractiveUser')"
Get-MgBetaAuditLogSignIn -All -Filter $filter |
Select-Object CreatedDateTime, UserPrincipalName, IPAddress, AppDisplayName, ResourceDisplayName, UserAgent,
@{n='Fehlercode';e={$_.Status.ErrorCode}}
} | Sort-Object CreatedDateTime | Format-Table -AutoSize0 bedeutet eine erfolgreiche Anmeldung. Keine Ausgabe heißt: In den letzten 30 Tagen gab es keine Anmeldung von diesen Adressen. Die Adressen stammen aus dem Huntress-Bericht. Neue Wellen kommen erfahrungsgemäß von neuen Adressen, deshalb ist Schritt 5 mindestens genauso wichtig.Schritt 5: Verdächtige Muster unabhängig von der Adresse
Lädt alle Anmeldungen der letzten sieben Tage und prüft sie auf drei Merkmale aus der Kampagne. In größeren Tenants kann der Abruf einige Minuten dauern:Import-Module Microsoft.Graph.Authentication, Microsoft.Graph.Beta.Reports
Connect-MgGraph -Scopes 'AuditLog.Read.All' -NoWelcome
$seit = (Get-Date).ToUniversalTime().AddDays(-7).ToString('yyyy-MM-ddTHH:mm:ssZ')
$filter = "createdDateTime ge $seit and signInEventTypes/any(t: t eq 'interactiveUser' or t eq 'nonInteractiveUser')"
$anmeldungen = Get-MgBetaAuditLogSignIn -All -Filter $filter
$spalten = 'CreatedDateTime', 'UserPrincipalName', 'IPAddress', 'AppDisplayName', 'UserAgent'
# 1. Skript-Werkzeug: User-Agent 'node' oder nur 'Mozilla/5.0'
$anmeldungen | Where-Object { $_.UserAgent -in 'node', 'Mozilla/5.0' } | Format-Table $spalten -AutoSize
# 2. Gerätecode-Anmeldungen
$anmeldungen | Where-Object { $_.AuthenticationProtocol -eq 'deviceCode' -or $_.OriginalTransferMethod -eq 'deviceCodeFlow' } | Format-Table $spalten -AutoSize
# 3. Richtig angemeldet, aber vom bedingten Zugriff blockiert
$anmeldungen | Where-Object { $_.Status.ErrorCode -eq 53003 } | Format-Table $spalten -AutoSizenode hat bei einer normalen Anmeldung nichts zu suchen. Jeder Treffer ist verdächtig.
2. Gerätecode-Anmeldungen sind nur bei Konferenzraum-Systemen, manchen Druckern oder Admin-Werkzeugen normal. Taucht ein Büro-Mitarbeiter auf, nachfragen.
3. Fehlercode 53003 heißt: Passwort und MFA waren korrekt, erst der bedingte Zugriff hat blockiert. Huntress betont, dass das ein Zeichen für gültige Zugangsdaten in fremder Hand sein kann. Häufig sind es aber auch Mitarbeiter auf privaten Geräten — entscheidend sind Ort und IP-Adresse.Schritt 6: Inbox-Regeln und Weiterleitungen prüfen
Jetzt geht es zu Exchange Online. Der Schalter-IncludeHidden zeigt auch versteckte Regeln:Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline -ShowBanner:$false
$ordner = 'RSS|Unterhaltungsverlauf|Conversation History'
Get-EXOMailbox -ResultSize Unlimited | ForEach-Object {
Get-InboxRule -Mailbox $_.UserPrincipalName -IncludeHidden
} | Where-Object {
$_.Name.Trim().Length -le 3 -or
$_.Name -notmatch '[a-zA-Z0-9]' -or
$_.MoveToFolder -match $ordner -or
$_.DeleteMessage -or
$_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo
} | Select-Object MailboxOwnerId, Name, Enabled, MoveToFolder, DeleteMessage, MarkAsRead,
ForwardTo, RedirectTo, SubjectOrBodyContainsWordsMailboxOwnerId : Buchhaltung
Name : ,.
Enabled : True
MoveToFolder : Buchhaltung:\RSS-Feeds
DeleteMessage : False
MarkAsRead : True
ForwardTo :
RedirectTo :
SubjectOrBodyContainsWords : {Gehalt, Lohn, Bankverbindung, Überweisung}Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline -ShowBanner:$false
Get-EXOMailbox -ResultSize Unlimited -Properties ForwardingSmtpAddress,ForwardingAddress,DeliverToMailboxAndForward |
Where-Object { $_.ForwardingSmtpAddress -or $_.ForwardingAddress } |
Format-Table UserPrincipalName, ForwardingSmtpAddress, ForwardingAddress, DeliverToMailboxAndForward -AutoSizeSchritt 7: Wann und von wo Regeln angelegt wurden
Das einheitliche Überwachungsprotokoll reicht 180 Tage zurück und deckt damit den gesamten Zeitraum der Kampagne ab. Es zeigt, wer wann von welcher Adresse eine Regel angelegt oder geändert hat — auch Regeln, die über Outlook entstanden sind (UpdateInboxRules):Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline -ShowBanner:$false
$operationen = 'New-InboxRule', 'Set-InboxRule', 'UpdateInboxRules'
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-120) -EndDate (Get-Date) -Operations $operationen -ResultSize 5000 |
ForEach-Object {
$d = $_.AuditData | ConvertFrom-Json
[pscustomobject]@{
Zeit = $_.CreationDate
Benutzer = $_.UserIds
Aktion = $_.Operations
IP = if ($d.ClientIP) { $d.ClientIP } else { $d.ClientIPAddress }
}
} | Sort-Object Zeit | Format-Table -AutoSizeSchritt 8: App-Berechtigungen und Schutzeinstellungen
Apps, denen einzelne Benutzer Zugriff auf ihre Daten gegeben haben:Import-Module Microsoft.Graph.Authentication, Microsoft.Graph.Identity.SignIns, Microsoft.Graph.Applications, Microsoft.Graph.Users
Connect-MgGraph -Scopes 'Directory.Read.All' -NoWelcome
Get-MgOauth2PermissionGrant -All | Where-Object ConsentType -eq 'Principal' | ForEach-Object {
$app = Get-MgServicePrincipal -ServicePrincipalId $_.ClientId
$user = Get-MgUser -UserId $_.PrincipalId -Property UserPrincipalName
[pscustomobject]@{
App = $app.DisplayName
Herausgeber = $app.PublisherName
Benutzer = $user.UserPrincipalName
Rechte = $_.Scope
}
} | Format-Table -AutoSize -WrapMail.Read, Mail.Send oder offline_access genau ansehen.
Zum Schluss ein Blick auf den Schutz: Sind die Sicherheitsstandards aktiv, welche Richtlinien für bedingten Zugriff gibt es, und sperrt eine davon den Gerätecode-Fluss?Import-Module Microsoft.Graph.Authentication, Microsoft.Graph.Identity.SignIns
Connect-MgGraph -Scopes 'Policy.Read.All' -NoWelcome
"Sicherheitsstandards aktiv: " + (Get-MgPolicyIdentitySecurityDefaultEnforcementPolicy).IsEnabled
Get-MgIdentityConditionalAccessPolicy -All |
Select-Object DisplayName, State,
@{n='Authentifizierungsfluss';e={$_.Conditions.AuthenticationFlows.TransferMethods}},
@{n='Gewaehrung';e={$_.GrantControls.BuiltInControls -join ', '}} |
Format-Table -AutoSizeSicherheitsstandards aktiv: False
DisplayName State Authentifizierungsfluss Gewaehrung
----------- ----- ----------------------- ----------
MFA fuer alle Benutzer enabled mfa
Geraetecode blockieren enabledForReportingButNotEnforced deviceCodeFlow blockenabledForReportingButNotEnforced) — sie protokolliert, blockiert aber nichts. Steht nirgends deviceCodeFlow mit block und Status enabled, ist der Gerätecode-Fluss offen.Was ein Treffer bedeutet
Eine einzelne Auffälligkeit ist noch kein Beweis. Trifft aber mehr als ein Punkt auf dasselbe Konto zu — etwa ein neues Gerät plus eine neue Authenticator-App plus eine merkwürdige Inbox-Regel —, behandeln Sie das Konto als übernommen.Wenn ein Konto übernommen wurde: Sofortmaßnahmen
1. Konto sperren und Sitzungen widerrufen
Import-Module Microsoft.Graph.Authentication, Microsoft.Graph.Users, Microsoft.Graph.Users.Actions
Connect-MgGraph -Scopes 'User.ReadWrite.All','User.RevokeSessions.All' -NoWelcome
$upn = 'name@firma.de'
Update-MgUser -UserId $upn -AccountEnabled:$false
Revoke-MgUserSignInSession -UserId $upn2. Fremde MFA-Methoden entfernen
Erst anzeigen, dann gezielt die fremde App löschen. DieId übernehmen Sie aus der ersten Ausgabe:Import-Module Microsoft.Graph.Authentication, Microsoft.Graph.Identity.SignIns
Connect-MgGraph -Scopes 'UserAuthenticationMethod.ReadWrite.All' -NoWelcome
$upn = 'name@firma.de'
Get-MgUserAuthenticationMethodMicrosoftAuthenticator -UserId $upn |
Format-Table Id, DisplayName, CreatedDateTime -AutoSize
Remove-MgUserAuthenticationMethodMicrosoftAuthenticator -UserId $upn -MicrosoftAuthenticatorAuthenticationMethodId '<Id>'3. Fremde Geräte deaktivieren
Deaktivieren statt löschen, damit die Spuren für die Analyse erhalten bleiben. Die Objekt-ID stammt aus Schritt 1 der Prüfung (Get-MgDevice … | Select-Object Id, DisplayName):Import-Module Microsoft.Graph.Authentication, Microsoft.Graph.Identity.DirectoryManagement
Connect-MgGraph -Scopes 'Directory.AccessAsUser.All' -NoWelcome
Update-MgDevice -DeviceId '<Objekt-ID>' -AccountEnabled:$false4. Inbox-Regeln und Weiterleitungen entfernen
Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline -ShowBanner:$false
$upn = 'name@firma.de'
Get-InboxRule -Mailbox $upn -IncludeHidden | Format-Table Name, Identity, MoveToFolder, DeleteMessage -AutoSize
Remove-InboxRule -Mailbox $upn -Identity '<Identity>' -Confirm:$false
Set-Mailbox -Identity $upn -ForwardingSmtpAddress $null -ForwardingAddress $null5. Aufräumen und wieder freigeben
1. App-Berechtigungen prüfen (Schritt 8 der Prüfung) und unbekannte Apps entfernen. 2. Neues, langes Passwort setzen — erst jetzt, wenn alle Hintertüren geschlossen sind. 3. MFA gemeinsam mit dem Mitarbeiter neu einrichten, dann das Konto wieder freigeben (Update-MgUser -UserId $upn -AccountEnabled:$true).
4. Gesendete Mails auswerten: Was hat das Konto in der Zeit verschickt? Geschäftspartner, die Zahlungsaufforderungen oder geänderte Bankdaten erhalten haben könnten, aktiv warnen.
5. Prüfen, ob dieselbe IP-Adresse auch bei anderen Konten auftaucht.Meldepflichten nicht vergessen
Hatten die Angreifer Zugriff auf ein Postfach mit personenbezogenen Daten, liegt in aller Regel eine Datenschutzverletzung vor. Diese ist nach Art. 33 DSGVO innerhalb von 72 Stunden der zuständigen Aufsichtsbehörde zu melden, es sei denn, sie führt voraussichtlich nicht zu einem Risiko für die Betroffenen. Dokumentieren Sie Zeitpunkt, Umfang und Maßnahmen von Anfang an.So schützen Sie sich dauerhaft
1. Phishing-resistente Anmeldung einführen
Der wirksamste Schutz gegen gefälschte Anmeldeseiten. Passkeys (FIDO2), Sicherheitsschlüssel, Windows Hello for Business und zertifikatbasierte Anmeldung sind kryptografisch an die echte Microsoft-Adresse gebunden. Auf einer gefälschten Seite funktionieren sie nicht — der Mitarbeiter kann sich dort gar nicht anmelden, selbst wenn er die Täuschung nicht erkennt. Im bedingten Zugriff setzen Sie das mit „Require authentication strength“ und der eingebauten Stärke „Phishing-resistant MFA“ durch. Fangen Sie mit Administratoren und der Buchhaltung an. Passkeys lassen sich auch in der Microsoft-Authenticator-App speichern, ein separater Schlüssel ist nicht zwingend nötig. Die Anmeldung per Authenticator-Push zählt dagegen nicht als phishing-resistent.2. Nur verwaltete Geräte zulassen
Eine Richtlinie, die ein konformes Gerät verlangt (Require device to be marked as compliant), lässt gestohlene Token auf fremden Rechnern ins Leere laufen. Ein Gerät, das der Angreifer selbst registriert, ist dadurch nicht automatisch konform — dafür muss es über Intune verwaltet sein und Ihre Vorgaben erfüllen. Microsoft nennt diese Richtlinie ausdrücklich als Grundbaustein gegen Token-Diebstahl.3. Gerätecode-Fluss sperren
Microsoft empfiehlt, den Gerätecode-Fluss so weit wie möglich zu blockieren. Im bedingten Zugriff unter Conditions > Authentication flows die Option „Device code flow“ wählen und „Block access“ setzen. Zuerst im Modus „Report-only“ einschalten und prüfen, ob legitime Nutzung auftaucht, etwa bei Konferenzraum-Systemen. Notfallkonten ausnehmen. Schritt 8 der Prüfung zeigt, ob die Sperre wirklich aktiv ist.4. Geräte- und MFA-Registrierung absichern
Genau diese beiden Schritte haben die Angreifer genutzt, um sich festzusetzen: • Unter Entra ID > Devices > Device settings festlegen, dass nur ausgewählte Benutzer Geräte in Entra einbinden dürfen. • Eine Richtlinie für die Benutzeraktion „Register security information“ anlegen, die neue MFA-Methoden nur aus dem Firmennetz oder von verwalteten Geräten erlaubt. • Eine Richtlinie für die Benutzeraktion „Register or join devices“ anlegen und dafür eine starke Anmeldung verlangen.5. Riskante Anmeldungen automatisch stoppen
Mit Microsoft Entra ID P2 (zum Beispiel in E5 oder als Zusatz) bewertet ID Protection jede Anmeldung. Für Token-Diebstahl relevant sind die Erkennungen „Anomalous Token“, „Attacker in the Middle“ und „Unfamiliar sign-in properties“. Microsoft empfiehlt zwei Richtlinien: bei mittlerem oder hohem Anmelderisiko eine erneute phishing-resistente Anmeldung verlangen, bei hohem Benutzerrisiko blockieren oder ein sicheres Zurücksetzen erzwingen. Eine gestohlene Sitzung scheitert dann an der erneuten Anmeldung.6. Token-Schutz aktivieren, wo möglich
Token Protection ist eine Sitzungssteuerung im bedingten Zugriff, die nur noch Token akzeptiert, die kryptografisch an das Gerät gebunden sind. Ein gestohlenes Token funktioniert dann auf einem anderen Rechner nicht. Für native Anwendungen wie Outlook, Teams und OneDrive ist das unter Windows, macOS und iOS verfügbar und lässt sich für Exchange Online, SharePoint Online und Teams erzwingen. Apple-Geräte müssen dafür per MDM verwaltet sein und das Microsoft Enterprise SSO-Plug-in nutzen. Browser-Sitzungen deckt Token Protection bisher nur in einer Vorschau für wenige Azure-Anwendungen ab — gegen das Abgreifen über den Browser hilft also vor allem Punkt 1. Microsoft empfiehlt, mit einer Pilotgruppe im Modus „Report-only“ zu starten.7. Zugriff an das Firmennetz binden
Wer feste Internetadressen hat, kann den Zugriff per Standort-Richtlinie auf diese Adressen beschränken. Exchange Online und SharePoint Online setzen solche Richtlinien dank CAE sofort durch: Ein Token, das von außerhalb benutzt wird, wird abgewiesen. Für mobile Mitarbeiter ist das allerdings nur mit VPN oder Microsofts Global Secure Access praktikabel.8. Zustimmung zu Apps einschränken
Unter Enterprise applications > Consent and permissions festlegen, dass Benutzer nur noch Apps verifizierter Herausgeber mit geringen Berechtigungen zustimmen dürfen — oder gar keinen. So kann ein Angreifer nicht über eine eigene App dauerhaft Zugriff behalten.9. Protokolle länger aufbewahren
30 Tage reichen nicht, um eine Kampagne wie diese nachträglich aufzuklären. Leiten Sie Anmelde- und Audit-Protokolle über die Diagnoseeinstellungen von Entra in einen Log-Analytics-Arbeitsbereich oder ein SIEM weiter. Mit Microsoft Defender XDR erkennt die automatische Angriffsunterbrechung AiTM-Angriffe zudem früh und sperrt betroffene Konten selbstständig.Ohne Entra ID P1: Was trotzdem geht
Mit Business Basic oder Business Standard steht der bedingte Zugriff nicht zur Verfügung. Dann gilt: • Sicherheitsstandards (Security Defaults) eingeschaltet lassen — sie erzwingen MFA, ersetzen aber keine der obigen Richtlinien. • In den Authentifizierungsmethoden Passkeys aktivieren und Mitarbeiter darauf umstellen. • Die Prüfungen 1, 2, 6 und 7 von oben funktionieren auch ohne P1 — führen Sie sie regelmäßig durch, zum Beispiel monatlich. • Ernsthaft über ein Upgrade auf Business Premium nachdenken. Der Aufpreis ist meist deutlich geringer als der Schaden durch eine einzige umgeleitete Zahlung.Was Ihre Mitarbeiter wissen sollten
Fazit
Quellen
Microsoft 365 prüfen lassen?
Wir prüfen Ihren Microsoft-365-Tenant auf Spuren dieser Angriffe, richten bedingten Zugriff, Passkeys und Token-Schutz ein und helfen sofort, wenn ein Konto übernommen wurde.
Jetzt Kontakt aufnehmenTransparenzhinweis: Die Inhalte dieses Beitrags wurden mit Unterstützung von künstlicher Intelligenz erstellt und von uns redaktionell geprüft.
Matthias Tichý
IT-Berater und Gründer von IT-Service M.Tichý in Berlin-Spandau. Seit 2010 betreut er kleine und mittlere Unternehmen in Berlin und Brandenburg bei Microsoft 365, IT-Sicherheit, Backup und Managed Services.