If Ransomware Hits Your Company: Are You Ready for a 1TB Leak Threat Like Fairlife’s?

A ransomware incident used to mean one ugly problem: locked files. Now it’s two problems at once: locked files and a public leak countdown. In July 2026, the Anubis ransomware group claimed it hit Coca-Cola’s Fairlife subsidiary, and the story had the classic operational punch (U.S. production disruption) plus a sharper edge: a threat to publish roughly 1TB of allegedly stolen corporate data if negotiations didn’t start by the end of the week . If you’re responsible for incident response, IT, security, legal, or comms, this is the scenario to rehearse—because the leak threat changes your first 72 hours.

What’s confirmed vs. what’s alleged (and why that distinction matters)

When ransomware hits, the fastest way to make a bad week worse is mixing verified facts with attacker claims. The Fairlife situation is a clean example of why your team needs two tracks in parallel: operational response (what you can prove) and extortion response (what you’re being told).

What Coca‑Cola/Fairlife has actually confirmed

Coca‑Cola said attackers gained unauthorized access to a portion of Fairlife’s systems, including production-related systems. That triggered incident response and business continuity plans. The impact wasn’t abstract: it disrupted operations and suspended production at U.S. facilities, while Canadian production continued normally. Coca‑Cola also stated product quality and safety were not affected .

Just as important is what they didn’t confirm at the time: no public confirmation of data theft, no confirmation of an extortion demand, and no attribution to a specific ransomware group .

That “we’re not saying yet” gap is normal early in an incident. It usually means the investigation is still sorting out scope, access paths, and what evidence is reliable.

What the Anubis ransomware group claims

The Anubis ransomware group later added Fairlife to its data leak site, claiming responsibility and alleging a ~1TB data leak threat: publish the stolen corporate data unless Fairlife enters negotiations by the end of the week .

They also claimed they encrypted Fairlife’s Nutanix infrastructure and that the company “has no chance” of recovery without their key .

Key detail: these are attacker statements. BleepingComputer noted it could not independently verify the claims about the theft, the encryption, or the amount of data allegedly stolen .

Why this distinction changes your first decisions

In a double-extortion ransomware event, the attacker wants you to treat their narrative like a verified incident report. Don’t.

Here’s the practical rule your IR lead, legal, and comms should stick to:

• Confirmed facts drive containment and recovery.
• What systems were accessed?
• What’s down right now?
• What business processes are disrupted?
• Allegations drive investigation priority, not public certainty.
• “1TB stolen” is a hypothesis until your logs, DLP signals, cloud audit trails, and endpoint telemetry support it.
• “Nutanix encrypted” is a claim until you validate what clusters are impacted, what’s recoverable, and whether the blast radius includes identity and backups.

If you blur the two, you get predictable failure modes: rushed executive decisions, sloppy internal updates, and external statements you’ll spend months walking back. Keeping “confirmed vs. alleged” separate isn’t PR polish—it’s how you keep a ransomware incident from turning into a credibility incident too.

Why a 1TB leak threat is a different kind of emergency (double‑extortion reality)

Once you separate facts from attacker noise, the real shift becomes obvious: you’re not dealing with “ransomware” as a single problem anymore. You’re dealing with double extortion.

Double extortion, explained like you’d explain it to a board member

Old-school ransomware was one primary pain: your systems are encrypted.

Double extortion adds a second weapon: your data gets stolen and the attacker threatens to publish it. Anubis is explicitly described as an operation that combines data theft with file encryption, using stolen information as pressure to make victims pay .

That second threat changes who’s in the room on day one.

Encryption pulls in ops. A leak threat pulls in everyone.

A large data leak threat (think “1TB”) isn’t just an IT outage story. It drags these teams into the blast radius immediately:

• Legal & privacy
• Breach notification duties can start based on access/exfiltration risk, not on whether files are locked.
• You’ll need counsel involved early to keep privilege clean and decisions defensible.
• Comms
• Internal rumors move faster than forensics.
• External messaging can’t be “we don’t know anything” for long if proof samples show up.
• Customer/vendor management
• Partners want to know if they’re exposed before you’ve finished triage.
• Regulators
• The leak threat creates a clock even if production systems come back quickly.

The deadline is the attack

Attackers love short deadlines because they create sloppy decision-making. In the Fairlife case, Anubis warned it would publish allegedly stolen data unless the company entered negotiations by the end of the week . That’s not a random date. It’s a pressure tactic.

A “publish stolen data” deadline pushes companies into two expensive mistakes:

1. Rushing the technical read

• Accepting the attacker’s story about what was taken.
• Over-rotating on getting systems online while under-investing in exposure analysis.

2. Rushing the human decisions

• Too many voices, too many Slack channels, too many half-updates.
• Inconsistent statements that become discoverable artifacts later.

What makes a 1TB leak threat feel different (even before you verify it)

Even if you can’t confirm the exact size, “1TB” signals scale. It implies a mix of data types—email, fileshares, exports, engineering docs, HR, finance, customer lists—whatever they could reach and pull.

That matters because the harm is asymmetric:

• You can restore servers.
• You can’t un-leak data once it’s mirrored, reposted, and scraped.

One more ugly twist: Anubis has been reported to add a data wiper capability that destroys files beyond recovery . That raises the stakes on containment and recovery planning, because the attacker isn’t just threatening disclosure—they may be signaling a willingness to burn the house down on the way out.

Your first 24–72 hours: the moves that actually change outcomes

A leak deadline is meant to hijack your calendar. Your job is to slow the chaos down without slowing the response.

Think of the first 72 hours as two lanes running at the same time: contain + investigate and exposure + comms. If your team only runs one lane, you lose time you won’t get back.

Lane 1: Contain access (without destroying evidence)

Your first wins come from stopping the bleed while keeping proof intact.

1. Stand up a single command channel

• One incident lead. One decision log. One “who can approve what” list.
• Bring in Security, IT, Legal, Exec, Comms immediately. If any of them joins on day 3, you’re already behind.

2. Cut off attacker control paths

• Disable suspected accounts, revoke sessions/tokens, rotate privileged creds.
• Block known C2 where you can, but don’t assume you’ve found all of it.

3. Preserve evidence early

• Snapshot key systems (AD/IdP logs, EDR telemetry, VPN, email, file servers, virtualization hosts).
• Keep copies of ransom notes and any attacker messages. Don’t “clean up” endpoints yet.

4. Map “down” vs. “at risk”

• Down: what’s broken and stopping operations.
• At risk: what the attacker could still access or already staged for exfil.

Lane 2: Treat the leak as a data-theft investigation, day one

If the actor is known for combining data theft with file encryption , assume exfil is possible until proven otherwise.

Build an exposure picture fast (even if it’s incomplete)

• What data types were reachable? (HR, finance, contracts, customer lists, engineering, emails)
• Where was it stored? (file shares, SharePoint/Drive, ticketing tools, ERP, backups, SaaS apps)
• What pathways existed? (RDP, VPN, service accounts, API keys, sync agents)

Validate attacker claims without letting them steer you

• If the attacker is threatening to publish stolen data unless you negotiate by a short deadline , that’s pressure—not proof.
• Look for your own indicators: unusual outbound traffic, large archive creation, cloud download spikes, new OAuth apps, suspicious admin activity.

Comms rules so rumors don’t become the strategy

When internal updates are messy, external comms gets messy.

Set these rules within hours:

• One internal update cadence (example: every 4 hours, even if the update is “no change”).
• One source of truth (a page or channel people can point to).
• One spokesperson path (employees don’t freelance on LinkedIn “to be helpful”).

Quick decision points your leadership will ask for by hour 24

Have answers ready, even if they’re “we’re still verifying”:

• Are we contained or still actively compromised?
• Do we have a clean restore path?
• What’s our current confidence on data access/exfil?
• What’s the trigger for customer/regulator notification review?

If you do these basics well, you’re buying yourself the only thing that matters in a ransomware incident with a leak threat: time to make accurate decisions under pressure.

Backup + recovery readiness checks (before you’re forced to learn the hard way)

When a ransomware crew claims they “fully encrypted” core infrastructure like Nutanix , your backups stop being a line item and become your negotiating position.

This isn’t about having backups. It’s about answering one blunt question: Can we restore fast enough to keep operating without paying?

The blunt readiness test (use real RTO/RPO, not hopeful numbers)

Run this like a drill, not a slide deck.

• RTO (Recovery Time Objective): how long you can be down before the business takes unacceptable damage
• RPO (Recovery Point Objective): how much data you can afford to lose (time-wise)

Now apply those numbers to the systems people forget until they’re gone:

• Identity: AD / Entra ID / Okta, MFA, conditional access policies
• Core compute: virtualization stack (VMware/Nutanix/AHV), hypervisor hosts, management plane
• Networking dependencies: DNS, DHCP, VPN, firewalls, remote access tooling
• Production dependencies: OT jump hosts, historians, scheduling systems, QA systems, batch/plant apps
• Collaboration + email: M365/Google Workspace access and admin control
• Security tooling: EDR consoles, SIEM log pipelines, PKI, secrets management

If you can’t restore identity + core compute cleanly, everything else turns into a scramble.

Recovery architecture checks that actually matter in a ransomware event

You’re aiming for two things: survivable backups and restorable backups.

Survivable: can the attacker delete or encrypt your backups?

Common failure points that show up in real incidents:

• Backups joined to the same domain (or managed by the same admin identities)
• Backup repositories accessible with everyday credentials
• No “break glass” admin accounts for backup platforms
• Backup immutability that can still be turned off by a compromised admin

If an attacker can admin your environment, they can often admin your backups too.

Restorable: can you bring systems back under pressure?

A backup you’ve never restored is a guess.

Pressure-test these areas:

• Restore runbooks that exist only in someone’s head
• Missing app configs and secrets (service account passwords, API keys, certs, encryption keys)
• Dependency blind spots (the app restores, but DNS doesn’t, so nothing works)
• No clean-room restore plan (restoring into the same compromised environment = reinfection)

Ownership: who can say “we restore this first”

A lot of companies lose hours arguing about priorities.

Decide now:

• Who owns restore order (IT? app owners? business continuity lead?)
• Who can approve risk trade-offs (restore fast vs. restore clean)
• Who can authorize a full identity reset if needed

A practical mini-checklist to run this quarter

If you want a short ransomware backup recovery readiness checklist, start here:

1. Prove you can restore identity in an isolated environment.
2. Prove you can restore your virtualization management plane (including Nutanix/AHV or equivalent).
3. Do a full restore of one “critical” app end-to-end, including configs/secrets.
4. Time it and compare to your real RTO/RPO.
5. Document gaps and assign one owner per gap with a due date.

Attackers love to claim you “have no chance of recovering without our encryption key” . The way you make that line irrelevant is boring, disciplined restore practice—done before you’re staring at a leak countdown.

Leak-site monitoring and exposure assessment: how to stay calm when the clock starts

By the time backups and restores are in motion, the leak threat becomes its own workstream. You need discipline here, because attackers want you obsessively refreshing a leak site instead of running a clean investigation.

Leak-site monitoring: treat it like evidence, not entertainment

If an actor is known for combining data theft with file encryption , you monitor for publication signals—but you do it in a controlled way.

Set a tight process:

• Assign one monitoring owner
• One person/team collects intel and posts updates on a set schedule.
• Everyone else stays focused on response work.
• Log everything, in a timeline
• What appeared (victim page, “coming soon,” sample files, full dump)
• Exact timestamp, URL, screenshots, and hashes if files are captured
• Any changes (new archives, edits to the post, updated deadline language)
• Track reposting
• Leaks often jump from the original ransomware leak site to forums, mirrors, and file-sharing links.
• Your goal isn’t to “chase the internet.” It’s to understand spread so legal/comms can plan.

Validating samples: “looks real” isn’t the same as “is real”

Leak sites often post small “proof” packs. Some are authentic, some are padded, some are old.

A practical authenticity check (without contaminating evidence):

1. Compare sample metadata to known internal patterns

• naming conventions, document templates, email headers, internal project codes

2. Check for internal-only fields

• system-generated IDs, directory structures, or exports that match your tools

3. Confirm time ranges

• do the dates align with your current environment or a past system?

4. Keep chain-of-custody clean

• If you download anything, do it through counsel/forensics workflows and document handling.

Exposure assessment: focus on “who’s harmed” before “what’s embarrassing”

If the attacker is threatening to publish stolen data unless you negotiate by a deadline , the hard part is scoping impact fast enough to make notification decisions without guessing.

Prioritize scoping like this:

• Tier 1: regulated and high-risk data
• employee data, customer PII, payment-related data, health-related data (if applicable), credentials/keys
• Tier 2: business-sensitive
• contracts, pricing, M&A, IP, vendor terms
• Tier 3: operational noise
• routine docs that feel scary but don’t trigger obligations

Build an “exposure matrix” the exec team can read in 60 seconds:

• data category → likely source system → confidence (low/med/high) → affected populations → next action

Reduce future leak impact: shrink the pile of real identifiers

A lot of breach pain comes from one simple truth: companies collect too much PII and spread it across too many tools.

Cut that down:

• Stop collecting fields you don’t need (especially phone numbers, personal emails, full addresses)
• Centralize sensitive workflows instead of letting every team use a new SaaS tool with a fresh data copy
• Limit where identifiers live (don’t put them in tickets, spreadsheets, shared drives “temporarily”)

For high-risk workflows—vendor signups, demo requests, conference lead capture, one-off tools—consider using Cloaked identities: separate emails and phone numbers for each relationship, plus masked cards for payments. That way, if one system or third party gets popped, you’re not exposing the same real identifiers everywhere. It’s not a ransomware fix; it’s a practical way to reduce blast radius when data theft is part of the playbook.

The goal of leak-site monitoring and exposure assessment isn’t to win an argument with criminals. It’s to keep your decisions calm, documented, and defensible while the clock is trying to rush you.

‍