How do you handle the KRBTGT object? And when was the last time you changed KRBTGT password? or which AD attacks can be performed by using KRBTGT. The post-Monitor KRBTGT with Azure Sentinel describes why and how to monitor KRBTGT.
These and others will be described in the following blog post, including some points about Azure ATP, MCAS, and Azure Sentinel.

What is KRBTGT

The KRBTGT is an Active Directory default account that operates as a service account for the Key Distribution Center (KDC) service. It’s created automatically when a new domain is created.
Some highlights for KRBTGT:

• The SID for the KRBTGT account is S-1-5-domain-502
• Lives in the Users OU in the ADDS by default
• It cannot be deleted
• It cannot be changed
• It cannot be enabled
• It belongs to the following two groups
  • Domain Users
  • Denied RODC Password Replication Group

KDC service handles all Kerberos ticket requests, so the KRBTGT account in Active Directory plays a crucial role in encrypting and signing all Kerberos tickets for the Active Directory.

How it works

• The user logs on with user credentials to a domain-joined computer with his machine.
• The user requests authentication by sending a timestamp (Pre-auth data) encrypted with the user’s password-based encryption key (password hash)
• The user (with the principal name) requests a Kerberos service ticket (TGT) with PREAUTH data (Kerberos AS-REQ)
• The Kerberos server (KDC) receives the authentication request, then validates the data, and replies with a TGT (Kerberos AS-REP)

Why, How, and before changing

In 99% of the scenarios, the KRBTGT account’s password has not changed since the Active Directory Domain Services was set up for the first time. But since it’s an Active Directory account, all writable DCs know the account password to decrypt Kerberos tickets for validation.
Thus, the attackers may use the KRBTGT account to persist on the network even if every other account has its password changed.
This is the reason why Microsoft recommends that the KRBTGT password change regularly.
Changing the KRBTGT account password can be painful, and it must be changed twice to ensure no password history is maintained.
There are two KRBTGT Password Change Scenarios:
Maintenance scenario when changing the KRBTGT account password once, waiting for replication to complete, and then changing the password a second time provides a solid process for ensuring the KRBTGT account is protected and reduces risk.
Breach Recovery scenario when you must change the KRBTGT account password twice to invalidate all existing TGTs forcing clients to re-authenticate since the KDC service will be unable to decrypt the existing TGTs.
Note: On the second password reset, you must wait a period, based on TGT lifetime + TGS lifetime 600minutes + latency de replication AD + Time Skew.
It’s also recommended to force the AD replication and stop and start the KDC service on all RW Domain Controllers.

Highlights

Some highlights when changing the KRBTGT password:

• It is possible to wait 24 hours between the first and second resets.
• Microsoft only supports the KRBTGT password when the domain functional level is Windows Server 2008 or more excellent.
• KRBTGT password changes as part of the DFL update to 2008 to support Kerberos AES encryption, so it has been tested
• When changing the KRBTGT account password, make sure you use a solid password.
• KRBTGT password must be a complex password
• If you choose a simple password, it’s automatically changed to a complex password in the background.
• Two main events for KRBTGT:
  • Event ID 14 — Kerberos Key Integrity
  • Event ID 10 — KDC Password Configuration

Password Checking

How to check the last password changes? There are few ways to prevent the previous password change date using PowerShell with the following command:

$user = [ADSI]’LDAP://CN=krbtgt,CN=Users,DC=yourdomainname,DC=com’; [datetime]::FromFileTime($user.ConvertLargeIntegerToInt64($user.pwdLastSet.value))
Get-AdUser krbtgt -property created, passwordlastset, enabled, sid, distinguishedname

How to Reset

KRBTGT account password reset divided into few phases: (reset the KRBTGT user account password twice)

• From Active Directory Users and Computers, reset the password twice.
• After resetting the KRBTGT password, ensure that event ID 6 in the Microsoft-Windows-Kerberos-Key-Distribution-Center event source is written to the System event log.
• Verify KRBTGT password replication

If you want to reset KRBTGT from PowerShell, run the following command:
Microsoft has a KRBTGT account password PowerShell script on TechNet that will change the KRBTGT account password once for a domain, force replication, and monitor change status.

Azure Sentinel Detection

Azure Sentinel with Azure ATP and security alerts can detect and hunt KDC events with KRBTGT changes and provide ways to investigate and remediate with the right actions.
When trying to gain access to the KRBTGT account by an attacker, most of the time, it will be Golden Ticket attacks that can be carried out against Active Directory domains, where access control is implemented using Kerberos tickets issued to authenticated users by a Key Distribution Service.
The attacker gains control over the domain’s Key Distribution Service account (KRBTGT) by stealing its hash. This allows the attacker to generate Ticket Granting Tickets (TGTs) for any Active Directory objects.
With valid TGTs, the attacker can request access to any resource or system on its domain from the Ticket Granting Service (TGS).
From Azure ATP Domain dominance alerts
“Attackers with domain admin rights can compromise the KRBTGT account. Using the KRBTGT account, they can create a Kerberos ticket-granting ticket (TGT) that provides authorization to any resource and set the ticket expiration to any arbitrary time. This fake TGT is called a “Golden Ticket” and allows attackers to achieve network persistence.”
Azure ATP can detect KRBTGT with Suspected Golden Ticket usage for the following alerts:

• encryption downgrade
• forged authorization data
• nonexistent account
• ticket anomaly
• ticket anomaly using RBCD
• time anomaly

The Windows event logs can also provide additional information with event id’s numbers 10 and 14 and KDC source (Microsoft-Windows-Kerberos-Key-Distribution-Center).
With the Azure Sentinel log query, you can identify the action by running a simple query with the event table and query the event id numbers or the event source.
So how can I combine all of this helpful information with Azure Sentinel? to work with Analytics rules, Hunting, and Incidents, you need to make sure that you have got the following requirements:

• Connected Azure ATP Data Connector
• Connected Security Events Data Connector
• Collected Logs from KDC-Event for Event ID 14 and Event ID 10

Once you’ve got all of these requirements, you can create an incident rule, hunting, and work queries alerts.
To create a simple analytics rule on the Azure Sentinel dashboard, run the following actions.
 

Once an Analytics rule has been configured, you can correlate the Azure ATP information and investigate the event.
More blog posts about Azure Sentinel