How to Backdoor Azure Applications and Abuse Service Principals

If an attacker gains access to an Azure tenant (with sufficient permissions) they can add a “secret” or a “certificate” to an application. This will allow an attacker single-factor access to Azure allowing the attacker to persist within the client environment. Further, each application that exists within an Azure tenant has a service principal automatically assigned/created. This happens every time an application is registered within an Azure portal. A service principal account is basically an identity that’s used by applications, tools to access resources / perform automated actions. 

 Attackers want to target service principals because:
  • Service accounts and service principals do not have MFA
  • Attackers can log into Azure using a service principal account
  • These accounts exist with all applications in Azure (most companies have several) 
  • These accounts cannot be controlled through conditional access

This blog post is going to show you how to create / register an application within an Azure portal; how to backdoor the application (aka add a “secret’) and lastly, how to detect this. I tried to make this blog post as simple as I possibly can :) 

This technique was one of the techniques that I covered in my AAD/M365 attack matrix here. I’m slowly going to go through each of these techniques and cover how they work / how to detect theme. 

Step 1: Malicious App Registration

If an attacker wants to backdoor an application – they need an application to target. This can either be an existing application within the portal, or the attacker can register a new application. The attack flow therefore has three parts:

  • Send a phishing email to register a malicious application through an unsuspecting user
  • Register an application within the Azure portal
  • Find an existing application within the Azure portal to target

In this example, I have registered a new application called CatsRCute. When you register an application, it automatically tells you (as you can see on this screen), an application ID, Object ID and a tenant ID. The Object ID string is a unique value for every single application object and service principal – it basically identifies this object in Azure. 




Step 2: Backdoor the application 

In every application, there are two methods you are presented with for authenticating the service principal – a “secret” or a “certificate”. An attacker can add a new secret or a certificate to allow them to log into Azure – basically acting as a “backdoor”.

As you can see from the screenshot below – I added a malicious client secret which I named “EvilSecret”. The default expiration as you can see is also approximately 2 years. When this secret is created it automatically gives you a “value” which has been redacted by Azure. This “value” serves as the “password” that is used to log in for this service principal.

Of course, you are not limited to adding a client secret, you can also go the route of adding a certificate.


Step 3: Log in with your malicious secret 

How you choose to login depends on how you want to login, but for the sake of this exercise, I opted to use Microsoft’s Azure CLI. As you can see from the screenshot excerpt from their documentation, it details exactly how to log in with a service principal. 




As you can see from the screenshot, to log in via the “EvilSecret”we added to my CatsRCute application, you need a few details:

  • The application ID (which is the username for the service principal). This is fetched from the overview page in the application. You can see this in the first screenshot.
  • The password – this is the redacted “Value” string which is present when we registered the client secret “EvilSecret”
  • The tenant associated with the application – this is also on the overview page of the application. It’s written down as “Directory (tenant) ID”.

Using the Azure CLI, this is what I did to “login”. 


Detection Methodology 

The forensically sound methodology to help detect something like this focuses on a few elements:

  • Review all application permissions that exist for all applications
  • Review all service principals with secrets / certificates 
  • Review all sign-in logs for logons from service principals, focusing on anomalies
  • Review audit logs for an action where a “secret” or “certificate” is added to an application 
  • Review all users that have the application-level roles assigned i.e. “Cloud Application Administrator” for the CatsRCute application (there can be more for each application)
  • Review the application owner i.e. in this case I created the application with my Global Admin account (bad Lina!) 

The reason you want to also look at application owners and all users with application-level roles assigned is that all of these users have control of the service principal. In this instance, as I am the owner of the application, and I have Global Admin permission – this impacts the severity of access an attacker would have in your tenant. This can basically allow an attacker to privilege escalate their way from a low privilege user to a Global Administrator.  

Within the Sign-In logs for service principals, you should see this event:



Review of the audit logs for the event “Update application – Certificates and secrets management” will show when a secret/certificate is added to an application:


It’s also very important to have an audit of the application owners and people who are within the app-level role groups that exist. For example, my application had the role of “Cloud application administrator”. Within this role, I had one user assigned called “banana”. There are usually more than 1 role and more users within each of these roles, but all of these users can potentially be a part of the attack path as they have control of a service principal with global administrator rights.  


This screenshot shows you who has the role of “Cloud application administrator” and this is my fake user “banana”. 



Comments

Popular posts from this blog

Office365 Attacks: Bypassing MFA, Achieving Persistence and More - Part I

Backdoor Office 365 and Active Directory - Golden SAML

Forensic Analysis of AnyDesk Logs