Microsoft 365 AiTM-Phishing: Warum ein DMARC-Pass keine Sicherheit garantiert

Ein grüner Auth-Check – und trotzdem Phishing

SPF: Pass. DKIM: Pass. DMARC: Pass. Für viele IT-Admins bedeutet diese Kombination: Die E-Mail ist legitim. Ein aktuell beobachteter Angriff auf Microsoft-365-Umgebungen zeigt, warum das ein gefährlicher Trugschluss ist.

Die Angreifer nutzen echte, kompromittierte GMX-Accounts als Absender. Weil diese Accounts tatsächlich bei GMX registriert sind, bestehen alle drei Authentifizierungsprüfungen problemlos. Der empfangende Mailserver sieht eine sauber signierte E-Mail von einer legitimen Domain – und lässt sie durch.

Wie die Angriffskette funktioniert

Der Ablauf ist technisch durchdacht und in mehrere Stufen aufgeteilt:

• Kompromittierter Absender-Account: Die Angreifer übernehmen echte GMX-Postfächer. Damit ist die sendende Infrastruktur authentisch – kein Spoofing, kein Look-alike-Domain-Trick.
• Randomisierter Display-Name pro Ziel: Für jedes Opfer wird der angezeigte Absendername individuell angepasst. Das erschwert regelbasierte Erkennungssysteme erheblich, weil kein fester Muster-String existiert.
• PDF-Invoice als Lure: Der Anhang ist eine PDF-Rechnung, die einen Link zu einer AiTM-Phishing-Seite (Adversary-in-the-Middle) enthält. Diese Seite fängt nicht nur Zugangsdaten ab, sondern auch Session-Cookies – womit eine Mehr-Faktor-Authentifizierung umgangen werden kann.
• Microsoft 365 als Ziel: Die gefälschten Login-Seiten imitieren das Microsoft-365-Portal. Nach erfolgreichem Cookie-Diebstahl übernehmen die Angreifer die Sitzung direkt, ohne das Passwort zu kennen.

Das Ergebnis: Account-Takeover trotz MFA, trotz DMARC-Pass, trotz moderner E-Mail-Sicherheitsinfrastruktur.

Die kritische Lücke: Was DMARC leistet – und was nicht

DMARC wurde entwickelt, um Domain-Spoofing zu verhindern. Es stellt sicher, dass eine E-Mail, die vorgibt, von beispiel.de zu kommen, auch tatsächlich von der Infrastruktur von beispiel.de versendet wurde. Das ist wertvoll – aber es ist eine eng definierte Garantie.

Was DMARC nicht prüft:

• Ob der Absender-Account selbst kompromittiert wurde
• Ob der Display-Name mit dem tatsächlichen Absender übereinstimmt
• Ob der Inhalt der E-Mail bösartig ist
• Ob ein Link in der E-Mail auf eine Phishing-Seite zeigt

Im beschriebenen Angriff ist die sendende Domain gmx.de oder gmx.net – und die E-Mail kommt tatsächlich von dort. DMARC hat also vollkommen korrekt gearbeitet. Das Problem liegt eine Ebene tiefer: im kompromittierten Account selbst.

Behavioral Signals: Die zweite Verteidigungslinie

Wenn technische Authentifizierung allein nicht ausreicht, braucht es ergänzende Erkennungsebenen. Behavioral Signals sind dabei besonders relevant:

Display-Name-Anomalien erkennen: Wenn der angezeigte Name eines Absenders nicht mit dem tatsächlichen Absender-Account übereinstimmt oder sich bei jedem Versand ändert, ist das ein starkes Warnsignal. Moderne E-Mail-Security-Gateways und SIEM-Systeme können solche Muster erkennen.

Ungewöhnliche Absender-Domain für den Kontext: Erwartet ein Mitarbeiter eine Rechnung von einem deutschen Lieferanten, aber die E-Mail kommt von einem GMX-Account? Das ist ein Kontextsignal, das unabhängig vom Auth-Status bewertet werden sollte.

PDF-Anhänge mit externen Links: PDFs, die ausschließlich einen Link enthalten und keinen substanziellen Inhalt, sind ein klassisches Muster für Phishing-Lures. Sandbox-Analyse und URL-Rewriting helfen hier.

Anomalien in DMARC-Aggregat-Reports: Auch wenn ein Angriff wie dieser keinen DMARC-Fehler erzeugt, können Aggregat-Reports helfen, ungewöhnliche Sendevolumen von Drittdomains zu erkennen – besonders wenn die eigene Domain als Ziel in Reply-To-Feldern missbraucht wird.

Was das für eure DMARC-Strategie bedeutet

DMARC auf p=reject zu setzen ist richtig und wichtig. Es verhindert, dass Angreifer eure eigene Domain für Spoofing-Angriffe missbrauchen. Aber es schützt euch nicht davor, dass jemand anderes Domain für einen Angriff auf euch genutzt wird.

Die praktischen Konsequenzen:

• DMARC-Pass ist eine notwendige, aber keine hinreichende Bedingung für Vertrauen in eine E-Mail.
• Nutzer-Schulungen müssen über “schau auf das Schloss-Symbol” hinausgehen. Display-Namen sind trivial manipulierbar.
• Technische Kontrollen wie Anti-Phishing-Policies in Microsoft 365 Defender, die speziell auf Impersonation-Angriffe ausgelegt sind, sind ein sinnvoller nächster Schritt.
• MFA allein reicht nicht, wenn AiTM-Angriffe Session-Cookies abgreifen. Phishing-resistente MFA-Methoden wie FIDO2/Passkeys sind hier deutlich robuster.

DMARC-Monitoring als Frühwarnsystem

Auch wenn dieser spezifische Angriff keinen DMARC-Fehler erzeugt, bleibt kontinuierliches DMARC-Monitoring essenziell. Warum?

Erstens: Angreifer testen Varianten. Eine Kampagne, die heute mit kompromittierten Accounts arbeitet, kann morgen auf Subdomain-Spoofing oder Look-alike-Domains wechseln – und dann schlägt DMARC an.

Zweitens: Aggregat-Reports zeigen euch, welche Dienste E-Mails in eurem Namen versenden. Unbekannte Quellen in diesen Reports sind immer ein Untersuchungsanlass.

Drittens: Ein sauber konfiguriertes DMARC-Setup mit p=reject und regelmäßigem Report-Review ist die Grundlage, auf der weitere Sicherheitsschichten aufbauen können.

Prüft jetzt, ob eure Domain korrekt konfiguriert ist – und ob ihr alle Sendequellen im Blick habt: Kostenloser Domain-Check auf DMARCPulse