From DNS Takeover to Org Admin: Secondary Attacks on Atlassian Cloud

Notice: Prior to the publication of this research, Obsidian responsibly disclosed the issue to Atlassian and collaborated with them to ensure that appropriate auditing mechanisms are in place to assist customers in investigating the topics discussed in this blog post.This issue highlights a cross-system risk — where a compromise in one layer (such as DNS) can have direct security implications for another, IE SaaS platforms. DNS security plays a critical role in protecting SaaS environments, and is often more impactful than it appears on the surface. Atlassian has implemented controls to prevent the "Join as Admin" feature from being abused in a DNS compromise scenario, and has road mapped additional features designed to assist customers in this situation in the future. Both Obsidian and Atlassian have taken steps to verify existing customers are not currently impacted by an attack using these methods.

This is not an issue unique to Atlassian — similar risks may exist across other SaaS platforms that rely on domain-based identity or ownership. We appreciate Atlassian’s responsiveness and collaboration throughout the disclosure process, and their commitment to transparency and customer security.

Background

In a recent incident, Obsidian uncovered a serious case of "cross-organization privilege escalation" in an Atlassian cloud environment.

After successfully compromising a customer’s domain outside of the Atlassian environment, the attacker used the compromised domain to gain org admin privileges to the customer’s Atlassian account. After being detected, the security team removed the attacker from the organization. But that wasn’t the end — far from it.

The attacker kept coming back.

The attacker rejoined the organization multiple times, each time with full org admin access. In some rounds, they even removed legitimate admins, effectively locking out the defenders. What followed was a prolonged tug-of-war between the attacker and the victim org’s security team. For a while, the organization had no meaningful control over its own environment.

Through further research, we were able to reconstruct the full attack path. This wasn’t a typical breach involving social engineering of an admin or misuse of invitation flows. Instead, the attacker cleverly abused Atlassian’s "Verify a domain to manage accounts" and "Join as Admin" features, combined with DNS takeover techniques, to gain persistent org admin access. All through legitimate, documented functionality.

Let’s dive deep into the details.

The Risk of Shadow IT

Before we explore how the feature works, it’s important to understand the problem it was built to solve.

In the Atlassian ecosystem, users aren’t restricted to a single app or organization. With a corporate email address, anyone can create their own organization and set up products like Jira or Confluence, or join someone else’s organization, all without involving IT. While this flexibility lowers the barrier to adoption, it also introduces the risk of shadow IT.

That means users at your company might be creating their own Atlassian sites without your knowledge. These self-managed instances can become silos of sensitive data, completely outside the visibility and control of your IT or security teams. Worse, if someone invites external collaborators, people outside your organization could end up with access to internal content — and no one would know.

‍

Atlassian’s Solution

To give org admins greater ease of control over products within and outside their organizations - including shadow IT, Atlassian introduced the "Verify a domain to manage accounts" and "Join as Admin" features.

A domain refers to your company’s email domain — for example, yourcompany.com.When you verify a domain for your organization, you gain the ability to claim and manage all Atlassian accounts under that domain, and also gain control over the apps those users have created.

Here’s what the typical process looks like:

Verify Domain Ownership

Atlassian provides a few verification methods you can choose from:

• HTTPS file upload – Place a specific HTML verification file in the root directory of your website. This can be done at the apex domain or on the www subdomain.
• DNS TXT record – Add a special TXT record to your domain’s DNS settings. This is a common method used in domain-based verifications.
• Identity provider integration – If you’re using Google Workspace or Microsoft Entra ID, you can link them to your Atlassian organization. Any domains managed through those providers will be automatically verified without additional steps.

You can verify your domain using one or more methods. You can’t remove all of them — at least one verification method must stay in place, as Atlassian will periodically recheck domain ownership.

Notably, public email domains like gmail.com and outlook.com are on Atlassian’s blocklist and can’t be verified, which makes sense.

Claim Accounts

Once the domain is verified, you can claim the accounts associated with that domain. These accounts may already exist within your organization or in another organization. Claimed accounts become managed accounts.

In Atlassian, organization users and managed accounts are two separate concepts:

• Inviting users to your organization adds them to the Users list, but not to Managed accounts.
• Users refers to people you’ve explicitly invited to your organization, while Managed accounts are accounts using your verified domain that you have administrative control over, even if they belong to other organizations.

You might wonder why verifying a domain doesn’t automatically give you control over all associated accounts.

This is because a single domain can be verified by multiple organizations. For example, different departments, subsidiaries, or business units may each manage their own Atlassian organization under the same corporate domain.

However, each account can only be claimed (and thus managed) by one organization. So in essence, claiming is how your organization decides which accounts it actually wants to manage.

The below screenshot shows that the same domain is verified in both the Attacker Org and the Legit Org. The Legit Org has Claim New Accounts set to Automatically and the Attacker Org has Claim New Accounts set to Manually.

You have two options for claiming new accounts: "Manually claim" or "Automatically claim".

Note that only one organization can enable "Automatically claim" for a given domain. If one organization has already enabled this setting, other organizations won’t be able to use "Automatically claim" for the same domain. Additionally, once "Automatically claim" is active for an organization, no other organization can claim any new accounts under that domain. Therefore, if a domain has been verified by multiple organizations, Atlassian recommends using the "Manually claim" option instead.

Managed Accounts

A user account that organizations claim becomes a managed account. You can perform several administrative actions: update basic account details, send password reset links (note: you can’t reset the password directly), deactivate or delete accounts, apply authentication policies, and force users to log out.

You can also view which Atlassian apps a user has access to. However, if the apps were created by the managed account under another organization, you don’t have permission to manage them.

If you need to manage these apps, refer to the next section.

Discover Apps and Join as Admin

In Atlassian, any app that was directly created by a managed account but falls outside your organization will appear under the Discovered apps page.

From there, you can view all the organization admins associated with that app, and if needed, you can join as an admin to take over management of the app.

What actually happens is that you’re invited to the target organization and automatically assigned the org admin role.

Atlassian has applied additional controls designed to enhance the security of the "Join as Admin" feature to help prevent it being abused in a DNS compromise scenario. To join as admin, there must be at least one admin among the managed accounts — typically the app creator, since only admins can create apps within an organization. If we can see the app, it usually means the creator is (or was) an admin in the target org. However, even if the creator has lost admin rights, the app may still be visible — but attacker would then need to gain control of another admin account to complete the join as admin step.

Key Risks

The "Verify a domain to manage accounts" and "Join as Admin" features makes cross-organization account management significantly easier for administrators. However, it also introduces potential opportunities for abuse. Below are some of the key risks associated with this mechanism.

One Weak Link, Massive Impact

Atlassian allows multiple organizations to verify ownership of the same domain, but the verification process relies on minimal safeguards. Organizations can verify a domain simply by:

• Adding a DNS TXT record, or
• Uploading a verification file to the apex domain or www subdomain.

Critically, there are no effective restrictions preventing malicious or unrelated organizations from verifying a domain already used by a compromised legitimate enterprise.

This opens the door for attackers to create their own organization and illegitimately verify a victim company’s domain. The following are common attack scenarios that can be used to verify a domain on AdminHub:

• DNS compromise: If an attacker gains access to DNS management credentials (e.g., via phishing the domain registrar or social engineering) or API keys, they can add the required DNS record and verify ownership of the domain. One incident response firm recently highlighted a broad and focused effort to compromise DNS registrars and target various SaaS services.
• File upload vulnerabilities: If the website is vulnerable to arbitrary file uploads, an attacker may be able to upload the verification file without needing full control of the domain.
• Subdomain takeover: If the www subdomain is vulnerable to subdomain takeover, an attacker could host the verification file and falsely prove domain ownership.

Once verification is complete, the attacker can claim and manage accounts associated with the domain. In such cases, DNS effectively becomes a single point of failure for domain-based trust.

Expectation vs. Reality

Atlassian claims that once a domain is verified and "Automatically claim" is enabled, no other organization can claim new accounts from that domain.

However, testing shows this is not entirely accurate. There is a short time window, typically a few seconds, between when an account becomes available and when it is automatically claimed. During this period, other organizations can still manually claim the account.

In effect, account claiming follows a first-come, first-served model: as long as the account hasn’t been claimed, it remains up for grabs.

The below video demonstrates that even though an org is configured to automatically claim new accounts, the org with manual claiming can claim the account before the auto claim functionality triggers. Atlassian has implemented detection capabilities to alert them when there are attempts to manually claim accounts when automatically claim is already enabled.

Worth noting: Automatically claim only works for new accounts. Any unclaimed accounts that existed before enabling it, or accounts you later unclaim, won’t be claimed automatically.

Feature at Risk for Abuse

An attacker can gain Org Admin privileges by leveraging apps created by managed accounts.

There are two main cases:

1. The app is created in the managed account’s own organization - for all the managed accounts, they are almost certainly admins in their personal orgs.

2. The app is created in the legitimate organization’s workspace - possible if the managed account has admin rights there.

The second case is clearly more impactful and more attractive to attackers, as it involves more sensitive data. Ideally, verifying the domain would allow the attacker to take over both organizations.

Here are some common attack paths associated with it.

Case 1: Domain Not Verified by the Target Organization

If the legitimate organization hasn’t verified their domain, an attacker can do so first. Once verified, they can claim all existing accounts associated with that domain.

They may then be able to see all apps within the target organization and use the "Join as Admin" feature to become an Org Admin, potentially leading to full organizational takeover.

Obsidian insights reveal that 10% of our customers using Atlassian products have at least one unverified domain.

From a red team perspective: An attacker could easily collect email domains of top 500 companies and use Atlassian’s web API to automatically check which domains have not been verified. This is possible because one API leaks how many organizations have verified a given domain. The attacker can run these checks from their own organization to automate the process quietly.

Add the domain (no need to verify) — just to allow the second request.

Use the API to check if the domain is verified and how many orgs have verified it.

By identifying unverified domains, attackers can focus DNS-based attacks (e.g., DNS takeover) on them.

From a defensive perspective, the same API can help organizations see how many other organizations have verified their domain. Organizations should also confirm that they have claimed their own domains for Atlassian platforms.

Case 2: Domain Verified and Manually claim Enabled

In this case, the domain is verified by the legitimate organization, but only Manually claim is enabled. The attacker can still:

• Manually claim any unclaimed accounts using that domain.
• Stay dormant and wait for new accounts to be created.
• Attempt to claim these accounts before the organization does.
• Exploit any admin accounts among them if they have created, or later create, apps within the organization’s environment.

Obsidian insights show that, among our customers using Atlassian products, 20% have unclaimed org admins and 28% have unclaimed site-admins. This reveals that there is still a good percentage of unmanaged admin accounts that could be claimed by an attacker should they be able to verify an organization’s domain.

Case 3: Domain Verified and Automatically claim Enabled

This is similar to Case 2, but with automated claiming enabled by the real organization. In this case, the attacker must race the auto-claim system to manually claim new accounts during the short window before they are automatically claimed.

While more difficult, this method is still feasible with precise timing or automation.

For verified domains, an attacker can use the API below to retrieve metadata, such as how many accounts remain unclaimed, enabling automated monitoring and preemptive claiming.

Atlassian has implemented additional monitoring and detection tools to identify manual attempts to claim accounts where auto claim is enabled.

Final Thoughts & Recommendations

Even without exploiting traditional vulnerabilities, attackers can achieve full control simply by understanding and abusing intended features.

When DNS is compromised, domain verification for SaaS applications can compound consequences for compromised organizations.

Kicking an attacker out of the organization doesn’t solve the problem if they can return via apps created by managed accounts.

Persistence becomes trivial. Recovery becomes complex.

Security controls must assume that attackers will think creatively - and should defend against exploits and misuse by design.

While responsibility for DNS and web application vulnerabilities may be out of scope for SaaS vendors, a defense in depth strategy is still necessary. Regardless of upstream services being compromised, certain measures can be taken to protect customers and prevent full organizational take over by a malicious actor.

Recommendations for Atlassian

• As a safeguard, domain verification should require that the organization already includes users whose email addresses match the domain. This raises the barrier for malicious actors attempting to verify domains they do not own or control.
• Enforce exclusive auto-claim control: If one organization has enabled "Automatically claim" for a domain, no other organization should be allowed to claim accounts under that domain. A manual transfer mechanism can be provided to allow users to be moved between organizations when necessary
• Consider disabling HTTP-based domain verification: This method introduces risks such as file upload vulnerabilities and domain/subdomain takeover.
• Consider removing or hiding the verifiedOrgsQuantity field from the API response, as it may unintentionally expose how many organizations have verified a given domain — information that could be leveraged by attackers for reconnaissance or targeting.

Recommendations for Organizations

• Regularly audit domain-based accounts.  Verify all your domains and claim all associated accounts, especially admin accounts, as this not only allows you to manage them but also prevents attackers from claiming them.Periodically check that the number of managed accounts matches the number of users using the verified domain. If any accounts are managed by a different organization, it should trigger a security review.

There is an Obsidian Posture control to review any unclaimed admins you may have.

There is also an Obsidian Posture control to review any unverified domains.

• ‍Audit any occurrence of the joined-as-org-admin event type. This event type is rare and only triggered via the shadow IT workflows.  When Discovered apps → Join as admin is used, this will generate the joined-as-org-admin event type within the shadow IT org. Seeing this occur in your corporate Atlassian organization may be your first indicator that this attack vector is being abused. There is an Obsidian Saved Search to review these Shadow IT related events.

• ‍Regularly review DNS record especially after a security incident. Attackers may leave behind malicious TXT records (e.g. for domain verification or persistence), so it’s important to audit and clean up any unauthorized entries to prevent further access. Pay close attention to A and CNAME records for decommissioned services to reduce the risk of subdomain takeovers.