Authentication headers are a statement about infrastructure, not identity. This attack built its entire evasion strategy on that gap.
A SaaS-sector recipient received an email styled as a HubSpot compliance notice. The From display name read "HubSpot Team." The sender address belonged to an unrelated personal marketing domain, a long-established registration (2009) with no affiliation to HubSpot, anonymized here because its owner appears to be a third party whose authenticated sending identity was abused. The email traveled through Amazon SES infrastructure (a64-44[.]smtp-out[.]amazonses[.]com, IP 54[.]240[.]64[.]44), and the authentication chain returned SPF pass, DKIM pass, and DMARC pass, all aligned to that sending domain. The authentication verdicts are accurate; they just describe the wrong identity.
The subject line announced "Case: #048974-489368 Account Suspended." The body told the recipient that email campaigns had been suspended as of a specific date due to compliance concerns, and that restoring access required clicking "Verify Your Account" to confirm identity and provide consent documentation for the contact list.
Every word of that construction is engineered. The case number fabricates process legitimacy. The suspension date creates urgency with a concrete deadline. "Consent documentation" elevates a credential request to a compliance obligation: the framing implies the recipient owes the action rather than being asked to perform it voluntarily.
The greeting was generic ("Dear Customer") with no account-specific identifiers: no account email, no organization name, no subscription tier. Legitimate SaaS transactional notices include account-specific context because they are generated from a database record tied to that recipient. The absence of personalization here is a tell: this message was sent at scale.
The footer listed a residential street address with no connection to HubSpot's Cambridge, Massachusetts headquarters. The unsubscribe and preference links pointed to form[.]flodesk[.]com and usercontent[.]flodesk[.]com, indicating the message was assembled in Flodesk rather than in HubSpot's own sending infrastructure. Those Flodesk links returned clean verdicts; they are not part of the attack chain. They are, however, the visible contradiction of the brand claim embedded in every other element of the email.
Display name spoofing of this kind exploits the fact that most email clients display the human-readable From name prominently and render the actual sending address in smaller, less-visible text or hide it behind a tap or hover. Recipients scanning a notification in a mobile email client may never see that "HubSpot Team" resolves to an unrelated personal marketing domain.
See Your Risk: Calculate how many threats your SEG is missing
The "Verify Your Account" button did not link to hubspot.com. It linked to gkbt4brd[.]r[.]us-east-1[.]awstrack[.]me, an Amazon SES click-tracking URL that wrapped the real destination: r2[.]ddlnk[.]net.
The awstrack.me layer serves a dual purpose for the attacker. First, it inherits Amazon's IP reputation: a gateway scanning the link in the email body sees Amazon infrastructure, not an unfamiliar redirect domain. Second, the opaque encoded path makes the destination URL invisible to header inspection without actually following the chain. The recipient's email client shows a link that resolves through Amazon before the real target appears.
The r2[.]ddlnk[.]net domain has documented prior abuse history across phishing and spam campaigns on sibling subdomains. At scan time the specific path returned HTTP 404, consistent with a campaign that had concluded or rotated its landing page. The infrastructure signature (an abused redirect domain reached through a cloud-provider tracking wrapper) is the operative finding regardless of whether a live credential form was present at analysis time. URL rewriting of this type, using legitimate click-tracking infrastructure to mask the final hop, is a documented technique for defeating gateway-layer URL scanning.
MITRE ATT&CK T1566.001 (spearphishing link) covers the delivery mechanism. T1656 (impersonation) applies to the HubSpot brand claim throughout. T1598.003 (phishing for information: spearphishing link) reflects the credential-harvesting objective embedded in the "Verify Your Account" CTA.
ESP abuse through Amazon SES is a deliberate infrastructure choice. Registering any domain, configuring DKIM in the SES console, and publishing an SPF record takes under an hour. The result is a sending identity that passes all three email authentication checks. The sending domain is a 2009 registration, not a fresh throwaway domain that might trigger age-based heuristics, which means a reputable, well-aged sending identity was abused rather than stood up from scratch. Amazon SES enforces its own usage policies, but at the moment of send, the gateway receiving the message has no visibility into whether SES has acted on a complaint.
This is the authentication theater problem at scale. SPF, DKIM, and DMARC were designed to prevent domain forgery, and they accomplish that goal. They were not designed to validate brand identity claims made in the display name field. The receiving tenant's protection layer did assign SCL:5 and quarantine the message, which suggests behavioral signals (generic greeting, suspicious redirect chain, brand-domain mismatch) contributed to the verdict alongside the authentication result. In environments without that behavioral layer, the authentication pass is the entire story, and it reads as legitimate.
| Type | Indicator | Context |
|---|---|---|
| Sender domain | Long-established personal marketing domain (registered 2009), name withheld | Authenticated sender abused to impersonate "HubSpot Team"; not hubspot[.]com; likely third-party owner |
| Sending identity | Amazon SES, SPF/DKIM/DMARC aligned to the sender domain | Reputable authenticated identity abused for delivery |
| Sending IP | 54[.]240[.]64[.]44 | Amazon SES outbound (a64-44[.]smtp-out[.]amazonses[.]com) |
| Redirect domain | r2[.]ddlnk[.]net | CTA destination after awstrack.me wrapper; prior phishing/spam abuse reports |
| Click-tracker | gkbt4brd[.]r[.]us-east-1[.]awstrack[.]me | Amazon SES click-tracking URL wrapping the ddlnk.net payload link |