A ransomware disclosure and a credential package we track from an entirely separate source, read side by side, illustrate a pattern our research team sees again and again: the quiet theft of a single login can be the first domino in a breach that ends, months later, on a dark web leak site.

Reading time · 11 min | Victim · Fairlife (The Coca-Cola Company) | Threat actor · Anubis RaaS

A NOTE ON THIS POST

Fairlife and its parent, The Coca-Cola Company, are named here because the ransomware incident and the leak site disclosure referencing them are already public, Coca-Cola confirmed the incident itself and the threat actor named the victim on its own site. Everything else below that is not already public, the vendor, the individual whose credentials were exposed, and every named employee visible in the leak, has been anonymized, redacted or replaced with a placeholder, including in the screenshots. Nothing here should be read as a confirmed, forensically established account of exactly how this organization was compromised. We pair the public disclosure with a separate credential package our research team observed through an unrelated channel as a realistic, illustrative example of a pattern a threat actor could exploit, the kind of pattern Constella’s platform is built to surface before it reaches this stage.

The Incident

What the leak site actually showed

In mid 2026, a ransomware group operating under the name Anubis added Fairlife, the dairy brand owned by The Coca-Cola Company, to its dark web extortion portal, a fact Coca-Cola itself has publicly confirmed. The group claimed to have exfiltrated close to a terabyte of internal data before triggering its encryption routine, and stated it had also run its optional wipe mode against part of the victim’s virtualization infrastructure, permanently destroying files rather than only encrypting them. That destructive option is one of the traits that sets Anubis apart from most double extortion crews.

Figure 1. Excerpt from the leak site’s landing page for this disclosure. The victim’s name is left visible because Coca-Cola and the threat actor have each already made it public, only the site’s onion address is masked.

Figure 2. The threat actor’s own summary of how it organized the stolen data into categories, reproduced here with only the site header masked.

The leak was organized into three categories, each posted as evidence that the intrusion reached deep into the business rather than stopping at its perimeter.

Engineering and OT documentation

Confidential equipment documentation, CAD and DWG drawings, process control schematics and internal maintenance manuals for production line hardware.

Production and formulation data

Vendor and ingredient specification sheets referencing product formulations across the manufacturer’s beverage and dairy lines.

HR and people data

Employee directories with phone numbers and emergency contacts, compensation and payroll spreadsheets, disciplinary and termination case files and, for a small number of staff, scanned government issued identity documents.

To illustrate the HR category without republishing anyone’s personal data, the two figures below show the general shape of what was posted, fully redacted.

Figure 3. Structure of a leaked employee directory. Every name, phone number and emergency contact has been blacked out.

Figure 4. Structure of an internal HR memo included in the leak. The brand’s logo is left visible since the company’s identity is already public, the names, titles and location of the individual staff involved have been redacted.

The leak site framed the HR exposure as proof the company stored sensitive employee records, including identity documents, with inadequate access controls. Whatever the threat actor’s motive for saying so, the underlying observation holds up on its own: once an attacker is inside, the blast radius of a ransomware event is rarely limited to the systems that were technically in scope.

The Part Ransomware Groups Never Explain

Every leak site post follows the same script: a countdown timer, a data sample, a ransom demand. What is missing, deliberately, is the initial access story.

That missing piece is exactly what Constella’s telemetry is built to reconstruct. Across the incidents we track, one input shows up more consistently than any exploit or misconfiguration: a credential that was already stolen, weeks or months earlier, by malware the victim never even knew was on a device.

• 8B: credentials harvested by infostealers globally in 2025
• 54%+: of 2024 to 2025 ransomware victims had domain credentials sitting in a stealer log before the attack
• <48h: typical window between a log surfacing and it being weaponized by a ransomware crew
• $1 to $100: street price of a single stealer log on Telegram and dark web markets

Infostealers, commodity malware families that quietly harvest saved browser passwords, session cookies, autofill data and local password manager vaults, have become the single most common initial infection vector our industry tracked in 2025. They are cheap, automated and do not need a zero day, a single pirated software installer, a fake job application attachment or a cracked game loader is enough to plant one on a laptop. What comes out the other end reads like a master key to someone’s entire digital life, personal and corporate accounts included.

Case Study: Inside a Vendor Employee’s Credential Package

An anonymized breakdown of a real package our research team observed, used here purely as an example of what this kind of exposure looks like from the inside

To make the “infostealer feeds ransomware” pipeline concrete, we walk through a credential package believed to belong to an employee of a third party digital agency, referred to here as “VendorCo”, contracted to build and maintain staging and production websites for several of The Coca-Cola Company’s brands. We want to be precise about what we can and cannot claim, we cannot prove this specific package was the entry point Anubis used, and we are not asserting that it was. We present it because it is a genuine, representative example of exactly the kind of exposure that gives a ransomware affiliate everything it needs, and because it shows how much a single infected laptop, far outside the victim’s own network, can expose.

• 789: saved credential pairs recovered from the browser credential store
• 543: unique hostnames represented, across at least 140 distinct root domains
• 540: browser session cookies exported alongside the credentials
• 1: local password manager vault store found sitting on the same disk

Password hygiene, or the lack of it

The 789 credential pairs in this package were secured by just 118 unique passwords. On average, every password in use was reused across close to seven different logins. The single most common password appeared 146 times across 87 distinct hosts, meaning it alone would have been worth trying against 87 separate systems. Only 96 distinct usernames appear across all 789 entries, a strong signal that shared service accounts, not individual named logins, protected much of this environment.

Breakdown by category

The category worth sitting with is not the personal accounts, it is the 503 credential pairs for the brand site content management environments themselves, spanning staging, QA, UAT and production instances across dozens of distinct beverage and dairy brand websites, most running the same enterprise CMS platform (Adobe Experience Manager, identifiable from the CMS specific paths and cloud hostnames in the package) with default or reused service account passwords. A password reused across ten test environments is, from an attacker’s point of view, a password that is worth trying on the eleventh, production one too.

Layered on top of that were 27 credentials for cloud infrastructure, DevOps and source control consoles, and 29 credentials for corporate identity and SSO providers, plus a further 540 browser session cookies exported from the same two browsers, among them sessions for a mainstream identity provider and a major cloud office suite. Session cookies matter because, if still valid and replayed before they expire, they can grant access to an already authenticated session without ever touching the account’s password or its multi factor prompt, we have not tested whether any specific cookie in this package still works, only that this class of exposure is present.

What most credential monitoring tools skip entirely

Most programs that watch for stolen credentials stop at two things: passwords and cookies. This package shows why that is not enough. Its autofill store, the cache of values a browser remembers to speed up form filling, held a different kind of evidence altogether, the kind most monitoring tools never look at because autofill was never designed to hold credentials in the first place, and it turned out to hold as much as the credentials themselves.

Personal identity

A full name, a street number and postal code consistent with a home address, and a number formatted as a valid national identification document, plus the local storage folder for a consumer password manager browser extension.

Client side identity and documents

An email address on the client’s own domain, used repeatedly across the package, saved alongside links that look like the organization’s own internal documents and systems.

Network footprint

Six IP addresses distinct from the 19 exposed admin consoles described above, including a registered network block associated with a Brazilian city.

Cloud and DevOps activity

A confirmed AWS console action deleting a cloud resource, a production environment named explicitly alongside staging, UAT and test, and a source code search against a specific, versioned release branch.

On the personal identity side, the password manager folder holds the extension’s encrypted vault state; infostealers routinely exfiltrate it wholesale, and whether it can be unlocked depends on the specific malware family and on how strong the underlying master password was; we found no evidence in this package that the vault had actually been decrypted.

More strikingly, the forms filled out by this individual also reveal a persistent identity on the client’s own domain, an email address issued directly by the organization rather than by the vendor, appearing repeatedly, dozens of times, across unrelated saved logins and forms throughout the package. Saved alongside that identity are entries that look like references to the organization’s own internal documents and systems, personal cloud storage links, a production content address, an internal knowledge base page, and search terms tied to a privacy compliance effort. A small number of entries also name other, separate people at the organization, who appear to have simply shared a document with this individual at some point. Below are illustrative, redacted examples of what these entries look like in the raw data:

None of that is marketing website content. It is internal legal, privacy, and architecture material, further evidence that this exposure reached past staging servers and into the kind of internal work product an organization would assume stayed behind its own walls.

Separately, the same store recorded a direct AWS console action, a cloud resource identified by its internal reference being deleted, evidence of hands-on infrastructure management rather than a login that was saved and never used. Deployment tool fields nearby named a production environment explicitly, alongside staging, UAT and test equivalents, and a separate field recorded a search for open pull requests against a specific, versioned release branch in a source code repository. None of this is a password or a cookie either; it is proof of an active operator working inside real systems, a different and arguably stronger signal than a saved login that may never have been used.

• 6: additional IP addresses found only in autofill data, distinct from the 19 above
• 3+: internal document or meeting references tied to the client’s own domain, found in autofill
• 1: confirmed AWS console action, a cloud resource being deleted
• 1: production environment named explicitly in deployment tool fields

Taken as a whole, none of this came from a password field or a cookie file. It is contextual evidence, a working client identity, real documents, real infrastructure actions, real environment names, and it is exactly what turns a generic-looking credential list into proof of an active operator with production-level access, all starting from one infected laptop that belonged to an outside vendor, not to Fairlife itself. It is also exactly the evidence a monitoring program built only to flag exposed passwords and session cookies will never surface, because it never looks at the autofill store at all.

Infrastructure exposed directly to the public internet

Beyond the brand hostnames already discussed, the package also contained 19 credential pairs for admin consoles reached directly by public IP address rather than by a domain name, with no VPN or reverse proxy evident in the saved path, plus a further 72 credential pairs for the same kind of console on private, internal IP ranges reachable only from inside a corporate or vendor network. We cannot confirm from the package alone which client or project each of these specific addresses belongs to; they were saved using the same admin console pattern seen throughout the rest of this vendor’s credentials, Adobe Experience Manager’s CRXDE Lite and Package Manager, which is consistent with the same vendor managing them as part of its broader portfolio rather than evidence tying them specifically to Fairlife. Both of those consoles are development tools, not public-facing pages. CRXDE Lite lets a logged-in user browse and edit the underlying content repository directly, and the Package Manager lets a logged-in user upload a package that installs and runs on the server. That is the mechanism behind real-world incidents where this kind of exposed console was used to run attacker-supplied code, so pairing it with working admin credentials in the same package turns a single stolen login into control of the server itself, not just its content.

The same package also included saved sign-in credentials for Amazon Web Services accounts across four separate regions: US East, two US West zones, and South America. On top of the CMS access already described, this one credential set could reach into cloud infrastructure spanning multiple regions and continents.

One vendor, more than one client

The package also lets us answer a question that matters a great deal for how an organization should think about this kind of risk: was this person a direct employee of The Coca-Cola Company, or someone working for a vendor that serves many clients? The evidence points toward the latter. Alongside the brand and CMS credentials, the package included logins and session cookies for a distinct set of internal tools, an identity provider, an internal learning academy, an HR self-service portal, and at least three separate Slack workspaces tied to different client account teams, all branded separately from The Coca-Cola Company.

At the same time, the picture is not perfectly clean. As the autofill findings above show, the same package also contained one email account issued directly on the victim organization’s own domain, used repeatedly and alongside what look like the organization’s own internal documents, evidence that the individual had, at some point, been provisioned a client side identity for closer collaboration, a common practice with embedded vendor staff that quietly erases the boundary between vendor risk and an organization’s own risk.

Just as tellingly, the credentials were not limited to The Coca-Cola Company’s brand family. The package included exactly one confirmed credential pair for a development environment whose hostname referenced a well-known global quick service restaurant chain, entirely unrelated to Fairlife or The Coca-Cola Company. We only found one such pair, so we are not claiming broad access to that other company’s systems; only that it exists at all is the point. It is consistent with how shared services vendors typically operate; the same staff often hold credentials for more than one unrelated enterprise client at once, which means a single infection on a single laptop at a vendor like this does not necessarily stay contained to one client.

• 19: public IPs saved with admin console credentials, no network layer barrier evident
• 4: distinct AWS regions with sign-in credentials in the same package
• 2: unrelated enterprise clients with confirmed credentials in the same package
• 1: client-issued email account found alongside the vendor’s own identities

EMPLOYEE, OR THIRD PARTY

Our read of the evidence is that this was a vendor employee, not a direct hire of The Coca-Cola Company, based on the concentration of separately branded internal tools and multi-client Slack workspaces in the package. We are flagging our reasoning, not just our conclusion, so it can be checked; the same reasoning is what led us to also find the one client-issued mailbox that complicates a clean answer. We think that complication is worth stating plainly rather than smoothing over. Either way, the distinction changes the right response: a compromised direct employee is contained by that one company’s own controls; a compromised vendor employee is contained by nobody’s controls by default, unless every client that vendor serves is independently monitoring for exactly this kind of exposure.

Illustrative, redacted log entry

WHY WE KEEP COMING BACK TO THIS EXAMPLE

Nothing in this package came from Fairlife’s or The Coca-Cola Company’s own network. It came from a laptop belonging to an outside agency contracted to build marketing websites. That distinction is precisely why it matters: security teams monitor their own endpoints closely and their vendors’ endpoints almost never, yet the credentials on that one vendor laptop opened doors into shared brand infrastructure just the same.

Beyond Infostealers, the Compilation Economy

What Constella sees that a single infostealer feed does not

Infostealer logs are only one piece of the credential exposure picture, and treating them as the whole picture is one of the most common blind spots we see in security programs today. In a large share of the cases our research team investigates, individual credentials tied to a victim organization surface days, sometimes weeks, inside compiled credential lists well before a threat actor packages and posts a complete, named breach or ransomware disclosure. These compilations pull together credentials from many smaller sources, older breaches, smaller infostealer runs, phishing kits, and unrelated third-party leaks, and circulate quietly among initial access brokers long before any single victim organization is named publicly.

This is the layer where initial access brokers do their real work. Rather than running their own infections, many brokers specialize in combing through combolists and stealer logs, verifying which corporate logins still work, and packaging that verified access for sale to whichever ransomware affiliate is buying that week. A credential that looks unremarkable inside a generic compilation can be worth hundreds or thousands of dollars once a broker confirms it opens a live corporate VPN, SSO portal or cloud console.

This is also why Constella does not monitor infostealer output alone. Our platform correlates identity exposure across breach data, credential compilations, active infostealer logs and ransomware leak site disclosures in a single data layer, which is precisely how we are able to look at a case like this one and connect a credential package on one side to a leak site disclosure on the other. Most vendors in this space specialize in one of those four sources. As far as we can tell, Constella is the only company positioned to give an organization a single, correlated view across all of them, which is what makes it possible to catch the exposure while it is still sitting quietly in a compilation, long before it becomes the headline.

Connecting the Dots

A plausible, evidence-consistent reconstruction, not a forensic conclusion

We want to be careful here. We cannot claim certainty that this specific package was the specific entry point Anubis used; attribution at that level of precision normally requires incident response access that neither artifact grants on its own. What we can say is that the two pieces of evidence are consistent with, and illustrative of, the exact pattern seen across the large majority of ransomware intrusions our industry tracks: a commodity infostealer infection upstream, a ransomware detonation downstream, and a broker economy somewhere in between turning one into the other.

Commodity infostealer infection

An employee at a third-party vendor is infected through a phishing lure, cracked software, or a malvertised download. The malware harvests browser saved passwords, session cookies, autofill data, and any local password manager vault, then exfiltrates it as a single package within minutes.

The package enters the compilation economy

The log is uploaded to a Telegram-based stealer channel or dark web marketplace, then often folded into larger compiled credential lists that get recirculated and reindexed by country, browser, and domains of interest, including the corporate CMS and cloud console hostnames it contains.

An initial access broker verifies and packages it

Brokers specifically search fresh logs and compilations for enterprise SSO, VPN, and cloud console strings, then confirm which ones still work. A package containing dozens of live corporate credentials and session cookies for a household name brand is worth far more resold as verified access than as a raw log.

A ransomware affiliate buys access

An Anubis affiliate, or a group exploiting a parallel vulnerability such as the CitrixBleed 2 flaw reported in connection with this wider campaign, uses purchased credentials or a related edge device exploit to establish a foothold, then moves laterally from vendor-adjacent infrastructure toward the client’s core network.

Exfiltration, encryption, wipe, extortion

Roughly a terabyte of data is staged and exfiltrated. Encryption is triggered across production systems, wipe mode is used selectively for added pressure, and the leak site post goes up days later as the extortion lever.

The Third Party Blind Spot

Most enterprise security programs are still built around a simple, outdated assumption: that the perimeter which matters most is the one around their own employees and endpoints. A growing share of ransomware intrusions never touch a victim’s own laptop at all. They touch a vendor’s laptop, a marketing agency, a managed service provider, a contractor with a login to a shared content platform, and ride that trust relationship inward.

In the case we walked through, a marketing and technology vendor held standing credentials into staging and production content systems for dozens of brand properties, credentials that show clear signs of having gone unrotated for a long time, were not scoped to least privilege, and were, as far as we can tell, never monitored for exposure on criminal marketplaces or in credential compilations. That is not a failure unique to any one company; it is close to the industry default, and it is precisely the gap Constella’s platform was built to close.

How Constella Helps Close This Gap

Recommendations we can back with our own platform capabilities

• 01 Monitor your own organization and your vendors across every source that matters. Constella gathers information from breach data, credential compilations, active infostealer logs, and ransomware leak site activity in one place, so a silent infection becomes an actionable alert long before it is weaponized.
• 02 Extend that visibility to third parties by contract, not by hope. Constella’s identity risk intelligence can be scoped to named vendors and contractors, so a marketing agency or managed service provider with standing access to your systems is monitored with the same rigor as your own workforce.
• 03 Catch credentials while they are still in a compilation. Because our data lake spans more than 1 trillion attributes, Constella regularly surfaces exposed corporate credentials while they are sitting quietly inside a compiled list, well before a broker or affiliate has packaged them into a named attack.
• 04 Treat session cookie exposure as seriously as password exposure. Stolen session cookies can bypass MFA entirely. Constella’s telemetry includes cookie and token exposure alongside credentials, giving security and identity teams a fuller picture than password monitoring alone.
• 05 Get alerted the moment exposure appears, not on a quarterly cycle. Constella’s API delivers real-time alerts as soon as credentials tied to your organization or your vendors surface anywhere across our sources, so your team can act immediately instead of waiting for a periodic review.

See your own exposure before a threat actor does

If a package like the one in this post exists for your organization or one of your vendors, we would rather you heard it from us first. Talk to our team about how Constella’s Hunter+ platform can put your identity risk and your third-party risk in one view.

Talk to Constella Intelligence