Cloud Security Office Hours Banner

Vimeo / Anodot 2026

Step-by-step kill chain mapped to MITRE ATT&CK Cloud, sourced from official post-mortems and primary technical analyses.

April 2026 Critical Snowflake / BigQuery

Vimeo / Anodot - Stolen Analytics Vendor Tokens → Direct Snowflake and BigQuery Access → 119,000 Records Exfiltrated → Extortion

On April 28, 2026 Vimeo confirmed a data breach affecting roughly 119,000 users and customers. Vimeo's own systems were not broken into. The compromise happened at Anodot, an analytics vendor that held authentication tokens on Vimeo's behalf, giving it legitimate and persistent access to Vimeo's cloud data environments. The extortion group ShinyHunters obtained those tokens and used them to authenticate directly to Vimeo's Snowflake and BigQuery instances, query what the integration was permitted to see, and pull it out. The access never exceeded the permissions granted to Anodot's integration, which is precisely why it looked like normal analytics traffic. Email addresses, video titles and technical metadata were taken; uploaded video content, account credentials and payment card data were not. ShinyHunters claimed responsibility on April 29 and set a leak deadline for April 30. Vimeo disabled all Anodot credentials, removed the integration, and engaged outside experts and law enforcement.

~119,000 unique email addresses exposed, some with names
Two warehouses: Snowflake and BigQuery, reached with one vendor's tokens
Zero privilege escalation - the integration's own scope was enough
Threat actor: ShinyHunters, an extortion-focused group
📄 CPO Magazine - Vimeo confirms breach impacting 119,000 users ↗ 📄 Security Affairs - ShinyHunters exploit the Anodot incident to target Vimeo ↗
Initial Access - The Breach Happened Somewhere Else
01
Anodot, a third-party analytics provider, was compromised and the authentication tokens it held for customer cloud environments were stolen
T1199 - Trusted Relationship T1528 - Steal Application Access Token

Vimeo's incident began on someone else's infrastructure. Anodot is an analytics platform, and like most analytics platforms it works by holding durable credentials into its customers' data estates so it can read from them on a schedule. Public reporting has not established how Anodot itself was compromised; researchers describe it as likely either an infostealer infection or a direct compromise of Anodot's systems, and that distinction remains unresolved. What is not in question is what the attacker walked away with: a set of working tokens into multiple customers' cloud data platforms, held in one place, by a company those customers' security teams did not monitor.

Compromised party: Anodot, a third-party analytics vendor
Method: Not publicly established; researchers cite infostealer infection or direct system compromise
Taken: Authentication tokens held on behalf of customers for their cloud data environments
Structural issue: A vendor's token store aggregates standing access across all of its customers
Vendor CompromiseToken TheftFourth Party RiskT1199
🔐 Persistence - Tokens That Were Built Never to Expire
02
The stolen tokens were service-to-service credentials with standing access, requiring no password, no interactive login and no MFA
T1078.004 - Valid Accounts: Cloud Accounts

Analytics integrations exist to run unattended, so their credentials are deliberately long-lived: they authenticate machine to machine, they do not prompt anyone, and they survive every human-facing control an organization deploys. A stolen token of this kind is not defeated by password rotation, by an MFA requirement, or by disabling an employee account, because none of those things apply to it. This is non-human identity risk in its purest form, and it is the reason the same pattern keeps producing large breaches from small vendors.

Credential type: Long-lived service-to-service authentication tokens
Bypassed by design: Passwords, interactive sign-in, MFA, session expiry
Not revoked by: Employee offboarding or user credential rotation
Only real kill switch: Revoking the integration's credential at the data platform
Non-Human IdentityLong-Lived TokensNo MFA PathT1078.004
🔀 Lateral Movement - Straight Into Snowflake and BigQuery
03
ShinyHunters authenticated to Vimeo's Snowflake and BigQuery instances using Anodot's tokens, without ever touching Vimeo's own perimeter
T1199 - Trusted Relationship T1078.004 - Valid Accounts: Cloud Accounts

The tokens worked exactly as intended, which is the whole problem. Vimeo's firewalls, its identity provider, its endpoint controls and its employee MFA posture were all irrelevant, because the attacker arrived through an authorized integration on a path the company had deliberately opened. Notice that the same tokens reached across two different clouds' analytics platforms: consolidating vendor access into one credential store means one theft crosses provider boundaries. Reporting also indicates Anodot's tokens covered access to S3 and Amazon Kinesis for its customer base, so the reachable surface was broader than the two warehouses that were used here.

Platforms accessed: Vimeo's Snowflake and BigQuery instances
Vendor's broader token scope: Reporting also cites S3 and Amazon Kinesis access across its customer base
Perimeter relevance: None. The path was authorized and expected
Cross-cloud effect: One vendor credential store spans AWS and Google Cloud data services
SnowflakeBigQueryAuthorized PathT1199
🔍 Discovery - Working Inside the Integration's Own Scope
04
The attacker's access was bounded by the permissions granted to Anodot's integration, so nothing had to be escalated and nothing looked anomalous
T1580 - Cloud Infrastructure Discovery T1087.004 - Account Discovery: Cloud Account

Reporting is consistent that the intrusion never exceeded what the integration was already permitted to do. Read that as the finding it is, not as mitigation. It means the analytics grant by itself was sufficient to expose 119,000 user records, and it means no privilege escalation alert could have fired, because none was needed. The defensive question is not "how did they escalate" but "why did the analytics integration have read access to customer email addresses at all?" Least privilege for a vendor integration means granting the aggregated or pseudonymized views the vendor's job requires, not table-level reads on production identity data.

Access ceiling: Exactly the permissions granted to the Anodot integration
Escalation observed: None, and none required
Consequence: No privilege escalation detection could have triggered
Real question: Why an analytics grant could read customer email addresses at all
Scoped AccessNo EscalationOver-Broad GrantT1580
📤 Collection & Exfiltration - Ordinary Database Tooling
05
Bulk queries were run with commodity database clients and custom scripts, and results were compressed before being pulled out over the same authorized channel
T1213 - Data from Information Repositories T1560.001 - Archive via Utility

There was no bespoke tradecraft. Researchers describe the use of a mainstream database client, DBeaver, alongside custom scripts, with results compressed using standard utilities such as gzip before exfiltration. That is the same profile as UNC5537 / Snowflake two years earlier, and it is why detection has to be volumetric rather than signature-based: the queries are valid, the client is legitimate, the credential is authorized, and the only thing out of place is how much data moved and when. What left was email addresses of users and customers, video titles, and technical metadata. Uploaded video content, account passwords and payment card data were not accessed.

Tooling: DBeaver plus custom scripts, all ordinary database access
Staging: Results compressed with standard utilities such as gzip before transfer
Taken: Email addresses, video titles, technical metadata (~119,000 unique addresses, some with names)
Not taken: Uploaded video content, account passwords, payment card data
Only anomaly available: Query volume and rows scanned, not the tooling or the credential
DBeaverBulk QueryVolumetric DetectionT1213
💥 Impact - Disclosure, Extortion Deadline, Integration Removed
06
Vimeo disclosed on April 28, ShinyHunters claimed the breach on April 29 with a leak deadline of April 30, and Vimeo killed the integration
T1657 - Financial Theft

ShinyHunters is an extortion group rather than a ransomware crew: the business model is stealing data and threatening publication, and in the same period it ran the same play against Instructure's Canvas learning platform, affecting data on tens of millions of students and staff. Vimeo's response was the right shape and fast: disable all Anodot credentials, remove the integration entirely, bring in external security experts, notify law enforcement. Worth noting what that response depended on, though. Executing it in hours requires already knowing which integrations exist, which credentials each holds, and where the revocation switch is. Organizations that have to discover that during an incident lose days they do not have against a deadline measured in them.

April 28: Vimeo publicly discloses the incident
April 29: ShinyHunters publicly claims responsibility
April 30: Extortion deadline for publication of the stolen data
Response: All Anodot credentials disabled, integration removed, external experts and law enforcement engaged
Same actor, same period: Instructure Canvas, affecting tens of millions of students and staff
ShinyHuntersExtortionIntegration RevokedT1657

🛡 How to Defend Against This Chain

Keep a live inventory of every non-human identity that can read your data warehouse. You cannot revoke what you have not written down. For each integration record the credential, its scope, its owner, its expiry, and the exact command that revokes it. Vimeo's fast containment worked because the integration was identifiable and killable; that is an inventory property, not a luck property. Review the list quarterly and delete the integrations nobody remembers enabling.
Scope analytics grants to what analytics actually needs. The attacker never escalated because the integration's own permissions were enough to expose 119,000 records. Give vendors purpose-built views: aggregated, pseudonymized, or column-masked, with direct email and identity columns excluded. Snowflake dynamic data masking and row access policies, and BigQuery authorized views with column-level access control, all exist for this and cost nothing to apply.
Replace standing tokens with short-lived, source-bound credentials. Long-lived service tokens are the asset every one of these campaigns is actually stealing. Prefer OIDC federation or workload identity federation over static keys, cap token lifetimes, and bind them to a network location: Snowflake network policies and BigQuery VPC Service Controls both let a stolen credential fail from an unexpected source address. Rotate on a schedule you actually execute.
Alert on data volume, because everything else looks legitimate. Valid credential, valid client, valid query. The only signal available is behavioral: rows scanned, bytes returned, query patterns and access times that deviate from what a scheduled analytics job does. Baseline each integration's normal profile in Snowflake's ACCESS_HISTORY and QUERY_HISTORY and in BigQuery's audit logs and INFORMATION_SCHEMA.JOBS, then page on deviation rather than on failed logins that will never happen.
Extend vendor risk to the fourth party and make revocation a drill. Ask vendors what credentials of yours they hold, how those are stored and rotated, what their endpoint controls look like, and how fast they will notify you. Then rehearse your side: a tabletop where the scenario is "a vendor tells us our tokens are stolen" and the success criterion is total revocation within an hour. Pair it with an incident response plan that treats third-party notification as a trigger, not an FYI.
Assume the extortion clock starts before you hear about it. ShinyHunters claimed this breach one day after disclosure and set a leak deadline the day after that. Legal, communications and customer notification workflows need to be pre-staged, and the decision framework for how you handle an extortion demand should be settled long before a deadline is in front of you.

Related defense topics