5 December 2024

Cloud attack techniques that compromise Sharepoint and M365 user accounts

If a threat actor gains a foothold on your cloud environment, they are likely to try and pivot to your on-premises environment. Vice versa, if an attacker gains a foothold on your on-premises environment, they will likely pivot to your cloud environment at some point in their attack chain.

Whether your cloud provider is AWS, Azure, or GCP, it is likely to be interconnected with your on-premises environment in such a way that some of the information, data and user accounts an attacker wants to target will lie in your cloud environment. 

(If you are interested more in this topic, also check out our recent blog post Cloudy with a chance of persistence.) 

In this blog, we will demonstrate an attack path from a recent red team engagement with a restaurant chain. We were able to pivot from the client’s on-premises environment and, by exploiting known security vulnerabilities and misconfigurations, we were able to compromise user accounts and become a SharePoint administrator able to access, modify and delete files on the client’s cloud storage network.

Systems, applications and processes targeted

Exploits achieved

  • Adobe ColdFusion
  • Azure Arc
  • Azure Connected Machine
  • Active Directory Certificate Authorities
  • Azure Active Directory Single Sign-On
  • Azure Service Principals
  • Domain Controller
  • Sharepoint
  • Microsoft 365
  • Pivot from client’s on-premises environment to their Azure cloud environment
  • Enumerate which machines and user’s cloud accounts and their permissions levels
  • Coerced Domain Controller and a Domain Admin account into authenticating an attacker’s machine
  • Able to impersonate user accounts on M365 services without gaining that user’s password or hashed credentials
  • Act as an Admin account on SharePoint, to access, modify and delete files on the client’s fileshare

(For the purpose of this blog, the usernames, servers and account details will be obscured in screenshots, and renamed in text using “Contoso” – the fictional company used by Microsoft.)

What are we attacking?

During a red team engagement, we were looking for a foothold in the client environment. The objective of the test is to access a flag that has been placed in a SharePoint folder containing the company’s most trusted secrets. But, because we are trying not to raise alarms on any of the client’s defensive tools, fuzzing and automatic tooling is not an option. Still, should be easy enough, right? 

We discovered a host that was running Adobe ColdFusion, which has a number of public exploits. 

We were unable to achieve code execution on the host with any of the public exploits. But we found the service to be vulnerable to a blind deserialization exploits, using a blind file read to look for the existence of a gadgets file. A blind file read would make the host would simply act as an oracle and respond with a HTTP response code 500 if a file existed and a response code of 200 if the file did not exist. 

First, we requested a directory that did not exist on the host.  

Next, we requested a directory that actually did exist on the host.  

We created a proof of concept using Burp suite and a wordlist of common Windows file paths to check the validity of this exploit, and to enumerate if the host was running windows. 

During the external component of the test, We tried to request an SMB share using the vulnerability, but outbound SMB was blocked by the xxxx network.

Using SMB Relay with Adobe ColdFusion

Once access to the internal network was obtained, we validated if a file read from an SMB share inside the network was possible. 

We set up an SMB relay to relay authentication from the Adobe ColdFusion host to other hosts inside the network with SMB signing disabled. 

We successfully relayed authentication, but the service was found to be running in the context of a machine account with seemingly no Administrator status. 

We used a SOCKS proxy to use the authentication with other tools such as SMBCLIENT to read and enumerate which shares this account had read access to.  

We located a number of sensitive files on one specific host machine. 

Two of the files On-boardingScript.ps1 and ESU_Unlink.ps1 contained hard-coded Azure service principals. 

Pivoting into the cloud: Part 1

From there, we were ready to pivot to the cloud. We did so by enumerating the available machines that were using the Azure Arc connected machine service and checking their permissions granted by service principal in order to perform a credential dump. 

We used the Azure CLI from Microsoft to validate and enumerate the permissions of the service principal. Essentially: what can they do and what can’t they do? Let’s find out. 

The service principal has a number of interesting permissions, such as being able to on-board new machines to Azure, and more interestingly to administrate on-boarded machines. 

It is worth noting, the only permission required for this service principal for its intended task was Azure Connected Machine On-boarding, but it had been misconfigured to grant excessive permissions. 

Azure Arc connected machine is a relatively new service to Azure, it allows for on-premises machines, or machines hosted by cloud providers, to be on-boarded into the Azure ecosystem, with a locally-installed agent. 

The connected machine service runs on the local machine in the context of NT / Authority System. 

We enumerated the available machines that were using the Azure Arc connected machine service.  Then we verified that it was possible to execute commands on the remote machines.  

Then we pivoted to another machine managed by Azure Arc and performed enumeration of the Domain Admins group. 

Path to Domain Admins

If we can coerce a domain account to authenticate to the attacker machine, we can relay the victim’s credential to the Certificate Authorities to obtain a certificate on behalf of that victim.  In this attack path, we’re going to show how we can do exactly that with user CONTOSOWEBPV01CONTOSO$. 

Attack Path 2: 

Using the previously discovered ColdFusion CVE, we relayed authentication from this host to the ADCS server (casrvpv01contoso. xxxx.com) to request a certificate on behalf of the user CONTOSOWEBPV01CONTOSO$.  

We then used the tool Certipy to authenticate using the certificate and requested a TGT ticket. This TGT was then used to get the NT hash for the user CONTOSOWEBPV01CONTOSO$.  

We then used Certipy with the user CONTOSOWEBPV01CONTOSO$ and the user’s hash to find vulnerable ADCS certificate templates. 

A certificate template was found to be vulnerable to ESC6, ESC8 and ESC11 attacks.  

We focused on the ESC8 vulnerability. Note that the ESC8 technique does not abuse certificate template misconfigurations. Instead, this technique leverages the configuration of the Certificate Authority (CA) server. Active Directory Certificate Authorities that are vulnerable to ESC8 meet the following conditions: 

  • Web Enrolment: Enabled 
  • Request Disposition: Issue 

Using the ESC8 attack technique we were able to coerce a domain account to authenticate the attacker’s machine (i.e., ours), and thus relayed the victim’s credential (user CONTOSOWEBPV01CONTOSO$) to the Certificate Authorities to obtain a certificate on behalf of that victim.  

But how can we coerce the Domain Controller?

Using the credentials for CONTOSOWEBPV01CONTOSO$, we found the Domain Controller was to be vulnerable to PetitPotam, allowing us to coerce the Domain Controller to into authenticating the attacker machine.  

We set up a relay with ntlmrelayx on the attacker machine with the target URL of the Certificate Authority and specified the SMB2 support, ADCS exploitation, and the template to use for certificate enrolment. Then we successfully created a certificate for the Domain Controller.  

Next we used this certificate to request a TGT and the NT hash for the computer account ADDCPV02CONTOSO$. 

The NTLM hash was recovered for account ADDCPV02CONTOSO$.  

Then we executed a credential extraction attack on the Domain Controller for the Domain Admin user !Jane.Doe. 

Thus we recovered the NTLM hash along with other credentials such as Kerberos keys. 

Pivoting into the cloud: Part 2 (Silver ticket attacks)

A Silver Ticket attack involves exploiting vulnerabilities in Kerberos – a network authentication protocol – to gain unauthorised access to services within the Azure environment. This type of attack focuses on Service Principal Names (SPNs) and the Ticket Granting Service (TGS) tickets used in Kerberos authentication.

How do Silver Ticket attacks work?

Service Principal Names (SPNs):

  • SPNs are unique identifiers for services in the network that Kerberos can authenticate.
  • Each service has an associated SPN and a corresponding account (often a service account) that handles authentication requests.

Extracting Hashes:

  • An attacker first needs to gain administrative access or compromise a service account that has an SPN registered.
  • They extract the NTLM hash of the service account's password. This can be done through various means, such as exploiting vulnerabilities, phishing, or using tools like Mimikatz.

Forging the Ticket:

  • Using the extracted NTLM hash, the attacker creates a forged TGS ticket (the Silver Ticket) for the service they want to access.
  • The forged ticket is crafted to appear as if it were legitimately issued by the Key Distribution Center (KDC).

Impersonating the Service:

  • The attacker uses the forged TGS ticket to authenticate to the targeted service.
  • Because the ticket is cryptographically valid, the service accepts it and grants the attacker access as if they were the legitimate service account.

How we performed the Silver Ticket attack

We decided to use the account AZUREADSSOACC$ for the purpose of this attack. The account AZUREADSSOACC$ is used by Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO). This feature automatically signs in users when they are on their corporate devices connected to the corporate network, without needing to type in their passwords. 

For example, let’s say you have a laptop and a company phone. Once you log in to Outlook on your laptop, when you choose to open up Outlook to log in on your phone, you will not need to enter your password every time. For businesses that provide users with multiple corporate devices, this provides greater convenience and user experience, but also opens up a potential attack vector. 

Because AZUREADSSOACC$ is a critical account for seamless authentication, it can be a target for Silver Ticket attacks. Here's how:

  • If an attacker compromises this account, they could extract the NTLM hash of its password.
  • With the hash, they can forge Kerberos TGS tickets (Silver Tickets) that impersonate the AZUREADSSOACC$ account.
  • This allows unauthorised access to resources and services within the Azure environment, bypassing normal authentication mechanisms.

Using the addcpv02Contoso$ we compromised previously we requested the credentials of the user AZUREADSSOACC$ using the tool impacket-secretsdump and the DC-SYNC technique. It is worth noting that no detections were made during any dumping using this method. 

This not only revealed the hashed credentials but also the cleartext credentials for the user ‘AZUREADSSOACC’ 

As a proof of concept for this Silver Ticket attack, we obtained the Security Identifier (SID) for the user landesk.  

We used this SID, along with the NTLM hash of the AZUREADSSOACC$, to request a Kerberos ticket. Then using this token we sent an email to ourselves via the Microsoft Outlook API.  

We received the email, which confirmed that we do not require the credentials of any user, provided that we use the NTLM hash for AZUREADSSOACC$ along with the user’s Security Identifier (SID). 

By performing Silver Ticket attack we proved that we could act on behalf of any user effectively impersonating them via email, without having that user’s password or hashed credentials.

From domain to the cloud

We used ROADrecon – part of the ROADtools suite – which is designed to enumerate information in Azure Active Directory. We used the credentials of user !Jane.Doe within ROADrecon to generate an authorisation token. 

After examining the results, we decided that creating a new account would risk detection from the client’s endpoint detection and response platforms. Therefore, we decided to select a recently deactivated user account from a cloud-only user so as not to risk detection. 

We examined the users listed by ROADrecon. They were perfect for a quick smash-and-grab attack. 

Using the credentials of the domain admin account !Jane.Doe, we successfully requested an Azure Active Directory token.  

Next, we activated the selected deactivated account John.Doe@Contoso.com

We assigned a new password to the account and set ForceChangePasswordNextLogin to False. 

We then assigned the user the role SharePoint Administrator.  

Note that new accounts are not required to have 2FA for 14 days. 

We then logged in to M365 using the newly minted account. 

We browsed to the Contoso Project folder.

We were not able to see the contents of this group due to not being a member, but as SharePoint administrator we could add any user to the group. We added the user John Doe as a member of the group. 

We were then able to access the file NSS.txt. This was the flag we had set out to find in the scope of the Red Team engagement. Though this was a flag designed for the purposes of an offensive security engagement, had we been a real attacker, as a SharePoint administrator, we would have been able to access, modify and delete files throughout the organisation’s SharePoint site. If any personally identifiable information, or sensitive data were stored on their SharePoint (and given how widely it was used across the enterprise, they likely were) an attacker would have been able to exfiltrate this data, resulting in a data breach. 

Don’t forget to test for stupid 

Turns out a member of the Domain Admins group also had the password Password2024@ 

What can we learn from this?

It is essential that you configure the access permissions and security controls which are built in to your cloud environment to prevent threat actors from escalating their privileges or compromising data which could result in a data breach. Moreover, given how many businesses rely on Microsoft services such as SharePoint and M365, simple misconfigurations can lead to significant compromises.

  • Always check for service principals on network shares or filesystems.
  • If you are on a machine hosted on Azure, or using Azure Arc service, always double-check for service principal and scripts as these are dropped on the file system by Azure at runtime.
  • When dumping credentials from the domain controller, always check for the machine account AZUREADSSOACC$ or MSOL_<12 random char>. If an attacker obtains the hash or password for either of these accounts, they will be able to achieve persistence in the cloud and pivot into the your Azure environment.

We pride ourselves on finding things that other teams miss. Our team of experienced penetration testers and offensive security consultants conduct their own research into cutting edge topics in the field of cybersecurity. Their discoveries inform, not only our training syllabuses, but all our offensive security engagements. Our value comes from combining real-world experience of how cyber attackers think and act with blue-sky-thinking and the latest research, to outsmart attackers before they can even begin.  

Contact us today to learn more about Claranet’s penetration testing services and Red Team exercises. We can also help you understand your cloud security and manage your cloud security.