Azure registered application abuse

Prev Next

Attack technique

Technique name: Azure Single-Tenant App Abuse

MITRE ATT&CK

  • Tactic: Initial Access, Persistence, Impact
  • Technique: Valid Accounts: Cloud Accounts, Additional Cloud Roles, Additional Cloud Credentials

Technique description
Adversaries may gain access to high-privileged accounts in Azure environments and register a new Single-Tenant application in Azure Entra ID (Formally Azure Active Directory). After registering the application, grant it extensive API permissions allowing a persistent foothold in Azure’s environment and execution of malicious activities on behalf of the application.

Permissive API permissions may allow adversaries to perform activities in Microsoft 365 services such as Read\Write\Send actions in all of the organization’s mailboxes, Read\Write actions in OneDrive files and Sharepoint sites, modify Entra resources like users, groups, domains, and other accounts.
Also, permissive API permissions may allow the malicious application to utilize and modify Azure cloud computing resources such as VMs, storage accounts, and more.

Registered applications, and specifically single-tenant applications, are traditionally less suspected and monitored by users and administrators, making them a perfect candidate for a persistent foothold in Azure for malicious activities.
Ultimately, single-tenant registered applications can have far-reaching consequences, as they can compromise critical data for individuals and organizations.

Insights from threat intelligence
Threat actors have been spotted in the wild utilizing high-privileged accounts to create single-tenant applications to create a malicious inbound connector in the email server and spread spam.

References

Threat hunting theses breakdown

Data theft and encryption

Relevant Data Sources:

  • Azure Sign-in Logs
  • Azure Audit Logs
  • Azure Activity Logs
  • Microsoft 365 Audit Logs

Thesis explanation

Detecting a suspicious application
When investigating an application, we must recognize 3 important identifiers of the application:

  • App ID - The ID of the application. This identification is unique to all Azure, and is consistent in all Azure subscriptions and accounts. Referred also as Application ID \ client ID \ App principal ID.
  • App Object ID - The ID of the application instance. This identification will be different in every tenant.
  • Service Principal ID - The ID of the registered application in Azure Entra. This identifier will be the one associated with the granted permissions of the application.

The thesis of detecting single-tenant malicious applications includes 3 main steps:

  1. Find the registration event of a new single-tenant application
  2. Find the application’s permissive service principal role assignments
  3. Find applications that their suspected assignment was made from a non-organizational IP address.

First, we will look for an event called “Add application” in Azure audit logs.
From this event, we will extract the App ID and the App Object ID along with other attributes such as the application name, creator, user-agent and more.
This event also indicates whether the application is available to other tenants (meaning - multi-tenant) or not (Single-tenant).

With these identifiers, and the App ID in particular, we will look for role assignment logs named “Add app role assignment to service principal”. The event includes the App ID, which we can ultimately correlate to the application registration event.
This event also includes the service principal ID of the application along with other supporting properties.

Finally, we will examine the granted permissions per registered application and look for the existence of any permissive role that was assigned to the application.
Here is a list of permissive roles that can be granted:

  • Mail.Read
  • Mail.ReadWrite
  • Files.Read.All
  • Files.ReadWrite
  • Domain.ReadWrite.All
  • User.ReadWrite.All
  • Directory.ReadWrite.All
  • Files.ReadWrite.All
  • Group.ReadWrite.All
  • User.Export.All

Blind spots

  • Due to the nature of the thesis, the suggested investigation flow does not cover Multi-tenant applications that performed malicious activities
  • The thesis heavily relies on organizational IP classification. Certain threats may originate from organizational IPs (Insider threats, tunneled sessions via organizational resources, etc) and they will not be found in the suggested thesis.
    To overcome this blind spot, we can take off the filtering made by organizational IP classifications.

Recommended investigation flow
To determine the maliciousness of an application, we will use the following data sources:

  • Azure Sign-in Logs
  • Azure Audit Logs
  • Azure Activity Logs
  • Microsoft 365 Audit Logs

Here are investigation steps that can be performed to help determine an application's maliciousness:

  • Check for unusual sign-in behaviors of the application's service principal, such as unusual locations, Failures, and frequency of sign-ins. It can be seen in Azure sign-in in Entra.
  • Check for the activities made during the suspected sessions. Are accessed resources by the application expected? Do they correspond to the application purpose? Such activities can be seen in Azure Activity Logs and Microsoft 365 Audit Logs.
  • Check for the type of granted permission (Application or Delegated).
    If it’s an application permission then find the admin who consents to the added permission (can immediately affect all users).
    If it is a delegated permission, then find the users that consent to the application, as they may be exposed to a compromise by the application

Hunting queries

The gist contains a threat-hunting query that allows finding single-tenant registered applications that are assigned with permissive roles from non-organizational IPs
https://gist.github.com/axon-git/956a1c773f4eccfeaceff5b122269b17