The USPS Link That Looked Right Until It Wasn't

You can hover over a link. Every security awareness training program in existence tells you to do exactly that. Hover before you click, check the domain, move on.

This attack breaks that reflex completely.

A phishing email impersonating USPS arrived with a link that displayed as https://www.usps.com/Update_Address. Hovering it would have shown translate.goog, which is Google. Still looks safe to most people. Neither check would have exposed the actual destination: a threat-actor-controlled domain at dpdns[.]org, proxied through Google Translate, reached through a Microsoft 365 relay that kept the authentication chain intact. Two evasion layers working together, each one designed to defeat a different detection instinct.

What the Link Actually Said vs. What It Showed

The displayed URL in the email body was visually indistinguishable from a legitimate USPS link. Rendered on screen, it read https://www.usps.com/Update_Address. Look at the raw HTML and the picture changes immediately.

The attacker peppered every word and URL segment with Unicode U+FEFF, the zero-width no-break space character. These characters are invisible to the human eye but present in the underlying markup. Security filters that evaluate the display text of a link rather than its raw href value see what appears to be a usps.com URL. The href itself pointed somewhere entirely different.

The actual destination: hxxps://breakfast881-saccessful-dpdns-org.translate[.]goog/?_x_tr_hl=zh-CN&_x_tr_sl=auto&_x_tr_tl=mr

Unpacked, that is a Google Translate proxy URL. The origin domain is encoded in the subdomain as saccessful-dpdns.org, a subdomain of the attacker-registered dpdns[.]org. Google Translate fetches and renders the origin page at that domain, wrapped in the translate.goog hostname. To any tool checking the immediate URL, this is a Google domain.

This is a two-stage misdirection. The first stage fools anyone relying on display text. The second stage fools anyone who gets past the first stage and checks the actual href.

The Infrastructure Behind the Lure

dpdns[.]org was registered on 2025-03-13 through Gandi SAS with fully redacted WHOIS registrant data. Nameservers resolve to ns1.digitalplat[.]org, ns2.digitalplat[.]org, and ns3.digitalplat[.]org. The specific subdomain used in this campaign (saccessful-dpdns.org) returned NXDOMAIN during SOC analysis, a pattern consistent with phishing kits that rely on the Google Translate proxy to serve content without ever needing the phishing subdomain to resolve directly.

The domain was less than eight months old at the time of this incident. IRONSCALES platform data shows this kind of newly-registered, WHOIS-redacted infrastructure appearing regularly in campaigns that pair fresh domains with trusted proxy services precisely because reputation scores have no history to work from.

The email itself came from ptwmihaf462@hotmail.com, sent through a Microsoft 365 Groups relay (groups.outlook.com). That routing choice was deliberate. Because the relay is legitimate Microsoft infrastructure, ARC-Seal and ARC-Message-Signature were present and passed. SPF passed for the envelope sender domain (groups.outlook.com). DMARC failed for the visible header From address (hotmail.com) because there was no DKIM signature and no SPF alignment with hotmail.com, but that failure was buried in authentication headers that most end users never see and that some automated filters weight less heavily when the overall relay chain looks clean.

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

The USPS logo was pulled directly from www.usps.com. The body text followed a standard redelivery pretext: your package arrived, it will be returned if you don't update your address, click here. Generic enough to apply to anyone, urgent enough to prompt action. According to the FBI IC3 Internet Crime Report 2024, parcel and delivery-themed phishing continues to be one of the most volume-efficient social engineering pretexts in circulation, requiring minimal customization per target.

Why Standard Checks Did Not Catch This

URL reputation tools typically evaluate the domain in the href against known-bad lists. translate.goog is not on any reputation blocklist. It is an active Google service. Checking the redirect chain from translate.goog to the actual origin domain requires the scanner to follow the proxy and inspect what is on the other side, which most gateway-level scanners do not do in real time.

MITRE ATT&CK classifies the underlying techniques as T1566.002 (Spearphishing Link), T1036 (Masquerading), and T1027 (Obfuscated Files or Information). The combination is specifically engineered to defeat layered inspection that stops at any single checkpoint.

Verizon's 2024 Data Breach Investigations Report notes that the median time for a user to click a phishing link after delivery is under 60 seconds. This campaign did not need to beat sophisticated automated analysis. It needed to beat a person glancing at a URL on a phone or in a preview pane. It was built for that.

Themis flagged the mismatch between the displayed URL and the actual href value during behavioral analysis, catching what the surface-level authentication checks missed. The email was quarantined automatically before any recipient interaction. The sender was flagged as a first-time sender with high risk, and community intelligence from across the IRONSCALES platform had already associated similar relay chain patterns with active credential harvesting campaigns.

What Security Teams Need to Adjust

URL analysis needs to evaluate href values, not display text. If your email security platform only checks what the link appears to say, zero-width character injection bypasses it by design. The Microsoft Digital Defense Report 2024 specifically calls out URL obfuscation as an increasingly common technique used to evade gateway-level scanning (see: Microsoft Digital Defense Report 2024).

Trusted proxy abuse via Google Translate, AMP caches, and similar services is not new, but it has become more systematic. Filtering on the proxied hostname alone is insufficient. Detection needs to dereference redirect chains and inspect final destinations. The IRONSCALES Advanced Malware and URL Protection layer handles this at the platform level, but for teams relying on gateway inspection alone, the gap is real.

DMARC failure is a signal, but context matters. A DMARC fail on a message that transited legitimate Microsoft infrastructure is easier to dismiss than a DMARC fail from an entirely unknown source. Attackers know this. Routing through M365 Groups, Exchange Online Protection, or similar high-trust relays is a deliberate strategy to reduce the weight of authentication failures in automated scoring.

Train your users on more than just hovering. The hover-to-check habit is valuable but insufficient when the immediate destination is a legitimate Google domain masking the actual payload. For phishing simulation programs, testing against this class of redirect-wrapped lure reveals whether your user population recognizes the difference between an expected service URL and a proxied redirect chain.

Indicators of Compromise