Attending InfoSec?

Are you using Atlassian? You better check if you've been breached

No Service Is Safe – Atlassian Demands Increasing


This year, Cyberint Research Team has witnessed a major spike in compromised Atlassian service credentials compared to 2021. When observing compromised Atlassian credentials from the start of 2021 and 2022 through to August of the relevant year, we have seen an increase of around 337% (Figure 1, 2) in leaked credentials. Given the fact that Atlassian services serve as the gateway to the “promised land” for threat actors, it is only natural that the demand for access to this infrastructure will rise in the coming years.
In addition, recently discovered vulnerabilities allowing RCE and authentication bypass, make things even worse for the Atlassian infrastructure. While the Australian company is doing its best to patch these issues, some of these vulnerabilities have already been exploited in the wild.

Total credentials leaked in 2021/2 throughout January-August
Figure 1: Total credentials leaked in 2021/2 throughout January-August
Comparing Atlassian services’ leaked credentials per month in 2021 and 2022
Figure 2: Comparing Atlassian services’ leaked credentials per month in 2021 and 2022

High Demand – Easy Supply

As mentioned, over the past year, threat actors of all kinds sought to purchase or find vulnerable Atlassian components to exploit, given the huge potential. We have already seen ransomware campaigns exploiting Atlassian vulnerabilities, but it is only logical that other “more serious” threat groups, such as APTs and espionage groups, will make use of these vulnerabilities, if they’re not already doing so.

Finding Exploit

Exploiting Atlassian vulnerabilities is not easy, but they are easy to find. Given the high profile of these vulnerabilities, almost every published CVE recently received a massive number of PoCs developed by threat actors and security researchers alike. For example, the recently discovered remote code execution (RCE) vulnerability, CVE-2022-26134, already has 57 free PoCs available on GitHub (Figure 3).

Underground Telegram group shares free exploits
Figure 3: Underground Telegram group shares free exploits

Strangely enough, we see that the most PoCs being developed by the masses are, for the most, complex and severe CVEs.

A threat actor looking for something more exclusive or targeted, will seek to buy an exploit from experienced exploit developers (Figure 4). These exploits are often sold for between hundreds and thousands of dollars in cryptocurrency.

Threat actor publishing access to Atlassian services for sale
Figure 4: Threat actor publishing access to Atlassian services for sale

Finding Victims

Although many campaigns by most major threat groups are focused on a specific victim, it’s easy to find random potential victims. A quick and broad search using the platform for the “atlassian confluence” component, has already led us to almost 12,000 potential hosts that can be exploited (Figure 5). Of course, versions and other parameters are essential to determining the “ultimate victim”, but following more advanced filtering, we still could locate a substantial number of potential victims.

Number of potential Atlassian victims found on
Figure 5: Number of potential Atlassian victims found on

Finding victims is also part of the threat landscape around these issues. We were able to find underground chatter of threat actors discussing the best and easiest methods for obtaining new potential victims (Figure 6).

Dorking methods for CVE-2022-26134 published on a hacking forum
Figure 6: Dorking methods for CVE-2022-26134 published on a hacking forum

Recent Vulnerabilities


This vulnerability can be exploited thanks to the “Questions For Confluence” plugin for the Confluence Server and Confluence Data Center.

Both of these Confluence services automatically create a user account with the username disabledsystemuser with a hardcoded password.

As mentioned, threat actors can use these hardcoded credentials to gain access to a front-facing Confluence machine and perform data extraction remotely without any previous authentication.

The authentication process consists of an HTTP POST request to the /dologin.action path, as the content of the packet will include the hardcoded username and password disabledsystemuser and disabledsystemuser6708 respectively.

Along with the fix Atlassian provided for the Questions plugin in versions 2.7.36 and 3.0.5, other mitigation methods are also available due to the simplicity and narrow attack surface of this vulnerability. Organizations can monitor the exploitation of this vulnerability by creating network-based indicators identifying login attempts of the automatically generated user, or looking for authentication times and other documentation regarding this user activity, especially if the organization does not have any use for this account.


On June 2, Atlassian published a security advisory regarding a zero-day vulnerability in all versions of the Confluence Server and Data Center that is already being exploited in the wild.

This critical severity vulnerability has the CVE-2022-26134 ID, and a threat actor can exploit this vulnerability in order to perform unauthenticated remote code execution (RCE) [1].

As with any other RCE vulnerability, the potential damage that a threat actor can cause to the victim’s infrastructure can be devastating and might lead to a complete domain takeover if done properly.

Successfully exploited, a threat actor can use this vulnerability to deploy any backdoor, ransomware, information stealer and RATs desired, and run a high alert campaign against organizations using these products.

The exploitation of this vulnerability is fairly simple as a threat actor can use a specially crafted HTTP request including the code they wish to run on the vulnerable server located in the URI.

As expected, once the vulnerability was released, threat actors of all kinds, including the notorious ransomware group AvosLocker, were observed exploiting this vulnerability.

As for mitigation and prevention, the first recommendations from Atlassian included very broad solutions such as restricting access to the Confluence server and Data Center. But on Friday, June 3, Atlassian released a patch to solve this issue.

CVE-2022-26136 & CVE-2022-26137

As mentioned, the main failure point in these two vulnerabilities is the Servlet Filter, which is a Java code that intercepts and processes HTTP requests before a client request is sent to and from a back-end resource, before they’re sent to a client.

Some Servlet Filters provide security mechanisms such as logging, auditing, authentication, or authorization.

These vulnerabilities can be applied to several Atlassian services such as:

  • Bamboo Server and Data Center
  • Bitbucket Server and Data Center
  • Confluence Server and Data Center
  • Crowd Server and Data Center
  • Fisheye and Crucible
  • Jira Server and Data Center
  • Jira Service Management Server and Data Center


Successfully exploiting this vulnerability allows an unauthenticated attacker to bypass Servlet Filters used by first and third-party apps, depending on which filters are used by each app, and how the filters are used.

Currently, only two consequences of this vulnerability were identified: Authentication bypass and Cross-Site-Scripting (XSS), but more outcomes might be still available, but are not yet identified.

According to the Atlassian security advisory[1] for these issues, they have released a fix of the root cause for all products affected by this vulnerability, including any first or third-party apps installed on each product.

The authentication bypass can be achieved by sending a specially crafted HTTP request to Servlet Filters by a third-party app and enforcing authentication.

Cross-site scripting (XSS) can also be done by sending a specially crafted HTTP request, which can bypass the Servlet Filter used to validate legitimate Atlassian Gadgets. This can lead to XSS as a threat actor that can trick a user into requesting a malicious URL and execute arbitrary JavaScript in the user’s browser.


This vulnerability allows a remote, unauthenticated attacker to cause additional Servlet Filters to be invoked when the application processes requests or responses.

As the end result and vulnerable services remain the same as the CVE-2022-26137, the only difference is the result of exploiting this vulnerability, as the former can lead to authentication bypass and XSS., This issue is focused on Cross-origin Source Sharing (CORS) bypass.

CORS bypass is achieved via sending a specially crafted HTTP request that invokes the Servlet Filter used to respond to CORS requests, resulting in a CORS bypass.

Threat actors can trick a user into requesting a malicious URL and can access the vulnerable application with the victim’s permission.

Atlassian has confirmed and fixed this security issue.


The demand for access to third-party services is higher than ever. The increase of leaked Atlassian services credentials for sale, and storming any new RCE vulnerability related to these services, teach us a lot about the mastery of threat actors and threat groups.

As mentioned, threat actors will look to gain access to these services in any way possible, whether via buying access directly from access brokers or developing their own exploits and scanning for potential victims themselves. Either way, the pay-off is huge.

Although we chose to focus on the Atlassian services use case in this report, it is obvious that other platforms similar to those that Atlassian offers, are targets as well.

Currently, third-party services are a crucial entity within an organization, and they should be taken very seriously as a high value link in the supply chain to be targeted by ransomware, espionage, APT and hacktivist groups alike.

Uncover your compromised credentials from the deep and dark web

Fill in your business email to start