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/

 

The post Introducing SharpConflux appeared first on LRQA Nettitude Labs.

Network relaying abuse in the context of a legacy Windows authentication protocol is by no means a novel vector for privilege escalation in a domain context. However, in spite of these techniques being well understood and documented for many years, it is unfortunately still common during the course of an internal network penetration test for Nettitude consultants to escalate from a low privileged user to Domain Admin in a matter of hours (or even minutes). This is due to a handful of Active Directory and internal network misconfigurations which this article will explore.

Through the course of four scenarios, we’ll cover both longstanding and more recent attack primitives that center around relaying techniques in the hopes that network defenders can apply the mitigations contained therein.

Scenario 1 – LLMNR/NBT-NS Poisoning

Link Local Multicast Name Resolution (LLMNR) and NetBIOS Name Service (NBT-NS) are alternative resolution protocols used to derive a machine’s IP address given its hostname on the network.

LLMNR, which is based upon the DNS format, enables name resolution on link local scenarios and has been around since the dawn of Windows Vista. It is the spiritual successor to NBT-NS, which uses a system’s NetBIOS name to identity it on the network.

In general, name resolution (NR) protocols stand as the final fallback should suitable records not be found in local host files, DNS caches, or the configured DNS servers. One can think of the purpose of NR protocols as allowing a host to broadly query its neighbors over multicast: “Hey, does anyone have x resource, as I can’t find it anywhere else?”

These broadcasts are sent out to the entire intranet; however, no measures are taken to verify the integrity of the response of addresses and the address providers on the network, since Microsoft views the network as a trust boundary; as such, malicious actors can take advantage of essentially a race-condition and interpose themselves as an authoritative source for name resolution by replying to LLMNR (UDP 5355)/NBT-NS (UDP 137) requests with popular opensource offensive tooling such as Responder. Crucially, if the requested resource requires authentication, the victim’s username and NetNTLM hash are summarily sent to the adversary’s spoofed authoritative node.

Mistyping, misconfigurations (either on the DNS server or client side), WPAD, or even Google Chrome can easily lead to a scenario in which the client machine relies on multicast name resolution queries and gifts a malicious man-in-the-middle its coveted hash.

In this demonstration, the attacker sets up Responder listening on eth0 and with the -wF flags to start the WPAD rogue proxy server and force NTLM authentication on wpad.dat file retrieval:

Shortly thereafter, the victim (on client01 at 192.168.136.133) requests a shared resource via SMB with an unfortunate misspelling:

As demonstrated below, the attacker then responds to the name resolution query initiated by the victim via LLMNR, naming himself as the recipient and receiving the victim’s credentials in return:

From here, the user’s hash can either be cracked offline using a hash cracker like Hashcat or possibly relayed further in the environment to authenticate to other network resources via relay attacks, should mitigations such as SMB signing be disabled.

Mitigations:

1. Open the Group Policy Editor and navigate to Local Computer Policy > Computer Configuration > Administrative Templates > Network > DNS Client
2. Ensure that the option “Turn OFF Multicast Name Resolution” is enabled.
3. To disable NBT-NS on Windows clients:
4. Open your Network Connections and view the properties of the network adapter.
5. Select TCP//IPv4 and select “Properties.”
6. Select “Advanced” on the “General” tab and navigate to the WINS tab, then choose “Disable NetBIOS over TCP/IP.”

Scenario 2 – NetNTLM Relay over SMB

Continuing our exploitation of the potential consequences of LLMNR and NBT-NS broadcast traffic being present in the target environment, let’s turn our attention to relaying the NetNTLM hashes previously captured by Responder and see if more damage can be done.

Much like wine and cheese, Responder and Ntlmrelayx from the Impacket suite are the perennial pairing here. The idea is that an attacker can opt to relay captured NetNTLM hash to any systems on the network that have SMB signing turned off, which is the default setting on Windows clients.

After configuring Responder with its SMB and HTTP server deactivated (which can typically be done by editing /etc/responder/Responder.conf) and running the module via CLI as before (responder -I eth0 -wF), the attacker can then set up ntlmrelayx to listen for incoming connections with smb2 support enabled:

In this simulated scenario, an administrator on DC01 (192.168.136.132) mistypes a network share, which leads to a successful relay of the NetNTLM hash to client01 (192.168.136.133) and the dumping of the SAM, or the Security Account Manager, which is a database present on Windows machines that stores local user accounts and authentication information:

Do be advised that from MS08-068 and onwards, it is impossible to relay the same NetNTLM hash to the originating machine from which it was issued; as such, in order for this attacker to work, it is necessary to relay the hash originating from DC01 to client01.

Apart from dumping the computer’s SAM, which is disastrous in and of itself, an attacker could also elect to execute arbitrary commands on the target system or even spawn an SMB session on the host, which is what shall be demonstrated next. Upon successful relay of the administrator hash to client01, a malicious actor is presented with an interactive SMB client shell on 127.0.0.1:1000 after specifying the -i flag when deploying ntlmrelayx:

From here, the attacker has full access to the C$ drive and can amplify their foothold on the network by deploying a remote access trojan (RAT) or even proliferating ransomware through the network’s file system:

Mitigations:

1. The steadfast advice from Microsoft when it comes to any variant of the classic NTLM relay attack is to migrate from the natively vulnerable NTLM challenge-response authentication to the far more secure method of Kerberos authentication when possible. Kerberos has been Microsoft’s preferred replacement for NTLM since the inception of Windows 2000.
2. For those organizations that must use NTLM in their environments, it is recommended that EPA (Extended Protection for Authentication) and SMB signing are enabled, which in conjunction can vastly blunt the possibility of NTLM relay attacks.

Scenario 3 – IPv6 Carnage

Another common man-in-the-middle privilege escalation vector that poses risk an enterprise domain context stems from the abuse of IPv6, which is enabled by default on modern Windows operating systems and takes precedence over its predecessor IPv4 since the release of Vista. As such, systems internally poll the network for IPv6 leases, which plays into an attack vector still ripe with potential in 2022. For a step-by-step breakdown of how this all works:

1. An IPv6 client periodically sends out solicit packets on the local network, seeking an IPv6 router.
2. When an IPv6 router is present, it sends out an advertise packet in response to the solicit packet. This advertise packet informs the client that the IPv6 router is available for DHCP services.
3. The IPv6 client replies with a request packet to the DHCPv6 server, asking for an IPv6 configuration.
4. Finally, the DHCPv6 server issues the IPv6 configuration to the IPv6 client, which specifies several things, including the IP address, default gateway, DNS servers, etc. This is all included in the reply packet.

The idea with this attack, which utilizes Dirk-jan Mollema’s excellent research from 2018, is that a malicious actor can interpose their machine as an IPv6 router and force authentication to their server as the authoritative DNS server on the network over any other IPv4 servers. The attacker can then in tandem utilize ntlmrelayx to relay captured credentials to the specified target machine, leading to dumping of sensitive domain information or possibly even the addition of additional computer accounts or escalated privileges.

To set up this scenario, mitm6 is launched listening on eth0 and targeting the lab.local domain along with the machine client01:

Shortly thereafter, the preferred IPv6 DNS server is displayed from the perspective of the command prompt of our client01 victim as being the attacker’s machine, where 192.168.136.132 is the IPv4 address of the lab.local domain controller:

From here, ntlmrelayx is launched targeting the relay to the domain controller with the following command, with the -6 flag ensuring that our ntlmrelayx listens for both IPv4 and IPv6 connections and the -wh flag specifying a non-existent WPAD file host:

ntlmrelayx.py -6 -t ldap://192.168.136.132 wh netti-wpad.lab.local -l loot

After simulating the client machine rebooting and joining the network, it is observed that the attack successfully relays the client01 machine account against the DC:

This enables the attacker to gather and enumerate valuable information against the target domain environment, including group memberships, domain policies, and sensitive information disclosed in any AD object’s description fields, as demonstrated below:

It should be remarked that, while the scenario of the service account password being exposed in cleartext in the AD object’s description field is contrived for this example, it is unfortunately a practice that is still observed in modern-day engagements.

Now, while the aforementioned information dump about the targeted AD objects is certainly valuable, things can take a decisive turn for the worst should an attacker set up the ntlmrelay over LDAPS. Relaying to LDAP over TLS offers an opportunity for quick compromise of an entire domain, as creating new accounts is not possible over unencrypted connections. Specifying the --delegate-access flag on ntlmrelayx and waiting for the victim to request an IPv6 address or a WPAD configuration leads to the following series of events in the attacker’s console:

Once the victim requests a new IPv6 address or WPAD configuration from the mitm6 server (this is often seen when the victim reboots their machine or plugs in their network cable again), the ntlmrelayx server receives the connection and creates a new computer account over LDAPS, which is permitted by the default AD setting which dictates that any domain user can add up to 10 computer accounts:

From here, the malicious actor can utilize getST.py from the impacket suite to take advantage of a classic resource-based constrained delegation attack vector in order to have the new computer account request service tickets for itself on behalf of any other user in the domain, including the administrator. The typical flow of this attack finishes with requesting a TGS for the CIFS service of the target computer impersonating the domain administrator and dumping the SAM with impacket’s secretdump.py module, as previously demonstrated. In case the reader needs a refresher on the meaning of terms like TGS or a primer on Kerberos-based attacks, please consult this excellent resource as additional reading.

Should a user with functional permissions of domain admin log into one of the workstations in scope of the mitm6 attack, ntlmrelayx can be further weaponized to create a new enterprise administrator user; below, the domain administrator “henry” logs into the target machine, after which the authentication is relayed against the domain controller of the target environment:

Further in the output below, ntlmrelayx adds a new user with Replication-Get-Changes-All privileges:

At this point, it is game over for the domain’s integrity. An attacker can achieve complete domain compromise by dumping all domain user hashes from the Ntds.dit file, which is essentially the database at the heart of active directory:

Now that the wide-ranging ramifications of a simple IPv6 network configuration being left in its default state have been fully explored, let’s turn to discussing mitigating the factors that make this attack chain possible. Owing to the fact that there were several components abused along the way, there are several mitigation aspects to address.

Mitigations:

In summary, the mitm6 tool abuses the fact that Windows by default queries for an IPv6 address even in IPv4-only environments. If IPv6 is not internally in use, the surest way to prevent mitm6 attacks is to block DHCPv6 traffic and incoming router advertisements in Windows Firewall via Group Policy. However, entirely disabling IPv6 entirely may have unwanted side effects. As outlined in the linked article source below verbatim, setting the following predefined rules to Block instead of Allow prevents the attack from working:

• (Inbound) Core Networking – Dynamic Host Configuration Protocol for IPv6(DHCPV6-In)
• (Inbound) Core Networking – Router Advertisement (ICMPv6-In)
• (Outbound) Core Networking – Dynamic Host Configuration Protocol for IPv6(DHCPV6-Out)

Mitigating WPAD abuse:

If WPAD is not in use internally, disable it via Group Policy and by disabling the WinHttpAutoProxySvc service.

Mitigating relaying to LDAP:

Relaying to LDAP and LDAPS can only be mitigated by enabling both LDAP signing and LDAP channel binding.

Mitigating resource-based delegation abuse:

As RBCD is a part and parcel of intended Kerberos functionality, there is no one-click mitigation here. Most of the attack surface can however be reduced by adding administrative and key users to the Protected Users group or by marking the account as sensitive and ineligible for delegation.

Scenario 4 – Nothing but Certified Trouble

In the summer of 2021, SpecterOps researchers Will Schroeder and Lee Christensen published a deluge of information on the attack potential in inherently insecure Active Directory Certificate Services (hereafter ADCS, essentially Microsoft’s PKI implementation). While a full discussion of the eight attack mappings (ESC1 through ESC8) is outside of the scope of this blog post, it is worthwhile to explore ESC8 further as it stands as an excellent recent example of the continued potential for domain compromise that NTLM relay poses.

Essentially, this vulnerability arises from the fact that the web interface of the ADCS allows NTLM authentication by default and does not enforce relay mitigations by default. If the certificate authority in the domain does indeed have the web enrolment feature enabled (which is exposed typically via http://<CA_SERVER/certsrv/ upon the Certificate Authority Web Enrolment role being installed on the server), then the attacker can carry out an NTLM relay to the HTTP endpoint. Per the linked SpecterOps resource:

“This attack, like all NTLM relay attacks, requires a victim account to authenticate to an attacker-controlled machine. An attacker can coerce authentication by many means, but a simple technique is to coerce a machine account to authenticate to the attacker’s host using the MS-RPRN RpcRemoteFindFirstPrinterChangeNotification(Ex) methods using a tool like SpoolSample or Petitpotam. The attacker can then use NTLM relay to impersonate the machine account and request a client authentication certificate (e.g., the default Machine/Computer template) as the victim machine account. If the victim machine account can perform privileged actions such as domain replication (e.g., domain controllers or Exchange servers), the attacker could use this certificate to compromise the domain. Otherwise, the attacker could logon as the victim machine account and use S4U2Self as previously described to access the victim machine’s host OS.”

With the theory out of the way, let’s see this attack in action. First, from their initial foothold on the client01 machine as a low-privileged user, the attacker can utilize the living-off-the-land binaries, like certutil.exe, to enumerate certificate authorities in the domain:

From here, the attacker can set up ntlmrelayx to forward incoming forced authentications from DC01 to the HTTP endpoint for certificate enrolment; note that ExAdndroidDev’s fork of Impacket with support for ADCS exploitation was utilized for this demonstration:

As the final step in the attack chain, the PowerShell implementation of PetitPotam is leveraged in order to coerce an authentication from DC01 to our relay server:

At this point, the CA issues a certificate for the DC01$ computer account, which is captured by the ntlmrelayx server:

Now that the hard work is done, from here, with the base64 certificate of the domain controller computer account in hand, the attacker can use Rubeus to request a Kerberos TGT for the DC01$ computer account and can now perform a DCSync to request the NTLM hash of the krbtgt user to achieve complete domain compromise and persistence.

Mitigations:

1. Prior to releasing the offensive tooling for ADCS exploitation, SpecterOps released the PSPKIAudit auditing toolkit to enable defenders to proactively monitor their environments for potential ADCS misconfigurations. Please do recall that there are seven other scenarios for ADCS abuse which are outlined in the original SpecterOps whitepaper and not discussed in this blog post, so concerned blue team individuals are encouraged to read more here.
2. Alongside reviewing the aforementioned resources, it is highly recommended that defenders enumerate the Web Enrolment interfaces in their environment (either with or without PSPKIAudit) and either enforce HTTPS and enable EPA on the IIS server endpoints or remove the endpoints if possible altogether.
3. If not already doing so, defenders are encouraged to treat CA servers as tier 0 assets along with domain controllers from an asset management standpoint.

Conclusion

Owing to the fact that an attacker would need to have successfully leveraged another server-side vulnerability or a social-engineering attack to be in the position to relay credentials as a man-in-the-middle, hardening domain authentication and superfluous network broadcast traffic stands as an important component of Defence in Depth (DiD). While Microsoft may have worked to address the impact of some of these relay issues at different levels, it is nonetheless paramount that network administrators and defenders do their part to blunt the force of these vectors to potential domain takeover by following the mitigation advice on the subject. As there is no silver bullet to pre-emptively thwart every network attack primitive, the remedial guidance contained in this article can be followed as part of the multifaceted approach of DiD to secure the digital estate from domain compromise. Nettitude’s specialized internal infrastructure penetration testing services can also provide network stakeholders with world-class technical knowledge and tailored advice on remediating the issues explored here and beyond.

The post Network Relaying Abuse in a Windows Domain appeared first on Nettitude Labs.