{
	"id": "3e3748cf-6bf6-4821-96c0-430b26b91a19",
	"created_at": "2026-04-06T01:32:33.797101Z",
	"updated_at": "2026-04-10T03:23:18.05024Z",
	"deleted_at": null,
	"sha1_hash": "8a33706c29a0eefbc44266bfd79a24d4f170c7d2",
	"title": "Kerberos \u0026 KRBTGT: Active Directory’s Domain Kerberos Service Account",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 628130,
	"plain_text": "Kerberos \u0026 KRBTGT: Active Directory’s Domain Kerberos\r\nService Account\r\nBy Sean Metcalf\r\nPublished: 2014-11-10 · Archived: 2026-04-06 01:14:03 UTC\r\nEvery Domain Controller in an Active Directory domain runs a KDC (Kerberos Distribution Center) service\r\nwhich handles all Kerberos ticket requests. AD uses the KRBTGT account in the AD domain for Kerberos tickets.\r\nThe KRBTGT account is one that has been lurking in your Active Directory environment since it was first stood\r\nup. Each Active Directory domain has an associated KRBTGT account that is used to encrypt and sign all\r\nKerberos tickets for the domain. It is a domain account so that all writable Domain Controllers know the account\r\npassword in order to decrypt Kerberos tickets for validation. Read Only Domain Controllers (RODCs) each have\r\ntheir own individual KRBTGT account used to encrypt/sign Kerberos tickets in their own sites. The RODC has a\r\nspecific KRBTGT account (krbtgt_######) associated with the RODC through a backlink on the account. This\r\nensures that there is cryptographic isolation between trusted Domain Controllers and untrusted RODCs.\r\nThe KRBTGT is shrouded in mystery and most AD admins will not mess with it or change its membership. It\r\nshouldn’t be a member of Domain Admins, Administrators, or any other groups other than “Domain Users” and\r\n“Denied RODC Password Replication Group”. Note that the “Denied RODC Password Replication Group” is a\r\nnew group added when you run ADPrep before installing the domain’s first 2008/2008R2/2012 DC. This group\r\nsupports Read-Only Domain Controllers (RODC) ensuring that certain accounts never have their passwords stored\r\non a RODC.\r\nThe SID for the KRBTGT account is S-1-5-\u003cdomain\u003e-502 and lives in the Users OU in the domain by default.\r\nMicrosoft does not recommend moving this account to another OU.\r\nFrom Microsoft TechNet:\r\nThe KRBTGT account is a local default account that acts as a service account for the Key Distribution\r\nCenter (KDC) service. This account cannot be deleted, and the account name cannot be changed. The\r\nKRBTGT account cannot be enabled in Active Directory.\r\nhttps://adsecurity.org/?p=483\r\nPage 1 of 7\n\nKRBTGT is also the security principal name used by the KDC for a Windows Server domain, as\r\nspecified by RFC 4120. The KRBTGT account is the entity for the KRBTGT security principal, and it\r\nis created automatically when a new domain is created.\r\nWindows Server Kerberos authentication is achieved by the use of a special Kerberos ticket-granting\r\nticket (TGT) enciphered with a symmetric key. This key is derived from the password of the server or\r\nservice to which access is requested. The TGT password of the KRBTGT account is known only by the\r\nKerberos service. In order to request a session ticket, the TGT must be presented to the KDC. The TGT\r\nis issued to the Kerberos client from the KDC.\r\n99.99% of the time*, the KRBTGT account’s password has not changed since the Active Directory domain was\r\nstood up.\r\nRODCs have the msDS-SecondaryKrbTgtNumber attribute on their computer object populated with the random\r\nRODC code with identifies the RODC KRBTGT account (KRBTGT_33171) following the name standard\r\n“krbtgt_######” (where # is a number greater than 32737) .\r\nThere’s also an attribute which is a back-link to the associated RODC called msDS-KrbTgtLinkBl.\r\nThe KRBTGT accounts store the Key Version Number (KVNO) in the msDS-KeyVersionNumber attribute on the\r\nKRBTGT account.\r\nTheoretically, this tracks the KRBTGT password version and is necessary for the DCs to identify which KRBTGT\r\naccount was used to encrypt/sign Kerberos tickets. If the KVNO = 5 and the Kerberos (TGT) ticket has a KVNO\r\n= 4, then the DC needs to use the previous KRBTGT password to decrypt the Kerberos ticket.\r\nWindows doesn’t do that though. It attempts to decrypt with the current password and if that fails, it attempts\r\nagain with the previous one (assuming it has it). Reference: MSDN To KVNO or To Not KVNO\r\n“To distinguish between Kerberos tickets issued by RODC’s vs. Kerberos tickets issued by full RWDC’s, the low\r\n16 bits of the Property Version Number (PVN) of the 32-bit unicodePWD attribute of the relevant krbtgt account\r\nas the traditional Key Version Number (KVNO) and the high 16 bits as a branch ID.”\r\n– TechNet Blogs on 2008 \u0026 2003 DC Interop problems\r\nScript code to identify KRBTGT account info (including the key version number – tracks password changes) for\r\nevery domain in the AD forest:\r\nimport-module activedirectory\r\n$ADForestRootDomain = (Get-ADForest).RootDomain\r\n$AllADForestDomains = (Get-ADForest).Domains\r\n$ForestKRBTGTInfo = @()\r\nForEach ($AllADForestDomainsItem in $AllADForestDomains)\r\n{\r\n[string]$DomainDC = (Get-ADDomainController -Discover -Force -Service “PrimaryDC” -\r\nDomainName $AllADForestDomainsItem).HostName\r\n[array]$ForestKRBTGTInfo += Get-ADUSer -filter {name -like “krbtgt*”} -Server $DomainDC -Prop\r\nName,Created,logonCount,Modified,PasswordLastSet,PasswordExpired,msDS-https://adsecurity.org/?p=483\r\nPage 2 of 7\n\nKeyVersionNumber,CanonicalName,msDS-KrbTgtLinkBl\r\n}\r\n$ForestKRBTGTInfo | Select Name,Created,logonCount,PasswordLastSet,PasswordExpired,msDS-KeyVersionNumber,CanonicalName | ft -auto\r\nThe following graphic shows similar results to the script code above:\r\nPowerShell code to get Active Directory domain KRBTGT account details for the forest: Get-PSADForestKRBTGTInfo\r\nHere’s the output of this script for a lab environment:\r\nProcessing 2 service accounts (user accounts) with SPNs discovered in AD Forest\r\nDC=ADSecurity,DC=org\r\nDomain          : lab.ADSecurity.org\r\nUserID          : krbtgt\r\nDescription     : Key Distribution Center Service Account\r\nPasswordLastSet : 11/16/2009 05:59:56\r\nLastLogon       : 01/01/1601 00:00:00\r\nDomain          : RD.ADSecurity.org\r\nUserID          : krbtgt\r\nDescription     : Key Distribution Center Service Account\r\nPasswordLastSet : 08/30/2013 19:23:25\r\nLastLogon       : 01/01/1601 00:00:00\r\nThe LastLogon value for the KRBTGT accounts in the above example shows that the accounts haven’t logged on.\r\nWhile the account is disabled and technically can’t be enabled, it is often one of the first accounts an attacker goes\r\nafter once a Domain Controller has been compromised.\r\nhttps://adsecurity.org/?p=483\r\nPage 3 of 7\n\nWhy is that?\r\nHere’s how Kerberos works (in a nutshell):\r\n1. User logs on with AD user name and password to a domain-joined computer (usually a workstation).\r\n2. The user requests authentication by sending a timestamp (Pre-auth data) encrypted with the users\r\npassword-based encryption key (password hash).\r\n3. User account (user@adsecurity.org) requests a Kerberos service ticket (TGT) with PREAUTH data\r\n(Kerberos AS-REQ).\r\n4. The Kerberos server (KDC) receives the authentication request, validates the data, and replies with a TGT\r\n(Kerberos AS-REP).\r\nThe most important point of this process is that the Kerberos TGT is encrypted and signed by the KRBTGT\r\naccount. This means that anyone can create a valid Kerberos TGT if they have the KRBTGT password hash.\r\nFurthermore, despite the Active Directory domain policy for Kerberos ticket lifetime, the KDC trusts the TGT, so\r\nthe custom ticket can include a custom ticket lifetime (even one that exceeds the domain kerberos policy).\r\nThe attacker may use the KRBTGT account to persist on the network even if every other account has its password\r\nchanged.\r\nDuring an incredibly awesome talk (Video) at the Black Hat 2014 security conference in Las Vegas, NV in early\r\nAugust, Skip Duckwall \u0026 Benjamin Delpy spoke about a method (using Mimikatz) to generate your own\r\nKerberos tickets (aka the Golden Ticket). Key to this is that you need the hash for the KRBTGT account which\r\nexists in every Active Directory domain. The KRBTGT account is the account used to generate and sign every\r\nKerberos ticket in the domain.\r\nThe “Golden Ticket” method enables an attacker to create their own TGT using the KRBTGT account password\r\nhash (often extracted from a DC using Mimikatz) with a long lifetime (10 years perhaps) and with any group\r\nmembership they wish – remember, the TGT is encrypted/signed by the domain’s KRBTGT account which is\r\ntrusted by default by all computers in the domain. And why wouldn’t they? That account is central to Kerberos\r\nworking. Since Kerberos tickets are only validated after 20 minutes (for Kerberos service ticket, TGS), an attacker\r\nhas more than enough time to access data and/or resources. If not, the attacker can always generate a new\r\n“Golden” TGT.\r\nThe brilliant part of creating a Golden Ticket (GT)  using the domain KRBTGT hash is that the Golden Ticket\r\ncontains whatever options the creator specifies and the KDC receiving the Golden Ticket generates a TGS\r\nassuming that all info in the Golden Ticket is valid. This means that a Golden Ticket can be created for a disabled\r\nuser outside of normal logon hours.\r\nCommon TGT Options:\r\nUser Name\r\nUser Domain\r\nTicket Encryption Type\r\nLogon Hours\r\nhttps://adsecurity.org/?p=483\r\nPage 4 of 7\n\nGroup Membership (PAC) which contains group SIDS (in a Golden Ticket user SIDs in the PAC are\r\nprocessed)\r\nAuthentication Silo\r\n(remove) Protected Users\r\nIf your Active Directory domain/forest has been compromised and you can’t rebuild the entire network from\r\nscratch, you will need to reset all passwords in the forest, including the KRBTGT account password(s). Microsoft\r\nstates that resetting the KRBTGT account password is only supported in a Windows Server 2008 Domain\r\nFunctional Level (DFL) (or higher). When the DFL is raised from 2003 to 2008 (or higher), the KRBTGT account\r\npassword is changed automatically.\r\nChanging the KRBTGT Password\r\nChanging the KRBTGT account password can be painful – it has to be changed twice to ensure there is no\r\npassword history maintained. If your domain/forest has been compromised, you must reset the KRBTGT account\r\npassword twice. It must be changed twice since the account’s password history stores the current password and the\r\nlast one or ‘n-1’ (sounds a lot like a trust account password and a computer account password). If this isn’t done, it\r\nis very likely the attacker can get back on the network at some point and generate custom TGTs (aka Golden\r\nTickets) using the KRBTGT account password hash. The KRBTGT password hash which usually has never been\r\nchanged (other than when the domain functional level was raised from 2003 to 2008/2008R2/2012/2012R2).\r\nEnsure you change the KRBTGT account password for every domain in your forest. Don’t leave an attacker any\r\nbackdoors.\r\nNote: Changing the KRBTGT password is only supported by Microsoft once the domain functional level is\r\nWindows Server 2008 or greater. This is likely due to the fact that the KRBTGT password changes as part of the\r\nDFL update to 2008 to support Kerberos AES encryption, so it has been tested.\r\nMicrosoft now recommends that the KRBTGT password change on a regular basis.\r\nhttps://adsecurity.org/?p=483\r\nPage 5 of 7\n\nMicrosoft posted a KRBTGT account password PowerShell script on TechNet that will change the KRBTGT\r\naccount password once for a domain, force replication, and monitor change status.\r\nNote that changing the KRBTGT account password in a 2008 (or higher) DFL will not cause replication issues.\r\nKRBTGT Password Change Scenarios:\r\nMaintenance: Changing the KRBTGT account password once, waiting for replication to complete (and the\r\nforest converge), and then changing the password a second time, provides a solid process for ensuring the\r\nKRBTGT account is protected and reduces risk (Kerberos and application issues).\r\nBreach Recovery: Changing the KRBTGT account password twice in rapid succession (before AD\r\nreplication completes) will invalidate all existing TGTs forcing clients to re-authenticate since the KDC\r\nservice will be unable to decrypt the existing TGTs. Choosing this path will likely require rebooting\r\napplication servers (or at least re-starting application services to get them talking Kerberos correctly again).\r\nMicrosoft has two TechNet articles which describe scenarios where changing the KRBTGT account password\r\nmay be necessary:\r\nEvent ID 14 — Kerberos Key Integrity\r\nEvent ID 10 — KDC Password Configuration\r\nWhen changing the KRBTGT account password make certain you use a solid password.\r\nUPDATE: Note that when you set the KRBTGT password, even if you set it to “KerberosIsMyPal1!” it will\r\nbe automatically changed to a complex password in the background. This means that the password you\r\nenter when changing the password doesn’t matter, only that the password changes.\r\nHere’s PowerShell code to generate a 128 character, complex password. Note that the DC will change the\r\npassword to something else.\r\n[Reflection.Assembly]::LoadWithPartialName(“System.Web”)\r\n$RandPassLength = [int] 128\r\nWrite-Output “Generating $RandPassLength Character Random Password”\r\n$RandomPassword = [System.Web.Security.Membership]::GeneratePassword($RandPassLength,2)\r\n$RandomPassword\r\nIn conclusion, the KRBTGT account is critical for AD domain Kerberos authentication and if not properly\r\nprotected, enables an attacker to create their own Kerberos TGT “Golden Tickets.” These special TGTs provide\r\nthe attacker with access to anything and everything Kerberos enabled on the network without having to add\r\nthemselves to AD groups.\r\nNote:\r\nThere is a potential issue with Exchange when changing the KRBTGT account password:  Considering updating\r\nyour Domain functional level from Windows 2003? Read this!\r\nReferences:\r\nhttps://adsecurity.org/?p=483\r\nPage 6 of 7\n\nActive Directory Accounts: KRBTGT\r\nhttp://blogs.msdn.com/b/openspecification/archive/2011/05/11/notes-on-kerberos-kvno-in-windows-rodc-environment.aspx\r\nhttp://blogs.technet.com/b/instan/archive/2009/07/30/problems-with-introducing-a-new-windows-server-2008-dc-into-a-windows-2003-forest.aspx\r\nMimikatz and Active Directory Kerberos Attacks\r\nBlackHat USA 2013 Slides: Microsoft’s Credential Problem – Skip Duckwall \u0026 Chris Campbell\r\nAbusing Kerberos (aka the Mimikatz Golden Ticket Presentation) BlackHat USA 2014 Presentation Video\r\n– Skip Duckwall \u0026 Benjamin Delpy\r\nMimikatz and Golden Tickets… What’s the BFD? BlackHat USA 2014 Redux part 1\r\nBlueHat 2014 Slides: Reality Bites: The Attacker’s View of Windows Authentication and Post-exploitation\r\n– Chris Campbell, Benjamin Delpy, \u0026 Skip Duckwall\r\nChristopher Campbell’s DEFCON 22 Presentation: The Secret Life of krbtgt (PDF download)\r\nDerbyCon 2014 Presentation: Et tu Kerberos – Christopher Campbell\r\nPass The Golden Ticket Protection from Kerberos Golden Ticket Mitigating pass the ticket on Active\r\nDirectory\r\nWhy We Don’t Get It and Why We Shouldn’t\r\nLet’s talk about Pass-the-Hash\r\nPass The Golden Ticket Protection from Kerberos – Golden Ticket Mitigating pass the ticket on Active\r\nDirectory (CERT EU Whitepaper)\r\nMitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft, Version 1 and 2 (Microsoft)  (PDF\r\ndocument download).\r\nLSA (LSASS) Protection Option in Windows 8.1 \u0026 Windows Server 2012 R2 (technical article)\r\nFixing Pass The Hash and Other Problems (Blog post by Scriptjunkie 2013)\r\nActive Directory Real Defense for Domain Admins – Jason Lang\r\nAttacking Microsoft Kerberos Kicking the Guard Dog of Hades – Tim Medin\r\nDerbyCon 2013: The InfoSec Revival – Scriptjunkie\r\nKerberos for the Busy Admin\r\nHow the Kerberos Version 5 Authentication Protocol Works\r\nEncryption Type Selection in Kerberos Exchanges\r\nUnderstanding Microsoft Kerberos PAC Validation\r\nReplication Version Number for your KrbTGT account password?\r\n(Visited 259,236 times, 6 visits today)\r\nSource: https://adsecurity.org/?p=483\r\nhttps://adsecurity.org/?p=483\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://adsecurity.org/?p=483"
	],
	"report_names": [
		"?p=483"
	],
	"threat_actors": [
		{
			"id": "8670f370-1865-4264-9a1b-0dfe7617c329",
			"created_at": "2022-10-25T16:07:23.69953Z",
			"updated_at": "2026-04-10T02:00:04.716126Z",
			"deleted_at": null,
			"main_name": "Hades",
			"aliases": [
				"Operation TrickyMouse"
			],
			"source_name": "ETDA:Hades",
			"tools": [
				"Brave Prince",
				"Gold Dragon",
				"GoldDragon",
				"Lovexxx",
				"Olympic Destroyer",
				"Running RAT",
				"RunningRAT",
				"SOURGRAPE",
				"running_rat"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775439153,
	"ts_updated_at": 1775791398,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/8a33706c29a0eefbc44266bfd79a24d4f170c7d2.pdf",
		"text": "https://archive.orkl.eu/8a33706c29a0eefbc44266bfd79a24d4f170c7d2.txt",
		"img": "https://archive.orkl.eu/8a33706c29a0eefbc44266bfd79a24d4f170c7d2.jpg"
	}
}