Security in the video game industry: the real risk of Slack, Teams and cloud tools

The pattern nobody wants to name Every major leak in the video game industry over the last six years followed the same script. Nobody broke the encryption. Nobody defeated a cryptographic algorithm. Someone got into a collaboration tool — Slack, Teams, a Jira instance, a helpdesk, a cloud warehouse — and from there the content was simply *readable*.

That is the uncomfortable common denominator: studios protect their perimeters, but their most sensitive material — unreleased builds, cinematics, source code, HR files, contracts, employee identity documents — sits in plaintext inside tools whose vendors can read it, whose sessions can be stolen, and whose admin consoles can be phished.

This page documents the best-known cases, then explains why DRIVUNO is built so that the same attack produces nothing usable.

The major incidents, case by case

### Rockstar Games — the GTA VI leak (September 2022) An attacker associated with the Lapsus$ group obtained access to internal communications and published roughly 90 videos of unfinished *Grand Theft Auto VI* gameplay. The intrusion did not require breaking encryption: it started with credential/session compromise and social engineering, and the internal collaboration workspace then acted as a single, fully readable archive of everything the team had shared. Take-Two confirmed the breach; the resulting media cycle was one of the most damaging in the industry's history.

### Insomniac Games — Rhysida ransomware (December 2023) The Rhysida group exfiltrated around 1.6 TB of internal data and, after the ransom went unpaid, published it: *Wolverine* materials, roadmaps, contracts, and — most seriously — passports and personal documents belonging to employees. The lesson is about the *volume*: 1.6 TB left the studio without triggering an effective stop, which is exactly what an exfiltration ceiling exists to prevent.

### Electronic Arts — 780 GB of source code (June 2021) Attackers bought stolen browser cookies for a few dollars, used them to authenticate to EA's Slack workspace, then convinced IT support to issue a multi-factor token by posing as an employee who had lost their phone. From there they took the *FIFA 21* source code and the Frostbite engine source. No zero-day, no cryptography broken — a session cookie and a conversation.

### CD Projekt Red — HelloKitty ransomware (February 2021) Source code for *Cyberpunk 2077*, *The Witcher 3*, *Gwent* and internal documents (accounting, HR, legal, investor relations) was encrypted and exfiltrated. CD Projekt refused to pay; the data was auctioned. Recovery was possible because backups existed — but confidentiality was already lost the moment the data was readable.

### Capcom — Ragnar Locker (November 2020) Roughly 1 TB exfiltrated and about 390,000 people affected: employees, former employees, business partners, customers. Passports, HR files, sales data and unreleased game plans circulated publicly. Initial access came through a legacy VPN device left reachable.

### Ubisoft — Lapsus$ intrusion (March 2022) Ubisoft confirmed an incident affecting internal systems and services, and forced a company-wide password reset. Lapsus$ again — the same playbook of identity compromise and internal-tool access rather than technical exploitation of encryption.

### NVIDIA — Lapsus$ (February 2022) Around 1 TB exfiltrated, including driver source code and employee credential hashes, with the attackers publicly attempting to extort engineering changes. NVIDIA is not a studio, but the incident shaped the entire graphics/gaming supply chain and its code-signing certificates were abused afterwards.

### Riot Games — social engineering (January 2023) Source code for *League of Legends*, *Teamfight Tactics* and a legacy anti-cheat platform was stolen after a social-engineering attack on the development environment. Riot publicly refused a $10 million ransom and disclosed the incident itself.

### Activision — SMS phishing into Slack (December 2022, disclosed 2023) An employee in HR was phished by SMS. The attacker reached the internal Slack workspace and pulled employee data and the 2023 content release schedule. Again: no cryptographic failure, just a readable workspace behind one compromised human.

### Bandai Namco — ALPHV/BlackCat (July 2022) Ransomware with exfiltration; customer data from Asian regions and internal documents were leaked following non-payment.

### Sony — two distinct eras (2011 and 2023) The 2011 PlayStation Network breach exposed about 77 million accounts and took the service offline for 23 days — still the reference case for the cost of a centralized identity store. In 2023, Sony was hit again through the MOVEit file-transfer vulnerability and separately claimed by the Ransomed.vc group, illustrating the newer risk: your *file transfer vendor* becomes the breach.

### 2K Games — weaponised support desk (September 2022) Attackers took over the 2K helpdesk platform and replied to real support tickets with malware links, turning a trusted customer channel into a distribution vector.

### Roblox — third-party vendor leak (2023) Personal data of developer-conference attendees, including addresses and identity details, leaked through a third-party vendor rather than through Roblox itself.

### Naughty Dog / *The Last of Us Part II* — pre-release leak (April 2020) Major story content leaked months before release. The technical entry point mattered less than the outcome: the internal build material was in a form somebody could simply watch and republish.

### Nintendo — the "Gigaleak" (2020) Decades of source code, prototypes and design documents from the SNES/N64 era spilled publicly, largely traced to compromises of partners and older archived material. Old data does not stop being sensitive.

### Snowflake-linked campaign (2024) A large-scale campaign against cloud data-warehouse accounts protected only by passwords — no MFA — hit dozens of major companies across sectors including gaming and entertainment. It marked the shift from "hack the studio" to "hack the analytics vendor everyone uses".

What every one of these has in common - **Identity was the entry point.** Stolen cookies, phished MFA, an abused helpdesk. Not broken cryptography. - **The collaboration tool was the jackpot.** Once inside Slack, Teams or the shared drive, everything was plaintext, searchable and downloadable in bulk. - **The provider could read the data too.** Every one of those tools decrypts content server-side to index it, preview it, moderate it or feed analytics. That means the data has a readable form somewhere by design. - **Exfiltration was slow and loud, and still succeeded.** 780 GB at EA, 1 TB at Capcom, 1.6 TB at Insomniac. Nothing stopped the tap. - **Third parties widened the blast radius.** MOVEit, Snowflake, helpdesk vendors, conference organisers.

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

Concretely, on the scenarios above:

• **A stolen session behaves nothing like a stolen Slack cookie.** An attacker holding a session token holds access to encrypted material, not to content. What is stored is unreadable without keys that were never uploaded.
• **There is no admin console that can read a project.** No DRIVUNO employee, no support tool and no court order can produce a readable copy of your files, because no readable copy exists on our infrastructure. That is the entire point of the design.
• **A ransomware pass on your own machine does not destroy your history.** Continuous encrypted mirroring keeps prior versions, and our own backups are immutable for a fixed retention window, so an attacker cannot delete or overwrite what has already been stored.
• **Team access is per-person, not per-workspace.** Being "in the company" does not grant access to a project. Access is granted individually and revocable individually, and removing someone rotates the keys of what they could reach.
• **Sharing outside the team is deliberate and short-lived.** Public links expire within 24 hours, and the material needed to open them is never transmitted to our servers.
• **We removed third-party analytics entirely.** DRIVUNO runs no Google Analytics and no external marketing tag. Our visit counter is our own, first-party, and cannot see anything inside an account. The Snowflake-style "your vendor is the breach" path is closed by not having the vendor.
• **Mass download is detected and slowed automatically.** Every account has an adaptive ceiling based on its *own* normal behaviour, so a studio that regularly pulls hundreds of gigabytes stays unimpeded, while a sudden full-library sweep triggers an alert and an automatic slowdown. This is the signal that would have surfaced the EA and Insomniac exfiltrations while they were still in progress.

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

What a studio should take away 1. Stop treating chat and shared drives as ephemeral. They are your real archive, and they are indexed in plaintext. 2. Assume identity will eventually be compromised. Design so that a compromised identity does not equal a readable library. 3. Watch volume, not just access. Every one of these disasters was a very large amount of data moving out, quietly. 4. Reduce the number of vendors that can technically read your work. Each one is an additional breach you do not control.

Working under NDA, without the exposure DRIVUNO gives studios 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. Start free, and keep your builds out of anyone else's plaintext.