{
	"id": "1474360a-2f1a-4bcd-a9d3-19c891fa5dba",
	"created_at": "2026-04-06T00:14:07.637829Z",
	"updated_at": "2026-04-10T03:23:18.017019Z",
	"deleted_at": null,
	"sha1_hash": "89409a118d57f7e11d3feb116deec0992b4df5a8",
	"title": "Mimikatz and Active Directory Kerberos Attacks",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 501848,
	"plain_text": "Mimikatz and Active Directory Kerberos Attacks\r\nBy Sean Metcalf\r\nPublished: 2014-11-22 · Archived: 2026-04-05 13:29:43 UTC\r\nNov 22 2014\r\nNOTE:\r\nWhile this page will remain, the majority of the Mimikatz information in this page is now in the “Unofficial\r\nMimikatz Guide \u0026 Command Reference” which will be updated on a regular basis.\r\nMimikatz is the latest, and one of the best, tool to gather credential data from Windows systems. In fact I consider\r\nMimikatz to be the “swiss army knife” of Windows credentials – that one tool that can do everything. Since the\r\nauthor of Mimikatz, Benjamin Delpy, is French most of the resources describing Mimikatz usage is in French, at\r\nleast on his blog. The Mimikatz GitHub repository is in English and includes useful information on command\r\nusage.\r\nMimikatz is a Windows x32/x64 program coded in C by Benjamin Delpy (@gentilkiwi) in 2007 to learn more\r\nabout Windows credentials (and as a Proof of Concept). There are two optional components that provide\r\nadditional features, mimidrv (driver to interact with the Windows kernal) and mimilib (AppLocker bypass, Auth\r\npackage/SSP, password filter, and sekurlsa for WinDBG). Mimikatz requires administrator or SYSTEM and often\r\ndebug rights in order to perform certain actions and interact with the LSASS process (depending on the action\r\nrequested).\r\nAfter a user logs on, a variety of credentials are generated and stored in the Local Security Authority Subsystem\r\nService, LSASS, process in memory. This is meant to facilitate single sign-on (SSO) ensuring a user isn’t\r\nprompted each time resource access is requested. The credential data may include NTLM password hashes, LM\r\npassword hashes (if the password is \u003c15 characters), and even clear-text passwords (to support WDigest and SSP\r\nauthentication among others. While you can prevent a Windows computer from creating the LM hash in the local\r\ncomputer SAM database (and the AD database), though this doesn’t prevent the system from generating the LM\r\nhash in memory.\r\nThe majority of Mimikatz functionality is available in PowerSploit (PowerShell Post-Exploitation Framework)\r\nthrough the “Invoke-Mimikatz” PowerShell script which “leverages Mimikatz 2.0 and Invoke-ReflectivePEInjection to reflectively load Mimikatz completely in memory. This allows you to do things such as\r\ndump credentials without ever writing the mimikatz binary to disk.”  Mimikatz functionality supported by Invoke-Mimikatz is noted below.\r\nBenjamin Delpy posted an Excel chart on OneDrive (shown below) that shows what type of credential data is\r\navailable in memory (LSASS), including on Windows 8.1 and Windows 2012 R2 which have enhanced protection\r\nmechanisms reducing the amount and type of credentials kept in memory.\r\nhttps://adsecurity.org/?p=556\r\nPage 1 of 9\n\n(Click image to embiggen)\r\nOne of the biggest security concerns with Windows today is “Pass the Hash.” Simply stated, Windows performs a\r\none-way hash function on the user’s password and the result is referred to as a “hash.” The one-way hash\r\nalgorithm changes the password in expected ways given the input data (the password) with the result being\r\nscrambled data that can’t be reverted back to the original input data, the password. Hashing a password into a hash\r\nis like putting a steak through a meat grinder to make ground beef – the ground beef can never be put together to\r\nbe the same steak again. Pass the Hash has many variants, from Pass the Ticket to OverPass the Hash (aka pass the\r\nkey).\r\nThe following quote is a Google Translate English translated version of the Mimikatz website (which is in\r\nFrench).\r\nContrary to what could easily be imagined, Windows does not use the password of the user as a\r\nshared secret, but non-reversible derivatives: LM hash, NTLM, DES keys, AES … According to the\r\nprotocol, the secret and the algorithms used are different:\r\nProtocol Algorithm Secret used\r\nLM DES-ECB LM Hash\r\nNTLMv1 DES-ECB NT Hash\r\nNTLMv2 HMAC-MD5 NT Hash\r\nMimikatz OS support:\r\nWindows XP\r\nWindows Vista\r\nWindows 7\r\nWindows 8\r\nWindows Server 2003\r\nWindows Server 2008 / 2008 R2\r\nWindows Server 2012 / 2012 R2\r\nWindows 10\r\nSince Windows encrypts most credentials in memory (LSASS), they should be protected, but it is a type\r\nof reversible encryption (though creds are in clear-text). Encrypt works with LsaProtectMemory and\r\nhttps://adsecurity.org/?p=556\r\nPage 2 of 9\n\ndecrypt with LsaUnprotectMemory.\r\nNT5 encryption types: RC4 \u0026 DESx\r\nNT6 encryption types: 3DES \u0026 AES\r\nMimikatz capabilities:\r\nDump credentials from LSASS (Windows Local Security Account database) [sekurlsa module]\r\nMSV1.0: hashes \u0026 keys (dpapi)\r\nKerberos password, ekeys, tickets, \u0026 PIN\r\nTsPkg (password)\r\nWDigest (clear-text password)\r\nLiveSSP (clear-text password)\r\nSSP (clear-text password)\r\nGenerate Kerberos Golden Tickets (Kerberos TGT logon token ticket attack)\r\nGenerate Kerberos Silver Tickets (Kerberos TGS service ticket attack)\r\nExport certificates and keys (even those not normally exportable).\r\nDump cached credentials\r\nStop event monitoring.\r\nBypass Microsoft AppLocker / Software Restriction Polcies\r\nPatch Terminal Server\r\nBasic GPO bypass\r\nItems in bold denotes functionality provided by the PowerSploit Invoke-Mimikatz module with built-in parameters.\r\nOther mimikatz commands may work using the command parameter.\r\nMimikatz Command Overview:\r\nThe primary command components are sekurlsa, kerberos, crypto, vault, and lsadump.\r\nSekurlsa interacts with the LSASS process in memory to gather credential data and provides enhanced capability\r\nover kerberos.\r\nThe Mimikatz kerberos command set enables modification of Kerberos tickets and interacts with the official\r\nMicrosoft Kerberos API. This is the command that creates Golden Tickets. Pass the ticket is also possible with this\r\ncommand since it can inject Kerberos ticket(s) (TGT or TGS)  into the current session. External Kerberos tools\r\nmay be used for session injection, but they must follow the Kerberos credential format (KRB_CRED).\r\nMimikatz kerberos also enables the creation of Silver Tickets which are Kerberos tickets (TGT or TGS) with\r\narbitrary data enabling AD user/ group impersonation.\r\nThe key required for ticket creation depends on the type of ticket being generated:\r\nGolden tickets require the KRBTGT account NTLM password hash.\r\nSilver tickets require the computer or service account’s NTLM password hash.\r\nhttps://adsecurity.org/?p=556\r\nPage 3 of 9\n\nCrypto enables export of certificates on the system that are not marked exportable since it bypasses the standard\r\nexport process.\r\nVault enables dumping data from the Windows vault.\r\nLsadump enables dumping credential data from the Security Account Manager (SAM) database which contains\r\nthe NTLM (sometimes LM hash) and supports online and offline mode as well as dumping credential data from\r\nthe LSASS process in memory. Lsadump can also be used to dump cached credentials. In a Windows domain,\r\ncredentials are cached (up to 10) in case a Domain Controller is unavailable for authentication. However, these\r\ncredentials are stored on the computer.\r\nThese caches are located in the registry at the location HKEY_LOCAL_MACHINE\\SECURITY\\Cache\r\n(accessible SYSTEM).\r\nThese entries are encrypted symmetrically, but we find some information about the user, as well as\r\nsufficient to verify the hash authentication.\r\nFurther down is a more detailed list of mimikatz command functionality.\r\nCommon Kerberos Attacks:\r\nPass The Hash\r\nOn Windows, a user provides the userid and password and the password is hashed, creating the\r\npassword hash. When the user on one Windows system wants to access another, the user’s password\r\nhash is sent (passed) to the destination’s resource to authenticate. This means there is no need to\r\ncrack the user’s password since the user’s password hash is all that’s needed to gain access.\r\nContrary to what could easily be imagined, Windows does not use the password of the user as a\r\nshared secret, but non-reversible derivatives: LM hash, NTLM, DES keys, AES …\r\nPass the Ticket  (Google Translation)\r\nExtract an existing, valid Kerberos ticket from one machine and pass it to another one to gain access\r\nto resoiurces as that user.\r\nOver-Pass The Hash (aka Pass the Key)  (Google Translation)\r\nUse the NTLM hash to obtain a valid user Kerberos ticket request.\r\nThe user key (NTLM hash when using RC4) is used to encrypt the Pre-Authentication \u0026 first data\r\nrequests.\r\nThe following  quote is a Google Translate English translated version of the Mimikatz website\r\n(which is in French):\r\nAuthentication via Kerberos is a tad different. The client encrypts a timestamp from its user secret,\r\npossibly with parameters realm and iteration number sent from the server.\r\nIf the secret is correct, the server can decrypt the timestamp (and the passage verify that the clocks are\r\nnot too time-shifted).\r\nProtocol Secret (key) used\r\nhttps://adsecurity.org/?p=556\r\nPage 4 of 9\n\nKerberos\r\nOF\r\nRC4 = NT Hash!\r\nAES128\r\nAES256\r\nYes, the RC4 key type available and enabled by default in XP 8.1 is our NT hash!\r\nKerberos Golden Ticket  (Google Translation)\r\nThe Kerberos Golden Ticket is a valid TGT Kerberos ticket since it is encrypted/signed by the\r\ndomain Kerberos account (KRBTGT). The TGT is only used to prove to the KDC service on the\r\nDomain Controller that the user was authenticated by another Domain Controller. The fact that the\r\nTGT is encrypted by the KRBTGT password hash and can be decrypted by any KDC service in the\r\ndomain proves it is valid.\r\nGolden Ticket Requirements:\r\n* Domain Name [AD PowerShell module: (Get-ADDomain).DNSRoot]\r\n* Domain SID  [AD PowerShell module: (Get-ADDomain).DomainSID.Value]\r\n* Domain KRBTGT Account NTLM password hash\r\n* UserID for impersonation.\r\nThe Domain Controller KDC service doesn’t perform validate the user account until the TGT is\r\nolder than 20 minutes old, which means the attacker can use a disabled/deleted user account or even\r\na fictional user that doesn’t exist in AD!\r\nMicrosoft’s MS-KILE specification (section 5.1.3 ):\r\n“Kerberos V5 does not provide account revocation checking for TGS requests, which allows TGT\r\nrenewals and service tickets to be issued as long as the TGT is valid even if the account has been\r\nrevoked. KILE provides a check account policy (section 3.3.5.7.1) that limits the exposure to a\r\nshorter time. KILE KDCs in the account domain are required to check accounts when the TGT is\r\nolder than 20 minutes. This limits the period that a client can get a ticket with a revoked account\r\nwhile limiting the performance cost for AD queries.”\r\nSince the domain Kerberos policy is set on the ticket when generated by the KDC service on the\r\nDomain Controller, when the ticket is provided, systems trust the ticket validity. This means that\r\neven if the domain policy states a Kerberos logon ticket (TGT) is only valid for 10 hours, if the\r\nticket states it is valid for 10 years, it is accepted as such.\r\nThe KRBTGT account password is never changed* and the attacker can create Golden Tickets until\r\nthe KRBTGT password is changed (twice). Note that a Golden Ticket created to impersonate a user\r\npersists even if the impersonated user changes their password.\r\nThis crafted TGT requires an attacker to have the Active Directory domain’s KRBTGT password\r\nhash (typically dumped from a Domain Controller).\r\nThe KRBTGT NTLM hash can be used to generate a valid TGT (using RC4) to impersonate any\r\nuser with access to any resource in Active Directory.\r\nhttps://adsecurity.org/?p=556\r\nPage 5 of 9\n\nThe Golden Ticket (TGT) be generated and used on any machine, even one not domain-joined. The\r\ncreated TGT can be used without requiring Debug rights.\r\nMitigation: Limit Domain Admins from logging on to any other computers other than Domain\r\nControllers and a handful of Admin servers (don’t let other admins log on to these servers) Delegate\r\nall other rights to custom admin groups. This greatly reduces the ability of an attacker to gain access\r\nto a Domain Controller’s Active Directory database. If the attacker can’t access the AD database\r\n(ntds.dit file), they can’t get the KRBTGT account NTLM password hash. Configuring Active\r\nDirectory Kerberos to only allow AES may prevent Golden Tickets from being created. Another\r\nmitigation option is Microsoft KB2871997 which back-ports some of the enhanced security in\r\nWindows 8.1 and Windows 2012 R2.\r\nKerberos Silver Ticket\r\nThe Kerberos Silver Ticket is a valid Ticket Granting Service (TGS) Kerberos ticket since it is\r\nencrypted/signed by the service account configured with a Service Principal Name for each server\r\nthe Kerberos-authenticating service runs on.\r\nWhile a Golden ticket is encrypted/signed with the KRBTGT, a Silver Ticket is encrypted/signed by\r\nthe service account (computer account credential extracted from the computer’s local SAM or\r\nservice account credential).\r\nMost services don’t validate the PAC (by sending the PAC checksum to the Domain Controller for\r\nPAC validation), so a valid TGS generated with the service account password hash can include a\r\nPAC that is entirely fictitious – even claiming the user is a Domain Admin without challenge or\r\ncorrection.\r\nSince service tickets are identical in format to TGTs albeit with a different service name, all you need to\r\ndo is specify a different service name and use the RC4 (NTLM hash) of the account password (either\r\nthe computer account for default services or the actual account) and you can now issue service tickets\r\nfor the requested service.  Note:  You can also use the AES keys if you happen to have them instead of\r\nthe NTLM key and it will still work 😉\r\nIt is worth noting, that services like MSSQL, Sharepoint, etc will only allow you to play with those\r\nservices.  The computer account will allow access to CIFS, service creation, and a whole host of other\r\nactivities on the targeted computer.  You can leverage the computer account into a shell with PSEXEC\r\nand you will be running as system on that particular computer.  Lateral movement is then a matter of\r\ndoing whatever you need to do from there 🙂\r\nService Account Password Cracking by attacking the Kerberos Session Ticket (TGS)\r\nNOTE: This attack does NOT require hacking tools on the network since it can be performed\r\noffline.\r\nThe Kerberos session ticket (TGS) has a component that is encrypted with the service’s (either\r\ncomputer account or service account) password hash. The TGS for the service is generated and\r\ndelivered to the user after the user’s TGT is presented to the KDC service on the Domain Controller.\r\nSince the service account’s password hash is used to encrypt the server component, it is possible to\r\nrequest the service TGS and perform an offline password attack.\r\nhttps://adsecurity.org/?p=556\r\nPage 6 of 9\n\nOnly normal Kerberos traffic is observed on the wire: the TGT is delivered to the Domain\r\nController along with a TGS request and response. At this point, no further network traffic is\r\nrequired.\r\nService accounts typically have weak passwords and are rarely changed making these excellent\r\ntargets. Computer account passwords are changed about every 30 days and are extremely complex\r\nmaking them virtually uncrackable.\r\nFinding interesting service accounts is as simple as sending a Service Principal Name query to the\r\nGlobal Catalog.\r\nService accounts often have elevated rights in Active Directory and since only a Kerberos service\r\nticket (TGS) is required to attack the service account’s password, getting a TGS and saving it to\r\nanother system to crack the password means this is a difficult attack to stop.\r\nMitigation: Ensure all service accounts have long (\u003e25 characters), complex passwords and only\r\nhave the exact rights required (ensure the principle of least privilege).\r\nTim Medin (@timmedin) describes this attack at his “Attacking Microsoft Kerberos: Kicking the\r\nGuard Dog of Hades” presentation at DerbyCon 2014.\r\n[Slides: https://www.dropbox.com/s/1j6v6zbtsdg1kam/Kerberoast.pdf?dl=0 ]\r\nIn his DerbyCon2014 presentation, Tim Medin provided PowerShell code examples for requesting a\r\nTGS. I have modified it slightly to add the $SPN variable.\r\n$SPN = “HTTP/sharepoint.adsecurity.org”\r\nAdd-Type -AssemblyNAme System.IdentityModel\r\nNew-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken -ArgumentList “$SPN”\r\nPass the Cache (*nix systems)\r\nLinux/Unix systems (Mac OSX) store Kerberos credentials in a cache file. As of 11/23/2014,\r\nMimikatz supports extracting the credential data for passing to Active Directory in a similar manner\r\nto the Pass the Hash/ Pass the Ticket method.\r\nMimikatz Commands:\r\nhttps://adsecurity.org/?p=556\r\nPage 7 of 9\n\nlogonpasswords: mimikatz # sekurlsa::logonpasswords )\r\nExtracts passwords in memory\r\npth (pass the hash):\r\nmimikatz # sekurlsa::pth /user:Administrateur /domain:chocolate.local /ntlm:cc36cf7a8514893efccd33244615\r\nA fake identity is created and the faske identitt’s NTLM hash is replaced with the real one.\r\n“ntlm hash is mandatory on XP/2003/Vista/2008 and before 7/2008r2/8/2012 kb2871997 (AES not\r\navailable or replaceable)”\r\n“AES keys can be replaced only on 8.1/2012r2 or 7/2008r2/8/2012 with kb2871997, in this case\r\nyou can avoid ntlm hash.”\r\nptt (pass the ticket):\r\nmimikatz # kerberos::ptt\r\nEnables Kerberos ticket (TGT or TGS) injection into the current session.\r\ntickets:  mimikatz # sekurlsa::tickets /export\r\nIdentifies all session Kerberos tickets and lists/exports them.\r\nsekurlsa pulls the Kerberos data from memory and can access all user session tickets on the\r\ncomputer.\r\nekeys:  mimikatz # sekurlsa::ekeys\r\nExtract the Kerberos ekeys from memory. Provides theft of a user account until the password is\r\nchanged (which may be never for a Smartcard/PKI user).\r\ndpapi:  mimikatz # sekurlsa::dpapi\r\nminidump:\r\nmimikatz # sekurlsa::minidump lsass.dmp\r\nPerform a minidump of the LSASS process and extract credential data from the lsass.dmp. A\r\nminidump can be saved off the computer for credential extraction later, but the major version of\r\nWindows must match (you can’t open the dump file from Windows 2012 on a Windows 2008\r\nsystem).\r\nkerberos:\r\nmimikatz # sekurlsa::kerberos\r\nExtracts the smartcad/PIV PIN from memory (cached in LSASS when using a smartcard).\r\ndebug:\r\nmimikatz # privilege::debug\r\nhttps://adsecurity.org/?p=556\r\nPage 8 of 9\n\nSets debug mode for current mimikatz session enabling LSASS access.\r\nlsadump cache: (requires token::elevate to be SYSTEM)\r\nmimikatz # lsadump::cache\r\nDumps cached Windows domain credentials from HKEY_LOCAL_MACHINE\\SECURITY\\Cache\r\n(accessible SYSTEM).\r\nReferences:\r\nBenjamin Delpy’s blog (Google Translate English translated version)\r\nMimikatz GitHub repository\r\nMimikatz Github wiki\r\nMimikatz 2 Presentation Slides (Benjamin Delpy, July 2014)\r\nAll Mimikatz Presentation resources on blog.gentilkiwi.com\r\nExcel chart on OneDrive that shows what type of credential data is available in memory (LSASS),\r\nincluding on Windows 8.1 and Windows 2012 R2 which have enhanced protection mechanisms.\r\nPAC Validation issue aka the Silver Ticket description from the Passing the Hash Blog\r\n(Visited 86,224 times, 2 visits today)\r\nSean Metcalf\r\nI improve security for enterprises around the world working for TrustedSec \u0026 I am @PyroTek3 on Twitter.\r\nRead the About page (top left) for information about me. :)\r\nhttps://adsecurity.org/?page_id=8\r\nComments have been disabled.\r\nSource: https://adsecurity.org/?p=556\r\nhttps://adsecurity.org/?p=556\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://adsecurity.org/?p=556"
	],
	"report_names": [
		"?p=556"
	],
	"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": 1775434447,
	"ts_updated_at": 1775791398,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/89409a118d57f7e11d3feb116deec0992b4df5a8.pdf",
		"text": "https://archive.orkl.eu/89409a118d57f7e11d3feb116deec0992b4df5a8.txt",
		"img": "https://archive.orkl.eu/89409a118d57f7e11d3feb116deec0992b4df5a8.jpg"
	}
}