Ghostwriter Phishing Against Ukrainian Government: When DMARC Says "All Clear" But Shouldn't
The Attack That DMARC Cannot Stop
In May 2026, it emerged that Ghostwriter — a long-running threat actor widely attributed to Belarus — had been running targeted phishing campaigns against Ukrainian government agencies. The twist: the attackers did not use fake domains. They used real, already-compromised email accounts belonging to legitimate senders.
The result: SPF passed. DKIM passed. DMARC passed. And every one of those emails was still a weapon.
What Makes Ghostwriter Different
Classic phishing relies on domain spoofing: an attacker registers microsoft-support.net or slips @paypa1.com into the From field. DMARC was built precisely for this — it checks whether the sending domain matches the one in the From: header and whether SPF or DKIM can vouch for it.
Ghostwriter goes a step further. The group first compromises real accounts — through credential stuffing, spear-phishing, or purchasing stolen credentials on underground markets. Then it sends from those accounts. The email arrives from employee@agency.gov.ua. SPF points to the agency’s legitimate mail servers. DKIM is signed with the real private key. DMARC sees a clean alignment check — and lets it through.
No filter that operates purely at the protocol level can stop this.
The Structural Limit of DMARC
This is not a flaw in DMARC. It is a design boundary that is frequently misunderstood.
DMARC answers a very specific question: “Does this email have the right to speak on behalf of this domain?” When a compromised account sends a message, the technically correct answer is: yes. The account belongs to the domain. The infrastructure is the same. The cryptography checks out.
What DMARC does not answer: “Is this sender behaving normally? Does the content match past patterns? Has this account possibly been taken over?”
Those questions require different tools.
What Behavioral Analytics Can Do Here
When DMARC reaches its limits, signals at a different layer need to be evaluated. Concretely:
- Sender behavior: Is
employee@agency.gov.uasuddenly emailing 200 recipients it has never contacted before, or sending at unusual hours? - Content patterns: Does the email contain a link to an external file-sharing service the sender has never used?
- Login anomalies: Did the account log in from an unknown IP or country shortly before the message was sent?
- Recipient reactions: Are recipients replying with questions that suggest confusion about the email’s legitimacy?
None of these signals is proof on its own. Together they form a picture that a well-configured SIEM or an email security platform with a behavioral analytics module can detect.
What This Means for Your Email Security Strategy
DMARC remains essential. Organizations without a DMARC policy leave the door wide open for domain spoofing — still the most common phishing technique. But DMARC is one layer, not a complete solution.
A realistic security model for 2026 looks like this:
Layer 1 — Protocol authentication: SPF, DKIM, DMARC at p=reject. Non-negotiable.
Layer 2 — Reputation and filtering: Gateway filters that block known malicious IPs, domains, and attachments.
Layer 3 — Behavioral analytics: Detection of anomalies in sender behavior, unusual communication patterns, and suspicious login events.
Layer 4 — Incident response: Clear processes for when an account is suspected of being compromised — immediate password resets, session invalidation, notification of affected recipients.
Ghostwriter demonstrates that once layers 1 and 2 are well-secured, attackers shift their focus to layers 3 and 4. That is not a surprise — it is the logical consequence.
What IT Admins and MSPs Should Do Right Now
Check your DMARC policy. If you are still on p=none, that is the first step. But do not stop there.
Talk to your users about account hygiene: strong passwords, MFA, and the awareness that a “real” email from a known sender can still be dangerous.
Look at what behavioral analytics features your existing email security platform already offers — many Microsoft 365 and Google Workspace environments have these capabilities built in, but they are often not activated or properly configured.
And if you do not yet have a clear picture of your own DMARC configuration, that is the most obvious place to start.
Check your domain for free at dmarcpulse.io/en/free-domain-check — you will see immediately whether SPF, DKIM, and DMARC are correctly configured and where action is needed.