Today, we are releasing a new tool called SharpConflux, a .NET application built to facilitate Confluence exploration. It allows Red Team operators to easily investigate Confluence instances with the goal of finding credential material and documentation relating to objectives without having to rely on SOCKS proxying.
SharpConflux is available for download from the GitHub repository below:
GitHub: https://github.com/nettitude/SharpConflux/
Background
Red Team operators typically interact with the target organisation’s network via an in-memory implant supported by a Command and Control (C2) framework such as Fortra’s Cobalt Strike, MDSec’s Nighthawk or Nettitude’s PoshC2. Direct access to the corporate network through a Virtual Private Network (VPN) or graphical access to a Virtual Desktop Infrastructure (VDI) host is unusual, meaning that in order to interact with internal corporate websites, operators must tunnel traffic from their systems to the internal network, through the in-memory implant.
Multiple tooling exists for this purpose such as SharpSocks and Cobalt Strike’s built-in socks command. However, this approach presents two problems:
- First of all, it is troublesome to setup. While a seasoned operator will be able to do so in minutes, I have yet to know a Red Teamer that enjoys the setup process and the laggy browsing experience. In fact, this tool was created as a result of a recent Red Team exercise during which, none of the operators wanted to have to setup proxying to explore an internal Confluence instance.
- Secondly, in order to provide a stable and usable experience, it forces operators to set the implant’s beaconing time to a small value (almost always less than 100 milliseconds, and often 0 milliseconds). This significantly increases the number of HTTP requests transmitted over the existing C2 channel, creating abnormal volumes of traffic and therefore, providing detection opportunities. Additionally, this prevents certain in-memory evasion techniques from functioning as expected (e.g. Cobalt Strike’s sleep masks), thus potentially leading to a detection by the Endpoint Detection & Response (EDR) solution in place.
SharpConflux aims to bring Confluence exploration functionality to .NET, in a way that can be reliably and flexibly used through common C2 frameworks.
Confluence Introduction
Confluence is a data sharing platform developed by Atlassian, generally used by organisations as a corporate wiki.
Content is organised in spaces, which are intended to facilitate information sharing between teams (e.g. the IT department) or employees responsible for specific projects. Furthermore, users can setup their own personal spaces, to which they can upload public or private data.
Within these spaces, users can publish and edit web pages and blog posts through a web-based editor, and attach any relevant files to them. Additionally, users can add comments to pages and blog posts.
The diagram below, which has been extracted from Confluence’s support page, better illustrates the structure used by the platform:
From a Red Teamer’s perspective, Confluence is particularly useful in two scenarios:
- During early stages of the operation, as all sorts of credentials can typically be found in Confluence. These may facilitate privilege escalation and lateral movement activities.
- To discover documentation, hostnames and even credential material relating to the objective systems, which are usually targeted after achieving high levels of privileges and therefore, in late stages of the cyber kill chain.
Confluence Instance Types and Authentication
Atlassian offers three Confluence hosting options to fit different organisation’s requirements:
- Confluence Cloud instances are maintained by Atlassian and hosted on their own AWS tenants. This is the preferred option for newer Atlassian clients. Confluence Cloud instances are accessed as a subdomain of atlassian.net. For instance, https://companysubdomain.atlassian.net/wiki/.
- Confluence Server and Confluence Data Center instances are maintained by the relevant organisation and therefore, they are hosted on their servers. This can be completely on-premise, or in any cloud tenant managed by the organisation (e.g. Azure, AWS, GCP). Both instance types are similar but Data Center includes additional features. It should be noted that Atlassian has decided to discontinue Confluence Server and support ended in February 2024. However, it still has plans to support Confluence Data Center for the foreseeable future. These instance types run on TCP port 8090 by default and can typically be accessed through an internal FQDN (e.g. http://myconfluence.internal.local:8090). For the purpose of this tool, Confluence Server and Confluence Data Center are considered equivalent.
Even though a lot of organisations are migrating to Confluence Cloud, a significant proportion of them still use on-premise Confluence instances. In fact, it is not uncommon to find companies that have already made the move to Cloud but still maintain on-premise instances for specific internal projects, platforms or departments.
Certain attributes and API endpoints differ slightly between Cloud and Server / Data Center instances. More importantly, authentication methods are significantly different. SharpConflux has been developed with compatibility in mind, supporting a variety of authentication methods across the different instance types.
The most relevant authentication methods are described below.
Confluence Cloud: Email address + password authentication
Users can authenticate to Confluence Cloud instances using an email address and password combination. Upon browsing https://companysubdomain.atlassian.net/wiki/, unauthenticated users are redirected to https://id.atlassian.com/login, where the following form data is posted:
{
"username":"EMAILVALUE",
"password":"PASSWORDVALUE",
"state":
{
"csrfToken":"CSRFTOKENVALUE",
"anonymousId":"ANONYMOUSIDVALUE"
},
"token":"TOKENVALUE"
}
If the provided credentials within the username and password parameters, in addition to the csrfToken and token parameters are correct, the server will return a redirect URI. Subsequently accessing this URI will cause the server to set the cloud.session.token session cookie.
This authentication method is not supported by SharpConflux. From an adversarial perspective, firms very rarely rely on this authentication mechanism, as most will be using SAML SSO authentication for Cloud instances.
Confluence Cloud: Email address + API token
Users can create and manage their own API tokens by visiting https://id.atlassian.com/manage-profile/security/api-tokens:
In order to authenticate, the user’s email address and API token are submitted through the Authentication: Basic header in each HTTP request.
This authentication method is supported by SharpConflux. However, gathering valid API tokens is a rare occurrence.
Confluence Cloud: Third Party and SAML SSO
Confluence Cloud allows users to log in with third party (e.g. Apple, Google, Microsoft, Slack) accounts. Typically, firms will configure Confluence Cloud instances to authenticate through Active Directory Federation Services (ADFS) or Azure AD.
Once the SAML exchange is completed, the server will return a redirect URI to https://id.atlassian.com/login/authorize. Subsequently accessing this URI will cause the server to set the cloud.session.token session cookie.
As of the time of release, this authentication method is not supported by SharpConflux. Whilst this is the most commonly deployed authentication method by organisations relying on Confluence Cloud, it is also frequent for them to enforce Multi-Factor Authentication (MFA), making cookie-based authentication a much more interesting method from an adversarial perspective.
Confluence Cloud: Cookie-based Authentication
If you have managed to dump Confluence Cloud cookies (e.g. via DPAPI), you can use SharpConflux to authenticate to the target instance. Please note that including a single valid cloud.session.token or tenant.session.token cookie should be sufficient to authenticate, but you can specify any number of cookies if you prefer.
Confluence Server / Data Center: Username + password (Basic authentication)
By default, Confluence Server / Data Center installations support username + password authentication through the Authorization: Basic HTTP request header. However, Basic authentication can be disabled by the target organisation through the “Allow basic authentication on API calls” setting:
This authentication method is supported by SharpConflux. From an adversarial perspective, finding a username and password combination for an on-premise Confluence instance is one of the most common scenarios.
Confluence Server / Data Center: Username + password (via form data)
Users can visit the on-premise Confluence website (e.g. http://myconfluence.internal.local:8090) and log in using a valid username and password combination. The following HTTP POST request will be sent as a result:
POST /dologin.action HTTP/1.1 [...] os_username=USERNAMEVALUE&os_password=PASSWORDVALUE&login=Log+in&os_destination=%2Findex.action
If the provided credentials within the os_username and os_password parameters are correct, the server will set the JSESSIONID session cookie.
This authentication method is supported by SharpConflux. Similarly to the previous method, finding a username and password combination is one of the most common scenarios. Please note that this authentication method will still work even if the “Allow basic authentication on API calls” setting is disabled.
Confluence Server / Data Center: Personal Access Token (PAT)
On Confluence Server / Data Center installations, users are allowed to create and manage their own Personal Access Tokens (PATs), which will match their current permission level. PATs can be created from /plugins/personalaccesstokens/usertokens.action:
In order to authenticate, the PAT is submitted through the Authentication: Bearer header in each HTTP request.
While this authentication method is supported by SharpConflux, it has only been added for completeness and to support edge cases, as I have never come across a PAT.
Confluence Server / Data Center: SSO
Similarly to Confluence Cloud instances, Confluence Server / Data Center variations support authentication through various Identity Providers (IdP) including ADFS, Azure AD, Bitium, Okta, OneLogin and PingIdentity. However, in this case, it is uncommon to find on-premise Confluence instances making use of SSO. For this reason, this authentication method is not supported by SharpConflux as of the time of release.
Confluence Server / Data Center: Cookie-based authentication
If you have managed to dump Confluence Server / Data Center cookies (e.g. via DPAPI), you can use SharpConflux to authenticate to the target instance. Please note that including a single valid JSESSIONID or seraph.confluence cookie should be sufficient to authenticate, but you can specify any number of cookies if you prefer.
Summary
Confluence is the most widely used corporate wiki platform, often storing sensitive data that can largely facilitate privilege escalation and lateral movement activities. Whilst this blog post has not uncovered any new attack techniques, release of SharpConflux aims to help Red Team operators by providing an easy way to interact with all types of Confluence instances.
SharpConflux has been tested against the latest supported versions as of the time of development (Cloud 8.3.2, Data Center 7.19.10 LTS and Data Center 8.3.2). A complete list of features, usage guidelines and examples can be found in the referenced GitHub project.
GitHub: https://github.com/nettitude/SharpConflux/
