Your password wasn’t stolen. Your multi-factor authentication is enabled. And yet your files in Dropbox, Google Workspace, or Microsoft 365 could still be accessible to attackers. That’s not a hypothetical — it describes the attack pattern a group called ShinyHunters has been running at scale across dozens of major organizations.
The mechanism is OAuth: the authentication standard that lets third-party apps access your accounts without seeing your password. The attack doesn’t require guessing or stealing credentials. It exploits the web of trusted connections that cloud services build between themselves and their third-party integrations.
Understanding how this works — and what it means for your personal files — requires a short primer on how OAuth actually functions, and then a clear look at where the seams are being pulled apart.
What OAuth Is (and Why It’s Everywhere)
When you click “Sign in with Google” to access a third-party app, or when a project management tool asks permission to connect with your Dropbox account, you’re using OAuth. The mechanism was designed to let services share access without sharing passwords.
Here’s how it works at a basic level: when you grant an app access to your Google Drive, Google issues that app a token — essentially a permission slip. The app uses the token to read or write files in your Drive without ever knowing your password. If you revoke the app’s access, the token becomes invalid.
This is genuinely good design for its intended purpose. It means a third-party app never has your Google credentials, and you can revoke its access without changing your password.
The problem is what happens at the margins — when tokens are long-lived, when connected vendor apps are misconfigured, and when attackers can get inside one of these trusted connections rather than attacking your account directly.
How ShinyHunters Exploited It
ShinyHunters’ campaign, which Microsoft documented in detail in a July security advisory, doesn’t target individual users. It targets the vendor ecosystem.
The attack chain typically looks like this:
Step 1: Compromise a connected vendor. Large organizations use dozens of third-party SaaS tools — customer platforms, analytics tools, communication software — that have OAuth connections into core platforms like Salesforce, Microsoft 365, or Google Workspace. ShinyHunters has focused on attacking these connected vendors through social engineering, specifically voice phishing attacks against employees.
Step 2: Use the vendor’s OAuth access. Once inside a vendor’s systems, the attacker can use the OAuth tokens the vendor legitimately holds to access the core platform. They’re not breaking into Microsoft 365 directly. They’re coming in through a door that was already open — the door being the trusted integration.
Step 3: Exfiltrate at scale. With valid OAuth access to a core platform, the attacker can read and download files, emails, or other data that the integrated service had permission to access. Because OAuth tokens can be long-lived and because revoking them requires identifying the compromise first, the window for exfiltration can be substantial.
The Salesforce campaign — which affected organizations including Cloudflare, Palo Alto Networks, Pandora, and Chanel — began with compromised vendor integrations (specifically Drift and Gainsight) and cascaded to hundreds of organizations whose Salesforce data was accessible through those connections.
Why MFA Doesn’t Stop This
Multi-factor authentication is a meaningful protection against credential theft. If an attacker has your password but not your second factor, they can’t log in as you.
But OAuth attacks don’t require logging in as you. The attacker is using a token that was already issued to a vendor application — a token that was created after a legitimate MFA login by someone at the vendor. Once the token exists, it operates independently of the original login. There’s no re-authentication step each time the token is used.
This is the fundamental limitation of MFA as a defense against this class of attack: MFA protects the moment of login. It doesn’t continuously re-verify whether the applications that were granted access after that login are still behaving legitimately.
Which Platforms Were Affected
The ShinyHunters campaign specifically targeted organizations using:
- Salesforce and Experience Cloud (Aura) integrations
- Microsoft 365 (including OneDrive and SharePoint)
- Google Workspace (Drive, Gmail)
- Dropbox
- Slack
- Atlassian (Jira, Confluence)
- Zendesk and Gainsight as entry points
This isn’t a single-vendor vulnerability. It’s a technique that works against any major cloud platform that has an ecosystem of third-party integrations with OAuth access. The larger the vendor ecosystem, the more attack surface.
For individual users of consumer tiers of these platforms — a personal Dropbox account, a Google Workspace personal subscription — the direct risk is lower than for enterprise environments, because personal accounts typically have fewer third-party OAuth integrations. But the campaign illustrates a systemic property of cloud storage: your files’ security isn’t just a function of your own account’s security. It’s a function of every vendor that has OAuth access to your account.
The Audit You Probably Haven’t Done
Most users have granted OAuth access to more apps than they realize. You sign into a new service with Google, grant a project tool access to Dropbox, let a photo editor connect to your Drive — and then never review those connections again.
Each of those connections is a token. If the app that holds the token is compromised, that token can be used. If you no longer use the app, the token may still be valid.
To audit your Google account OAuth connections: Go to myaccount.google.com → Security → Third-party apps with account access. Review every app listed. Revoke access for anything you don’t actively use or recognize.
To audit your Microsoft account: Go to account.microsoft.com → Privacy → Apps & services.
To audit your Dropbox account: Go to dropbox.com → Account → Connected apps.
This isn’t a one-time exercise. Apps you’ve forgotten about accumulate over time. Doing this audit annually — and immediately when a major breach is disclosed — meaningfully reduces your attack surface.
What This Means for Your Personal Files
If you store personal documents, photos, or sensitive records in a consumer-tier cloud storage service that has a large third-party app ecosystem, the security of those files depends not just on your own account hygiene but on the security of every connected vendor.
That’s a structural property of how these platforms work. The integrations that make them useful — connecting your calendar to your project management tool, letting your photo editor access your Drive — create the same OAuth connections that attackers exploit.
This isn’t an argument against using cloud storage. It’s an argument for understanding what “secure” actually means in this context: it means your account credentials, your MFA, and the entire web of trusted applications you’ve granted access to.
For files you consider particularly sensitive, there’s an argument for keeping them in a dedicated storage service with fewer third-party integrations rather than mixed into a platform whose primary value comes from ecosystem connectivity.
How to Reduce Your Exposure
Beyond the OAuth audit, a few practical steps:
Be skeptical of voice calls asking you to verify credentials. ShinyHunters’ primary initial attack vector is voice phishing — impersonating IT support or security teams to get employees to provide authentication codes. This is a consumer risk too, not just a corporate one.
Use storage that separates your personal files from your productivity tools. Google Drive is connected to Gmail, Calendar, Docs, and hundreds of third-party integrations. A dedicated storage service with fewer integrations is a smaller OAuth attack surface.
Check for breach disclosures proactively. If a service you use integrates with platforms like Salesforce or Microsoft 365, monitor their security announcements. Cascading breaches often affect users of connected services even when the primary target was an enterprise platform.
What daftei’s Architecture Means for This Attack Class
daftei is a personal storage service — it stores your photos and files with TLS 1.3 in transit and AES-256 at rest. It doesn’t have an ecosystem of third-party vendor integrations with OAuth access into your stored files. There’s no Gainsight connection, no Drift integration, no cascading vendor access path.
That’s not a coincidence. A service built specifically for personal storage doesn’t need the integration ecosystem that enterprise-class platforms are built around. The smaller integration surface isn’t a missing feature — it’s a different risk profile.
daftei is GDPR and CCPA compliant, doesn’t sell data, and doesn’t use your files for AI training. For people thinking through where their most sensitive personal files should live, the OAuth attack landscape is a meaningful part of that calculation.
The question isn’t just “is my password secure?” It’s “how many trusted pathways exist into the service holding my files, and how well can I monitor those pathways?” For most major cloud platforms, the honest answer involves a long list of third-party vendors, OAuth tokens, and integration dependencies that most users have never reviewed.
The Takeaway
OAuth attacks don’t require stealing passwords. They require finding one compromised connection in a web of trusted integrations — and those connections are often easier to find than they look from the outside.
Auditing your OAuth connections is the most underutilized privacy and security practice available to individual users. It costs nothing, takes fifteen minutes, and addresses a risk category that standard security advice — strong passwords, MFA enabled — doesn’t touch.
Do it now. Then set a reminder to do it again in six months.