On January 25, 2024, Microsoft announced Russia’s foreign intelligence service (i.e., Sluzhba vneshney razvedki Rossiyskoy Federatsii [SVR]) breached their corporate EntraID environment. We reviewed the information Microsoft’s team provided in their post which contained details significant enough to explain what likely resulted in the compromise of their environment. In this post, we’ll show you how to understand where similar Attack Paths may exist within your own Entra ID environments.

I highly recommend reading Andy Robbins’ blog, “Microsoft Breach — What Happened (and What Should Azure Admins Do)?”, or our recent video describing the breach here, to understand the full scope of what we know based on Microsoft’s transparency report.

I’ll provide an extremely abbreviated version below.

Based on the breach details Microsoft provided, a critical part of SVR’s Attack Path involved abusing a foreign app registration with elevated privileges in Microsoft’s corporate Entra ID tenant. They state, “The threat actor then used the legacy test OAuth application to grant them the Office 365 Exchange Online full_access_as_app role, which allows access to mailboxes.” This roughly looks like the following (Figure 1):

Based on what Microsoft has shared, we learned several things:

• To grant a principal the full_access_as_app role without hitting the human-consent process that may indicate a compromise in an Entra ID environment (assuming that the principal is not already highly privileged, such as a Global Administrator), a service principal must have the AppRoleAssignment.ReadWrite.All MS Graph app role assigned
• If a principal holds the AppRoleAssignment.ReadWrite.All app role, that principal may grant any principal (including itself) any app role against any resource app, including the RoleManagement.ReadWrite.Directory MS Graph app role
• With the RoleManagement.ReadWrite.Directory MS Graph app role, a principal may assign itself or any other principal to any Entra ID role, including Global Administrator

Based on this information, we know we need to look for two primary things in BloodHound:

1. Foreign principals (i.r., those coming from a tenant outside of your own) with escalation privileges which create paths to highly privileged roles
2. Foreign principals that already hold highly-privileged roles

With a full collection from AzureHound, BloodHound will show each of those two Attack Paths in any Entra ID tenant. To configure Azure collection in BloodHound Enterprise (BHE), you’ll deploy AzureHound Enterprise; for BloodHound CE, you can collect with AzureHound.

BloodHound will let users discover service principals that are associated with foreign app registrations; however, you first must know the ID of your own tenant. Run the following query and click on the tenant object that represents your Azure tenant:

MATCH (n:AZTenant)
RETURN n

Either the “Object ID” and “Tenant ID” fields will contain the value we need here (they are the same value on the tenant object). Throughout this blog, when queries are provided, you may paste this value in place of the “TENANT_ID” placeholder values (Figure 2):

Your critical assets (Tier Zero / High Value Assets) in BloodHound are automatically tagged to identify objects with full control of your Entra ID tenant. The first place to validate that no foreign objects maintain significant control of your environment is here. The following query will show any objects tagged into this asset group that do not belong to your tenant:

MATCH p=(sp)-[:AZHasRole|AZMemberOf*1..2]->(r:AZRole)
WHERE coalesce(sp.system_tags,"") CONTAINS "admin_tier_0"
AND NOT toUpper(sp.appownerorganizationid) = "TENANT_ID"
AND sp.appownerorganizationid CONTAINS "-"
RETURN p

Note that the App Owner Organization ID differs from the Tenant ID in each resultant object. This indicates that the object belongs to a tenant outside of your own (Figure 3).

Review each of these objects and validate that they are known and expected. As you do not maintain control of the foreign tenant, SpecterOps generally recommends removing any foreign principals from holding complete control over your tenant.

One of the primary features of BHE is the automated identification and measurement of Attack Paths within your environment. BHE customers can identify these Attack Paths under the following two findings within your BHE tenant:

• Non Tier Zero Principal Can Grant Tier Zero AzureAD Role
• Non Tier Zero Principal Can Grant Tier Zero App Roles (Figure 3)

Within each finding, confirm whether the Non-Tier Zero Service Principal is a foreign object. Follow the remediation instructions on the finding to remove the undesired privileges.

Whether you are a BHE customer or BloodHound CE user, these steps will work the same (however, BHE customers will have seen this information already in the “Attack Paths” view). Knowing your Tenant ID, construct a cypher query that finds any service principal with the most dangerous privileges.

MATCH p = (sp:AZServicePrincipal)-[]->(t:AZTenant)
WHERE t.objectid = "TENANT_ID"
AND NOT toUpper(sp.appownerorganizationid) = "TENANT_ID"
AND sp.appownerorganizationid CONTAINS "-"
RETURN p

The resulting data will show those principals with direct control of the tenant itself (Figure 4):

Review each service principal and validate whether the associated privilege is expected. The “App Owner Organization ID” will indicate the tenant from which the principal originates.

Beyond the most notable, direct controls involved in what we understand of the SVR Attack Path, we can make modifications to the queries to discover additional (and potentially very interesting) information about the relationship with the foreign tenant.

Within Entra ID environments, there may exist quite a few of these depending on your configuration.

MATCH p = (sp:AZServicePrincipal)-[:AZMemberOf]->(g:AZGroup)
WHERE g.tenantid = "TENANT_ID"
AND NOT toUpper(sp.appownerorganizationid) = "TENANT_ID"
AND sp.appownerorganizationid CONTAINS "-"
RETURN p

Review each to validate whether their presence is expected and whether the assigned group memberships are appropriate for the foreign service principal (Figure 5):

Entra ID admin roles grant significant control over a tenant environment, even if the role is not a default Tier Zero / High Value role.

MATCH p = (sp:AZServicePrincipal)-[:AZHasRole]->(r:AZRole)
WHERE r.tenantid = "TENANT_ID"
AND NOT toUpper(sp.appownerorganizationid) = "TENANT_ID"
AND sp.appownerorganizationid CONTAINS "-"
RETURN p

Review all role assignments within your tenant to validate whether the role assignments are expected and the foreign tenant is trusted to have this level of access to your own (Figure 6):

MS Graph app role assignments provide significant power within an Entra ID tenant, similar to an Admin role.

MATCH p = (sp1:AZServicePrincipal)-[r]->(sp2:AZServicePrincipal)
WHERE sp2.tenantid = "TENANT_ID"
AND NOT toUpper(sp1.appownerorganizationid) = "TENANT_ID"
AND sp1.appownerorganizationid CONTAINS "-"
AND TYPE(r) CONTAINS "_"
RETURN p

Review all app role assignments within your tenant to validate whether the role assignments are expected and the foreign tenant is trusted to have this level of access to your own (Figure 7):

The information Microsoft provided within their transparency report provides significant insight into the Attack Path SVR executed to compromise the corporate Microsoft Entra ID tenant. With this information, we can utilize BloodHound to identify similar Attack Paths within any other Entra ID tenant and gain broad visibility into the risks your organization holds from existing configurations.