Attack Detection Fundamentals 2021: Azure - Lab #2

By Masande Mtintsilana on 28 April, 2021

In the final part of F-Secure Consulting's Attack Detection Fundamentals workshop series for 2021, we covered a walkthrough of an end-to-end kill chain in Azure. 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.

Required Tools

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


Account Setup

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.

logic app setup

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.

Inkedhttp action config redacted

 Don't forget to click save!

Escalating Privileges

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

az login --service-principal --username <client_id> --password <client_secret> --tenant <tenantId>
az role assignment list --all --assignee <client_id>

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.

role assignment reader

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:

az logic workflow list --query '[].name'

list logic apps2

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.

az logic workflow list > workflows.json

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

logic app creds

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.

az login --service-principal --username <client_id> --password <client_secret> --tenant <tenantId>
az role assignment list --all --assignee <client_id>

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

Contributor role

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.

| where AppId == "<Client ID>"

Useful information provided in each login event includes:

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

sp auth logs

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.