Film, studios and media: why Slack and Teams are the real leak

Scripts do not leak from vaults. They leak from chat. Every high-profile leak in film, production and media over the last decade followed the same route: nobody attacked the encryption, somebody got into a collaboration tool. Once inside, scripts, rushes, unreleased cuts, casting notes, contracts and internal conversations were simply *readable*, searchable and downloadable in bulk.

This page documents the best-known cases in the sector, then explains why the same attack produces nothing usable on DRIVUNO.

The major incidents

Disney — 1.1 TB exfiltrated from Slack (July 2024) A group calling itself NullBulge published roughly **1.1 TB of data taken from Disney's internal Slack**, covering close to 10,000 channels. The dump included internal communications, candidate evaluations, unreleased project material, code, images and credentials. Disney confirmed it was investigating and, in the aftermath, **moved off Slack to Microsoft Teams**.

The instructive detail is not the tool. It is that a chat workspace had quietly become the studio's real archive — years of attachments and discussion, all in plaintext on the vendor's side.

Nikkei — 17,000+ Slack conversations exposed (2025) Malware on a single employee's PC stole their Slack credentials. From that one machine, the attacker reached the **history of more than 17,000 conversations**, plus information about business partners. Nikkei — owner of the Financial Times — is exactly the kind of organisation whose sources and internal discussions must never be readable by anyone else.

Sony Pictures (2014) — the reference case Unreleased films, scripts, salary tables and tens of thousands of internal emails were published. Fifteen years of "we'll fix collaboration security later" ended in a full public dump. The confidentiality loss was permanent the moment the material was readable.

MGM Resorts / Caesars (2023) — the helpdesk as the front door Both were compromised through **social engineering of IT support**, not through a technical exploit. A convincing phone call to a helpdesk produced a credential reset, and from there the internal environment opened up. Any media group with an outsourced service desk faces the identical path.

MOVEit (2023) — when the transfer vendor is the breach The file-transfer platform used by media groups, broadcasters and their payroll and post-production partners was exploited at scale. Organisations that had never been attacked directly still leaked, because their **vendor** held readable copies of their files.

What these have in common - **Identity is the entry point.** A stolen cookie, a phished token, a convincing call to support. - **The chat workspace is the jackpot.** Once inside, everything is indexed plaintext: attachments, drafts, links, screenshots. - **The provider can read it too.** Server-side previews, full-text search, moderation and AI features all require a readable copy to exist by design. - **Exfiltration is enormous and still unnoticed.** 1.1 TB left Disney without anything cutting the tap. - **Third parties widen the blast radius.** Transfer platforms, post-production partners, analytics vendors.

Why this cannot play out the same way on DRIVUNO DRIVUNO is zero-knowledge: files, messages, attachments and shared team folders are encrypted **on your device** before anything is transmitted. Keys are derived from your own credentials and never exist in readable form on our side. It is an architectural property, not a policy promise.

Against the scenarios above:

• A stolen session is not a stolen archive. An attacker holding a session token holds ciphertext. What is stored cannot be read without keys that were never uploaded.
• There is no admin console that can open a project. No employee, no support tool and no legal order can produce a readable copy of a rush or a script, because no readable copy exists on our infrastructure.
• A Disney-style chat dump yields nothing. Our messaging workspace is end-to-end encrypted per channel. Exporting the database gives an attacker encrypted blobs, not 10,000 readable channels.
• Access is per person, not per workspace. Being "in the company" does not grant access to a production. Access is granted and revoked individually, and removing someone rotates the keys of everything they could reach.
• Outside sharing is deliberate and short-lived. Public links expire within 24 hours and the material needed to open them is never sent to our servers.
• No third-party analytics at all. No Google Analytics, no external marketing tag. The "your vendor is the breach" path is closed by not having the vendor.
• Bulk download is detected and slowed automatically. Every account has an adaptive ceiling based on its own normal behaviour, so a post-production team pulling hundreds of gigabytes works normally, while a sudden full-library sweep triggers an alert and an automatic slowdown.
• Ransomware on your own machine does not erase your history. Continuous encrypted mirroring keeps prior versions, and our own backups are immutable for a fixed retention window.

We deliberately do not publish thresholds, heuristics or internal response procedures. Publishing them would only help someone trying to stay under them.

What a production should take away 1. Treat chat as your archive, because it already is one. 2. Assume an identity will be compromised, and design so that it does not equal a readable library. 3. Watch volume, not just access. 4. Reduce the number of vendors technically able to read your work.

Working under NDA, without the exposure DRIVUNO gives studios and newsrooms encrypted storage, encrypted team folders and an encrypted Slack-style workspace where the provider is structurally unable to read the content — plus continuous encrypted backup of local project folders.