Zum Hauptinhalt springen
Alle Beiträge

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 passiert ist: Das Sicherheitsunternehmen Huntress hat eine Kampagne gegen Microsoft-365-Konten dokumentiert. Zwischen dem 14. Juli und dem 22. September 2026 zählte es 497 erfolgreiche Anmeldungen in 79 Organisationen, dazu über 200.000 fehlgeschlagene Versuche. • Wie: Die Opfer meldeten sich auf einer täuschend echten Login-Seite an, die alles an Microsoft weiterreichte — auch die MFA-Bestätigung. Die Angreifer behielten das Anmelde-Token und nutzten es teils nur vier Minuten später von eigenen Servern aus. • Danach: eigene Geräte im Firmenverzeichnis registriert, MFA-Methoden der Opfer gelöscht und ersetzt, versteckte Inbox-Regeln angelegt, Lohn- und Zahlungsmails abgefangen. • Warum das alle betrifft: MFA per Push, Code oder SMS schützt nicht gegen diese Methode. Das ist kein Fehler bei Microsoft, sondern eine Schwäche dieser MFA-Verfahren. • Wichtig für die Prüfung: Microsoft bewahrt Anmeldeprotokolle nur 7 bzw. 30 Tage auf. Wer Spuren aus dem Sommer sucht, muss auf das Überwachungsprotokoll von Exchange ausweichen — und sollte ab jetzt regelmäßig prüfen. • Was jetzt zu tun ist: Tenant mit den PowerShell-Befehlen unten prüfen, den Gerätecode-Fluss sperren, Geräte- und MFA-Registrierung absichern und schrittweise auf phishing-resistente Anmeldung (Passkeys, Windows Hello for Business) umstellen.

Was ist passiert?

Am 22. Oktober 2026 hat Huntress einen ausführlichen Bericht über eine Angriffswelle veröffentlicht, die das Unternehmen bei seinen Kunden beobachtet hat. Fachmedien wie The Hacker News und Daily CyberSecurity haben das Thema aufgegriffen. Die Eckdaten laut Huntress: • 79 betroffene Organisationen, 497 erfolgreiche Anmeldungen der Angreifer • über 200.000 fehlgeschlagene Anmeldeversuche aus demselben Adressbereich • mindestens 48 gefälschte Geräte, die in den Verzeichnissen der Opfer registriert wurden • in 19 Organisationen wurden die MFA-Methoden der Opfer innerhalb von drei Stunden nach der ersten Anmeldung gelöscht und ersetzt

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 Adressbereich 193.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.
Zeitleiste der Kampagne vom 14. Juli bis 22. September 2026 mit vier Phasen: Skript-Replay, Pause, Gerätecode-Phishing und MFA-Übernahme, Browser-Replay und ein Ausbruch mit 303 Anmeldungen in vier Tagen
Die Kampagne in vier Phasen. Quelle: Huntress, 22. Oktober 2026
Zeitstrahl des Falls vom 21. Juli 2026: 17:18 Anmeldung über die gefälschte Seite, 17:30 Angreifer nutzen die Sitzung, 17:43 zweiter Zugriff, 18:08 eigene Authenticator-App registriert
Der Fall vom 21. Juli: Nach 50 Minuten hatten die Angreifer einen dauerhaften Zugang.

Wie Token-Replay funktioniert und warum MFA hier nicht reicht

Wenn Sie sich bei Microsoft 365 anmelden, prüft Microsoft Passwort und zweiten Faktor genau einmal. Danach erhalten Browser oder App mehrere Token — digitale Ausweise, die sagen: „Diese Person hat sich korrekt angemeldet.“ • Das Zugriffstoken (Access Token) öffnet Outlook, Teams oder SharePoint. Es gilt normalerweise eine Stunde. • Das Aktualisierungstoken (Refresh Token) holt neue Zugriffstoken, ohne dass Sie sich erneut anmelden müssen. Es gilt deutlich länger. • Im Browser übernimmt ein Sitzungs-Cookie diese Rolle. Wer diese Token besitzt, ist für Microsoft angemeldet. Genau darauf zielt der Angriff.

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-Agent node 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.
Ablaufdiagramm: Der Mitarbeiter meldet sich über eine gefälschte Seite an, die Passwort und MFA an die echte Microsoft-Anmeldung weiterreicht. Die Seite behält eine Kopie des Tokens, die Angreifer spielen es von eigenen Servern bei Microsoft 365 ein.
So funktioniert Token-Replay über eine gefälschte Anmeldeseite: Die MFA wird erfüllt – das Token landet trotzdem beim Angreifer.

Was die Angreifer nach der Übernahme tun

Die Muster sind typisch für Business E-Mail Compromise (BEC), also Betrug über übernommene Firmenpostfächer: • Eigene Geräte registrieren: Rechner mit Namen nach dem Muster 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 -AutoSize
So sieht eine saubere Installation aus — wichtig ist, dass alle Graph-Module dieselbe Versionsnummer haben:
Beispielausgabe
Name                                         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.0

Typische Stolperfallen bei der Installation

• Unterschiedliche Versionen: Sind ältere Graph-Module vorhanden, meldet Connect-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

Alle Befehle in diesem Abschnitt lesen nur und ändern nichts. Ersetzen Sie Beispielwerte wie name@firma.de durch Ihre eigenen.

Schritt 1: Gefälschte Geräte finden

Sucht nach Geräten, deren Name genau dem Muster DESKTOP- 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 -AutoSize
So kann die Ausgabe aussehen:
Beispielausgabe
Geraet           Registriert          Typ       Besitzer
------           -----------          ---       --------
DESKTOP-BAF88EF4 21.07.2026 18:02:17  Workplace buchhaltung@firma.de
Ein Treffer ist ein starkes Indiz, aber kein Beweis — klären Sie mit dem Mitarbeiter, ob er das Gerät kennt. Der Typ Workplace 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 -AutoSize

Schritt 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 -AutoSize
Beispielausgabe
Benutzer             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:10
DisplayName 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 -AutoSize
Beispielausgabe
Benutzer             Geloescht           Neu                 Minuten IP
--------             ---------           ---                 ------- --
buchhaltung@firma.de 17.09.2026 14:02:11 17.09.2026 14:09:47       8 193.26.115.16
Jede Zeile hier verdient eine Rückfrage beim Mitarbeiter. Ein neues Handy erklärt das Muster manchmal — eine fremde IP-Adresse nicht.

Schritt 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 -AutoSize
Fehlercode 0 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 -AutoSize
So lesen Sie die drei Listen: 1. Der User-Agent node 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, SubjectOrBodyContainsWords
Beispielausgabe
MailboxOwnerId             : Buchhaltung
Name                       : ,.
Enabled                    : True
MoveToFolder               : Buchhaltung:\RSS-Feeds
DeleteMessage              : False
MarkAsRead                 : True
ForwardTo                  :
RedirectTo                 :
SubjectOrBodyContainsWords : {Gehalt, Lohn, Bankverbindung, Überweisung}
Der Filter ist bewusst großzügig. Auch harmlose Regeln wie „Newsletter löschen“ können auftauchen. Klar verdächtig sind Regeln aus Satzzeichen, Ziele wie „RSS-Feeds“, die Kombination aus „als gelesen markieren“ und „löschen“ sowie Filter auf Gehalt, Bank, Rechnung oder Zahlung. Weiterleitungen lassen sich auch direkt am Postfach einrichten, ganz ohne Regel:
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 -AutoSize

Schritt 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 -AutoSize
Achten Sie auf Adressen aus Rechenzentren, VPN-Diensten oder dem Ausland — und auf Regeln, die zu Zeiten angelegt wurden, an denen der Mitarbeiter nicht gearbeitet hat. Liefert der Befehl gar nichts, prüfen Sie im Microsoft-Purview-Portal unter „Überwachung“, ob die Protokollierung eingeschaltet ist.

Schritt 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 -Wrap
Unbekannte Apps mit Rechten wie Mail.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 -AutoSize
Beispielausgabe
Sicherheitsstandards aktiv: False

DisplayName                     State                              Authentifizierungsfluss Gewaehrung
-----------                     -----                              ----------------------- ----------
MFA fuer alle Benutzer          enabled                                                    mfa
Geraetecode blockieren          enabledForReportingButNotEnforced  deviceCodeFlow          block
In diesem Beispiel ist die Sperre des Gerätecode-Flusses nur im Berichtsmodus (enabledForReportingButNotEnforced) — 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

Die Reihenfolge ist wichtig. Wer nur das Passwort ändert, lässt die Hintertüren offen. Die Befehle in diesem Abschnitt ändern etwas — prüfen Sie Benutzernamen und IDs vor dem Ausführen genau.

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 $upn
Die Sperre verhindert neue Anmeldungen, der Widerruf macht alle Aktualisierungstoken ungültig. Exchange, SharePoint und Teams setzen das dank CAE innerhalb weniger Minuten um.

2. Fremde MFA-Methoden entfernen

Erst anzeigen, dann gezielt die fremde App löschen. Die Id ü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>'
Im Zweifel alle Methoden entfernen und gemeinsam mit dem Mitarbeiter neu einrichten — am besten gleich als Passkey.

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:$false
Zum Deaktivieren von Geräten braucht das angemeldete Konto die Rolle „Cloudgeräteadministrator“ oder höher.

4. 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 $null

5. 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

Microsoft empfiehlt gegen Token-Diebstahl einen mehrstufigen Ansatz: Diebstahl erschweren, Diebstahl erkennen, Wiederverwendung verhindern. Die meisten Maßnahmen setzen den bedingten Zugriff (Conditional Access) voraus und damit Microsoft Entra ID P1.

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.
Diagramm: Fünf Glieder der Angriffskette mit den passenden Schutzmaßnahmen darunter – von Schulung und Gerätecode-Sperre über Passkeys, konforme Geräte und Token Protection bis zur Absicherung der Geräte- und MFA-Registrierung und der Kontrolle von Inbox-Regeln
Jedes Glied der Angriffskette lässt sich unterbrechen – Passkeys wirken am frühesten.

Was Ihre Mitarbeiter wissen sollten

Technik ist die wichtigste Verteidigung, aber diese Regeln sollte jeder kennen: 1. Niemals einen Code auf microsoft.com/devicelogin eingeben, den man per Mail, Chat oder Telefon bekommen hat. Echte Kollegen und echter IT-Support verlangen das nicht. 2. Eine MFA-Anfrage, die man nicht selbst ausgelöst hat, immer ablehnen und sofort der IT melden. 3. Wer merkt, dass die eigene Authenticator-App plötzlich keine Anfragen mehr bekommt, meldet das sofort. Das kann bedeuten, dass jemand anderes die MFA übernommen hat. 4. Änderungen an Bankverbindungen immer über einen bekannten zweiten Kanal bestätigen, etwa per Rückruf unter der gespeicherten Telefonnummer — nie über die Kontaktdaten aus der Mail.

Fazit

Die Kampagne zeigt, dass MFA per Push-Nachricht oder Code allein nicht mehr ausreicht, um Microsoft-365-Konten zu schützen. Angreifer müssen das Passwort nicht mehr knacken, sie übernehmen die fertige Anmeldung — und richten sich mit eigenen Geräten und Authenticator-Apps dauerhaft ein. Diese Spuren bleiben auch dann sichtbar, wenn die Anmeldeprotokolle längst gelöscht sind. Prüfen Sie Ihren Tenant deshalb jetzt mit den Befehlen oben, sperren Sie den Gerätecode-Fluss, sichern Sie die Registrierung von Geräten und MFA-Methoden ab und stellen Sie schrittweise auf Passkeys um. Wer ein auffälliges Konto findet, schließt alle Hintertüren — ein neues Passwort allein genügt nicht.

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 aufnehmen

Transparenzhinweis: Die Inhalte dieses Beitrags wurden mit Unterstützung von künstlicher Intelligenz erstellt und von uns redaktionell geprüft.

MT

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.

Weitere Beiträge