TL;DR A home care services provider received a phishing email styled as a Dropbox file-share notification, sent through SendGrid from a domain registered roughly 20 days earlier. The single Review_Copy button did not point to Dropbox. It pointed to a raw Amazon S3 bucket URL that rendered a DocuSign-branded credential form for a fake proposal document. The email passed SPF, DKIM, and DMARC because the attacker owned and configured the sending domain. The cross-brand handoff, Dropbox for the click and DocuSign for the credential, was the entire trick.
Severity: High Credential Harvesting Brand Impersonation Cloud Infrastructure Abuse MITRE: T1566.002 MITRE: T1585.002 MITRE: T1102.002

The email looked like a Dropbox share notification. The credential form it eventually landed on looked like DocuSign. Neither brand touched a single piece of the infrastructure that delivered the message or hosted the page.

That mismatch is the entire attack. A Regional HR Compliance Manager at a home care services provider received a message styled with Dropbox template visuals, a clean logo, minimal copy, and a single call to action. "Enclosed is the confidential file for your review," it read, above one button labeled Review_Copy. The styling did its job. The button did something else.

A Dropbox click that never went to Dropbox

The Review_Copy button did not link to dropbox.com. It linked to a raw Amazon S3 object URL, a long numeric string ending in amazonaws.com, that rendered a DocuSign-branded page titled "Secure Document Access." That page displayed a fake file, "Proposal_Document.pdf - 2.8 MB," behind a button labeled Access Document. The button gated an email-capture form. Enter your address to see the document, and the credential harvest was complete.

Read the handoff carefully, because it is deliberate. Dropbox cues earned the click. DocuSign cues earned the credential. A raw cloud-storage URL hosted the payload. At no point did the attacker impersonate a brand whose infrastructure they had to compromise or spoof. They borrowed two logos and rented the hosting.

Splitting the impersonation across two brands is a soft evasion tactic. A recipient primed to trust a Dropbox notification does not re-evaluate when a DocuSign page appears, because both are ordinary parts of a document workflow. The context feels continuous even though the brand identity has quietly changed twice.

Why every authentication check passed

Here is the part that trips up teams who lean on authentication as a verdict rather than a signal. This message passed SPF, DKIM, and DMARC cleanly.

It passed because the attacker earned the pass. The sending domain, unitedglasswork[.]com, was registered through Amazon Registrar with privacy-protected WHOIS, then relayed through SendGrid infrastructure (wfbttxbb[.]outbound-mail[.]sendgrid[.]net). SPF, DKIM, and DMARC all confirm that a message genuinely came from the domain it claims to come from. They say nothing about whether that domain deserves trust.

A domain registered roughly 20 days before the attack, configured by the attacker with correct DNS records and routed through a reputable email service provider, will authenticate perfectly. Authentication measures provenance, not intent. Treating a green DMARC result as a safety verdict is exactly the assumption this attack was built to exploit.

The domain age is the tell that authentication cannot surface. A sender domain that is 20 days old, privacy-shielded, and sending its first message to your organization is a behavioral anomaly no SPF record will flag.

The raw bucket that gave the game away

The strongest signal was the link destination itself. A message wearing Dropbox visuals should resolve to a Dropbox-owned domain. This one resolved to a raw Amazon S3 bucket, and that bucket served a DocuSign-branded page. Three brand identities, three different owners, zero of them consistent with each other.

Hosting credential-harvest pages on cloud storage is a well-documented technique that MITRE tracks as Web Service abuse (T1102.002). Cloud platforms carry strong domain reputations, rarely land on blocklists, and let an attacker skip registering and defending a dedicated phishing domain. The delivery method maps to Spearphishing Link (T1566.002), and the throwaway sending domain maps to Establish Accounts (T1585.002).

Here are the defanged indicators.

Indicators of Compromise

TypeIndicatorContext
Emailinfo[@]unitedglasswork[.]comAttacker-registered sender, Amazon Registrar, privacy-protected WHOIS, created ~20 days before send
Domainunitedglasswork[.]comAttacker-owned sending domain, authenticated via SendGrid
Hostwfbttxbb[.]outbound-mail[.]sendgrid[.]netSendGrid relay used to earn SPF/DKIM/DMARC pass
IP159[.]183[.]122[.]187Sending infrastructure
URLhxxps://47318389482498380929740224[.]s3[.]eu-central-1[.]amazonaws[.]com/54378098248023988574388404284DocuSign-branded credential form hosted on raw S3 bucket

This is why a gateway that scores mail on reputation and authentication lets a message like this through. Every check it runs comes back clean. IRONSCALES platform data shows secure email gateways (SEGs) miss an average of 67.5 phishing emails per 100 mailboxes each month, and cross-brand relays like this one are exactly the category that slips past reputation-based filtering.

Themis, our Adaptive AI analyst, reads the message the way a human investigator would, correlating the signals a checklist treats in isolation. A 20-day-old sender, a first-contact domain, Dropbox visual styling, a single-button call to action, and a destination that points to a raw cloud-storage bucket rather than the brand the email claims to be. No individual signal is fatal. Together they describe an attack. That behavioral read is what stops credential harvesting that passes authentication, and it matters most for organizations in home care and healthcare, where HR and compliance inboxes handle sensitive records and sit high on target lists.

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

The stakes behind a captured credential are well established. The 2024 Verizon Data Breach Investigations Report (DBIR) found stolen credentials involved in 38 percent of breaches, the single most common initial action. Credential-first phishing like this attack is not a nuisance category. It is the front door. CISA's phishing guidance makes the same case, treating credential theft as the opening move in a longer intrusion chain, and the Microsoft Digital Defense Report 2024 documents the same shift toward attacks that abuse legitimate services to stay under reputation thresholds. IRONSCALES sees this pattern across 35,000+ security professionals in 17,000+ organizations.

Judge the infrastructure, not the logo

The defense here is a single habit: trust the destination, not the decoration. A message can wear any brand's colors for free. What it cannot easily fake is a consistent chain of ownership from sender to link to landing page.

When the email brand, the link destination, and the landing-page brand disagree, that disagreement is the verdict. A Dropbox email that resolves to a raw Amazon S3 bucket showing a DocuSign form is three brands and one attacker. Teach your users to hover before they click and to distrust brand-mismatched hops, and deploy detection that reads sender age, first-contact behavior, and destination mismatch as one correlated signal rather than five separate green lights.

Email Attack of the Day is a daily series from IRONSCALES spotlighting real phishing attacks caught by Adaptive AI and our community of 35,000+ security professionals. Each post breaks down a real attack. What it looked like, why it worked, and what to do about it.

Related attacks

Attack What happened
The Fireflies Meeting Recap That Never Happened: Dual-Brand Impersonation via Amazon SESA phishing campaign combined Fireflies.ai meeting recap templates with Microsoft Teams branding to target a financial controller.
The Law Firm Name That Used Invisible Characters to Pass AuthenticationA phishing email impersonating Alston & Bird LLP used homoglyph characters in the display name and rode Google Drive sharing infrastructure to pass SPF.
The Procore Footer Was Real. The Document Was Not.Every link scanner called the Procore and ExxonMobil URLs clean.
The Email That Passed Every Security Check (Because Adobe Sent It)A phishing campaign targeting school district staff used Adobe's own sending infrastructure, real DKIM signatures.
The DocuSign Lure That Used Google as a Trust Shield (And Encoded Your Email in the Link)A DocuSign phishing email hid its harvest domain behind a google.com redirect and encoded the recipient's exact email address into the link as base64.

Explore More Articles

Say goodbye to Phishing, BEC, and QR code attacks. Our Adaptive AI automatically learns and evolves to keep your employees safe from email attacks.