Cyber-Kriminalität
BEC: Phishing umgeht Multifaktorauthentifizierung
Ein einziger Klick auf einen gezielten Köder verschaffte einem Angreifer aktive Microsoft 365-Sitzungs-Tokens – genug, um sich als Lieferant auszugeben und Zahlungen umzuleiten. Wir haben den Angriff vom ersten Klick bis zu seiner Ursache verfolgt.
Save to Folio
Wichtige Erkenntnisse
- Bei einem Cloud-basierten Business-Email-Compromise (BEC)-Angriff nahm der Kriminelle einen Mitarbeiter der Finanzabteilung mit einer Spear-Phishing-Mail ins Visier, umging die Multi-Faktor-Authentifizierung (MFA) und entwendete das Live-Sitzungs-Token für Microsoft 365.
- Der Angriff erfolgte ohne Malware und ohne Kompromittierung eines Endgeräts, lediglich auf Microsoft 365-Identitätsebene.
- Die Untersuchung stützte sich auf Identitäts-Telemetrie (die anomale Wiederverwendung des Sitzungs-Tokens und die Erstellung von Posteingangsregeln von fremden IP-Adressen).
BEC bleibt eine Bedrohung mit hoher Auswirkung und geringer Komplexität. Ein scheinbar gewöhnlicher E-Mail-Austausch endet damit, dass Geld auf dem falschen Konto landet. Das TrendAI Vision One™ MDR-Team untersuchte ein Musterbeispiel für einen vollständig cloudbasierten BEC-Angriff.
Überblick
Ein Finanzmitarbeiter erhielt eine Spear-Phishing-Mail, klickte auf den Link und löste damit eine AiTM-Relay-Kette aus. Der Vorgang involvierte nicht nur das Passwort des Benutzers, sondern auch die authentifizierte Microsoft-365-Sitzung selbst. Die MFA wurde außer Kraft gesetzt. Von da an agierte der Angreifer vollständig als der Benutzer, las Mails, erstellte versteckte Posteingangsregeln und gab sich als Lieferant des Unternehmens aus, um eine Zahlung an einen Lieferanten umzuleiten. Die Host-Forensik bestätigte, dass auf dem kompromittierten Endpunkt weder Infostealer noch Fernzugriffstools noch Anzeichen für laterale Bewegung vorhanden waren. Die Aktivitäten beschränkten sich auf die Identitäts- und E-Mail-Ebene.
Erster Zugriff: Die Phishing-Mail war eine Mitteilung zum Thema Personalwesen mit dem Betreff „PTO-Antrag abgelehnt“. Sie war auf den bestimmten Finanzmitarbeiter zugeschnitten, sie enthielt dessen Namen, Berufsbezeichnung und den Namen des Unternehmens. Diese individuelle Anpassung kennzeichnet sie als Spear-Phishing. Der geforderte Klick auf eine Schaltfläche mit der Beschriftung „View PTO Conflicting Dates“ reichte aus (ein Click-Tracking-Link von SendGrid), um eine Umleitungskette auszulösen, die auf einer gefälschten Microsoft 365-Anmeldeseite endete.
Die Tatsache, dass die Mail im Posteingang landete, bedeutet, dass sie die Überprüfungen nach Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM) und Domain-based Message Authentication, Reporting and Conformance (DMARC) bestanden hatte. Die Rekonstruktion der URL-Weiterleitungskette anhand des Endpunktverlaufs liefert der Originalbeitrag.
Der Nutzer bestätigte unwissentlich die MFA-Aufforderung, wodurch der Angreifer das authentifizierte Sitzungs-Token erfassen konnte. Dieser wurde anschließend über eine kommerzielle VPN-Infrastruktur wiederverwendet, sodass der Angreifer als der Nutzer agieren und mit betrügerischen Aktivitäten fortfahren konnte.
Umleitung von Lieferantenzahlungen
Der Betrug verlief in zwei sich überschneidenden Phasen der Identitätsfälschung. Jede Phase umfasste eine andere vertrauenswürdige Person und war so konzipiert, dass eine betrügerische Änderung der Bankdaten wie eine routinemäßige Buchhaltung im Kreditorenbuchhaltungsbereich (AP) aussah. Durch die gleichzeitige Durchführung beider Phasen wurde dieselbe Bankdatenänderung sowohl von außerhalb als auch von innerhalb der Organisation angefordert, sodass jede Anfrage die andere zu bestätigen schien.
Die erste Phase bestand aus einer Kampagne, bei der sich der Angreifer als Lieferant ausgab und das gemeinsame Postfach der Kreditorenbuchhaltung ins Visier nahm. Da in diesem Postfach legitimerweise Lieferantenrechnungen, Zahlungsanfragen und Bankbenachrichtigungen bearbeitet wurden, musste sich der Angreifer lediglich in die normale Geschäftskommunikation einfügen. Innerhalb weniger Tage nach dem ersten Austausch wurde eine ungewöhnliche Anomalie im Datenverkehr protokolliert. Diese wurde später zum Ausgangspunkt der Ermittlungen.
Durch die Verschleierung blieb der Betrug unentdeckt. Unter Nutzung der gestohlenen Sitzung ging der Angreifer davon aus, dass unbezahlte Lieferanten schließlich Mahnungen an das gemeinsame Postfach der Kreditorenbuchhaltung senden würden. Daraufhin richtete er eine Posteingangsregel ein, um diese Nachrichten automatisch zu archivieren und als gelesen zu markieren, bevor die weitere Regelverarbeitung gestoppt wurde. Das Opfer sah die Mahnungen des echten Lieferanten nie.
Eine zweite Regel im Postfach des Opfers verbarg den Identitätsbetrugs-Thread selbst. Unsere Untersuchung ergab, dass der Angreifer Beweise für E-Mails beseitigte, die den Betrug hätten aufdecken können.
Die Phase 2 markierte eine Eskalation. Der Angreifer gab sich als leitender Mitarbeiter der Kreditorenbuchhaltung des Unternehmens aus, um die betrügerische Zahlung durchzusetzen. Einige Tage nach dem Ende der E-Mails mit gefälschter Identität platzierte der Angreifer eine dritte und letzte Verschleierungsregel, die diesmal darauf abzielte, einer Überprüfung von innen zu entgehen. Sie wurde von einer fremden VPN-IP-Adresse unter derselben gekaperten Sitzung aus erstellt und ergänzte die beiden Regeln der Phase 1, die die Bedrohung durch den externen Anbieter verdeckt hatten. Der Angreifer hatte die vollständige Kontrolle über beide Seiten des Kommunikationsablaufs erlangt: die Verifizierung durch den externen Anbieter und die interne Zahlungsprüfung.
Untersuchung durch das MDR-Team
Das MDR-Team verfolgte den Fall bis zu seiner Ursache zurück – mithilfe von Host-Forensik, E-Mail- und Header-Analyse sowie der Korrelation der Identitätsspur. Auf dem Host wurden Eindämmungsmaßnahmen durchgeführt, wobei keine Malware gefunden wurde.
Die Untersuchung ergab, dass die TrendAI Vision One™-Plattform eine Anomalie im Zusammenhang mit einer Reise des Finanzmitarbeiters protokolliert hatte: Dieselbe Microsoft 365-Sitzung authentifizierte sich zunächst von Amsterdam und etwa eine Minute später von Los Angeles aus. Das physikalisch unmögliche Reiseintervall zwischen den Niederlanden und Kalifornien deutete auf eine Wiederverwendung des Sitzungs-Tokens hin und nicht auf legitime Benutzeraktivitäten von zwei Standorten aus.
Die Erkennung eines atypischen Zugriffsmusters allein reicht jedoch nicht aus. Zusätzliche Untersuchungen sollten sich auf nachfolgende Aktivitäten im Zusammenhang mit dem Konto konzentrieren, um verdächtige Folgeaktionen zu identifizieren. Die Anmelde-Telemetriedaten bestätigten, dass das Sitzungs-Token wiederverwendet worden war. Unter normalen Umständen würde eine Anmeldung von einem neuen Gerät oder Standort aus eine MFA auslösen. Der Angreifer hatte die vollständige Kontrolle über beide Seiten des Kommunikationsablaufs erlangt: die Verifizierung durch den externen Anbieter und die interne Zahlungsprüfung. Der Originalbeitrag beinhaltet Einzelheiten zu den Zugriffen des Angreifers.
Korrelation von drei Datenquellen
Das Team korrelierte drei Datenquellen unter dem Produktnamen (pname). Diese Protokolle bündeln Aktivitäten aus mehreren Quellen und ermöglichen so die effiziente Identifizierung, Kategorisierung und Abfrage verwandter Ereignisse: Microsoft Entra ID, Anmeldeaktivitäten in Entra ID, Collaboration Sensor, Überwachungsaktivitäten für Microsoft 365-Postfächer und Cloud Email and Collaboration Protection, E-Mail-Aktivitäten. Anschließend analysierten wir die zugehörigen Signale und korrelierte Benutzerkonten, IP-Adressen und Sitzungsaktivitäten, um verdächtige Muster zu identifizieren.
Die Tabelle 4 im Originalbeitrag listet die Signale auf, die den einzelnen Schritten dieses Angriffs zugeordnet sind, sowie die Abfragen, mit denen sie aufgedeckt wurden. Dort finden sie auch die Zuordnung zu MITRE ATT&CK-Techniken.
Fazit
Diese BEC-Kampagne zeigt ein weiteres Mal, wo der Perimeter eines Unternehmens heute tatsächlich liegt: bei Vertrauen und Identität. Durch den Diebstahl einer einzigen authentifizierten Sitzung erhielten die Drahtzieher dieser Kampagne alles, was sie brauchten, um sich als Finanzmitarbeiter auszugeben und echtes Geld umzuleiten. Authentifizierung ist nicht gleichbedeutend mit Legitimität, und die frühesten Warnsignale sind in der Identitäts- und Postfach-Ebene zu finden, nicht am Endgerät.
Empfehlungen
Unternehmen können ihr Risiko mit drei Kontrollmaßnahmen verringern:
- Konsolidieren Sie Endpunkt-, E-Mail- und Identitäts-Telemetrie mit TrendAI Vision One™. Die Plattform vereinheitlichte und korrelierte die Signale zu einer einzigen Angriffszeitleiste und verband dabei die AiTM-Weiterleitungskette, den Zugriff auf das Postfach und die Wiederverwendung des Sitzungstokens. Dadurch wurden isolierte Indikatoren zu einem bestätigten Vorfall, was die Untersuchung und Reaktion beschleunigte.
- Aktivieren Sie den Token-Schutz in Microsoft Entra ID Conditional Access. Dies würde es ermöglichen, jedes Sitzungs- oder Aktualisierungs-Token kryptografisch an das Gerät zu binden, auf dem es ausgestellt wurde. Ein von diesem Gerät entnommenes Token kann von keinem anderen Rechner aus wiederverwendet werden.
- Führen Sie einen obligatorischen Out-of-Band-Verifizierungsprozess für Änderungen an Bankdaten des Anbieters ein. Verlangen Sie eine doppelte Genehmigung und eine Rückruf-Verifizierung unter Verwendung einer vertrauenswürdigen, bereits hinterlegten Telefonnummer, bevor Änderungen an ACH- oder Bankdaten genehmigt werden. Diese Kontrollmaßnahme bietet einen unabhängigen Validierungsschritt und kann die Umleitung von Zahlungen selbst in Szenarien verhindern, in denen E-Mail-Konten oder Benutzeridentitäten kompromittiert wurden.