June 11, 2026

How a Single KQL Query Stopped an Entire EvilTokens Phishing Campaign

Back in April of this year, an AI-powered phishing campaign known as EvilTokens took the spotlight in the infosec world. While the term…

Matt Swann

3 min read

Back in April of this year, an AI-powered phishing campaign known as EvilTokens took the spotlight in the infosec world. While the term "AI-powered" is often used as a buzzword these days, it was certainly fitting for this campaign as an article by Huntress outlined the use of AI in bypassing email filters, generating phishing lures, and even identifying potential targets for the campaign. Adding to the power of the EvilTokens campaign was the fact that it was sold as a Phishing as a Service (PhaaS) platform for as little as a few hundred dollars USD, with full access to the platform costing a mere $1,500, trivial for most cybercrime organizations.

The EvilTokens campaign can be identified by a number of indicators. First, despite AI generating a number of unique subject lines, the overall lure theme revolved around a small handful of topics, including themes of bid proposals or RFPs, bogus DocuSigns, fake voicemails, and bogus HR documents. Next up was the use of legitimate security vendor redirects using URLs related to Trend Micro, Mimecast, and Cisco to give the impression of it being a legitimate link, which would then redirect to the actual phishing landing page. On top of these, the campaign also leveraged high-reputation serverless platforms such as Vercel, Cloudflare Workers, and AWS Lambda to host the redirection, further obfuscating the phishing traffic, as reported by Microsoft. Ultimately, the phishing lure would land at a device code authorization flow page, a phishing technique growing in popularity among threat actors that seeks to trick the victim into copying the device code provided (and controlled by the attacker) into a legitimate Microsoft authorization prompt, thereby giving the attacker access to the victims M365 account, enabling token theft and ultimately, unauthorized access into the victim's M365 tenant.

With the above in mind, detecting the campaign is actually quite simple. In one campaign observed by the author, phishing emails matching all of the above characteristics were hitting user inboxes being spoofed as coming from the potential victim themselves. The spoofing should immediately throw red flags on SPF, DKIM, and DMARC, and indeed it did, though the email protections at the time this campaign occurred did not stop these spoofed emails from hitting user inboxes rather than quarantine or junk boxes. Thankfully, through the use of a single KQL detection query and Microsoft Defender for Endpoint (MDE) automation rules, we can create a workflow that quickly deals with these emails.

Let's start with the below KQL query:

EmailEvents
| where tolower(RecipientEmailAddress) == tolower(SenderFromAddress)
| extend DKIMcheck = tostring(parse_json(AuthenticationDetails).DKIM)
| extend DMARCcheck = tostring(parse_json(AuthenticationDetails).DMARC)
| where DKIMcheck contains "none" and DMARCcheck !contains "pass"
| where DeliveryLocation contains "Inbox/folder"
| where not(EmailDirection contains "Intra-org")
| project TimeGenerated, DKIMcheck, DMARCcheck, DeliveryAction, DeliveryLocation, RecipientEmailAddress, SenderFromAddress, SenderIPv4, Subject, NetworkMessageId, EmailDirection

This query leverages the EmailEvents table available in Microsoft Sentinel and MDE, which logs email activity within the M365 tenant. We're looking at emails specifically where the sender and recipient are identical, indicating the aforementioned spoofing. From there, we extract additional DKIM and DMARC details from the JSON-formatted AuthenticationDetails column, and filter to find only emails that fail both. Last, we filter on DeliveryLocation showing emails that only land in user inboxes, and filter out Intra-org communication to remove false positives. This query showed a 100% success rate at catching every single phishing email attributed to the EvilTokens campaign.

Once this query is operationalized in MDE, you have the options to set automated actions any time the query fires. An unfortunate intricacy of MDE is that while many tables do allow for Near Real Time (NRT) querying and actions, some (including EmailEvents) do not allow for NRT actions, though the next best option is every 5 minutes. For this query, we can set the MDE automated action every 5 minutes to delete any emails this query detects on, with the end effect being that while emails may technically still hit user inboxes, they are soft deleted within 5 minutes, most often likely before the user has the opportunity to view the email ( and thus follow the link and potentially be phished).

Within 48 hours of implementing this query and automation, over 1,200 malicious emails were prevented from being accessed by users, virtually nullifying the entire campaign's effect on the target organization.

With powerful AI becoming commonplace in both the attacker and defender lifecycle, the barrier to entry for sophisticated phishing has never been lower, and defender should expect campaigns like this to become the norm rather than the exception. But as flashy as the "AI-powered" label may be, this campaign also proves that the fundamentals still win. A single well-crafted KQL query paired with a 5 minute automation loop was enough to neutralize over 1,200 malicious emails over 2 days. No expensive tooling, no LLMs, just a sharp eye for the anomalies attackers can't avoid creating. The takeaways for defenders is simple: when attackers innovate at the lure layer, look for the unchanging fundamentals underneath.