Every Link Is Amazon: How Legitimate Infrastructure Becomes the Phishing Payload

A delivery notification landed in an employee's inbox at a building products company. The subject line read: "Your Amazon package is out for delivery and will arrive by this evening." The email carried Amazon Business branding, a personalized greeting, a real order number, and a yellow "Track your package" button. SPF passed. DKIM passed. DMARC passed with a compauth score of 100. Every single embedded URL resolved to amazon.com or business.amazon.com.

Every automated URL scanner returned a clean verdict. There was no attacker-controlled domain to flag, no suspicious redirect chain to unwind, no newly registered infrastructure to catch. The email was, by every technical measure, legitimate.

The IRONSCALES community flagged it anyway. Multiple mailboxes were quarantined within seconds.

The Perfect Authentication Score Hiding an Exploitable Attack Surface

The email originated from shipment-tracking@amazon[.]com with a Return-Path of bounces.amazon[.]com. It was delivered through Amazon SES infrastructure at IP 54[.]240[.]13[.]79, which reverse-resolves to a13-79.smtp-out.amazonses[.]com. The full authentication chain:

• SPF: Pass (bounces.amazon[.]com designates 54[.]240[.]13[.]79 as permitted sender)
• DKIM: Pass on both amazon[.]com and amazonses[.]com selectors
• DMARC: Pass, action=none
• compauth: 100 (Microsoft Composite Authentication, perfect score)
• SCL: 1 (lowest non-zero spam confidence level)

The X-AMAZON-MAIL-RELAY-TYPE header was set to "notification," consistent with Amazon transactional email. The Feedback-ID confirmed Amazon SES origin. Microsoft's own antispam systems categorized it as NONE (no threat detected).

This authentication profile is indistinguishable from a legitimate Amazon shipment notification. That is the point.

Redirect Flows as Weaponizable Payloads

The email contained over 20 embedded URLs. Every one pointed to Amazon-owned domains. But not all Amazon URLs carry equal risk. Three classes of links appeared in this message, and the distinction matters.

Class 1: Direct tracking pages. Links like amazon[.]com/gp/css/shiptrack/view.html with order and shipment parameters. These resolve to standard Amazon package tracking. Low risk in isolation.

Class 2: OpenID sign-in redirects. The email embedded amazon[.]com/ap/signin URLs carrying openid.return_to parameters pointing to amazon[.]com/your-orders/order-details. This is Amazon's standard OpenID Connect flow. When a user clicks, they hit Amazon's real sign-in page. The return_to parameter controls where they land after authenticating. In a legitimate flow, that destination is another Amazon page. In a compromised or modified flow, that destination could be anywhere. This is the credential harvesting mechanism. The initial click URL passes every scanner because it IS Amazon.

Class 3: Multi-hop redirect wrappers. The email used amazon[.]com/gp/f.html and business.amazon[.]com/abredir wrapper URLs that accept a U= parameter containing the final destination. These wrappers route through Amazon's own redirect infrastructure before resolving. The gp/f.html links carried encoded URN message identifiers (M=urn:rtn:msg:...) and unique recipient tracking tokens (R=, K=, H= parameters), creating per-recipient redirect paths that make bulk URL analysis ineffective.

The architecture is layered. A user clicking "Track your package" could traverse: gp/f.html (Amazon wrapper) to business.amazon[.]com/abredir (Amazon Business redirect) to gp/css/shiptrack/view.html (tracking page). Three hops, all Amazon domains, all clean verdicts. If any hop in this chain were modified to point outside Amazon's ecosystem, the preceding hops would still scan clean.

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

Why URL Scanning Returned 22 Clean Verdicts

Automated URL scanners evaluate the destination a link resolves to at scan time. Every link in this email resolved to a real Amazon page. Screenshots captured during analysis showed legitimate Amazon tracking pages, Amazon sign-in pages, and Amazon Business portal pages. No scanner can flag amazon[.]com as malicious.

This is the structural limitation of domain reputation and URL verdict systems. They answer the question "is this domain bad?" The answer for amazon[.]com will always be no. The relevant question, which requires behavioral context to answer, is: "should this recipient be receiving this email from this sender at this time?"

The Verizon DBIR 2024 found that credential theft remains the top action variety in breaches, and the FBI IC3 2024 report documented $2.9 billion in BEC/fraud losses. Attacks that abuse trusted infrastructure to harvest credentials represent the convergence of these two trends. When the infrastructure is legitimate and the authentication is perfect, the attack becomes invisible to any tool that evaluates emails based on sender reputation or link reputation alone.

Community Signal as the Detection Layer

The Themis AI engine assigned this email a 50% confidence score with a "VIP Recipient" label. That moderate confidence reflects the technical reality: authentication was perfect, links were clean, and content matched Amazon's template format. Nothing in the technical indicators warranted a high-confidence phishing classification.

The community signal changed the calculus. Security analysts across the IRONSCALES network had flagged similar emails, and the aggregated resolution pattern pointed to phishing with high confidence. That collective intelligence triggered quarantine actions across four affected mailboxes, all within seconds of the initial community report.

This case maps to MITRE ATT&CK T1566.002 (Phishing: Spearphishing Link) and T1598.003 (Phishing for Information: Spearphishing Link). The T1078.004 (Valid Accounts: Cloud Accounts) technique applies to the credential harvesting objective of the /ap/signin redirect flow.

Observed Indicators: Amazon Redirect Chain

What This Case Demands from Your Detection Stack

Block lists are useless here. You cannot blocklist amazon[.]com. URL reputation is useless here. Every link is clean. DMARC is useless here. Authentication passed perfectly.

The detection layers that matter for this class of attack are behavioral: first-time sender analysis per recipient, anomalous delivery patterns (an Amazon Business notification to a non-procurement role), community intelligence that aggregates reports across organizations, and AI models trained to evaluate context rather than reputation.

If your email security stack relies primarily on authentication signals and URL scanning, it will pass this email every time. The question is whether you have a detection layer that operates above the technical indicators, one that evaluates whether the email makes sense for the recipient, not just whether the sender is who they claim to be.