DISCLAIMER

This blog post presents a technical analysis prepared by ZenoX at the request of and in collaboration with the news portal TecMundo. It is based on information and data samples allegedly related to a security incident and shared by the aforementioned journalist for the purpose of analysis and the development of technical recommendations for potential victims.

Our objective is to technically assess the plausibility of the threat actor’s claims, analyze the data provided, and discuss the potential security risks involved. This material does not constitute a complete forensic investigation.

No definitive conclusions regarding the actual occurrence of the incident or the legal responsibility of the companies mentioned should be inferred solely from this analysis. It is important to note that, as of the date of publication, Oracle officially denies the occurrence of any security incident in its systems related to these allegations. We recommend using Oracle’s official channels to obtain information regarding this and any other alleged data breaches.

All data used or received during the preparation of this blog post has been deleted.

Executive Summary

ZenoX Threat Intelligence has completed a comprehensive analysis of the alleged Oracle Cloud Identity breach reported in March 2025. Despite Oracle’s official denial, our technical assessment strongly indicates that a significant security incident has likely occurred. This report represents a continuation of our initial technical analysis dated March 20, 2025, now with access to a substantially larger data sample.

Our analysis reveals:

• An expanded sample of 10,000 records maintains consistent structure with previously analyzed data
• 89% of emails in the sample are “first-seen” breached data not present in prior leaks
• Verification confirms the threat actor gained access through multi-stage exploitation
• Compelling evidence suggests this represents a genuine compromise of Oracle’s core infrastructure
• This research-backed CTI bulletin provides a technical breakdown of our findings and essential mitigations that organizations should implement immediately.

This research-backed post provides a technical breakdown of our findings and essential mitigations that organizations should implement immediately.

Breach Background

In March 2025, a threat actor using the handle “rose87168” claimed to have compromised Oracle Cloud infrastructure, specifically the authentication systems (SSO/LDAP) at login.{region-name}.oraclecloud.com endpoints. The actor asserted they had exfiltrated approximately 6 million user records and provided evidence including LDAP structures and credential hashes.

Oracle has maintained there was no security incident, while the threat actor continues to present additional evidence to news outlets such as Bleeping Computer. Through collaboration with TecMundo news portal, ZenoX obtained access to a significantly larger data sample (s.txt) containing approximately 10,000 records for independent verification.

It’s worth noting that we have observed circulation of imprecise information regarding this alleged leak and the methodologies used to validate it. Some analyses, like the one published by CloudSEK, rely on evidence that could be constructed from public information rather than definitive proof of the breach.

Technical Analysis of Expanded Sample

Following our initial analysis based on smaller samples, we received and analyzed an additional file named s.txt. This file contains approximately 10,000 records, representing a significantly larger sample than the previously examined Sample_Database.txt (~100 records) from our earlier report, allowing for a more robust validation of the data and the attacker’s claims.

Confirmation of Structure and Consistency

1. Format and Structure: The s.txt file is presented in a tabular format, similar to a CSV, with values delimited by commas and enclosed in single quotes. The first line contains column headers (USR_KEY, ACT_KEY, USR_LAST_NAME, etc.), confirming that the data structure is identical to the smaller sample previously analyzed. This structural consistency between samples strengthens the claim that both originate from the same compromised data source.
2. Types of Exposed Data: The analysis of the 10,000 records confirms the presence of the same types of sensitive data identified in the smaller sample:
   • Internal Identifiers: USR_KEY, ACT_KEY
   • Personally Identifiable Information (PII): USR_LAST_NAME, USR_FIRST_NAME, USR_DISPLAY_NAME
   • Credentials and Account Status: USR_EMAIL, USR_LOGIN, USR_PASSWORD (containing hashes/encrypted values), USR_STATUS (Active/Deleted), USR_TYPE (End-User, End-User Administrator, Identity Domain Administrator), USR_DISABLED, USR_LOCKED
   • Temporal Metadata: USR_CREATED, USR_PWD_EXPIRE_DATE, USR_PWD_WARN_DATE
   • LDAP Linkage: USR_LDAP_GUID, USR_LDAP_DN with format (cn=…,cn=users,orclMTTenantGuid=…,dc=cloud,dc=oracle,dc=com) consistent with previous LDAP samples
   • Tenant Information: Fields such as USR_UDF_TENANT_GUID, USR_UDF_TENANT_NAME, and USR_UDF_NONMT_LOGIN reinforcing the multi-tenant architecture of Oracle Cloud Identity

Validation and Implications

1. Scale and Scope: The larger sample confirms the diversity of affected organizations, including accounts associated with domains such as @oracle.com, @gmail.com, @hotmail.com, as well as numerous global corporations from various sectors. The presence of accounts like @c9sftporacle.com may indicate service or infrastructure-specific accounts.
2. Internal Consistency: No obvious inconsistencies were identified within the 10k-line sample. The data appears coherent and aligns with expectations for a user table from a complex, multi-tenant identity management system. Date patterns (many accounts created in late 2022) persist, which may point to a specific activity window—such as mass onboarding or migration—captured in the dump.
3. Password Hashes: The USR_PASSWORD field consistently contains non-null values that appear to be hashes or encrypted data (e.g., ‘128***************e9so/yJmvEWppY=’). While the exact format may vary or follow a prefix+hash pattern, the widespread presence of these values validates the attacker’s claim of having obtained stored credential data.
4. Administrative Accounts: The confirmed presence of administrative accounts (End-User Administrator, Identity Domain Administrator) significantly raises the potential risk of the incident. Compromise of such accounts could enable lateral movement and deeper access within affected tenants.
5. Leak Plausibility: This expanded sample, due to its size and consistency with previous information and the expected structure of an Oracle Identity system (potentially OID/OUD/IDCS connected to a database), significantly increases the plausibility of the leak claim—despite Oracle’s official denial. The nature of the data is consistent with a deep compromise of the central identity management system, possibly through a vulnerability such as CVE-2021-35587.

The analysis of the 10,000-record sample (s.txt) reinforces the preliminary conclusions. The structure and types of data are consistent with previous samples and with a multi-tenant Oracle Cloud Identity system. The widespread presence of PII, corporate emails from various organizations, internal identifiers, LDAP linkage, and—critically—data in the USR_PASSWORD field lends greater credibility to the attacker’s claim regarding the occurrence and scale of the compromise.

Challenges in Data Validation and Confirmation of the Attack Methodology

One of the main challenges in validating this new dataset (the 10k-line sample), as well as the smaller samples publicly shared on BreachForums, lies in the discrepancy between the data structures presented as part of the same incident. As we highlighted in our previous report, this structural heterogeneity raised questions regarding the consistency of the alleged leak.

Was observed that while one of the files (Sample_Database.txt and s.txt) displays a well-defined tabular format typical of a relational database dump, another file (Sample_LDAP.txt) features a structure characteristic of LDAP data, and the original post also mentions other artifacts (JKS files, keys, etc.). The database sample, in particular, contains fields like USR_PASSWORD (with hashes) and USR_LDAP_DN, suggesting a linkage, but not necessarily a single and straightforward origin.

Our preliminary technical analysis indicated that the isolated exploitation of a single vulnerability, such as CVE-2021-35587 (RCE in Oracle Access Manager), would hardly explain the retrieval of data in such distinct formats (relational database structure, LDAP structure, and configuration/key files) without the execution of additional complex actions and significant lateral movement following the initial exploitation.

In collaboration with the TecMundo news portal, this question was presented directly to the threat actor: how can the differences in the obtained data structures be explained?

When questioned by the journalist about this discrepancy, the threat actor confirmed the suspicions raised by our analysis. They stated that the data extraction from the Oracle environment did not occur through a single exploit, but rather through a series of actions executed after gaining initial access to the allegedly vulnerable server.

Additionally, during the interaction mediated by the journalist, the threat actor requested that specific technical details regarding the methods and techniques used to extract the data from Oracle servers not be publicly disclosed in this report.

Implications

The threat actor’s confirmation that multiple actions were required validates our initial technical analysis and suggests a deeper and more persistent compromise than the mere exploitation of a single vulnerability followed by a data dump. This indicates that the attacker likely had the ability to:

• Execute arbitrary commands on the compromised system.
• Access different data sources (potentially the identity database and LDAP directory separately, or interconnected systems).
• Locate and exfiltrate configuration files and sensitive keys.

Therefore, although confirming the exact origin of each dataset remains a challenge without full access to logs or systems, the threat actor’s own admission of a complex methodology reinforces the plausibility that they obtained broad access to various components of Oracle’s identity infrastructure. Based on this, we proceed with the detailed analysis of the available samples.

Validating the New Sample

The scenario surrounding the alleged Oracle leak presents a significant validation challenge: the company’s official denial contrasts with the threat actor’s ongoing claims and demonstrations (such as the alleged upload of files to Oracle domains). This ambiguity complicates the development of effective response strategies and clear communication with executives at potentially affected organizations.

In this uncertain context, a more detailed validation approach involves identifying, within the exposed dataset, a substantial volume of information that could not have been easily obtained or fabricated by the actor using preexisting public sources. The key concept here is “First Seen“—the presence of data (in this case, email addresses) that were not previously known to be compromised before this specific incident.

If a significant proportion of the data in the sample is “First Seen,” this substantially strengthens the hypothesis of a genuine new leak, as it would suggest that the actor gained access to information not previously exposed in other documented breaches. This methodology contrasts with validations based solely on correlation with publicly known data (such as legacy GitHub configurations or previous breach appearances), which, while useful for risk context, can be more easily manipulated or compiled by an attacker to falsely legitimize a fabricated dataset.

Based on this principle, the most effective strategy we adopted was:

1. Extract all unique emails from the new 10,000-line sample (s.txt), resulting in 14,965 unique email addresses in the file emails.txt.
2. Use cross-referencing results of these emails with the Have I Been Pwned (HIBP) database to quantify the proportion of emails that had not appeared in previously documented breaches (identified as “Clean” or “EmailsNotInBreaches” in the HIBP analysis).

The analysis of these results—specifically the quantity and nature of the emails classified as “Clean” by HIBP—provides crucial insights into the possible authenticity and novelty of the data allegedly leaked from Oracle.

Technical Methodology of the “First Seen” Analysis via HIBP

To assess the proportion of “First Seen” emails in the 10,000-line sample (s.txt), we adopted the following technical process:

1. Extraction and Consolidation: Using a Go script, we read the sample file, identified, and extracted email addresses from the relevant columns (such as USR_EMAIL). To ensure accurate counting and avoid redundant checks, we stored only unique emails, resulting in a final list of 14,965 addresses saved in the emails.txt file.
2. Cross-Referencing with the HIBP API: We developed a second Go script that read the list of unique emails (emails.txt). For each email:
   • We made a request to the v3 API of Have I Been Pwned (HIBP) using the /breachedaccount/{email} endpoint, authenticating with our API key.
   • We implemented rate-limiting to respect the request limit per minute defined by the -rate parameter (45/min in this case).
   • We used goroutines (workers, defined by the -workers parameter, 5 in this case) to process emails in parallel, within the established rate limits
   • We interpreted the API responses: HTTP 200 OK indicated a “pwned” email (present in previous breaches), HTTP 404 Not Found indicated a “clean” email (potentially “First Seen”), and other codes indicated errors. Counters were updated atomically for each category.
3. Metric Aggregation: At the end of the process, the totals of verified emails, pwned, clean, and errored emails were consolidated. We calculated additional metrics, such as the frequency of each breach and the average number of breaches per pwned email. All results were saved in a JSON file (hibp_analysis.json), as specified by the -output parameter.

This method allowed us to efficiently quantify the prior exposure of the emails in the sample and identify the significant proportion of addresses potentially “First Seen“.

HIBP Results Analysis and “First Seen” Insights

The cross-referencing of the 14,965 unique emails from the expanded sample against the Have I Been Pwned (HIBP) database provided crucial quantitative insights. Notably, 13,312 emails (89.0%) were not found in any previously documented public breaches, classifying them as potentially “First Seen.” In contrast, 1,615 emails (10.8%) were identified as already “pwned,” with a concerning average of ~5.17 prior breaches per email. Only 38 checks (0.25%) resulted in errors.

The main takeaway from this analysis is the exceptionally high proportion of “First Seen” emails. The presence of nearly 90% of addresses with no prior record of public compromise makes the hypothesis of fabricated or compiled old data highly unlikely. It would be extremely difficult for a threat actor to generate a list of this magnitude with such a high degree of “novelty.” This result strongly reinforces the plausibility that the sample originates from a genuine and recent security incident within Oracle’s systems, providing compelling circumstantial evidence that contradicts the company’s official denial.

While the majority of emails may be new in this context, the 10.8% already “pwned” represent an immediate and elevated risk. The high average of prior exposures (~5.17) for these users indicates that their credentials are circulating in illicit markets and are frequent targets—making them vulnerable to credential stuffing attacks across various services, potentially including Oracle Cloud, regardless of whether the attacker successfully decrypts specific passwords from this incident.

The cross-referencing of the 14,965 unique emails extracted from the expanded sample against the Have I Been Pwned (HIBP) database revealed important quantitative data for analyzing the authenticity and risk associated with the alleged leak:

• “Clean” Emails (Potentially “First Seen”): 13,312 (89.0%) – Not found in previously documented public breaches.
• “Pwned” Emails: 1,615 (10.8%) – Found in one or more previous public breaches.
• Average Breaches per “Pwned” Email: ~5.17
• Verification Errors: 38 (0.25%)

Insights from the Results

1. Strong Indicator of Authenticity (“First Seen”): The finding that 89% of the emails in the sample are potentially “First Seen” (i.e., not present in known public breaches) is the most significant insight from this analysis. It is extremely difficult and unlikely for a threat actor to fabricate a list of nearly 15,000 unique emails where the vast majority have never appeared in previous leaks. Compiled lists from old breaches or public sources would show a much higher percentage of “pwned” emails. This high rate of “novelty” strongly supports the hypothesis that the sample originates from a genuine and recent security incident, rather than being a simple compilation of old data. It lends strong plausibility to the actor’s claim of an actual compromise.
2. High and Immediate Risk for “Pwned” Emails: While the majority of emails are “First Seen,” the 10.8% (1,615 emails) that had already been compromised in previous breaches represent an immediate and elevated risk. The average of ~5.17 breaches per email indicates that these specific users are recurring targets, and their credentials (potentially reused) are circulating in illicit environments. This makes them vulnerable to credential stuffing attacks on any service they use— including, potentially, Oracle Cloud—regardless of whether the attacker can decrypt specific SSO passwords from this incident.
3. Top Breach Analysis: By examining the breach_frequency metric, we identified the breaches where the “pwned” emails from this sample most frequently appeared. Key highlights include:
   • Data Aggregators/Lead Generation Platforms: PDL (Peoples Data Labs – 508 occurrences), Apollo (252), DemandScience (351), Naz.API (107). The high presence in these lists indicates massive exposure of contact and professional data, facilitating targeted phishing campaigns (spear-phishing).
   • Massive Compilations (Combo Lists): Collection #1 (245), Exploit.In (198), OnlinerSpambot (207), Cit0day (172), Verifications.io (174), AntiPublic (92), Telegram Combolists (153), db8151dd (111). The recurrence in these lists confirms that credentials associated with these emails have already circulated widely, increasing the risk of password reuse.
   • Major Popular Services: LinkedIn (very frequent, >236), Adobe (151), Dropbox (187), Canva (76), Deezer (160), Gravatar (225), Twitter (7 + 197 in the “200M” list), Nitro (131). This reflects the diverse online usage profile of the affected users.
   • Stealer Logs: AlienStealerLogs (139), TelegramStealerLogs (16). This indicates more direct and potentially recent credential compromises via malware.

The HIBP analysis, especially through the “First Seen” lens, provides the strongest circumstantial evidence to date that the leak alleged by the threat actor is likely to be authentic and contains new data, not merely a recycling of old information. The overwhelming majority (89%) of emails with no prior breach history makes the fabrication hypothesis highly unlikely. At the same time, the analysis confirms a high and pre-existing risk for approximately 11% of the users in the sample, whose credentials have been compromised multiple times, making them vulnerable to immediate attacks.

Additional Validation of “First Seen” Emails via Direct Contact

Although the high proportion of “First Seen” emails (89%) identified via HIBP is a strong indicator of the leak’s authenticity, there remained the theoretical possibility that these addresses could have been synthetically generated, albeit valid in format. The HIBP check confirms only the absence of these emails in previous public breaches, not their existence or current activity within a specific system such as Oracle’s.

To mitigate this uncertainty and add an extra layer of validation, we conducted a targeted verification effort for a subsample of the emails classified as “Clean” / “First Seen.” This was done through confidential channels and in collaboration with trusted clients and partners whose domains were present in the list:

1. Selection: We identified a set of email addresses belonging to these partner organizations within our list of 13,312 “First Seen” emails”.
2. Contact and Verification: We reached out to security focal points at these organizations and discreetly requested verification of the existence and status (active or recently active) of the selected emails within their internal systems (user directories, email systems, etc).
3. Confirmation: Through this process, we obtained positive confirmation of the existence and validity of 16 distinct email accounts that were part of our “First Seen” dataset.

Although 16 accounts represent a small fraction of the total number of “First Seen” emails, the confirmation of their actual existence and association with specific organizations is qualitatively significant. This demonstrates that:

• The “First Seen” list is not composed (at least not entirely) of randomly generated or invalid emails. There are real, active (or recently active) accounts within this dataset.
• It reinforces the likelihood that the vast majority of the 13,312 “First Seen” emails also correspond to valid user accounts extracted from a legitimate data source (in this case, allegedly Oracle systems).
• Combined with the overall high proportion of “First Seen” emails, this direct sampling validation substantially increases confidence in the general authenticity of the data sample and in the occurrence of a genuine new security incident, rather than an elaborate fraud using synthetic data.

This step of direct verification, confirming the existence of “First Seen” accounts, complements the HIBP analysis and solidifies the conclusion that the dataset shared by the threat actor indeed has a high likelihood of representing a genuine compromise.

The Hypothesis of Leakage via Partner Servers

Given the complexity of validating the incident—particularly due to Oracle’s denial and the threat actor’s ongoing claims (including demonstrating access to Oracle domains)—an alternative hypothesis emerged in unofficial discussions: the possibility that the data originated from Oracle partner servers rather than directly from Oracle’s core infrastructure.

This hypothesis is based on the fact that companies can license and host Oracle systems (such as SSO or IAM components) on their own infrastructure. A failure by these partners to apply security patches could theoretically lead to a compromise.

We evaluated this possibility in two ways:

• Technical Plausibility: It is technically feasible that a partner’s server running outdated Oracle software (for example, vulnerable to CVE-2021-35587) could be compromised.
• Logistical Implausibility: However, the breadth of the leaked data (millions of records, hundreds of thousands of domains across various countries and sectors, including Oracle’s own accounts) makes it highly improbable that a single partner server would contain such a vast and diverse set of identity information spanning multiple Oracle Cloud tenants. This scenario would require either a compromise on a much larger scale or from a centralized system.

Despite the low logistical probability, definitively proving or disproving this hypothesis solely using publicly available data and samples was challenging. Therefore, once again in collaboration with the TecMundo journalist, the question was directed to the threat actor: Were the extracted data sourced from servers directly managed by Oracle or from partner-operated servers?

The threat actor’s response was direct and aimed at refuting the partner-server hypothesis. He provided new evidence: two detailed LDAP records that, according to him, belong to Oracle’s CEO. The clear implication is that data belonging to such a high-profile account would be unlikely to reside on an isolated partner server, and would instead be stored on Oracle’s central and primary infrastructure.

Insights from the Additional Evidence

1. Consistent LDAP Structure: The records follow the expected Distinguished Name (DN) format for Oracle Cloud Identity, including orclMTTenantGuid, and contain typical attributes (mail, uid, cn, sn, givenName, objectClass, etc).
2. Presence of Password Hashes: The second record explicitly includes fields such as authPassword;oid (with partially obscured SASL/MD5 hashes) and userPassword (with what appears to be an SSHA hash encoded in Base64), corroborating the threat actor’s claim of having access to authentication data.
3. Multiple Records/Tenants: The existence of two distinct records for the same individual, each with different orclMTTenantGuid values, suggests that the CEO might have accounts in different tenants or contexts within Oracle’s infrastructure (possibly one corporate—corpsso—and another identified as a454031), reflecting the complexity of identity management within a large corporation.
4. Refuting the Partner Hypothesis: If authentic, such sensitive data pertaining to a central Oracle figure renders the hypothesis that the leak originated exclusively from an isolated, mismanaged partner server extremely implausible. It is far more likely that such information resides in central systems managed directly by Oracle.

The presentation by the threat actor of LDAP data allegedly belonging to Oracle’s CEO strongly counters the hypothesis that the leak was limited to partner-operated servers. The nature of the data (consistent LDAP structure, presence of hashes, high-profile information, and indication of multiple tenants/accounts) points to access involving central components of Oracle’s identity infrastructure. Although definitive authenticity of these specific records cannot be guaranteed without internal confirmation, they align well with other evidence (data samples, “First Seen” analysis, multi-stage attack confirmation), reinforcing the conclusion that the incident likely involved a direct compromise of systems managed by Oracle itself.

Recommendations

Given the technical analysis indicating a high likelihood of a genuine compromise involving Oracle Cloud identity systems, and considering both immediate and potential risks identified (despite Oracle’s official denial), we strongly recommend organizations currently using or that have used Oracle’s SSO/LDAP/IAM services adopt the following proactive and mitigating actions:

1. Urgent Implementation of Multi-Factor Authentication (MFA): Implementing or enforcing MFA for all access to Oracle Cloud and integrated systems is the most critical and effective measure against credential compromise, whether from direct leaks or credential stuffing. This should be the highest priority.
2. Immediate Credential Review and Rotation: Although the capability to decrypt SSO hashes is not confirmed, as a precaution and due to credential stuffing risks (confirmed by HIBP analysis), we recommend:
   1. Forcing a password reset for all users utilizing Oracle SSO/LDAP.
   2. Enforcing the use of strong, unique passwords, discouraging reuse across services.
   3. Invalidating and rotating any API keys, tokens, or secrets associated with Oracle identity system integrations.
3. Urgent Verification of Security Patches (CVE-2021-35587 and Others): Given the plausibility of CVE-2021-35587 exploitation in Oracle Access Manager (OAM), it is crucial to immediately verify that all OAM components (and related systems) under the company’s management (if applicable in on-premise or IaaS scenarios) are updated with Oracle’s latest Critical Patch Updates (CPU), especially those addressing CVE-2021-35587.
4. Implementation/Review of WAF Rules: Configure or review Web Application Firewall (WAF) rules to detect and block known attack patterns targeting Oracle Access Manager, specifically including attempts exploiting CVE-2021-35587 and similar vulnerabilities.
5. Rigorous Permission Review (Least Privilege Principle): Conduct a comprehensive audit of access permissions within Oracle identity systems. Strictly apply the principle of least privilege, ensuring that users and service accounts have only essential permissions. Special attention should be given to administrative accounts (Identity Domain Administrator, End-User Administrator).
6. Internal Risk Assessment and Threat Intelligence:
   1. Internally evaluate the extent of Oracle identity service usage and potential impact of compromised credentials..
   2. Actively monitor Threat Intelligence sources for Indicators of Compromise (IoCs) or Tactics, Techniques, and Procedures (TTPs) associated with the threat actor “rose87168” or this specific incident.
7. Updating Detection Systems: Adjust rules in SIEM, IDS/IPS, and other security tools to detect anomalous behaviors related to authentication, identity data access, and potential Oracle Access Manager exploitation attempts.
8. User Communication and Awareness: Communicate transparently (within confidentiality limits) to users regarding potential risks, the importance of strong and unique passwords, the mandatory use of MFA, and how to report suspicious activities. Reinforce training on phishing and social engineering.
9. Incident Response Plan Review: Update the incident response plan explicitly to include scenarios involving compromised cloud identity providers and large-scale credential leaks

While the situation may evolve with new information from Oracle or independent investigations, proactively acting based on the available technical evidence is the most prudent approach to mitigate the significant risks identified in this report.

Conclusion

The detailed technical analysis conducted by ZenoX regarding the alleged security incident involving Oracle’s SSO/LDAP systems, based on available evidence and claims, points strongly toward a genuine and significant compromise. Data samples shared by the threat actor “rose87168” demonstrate remarkable internal consistency and alignment with expected structures of Oracle Cloud Identity systems, including multiple password hash formats and specific identifiers such as orclMTTenantGuid. The hypothesis involving exploitation of CVE-2021-35587 in Oracle Access Manager, combined with subsequent confirmation by the threat actor of a multi-stage post-exploitation attack, provides a technically plausible vector for acquiring the observed diversity of data (LDAP, database, keys).

The disclosure of LDAP data allegedly belonging to Oracle’s CEO, if authentic, strongly undermines the alternative theory that the leak originated solely from mismanaged partner servers, suggesting instead direct access to core Oracle systems. However, the strongest circumstantial evidence supporting the authenticity of the leak lies in the “First Seen” analysis. Cross-referencing 14,965 unique emails from the expanded sample against the HIBP database revealed that nearly 90% had no prior record in publicly documented breaches. This exceptionally high proportion of potentially “new” data—partially validated by direct contact with partners—renders the hypothesis of fabrication or compilation from old data highly improbable, lending significant credibility to the actor’s claims of a recent incident.

While Oracle officially denies the incident, the weight of technical evidence analyzed strongly suggests otherwise. Regardless of ultimate confirmation, the risks are clear: approximately 11% of the users in the sample already have a high history of prior breaches (an average of ~5.17 previous leaks), making them immediately vulnerable to credential stuffing attacks. If the threat actor’s claims regarding possession of keys and decryption capability are accurate, the risk extends directly to the compromise of accounts involved in this incident.

Given this scenario, and despite the absence of definitive forensic proof (which would require internal access), ZenoX concludes that there is a substantial and genuine risk associated with this alleged incident. It is essential that potentially affected organizations adopt a proactive posture by implementing the mitigation measures recommended in this report to protect their assets and users.