Researchers at Check Point have documented a phishing campaign that skips the part security teams spend the most time training people to spot. Running from late June through the second week of July, the campaign sent more than 200 emails to roughly 120 organizations across a range of industries and countries, each disguised as a Microsoft Teams activity notification claiming HR had assigned the recipient a task. Clicking the link led nowhere fake. It led to a genuine Microsoft sign-in page, on Microsoft’s own domain, asking the victim to approve permissions for an application. Nothing about the page was forged, because nothing needed to be.
The Attack in Plain Terms
The lure itself is ordinary: a Teams-style notification claiming new activity from HR, engineered to get a click without much thought. What happens next is not ordinary. Instead of a cloned login form on attacker infrastructure, the link routes through a legitimate Microsoft OAuth authorization URL. A victim who signs in is not asked to hand over a password to a fake page, they are asked to approve permissions for a third-party application, with a prompt reading something close to “Accept on behalf of your organization.” Approving it does not steal a credential at all. It issues the attacker’s registered application a valid access token, with delegated permission to read mail, files, Teams messages, SharePoint, OneDrive, and calendar data, for as long as that grant stays active. No password changes hands. No multi-factor prompt gets defeated, because the victim completes it themselves, for real, on their own behalf.
Why DMARC Never Enters the Picture
This is worth sitting with longer than the usual lookalike-domain story. DMARC, SPF, and DKIM exist to answer one question: is this message’s sending domain who it claims to be. That question matters enormously for the initial notification email, and an organization with strong DMARC enforcement and vigilant users can still catch a forged sender at that stage. But the part of this attack that actually costs a victim their account access happens after the click, on a page that is not spoofed, not cloned, and not lying about its domain in any way, because it is simply Microsoft’s real infrastructure doing exactly what it was built to do: process an OAuth consent request. Email authentication has no jurisdiction over what a user chooses to click “Approve” on once they leave the inbox. That is a different trust boundary entirely, governed by application consent policy, not by anything DMARC evaluates.
The Blind Spot This Exposes
Security teams have spent years training defenses and users alike around a specific pattern: check the sender, check the domain, check the URL for a typo. This campaign was built by researchers who understood that pattern and designed around it. Check Point notes the technique has already been commoditized into a rentable phishing-as-a-service offering, which means the volume of campaigns using it is likely to grow well past this one disclosure. Every layer of email authentication can be working exactly as intended and this attack still succeeds, because the compromise happens one layer up the stack, in Entra ID’s application consent flow, a control surface most organizations have never configured beyond its default state.
The practical fix does not live in DNS. It lives in restricting what a user is even permitted to approve: requiring admin consent for any application requesting access beyond a narrow, pre-approved set of scopes, rather than leaving that decision to whichever employee gets a convincing enough Teams notification on a busy afternoon.
What This Means for Your Program
Review and restrict user consent settings in Microsoft Entra ID now, not after an incident. Default configurations in many tenants still let any user grant broad delegated permissions to unverified third-party applications, which is precisely the gap this campaign exploits.
Treat OAuth application grants as a monitored asset, the same way you monitor DMARC aggregate reports. Most organizations have visibility into who is sending mail as their domain and almost none into which third-party apps currently hold standing access to their users’ mailboxes and files.
Extend phishing awareness training past “check the URL.” A URL pointing to a genuine Microsoft domain will pass every check a trained user has been taught to run, which makes “does this application request make sense” a more useful question than “does this page look real.”
Keep DMARC enforcement in place regardless, since it still closes the door on outright spoofed sender domains. This campaign is a reminder that authentication is necessary but not sufficient, not an argument for skipping it.
The Takeaway
DMARC was never positioned to fail here because the part of this attack worth stopping happens entirely outside what DMARC evaluates. A domain owner can enforce a strict policy, keep every report clean, and still watch an attacker walk a victim through a completely genuine Microsoft sign-in screen toward handing over standing access to their account. Closing that gap takes application consent governance sitting alongside email authentication, not in place of it.
Excello Mail gives you continuous visibility into your DMARC enforcement and every source authorized to send under your domain, so you always know what your own authentication is actually protecting, and where its edges are. Sign up for free to Excello Mail and see exactly who is sending as you, all the time.