Microsoft Entra tenant branding abuse turns trust into phishing

At a glance

What this is: Attackers manipulated Microsoft Entra tenant branding and security-info workflows to make Microsoft send phishing messages that looked authentic and bypassed normal email authentication checks.

Why it matters: IAM and security teams need to treat tenant-controlled notification content as an identity-governance problem, because trusted delivery channels can be weaponized without compromising the sender domain.

By the numbers:

• Analysis of 2,000 messages across 250-plus abused tenants showed a scripted burn-and-churn campaign.

Context

Microsoft Entra tenant branding is supposed to help organisations present consistent identity messaging, but tenant-controlled fields can also shape the content of system-generated notifications. When those fields are abused, the platform itself becomes part of the phishing delivery path rather than just a branding layer.

This is an identity and trust problem as much as an email problem. The attack worked because recipients were trained to trust Microsoft security notifications, and because delivery came from legitimate Microsoft infrastructure that made the message look and behave like an authentic account workflow.

The article’s central point is that allowlisted, authenticated, and platform-native messages are not automatically trustworthy. For IAM teams, the governance question is who can influence identity notifications, what content they can inject, and whether verification workflows are being used as a delivery mechanism for fraud.

Key questions

Q: What breaks when identity notifications can be edited by tenant admins?

A: When tenant-controlled fields flow into system notifications, the notification channel stops being a neutral delivery mechanism and becomes part of the attack surface. Security teams lose the ability to assume that a legitimate sender implies legitimate content, so branding, approval, and audit controls matter as much as mail authentication.

Q: Why do SPF, DKIM, and DMARC not stop this kind of phishing?

A: They validate message authenticity signals, but they do not prove the communication is safe or legitimate in context. Attackers can still send technically valid emails that contain a phone number and rely on social engineering after the recipient calls. Identity and support workflows remain exposed even when mail authentication passes.

Q: What are the signs that identity notification workflows are being abused?

A: Look for tenant-name abuse, callback numbers in verification emails, long scam text inserted into branding fields, and Unicode lookalikes that defeat scanning. A sudden increase in trial tenants or repeated security-info enrolment attempts can also indicate a scripted campaign rather than normal user activity.

Q: How should organisations govern allowlisted Microsoft security mail?

A: Treat allowlisted identity mail as a controlled workflow instead of a permanent exception. Validate the content, the enrolment path, and the administrative rights that can shape the message. If trusted sender logic is not paired with content inspection, the allowlist becomes a delivery guarantee for abuse.

Technical breakdown

How tenant branding becomes a payload carrier

In Microsoft Entra ID, tenant branding fields can flow into system-generated email templates, including account verification and security notifications. If an attacker can write malicious text into a tenant name or related branding field, that content may appear in the subject line or body of a legitimate Microsoft message. The attack is not classic spoofing because the sender is real. Instead, the platform’s own notification logic is being used to carry attacker-controlled text, which makes the resulting email hard to distinguish from normal identity traffic.

Practical implication: review which tenant branding and notification fields can influence identity communications and restrict them to tightly governed administrators.

Why SPF, DKIM, and DMARC do not stop this abuse

SPF, DKIM, and DMARC validate that mail came from an authorised domain and has not been altered in transit. They do not verify whether the content inside a legitimate message is benign, expected, or socially engineered. In this campaign, the email originates from Microsoft infrastructure, so authentication succeeds by design. That means sender-based controls can confirm origin while still delivering harmful content, especially when the threat is embedded in platform-generated text rather than in a forged From address.

How obfuscation defeats content filters and OCR

The campaign used Unicode homoglyphs, letter-for-digit substitutions, and long tenant-name strings to frustrate keyword filters, regex rules, and OCR-based scanning. That matters because many email gateways still rely on surface patterns such as obvious URLs, attachments, or standard scam phrasing. Here, the message can contain only text and a phone number, while the visible wording is manipulated to look legitimate to a human and unstable to automated detection. The result is a notification that appears low-risk to static controls but high-credibility to the recipient.

Practical implication: add semantic and behavioural analysis for identity notifications instead of relying on string matching and IOC-driven filters.

Threat narrative

Attacker objective: The attacker’s objective is to induce victims to contact a fraud number or disclose information by making a phishing message appear to come from Microsoft itself.

1. Entry begins with a disposable Microsoft 365 free-trial tenant that the attacker creates for abuse.
2. Credential or workflow access is obtained through the legitimate Security Info registration path, which the attacker uses to trigger Microsoft’s notification logic toward the target.
3. Escalation occurs when tenant branding and obfuscation are used to inject scam text into authentic Microsoft messages that bypass sender-authentication checks.
4. Impact is phishing delivery from trusted infrastructure, with the recipient pushed toward a fraudulent callback flow rather than a malicious link.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Entra ID actor token flaw (CVE-2025-55241): Hidden Actor tokens plus an Azure AD Graph validation flaw could have let attackers become Global Admin in any Entra ID tenant (CVE-2025-55241).

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Tenant-controlled identity notifications are now a phishing surface, not just an administration detail. The abuse here is not limited to message styling. It shows that identity platforms can inherit an attacker’s content if tenant-managed fields flow into system templates. That turns branding and verification workflows into governance objects, because the security question becomes who can influence trusted notifications and how that influence is bounded.

Platform authentication and message trust are no longer the same control. SPF, DKIM, and DMARC can prove that a message came from Microsoft infrastructure, but they cannot prove the content is safe or expected. That gap matters because identity and access teams often rely on sender authenticity as an implicit trust signal for verification traffic. The implication is that platform-originated identity mail needs content governance, not just transport assurance.

Burn-and-churn tenant abuse is a lifecycle problem, not a one-off abuse case. The article describes disposable Microsoft 365 tenants created for short-lived campaigns, which means the real issue is rapid provisioning with no meaningful offboarding pressure. That pattern is familiar across NHI governance: ephemeral identities can be created faster than abuse can be reviewed. The practitioner conclusion is that lifecycle controls must extend to tenant creation, notification rights, and post-creation monitoring.

Semantic phishing defeats IOC-first email security models. The campaign intentionally removed the usual hooks that gateways look for, such as malicious links or attachments, and replaced them with phone-based fraud and text obfuscation. That creates an identity-driven attack path where trust is triggered by workflow context rather than technical indicators. The named concept here is identity notification abuse: when legitimate platform notifications are repurposed to deliver attacker-controlled content, defenders must govern the notification channel as a high-trust asset.

Allowlists for security mail create a trust trap when the sender is legitimate but the intent is hostile. Many organisations allowlist Microsoft security senders to avoid blocking MFA and account verification traffic. That is operationally understandable, but it also creates a delivery guarantee for abuse that originates inside a trusted workflow. The field implication is that IAM teams need to treat allowlisted identity mail as a governed workflow with abuse detection, not as a permanently trusted exception.

From our research library:

• Roughly 1 in 3 phishing payloads are delivered outside email, through channels such as social media, search ads and messaging apps.

What this signals

Identity notification abuse: The article shows how trusted platform messages can be converted into phishing delivery mechanisms when tenant-managed fields are allowed to shape system communications. That shifts the control point from mail authentication to notification governance, content validation, and admin-rights review.

Security teams should assume that allowlisted identity mail can be hostile even when it is technically authentic. The practical test is whether the organisation can inspect and constrain the content of verification flows before they reach the inbox.

The wider signal is that identity platforms now carry an abuse path through their own UX and workflow design. Teams that only harden sender domains will miss the real failure mode, which is trust being encoded into system-generated messages.

For practitioners

• Tighten tenant-branding permissions Limit who can edit tenant name and notification-related fields in Microsoft Entra ID, and review whether those fields are allowed to flow into system-generated emails.
• Replace static allowlists for identity mail Stop treating [email protected] and similar senders as unconditional trust signals, and apply content inspection to identity notifications before delivery.
• Detect obfuscation in verification traffic Look for homoglyphs, letter-for-digit substitutions, and unusually long tenant strings in account-verification messages, especially when the message contains a callback number.
• Monitor disposable tenant creation patterns Flag bursts of Microsoft 365 trial tenants and rapid security-info enrolment activity as a potential burn-and-churn campaign rather than routine onboarding.

Key takeaways

• The core failure is not email spoofing but the abuse of trusted identity workflows to deliver fraudulent content from legitimate infrastructure.
• The campaign analysed 2,000 messages across more than 250 abused tenants, which shows this was a structured operation rather than an isolated incident.
• Defenders need to govern tenant branding, verification workflows, and identity-mail allowlists together, because sender authentication alone does not protect trusted notifications.

Key terms

• Identity Notification Abuse: A misuse pattern in which legitimate identity or account notifications are altered, redirected, or repurposed to deliver malicious content. The message may still be authentic at the transport layer, which makes governance of the notification workflow and its editable fields critical.
• Tenant-aware Branding: Tenant-aware branding is the ability to present different logos, colours, labels, or journeys for different customers or organisations within one identity platform. It matters when the same authentication stack must serve multiple brands without splitting governance or audit controls.
• Burn-and-Churn Operation: A burn-and-churn operation creates short-lived infrastructure to deliver attacks at scale and then discards it before defenders can build durable detections. The pattern reduces the value of static indicators and forces defenders to focus on behavioural patterns rather than persistent assets.
• Unicode Homoglyph Obfuscation: A technique that uses visually similar Unicode characters to disguise code or text while preserving execution. In Python, lookalike identifiers may normalize to the same parsed name, which lets attackers hide malicious logic from reviewers and exact-match detection tools. This is especially relevant in software supply chain attacks and package review workflows.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.