Microsoft Defender for Identity Sensor Identification

Someone asked if I knew how to identify if a domain controller holds a Microsoft Defender for Identity sensor, remotely. It was an interesting question, so I took up the challenge. In this blog post, I will explain how I identified the presence of a Microsoft Defender for Identity sensor on a domain controller.

Introduction

Microsoft Defender for Identity is relatively passive on a server. The sensor does not broadcast much or open anything, like ports, to identify the presence of a sensor. The sensor, e.a., does create two services, a self-signed certificate, and opens two UDP ports for Syslog and RADIUS, but nothing interesting, at least, that you can use to identify a sensor remotely.

Note: The sensor uses an OWIN HTTP listener, but it only listens on localhost, so you can not access it remotely, but more on that in a future blog post.

Named Pipes

The only thing I could find during my research was named pipes that might help identify a sensor. If we look at the named pipes on a domain controller, we see multiple named pipes with exciting names.

I am still determining what CPF stands for, but ATP stands for Advanced Threat Protection, and the digits are the process ID, where the last part is the Common Language Runtime version. So, by the look of it, this is how the named pipe gets its name.

\\.\pipe\CPFATP_PID_vCLRVERSION

Here you can see the process ID used in the name of the named pipe.

You can not connect to the named pipe anonymously, so I needed to find another way to identify if the names pipe exists.

You can connect to the named pipe as ‘BUILTIN\Administrators’ or ‘NT AUTHORITY\SYSTEM,’ but that means I am already on the domain controller, which probably kills the idea of identifying the sensor in the first place.

Since we can not connect to the named pipe unauthenticated, let us see what we get if we connect to it using a low-privileged user.

We get the error “Access to the path is denied,” but the interesting thing is that you get a different error message if you connect to a named pipe that does not exist.

Capturing the correct error message means that if we know the name of the named pipe, we can identify if Microsoft Defender for Identity is running. There is a catch, though: The named pipe contains the process ID, which we do not know.

Performing the identification as a low-privileges user is not an issue, but not knowing the name of the named pipe is. The only way I could come up with is brute-forcing it, as it is fast enough to determine the named pipe within minutes.

I developed the following PowerShell script to identify if a Microsoft Defender for Identity sensor is running on a server.

$IPAddress= "10.211.55.90"
$i = 1
$foundNamedPipe = 0
while ($i -le 12999) {
  try {
    $namePipe = "CPFATP_" + $i +"_v4.0.30319"
    $pipe = new-object System.IO.Pipes.NamedPipeClientStream $IPAddress, $namePipe ,"In"
    $i++
    $pipe.Connect(100)
  }
  catch {
    if ($_ -match "Access to the path is denied") {
      Write-Host "Found a named pipe using the name: $namePipe"
      $foundNamedPipe++
    }
  }
}
if ($foundNamedPipe -gt 1) {
  Write-Host "Found $foundNamedPipe named pipes and likely MDI is running on IP address: $IPAddress"
}
else {
  Write-Host "Found $foundNamedPipe named pipe(s) and likely MDI is NOT running on IP address: $IPAddress"
}

Note: Since Microsoft Defender for Identity always creates two named pipes, and I am unsure if any other service uses a named pipe with the same name, I decided to build in a check for at least two named pipes to identify Microsoft Defender for Identity.

Conclusion

You can identify if a Microsoft Defender for Identity sensor is running, but I am not too fond of the brute-forcing part. Even though the brute-force does not impact any service, it is the only method I have found.