Microsoft Defender for Identity JSON API

In my previous blog post, I described the inner workings of the Microsoft Defender for Identity REST API during the deployment of the sensor. In this blog post, I will explain the inner workings of the REST API when communicating with the cloud and how to interact with it using my updated Microsoft Defender for Identity API Fiddler tool.

Introduction

My previous blog post describes that you need the WorkSpaceID and AccessKey to interact with the REST API during the deployment. Microsoft Defender for Identity installation creates a self-signed certificate to communicate with the cloud after the deployment of the sensor. So, only during the sensor installation will you need the AccessKey. Thus, it is safe to regenerate a new AccessKey after the installation since the authentication with the REST API endpoint takes place using the self-signed certificate.

I identified three REST API endpoints during my research: sensorDeployment, protobuf, and json. In this blog post, I am referring to the following REST API endpoint:

• https://<WorkspaceName>sensorapi.atp.azure.com/api/json/v1.0

Authentication

After installing the sensor, if you look at the Local Machine Certificate Store, you will find a self-signed certificate with the name “Azure ATP Sensor”.

The authentication takes place by encrypting the payload sent to the REST API endpoint. In my previous blog post, you see a CreateSensorRequest REST API request which sends the self-signed certificate public key to the cloud. The cloud can then identify which sensor sends the encrypted payload by decrypting it using the public key of the self-signed certificate and identity which sensor sends the REST API request.

The private key of the self-signed certificate is not exportable. Well, not by default. So, to send any REST API requests, you either need to send the request from the Domain Controller or export the self-signed certificate using a tool like Mimikatz. Mimikatz exports certificates in the PKCS#12 format. The PKCS#12 format includes the private key you need to send a REST API request. Here are the commands to export the self-signed certificate using Mimikatz.

You can use the PFX file, extracted by Mimikatz, to send REST API requests using my Microsoft Defender for Identity API Fiddler tool.

API Requests

Here is an example of a REST API request.

{
  "$type": "DeleteSensorRequest"
}

As you can see, the request does not include the sensor’s name or any identification to identify which sensor sends the request. As I mentioned at the beginning of the blog post, the cloud uses the public keys to match which sensor sends the request to identify the sensor.

Here are some other REST API requests.

{
  "$type": "TestRequest"
}

{
  "$type": "GetSensorKnownDomainCredentialIdentifiersRequest"
}

{
  "$type": "GetAdfsServerDnsNamesRequest"
}

{
  "$type": "GetPendingRemediationActionsRequest"
}

{
  "$type": "GetSensorComputerIpAddressAssertionsRequest"
}

{
  "$type": "GetSensorKnownDomainCredentialIdentifiersRequest"
}

{
  "$type": "GetSensorTypesAndRunningComputerIdsRequest"
}

{
  "$type": "GetSensorWindowsEventLogReaderBookmarksRequest"
}

{
  "$type": "GetTaggedEntitySidsAndIdsRequest"
}

{
  "$type": "GetWorkspaceSyslogMessageDatasRequest"
}

{
  "$type": "GetSensorMinorDeploymentPackageSensorApiRequest",
  "Version": "2.193.15824.20477"
}

{
  "$type": "GetSensorSoftwareUpdateDataRequest",
  "Version": "2.193.15824.20477"
}

There are some exciting REST API requests, but more on that in a later blog post.

Microsoft Defender for Identity API Fiddler

I updated my tool so you can also send a request to the REST API endpoint. I also included the encryption and decryption of the passwords, which will be relevant in my next blog post.

For more information about how to use the tool, check this repository.

Conclusion

We can now also fiddle around with the REST API endpoint and see what response we get when sending these requests. Using my tool makes it easier to send the request. In the next blog post, I will show you how you can use an REST API request to get the encrypted passwords described in my previous blog posts and hop from one forest to another, even when there is no trust between the forests.