Skip to content
CyberOpsSec
CyberOpsSec

Just another cybersecurity site

  • Home
  • Posts
  • Knowledge
    • Auditing
    • Linux Commands
    • Ports & Protocols
    • Scanning
    • Sniffing
    • Syslog
    • Vulnerability/Patch Mgmt
  • About
  • Contact
CyberOpsSec

Just another cybersecurity site

Rolling KRBTGT Account

Admin, September 30, 2024November 8, 2024

It is best practice to roll this account’s password every 180 days or immediately if there is a confirmed AD compromise.

This had never been done at the company I currently work for because the IT team had been too scared to do so. I did some research on the topic and wanted to share the information:

If this account has never had it’s password changed or the domain functional level hasn’t been upgraded there could be issues with hardening cryptographic settings within AD. The KRBTGT account’s pw hash is used to sign Kerberos tickets in the domain and the password should be reset twice.

One should wait at least 10x hours before resetting the password a second time. It needs to be reset twice because the KRBTGT account keeps a pw history of two. After the first pw reset and waiting 10x hours the tickets will expire. See screenshot of GPO default domain policy.

After resetting the password once, the new KRBTGT hashed password is used in the signing process. Tickets signed with the older password will continue to work because the password history is two. The older tickets will expire and phase out.

After resetting the password for the second time, new tickets will use the newly rolled password hash and older tickets will use the password hash after the first password change. After 10x hours they will expire and only the pw hash from the second password change will be used.

There is a Powershell script that is helpful in aiding in this process: https://github.com/microsoft/New-KrbtgtKeys.ps1

The script can be run in a simulation mode to make sure that there will not be any unexpected consequences from rolling the password. As you can see in the screenshot the password had not been rolled since 2004, since the domain was created. After doing this in the correct order. I had no issues in my lab or production environment.

I have not tested rolling the password twice without waiting 10x hours to simulate remediation after a compromise, but according to documentation if you have to do that all machines joined to the domain would need to be rebooted.

Vulnerabilities

Post navigation

Previous post
Next post

Related Posts

ICMP Timestamp Request Remote Date Disclosure

May 8, 2024June 5, 2024

You may have seen this vulnerability pop in Nessus. In order to remediate this we…

Read More

Uninstall Vulnerable Software Remotely

May 8, 2024June 5, 2024

If you find a ton of boxes running vulnerable software that is no longer used…

Read More

Blocking Responder

November 21, 2023March 13, 2024

Responder is usually one of the first things a pentester will fire up after plugging…

Read More

Leave a Reply Cancel reply

You must be logged in to post a comment.

Recent Posts

  • UBI – User Browsing Isolation
  • Rolling KRBTGT Account
  • SentinelOne: Why it’s important to monitor and audit your EPP
  • Nessus False Positive
  • Uninstall Vulnerable Software Remotely

Recent Comments

No comments to show.

Archives

  • November 2024
  • September 2024
  • June 2024
  • May 2024
  • March 2024
  • January 2024
  • November 2023
  • September 2023

Categories

  • EPP
  • Uncategorized
  • Vulnerabilities
©2025 CyberOpsSec | WordPress Theme by SuperbThemes
CyberOpsSec
  • Home
  • Posts
  • Knowledge
    • Auditing
    • Linux Commands
    • Ports & Protocols
    • Scanning
    • Sniffing
    • Syslog
    • Vulnerability/Patch Mgmt
  • About
  • Contact