Attack Detection Fundamentals 2021: Azure - Lab #2

Beginning with compromising a user account to retrieve service principal credentials, escalating privileges by further credential discovery, and finally moving laterally to a VM to access sensitive information.

A recording of the workshop can be found here, and the slides here.

In the previous lab, we used consent phishing as our initial access technique in order to compromise a victim's user account and discovered service principal credentials. In this lab, we will walkthrough discovering 'what' permissions are assigned to this account and leverage this to escalate our privileges.

• Deployment of the lab environment detailed in lab one
• Azure CLI
• Azure CLI "logic app" extension

Before we begin this lab, we will need to update information in our target resource - Logic App. Login to the Azure portal and search for the lab resource group "ad-lab-rg". Select the Logic App resource named "resource-tracker-<random value>-app" and then navigate to the Logic App designer in the left-hand blade.

By selecting the "HTTP" action, we will see its configuration details. Replace the following fields with those created during lab one.

• Tenant - Your tenant ID;
• Client ID - Contributor service principal client ID;
• Secret - Contributor service principal secret.

Don't forget to click save!

Using the previously discovered credentials from lab one, let's login into Azure and discover what credentials are assigned to us.

The second command lists all roles assigned to the service principal at all scopes in our subscription. An output similar to the below should be returned.

You will notice that you have Reader role permissions over the "ad-lab-rg" resource group. The Reader role can be considered to provide relatively benign permissions. However, several services can be configured to store sensitive information insecurely. In this lab we are interested in Logic Apps. Let's list all the Logic Apps we have access to using the following command:

We can see that a Logic App with the name "resource-tracker-bhsjipxqcj-app" exists. With the Reader role, we can get the Logic App workflows. For those not familiar with Logic Apps, they are composed of "actions" which perform a task. For example, performing an HTTP request is an action. Some actions require credentials and, if stored insecurely, will be readable to users with Reader role permissions.

With this in mind, we can get the workflow definition for all Logic Apps and store the contents in a file for manual review.

As can be seen in the following output, an HTTP action exists that stores credentials in clear text as HTTP Headers.

Great! Be retrieving these credentials and repeating the steps above, we can login to Azure as this newly-discovered account and list what permissions are assigned.

As can be seen below, the service principal has Contributor role permissions over the "ad-lab-rg" resource group.

This role is considered a highly-privileged role, as the only operations it is not permitted to perform are those related to access management.

An interesting fact about Azure Activity logs is that most "read" operations are not logged. Indeed, Microsoft states that only "write" operations (PUT, POST and DELETE) are logged. This does leave a blind spot for most of the actions we performed above. However, we can still take a look at authentication logs provided by Azure AD for detection opportunities.

Using our Log Analytics Workspace, we can query for all authentication attempts performed by our service principal.

Useful information provided in each login event includes:

• Time;
• App ID;
• Service Principal Name;
• IP Address;
• Location Details.

Considering how service principal are typically used, they often perform predictable actions from fixed locations. A detection use case that considers these facts is likely to be valuable.

In this lab, we used our previously-compromised credentials to gain access to our Azure lab and understand what permissions we have.

We learnt that with read-only permissions, we can still read Azure Logic App Workflow definitions and that they can contain sensitive information. Discovering additional credentials, we escalated our privileges to gain the Contributor role over the same resource group.

As the majority of our actions were "read" operations which are not logged by Azure Activity logs. As such we subsequently relied on the anomalous nature of our login event as a use case for detection.

In the final lab, we will look to be more stealthy as we access sensitive information in a virtual machine.