RansomHouse Claims the Trellix Breach, and the Screenshots Show More Than Source Code

RansomHouse claimed responsibility on May 7 for the Trellix breach the cybersecurity firm disclosed last week — and Cybernews researchers say screenshots posted by the group show internal VMware, Rubrik, and Dell EMC dashboards. That's a much wider compromise than Trellix's "portion of our source code repository" framing suggests. The group claims the intrusion occurred April 17, encrypted data, and is offering negotiation under its signature "Evidence Depends on You" label.

On Thursday, May 7, 2026, the data-extortion group RansomHouse listed Trellix on its dark-web leak site, claiming responsibility for the breach Trellix had disclosed six days earlier. The group published seven screenshots described by RansomHouse as proof of intrusion. Cybernews researchers reviewed those screenshots and identified dashboards linked to several enterprise infrastructure platforms — VMware (virtualization), Rubrik (backup and data management), and Dell EMC (storage) — concluding that "the attackers may have accessed broader operational infrastructure rather than isolated development repositories."

Trellix's response to BleepingComputer, SecurityWeek, and The Hacker News has been a single sentence: "aware of claims of responsibility for the attack and are looking into it." The company has not confirmed whether the RansomHouse claim is connected to the source-code incident it disclosed on May 1, and has not updated its prior statement that "based on our investigation to date, we have found no evidence that our source code release or distribution process was affected." The discrepancy between Trellix's narrow framing and RansomHouse's screenshot-based claim is the operational story for Trellix customers — and the editorial thread that distinguishes this update from the original disclosure.

For full context on the original disclosure, see The CyberSignal's coverage of Trellix's May 1 source-code repository breach announcement. This update covers the May 7 RansomHouse claim and the screenshot-based evidence that the breach scope may extend beyond the source code repository Trellix has acknowledged.

What the Screenshots Show, and Why It Matters

BleepingComputer noted explicitly that it could not confirm the authenticity of the screenshots. That caveat is real and operationally important: RansomHouse could be authentic, partially fabricated, or mislabeling material from a different victim. With that caveat in place, the substance of Cybernews's analysis is what makes the May 7 update editorially distinct from the May 1 disclosure. Cybernews researchers wrote: "These earlier-mentioned internal systems handle way more than just the source code of a launched product. … Regardless, the impact of this incident can extend to companies that use Trellix products, because these product databases could've been affected as well."

VMware, Rubrik, and Dell EMC management consoles are not where source code lives. They are where virtualization, backup, and storage operations are administered — environments that often contain backups, cached credentials, system configurations, internal documentation, and operational data including, in some configurations, customer-related telemetry. Cybernews's recommendation to Trellix was direct: "The company should rotate all compromised credentials used to access these systems, rotate to the latest safe database backups if needed, and they should transparently state which systems have been affected." If RansomHouse's screenshots are authentic, Trellix's "portion of our source code repository" framing materially understates the breach scope.

RansomHouse's "Evidence Depends on You" Negotiation Framing

RansomHouse listed Trellix on its leak site under the status "Evidence Depends on You" — a hallmark tactic the group uses to pressure victims into negotiations before publicly releasing stolen data. The group brands itself as a "professional mediator community" and typically seeks payment for data deletion rather than (or in addition to) decryption. The group emerged in 2022 as a data-extortion specialist; it later added an encryption capability via two distinctive utilities. Mario ESXi ransomware performs a dual-encryption pass with two keys, with code lineage from the leaked Babuk ransomware source. MrAgent is an automation tool that deploys encryptors at scale on VMware ESXi hypervisors. Palo Alto Unit 42 tracks the operators as "Jolly Scorpius." The group's leak site lists more than 170 victims as of disclosure.

The targeting fit is operationally interesting. RansomHouse's specialty is VMware ESXi compromise via stolen credentials. The dashboards Cybernews identified in the screenshots include VMware. If the screenshots are authentic, the breach pattern matches RansomHouse's known tradecraft. RansomHouse's most recent high-profile case before Trellix was Japanese e-commerce giant Askul Corporation, where the group stole 740,000 customer records. The Trellix case would represent a meaningful uplift in target value — a major cybersecurity vendor with 53,000 customers across 185 countries.

Why Trellix Customers Should Be Asking Hard Questions

Trellix protects more than 200 million endpoints. If RansomHouse had access to virtualization, backup, and storage management consoles in Trellix's environment, the questions for Trellix customers are: was your endpoint telemetry visible? were your security policy configurations exposed? were Trellix-managed agent-to-cloud authentication credentials compromised? Trellix's published statement does not answer any of these. The company's promise to "share further details as appropriate" after the investigation concludes is the standard vendor language for an incident still being scoped — but Trellix customers running production deployments cannot wait for the perfect statement to begin defensive activity.

The 2026 pattern of cybersecurity vendor breaches — Cisco's internal development environment compromise in April (via credentials stolen in the Trivy supply-chain attack), Checkmarx's LAPSUS$ disclosure last week, and now Trellix — suggests the attack surface for security vendors is no longer categorically different from typical enterprise environments. The Cisco precedent is particularly relevant: when an attacker has development credentials at a security vendor, source code is the headline but operational infrastructure is the broader risk.

The Trellix follow-up reads alongside a broader vendor-and-supply-chain compromise pattern accumulating across May 2026. The CyberSignal's coverage of the Daemon Tools trojanized-installer campaign documented Kaspersky's early-May disclosure that a properly signed installer shipped malware for nearly a month — same theme of trusted vendors as attacker-leveraged distribution channels, same downstream customer exposure that vendor-level statements alone do not resolve.

Defender Actions for Trellix Customers and ESXi Operators

• For Trellix customers: engage Trellix support directly for a written impact statement specific to your environment. The "portion of our source code repository" framing is too narrow to support a defensive risk assessment. Demand specifics: was Trellix product telemetry from your environment in scope? were customer-facing API credentials, agent enrollment tokens, or vendor-side analytics platforms affected? "Looking into it" is not a customer-actionable answer.
• Review Trellix product telemetry-and-configuration access logs for the period from approximately April 17, 2026 forward — the date RansomHouse claims the intrusion began. If your Trellix products send telemetry to vendor-side analytics, treat that telemetry stream as potentially compromised until Trellix says otherwise. Hunt for unusual administrative activity on Trellix-managed endpoints, including unauthorized policy changes or unusual exclusion lists.
• Rotate any credentials that integrate with Trellix products — API keys, service accounts, anything authenticating between your environment and Trellix-managed services. The credential-rotation cost is small; the cost of being wrong about exposure is large.
• For organizations running VMware ESXi, regardless of Trellix exposure: re-baseline your environment given RansomHouse's specialty. Verify ESXi management interfaces are not internet-exposed. Confirm root and admin credentials have been rotated within the last 90 days. Implement strict change-control on ESXi VIBs and lockdown mode. Verify off-platform backups exist for VMs with backup credentials not accessible from production environments.
• For executive teams: this is the third major cybersecurity vendor breach disclosure of 2026 (Cisco, Checkmarx, Trellix). The pattern argues against treating any single vendor as a complete security stack. Defense-in-depth still applies — even when, especially when, your security vendor itself is breached. The Trellix incident, if proven to extend beyond source code, becomes the year's clearest illustration of why you cannot outsource your security posture to a single vendor.

The CyberSignal Analysis

Signal 01 — Vendor disclosure framing is now an active risk-assessment input, not a baseline

The May 1 "portion of our source code repository" framing reads differently after May 7. Either Trellix's forensics scope was accurate and RansomHouse's screenshots are authentic but unrelated to the source-code incident — possible but operationally awkward — or Trellix's first disclosure understated the scope. Both possibilities have the same defensive implication: customers cannot treat a vendor's first public statement as a reliable scope-of-impact statement. Pre-script your IR playbook for vendor breaches with the assumption that the vendor's first public statement will be optimistic. Treat "portion of" qualifiers and similar narrowing language as flags to ask harder questions. The Canvas / Instructure case from this week's other coverage is a parallel example. The pattern is now consistent enough to be a default working assumption.

Signal 02 — Cybersecurity vendor breaches are now a category, not an anomaly

Cisco in April, Checkmarx last week, Trellix this week. Three publicly disclosed cybersecurity-vendor breaches in approximately 30 days. The pattern argues that the security industry's own attack surface is no different in kind from that of any other software vendor — and that source code, development credentials, and administrative consoles are equally accessible to motivated attackers regardless of vendor self-positioning. For CISOs, the operational implication is to apply the same vendor risk assessments to security vendors that you apply to any other enterprise software vendor: third-party risk reviews, contractual notification requirements, defined credential-rotation procedures for vendor-side compromises. The reflexive trust some organizations extend to security vendors as a category is no longer empirically supported.

Signal 03 — RansomHouse's "professional mediator" branding is still data extortion

RansomHouse's self-presentation as a "professional mediator community" is the kind of vocabulary that complicates defender decision-making. The group claims to focus on data deletion rather than encryption-and-decryption, and to engage in negotiation rather than coercion. The substance, regardless of branding, is that the group steals data and threatens to publish it unless paid. The branding makes ransom payments easier to characterize internally as "a settlement" rather than "a payment to a criminal organization" — and that's the point. For organizations whose IR playbooks include a Schelling-point ransom-payment policy, RansomHouse's language is the kind that makes "never pay" decisions harder to defend in the moment. Pre-commit decision-making is essential. Boards should already have ransom-payment policy decided in principle before any specific incident — including for groups that brand themselves as mediators rather than ransomware operators.

Sources