Backdoor Office 365 and Active Directory - Golden SAML

Backdoors can bypass all MFA requirements put in place by an organisation. Earlier this year, I worked an engagement with an APT group that had a keen interest on the client’s Office 365 environment, where this group found a way to bypass authentication controls to access the environment. Given that most clients either have a hybrid authentication model set-up or are fully in the cloud – I think it’s important that most blue teams / defenders / hunters are aware of the various techniques threat actors are using against Azure AD.

Compromise of the AD FS server token-signing certificate could result in access to the Azure/Office365 environment by the attacker. By default, this certificate is valid for a year and will allow an attacker to log into Azure/Office365 as any user within AD regardless of any password resets and MFA. The implication of this, is that the attacker maintains persistence and has a means to re-enter into the environment, escaping detection.

This blog post will cover the Golden SAML attack which is used by attackers to move from on-premise to Office 365/Azure. In a following blog post, I will break down the detection of malicious / backdoored applications in Azure AD as another backdoor mechanism. 


How the Attack Flow Works

In short, this attack was witnessed being utilised by APT groups – one notable example was during the SolarWinds attack. The attack works by an attacker hijacking, or gaining access to the AD FS server, extracting the secret (SAML token) and using this to access the Office365 Azure AD environment.


Keep in mind variations may occur with different attackers, but the principle is the same – that the attacker wants to hijack AD FS and gather the SAML token. The SAML token will grant the attacker access to:

  • Azure / Azure AD
  • Office 365
  • Azure Applications (which they can further backdoor)
  • Defender Security Center


Step 1: Attacker compromises the on-premise domain

In order for this attack to work, the attacker has already gotten access to credentials and is on a server / workstation within the domain. This can occur many different ways.

Step 2: Enumeration

During this step, the attacker will use enumeration tools to enumerate the AD FS server administrators and process owner usernames. This detail is critical as this "process owner" account has the permissions to "gather" the SAML token. The SAML token is a token that's used to authenticate users into the Office365/Azure environment. 

Step 3: Gather the credentials for AD FS process owner account

Once the AD FS process owner account is known, a credential dumping tool can be used to gather the NTLM hashed password of the account. This can be achieved through the use of Mimikatz or any other equivalent tool.



Step 4: Laterally move to AD FS server

With the harvested credentials of the AD FS process owner account, the next step is to log onto the AD FS server. This is typically done using pass-the-hash, but can be done using other techniques. This will vary between actors.

Step 5: Attain the token-signing certificate from the AD FS server

AD FS servers use SAML tokens to perform authentication of users. When users authenticate to Office 365, Microsoft validates the SAML tokens by verifying that the token isn't expired, that the token ImmutableID matches a user present in Azure AD and that the signature of the token is valid. 

The purpose of this attack is to attain the token-signing certificate and private key that AD FS uses to sign SAML tokens issued by AD FS for authentication. Once an attacker attains this, they can essentially log into, authenticate and access Azure AD and Office 365 as any AD user. This will allow authentication regardless if a user resets their AD password. To logon as any user, the attacker simply needs to access the ImmutableID of each user - which is a unique identifier associated with each user in Azure AD. This ImmutableID can be fetched and viewed by any user regardless of permissions, granted that the user is a part of Azure AD or on-premises AD. 

There are multiple different ways to fetch this certificate that have been utilised by threat actors listed below:



Step 6: Attain the DKM 

The token-signing certificate is encrypted by default and requires a "DKM" which is a Distributed Key Manager in order to decrypt. In order for an attacker to use this, they need to attain the DKM to decrypt the certificate. At this stage of the attack, it is not difficult for the attacker to gain access to the DKM. This can be done by using Powershell to query the DKM certificate container, and then passing these details over to a generic tool like Adfind.exe to extract the DKM. 

Step 7: Decrypt the token-signing certificate

There are multiple tools online that allow an attacker to decrypt the token-signing certificate with the DKM. 

Step 8: Generate a SAML token

Given that the attacker now has the key/certificate pair, they can produce a signed security token that can allow the attacker to log onto Office365 as a user. This can be done by passing the SAML token into Burpsuite as a POST request.


Detection Mechanisms


Remediations







Comments

Post a Comment

Popular posts from this blog

Forensic Analysis of AnyDesk Logs

Image
Most threat actors during ransomware incidents utilise some type of remote access tools - one of them being AnyDesk. This is a free remote access tool that threat actors download onto hosts to access them easily and also for bidirectional file transfer.  There are two locations for where AnyDesk logs are stored on the Windows file system: %programdata%\AnyDesk\ad_svc.trace %appdata%\Anydesk\ad.trace The AnyDesk logs can be found under the appdata located within each users' directory where the tool has been installed. Forensic analysis of these logs reveal interesting pieces of information inside the "ad.trace" log: Remote IP where the actor connected from File transfer activity Locating the Remote IP Connecting to AnyDesk Inside the "ad.trace" log you can grep for the following term "External address" and this should reveal the following line pasted below. I have redacted the IP for privacy's sake: info 2021-02-04 23:25:10.500       lsvc   9988 ...
Read more

How to Reverse Engineer and Patch an iOS Application for Beginners: Part I

Image
So you want to reverse and patch an iOS application? I got you >_< If you’ve missed the blogs in the series, check them out below ^_^ Part 1: How to Reverse Engineer and Patch an iOS Application for Beginners Part 2: Guide to Reversing and Exploiting iOS binaries: ARM64 ROP Chains Part 3: Heap Overflows on iOS ARM64: Heap Spraying, Use-After-Free  This blog is focused on reversing an iOS application I built for the purpose of showing beginners how to reverse and patch an iOS app. No fancy tools are required (IDA O.o), it's just you, me & a debugger <3 The app is a simple, unencrypted Objective-C application that just takes in a password and the goal of this is to bypass the password mechanism and get the success code. This blog post will focus on reversing/debugging the application and will not cover aspects of static analysis. The reason I wanted to write this is because I realised this topic is confusing for a lot of people and I wanted to try and write a blog t...
Read more

Successful 4624 Anonymous Logons to Windows Server from External IPs?

Image
If you see successful 4624 event logs that look a little something like this in your Event Viewer showing an ANONYMOUS LOGON, an external IP (usually from Russia, Asia, USA, Ukraine) with an authentication package of NTLM, NTLMSSP, don't be alarmed - this is not an indication of a successful logon+access of your system even though it's logged as a 4624. If your server has RDP or SMB open publicly to the internet you may see a suite of these logs on your server's event viewer. Although these are showing up as Event ID 4624 (which generally correlates to successful logon events), these are NOT successful access to the system without a correlating Event ID 4624 showing up with an Account Name \\domain\username and a type 10 logon code for RDP or a type 3 for SMB. You can double check this by looking at 4625 events for a failure, within a similar time range to the logon event for confirmation. The reason for this is because when a user initiates an RDP or SMB c...
Read more