DMARCPulse
Alle Beiträge Ghostwriter-Phishing gegen ukrainische Behörden: Wenn DMARC grünes Licht gibt, obwohl es das nicht sollte

Ghostwriter-Phishing gegen ukrainische Behörden: Wenn DMARC grünes Licht gibt, obwohl es das nicht sollte

DMARCPulse Team

Der Angriff, der DMARC kalt lässt

Im Mai 2026 wurde bekannt, dass die Ghostwriter-Gruppe – ein seit Jahren aktiver, mutmaßlich belarussischer Bedrohungsakteur – gezielte Phishing-Kampagnen gegen ukrainische Regierungsbehörden durchgeführt hat. Das Besondere daran: Die Angreifer nutzten keine gefälschten Domains. Sie nutzten echte, bereits kompromittierte E-Mail-Accounts legitimer Absender.

Das Ergebnis: SPF hat bestanden. DKIM hat bestanden. DMARC hat bestanden. Und trotzdem war jede dieser E-Mails eine Waffe.

Was Ghostwriter anders macht

Klassisches Phishing funktioniert über Domain-Spoofing: Ein Angreifer registriert microsoft-support.net oder tippt @paypa1.com in das Absenderfeld. DMARC wurde genau dafür entwickelt – es prüft, ob die sendende Domain mit der im From:-Header übereinstimmt und ob SPF oder DKIM diese Domain bestätigen.

Ghostwriter geht einen Schritt weiter. Die Gruppe kompromittiert zunächst echte Accounts – etwa über Credential-Stuffing, Spear-Phishing oder den Kauf gestohlener Zugangsdaten. Dann sendet sie von diesen Accounts aus. Die E-Mail kommt von [email protected]. SPF zeigt auf die legitimen Mailserver der Behörde. DKIM ist mit dem echten privaten Schlüssel signiert. DMARC sieht eine saubere Alignment-Prüfung – und lässt durch.

Kein Filter der Welt, der nur auf Protokoll-Ebene schaut, kann das aufhalten.

Die strukturelle Grenze von DMARC

Das ist kein Fehler in DMARC. Es ist eine Designgrenze, die oft missverstanden wird.

DMARC beantwortet eine sehr spezifische Frage: “Hat diese E-Mail das Recht, im Namen dieser Domain zu sprechen?” Wenn ein kompromittierter Account sendet, lautet die Antwort technisch korrekt: Ja. Der Account gehört zur Domain. Die Infrastruktur ist dieselbe. Die Kryptographie stimmt.

Was DMARC nicht beantwortet: “Verhält sich dieser Absender normal? Passt der Inhalt zu früheren Mustern? Wurde dieser Account möglicherweise übernommen?”

Diese Fragen erfordern andere Werkzeuge.

Was Behavioral Analytics hier leisten kann

Wenn DMARC an seine Grenzen stößt, müssen Signale auf einer anderen Ebene ausgewertet werden. Konkret:

  • Absenderverhalten: Sendet [email protected] plötzlich an 200 Empfänger, die er vorher nie kontaktiert hat? Oder zu ungewöhnlichen Uhrzeiten?
  • Inhaltsmuster: Enthält die E-Mail einen Link zu einer externen Dateiablage, obwohl der Absender das nie getan hat?
  • Login-Anomalien: Hat sich der Account kurz vor dem Versand aus einer unbekannten IP oder einem unbekannten Land eingeloggt?
  • Antwortverhalten: Reagieren Empfänger auf die E-Mail mit Rückfragen, die auf Verwirrung hindeuten?

Keines dieser Signale ist für sich allein ein Beweis. Zusammen ergeben sie ein Bild, das ein gut konfiguriertes SIEM oder eine E-Mail-Security-Plattform mit Behavioral-Analytics-Modul erkennen kann.

Was das für eure E-Mail-Security-Strategie bedeutet

DMARC bleibt unverzichtbar. Wer keine DMARC-Policy hat, öffnet die Tür für Domain-Spoofing – und das ist nach wie vor die häufigste Phishing-Methode. Aber DMARC ist eine Schicht, keine vollständige Lösung.

Ein realistisches Sicherheitsmodell für 2026 sieht so aus:

Schicht 1 – Protokoll-Authentifizierung: SPF, DKIM, DMARC mit p=reject. Pflicht, kein Diskussionspunkt.

Schicht 2 – Reputation und Filterung: Gateway-Filter, die bekannte bösartige IPs, Domains und Anhänge blockieren.

Schicht 3 – Behavioral Analytics: Erkennung von Anomalien im Absenderverhalten, ungewöhnlichen Kommunikationsmustern und verdächtigen Login-Ereignissen.

Schicht 4 – Incident Response: Klare Prozesse, wenn ein Account als kompromittiert gilt – sofortige Passwort-Resets, Session-Invalidierung, Benachrichtigung betroffener Empfänger.

Ghostwriter zeigt, dass Angreifer auf Schicht 3 und 4 abzielen, sobald Schicht 1 und 2 gut abgesichert sind. Das ist keine Überraschung – es ist die logische Konsequenz.

Was IT-Admins und MSPs jetzt konkret tun sollten

Überprüft eure DMARC-Policy. Wenn ihr noch auf p=none steht, ist das der erste Schritt. Aber hört dort nicht auf.

Sprecht mit euren Nutzern über Account-Hygiene: Starke Passwörter, MFA, und das Bewusstsein, dass eine “echte” E-Mail von einem bekannten Absender trotzdem gefährlich sein kann.

Schaut euch an, welche Behavioral-Analytics-Funktionen eure bestehende E-Mail-Security-Plattform bietet – viele Microsoft-365- und Google-Workspace-Umgebungen haben diese Funktionen bereits eingebaut, sie sind nur oft nicht aktiviert oder nicht richtig konfiguriert.

Und wenn ihr noch keinen vollständigen Überblick über eure eigene DMARC-Konfiguration habt, ist das der naheliegendste erste Schritt.

Prüft eure Domain kostenlos auf dmarcpulse.io/de/free-domain-check – ihr seht sofort, ob SPF, DKIM und DMARC korrekt konfiguriert sind und wo Handlungsbedarf besteht.