Executive Summary

    Updated March 26th, 2025: We've updated this blog to show how the login servers labs discovered earlier in the week relate to the Oracle cloud login flow also provided continued samples from the attacker as recent as this year. Please review the section titled "Update - March 26th 2025" for more details.

    On March 20th, a user on BreachForums claimed to have compromised Oracle Cloud Infrastructure (OCI). The breach reportedly affected servers responsible for authenticating users to Oracle Cloud services. The individual provided sample data to support their claim and offered to sell access to “about 6 million” credentials and authentication materials for 100,000 Monero (XMR), a cryptocurrency considered more difficult to trace than bitcoin. The threat actor is offering to remove any compromised accounts from the data dump for an unspecified payment and to trade breach information for 0-day exploits.

    BSL-A1115-Figure-1

    Figure 1: BreachForums screenshot

    In response, security researchers have been working to validate and confirm these findings while Oracle has denied any breach to multiple security reporters at BleepingComputer, TheRegister, and Dark Reading. While the extent of the breach is still unclear, they claimed to have access to a authentication server hosted at login.us2.oraclecloud[.]com and samples of the data they were attempting to sell included various types of authentication data and files related to Oracle Cloud systems. This would contain data for authentication to Oracle Cloud services, as an authenticator provider not only stores authentication for users but includes credentials and grants for automated systems. In short, LDAP user data, certificate information in Java Keystore files, Enterprise manager JPS keys, and access to any service backing its authentication with Oracle's cloud services.

    The entire collection of stolen authentication data was not leaked in the BreachForums post, rather a list of impacted Oracle clients was shared. Beazley Security Labs has collected and correlated the list with Beazley insured organizations and Beazley Security direct clients to communicate with potentially impacted organizations.

    At the time of writing, Oracle claims that their cloud service was not compromised. However, Beazley Security strongly recommends organizations that use Oracle Cloud verify how they are authenticating to Oracle Cloud applications and rotate any passwords or secrets that are shared amongst different services. Without additional information from Oracle, the security community lacks sufficient data to determine if this threat actor has been successfully eradicated. As a result, it is possible that they may still have access to Oracle's Cloud Infrastructure. Therefore, rotating unique passwords used only on OCI before Oracle provides more details may not be an adequate solution. Please refer to the Mitigation Steps section of this advisory for further details.

    This is a developing situation, and this advisory will be updated as more information is available.

    Affected Systems or Products

    Based on the data we have so far, Beazley Security believes OCI is affected, specifically their Authentication Platform on login.us2.oraclecloud[.]com.

    Beazley Security Labs has identified that the vulnerability may extend beyond this specific cloud region; therefore, it is advised to consider all Oracle Cloud services as potentially compromised. The affected server was seemingly Oracle Fusion Middleware 11g, which is vulnerable to CVE-2021-35587. While it’s possible that Oracle had deployed mitigating controls to this system, the Threat Actor has claimed that they compromised the Oracle Fusion Middleware using a known CVE with no publicly available Proof of Concept (POC).

    If the attack utilized this vulnerability, it is recommended that users of Oracle Fusion Middleware update their software with the latest patches immediately.

    Mitigations / Workarounds

    Effective mitigation steps depend on how an organization authenticates to Oracle Cloud Infrastructure. Organizations should determine which OCI products they are using and what authentication systems are in place.

    SAML

    If an organization is using SAML authentication, the threat actor may have access to public keys used to verify SAML assertions signed by your identity provider. This situation presents somewhat less risk, as the threat actor would not be able to forge authentication requests. However, if SAML assertions were encrypted and the threat actor is in possession of Oracle Cloud’s private decryption keys, they could decrypt authentication assertions.

    Regardless of how these assertions are sent (signed or signed and encrypted), these assertions contain sensitive user information such as email addresses, group memberships, and potentially other identity attributes such as Oracle Cloud services permissions that could be exploited for targeted attacks. Regardless, actions related to administration of Oracle’s infrastructure are Oracle’s responsibility, and without further information from Oracle, little can be done from the position of a user.

    OIDC

    If an organization is using Open Connect (OIDC), there may be slightly higher risk. If this threat actor has obtained the OIDC client secret for Oracle Cloud, they could impersonate Oracle Cloud’s authentication requests to your identity provider. This would allow them to request valid sessions and authenticate as your users to Oracle Cloud. We recommend rotating any OIDC secrets for any organization using this authentication mechanism.

    General Recommendations

    Regardless of implemented authentication strategies for Oracle Cloud applications and connected services, organizations should consider any credentials or secrets in Oracle Cloud compromised and should rotate any that may be reused elsewhere within the organization.

    While we would also normally recommend credential rotation in Oracle Cloud as well, we need to reiterate that at the time of writing, Oracle denies that a breach actually occurred. This means that while Beazley Security reasonably concludes that Oracle Cloud authentication systems are compromised, we cannot conclude that the threat actors have been removed from those systems as again, Oracle denies that a breach occurred.

    Technical Details

    Much of what is written here is a summarization of a two-part post from Rahul Sasi on CloudSEK, If you find interest in our additional findings please give them the attention they deserve. [Part1] [Part2]. However, there are some interesting findings that we’re publishing for the first time 👀.

    After the initial BreachForums post from “rose87168” security researchers began working to validate the reported breach. Rose87168 had confirmed access to at least one of the affected servers login.us2.oraclecloud[.]com by creating a publicly accessible link on the server at the address `https[:]//login.us2.oraclecloud.com/oamfed/x.txt?x.` This would imply that rose87168 had access to modify and read files on at least one of Oracle’s authentication systems. While this file is no longer available, proof of its existence can be found on the Web Archive’s WayBack Machine To confirm that login.us2 was a legitimate Oracle production server, CloudSEK validated oracle’s quickstart documentation code on Github to show the url of the affected server was used. Following this, CloudSEK searched publicly available Github repositories for API keys to Oracle, finding five such cases, and correlated them to domains in the leak from rose87168.

    This leads security researchers to a reasonable conclusion of sketchy behavior for the login.us2.oraclecloud[.]com server. However, we now must work to validate a mechanism for the attack that could have compromised this server. Some researchers have guessed that the version of Oracle Fusion Middleware was old enough on this server assert that it may have been impacted by a critical vulnerability (CVE-2021-35587). Beazley Security Labs has not validated this assumption at the time of reporting. Also, it's once again worth noting that it's possible that Oracle had deployed mitigating controls to prevent exploitation of this vulnerability.

    Rose87168 spoke with Bleeping Computer and claimed to have been on this server for 40 days before attempting to sell this data. In order to investigate this, Beazley Security leveraged the Wayback Machine in an attempt to get insight into the version of Oracle Fusion Middleware that was running on this host during the threat actors purported access. We can find an archived page from February 17th of this year showing this server was running “ORACLE FUSION MIDDLEWARE 11g”. Using this information, we can start to find other Oracle Fusion Middleware 11g servers matching the pattern of login.*.oraclecloud.com. Below are several examples of what appear to be Oracle managed systems that are online as of this writing:

    • login.us9.oraclecloud[.]com

    • login.us8.oraclecloud[.]com

    • cldadmininternal.us8.oraclecloud[.]com 👀

    BSL-A1115-Figure-2

    Figure 2: login.us8.oraclecloud[.]com

    Navigating on this site we can see a section labeled ”Online Documentation” showing the version on some Oracle Cloud Services to be 11.1.1.5, which appears to be software released in 2009 according to Oracle’s documentation.

    BSL-A1115-Figure-3

    Figure 3: Version information

    It’s worth noting here that there are many more services that we know are running this software but are do not appear to be directly related to Oracle Cloud Infrastructure. If rose87168 had leveraged a vulnerability within Oracle Fusion Middleware for us2, we can reasonably assume that these other services are currently vulnerable if there are not other mitigating controls.

    Additionally, a twitter account by the same name started posting information that seemingly corroborates the BreachForum’s account. This includes a link to video shared through Anonfile.io that seemingly shows internal administrative training that rose87168 claims to have pulled from the server. While the connection between this twitter user and our BreachForum’s user is not confirmed, it would behoove one to keep an eye out continued TA activity on this twitter account.

    At this point we as users have little actionable work to do to remediate this issue. Oracle denies any breach of data, and without a public statement from Oracle explaining the archived pages presented above, end users have little recourse to know if there will be action from Oracle moving forward. This includes whether rose87168 still has access to login.us2. Making password rotation potentially fruitless. Doubly so, while patches exist for Oracle Fusion Middleware that address currently known vulnerabilities, without acknowledgement of a vulnerability or attack, users running on-premise versions of this software have little to do to mitigate risk. This places security researchers in a precarious situation of reporting potentially incorrect information, while Oracle can continue to deny any potential impact.

    Update - March 26th 2025

    There has been continued speculation about the validity of these leaks and whether they are used for different services. As we have continued to observe, there is a correlation between users of Oracle's services and the domain leaks from rose87168. Compounding this, we have seen continued communications from rose87168 on BreachForums showing user entries from 2025, which correlates with the narrative presented from rose87168 on their initial postings.

    BSL-A1115-Figure-9

    While these entries may be forged, we believe that if an exploit was used to gain entry into login.us2.oraclecloud.com, other active oracle servers would still be vulnerable to this attack (as described above). This can be trivially demonstrated by attempting to log into Oracle Cloud and signing in with a "Traditional Cloud Account"

    BSL-A1115-Figure-10

    Which presents Oracle Cloud data-centers to authenticate to:

    BSL-A1115-Figure-11BSL-A1115-Figure-12

    Leading a user to an authentication portal that appears to be hosted on the same addresses as listed earlier in this post.

    BSL-1115-Figure08

    As previously demonstrated in our initial advisory, an educated attacker would be able to trivially determine which of these are active and still running vulnerable services. While there have been many arguments presented from various individuals online about the validity of this data, all of the evidence that we have seen leads us to believe that Oracle is likely compromised and should present the technical information to disprove the exploitation of their service, provide an explanation of the arbitrary file placed on their webserver, and reasonable action for individuals who may have been targeted. This would include messaging regarding patches, updates, and an explanation of the disruption of these services, as login.us2.oraclecloud.com appears to be unavailable at the time of this posting. Other Oracle Cloud servers still appear to be running vulnerable software as of this update.

    Part of the confusion surrounding this is the overloaded term of SSO. Single Sign On is a term we use to describe multiple standards (OIDC, SAML2) to authenticate to a service without storing that authentication information on the service itself. SSO Providers will allow "external" services to authenticate to their Identity Provider (IdP) and the Identity Provider will provide a result that the external service can use to validate and log the user in. The information presented and gathered from security researchers over the last several days implies that the SSO IdP was compromised, meaning that the authentication to servers is suspect, and that the Identity Provider's user accounts are also suspect. This is why, presently there is little end users can do to mitigate potential risk, if these IdP servers are compromised and we do not have updates from Oracle about a resolution, the attacker may still have an active presence on an IdP and continue to exfil any rotated credentials. While our investigation appears to show that these SSO providers are used to authenticate to "external" Oracle services, it would imply that these credentials are valid for production work cases.

    How Beazley Security is responding

    Beazley Security Labs has collected the list of supposedly impacted organizations and correlated the list with Beazley insured organizations and Beazley Security direct clients to communicate with potentially impacted organizations.

    Sources