Tuesday, 10:44 AM. Seven people at a specialty insurance firm receive a routine system alert. "The Power Automate flow has failed." Application: Intranet(DEX). Flow name: RequestNewsPromotionCore. Failure time stamped to the second.
One of them reports it. The platform flags it. The tenant closes it as a false positive.
That last part is the story.
The message looked exactly like what Power Automate sends when an automated workflow breaks. Plain layout, technical detail, a single link to review the failed run. The kind of alert that lands in an IT inbox a dozen times a week and gets handled in thirty seconds: click, check, close.
The sender display name was zsrv_IntranetServiceAccount. That matched a real internal service account pattern the organization used for SharePoint and intranet automation. The link in the body pointed to flow.microsoft.com, a legitimate Microsoft domain. Proofpoint had already scanned and wrapped it. Both URLs returned clean verdicts.
Nothing about the content said "phishing." There was no credential request, no urgency, no "your account will be suspended" language. It looked exactly like the real thing because, in almost every visible way, it was constructed to be indistinguishable from the real thing.
The one difference: the sending address was zsrv_IntranetServiceAccount@[organization]test.onmicrosoft.com. One word appended to the company name in the tenant subdomain. The word "test."
It was even in the subject line: "Flow Failed - RequestNewsPromotionCore (Test environment)."
Here is the thing about Microsoft 365 test tenants that most security teams don't fully internalize: any organization, or any individual, can register one. Free trial, developer account, sandbox environment. The onmicrosoft.com subdomain is available to anyone who signs up. Microsoft owns the parent domain. The tenant names, however, are first-come.
The attacker registered [organization]test.onmicrosoft.com, a subdomain that appends "test" to the real company's production tenant name. From that tenant, they created a service account whose display name, zsrv_IntranetServiceAccount, was close enough to the real internal account zsrv_SPO-Intranet_Service_Account that a quick visual scan wouldn't catch the difference.
Then they used Power Automate itself, or tooling that mimics its notification format, to generate a flow failure alert. The URLs embedded in the email were real Power Automate management URLs pointing at a flow run GUID inside the attacker's test environment. Those URLs scanned clean because they resolve to legitimate Microsoft infrastructure. There was no malicious payload at the link destination, at least not one that a scanner would find. The goal wasn't a drive-by download. It was a pretext: get someone to click into a Microsoft portal context they believe is their own, and handle authentication from there.
According to the Verizon 2024 Data Breach Investigations Report, over 68% of breaches involve a human element, and pretexting attacks that impersonate trusted internal systems have become one of the highest-conversion phishing vectors. This case is a precise illustration of why.
See how many phishing emails are getting through your filters.
The email traveled a specific path. It originated from Microsoft's outbound infrastructure (the attacker's test tenant), then passed through a Proofpoint gateway before entering the target organization's Exchange Online environment. That routing introduced a problem the attacker may not have fully accounted for, but which nearly saved everyone the trouble.
The ARC chain broke.
ARC, or Authenticated Received Chain, is the mechanism that preserves email authentication results across forwarding hops. The first ARC seal (i=1) showed SPF pass and DKIM pass for [organization]test.onmicrosoft.com. The second seal (i=2) showed cv=fail. Proofpoint's re-injection had disrupted the chain. The final authentication result at the Microsoft protection layer showed SPF fail and DKIM none, with DMARC result of "none" because the test tenant had no DMARC policy configured at all.
That combination, broken ARC, SPF fail, absent DMARC, would typically trigger scrutiny. But there's a catch that experienced attackers count on: Proofpoint is a known and trusted gateway. When security tooling sees that the SPF failure is attributable to a recognized email security relay, it frequently deprioritizes the anomaly. The message got through with a spam score of zero. Proofpoint's own verdict: rule=inbound_notspam.
This is the authentication paradox created by layered security infrastructure. The very tool deployed to protect the organization provided cover for the attack by making the authentication failure look like a routine forwarding artifact. Microsoft's own Digital Defense Report noted that attackers are increasingly exploiting the blind spots created by security tooling interactions, rather than trying to defeat individual tools head-on.
Themis caught it. Not with high confidence, and not on the basis of URLs or content. The confidence score was 68%, which reflects genuine ambiguity in the case. What it flagged was the display-name relationship.
The sending account name, zsrv_IntranetServiceAccount, was similar enough to a real recipient-side account, zsrv_SPO-Intranet_Service_Account, to trigger an impersonation tag. Not identical. Not an obvious clone. Similar in the way that a display name would look if someone was trying to approximate an internal naming convention without access to the exact account name.
That's the detection signal that mattered: behavioral proximity between the sender's display name and known internal identities, evaluated against directory data in real time. No URL was malicious. No attachment existed. No explicit social engineering phrase appeared in the body. The phishing indicator was entirely in the identity layer.
The incident was quarantined across four mailboxes. Then the tenant reviewed it, concluded it was a legitimate flow failure from their own infrastructure (it wasn't), and closed it as a false positive.
Which means, from the attacker's perspective, the campaign achieved plausible deniability. The message was delivered, reviewed by a human, and accepted as authentic. The organization's own judgment became the final layer of defense, and it failed.
The practical takeaways from this case aren't about a single exotic technique. They're about a structural gap that exists in almost every M365 environment.
Test tenant subdomains don't get the same scrutiny as production domains. Security teams monitor their primary domain's authentication records, DMARC policies, and registered tenants. They rarely audit which subdomains on onmicrosoft.com are available and could be registered by an outsider. CISA's guidance on Microsoft 365 security hardening addresses tenant configuration but doesn't specifically address the test subdomain registration attack surface.
DMARC absence on a test tenant is a red flag, not a coincidence. Legitimate Microsoft service notification emails come from properly authenticated tenants with published DMARC policies. When a "system alert" arrives from a domain with no DMARC record, that's a meaningful signal even if every other indicator looks clean.
Display-name proximity detection matters more than URL scanning for this class of attack. Both links in this email scanned clean. There was no malware, no redirect chain, no suspicious domain. The only technical indicator of compromise was in the sender's identity. Detection systems that rely primarily on link reputation or content analysis will miss this entirely.
The false positive resolution is itself a data point. When an organization closes a detected phishing incident as a false positive, it's worth asking whether the reviewer had access to the sender's tenant origin, the ARC chain history, and the DMARC result, or whether they were looking at the same rendered view the original recipient saw. Those are very different levels of information. The IRONSCALES community sees this pattern: incidents that look like internal automation alerts are the category most likely to be misclassified during review.
Across the threat intelligence cases tracked in this series, test tenant impersonation is an emerging pattern. Attackers are moving away from lookalike domains with new registrations toward Microsoft's own infrastructure, where the parent domain reputation is unimpeachable and the only tell is in the subdomain string, the ARC chain, and the display-name delta.
Those tells are subtle enough that a human will miss them. Behavioral AI, running against directory data in real time, is the layer that caught it here.
---
Defanged IOCs
| Type | Indicator | Context |
|---|---|---|
| Sender domain | [org]test[.]onmicrosoft[.]com | Attacker-controlled test tenant; anonymized org prefix |
| Sending IP | 52[.]101[.]96[.]109 | Microsoft outbound relay (attacker's test tenant) |
| Proofpoint relay | 91[.]207[.]212[.]167 | mx07-001fe601[.]pphosted[.]com (Netherlands), re-injection hop |
| Flow URL | hxxps://flow[.]microsoft[.]com/manage/environments/Default-9f3579cb[...] | Legitimate Microsoft URL pointing to attacker's test tenant environment |
| Power Automate URL | hxxps://make[.]powerautomate[.]com/manage/environments/Default-9f3579cb[...] | Same environment GUID as above |
| Environment GUID | 9f3579cb-d5b3-44c9-9b40-ad40cd327245 | Attacker's test tenant environment identifier |