Sophos URL Rewrite Hiding an is.gd Shortener Chained to an Azure Front Door Endpoint

The email arrived with a subject line referencing a consulting agreement document and a filename that trailed off with ellipses. The body contained no explanatory text. There was no greeting, no signature, no context. Just a single link, formatted to look like a document access button, and a second URL in the footer. Microsoft Outlook quarantined it with a spam confidence level of 5.

Neither link revealed where it actually went without executing the redirect chain.

A Security Tool's Own Rewrite Mechanism Used as Cover

The primary link in the email was routed through us-west-2.protection.sophos[.]com, the Sophos URL protection rewriting service. That wrapping is normally a defensive feature: Sophos rewrites URLs to proxy click-time scanning, replacing the original destination with a Sophos-hosted proxy URL.

Here, the attacker placed an is[.]gd shortened URL as the destination behind the Sophos rewrite. The structure was: Sophos proxy URL pointing to an is[.]gd shortener, which in turn pointed to an unknown final destination. Because is[.]gd resolves its redirect dynamically, any static analysis of the Sophos-wrapped link would see only the shortener, not the payload.

This is a deliberate double-wrapping technique. The Sophos rewrite creates an implicit trust signal (a recognizable security vendor's domain in the link). The is[.]gd shortener beneath it hides the final destination from any scanner that does not follow all redirects to their terminal endpoint and inspect what loads there.

The ?d=is.gd parameter visible in the Sophos proxy URL confirmed the shortener as the first hop after the rewrite resolved. Final destination: unknown at delivery time, by design.

A Second Link on Azure Front Door Infrastructure

The email carried a second URL pointing to microstandard-esfbdtcjhrcxdmcx.z01.azurefd[.]net, an Azure Front Door endpoint with a randomized subdomain. Azure Front Door subdomains under azurefd.net are Microsoft-issued, carry valid TLS certificates from Microsoft's certificate infrastructure, and appear under a Microsoft-owned domain.

Phishing operators create Azure Front Door profiles to proxy attacker-controlled origin servers. The subdomain randomization pattern visible here ("esfbdtcjhrcxdmcx") is consistent with programmatically generated Front Door profile names, a common indicator in cloud-hosted phishing infrastructure. The endpoint itself had no prior blocking history at delivery time.

Two links. Two different cloud-provider domains. Neither was a clearly attacker-controlled hostname. Neither could be blocked on the basis of domain reputation at delivery time.

The Sender: SPF Without DKIM or DMARC

The sending domain, hinet[.]net, is a long-established Taiwan ISP domain registered in 1994 with documented MX infrastructure. SPF passed for the sending IP 210[.]65[.]1[.]144 (PTR: 210-65-1-144.hinet-ip[.]hinet[.]net). No DKIM signature was present on the message. The _dmarc.hinet[.]net record returned NXDOMAIN, indicating the domain had published no DMARC policy at all.

SPF passing on an established ISP domain provides legitimate-looking authentication while hiding nothing about the message's actual intent. The relay path ran through cmsr2.hinet[.]net and cdmsr1.hinet[.]net before entering Microsoft's protection layer, consistent with outbound mail from a Taiwan ISP subscriber.

The sender had no prior relationship with the recipient organization. It was logged as a first-time external sender. The subject referenced a document ("Consulting_Agreement_-_02_22_26.docx...") that no one at the receiving organization had requested.

Why the URL Chain Matters More Than the Sending Domain

The fundamental detection challenge here is that every component of this email, taken in isolation, has some claim to legitimacy. hinet[.]net is a real ISP. us-west-2.protection.sophos[.]com is a real security vendor's rewrite service. is[.]gd is a real URL shortener. azurefd[.]net is real Microsoft cloud infrastructure.

The malice lives in the combination and the intent. A near-empty body with no explanatory context. A subject line naming a consulting agreement that was never requested. A primary link that runs through two redirect hops to an unknown destination. A secondary link to a randomized Azure Front Door endpoint.

Social engineering at this technical layer does not require a recognizably malicious domain name. It requires assembling enough legitimate-looking components that no single-signal scanner sees the full picture.

Themis, the IRONSCALES Adaptive AI engine, flagged this email based on the behavioral pattern: first-time external sender, near-empty body, attachment-themed subject with no context, multi-hop obfuscated primary link, and a secondary link to cloud infrastructure with randomized naming. The SCL-5 quarantine from Microsoft's filters provided a concurrent signal, though not a block. The combination built a high-confidence verdict.

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

Indicators of Compromise

MITRE ATT&CK Mapping