Eine Rechnung, eine Geschenkkarte und 22 Anmeldedatensätze

Kontext

Warum kam der Kunde zu uns? Er wollte die Menschen prüfen, nicht die Server, und stellte zwei Fragen. Lässt sich ein Mitarbeiter allein mit einer E-Mail zu einer Zahlung bewegen. Und schützt MFA wirklich die Konten, oder sieht es nur so aus.

Die Antwort auf beide lautete: Es lässt sich umgehen. Eine der Fragen beantwortete eine Person aus der Buchhaltung, die uns zurückschrieb, die Zahlung auf das ausgetauschte Konto gehe noch am selben Tag raus.

Die Mail lief auf Microsoft 365, ein Teil der Konten hatte MFA aktiviert, und das Sicherheitsteam ging davon aus, dass diese Konfiguration reicht. Sie reichte nicht.

Herausforderung

Auf dem Papier sah die Mail-Konfiguration vernünftig aus. SPF schloss die Serverliste mit einem harten -all, DMARC lief im Quarantäne-Modus, und der eingebaute Mailschutz scannte Anhänge mit einem Eifer, den wir später in den Logs wiedersahen.

$ dig +short TXT klient.example
"v=spf1 include:spf.protection.outlook.com -all"

$ dig +short MX klient.example
0 klient-example.mail.protection.outlook.com.

$ dig +short TXT _dmarc.klient.example
"v=DMARC1; p=quarantine; rua=mailto:dmarc@klient.example; fo=1"

$ dig +short TXT selector1._domainkey.klient.example
# pusto -> DKIM po stronie nadawcy niepodpisany

Eine Lücke war sofort sichtbar. Die Domain signierte die Mail nicht per DKIM, was in dieser Mail-Umgebung eine Sache von einem Schalter und einem DNS-Eintrag ist. Für sich genommen öffnet das keine Tür, aber es schwächt das, worauf DMARC aufbaut.

Das eigentliche Problem lag woanders. Bei der MFA. Klassisches Passwort-Phishing scheitert am zweiten Faktor, denn der Dieb hat Login und Passwort, aber bei der Anmeldung erscheint trotzdem ein Code oder ein Push in der App. Um da wirklich durchzukommen, übernimmt man nicht das Passwort, sondern die Session. Dazu kam der Mailschutz, der alles im Namen des Nutzers liest, bevor dieser überhaupt klickt. Genau das haben wir in eine Datenquelle verwandelt, dazu gleich mehr.

Was wir getan haben

Wir teilten die Kampagne in zwei Stufen mit unterschiedlichem Risikoprofil. Gezieltes Spear-Phishing gegen drei Personen aus der Finanzabteilung und breites Phishing gegen die gesamte Belegschaft. Die Abbildung auf MITRE ATT&CK steht unten, denn das ist die Sprache, in der man sich mit einem Blue Team am leichtesten verständigt.

Stufe 1: Spear-Phishing gegen die Finanzabteilung. Drei Adressen, drei Personen, die Zahlungen abwickeln. Wir registrierten eine Domain, die sich von der echten Domain des Geschäftspartners nur durch einen Zusatz unterschied, richteten darauf ein Absenderkonto ein und bauten die Rechnung des Partners nach. Typografie, Aufbau, Logos, Dateigröße, Metadaten. Dazu die Mail-Signatur, pixelgenau kopiert. Auf der Rechnung tauschten wir mit Zustimmung des Kunden die IBAN aus, um den vollen Weg des Zahlungsbetrugs zu zeigen und nicht nur den Klick.

An jede Nachricht hängten wir eine zweite PDF-Datei mit einem Canary-Token. Das ist eine digitale Falle, die im Moment des Öffnens ein Signal sendet und meldet, wer das Dokument wann und von welcher Adresse geöffnet hat. Und hier wird es interessant für jeden, der Öffnungsraten von E-Mails je für bare Münze genommen hat.

open  src=<chmura dostawcy poczty>  org="Microsoft Corporation"  geo=SE  -> bot (skan załącznika)
open  src=<chmura dostawcy poczty>  org="Microsoft Corporation"  geo=PL  -> bot
open  src=<krajowy operator>        org="operator lokalny"        geo=PL  -> realny użytkownik

Die Verteilung war aufschlussreich. Bei einem Token zählten wir zehn automatische Öffnungen und nur eine durch einen echten Nutzer. Bei einem anderen gar keine Nutzer, nur Scanner. Der Schluss für einen Analysten ist einfach. Wer einen Alarm auf "Datei wurde geöffnet" baut, den alarmiert in einer solchen Umgebung vor allem die Cloud-Infrastruktur, nicht der Angreifer. Ein Filter nach ASN und Geolokalisierung macht aus dem Rauschen ein Signal.

Das wichtigste Ereignis hatte nichts mit Technik zu tun. Eine Person leitete die Mail weiter, und aus der Kette kam die Antwort eines Mitarbeiters, der den Vorgang abschloss: Wir zahlen heute. Kein Exploit. Eine glaubwürdige Rechnung, der Druck einer Zahlungsfrist und das Vertrauen in eine bekannte Marke reichten, um die Überweisung in Gang zu setzen.

Stufe 2: breites Phishing und die Umgehung der MFA. Der Vorwand war einfach und zugkräftig. Eine Geschenkkarte eines bekannten Anbieters, angeblich im Rahmen eines Firmenprogramms vergeben. Einem geschenkten Gaul schaut niemand ins Maul, also verkaufte sich das Szenario von selbst.

Statt Passwörter zu stehlen, schlüpften wir in die Rolle des Adversary in the Middle. Auf einem VPS beim Cloud-Anbieter stellten wir einen Reverse-Proxy auf, der die Session abfing, die Domains parkten wir bei Cloudflare. Das Opfer sah ein echtes Anmeldeformular, denn es war ein echtes Formular, nur durch uns hindurchgereicht.

Der Schlüssel liegt in dem, was hinter den Kulissen passiert. Der Nutzer durchlief die normale MFA, bestätigte den Push in der App, meldete sich an und sah sein Postfach. Wir fingen in dieser Zeit das Session-Cookie aus dem Datenverkehr ab. Ein Session-Token ist kein Passwort. Es funktioniert nach einer Passwortänderung und geht am zweiten Faktor vorbei, weil die Authentifizierung bereits stattgefunden hat. Den Zugriff auf eines der Konten bestätigten wir manuell, indem wir das Postfach ohne erneute Anmeldung öffneten.

Dazu kam noch ein Trick gegen die Erkennung. Vor die Phishing-Seite setzten wir eine Firewall mit Geo-Filter, die nur Datenverkehr aus Polen durchließ. Die Anti-Phishing-Bots, die verdächtige Links aus aller Welt besuchen, stießen gegen eine Wand und hatten nichts, was sie an eine Sperrliste melden konnten.

Zwei Dinge fielen uns bei diesem Versand auf. Öffnungen und Klicks liefen fast im Gleichschritt, was eine Bot-Signatur ist, denn ein Scanner ruft den Link in einem Zug auf. Und über die gesamte Kampagne nutzte niemand den Knopf "Phishing melden". Das sagte uns mehr als die gekaperten Konten.

Ergebnis

Wir sammelten 22 Anmeldedatensätze für die Umgebung des Kunden, und für die meisten hatten wir auch Session-Tokens, also Zugriff, der auch nach einem Passwort-Reset weiter funktioniert und die MFA in ihrer bisherigen Form umgeht. Auf der Finanzseite führte eine E-Mail-Kette zur Zusage, Geld auf das ausgetauschte Konto zu überweisen. Google Safe Browsing erkannte eine der Domains erst nach einem vollen Tag, und der Kunde bemerkte die Quarantäne der zweiten einen Tag nach dem Start, das Zeitfenster war also ohnehin weit.

Eine Nutzerinteraktion war nötig, aber davon abgesehen war die Einstiegshürde niedrig, und die Übernahme einer Identität erlaubte es, über das Konto hinauszugehen, mit dem es begann.

Wir haben die Empfehlungen so formuliert, dass Sie sie abhaken können und nicht nur lesen:

• Wechseln Sie zu phishing-resistenter MFA, also FIDO2 oder Passkeys. AiTM funktioniert, weil sich Code und Push in Echtzeit weiterreichen lassen, ein an den Origin gebundener Hardware-Schlüssel jedoch nicht.
• Ziehen Sie Conditional Access an. Die Anforderung eines konformen Geräts oder eines vertrauenswürdigen Standorts zerstört das Szenario, in dem ein Token auf die Maschine des Angreifers abfließt. Der Bezugspunkt steht bei Microsoft in der Beschreibung der Abwehr gegen AiTM.
• Verkürzen Sie die Lebensdauer der Session und schalten Sie die kontinuierliche Zugriffsbewertung (CAE) ein, damit ein gestohlenes Token nicht wochenlang lebt.
• Ergänzen Sie DKIM auf der Absenderseite und lesen Sie die RUA-Berichte aus DMARC regelmäßig. Das Postfach rua gibt es, damit jemand hineinschaut.
• Führen Sie eine Zwei-Personen-Freigabe für Zahlungen ein und eine harte Prüfung jeder IBAN-Änderung über einen anderen Kanal als die Mail. Das stoppt BEC selbst dann, wenn die Rechnung perfekt aussieht.
• Setzen Sie einen Knopf "Phishing melden" dorthin, wo die Menschen hinschauen, und zählen Sie, wie oft er genutzt wird. Keine Meldungen trotz zahlreicher Klicks sind nicht die Schuld der Nutzer, sondern das Fehlen eines einfachen Meldewegs.

Ein Vorbehalt zum Schluss, denn wir wollen keine Gewissheit verkaufen, die wir nicht haben. Wir wissen nicht, wie viele der 22 Konten sich zu voller lateraler Bewegung ausbauen ließen, weil der Umfang mit der Bestätigung des Zugriffs endete. Wir gehen von einigen aus, da unter den gekaperten Sessions Konten mit Zugriff auf geteilte Postfächer waren.

Und wenn bei Ihnen heute jemand eine E-Mail mit einer Rechnung über einen kleinen Betrag von einem festen Geschäftspartner bekäme, mit korrekter Signatur und etwas Fristdruck, in welcher Phase würden Sie diesen Angriff erkennen? Am Menschen, an Conditional Access oder an der Zahlungsprozedur? Wenn Sie nicht auf alle drei eine sichere Antwort haben, prüfen wir das gern.