Author: thalpius

Microsoft Secure Score helps organizations get insights into security posture based on security-related measurements. Microsoft Defender for Identity leverages Secure Score with twenty-seven recommended actions. In a series of blog posts, I will go through all twenty-seven recommended actions and what they mean, a plan of approach, their impact, and my security recommendations, hopefully helping others. The eighth one in the series is the “Disable Print spooler service on domain controllers” recommended action.

Introduction

You have twenty-seven recommendations if you filter the Secure Score recommended actions for Microsoft Defender for Identity.

• Resolve unsecure domain configurations
• Resolve unsecure account attributes
• Remove dormant accounts from sensitive groups
• Protect and manage local admin passwords with Microsoft LAPS
• Configure VPN integration
• Reduce lateral movement path risk to sensitive entities
• Stop clear text credentials exposure
• Disable Print spooler service on domain controllers
• Stop weak cipher usage
• Remove unsecure SID history attributes from entities
• Modify unsecure Kerberos delegations to prevent impersonation
• Install Defender for Identity Sensor on all Domain Controllers
• Set a honeytoken account
• Start your Defender for Identity deployment, installing Sensors on DC’s and other eligible servers
• Accounts with non-default Primary Group ID
• Change Domain Controller computer account old password
• Reversible passwords found in GPOs
• Unsafe permissions on the DnsAdmins group
• GPO assigns unprivileged identities to local groups with elevated privileges
• Remove access rights on suspicious accounts with the Admin SDHolder permission
• Remove local admins on identity assets
• Remove non-admin accounts with DCSync permissions
• GPO can be modified by unprivileged accounts
• Built-in Active Directory Guest account is enabled
• Change password for krbtgt account
• Change password of built-in domain Administrator account
• Ensure that all privileged accounts have the configuration flag

Some recommended actions are easy to configure, but others require time, proper planning, auditing, and expertise. This blog post will review the recommended action of “Disable Print spooler service on domain controllers.”

Update: Microsoft keeps updating the recommended actions list. I will do my best to keep the list up-to-date.

Print Spooler

The print spooler is a service responsible for managing tasks sent to a server. The print spooler is a service that runs by default on almost all Windows operating systems, including Domain Controllers. The print spooler has a long history of vulnerabilities, including CVE-2021-1640, CVE-2021-1695, CVE-2021-34527, and many more.

A print spooler running on a Domain Controller is responsible for checking the availability of print queues on a published printer in Active Directory. Domain Controller deletes printers if their print queue is no longer available. The print spooler service contacts the print servers every eight hours, and if the print server is not responding, the print queue gets deleted from Active Directory. For this reason, disabling the print spooler on a Domain Controller is not that simple.

Arbitrary Code Execution

Arbitrary Code Execution is a malicious actor’s ability to run their malicious code on a target machine. You can imagine that if a malicious actor runs their code, it will be malicious and fully compromise the device. Arbitrary Code Execution is a security vulnerability where a malicious actor abuses the functionality of a vulnerability to run their malicious code. An example of the print spooler service is the “RpcAddPrinterDriverEx” function. RpcAddPrinterDriver installs a printer driver on the print server and links the configuration, data, and printer driver files.

The documentation describes the following “RpcAddPrinterDriverEx” structure.

DWORD RpcAddPrinterDriverEx(
   [in, string, unique] STRING_HANDLE pName,
   [in] DRIVER_CONTAINER* pDriverContainer,
   [in] DWORD dwFileCopyFlags
 );

The second parameter for the function is “DRIVER_CONTAINER“. If we look at the structure of “DRIVER_CONTAINER,” we see it accepts levels. Looking at “DRIVER_INFO_2,” we see an exciting parameter named “pDriverPath.” If we set the path to a path we own, we can add a malicious driver that runs under the context of the print spooler, which is SYSTEM. To make it even worse, “RpcAddPrinterDriverEx” is a function that can be accessed remotely using a Remote Procedure Call, making it Remote Code Execution. Before Microsoft patched this vulnerability, any authenticated user could add drivers to any device running the printer spooler service, including Domain Controllers.

The “RpcAddPrinterDriverEx” function is just one of many examples of malicious actors abusing the print spooler service to compromise an environment. Microsoft, therefore, advises turning off the print spooler service on any device where the print spooler is not needed, especially the Domain Controller.

Disable Print spooler service on domain controllers

When you disable the print spooler on a Domain Controller, pruning published printers in Active Directory must be done manually. If a published printer is at the end of its life cycle, an Administrator must delete the printer in Active Directory. Although manually removing objects in Active Directory can be tedious, the risks with the print spooler overshadow the manual removal of objects.

You can use the PowerShell command to check for any published printer in Active Directory.

Get-AdObject -Filter "ObjectCategory -eq 'printqueue'"

If there is no result from the command above, there is no published printer in Active Directory, and the print spooler on all Domain Controllers can safely be disabled. Otherwise, administrators must manually remove the printers from Active Directory when turning off the print spooler on Domain Controllers.

For the Microsoft Defender for Identity recommendation, I recommend using a Group Policy Object on the Domain Controllers to turn off the print spooler on all Domain Controllers Organization Unit.

The best-recommended action is to turn off the print spooler service on all servers that do not need the print spooler.

Conclusion

Due to the many vulnerabilities in the print spooler, which result in a complete domain take-over if the service runs on a Domain Controller, turning off the print spooler is the best mitigation. Sure, manually removing printers from Active Directory is tedious, but this does not outweigh the security risks that come with the print spooler.

Microsoft Secure Score helps organizations get insights into security posture based on security-related measurements. Microsoft Defender for Identity leverages Secure Score with twenty-seven recommended actions. In a series of blog posts, I will go through all twenty-seven recommended actions and what they mean, a plan of approach, their impact, and my security recommendations, hopefully helping others. The seventh one in the series is the “Stop clear text credentials exposure” recommended action.

Introduction

You have twenty-seven recommendations if you filter the Secure Score recommended actions for Microsoft Defender for Identity.

• Resolve unsecure domain configurations
• Resolve unsecure account attributes
• Remove dormant accounts from sensitive groups
• Protect and manage local admin passwords with Microsoft LAPS
• Configure VPN integration
• Reduce lateral movement path risk to sensitive entities
• Stop clear text credentials exposure
• Disable Print spooler service on domain controllers
• Stop weak cipher usage
• Remove unsecure SID history attributes from entities
• Modify unsecure Kerberos delegations to prevent impersonation
• Install Defender for Identity Sensor on all Domain Controllers
• Set a honeytoken account
• Start your Defender for Identity deployment, installing Sensors on DC’s and other eligible servers
• Accounts with non-default Primary Group ID
• Change Domain Controller computer account old password
• Reversible passwords found in GPOs
• Unsafe permissions on the DnsAdmins group
• GPO assigns unprivileged identities to local groups with elevated privileges
• Remove access rights on suspicious accounts with the Admin SDHolder permission
• Remove local admins on identity assets
• Remove non-admin accounts with DCSync permissions
• GPO can be modified by unprivileged accounts
• Built-in Active Directory Guest account is enabled
• Change password for krbtgt account
• Change password of built-in domain Administrator account
• Ensure that all privileged accounts have the configuration flag

Some recommended actions are easy to configure, but others require time, proper planning, auditing, and expertise. This blog post will review the recommended action of “Stop clear text credentials exposure.”

Update: Microsoft keeps updating the recommended actions list. I will do my best to keep the list up-to-date.

LDAP Bind Operation

To authenticate to Active Directory, clients use a Bind operation. There are several ways to authenticate to Active Directory, including a Simple Bind, which is the most common one. Using a simple Bind, a client authenticates either anonymously or by providing a Distinguished Name of the user and its corresponding password.

Unfortunately, simple authentication sends the password to authenticate in plain text over the network. With a man-in-the-middle attack, a malicious actor can read the password in plain text, which could lead to a disastrous result.

Here is an example of a simple authentication showing the plain-text password in Wireshark.

As you can see, the password sent to authenticate is in plain text.

Simple LDAP Bind Tool

I created a tool to perform a Simple LDAP Bind, which you can use to test the recommended action “Stop clear text credentials exposure” and the plain-text password using Wireshark.

Performing a Simple LDAP Bind results in “Exposed entities” in Microsoft Defender for Identity Recommended Actions “Stop clear text credentials exposure.“

Mitigation

The Microsoft Defender for Identity sensor detects clear text credentials by decoding the Bind request, looking for “Simple” authentication. Luckily, a Domain Controller audits unsigned LDAP binds, including a Simple Bind, using Event ID 2887 in the Directory Service log, which is on by default. Event ID 2887 reports every twenty-four hours; only reports performed unsigned LDAP Binds.

Unfortunately, it does not say which account and IP address performed the Bind. To see who performed an unsigned Bind, you must enable diagnostics on every Domain Controller using the following command.

New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics' -Name "16 LDAP Interface Events" -Value 2 -PropertyType DWORD -Force

Once enabled, Event ID 2889 in the Directory Service log shows who performed the Bind, including the IP address and account.

Once no unsigned LDAP Binds are shown for at least a month, you can enable LDAP signing, preventing Simple LDAP Binds and sending the password in plain text over the network.

Conclusion

The Microsoft Defender for Identity Recommended Action, “Stop clear text credentials exposure” is a perfect way to eliminate the plain-text password going over the network to lower the risk of a malicious actor getting a plain-text password. Using the events in the event viewer is also possible, but with Microsoft Defender for Identity, every clear text credential is in one place, which makes it a lot easier.

Microsoft Secure Score helps organizations get insights into security posture based on security-related measurements. Microsoft Defender for Identity leverages Secure Score with twenty-seven recommended actions. In a series of blog posts, I will go through all twenty-seven recommended actions of what it means, a plan of approach, their impact, and my security recommendations, hopefully helping others. The sixth one in the series is the “Reduce lateral movement path risks to sensitive entities” recommended action.

Introduction

You have twenty-seven recommendations if you filter the Secure Score recommended actions for Microsoft Defender for Identity.

• Resolve unsecure domain configurations
• Resolve unsecure account attributes
• Remove dormant accounts from sensitive groups
• Protect and manage local admin passwords with Microsoft LAPS
• Configure VPN integration
• Reduce lateral movement path risk to sensitive entities
• Stop clear text credentials exposure
• Disable Print spooler service on domain controllers
• Stop weak cipher usage
• Remove unsecure SID history attributes from entities
• Modify unsecure Kerberos delegations to prevent impersonation
• Install Defender for Identity Sensor on all Domain Controllers
• Set a honeytoken account
• Start your Defender for Identity deployment, installing Sensors on DC’s and other eligible servers
• Accounts with non-default Primary Group ID
• Change Domain Controller computer account old password
• Reversible passwords found in GPOs
• Unsafe permissions on the DnsAdmins group
• GPO assigns unprivileged identities to local groups with elevated privileges
• Remove access rights on suspicious accounts with the Admin SDHolder permission
• Remove local admins on identity assets
• Remove non-admin accounts with DCSync permissions
• GPO can be modified by unprivileged accounts
• Built-in Active Directory Guest account is enabled
• Change password for krbtgt account
• Change password of built-in domain Administrator account
• Ensure that all privileged accounts have the configuration flag

Some recommended actions are easy to configure, but others require time, proper planning, auditing, and expertise. This blog post will review the recommended action of “Reduce lateral movement path risk to sensitive entities.”

Update: Microsoft keeps updating the recommended actions list. I will do my best to keep the list up-to-date.

Lateral Movement Paths

Lateral movement is a technique malicious actors use to move sideways, searching for sensitive data or higher privileges. A good example is a user account having local administrator privileges on multiple devices. Once a malicious actor gets a foothold on one device and gets hold of the user’s password, the malicious actor moves sideways from one device to another using the same password until the malicious actors find what they are looking for.

A sensitive entity is a domain administrator, for example. Microsoft Defender for Identity identifies lateral movement paths to risky entities by accessing the SAM database on every device and checking which accounts are local administrators. Suppose Microsoft Defender for Identity detects an identity that is local admin on a device where a Domain Administrator is logged on. In that case, Microsoft Defender for Identity reports this as a lateral movement path to the sensitive entity.

Risks Enabling Lateral Movement Paths

To enable Lateral Movement Paths within Microsoft Defender for Identity, you need to configure Microsoft Defender for Identity to make remote calls to the SAM database. In my previous blog post, I described the risks of enabling remote calls to the SAM database. In another blog post, I described the risk once a single sensor is compromised, a malicious actor can read all local groups and users from the compromised sensor.

Conclusion

The main goal of this blog post is to identify the risks of configuring lateral Movement paths. Microsoft does not describe the risks of implementing a feature or service, and making the best design decision is crucial, hence my blog posts.

The fact that a malicious user “only” reads the local SAM database when a sensor is compromised or uses an NTLM relay attack does not overshadow the Microsoft Defender for Identity feature to detect lateral movement paths, in my opinion.

Microsoft Defender for Identity can identify Lateral Movement paths. Lateral Movement Paths allow malicious actors to hop from one device to another or from account to account. For Microsoft Defender for Identity to identify these Lateral Movement Paths, it needs to know which user is a local administrator on domain member servers. Microsoft Defender for Identity uses the Security Account Manager Remote (SAM-R) protocol to enumerate the users and groups on member servers. I discovered that it is possible to perform an NTLM-Relay attack and list any member server in the domain for its users and groups.

Introduction

Before I explain the NTLM-Relay attack, I want to explain what SAM-R is and why an NTLM-Relay attack works in the first place.

The Security Account Manager (SAM) database is a Windows file containing the local users and their passwords and is used to authenticate local users locally and remotely. The location of the SAM file is in the following folder: %SystemRoot%/system32/config/.

Microsoft created the SAM-R Remote Procedure Call (RPC) protocol, allowing administrators and users to manage users, groups, and computers. The SAM-R protocol is built on top of the Server Message Block (SMB) protocol. The SMB share IPC$ (Inter-Process Communication) is a share providing named pipes used for communication between a client and a server. By default, only administrators are allowed to access the SAM-R named pipe.

Lateral Movement Paths

For Microsoft Defender for Identity to identify Lateral Movement Paths, it uses the Directory Service Account to access the SAM-R named pipe on member servers and enumerate its users and groups. Since only administrators can access the named pipe, you need to configure a policy for the Directory Service Account to get remote access to the named pipe.

NTLM Relay Attack

Since the IPC$ SMB share provides the named pipe, authentication occurs over SMB. So, once Microsoft Defender for Identity enumerates a member server that a malicious actor compromises, the malicious actor asks Microsoft Defender for Identity to authenticate using NTLM and relays the authentication to another member server. Since all member servers are configured with the Directory Service Account to access the SAM-R named pipe, a malicious actor queries any server in the domain for its users and groups.

Here is an example of an NTLM relay attack querying another server for its local administrators.

Mitigation

Turning off NTLM authentication is the best solution, but enabling SMB signing also mitigates the risks of an NTLM relay attack. If you do not care about the lateral movement paths, you can always choose not to enable the lateral movement path in Microsoft Defender for Identity.

As you can see in the screenshot above, the authentication first takes place using Kerberos. I still wonder if performing a Kerberos relay attack and getting a valid Ticket Granting Ticket is possible, but that is for my next blog post.

Conclusion

For all I know, the policy to grant access for the Directory Service Account to access the SAM remotely only allows a malicious actor to enumerate its local users and groups on a member server. Although it is valuable information for a malicious actor, I would not worry too much about the NTLM-Relay attack. This blog post aims to identify the risks when configuring lateral movement paths in Microsoft Defender for Identity so you can make the best decision when configuring the product.

Microsoft Secure Score helps organizations get insights into security posture based on security-related measurements. Microsoft Defender for Identity leverages Secure Score with twenty-seven recommended actions. In a series of blog posts, I will go through all twenty-seven recommended actions of what it means, a plan of approach, their impact, and my security recommendations, hopefully helping others. The fifth one in the series is the “Configure VPN integration” recommended action.

Introduction

You have twenty-seven recommendations if you filter the Secure Score recommended actions for Microsoft Defender for Identity.

• Resolve unsecure domain configurations
• Resolve unsecure account attributes
• Remove dormant accounts from sensitive groups
• Protect and manage local admin passwords with Microsoft LAPS
• Configure VPN integration
• Reduce lateral movement path risk to sensitive entities
• Stop clear text credentials exposure
• Disable Print spooler service on domain controllers
• Stop weak cipher usage
• Remove unsecure SID history attributes from entities
• Modify unsecure Kerberos delegations to prevent impersonation
• Install Defender for Identity Sensor on all Domain Controllers
• Set a honeytoken account
• Start your Defender for Identity deployment, installing Sensors on DC’s and other eligible servers
• Accounts with non-default Primary Group ID
• Change Domain Controller computer account old password
• Reversible passwords found in GPOs
• Unsafe permissions on the DnsAdmins group
• GPO assigns unprivileged identities to local groups with elevated privileges
• Remove access rights on suspicious accounts with the Admin SDHolder permission
• Remove local admins on identity assets
• Remove non-admin accounts with DCSync permissions
• GPO can be modified by unprivileged accounts
• Built-in Active Directory Guest account is enabled
• Change password for krbtgt account
• Change password of built-in domain Administrator account
• Ensure that all privileged accounts have the configuration flag

Some recommended actions are easy to configure, but others require time, proper planning, auditing, and expertise. This blog post will review the recommended action of “Configure VPN integration.”

Update: Microsoft keeps updating the recommended actions list. I will do my best to keep the list up-to-date.

Configure VPN integration

The idea for this recommendation is simple: Microsoft Defender for Identity can integrate with a VPN solution by forwarding events to the Microsoft Defender for Identity sensors, including IP addresses and connection locations. With the integration with a VPN solution, you enrich the sensor with additional information it uses to get the source.

Here is an oversimplified example of an attack using a VPN.

If an attack happens over the internet through a VPN tunnel, the source of the attack is the VPN server. By integrating with your VPN solution, you provide additional information, such as the location of the attack and extra detections for abnormal VPN connections.

How to integrate your Microsoft VPN solution with Microsoft Defender for Identity is well documented, so I will not detail how to configure the integration. What I do want to talk about is the risks when integrating a VPN solution.

Risks

In my previous blog post, I identified a risk when installing the Microsoft Defender for Identity sensor in another environment. The risk when configuring a VPN integration is similar to the previous one.

The critical point of the risk is that you need to be careful when installing a Microsoft Defender for Identity sensor in another environment that is not secure. When a malicious actor compromises a single sensor in any environment, the malicious actor can get a lot of information from all sensors using the Microsoft Defender for Identity workspace, including the plain-text password for the VPN shared secret.

My previous blog post described how the Microsoft Defender for Identity sensor communicates with the cloud using an API. For the communication to work, you need a certificate for any sensor. Once you have the certificate, you can talk to the API and get sensitive information, including encrypted passwords. Once you have a certificate, you can decrypt the passwords, including the plain-text password for the VPN shared key.

I am discussing the shared secret you configure on the VPN server and the Microsoft Defender XDR portal.

To get the sensitive information, use my tool and send the following API request.

    "RadiusEventListenerConfiguration": {
      "$type": "RadiusEventListenerConfiguration",
      "ShouldMigrateOnDeserialized": true,
      "IsEnabled": true,
      "Port": 1813,
      "SharedSecretEncryptedData": {
        "$type": "EncryptedData",
        "EncryptedBytes": "nPHsSOxljDH<REDACTED>HCcV8ZzYWbxPia68mo6Dnx5ew1/C6w/Q==",
        "CertificateThumbprint": "2284725F3AC3278AA9EA5B6813455E186A3962CB",
        "SecretVersion": null
      },
      "IsRadiusAccountingRequestAuthenticatorValidationEnabled": true
    },

In the response, you will find the “RadiusEventListenerConfiguration” configuration. Part of the configuration is the “EncryptedBytes.”

You can decrypt the shared secret using my tool and the certificate and get the password in plain text.

Conclusion

Configuring VPN integration when using a VPN is a no-brainer. What I wanted to identify using this blog post is the risk that comes with it when configuring the VPN integration. Installing the Microsoft Defender for Identity sensor on all Domain Controllers, AD FS servers, and AD CS servers is a must, but be careful where you install the sensor in an environment that is not secure and can be compromised.