Microsoft Entra tenant branding abuse turns trust into phishing

At a glance

What this is: This is an analysis of Microsoft Entra tenant branding abuse that turns legitimate Microsoft security notifications into a phishing channel by manipulating tenant name fields.

Why it matters: It matters because identity and email controls built around trusted senders, allowlists, and authentication checks can be bypassed when the platform itself is used as the delivery mechanism.

By the numbers:

• Analysis of 2,000 messages across 250+ abused tenants revealed a scripted burn-and-churn operation using disposable Microsoft 365 free-trial tenants.

👉 Read Abnormal AI's analysis of Microsoft Entra tenant branding abuse

Context

Microsoft Entra tenant branding is supposed to let organisations customise identity-related communications, but that same customisation layer can become a delivery path for phishing when attackers control the values that appear in automated notifications. In this campaign, the abuse sits inside identity operations rather than outside them, which is why standard email trust checks fail to describe the real risk.

For IAM teams, the lesson is that tenant configuration is part of the attack surface. Once system-generated messages can be shaped by attacker-controlled fields, the security boundary moves from sender authentication to message intent, notification governance, and platform-abuse detection.

Key questions

Q: How should security teams detect phishing that comes from legitimate Microsoft identity workflows?

A: They should stop relying on sender reputation alone and inspect the notification context, body language, and tenant metadata that shaped the message. Identity workflow abuse often passes SPF, DKIM, and DMARC because the platform is genuine. The best defence is behaviour-based detection for unusual branding changes, callback numbers, urgency language, and Unicode obfuscation.

Q: Why do allowlists make Microsoft identity notifications easier to abuse?

A: Allowlists are built to preserve delivery of trusted security messages, but attackers exploit that trust by making malicious content arrive through the same path. If a rule exempts Microsoft verification mail, the organisation may no longer inspect content that looks operationally normal. That creates a predictable bypass for platform-assisted phishing.

Q: What breaks when tenant branding is not governed as a security control?

A: The organisation loses visibility into a field that can alter the text of security notifications seen by end users. That means an apparently harmless configuration change can become a phishing vector without touching mail infrastructure or compromising accounts. Tenant branding must be treated as governed identity state, not cosmetic metadata.

Q: How should IAM teams respond when a trusted platform can deliver malicious messages?

A: They should separate transport trust from content trust and review notification workflows as part of identity governance. That includes change control for message templates, monitoring for disposable tenant activity, and content analysis for social engineering cues. The goal is to reduce blind trust in system-generated identity mail.

Technical breakdown

How tenant branding becomes a payload delivery path

Microsoft Entra ID tenant branding lets administrators populate fields such as tenant name that are later inserted into automated system notifications. In this attack, the tenant name is not decorative. It becomes the text body of a verification message when Microsoft generates an email on the tenant’s behalf. The result is a system-authenticated phishing message that originates from legitimate Microsoft infrastructure and therefore inherits platform trust. The abuse does not require account compromise or a software exploit. It exploits how templated identity workflows reuse tenant metadata inside high-trust notifications.

Practical implication: treat tenant branding fields as externally influencing controls and monitor them as part of identity governance.

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

SPF, DKIM, and DMARC verify whether a message was sent by an authorised domain and mail path. They do not determine whether the content was maliciously shaped inside a legitimate workflow. That distinction matters here because Microsoft’s own infrastructure sends the message, so authentication succeeds even though the message is weaponised. This is a category error for defences that equate message authenticity with message trustworthiness. The attack exploits the gap between transport authenticity and content intent, especially when allowlists are built around trusted Microsoft sender addresses.

Practical implication: supplement sender authentication with content and workflow-context inspection for identity notifications.

How obfuscation defeats filters that look for obvious phishing signs

The campaign avoids the usual indicators that secure email gateways and OCR-based scanners rely on. There are no malicious links or attachments, only a phone number, and the text is distorted with Unicode homoglyphs and letter-for-digit substitutions to confuse regex rules and OCR. That combination makes the attack resilient against IOC-driven controls because the payload is embedded in the semantics of the notification, not in a file, URL, or attachment. The burn-and-churn model also limits the value of static indicators because the tenants are disposable.

Practical implication: tune detection for semantic anomalies in notification language, not just links, files, or sender reputation.

Threat narrative

Attacker objective: The attacker aims to deliver highly trusted phishing messages that bypass inbox protections and induce victims to disclose information or engage with the scam.

1. Entry begins when the attacker creates disposable Microsoft 365 tenants and configures tenant branding fields to shape future system notifications.
2. Escalation occurs when Microsoft’s Security Info workflow is abused to trigger legitimate verification emails to targeted recipients, giving the attacker a trusted delivery channel.
3. Impact is achieved when the phishing message passes authentication checks, lands in the inbox, and directs the recipient to call an attacker-controlled number.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Platform-generated identity messages have become an attack surface, not a trust anchor. This campaign works because organisations still treat Microsoft-originated identity notifications as inherently trustworthy when they are only platform-authenticated. That assumption is too weak for tenant-configurable workflows, where attacker-controlled metadata can shape the final message content. Practitioners need to recognise notification governance as part of identity security, not just email hygiene.

Tenant branding abuse is a message-integrity problem disguised as a configuration issue. The exploitable control is not a mailbox, domain, or compromised account. It is the ability to inject attacker intent into a legitimate system template through tenant fields. That makes the relevant failure mode closer to trust-boundary collapse in identity workflows than classic spoofing. Security teams should classify these settings as security-relevant state and review them with the same discipline applied to privileged configuration.

Allowlisting Microsoft verification senders creates a predictable bypass path for platform abuse. When organisations exempt [email protected] to preserve MFA delivery, they also reduce their ability to inspect the very messages attackers now weaponise. The problem is not the allowlist alone, but the assumption that trusted delivery and trusted content are the same thing. That premise fails under system notification abuse, and it should force teams to separate transport trust from content trust.

Subject Line Hijack: identity notifications now carry attacker-controlled narrative payloads. The named concept here is not just phishing, but the conversion of a tenant branding field into a narrative injection point inside a security workflow. That matters because the abuse targets cognition, not infrastructure, by making the alert look like an urgent account or billing notice. Practitioners should treat the notification template itself as a governed asset with a measurable abuse surface.

Static IOC-centric controls are structurally outmatched by burn-and-churn platform abuse. The campaign’s disposable tenants, legitimate Microsoft links, and text-only payloads remove the signals many email tools are built to chase. That means the defensive model has to shift from signature detection to behaviour and context analysis. For identity teams, the broader lesson is that platform trust can be operationalised as a delivery channel unless configuration changes are continuously monitored.

From our research:

• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
• For a broader governance lens, read Top 10 NHI Issues for the control failures that let platform abuse and identity sprawl persist.

What this signals

Notification governance now belongs inside identity programmes. Teams that manage Entra ID, Microsoft 365, or MFA delivery cannot treat branded security mail as a low-risk UX layer anymore. The operational signal to watch is any configuration path that can change what users see in a trusted identity workflow, especially when allowlists and exception rules are already in place.

The campaign also shows why message authentication and trust are diverging. A platform can authenticate a message perfectly and still deliver attacker-shaped content, so programmes need controls that inspect wording, workflow context, and account-enrolment behaviour rather than only sender identity.

With 6 distinct secrets manager instances on average, fragmentation already weakens central oversight in many environments. The same governance pattern appears here: once trust is distributed across too many configuration paths, the organisation loses the ability to see where identity workflows can be bent into delivery mechanisms.

For practitioners

• Inventory tenant fields that influence outbound identity messages Identify every Entra ID or Microsoft 365 field that can appear in automated security notifications, then classify it as security-relevant configuration. Review who can change tenant branding, how changes are approved, and whether those changes are logged for detection and audit.
• Replace sender-only trust with content-aware detection Build detections for financial pressure language, support-desk call-back numbers, and Unicode lookalike characters inside identity notifications. Correlate those signals with message origin, workflow type, and tenant metadata rather than relying on SPF, DKIM, DMARC, or mail allowlists alone.
• Review allowlists that exempt Microsoft verification mail Test whether inbox rules that exempt [email protected] create blind spots for abuse of Security Info or MFA workflows. If the allowlist is necessary, pair it with stronger inspection of the notification body and with alerts for unusual tenant branding changes.
• Monitor for disposable tenant creation patterns Look for bursts of free-trial tenant creation, repeated Security Info enrolment activity, and rapid name-field changes across short-lived Microsoft 365 instances. Those behaviours are stronger abuse indicators than message headers when the attacker is using burn-and-churn infrastructure.

Key takeaways

• This campaign shows that identity platform configuration can be abused to deliver phishing from a trusted Microsoft channel.
• The evidence points to a scalable burn-and-churn model built on disposable tenants, text-only payloads, and defence evasion rather than classic spoofing.
• The most relevant control shift is from sender trust to governed notification content, because that is where the abuse now lives.

Key terms

• Tenant Branding: Tenant branding is the set of configurable fields that shape how an identity platform presents an organisation in user-facing communications. In this abuse pattern, those fields become security-relevant because they can alter the text inserted into legitimate system notifications and be used to inject phishing content.
• Platform-assisted Phishing: Platform-assisted phishing uses a trusted service’s own infrastructure to deliver malicious or deceptive content. Instead of spoofing sender identity, the attacker abuses legitimate workflows, templates, or metadata so the message authenticates correctly while still carrying harmful intent.
• Notification Governance: Notification governance is the control of who can shape identity-related messages, what text appears in them, and how those messages are monitored. It matters because automated notifications are part of the trust chain, and configurable content can become an attack path when not reviewed as security state.
• 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.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Abnormal AI: Microsoft Entra tenant branding abuse turns trust into phishing. Read the original.