The Attachment Said .htm, the MIME Said .docx, and Microsoft's Name Did the Rest: An M365 Domain-Expiry Credential Harvest

The email subject read "Domain Expiry Alert - Action Required." The display name said Microsoft Domain Expiry. The reply path pointed toward no-reply@team.microsoft.com. None of those strings came from Microsoft.

The real From header showed an attacker-controlled domain with no relationship to any registrar, no authorization to send for Microsoft, and a DMARC result of fail. The body contained only Outlook safety banners with links to support.microsoft.com and aka.ms. Those were legitimate Microsoft properties inserted automatically by the receiving mail platform, not links placed by the attacker. There was nothing in the body to flag. The credential lure was in the attachment, and the attachment was designed to look like the wrong kind of file.

The display-name illusion and why the body links did not help

Display name spoofing costs nothing to execute. No domain ownership is required, no authentication record needs to be set up, and no registration is involved. The attacker placed "Microsoft Domain Expiry" into the friendly-name field of the From header. Email clients render that string prominently. The actual sending address, on a domain that has nothing to do with Microsoft, is often truncated or hidden entirely depending on client and display width.

Recipients saw a familiar brand name associated with a high-urgency action item: their domain was expiring and required immediate attention. The subject line reinforced the pressure. What they did not see was that the sending domain had failed DMARC alignment, that the SPF check at the originating hop had returned a softfail because the sending IP was not listed in the domain's policy, and that the DKIM signature present was for a Microsoft 365 tenant identifier rather than the attacker's From domain, a misalignment that is itself a red flag. The tenant-domain DKIM pass at the Microsoft relay hop is an artifact of Exchange Online Protection forwarding, not evidence of authorization from the claimed sender.

Legitimate domain-expiry notices from actual registrars arrive from authenticated infrastructure aligned to a known registrar brand. They carry an account reference, a renewal path, and a clear record of the registrar relationship. This message had none of those elements.

The attachment's double identity

One file arrived with the message: a 6.6 KB attachment named after a Microsoft 365 Admin Portal login summary. The filename ended in .htm. The MIME content-type header declared it an OpenXML word-processing document, the format used by modern Word files.

That contradiction is deliberate. Attachment-classification pipelines that trust the declared MIME type would route this file toward Office-document analysis. Office-document analysis looks for macros, embedded objects, and known exploit patterns. An HTML page inside an Office-labeled wrapper may never be rendered as HTML. If it is not rendered, the credential-harvest form it contains never executes, and there is no URL or network callout to score.

This technique sits at the intersection of HTML smuggling and file-type masquerading. The credential form lives in markup that only activates when a browser processes the file locally, from the victim's own filesystem. No remote server needs to serve anything. URL reputation services have no destination to fetch. Sandbox tools that execute the attachment would see the full behavior, but not every gateway runs execution-level sandboxing on files declared as word-processing documents.

The attachment's probable function, given its theme and size, is to render an offline Microsoft 365 admin login page that submits the victim's credentials to attacker-controlled infrastructure: the textbook credential harvesting pattern.

What the authentication stack actually said

The origin IP for this message, 31.58.144[.]12, had no reverse DNS entry and geolocated outside the region of the claimed sender. The SPF check at that first hop returned a softfail: the IP was not listed in the sending domain's policy. The DKIM signature that passed was for a Microsoft 365 tenant identifier, not for the From domain haoranchalerkotha[.]com; that misalignment caused DMARC to fail against the From header.

The subsequent hops through Microsoft's Exchange Online Protection infrastructure earned their own authentication passes because EOP is doing what it is supposed to do with inbound mail. Those internal relay passes do not validate the external originating sender. They are a normal artifact of mail flow through Microsoft's protection stack and carry no exculpatory weight for the message's claimed identity.

The sending domain's own DMARC policy was p=none: monitoring only, no enforcement. Even if alignment had been checked and found wanting, p=none instructs receivers to report the result and deliver the message anyway.

Indicators of compromise

What the detection surface looked like to a legacy gateway

A secure email gateway inspecting this message at the content layer found body links that resolved cleanly to Microsoft properties. There was no malicious URL to score in the message body. The attachment carried an Office-document MIME declaration, which may have directed it toward a less aggressive analysis path. The DMARC failure was available as a signal, but with p=none, policy enforcement provided no automatic block. The display-name mismatch between a Microsoft brand string and an unrelated From domain is precisely the gap that requires header-level identity analysis beyond what URL and attachment reputation checks cover.

Behavioral and identity-layer analysis changes that calculus. IRONSCALES' Adaptive AI (Themis) reads the relationship between the display name, the actual From domain, and community-level reputation to flag the identity inconsistency before the attachment is ever opened. The authentication failure and the MIME mismatch both add signal weight.

CISA's phishing guidance and the FBI IC3 2024 report both note that urgency lures tied to account or service expiry are among the most reliably effective pretexts because they threaten a real business consequence. Verizon's 2026 Data Breach Investigations Report attributes 62 percent of breaches to the human element. The lure was a routine IT maintenance notice, and nothing about it required technical sophistication to produce.

See Your Risk: Calculate how many threats your SEG is missing

The credential form never needed a live server. It never needed a domain to score. It needed only a recipient who opened an attachment because the display name said Microsoft and the subject said urgent. The entire attack lived in six and a half kilobytes, mislabeled as the wrong kind of file.