Category: Microsoft

Configuring Microsoft Defender for Identity is not rocket science, but it can be complex in a large organization with multiple forests and domains. Understanding the risks when implementing Microsoft Defender for Identity is critical. Even though the documentation regarding a multi-forest environment exists, it can sometimes be clarified. This blog post will describe my view on the risks of implementing Microsoft Defender for Identity in a multi-forest environment.

Introduction

To prepare for Microsoft Defender for Identity, you need to think of a couple of things looking at identities. For example, you will need a Directory Service Account and a Manage Action Account. The Managed Action Account takes remediation actions like forcing users to change their password at the next logon and disabling a user account. The Directory Service Account authenticates to domains and forests to collect information that Microsoft Defender for Identity needs to get a complete picture of an attack.

Since release 2.193 of the sensor, the sensor has used the SYSTEM account of the domain controller to perform the remediation actions.

To enable lateral movement path detection in Microsoft Defender for Identity, the Directory Service Account must make remote calls to ALL computers in ALL forests using the Security Account Manager Remote (SAM-R) protocol to the Security Account Manager (SAM). Microsoft Defender for Identity needs these permissions to enable lateral movement paths, but the permissions can also be abused by an attacker once a Domain Controller is compromised.

Sensor vs. Updater

Before we look at the Manage Action Account, I want to clarify that Microsoft Defender for Identity uses two services.

• Name: Azure Advanced Threat Protection Sensor
• Service Name: AATPSensor
• Executable: Microsoft.Tri.Sensor.exe
• Log on: Local Service

• Name: Azure Advanced Threat Protection Sensor Updater
• Service Name: AATPSensorUpdater
• Executable: Microsoft.Tri.Sensor.Updater.exe
• Log on: Local System

The AATPSensor service is where most of the magic happens. The AATPSensorUpdater service does perform some tasks, but most of the functionality is part of the AATPSensor service.

Note: The reason that the AATPSensor is running as Local Service is because of security considerations. Since the sensor parses and handles packets, an attacker could fully compromise the domain controller with SYSTEM privileges if an attacker sends a successful malicious packet.

Local Service Account

Microsoft described the Local Service account as follows.

“The LocalService account is a predefined local account used by the service control manager. It has minimum privileges on the local computer and presents anonymous credentials on the network.”

The “minimum privileges” that Microsoft talks about are the following.

• SE_ASSIGNPRIMARYTOKEN_NAME (disabled)
• SE_AUDIT_NAME (disabled)
• SE_CHANGE_NOTIFY_NAME (enabled)
• SE_CREATE_GLOBAL_NAME (enabled)
• SE_IMPERSONATE_NAME (enabled)
• SE_INCREASE_QUOTA_NAME (disabled)
• SE_SHUTDOWN_NAME (disabled)
• SE_UNDOCK_NAME (disabled)
• Any privileges assigned to users and authenticated users

The permission which I find interesting is the SeImpersonatePrivilege permission. Because SeImpersonatePrivilege allows code to impersonate a different Windows user, it is a known way for an attacker to escalate their privileges. There are options to limit the permissions for the Local Service account, but that is not the case for the AATPSensor service.

I do not know if AATPSensor does work without these permissions, but compromising the service could still mean a complete compromise of the domain controller. However, for all I know, there is no known attack against any Microsoft Defender for Identity services yet

Manage Action Account

The Microsoft documentation states the following about the Manage Action Account.

“By default, the Microsoft Defender for Identity sensor installed on a domain controller will impersonate the LocalSystem account of the domain controller and perform the actions. However, you can change this default behavior by setting up a gMSA account and scope the permissions as you need.”

The documentation does not state that this only applies to the AATPSensorUpdater service. The reason that this only applies to the AATPSensorUpdater service is that this is the service responsible for the remediation actions.

So, what to choose for the Manage Action Account? Using the SYSTEM account sounds like the account has a lot of permissions in Active Directory, and you are right.

Since the SYSTEM account has Full Control over Active Directory, there is no need to use a separate account. And once an attacker gets hold of the SYSTEM account on a domain controller, it is game over anyway.

Another huge advantage over using the SYSTEM account and not a Group Managed Service Account is that no additional configuration is needed in Active Directory since the SYSTEM account has Full Control over all objects anyway. So, the best way to run AATPSensorUpdater is using the Local System account.

Since the sensor on the domain controller is responsible for the remediation actions, this also applies in a multi-forest environment. So, this is a no-brainer: use the default Local System account for the AATPSensorUpdater service. The Directory Service Account is a different story, though.

Note: If you already configured a Group Managed Service Account, remove the Group Managed Service Account permissions and use the SYSTEM account for the AATPSensorUpdater service.

Directory Service Account

The Directory Service Account is mainly for LDAP authentication. Since only authenticated users can query Active Directory, an account is needed. The AATPSensor service runs as Local Service and not as the computer object when using the Local System account, so an additional account is required. Remember, the reason that the AATPSensor is running as Local Service is because of security considerations.

Microsoft describes the types of Directory Service Accounts quite well.

Type of DSA	Pros	Cons
gMSA (Recommended)	– More secure deployment since Active Directory manages the creation and rotation of the account’s password like a computer account’s password. – You can control how often the account’s password is changed.	– Requires additional setup steps.
Regular user account	– Easy to create and start working with.  – Easy to configure read permissions between trusted forests.	– Less secure since it requires the creation and management of passwords.  – Can lead to downtime if the password expires and password isn’t updated (both at the user and DSA configuration).
Local service account	– Configured by default during install of sensors. Deploy sensors quickly and easily without the need to create and configure additional AD user accounts.	– SAM-R queries for potential lateral movement paths not supported.  – LDAP queries only within the domain the sensor is installed. Queries to other domains in the same forest or cross forest will fail.

For me, a “Regular user account” is no option. If you have any doubts, read my previous blog post. I also want to emphasize that using a “Regular user account” is a bad idea even in a test environment. Since a test environment is often less secure, this is a good stepping stone for attackers to hop to a production environment once the test environment is compromised.

Microsoft describes the following as cons when using the “Local service account.”

• SAM-R queries for potential lateral movement paths are not supported.
• LDAP queries only within the domain the sensor is installed. Queries to other domains in the same forest or cross-forest will fail.

Let us look at the LDAP queries first. The LocalService account provides minimum privileges on the local computer and presents anonymous credentials on the network. Since only authenticated users can access Active Directory using LDAP, another account is needed to authenticate to other domains or forests.

Note: If a sensor detects any activity cross-forest and wants more information about the entity, a different domain or forest is requested to provide the information. Since only authenticated users can perform LDAP queries, an Active Directory account is needed. Without the permissions, Microsoft Defender for Identity can not display all information in the alert.

So, if you want all the information a sensor wants for an alert, you must look at a Group Managed Service Account.

Group Managed Service Account

When using a Group Managed Service Account, additional configuration is needed. The recommended practice is to create a Group Managed Service Account for every domain and every forest and add ALL domain controllers of all domains to the group, which is allowed to retrieve the password for the Group Managed Service Account.

If multiple forests and domains have a transitive trust, all objects in the trusted domain can authenticate in the trustee domain. Since any authenticated user, including computer objects, can authenticate to other domains once there is trust, I do not see any issues using a Group Managed Service Account as a Directory Service Account. I am having some difficulties with the SAM-R permissions, though.

Security Account Manager Remote Protocol

The other con that Microsoft describes using the “Local service account” is not able to send SAM-R queries for potential lateral movement paths. For SAM-R queries to work, you must add the Directory Service Account to the policy “Network access – Restrict clients allowed to make remote calls to SAM.” Since this policy applies to ALL servers and ALL clients, the is a huge security risk.

The permissions set in the policy is “Allow,” but what exactly can the account do on ALL servers and ALL clients? We need to understand what the Security Account Manager is to find out. The Security Account Manager, or SAM, is a database file that stores users’ passwords. So, giving any account any permissions on this file sounds scary. When you can access the database remotely, it even gets scarier.

I wanted to see what the “Allow” permissions mean. Microsoft provided the Security Descriptor Definition Language (SDDL) in the policy, so it should be easy to figure this out using PowerShell.

The Security Descriptor Definition Language is hard to read, but with a single PowerShell command, it is much easier to read.

It says “AccessAllowed (ReadPermissions)” for administrators (which is by default) and the Directory Service Account. It still sounds scary if the SAM database contains passwords. First, the passwords are encrypted, but that still sounds scary. Second, the SAM database is accessed using a named pipe named SAMR exposed by the IPC$ SMB share. Looking at the documentation by Microsoft, a lot of information can be retrieved using the named pipe, but no encrypted passwords. Is this still not an issue, then?

Suppose an attacker compromises a single Domain Controller in any domain or forest. Using the SAM-R protocol, the attacker can get much information for ANY server or client in ALL domains and forests. Getting the information is a massive advantage for an attacker. I am also not convinced that getting the local users and group is the information you can get using the SAM-R protocol. The downside is that if you do not configure the remote calls for the SAM-R protocol, Microsoft Defender for Identity cannot determine any lateral movement. For example, Microsoft Defender for Identity needs to know if an attacker adds a user account to the local administrator group of any server or client.

So, what is worse? That is for you to decide.

Conclusion

Even though it sounds scary that the Manage Action Account runs using the SYSTEM privileges, it is ok to use these permissions as if an attacker compromises a Domain Controller; it is game over anyway.

Not enabling remote calls for the SAM database for the Group Managed Action account means you do not have access to the lateral movement paths, but I am still determining what is worse; not having the lateral movement paths or security risks for ALL domains and forests when a Domain Controller is compromised. So, would you enable remote calls for the Group Managed Service account on ALL servers and clients in ALL domains and forests?

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.

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.

Although Microsoft did not document this feature yet, it is possible to set a custom location for your log files for Microsoft Defender for Identity since sensor version 2.197. In this short blog post, I will describe how to set up a custom location for the Microsoft Defender for Identity log files.

Introduction

The Microsoft Defender for Identity logs provides insight into what each component of the Microsoft Defender for Identity sensor is doing at any given time. Recently you did not have the option to save the log files in a different location than the default.

Set Custom Location

Once you have installed version 2.197 of the Microsoft Defender for Identity sensor, you will see a new entry in the SensorConfiguration.json file containing a “SensorCustomLogLocation” option.

{
  "$type": "SensorMandatoryConfiguration",
  "SecretManagerConfigurationCertificateThumbprint": "",
  "SensorCustomLogLocation": null,
  "SensorProxyConfiguration": null,
  "WorkspaceApplicationSensorApiWebClientConfigurationServiceEndpoint": {
    "$type": "EndpointData",
    "Address": "thalpiussensorapi.atp.azure.com",
    "Port": 443
  }
}

Changing the SensorCustomLogLocation to any path you like and restarting the service is enough to set the custom location.

{
  "$type": "SensorMandatoryConfiguration",
  "SecretManagerConfigurationCertificateThumbprint": "",
  "SensorCustomLogLocation": "c:\\logs",
  "SensorProxyConfiguration": null,
  "WorkspaceApplicationSensorApiWebClientConfigurationServiceEndpoint": {
    "$type": "EndpointData",
    "Address": "thalpiussensorapi.atp.azure.com",
    "Port": 443
  }
}

You can also use the argument “logsPath” during the installation to set a custom location.

"Azure ATP Sensor Setup.exe" logspath="c:\logs"

You will end up with the log files in a custom location.

Conclusion

Although log files have a maximum of 50 MB and the oldest get deleted after ten consecutive files, there are circumstances when you do not want the log files in the default location. Maybe you already have something in place to send files to your SIEM solution, and you want a single folder to store all log files for your domain controller. Anyway, with version 2.197, you can ☺️

Microsoft Defender Vulnerability Management is a service that provides advanced vulnerability management capabilities. Microsoft Defender Vulnerability Management includes many features, including Asset Discovery and Inventory Windows Authenticated Scans, which can run scans on unmanaged Windows devices. Unfortunately, the authenticated scan comes with serious security risks. In this blog post, I will go through the security risks so you can identify the risks when performing an authenticated scan.

Introduction

During the private preview last year, I provided feedback to the program team for the Windows Authenticated Scans. The program team was very supportive, and I love the way they handled the feedback 🙏🏻

Microsoft did add a warning after providing feedback on how an attacker can use the scan to their advantage. However, there are still some risks that I want to warn you about when using an authenticated vulnerability scan.

Note: The scanner installation is straightforward and out-of-scope of this blog post. The scanner registers itself in the cloud, which you then use to create a new scan. When creating a new scan is where it gets interesting.

NTLM Authentication

You can select two authentication methods for the authenticated scan, Kerberos and Negotiate. When selecting Negotiate, you see a warning saying, “Negotiate option will fallback to NTLM in case Kerberos fails. Using NTLM is not recommended as it is not a secure protocol“.

It is insecure because if an attacker is in the same target range and you perform a scan, the attacker can sniff the NTLM challenge, replay the credentials, and authenticate as that user or brute-force the hash to get the plain-text password.

Important: To lower the risk, do not use a wide range of IP addresses to scan to mitigate the risk of an attacker sniffing the NTLM hash.

Azure Key Vault

When selecting a Windows authenticated scan, you can get credentials to perform the scan from an Azure Key Vault.

The scanner needs access to the Azure Key Vault to get the secret, and since you can not set permissions on a single secret, the scanner gets access to all secrets in the Key Vault. So, when an attacker compromises a device that has the Device Discovery scanner installed, the attacker can get the bearer token with access to the Azure Key Vault and read all secrets in the Key Vault.

To make it even worse, an attacker can dump the process and get plain-text credentials from memory.

Important: To lower the risk of compromised secrets, use a separate Key Vault for the Windows Authenticated Scan and do not add any other secrets.

Conclusion

The Windows Authenticates Scan is an excellent way to better identify devices within your network. Unfortunately, it does come with security risks. Although there are ways to lower the risk, which I mentioned in this blog post, please be careful when performing a Windows Authenticated Scan in your network.