Dropbox shared file phishing scam: how legit-link phishing bypasses email security in 2026

Q: Should I report a suspected Dropbox phishing email?

Yes. Forward the full email with headers to abuse@dropbox.com. Dropbox's abuse team uses the report to lock the underlying account, remove the file, and update fraud monitoring. Also forward to your internal IT security inbox and use the Report phishing button in your mail client if one exists. Reporting is what makes the campaign expensive to run.

AI quick answer

Dropbox shared file phishing is a credential-theft attack in which the attacker abuses Dropbox's own sharing feature to send a real "shared a file with you" notification from no-reply@dropbox.com. The email passes SPF, DKIM, and DMARC because it really did come from Dropbox. The shared file is an HTML page that displays a fake Dropbox or Microsoft 365 login overlay; entering credentials sends them to the attacker. Common lures are "Encrypted invoice", "Tax document", and "Contract for review". The defense is to never type a password on a page reached from a share notification, to confirm out-of-context shares on a separate channel, and to enable phishing-resistant MFA on the Dropbox and email accounts that protect downstream files.

How Dropbox shared file phishing works, step by step

The technique sits in a family Proofpoint calls "legitimate-service abuse" or "trusted-platform phishing". The attacker is not spoofing Dropbox. The attacker is using Dropbox the way every paying customer uses it, only the file at the end of the link is built to steal a password.

Step 1: attacker registers a Dropbox account

A free Dropbox Basic account is enough. Many campaigns use throwaway accounts on disposable mailbox services; more careful operators buy seasoned accounts with weeks of plausible activity baked in. Dropbox's anti-abuse team takes accounts down quickly when reports come in, so campaigns are designed to burn through accounts and accept the churn.

Step 2: attacker uploads the lure file

The uploaded file is almost always an HTML document, sometimes wrapped in a thin PDF preview. The HTML renders a near-pixel copy of the Dropbox sign-in screen, the Microsoft 365 sign-in screen, or whichever brand the campaign targets. Filenames carry the social hook: Encrypted_Invoice_Q1_2026.html, Tax_Return_2025_Final.pdf.html, Contract_for_Review_Acme.html.

Step 3: attacker triggers a Dropbox share notification

The attacker clicks "Share" inside Dropbox, types the victim's email, and lets Dropbox send the notification through its own infrastructure. The mail leaves no-reply@dropbox.com, carries valid DKIM signatures, passes SPF, and aligns DMARC. To any inbound gateway, the message is indistinguishable from a normal customer share because it is a normal customer share.

Step 4: the recipient clicks "View file"

The link inside the notification is a real Dropbox URL of the form https://www.dropbox.com/scl/fi/<hash>/<filename>. The browser opens dropbox.com, the URL bar shows a Dropbox certificate, and the file preview loads. Some campaigns put the HTML inside a folder with an explicit "Preview" link that opens the file in a separate Dropbox-hosted preview frame. Either way, the recipient sees an interface that genuinely belongs to Dropbox.

Step 5: the credential page loads

The HTML file renders a fake login overlay. The most common framing is a Microsoft 365 sign-in prompt with a header line that reads "This document is encrypted. Enter your Microsoft account credentials to verify your identity." Some kits skin the same flow as a Dropbox login. The form posts to an attacker-controlled endpoint, often on a free hosting provider (Cloudflare Pages, Netlify, Firebase Hosting, Vercel), where the credentials are stored and forwarded into the attacker's panel.

Step 6: optional adversary-in-the-middle relay

More sophisticated kits do not just store the password. They run an adversary-in-the-middle proxy that relays the credential and the MFA challenge live against the real provider, captures the post-MFA session cookie, and hands the cookie to the attacker. The victim completes MFA on their phone as normal and concludes everything is fine. The session cookie is meanwhile sweeping the mailbox.

Step 7: the lateral pivot

With Dropbox credentials in hand, the attacker reads every folder the victim can access, including shared team folders. That alone is a corporate document leak. With M365 credentials in hand, the attacker is in Outlook, sweeping for wire instructions and standing up auto-forward rules on keywords like invoice, wire, and payment. See how clone phishing builds on a stolen mailbox for the follow-on attack.

Why this bypasses email security

Three properties of the Dropbox sharing flow combine into a defense-evasion stack that most secure email gateways were not designed to catch.

SPF, DKIM, and DMARC all pass on dropbox.com

SPF passes because the sending IPs are on Dropbox's published SPF record. DKIM passes because Dropbox signs every outbound notification. DMARC aligns because the From header domain matches the DKIM signing domain. Gateways that filter on authentication failure cannot fail this message because nothing about it is forged. Authentication confirms the domain, not the honesty of the human behind the share.

URL reputation passes on dropbox.com

Most URL-reputation databases treat dropbox.com as high-trust because the overwhelming majority of Dropbox shares are legitimate. A URL inspection layer that blocks domains on reputation alone would have to block Dropbox itself, which no enterprise gateway is willing to do. URL rewriting services (Proofpoint URL Defense, Microsoft Safe Links) will rewrite the link, but the rewritten click still resolves to dropbox.com and still hands control over to whatever HTML the attacker uploaded.

The malicious code is one click past the URL the gateway sees

Many gateways detonate URLs in a sandbox before delivery. A detonation hitting the dropbox.com share link will see Dropbox's preview pane, not the eventual login overlay. Detonating one click deeper into the HTML file itself is expensive and rarely the default. Even with deep detonation, modern kits cloak the credential-harvest behavior behind referrer and geolocation checks so the sandbox sees a benign page while the real victim sees the phish. Proofpoint's research on legitimate-service abuse repeatedly notes that detonation coverage drops sharply once the payload is one or two links inside a trusted SaaS platform.

The three templates in active rotation

Most campaigns observed since late 2025 use one of three lure templates. Knowing the templates makes the lure jump out.

1. "Encrypted invoice" or "secure document"

Subject line is some variation of "Encrypted invoice", "Secure document shared with you", or "Protected file ready for download". Body says the file requires login to verify the recipient before decryption. Filenames look like Invoice_18372_Encrypted.html. Aimed at accounts payable, finance, and executive assistants.

2. "Tax document" or "W-9 / VAT form"

Subject line reads "Tax document for your review", "Updated W-9 form", or "VAT invoice 2026". Body says HR or finance needs the recipient to download and confirm. Filenames are along the lines of W9_Form_2026.html. Surges in January through April. The IRS has issued public service announcements warning that the agency does not initiate document exchange by emailed file-share links.

3. "Contract for review" or "NDA"

Subject line is "Contract for review", "NDA - please sign", or "Vendor agreement Q2". Body mimics a real legal or procurement workflow. Filenames look like Contract_for_Review_Acme.html. Often paired with executive impersonation in the share notification's "from" name. See DocuSign phishing scam for the related signature-request variant.

How SafeBrowz blocks this threat

SafeBrowz runs a 3-layer detection architecture: Local + APIs + AI.

Layer 1, local detection: 60+ URL patterns plus 550+ brand-specific signatures (including Dropbox, Microsoft, and Google sign-in clones) plus community whitelist and blacklist, all running directly inside the extension before the page renders. When the click off a Dropbox share lands on a credential-harvest page on a free-hosting domain (pages.dev, web.app, netlify.app, vercel.app, workers.dev, r2.dev) and the page paints Dropbox, Microsoft, or Google sign-in chrome, the local layer flags the impersonation immediately, without sending the URL anywhere.
Layer 2, API checks: aggregates Google Safe Browsing, PhishTank, and URLhaus for known-malicious hosts, plus a 30-plus pattern list of scam TLDs and free-hosting subdomains commonly used for credential harvest.
Layer 3, AI deep scan (Premium): for novel pages that have not yet been catalogued, a content analysis pass in 100-plus languages reads the page DOM, identifies brand impersonation through visual and textual cues, and returns a verdict in seconds.

Detection signatures come from threat-intelligence research and brand database analysis, not from user browsing data. Per-user URL history is never stored, and page contents are not retained.

What to do if you entered credentials

Speed matters. AiTM kits sweep a stolen mailbox within seconds and install auto-forward rules within minutes. The next 30 minutes decide whether this is a footnote or a full incident.

Change your Dropbox password. Sign in by typing dropbox.com directly. Account → Security → Change password. The Dropbox Help Center documents the reset flow in its account-security pages.
Change your email password, separately. If the lure framed as Microsoft 365 or Google Workspace, the stolen credentials are your email credentials. Reset M365 at account.microsoft.com/security, Google at myaccount.google.com/security.
Enable phishing-resistant MFA. Hardware keys (YubiKey, Titan) and platform passkeys are AiTM-resistant because the cryptographic challenge is bound to the real domain. Phone prompts and SMS codes do not stop AiTM phishing.
Force sign-out of all sessions. Dropbox: Settings → Security → Web browsers and Devices. M365: portal.office.com → My Account → Sign me out everywhere. Google: myaccount.google.com → Security → Your devices. This invalidates any stolen session cookie.
Review the Dropbox access log. Settings → Security → Web browsers shows recent sign-in IPs and devices. Kill anything unfamiliar.
Audit Dropbox sharing settings. Settings → Sharing shows every link, shared folder, and connected app. Revoke anything you do not recognize. Tighten default link permissions to "Only invited people".
Audit mailbox rules. Outlook: Settings → Mail → Rules. Gmail: Settings → Filters. Remove anything you did not create, especially auto-forward rules and rules that hide messages containing invoice, wire, or payment.
Revoke OAuth grants. Attackers install an OAuth app for persistence after password change. M365 admin portal → Enterprise applications → User-consented apps. Google: Security → Connections to third-party apps. Dropbox: Settings → Connected apps.
Tell IT security. If you are on a managed device, security can pull the email and hunt for other recipients. Cyber-insurance riders typically require notification within 24 to 72 hours.

Protection that actually works

Dropbox two-step verification with a hardware key

Dropbox supports time-based one-time codes and hardware security keys for two-step verification. Hardware keys are the recommended choice for accounts containing business documents. Configuration is in Settings → Security → Two-step verification. Dropbox's Help Center documents the setup flow.

Tightened default sharing settings

Default link permissions should be "Only invited people can access" rather than "Anyone with the link". Folder-level permissions on team folders should distinguish edit from view. Dropbox Business administrators can enforce these defaults org-wide from the admin console.

Regular review of the security activity log

The Dropbox security page lists active web sessions, mobile devices, and connected apps with the IP and approximate location of each. A monthly review catches unrecognized sessions before they become incidents. For Dropbox Business, the team activity log surfaces unusual file-sharing patterns across the organization.

Browser-layer scanning of every URL before render

The email gateway cannot block the message and the URL-reputation layer cannot block the link, because the sender authenticates and the URL is dropbox.com. The defense layer that catches this attack is the browser. A brand-aware browser extension that scans every URL before render against a brand database (Dropbox, Microsoft, Google, and 547 others) and inspects page content for credential-harvest signals will flag the impersonation page even when it is rendered inside a Dropbox preview frame. SafeBrowz Business adds organization-wide threat reporting so IT teams can see how often file-share phishing reaches their employees.

Awareness training that uses real templates

The three lures above ("Encrypted invoice", "Tax document", "Contract for review") should be modeled in any internal phishing simulation. Training employees to type dropbox.com directly when in doubt, instead of clicking the share button, defeats the entire technique.

Frequently asked questions

Is the email really from Dropbox if SPF and DKIM pass on dropbox.com?

Yes, the email itself is genuinely from Dropbox. Dropbox sent it because an attacker who has a Dropbox account triggered the "share this file" action through the real Dropbox interface. Authentication on dropbox.com confirms that Dropbox delivered the message, not that the human who paid for the Dropbox account is honest. This is the property that makes "legitimate-service abuse" phishing so hard for email gateways to block.

How can I tell a malicious Dropbox share from a real one before clicking?

Two signals matter. First, context: were you expecting a file from this sender? Real shares almost always follow a meeting, Slack thread, or known project. An unsolicited share from a name you do not recognize, or from a known contact about a project that does not exist, is the strongest red flag. Second, the file extension: a real document share is a PDF, DOCX, XLSX, PNG, or similar. An HTML file disguised as a document (Invoice.pdf.html) is essentially never legitimate.

I opened the file but did not enter a password. Am I safe?

Almost certainly yes. Static HTML viewed in a browser does not have the privileges to compromise a modern, patched device on its own. The risk vector here is the credential form. If you did not type a password or paste a one-time code, close the tab, clear the recent cookies if you want to be cautious, and move on. Run an endpoint scan if you downloaded the file rather than previewing it.

I entered my Microsoft 365 password into the Dropbox-shared file. What now?

Change the M365 password immediately, force sign-out of all sessions, audit mailbox rules and OAuth grants, and enable a hardware-key or passkey MFA factor. The fact that the credential page was reached via Dropbox does not change the recovery flow: this is a Microsoft 365 credential incident. If you are on a managed device, tell IT security the same day. The recovery checklist above walks through every step.

Does enabling Dropbox two-step verification stop this attack?

It stops the attacker from logging into your Dropbox account with just the password they captured, which is a meaningful win. With a hardware key as the second factor, even an AiTM relay cannot complete the sign-in because the cryptographic challenge is bound to dropbox.com. Two-step verification does not by itself stop the email landing in your inbox, and it does not protect any other account whose password you might have typed into the lure page.

Why does Dropbox not just block this kind of abuse?

Dropbox does. Dropbox's trust and safety team takes down abusive accounts, scans files for known malware signatures, and publishes a security blog covering the program. The structural problem is that an attacker who uploads a brand-new HTML file with no malware signature, disguises it as a document, and shares it with a small targeted list looks identical to a legitimate customer at the moment of share. Detection lands after the report, which is why recipient-side defense is the layer that catches the click.

Should I report a suspected Dropbox phishing email?

Yes. Forward the full email with headers to abuse@dropbox.com. Dropbox's abuse team uses the report to lock the underlying account, remove the file, and update fraud monitoring. Also forward to your internal IT security inbox and use the "Report phishing" button in your mail client if one exists. Reporting is what makes the campaign expensive to run.

Is this the same as a Google Drive or OneDrive share scam?

Yes, in technique. The same legitimate-service abuse pattern targets every major file-share platform: Dropbox, Google Drive, OneDrive, SharePoint, Box, WeTransfer, and Adobe Creative Cloud. The attacker uploads credential-harvest HTML to a real account, shares it through the platform's own notification system, and lets authentication pass on the platform's domain. The defenses are the same: verify out-of-context shares on a separate channel, enable phishing-resistant MFA, and scan every URL at the browser layer before render.