Microsoft Defender for Identity OWIN HTTP Listener

My previous blog post mentioned that the Microsoft Defender for Identity sensor uses an OWIN HTTP listener. In this blog post, I will describe what the HTTP listener is for and how to interact with it.

Introduction

During my previous research, I saw something listening on port 444. I wanted to discover what it was and what I could do with it. After some enumeration, it looked like an OWIN HTTP listener, but what is it for, and can I interact with the service?

First, we need to understand what OWIN is. OWIN stands for Open Web Interface for .NET and allows web applications to decouple from web servers. OWIN is a standard and not a framework like ASP.NET. Since ASP.NET strongly depends on Internet Information Services (IIS) and its capabilities, ASP.NET only runs on IIS. For ASP.NET to run, you need the .NET framework, which runs on Windows, and .ASP.NET applications are dependent on the .NET framework and tightly integrated with IIS.

To remove these dependencies, make it more modular, and build a loosely coupled system, the OWIN standard came alive.

Identifying OWIN HTTP Listener

When checking the active TCP connection and ports on which the server is listening, I found that port 444 is in use.

Note: The HTTP listener only listens to localhost.

Then I looked at which libraries the Microsoft Defender for Identity sensor uses. It was easy to determine that the sensor uses OWIN for the HTTP listener, especially when one of the libraries is called Microsoft.Owin.Host.HttpListener.dll.

The first thing I did was send a simple GET request to see if I could get a response. I got a certificate error at first, but by skipping the certificate check, I got the error 404.

Results

When reading more about OWIN, I found out that it could be that I was not using the correct endpoint, so I had to figure out the endpoint to talk to. To figure out the endpoint, I dumped the sensor’s processes and checked the strings in the dump to see if I could find anything interesting. I quickly stumbled upon the following URL.

Now that I know the endpoint, I wanted to see if I could interact with it.

The message is “Unauthorized,” which is interesting. If you look at the authentication OWIN supports, you see certificate-based authentication, and the sensor uses a self-signed certificate. So, I tried sending a GET request using the “Azure ATP Sensor” certificate, and I got the following message.

The requested source does not support the HTTP GET method. Fair enough. Let us try a POST request with an empty body, then.

I got an Internal Server Error, but that looks very promising. I seem authenticated, but the body I am sending needs to be corrected. Looking at the strings of the processes, I found the endpoint and some interesting JSON objects I could try.

I could not get it to work in PowerShell. Still, in my previous blog post, I needed to send the JSON object using compression to the API endpoint. So, I used my own Microsoft Defender for Identity API Fiddler to send the JSON object to localhost, and I got some results.

I found this interesting as it gives the handle to the Group Managed Service Account token to impersonate the Group Managed Service Account, but more on that in a future blog post!

JSON Object Examples

Here are some JSON objects you can send to the OWIN HTTP listener.

{
  "$type": "SnapshotPerformanceCounterMetricSamplesRequest"
}

{
  "$type": "RestrictMemoryRequest"
}

{
  "$type": "RestrictCpuRequest"
}

{
  "$type": "LdapSigningPolicyValueRequest"
}

{
  "$type": "SensorUpdaterRequest"
}

{
  "$type": "LdapAdfsContainerRequest",
  "objectGuid": ""
}

{
  "$type": "GetGroupManagedServiceAccountAccessTokenHandleRequest",
  "accountName": "",
  "domainDnsName": ""
}

Conclusion

I do not know why Microsoft wants to use an OWIN HTTP listener for the data it is providing, but they probably have a good reason. Looking at the data provided by the HTTP listener, I guess the sensor uses this information to see if it needs to limit the CPU and MEM, but I am not sure.