This blog is the second post in a multipart series on how to get data from Defender for endpoint and analyze the patching data that is returned. Previously, we covered how to build a token, and request data from the Defender for endpoint API. This time we will cover how to create an azure app registration that allows the minimum required permissions to gather this data.
To refresh your memory on what data, and how we would acquire said data, give a read back over part one.
What is an Azure App Registration
An azure app registration, can be a rather exhaustive conversation. The core usage is to provide authentication to allow a user, or a service access to an azure tenant. Azure app registrations have changed over the years. This includes changes to the authentication library they use, and the granularity of permissions they allow.
Azure App Registration Requirements
To create an azure app registration in a tenant you need some special permissions. You need to not only be able to create the app registration, but you also need to be able to approve the usage of those permissions in your organization. To do this, you will need one of three different roles.
You can read more about quickly setting up any type of app registration here:
Creating an App Registration for Defender for Endpoint
Lets walk through the process to create an azure registration that we could use to complete the earlier released post. To register, you will first need to login at portal.azure.com and then navigate to app registrations.
Creating a registration
This will then launch the AAD registered apps portal, and launch the applications list blade. From here you can create a new registration, see existing registrations or troubleshoot issues. If you are not familiar with this section, this is also where you would see how your CMG connects to Azure, desktop analytics and more.
For this, we will simply select ‘New Registration’
Selecting this will open the window to start creating a new registration.
For our example, I have given the app a name ‘Defender For Endpoint API. Once you click register at the bottom of the screen you will then be presented with a small box in the top right once the app is created.
Permissions for the App
Once the application exists we are ready to start adding permissions to the application.
Before we add any permission we can go ahead and remove the User.Read permission as we will not need it. To do this click the three dots on the far right and select delete.
We can do so by using the add a permission button under the API permissions node.
This will then launch the request API permissions section.
From this section select the option ‘APIs my organization uses’
This will then let you search a lot of the build in API’s that are available in the portal. We want to search for Windows Defender ATP.
Then we will want to select Application Permissions to ensure that the PowerShell script only requires a token, and not a login. We could of course do a login, but this way we can use the token for automation purposes later.
We can then search for the three permissions we need
Once each of these permissions has been found, and checked, select add permissions at the bottom of the page.
Once completed it will look like this, and you will need to then grant admin consent.
Granting Admin Consent will pop up a box to confirm that you would like to grant these permissions.
At this time the permissions are set now we just need to create a key!
Creating a Key AKA a secret
First we will navigate to the certificates and secrets section.
Next we can create a new client secret, note for improved security usage of a certificate is also recommended for identity validation.
This will then open the Add a client secret window. Select a time frame for the secrets expiration. I would recommend no more than 12 months. And select Add.
This will then generate the client secret ID and the value for the secret.
IMPORTANT: Once you leave this screen the value is hidden and cannot be recovered, securely store this value.
That’s it the secret is now generated and now we can move on to testing!
A quick stroll back to part 1 to grab the script is all we need. We then plug in, the tenant ID, application ID, and the secret.