A phishing campaign documented by security researchers in June 2026 has drawn attention not because it breaks email authentication, but because it does not need to. The CodeStorm phishing kit – a commercial-grade attack platform with technical overlaps to the threat actor group Storm-1167 – builds its attack chain on compromised Microsoft 365 accounts. The emails it sends do not spoof a domain. They come from a real, active M365 identity. SPF passes. DKIM passes. DMARC passes. Every authentication gate clears, and the email is still a weapon.
This is the attack class that organizations least understand when they deploy DMARC and believe the job is done.
What CodeStorm Does
The CodeStorm kit operates in two distinct phases. In the first, the kit harvests Microsoft 365 credentials through a classic adversary-in-the-middle phishing page. The victim sees what looks like a familiar Microsoft login prompt. They enter their credentials and complete any multi-factor authentication challenge. The kit captures both the credentials and the session token issued after successful authentication.
With a real M365 account under attacker control, the second phase begins. The attacker uses that compromised account as the sending identity for subsequent phishing campaigns. Because the sending account is a genuine, active Microsoft 365 identity hosted on Microsoft’s own mail infrastructure, every authentication signal a receiving mail server checks comes back clean.
Researchers noted the kit’s specific capability for tenant-aware credential replay – the infrastructure probes the victim’s specific Microsoft tenant, replays credentials against live Microsoft identity systems in real time, and monitors for success signals including Entra sign-in failure codes. The goal is not just credential theft but functional account access that can sustain an ongoing sending operation.
Why DMARC Cannot See This
DMARC answers one question: does the domain in the From header align with the domain that authenticated the message via SPF or DKIM?
When an attacker sends from a compromised M365 account at victim-company.com, the answer is yes. The email originates from Microsoft’s mail servers. Microsoft’s SPF records authorize those servers. Microsoft’s DKIM signing infrastructure signs the message. The From address matches the authenticated domain. DMARC evaluates all of this and issues a pass.
There is no misconfiguration, no spoofing, no alignment failure. The authentication is correct because the underlying account is real. DMARC was designed to prevent unauthenticated parties from falsely claiming your domain. It has no mechanism to detect that the authenticated party sending from your domain has been taken over by someone else.
This is not a flaw in DMARC’s design. It is the boundary of what domain-level authentication is structurally capable of determining.
The Voicemail Lure and Evasion Stack
The CodeStorm kit delivers its phishing payload through a voicemail notification lure: a formatted email that mimics a genuine Microsoft communication, including a call duration, a reference ID, and a button labeled to open a voicemail portal. The visual design is indistinguishable from a legitimate enterprise notification.
Below the visible content, the kit appends a long block of dummy historical email thread content – a technique called conversation stuffing. Automated content scanners that classify messages based on thread context see what appears to be an ongoing business conversation, which reduces the probability of a spam or phishing classification.
When the recipient clicks through to retrieve the voicemail, they encounter a landing page protected by a Cloudflare Turnstile challenge that blocks automated analysis tools. The page actively checks for browser developer tools and automation signals, and terminates the session if it detects them. The page a human sees and the page a scanner sees are different environments.
The credential submission handler does not store credentials passively. It replays them against Microsoft’s authentication infrastructure in real time, producing genuine sign-in events in the victim’s Entra audit log. From the perspective of Microsoft’s systems, a legitimate user authenticated from an unfamiliar location.
What Account-Takeover Phishing Means for Deliverability and Trust
The implications extend beyond security. CodeStorm and similar account-takeover-based campaigns degrade the reputation of legitimate sending domains.
When a compromised M365 account sends phishing at scale, recipient providers observe a sudden change in sending pattern from that domain: different recipients, unusual volumes, content that generates spam complaints. Those signals feed sender reputation systems. A domain that has been used as a phishing vehicle – even through a compromised account rather than a spoofed one – can see its deliverability to major providers damaged even after the account is recovered and the threat removed.
Organizations that do not monitor their outbound email behavior have no way of knowing whether a compromised account has begun sending from their domain until recipient providers start deferring or rejecting their legitimate mail. By then, reputation damage is already accumulating.
The Signals That Can Catch This
Since DMARC cannot distinguish legitimate sending from account-takeover sending, other signal classes must do that work.
Entra sign-in anomalies. When CodeStorm replays credentials against a victim’s tenant, it generates Entra audit events. Unusual sign-in geographies, sign-in times that do not match the account holder’s patterns, and device fingerprints that differ from enrolled devices are all visible in Entra logs. Organizations monitoring these signals can detect account compromise before the sending phase begins.
Sending behavior baselines. Sudden increases in outbound volume from a specific account, sending to recipients outside the organization’s normal contact graph, and spikes in bounce rates or spam complaints are behavioral signals that sit above the authentication layer. DMARC aggregate reports show you which sources are sending on behalf of your domain. A source that was not there last week – or an existing source that has dramatically changed its behavior – is a flag worth investigating.
DMARC forensic reports. While RUA aggregate reports show sending volume and pass/fail rates by source, RUF forensic reports can include message samples from failing events. Even when an account-takeover campaign passes authentication, the sudden appearance of sending from cloud infrastructure not in your expected source set shows up in aggregate report data.
Post-compromise inbox rules. After gaining account access, attackers frequently create inbox rules to forward incoming mail or suppress delivery notifications. These rules are visible in M365 audit logs and serve as a secondary indicator of account compromise.
The DMARC Foundation Still Matters
None of this is an argument against DMARC enforcement. It is an argument for understanding what DMARC enforcement buys.
A domain at p=reject prevents external attackers – those without access to your infrastructure or a compromised account – from sending email that claims to be from your domain. That protection eliminates the majority of domain spoofing attacks. The EasyDMARC 2026 DMARC Adoption Report found that 52.1% of the top 1.8 million domains now have a DMARC record, up from 47.7% the prior year. But more than half of those records remain at p=none, the monitoring-only policy that stops nothing. Getting to p=reject is still the first, most impactful step most organizations can take.
What CodeStorm demonstrates is that p=reject is a floor, not a ceiling. An organization running enforcement-level DMARC eliminates spoofing from external parties. It does not eliminate the risk that an internal account gets compromised and weaponized. Both protections are necessary. Neither substitutes for the other.
Organizations that conflate “we have DMARC” with “our email is secure” are setting themselves up for a specific kind of surprise: authenticated phishing from their own domain, which passes every check and faces no delivery friction.
What to Do Now
If your domain sends email, three things are worth checking this week.
First, verify that your DMARC policy is at p=quarantine or p=reject. If you are still at p=none, every external actor who wants to spoof your domain can do so freely.
Second, review your DMARC aggregate reports for unexpected sending sources. Any IP range or mail service not in your known sending infrastructure sending on your behalf is a problem – whether it indicates a misconfigured service you forgot to authorize or an attacker using compromised access.
Third, establish a baseline for the outbound sending behavior of your M365 accounts. Know what normal volume, normal recipients, and normal geography look like for each account. When CodeStorm or a similar kit takes over an account, the behavioral deviation from that baseline is the signal you have.
Excello Mail gives you continuous visibility into your domain’s DMARC reports, sending sources, and authentication configuration across all your email streams. Sign up for free to Excello Mail and know exactly what is sending from your domain – before a compromised account tells you first.