Introduction
Service principals help interweave the data, resources and identities in Azure and allow for its systems to hold presence in others. Administrators of Azure tenants use service principals to interact with the control and data planes and in some cases even unknowingly generate one when building a new resource.
These complexities make service principles a key focus for adversaries who actively hunt for and abuse their often over privileged roles to enumerate infrastructure and ultimately achieve actions on objectives. As a detection engineer it's critical you understand clearly how service principals exist relative to the rest of the azure environment and what adversary playbooks often document regarding them.
This article is of three parts, the first explores some basic behaviours that are worth exploring in every environment. The next article is about how to build a behavioural model for service principals that greatly matures your detection capabilities and moves away from static and unreliable indicators. A third and final article will conclude with implementation guidance and demonstrating testing against attacker simulations.
- Article 1: Azure Service Principals | Detection Engineering Intro
- Article 2: Azure Service Principals | Threat Detection Model
- Article 3: Azure Service Principals | Adversaries in the wild
Shape
Service principals as native components to Entra ID are subject to the generation of three different log types. Each log type can be utilised to gain insight into potential adversary behaviour and should not be ignored:
Azure Activity -
Subscription level events that capture what actions are being applied onto resources in any given Azure subscription. When an adversary wields a service principal to assign a new role on a resource or even delete it this is where the telemetry is collected. Later in the series we will explore a basic empirical model that captures how service principles typically present in this telemetry, in particular the diversity of resources interacted with, the scope of permissions normally applied and the targeted nature of adversary initiated resource operations.
Entra Audit -
Changes to identities and their properties such as group membership additions and the provisioning of new service principal credentials. Here adversary behaviour often manifests in the form of privilege escalation and the development of further persistence whether its through Entra temporary access passes or the establishment of more enterprise applications. Later in the series I will explore how to develop a behaviour model for rating the perceived criticality of a user's permissions and operational habits to sort those users into functional groups that a model can be fitted around.
ServicePrincipalSigninLogs -
Authentication telemetry for service principals. These telemetry events can be used to measure when one identity suddenly changes authentication contexts or where an azure service is compromised via valid credentials and tokens are stolen for use later in the kill chain. In a later chapter i will explore how to capture relevant dimensions to this log for behavioral analysis.
Adversaries
To begin, it would be most appropriate to cover a selection of basic detection use cases where the behaviour is highly likely to be malicious or at least anomalous for your environment.
Enumeration
Often adversaries seek to capitalise on over privileged service principles. This manifests in the telemetry with a few interesting dimensions.
List operation on resource with keys
A number of highly sensitive Azure resources contain keys within their configuration content. These keys can be captured by adversaries with appropriate permissions through the listkeys/action operation. Importantly, the necessary roles to perform these actions are often not intuitive thanks to the implied inheritance on a subscription and the broad scope of permissions that Microsoft assigns.
While adversaries seek to abuse this, it can often be easy to detect as many service principals do not experience a fluid or diverse set of operation types, so when one service principal interacts with a new resource a signal should be generated.
Read/Write/Action disparity
Thanks to the common programmatic nature of service principals we can establish anomalies through the monitoring of whether a resource is reading an unusual amount of resources. In many cases identities will read roughly the same number of resources that they perform write or action operations on. Deviations from these baseline are a strong signal.
Privilege escalation
Changes to the root of a subscription
Azure categorises its resources using management groups, subscriptions, and resource groups. When administrators wish to grant a role to a selection of resources they will typically do so on the closest categorisation. This makes subscription level changes as a good signal to augment later on.
Add self
Service principles are most commonly serviced themselves by human operators so identifying service principals being used to perform the following actions for themselves will allow you to easily generate signals that suggest an unusual privilege escalation.
Other applications being altered by a service principal
Setting owners
Creating new secrets
Adding new federation settings
Service principal granting itself graph permissions
Set elevate/access
This operation exists uniquely in the telemetry so I have used a distinct heading. The providers/Microsoft.Authorization/elevateAccess operation enables an identity with Global Administrator in Entra ID to gain control over resources in Azure. This violates the general idea of a casual boundary between the two spheres of infrastructure as such this operation should almost always be cause for investigation.
Crossing boundaries
While service principals are commonly used to interact with services like Azure Arc extensions and cross tenant settings these operations are highly impactful and particularly every adversary seeking to cause maximum impact will be looking for an attach path into on premise systems. Ensure that you detect the following behaviours:
Cross-tenant consent rules
Azure Arc virtual machine extension command invocation
Enhancing our approach
While many of the above described behaviours may be appropriate to surface directly to a human, others are not and will require augmentation with context as to the identity's position in the tenant and expected baseline of activity. Additionally it would be appropriate to divide each behaviour into even further dimensions where a service principal may be permitted to perform highly sensitive operations, but when acquired by an adversary, just a single parameter may change.
Building a theoretical model to implement into your detection stack is a robust method to tackling these problems and producing higher fidelity alerts. The next chapter of this series will explore how to do exactly that..
Continue in Chapter 2: Building a model
