The right solution to the right problem: Microsoft Service accounts

Introduction

In this article, I will discuss the use of managed service accounts, including their implementation, characteristics, and benefits. The goal is to prevent attacks such as Kerberoasting. Furthermore, I will provide a method to monitor and identify Kerberoasting attacks using Windows EventViewer.

My intention is to highlight the benefits of managed service accounts in Active Directory by applying good practices. These practices are documented on the Microsoft website but are often neglected by system administrators for various reasons. Implementing these settings is crucial as they help reduce the exposure of the environment to attacks.

It is widely known that long-running processes in the Windows Operating System, including services, rely on supporters. Therefore, when running applications on the Operating System, a service must be installed, and a user must be defined for its execution. Unlike regular processes, services often run for extended periods and can be susceptible to persistent threats and privilege escalation (which will be further explained in the Attack section).

The Problem

Given the increasing demands of new applications and systems, companies often face urgent needs. However, this is where problems arise. Instead of creating a service account for each service, which is the proper approach, sysadmins often opt for a quick fix: creating common domain users in Active Directory to manage the services.

Unfortunately, this quick solution is prevalent in the technology market, leading to several security issues. For instance, it involves using the user's descriptive field to document information about the associated services, password management, and policies (such as character requirements, storage location, and frequency of changes), among others.

As a result, several questions arise: How can the correct use of service accounts improve the security of my environment? What steps should I take to enhance it? What types of attacks is my environment susceptible to? And most importantly, how can I protect it?

In this post, I will share the necessary information to address these questions, focusing on a common attack that exploits this vulnerability: Kerberoasting.

The attack

There are several attacks that exploit the described problem, including Kerberoasting, ASREProasting, Silver Tickets, and Golden Ticket attacks. These attacks, classified under the Mitre T1558 technique, are particularly concerning because they allow attackers to extract credentials from Active Directory accounts used in services. These compromised credentials can then be used for lateral movement and persistent access. Detecting these attacks is challenging since they leverage the standard operation of the Kerberos protocol. Therefore, specific monitoring approaches are necessary to differentiate malicious users from normal users.

These attacks are successful primarily because the majority of credential accounts adhere to the minimum password length defined by the company's password policy, often around 8 or 10 characters. Additionally, these accounts frequently have non-expiring passwords, enabling brute-force attacks to succeed within a reasonable timeframe. Compromised passwords can be used for extended periods.

Furthermore, many of these accounts possess excessive permissions and are often members of critical groups such as "Enterprise Admins," "Domain Admins," or "Administrators Built-in," among others. This grants the attacker administrative privileges within the Active Directory environment.

The solution

The solution to this problem was developed by Microsoft itself starting from Windows Server 2012, introducing the concept of Managed Service Accounts (MSAs). MSAs allow the operating system to autonomously manage service accounts through the Key Distribution Center (KDC), eliminating the need to worry about password length, storage location, or password rotation frequency.

With this approach, a service account is now available that offers easy management and helps improve the overall maturity of the environment. It provides a unified identity solution for services.

Some of the benefits of using a managed service account include:

• The password is changed every 30 days.
• The password has a high level of length and complexity.
• No one has access to the account password.
• There is no interactive login capability.
• Only authorized hosts will be able to utilize the account to run services and tasks.

The implementation process

Below, we will detail the process of applying Microsoft's recommended configurations in a test environment to assist the readers of this post in replicating the steps in their respective environments (it is recommended to test in a staging environment first).

Fictitious scenario:

• HOSTNAME: adds
• domain: purple.local
• service: Openfire
• Organizational Unit: servicesgroups

OBS.: There are well-defined naming practices by Microsoft for groups, OUs, etc. However, organizations can adopt various other strategies according to their specific needs, such as using pseudonyms to conceal actual service and group names.

Configure Key Distribution Services (KDS)

The implementation process starts with the creation of the KDS root key for the Key Distribution Services (Service Translation Key), which is responsible for automatic password generation and management.

There are two methods to view KDS Keys: one is through PowerShell, and the other is through Active Directory Sites and Services.

To check if a KDS key exists in the forest using PowerShell in administrative mode, you can use the following command:

Get-KdsRootKey

The image below shows the command output indicating that no key was returned.

The second method involves accessing the Master Root Keys container in Active Directory Sites and Services (ADDS), as demonstrated below.

Upon verifying that the key does not exist, we will proceed to create it. It is important to emphasize that generating and replicating the key may take up to 10 hours to complete.

To follow the process of creating the KDS root key, you need to use the following command in PowerShell (in privileged mode):

Add-KdsRootKey -EffectiveImmediately

After executing the command, you can verify through both PowerShell and ADSS that the key has been successfully created.

Creating service accounts

To continue the process of creating the service account, we will initiate the creation by executing the following command:

New-ADServiceAccount -Name openfire -DNSHostName adds.purple.local -PrincipalsAllowedToRetrieveManagedPassword adds$

For better command comprehension:

• Name: Specifies the account name.
• DNSHostName: Specifies the server name with the Fully Qualified Domain Name (FQDN).
• PrincipalsAllowedToRetrieveManagedPassword: Defines the msDS-GroupMSAMembership attribute of a service account object. In this case, it specifies the host that has permissions to use the account.

NOTE: If there are multiple hosts, you can create a security group and add all the hosts to this group. Then, substitute the "adds$" field with the name of the security group.

There are two ways to validate if the account was created: through the Master Root Keys container or using PowerShell with the following command:

Get-ADServiceAccount - Filter *

The image below shows the Master Root Key container with the "openfire" account, as well as the PowerShell output confirming its existence.

For demonstration purposes, the new service account will be added to the 'Domain User' group.

The HOST adds was connected to the service account, and to validate this connection, wait for the return of 'True'. Let's use the following command to search for the name of the created account:

Test-ADServiceAccount openfire

Listing the service

We previously installed an instant messaging server (openfire) on the HOST, which uses domain accounts in its integration.

There are two ways to validate the service status on Windows. We can check if the service is installed using the 'Get-Service' command:

get-service | where-object { $_.Name -eq "openfire" }

The second way involves using the MS-SCMR method. It allows us to view the RPC service through 'services.msc'.

So far, we have successfully created our managed service account, and now we need to link the created account 'OpenFire' to the corresponding service ('Openfire Service'). To do this, follow these steps:

1. Open the properties of the service.
2. Select the 'This Account' option.
3. Remove the password that the 'Local System' account was using.
4. Click on 'Browse' to locate the created account, namely 'openfire'.
5. Once you have selected the 'openfire' account, click 'Apply'.
6. The password field will be automatically filled, and the service account name will have a '$' at the end.

Please refer to the accompanying image for a visual representation of this step.

Monitoring and Detection

Before we continue, it's important to note that Microsoft recommends the use of Microsoft Defender for Identity - UEBA (User and Entity Behavior Analytics). This security solution utilizes behavioral analysis to detect internal and external threats, providing protection against targeted attacks. Defender for Identity monitors and analyzes Kerberos protocol traffic to identify anomalies and suspicious activities, such as attempts to access services using a TGS.

In this article, we will focus on monitoring the Kerberos protocol using the Windows EventViewer and customizing EventIDs. This approach can be utilized to feed a SIEM (Security Information and Event Management) system, aiding in reducing false positives.

EventViewer

The Event Viewer is a component of Microsoft's Windows NT operating system that allows administrators and users to view event logs on local or remote machines.

To ensure the security of user authentication and access systems in a network environment, it is crucial to enable the Audit Kerberos Authentication Service and Audit Kerberos Service Ticket Operations subcategories, which are available in Group Policy Management. These subcategories help identify events in the user account database on a domain controller.

Creating Custom Views using XML filtering is a powerful way to search event logs and display only the relevant information. These Custom Views can be used to monitor specific Kerberos protocol activities, such as Kerberoasting, by filtering Event Level, Event IDs, and EventData. Such measures aid in detecting possible attacks and malicious behavior in user authentication systems.

As mentioned earlier, certain elements are required for auditing the Kerberos protocol. The Audit Kerberos Authentication Service and Audit Kerberos Service Ticket Operations subcategories, which are part of the Accounts Logon policies in Group Policy Management, help identify events in the user account database on a domain controller. Enabling these subcategories is crucial for comprehensive monitoring.

Audit Kerberos Authentication Service is the subcategory responsible for determining whether audit events should be generated for TGT (Ticket Granting Ticket) authentication requests. If this policy is configured, an audit event will be generated after a TGT authentication request. In KDC (Key Distribution Center) environments, a high volume of events is generated.

Audit Kerberos Authentication Service

The primary event generated by this subcategory is EventID 4768 — 'A TGT authentication ticket was requested.' This event is generated whenever the KDC issues a TGT ticket. In other words, every time a user attempts to authenticate in the system, an access pass is generated. This event is only generated on domain controllers.

By utilizing the advanced auditing policies of Group Policy Management, the logs related to the Audit Kerberos Authentication Service are enabled, and the events can be viewed in the Windows Event Viewer. The following figure illustrates the necessary configuration to enable this element.

Audit Kerberos Service Ticket Operations

The Audit Kerberos Service Ticket Operations is a subcategory in Group Policy Management responsible for determining whether security audit events should be generated for TGS (Ticket Granting Service) service ticket requests. These events are generated whenever Kerberos is used to authenticate a user who wants to access a protected network resource. They can be used to track user activity.

The primary event generated by this subcategory is EventID 4769 - 'A ticket from TGT authentication was requested.' This event is generated whenever the KDC issues a TGT (Ticket Granting Ticket). In other words, every time a user attempts to authenticate in the system, an access pass is generated. This event is only generated on domain controllers.

Another important event generated by this subcategory is EventID 4771 - 'Failed Kerberos pre-authentication' or 'failed authentication process Kerberos.' When there is a failure in the authentication process, Windows will record event 4771. Therefore, whenever a user enters the wrong password, this event will occur.

By utilizing the advanced audit policies of Group Policy Management, the logs related to the Audit Kerberos Service Ticket Operations can be enabled, and the events will be displayed in the Windows Event Viewer.

Custom Views

Custom views using XML filtering are a powerful way to search event logs and display only the information you need. To create a custom view based on the username, follow these steps:

1. Open Event Viewer.
2. Navigate to Custom Views.
3. Right-click on Custom Views and choose 'Create Custom View.'
4. Configure the filter settings in the 'Create Custom View' dialog window based on the username or other criteria you want to use for filtering events.
5. Click 'OK' to create the custom view.

By following these steps, you can create a custom view in the Event Viewer that will filter events based on your specified criteria, helping you to focus on the relevant information you need.

The following elements are part of the XML syntax for creating custom views:

• Event Level: Levels are essentially ratings of event severity. You can narrow your search by specifying a single level, or broaden your search by selecting multiple levels (critical, warning, debug, information, and error).
• Event IDs: Windows uses EventIDs to identify events. You can filter the desired events by specifying the EventIDs and using comparison operators.
• EventData: This element allows you to filter events based on specific data contained in the event, such as 'Account Name,' 'Status,' or 'Source Port.' You can use these data elements to refine your custom views and focus on the relevant information.

Custom View Kerberoasting

Based on the analysis of the attacks and the behavior of logs, we have created the following custom views to effectively monitor the activities of the Kerberos protocol related to kerberoasting in the event logs:

1. Kerberoasting Successful Attempts: This custom view filters events with EventID 4769 (TGT authentication ticket requested) and EventID 4768 (TGT authentication ticket issued). These events indicate successful attempts at requesting and issuing TGT tickets, which are commonly exploited in kerberoasting attacks. By monitoring this custom view, we can identify potential instances of kerberoasting.
2. Kerberoasting Failed Attempts: This custom view filters events with EventID 4771 (failed Kerberos pre-authentication) and EventID 4776 (Kerberos authentication service failed). These events indicate failed attempts at pre-authentication or authentication during the kerberoasting process. Monitoring this custom view helps us detect and investigate any failed kerberoasting attempts.
3. Kerberoasting Account Usage: This custom view filters events that involve specific user accounts associated with kerberoasting vulnerabilities. We can specify the relevant user accounts by filtering the 'Account Name' field in the EventData. By monitoring this custom view, we can track the usage of these accounts and identify any suspicious activity.

These custom views provide targeted monitoring of the Kerberos protocol events related to kerberoasting, enabling us to promptly detect and respond to potential threats. By regularly reviewing these custom views in the Event Viewer, we can stay vigilant and take necessary actions to mitigate the risks associated with kerberoasting attacks.

In the creation of the custom view for kerberoasting monitoring, the following criteria were chosen to enhance the detailing and analysis of the logs:

• Event Level: Levels 0–5 were selected to provide a comprehensive view of the severity of events related to kerberoasting. By including a wider range of event levels (critical, warning, debug, information, and error), we ensure that no relevant events are missed during analysis.
• Event IDs: Specifically, EventID 4768 and EventID 4769 were chosen when creating the custom view. These event IDs correspond to TGT (Ticket Granting Ticket) authentication ticket requests and issuances. By focusing on these specific events, we can closely monitor the TGT-related activities that are often targeted in kerberoasting attacks.
• EventData: To further refine the custom view, filtering by 'ticketEncriptionType' was implemented. The goal is to identify TGS (Ticket Granting Service) tickets with weak encryption. Events with values other than '0x11' and '0x12' (representing AES encryption) and values different from '0x17' and '0x18' (representing RC4 encryption) are included in this custom view. By excluding these strong encryption values, we can specifically target TGS tickets with potentially vulnerable encryption types.

Additionally, another custom view, which has proven to be effective in identifying kerberoasting attacks, is illustrated in the figure below. This custom view complements the filtering based on event levels, IDs, and EventData, providing an integrated approach to monitoring and detecting kerberoasting activity.

• Event Level: Levels 0–5 were chosen in the creation of the custom view for kerberoasting to provide a more detailed and comprehensive analysis of the logs.
• Event IDs: The IDs 4768 and 4769 were specifically chosen when creating the Custom View. These event IDs are associated with TGT (Ticket Granting Ticket) authentication requests and issuances, which are relevant for monitoring kerberoasting activities.

EventData: The filtering in the custom view focuses on two specific elements:

• "TicketOptions" with the values "0x40800010", "0x40810000", and "0x40810010". These values correspond to specific ticket options associated with kerberoasting attacks that were identified during the replication process.
• "TicketEncryptionType" with the values "0x17" and "0x18". These values represent RC4 encryption, which is often exploited in kerberoasting attacks.

By filtering events based on these EventData elements, the custom view effectively targets and detects potential kerberoasting activities in the event logs.

Conclusion

As we have seen, the reported problem poses a vulnerability within the organization and can be easily exploited in attacks such as Kerberoasting, which specifically targets service accounts with weak passwords. The solution to this problem is the use of autonomously managed service accounts, which provide automated password management and contribute to overall security and reduced exposure to attacks in the environment. These accounts possess several characteristics, including highly complex passwords, restricted permissions, and the prevention of interactive logon, ensuring that only authorized machines have access to the service account.

In conclusion, the Event Viewer is a vital tool for viewing event logs both locally and remotely, including events related to the Kerberos protocol. To ensure comprehensive system monitoring of user authentication and access in an Active Directory network environment, it is essential to enable the mentioned audit subcategories in Group Policy Management. These subcategories allow the identification of events on a domain controller. Additionally, creating Custom Views using XML filtering is a powerful method to search event logs and display relevant information, facilitating the detection and prevention of potential attacks and malicious behavior in the Active Directory.

References:

“https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn319109(v=ws.11)"

“https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn319105(v=ws.11)"

“https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn452415(v=ws.11)"

“https://learn.microsoft.com/pt-br/windows-server/identity/ad-ds/manage/understand-service-accounts"

“https://learn.microsoft.com/pt-br/azure/active-directory/fundamentals/service-accounts-on-premises"

“https://attack.mitre.org/techniques/T1558/003/"

“https://docs.logpoint.com/docs/alert-rules/en/latest/MITRE.html"

“https://owasp.org/www-pdf-archive/OWASP_Frankfurt_-44_Kerberoasting.pdf "

“ https://adsecurity.org/?tag=kerberoast ”