{ "id": "5212914a-a8ff-4030-a622-ffa0a077d986", "created_at": "2026-04-06T01:29:07.934567Z", "updated_at": "2026-04-10T03:21:17.415057Z", "deleted_at": null, "sha1_hash": "ba87117f68c6ab9f9cf1f009375f36c4153acf91", "title": "Attackers Can Now Use Mimikatz to Implant Skeleton Key on Domain Controllers \u0026 BackDoor Your Active Directory Forest", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 359230, "plain_text": "Attackers Can Now Use Mimikatz to Implant Skeleton Key on\r\nDomain Controllers \u0026 BackDoor Your Active Directory Forest\r\nBy Sean Metcalf\r\nPublished: 2015-01-19 · Archived: 2026-04-06 01:09:29 UTC\r\nJan 19 2015\r\nBy Sean Metcalf in Microsoft Security, Technical Reference\r\nOnce an attacker has gained Domain Admin rights to your Active Directory environment, there are several\r\nmethods for keeping privileged access. Skeleton Key is an ideal persistence method for the modern attacker. More\r\ninformation on Skeleton Key is in my earlier post.\r\nNote that the behavior documented in this post was observed in a lab environment using the version of Mimikatz\r\nshown in the screenshot. There are likely differences in the Skeleton Key malware documented by Dell\r\nSecureWorks and the Mimikatz skeleton key functionality. Mimikatz effectively “patches” LSASS to enable use\r\nof a master password with any valid domain user. Rebooting the DC refreshes the memory which removes the\r\n“patch”.\r\nImplanting the Mimikatz Skeleton Key on one or multiple Domain Controllers:\r\nMimikatz can now inject a skeleton key into LSASS on the Domain Controller by running the following\r\ncommand on the DC:\r\nmimikatz.exe “privilege::debug” “misc::skeleton” exit\r\nhttp://adsecurity.org/?p=1275\r\nPage 1 of 7\n\nWhen there are multiple Domain Controllers in an Active Directory site, all of them need the Skeleton Key\r\nimplant to ensure the skeleton key master password is accepted as the user’s valid password.. Since the client\r\ndiscovers a Domain Controller using DCLocator, the DC the client selects is effectively random. If all the DCs\r\ndon’t have skeleton key configured, the master password won’t work when the client authenticates to a DC\r\nwithout skeleton key.\r\nScenario:\r\nEither the attacker exploits MS14-068 or has the KRBTGT NTLM password hash and uses it to generate a\r\nKerberos Golden Ticket to impersonate a valid Domain Admin account. The attacker leverages the forged\r\nKerberos TGT ticket to access the Domain Controllers via PowerShell remoting. PowerShell remoting runs over\r\nWinRM and provides a shell running on the remote computer (much like SSH). In this case, the attacker runs a\r\nPowerShell script that uses “invoke-command” to run the mimikatz command on the DCs.\r\nDomain Controller Security Events When Implanting the Mimikatz Skeleton Key:\r\nWhen implanting the skeleton key remotely using Mimikatz the following events are logged on the Domain\r\nController.\r\nEvent Id 4673 Sensitive Privilege Use,\r\nhttp://adsecurity.org/?p=1275\r\nPage 2 of 7\n\nEvent 4611: A trusted logon process has been registered with the Local Security Authority.\r\nIf Process Tracking (logging) is enabled, there are two events that are logged reliably.\r\nEvent 4688: A new process has been created.\r\nhttp://adsecurity.org/?p=1275\r\nPage 3 of 7\n\nEvent 4689: A new process has exited.\r\nAuthenticating with the Mimikatz Skeleton Key:\r\nhttp://adsecurity.org/?p=1275\r\nPage 4 of 7\n\nTesting user password and user account with skeleton key password.\r\nNote that both passwords are accepted – the valid user password and the skeleton key master password!\r\nTesting Domain Admin account with password \u0026 skeleton key password.\r\nNote that both passwords are accepted – the valid user password and the skeleton key master password!\r\n Skeleton Key Mitigation:\r\nProtect domain-level admin (DLA) accounts (Domain Admin, Administrators, etc) which reduces the risk\r\nof attackers gaining access to these credentials. Don’t let DLA accounts logon to systems at a different\r\nsecurity level from Domain Controllers. Don’t let services run as Domain Admin on member servers that\r\naren’t protected at the same level as DCs.\r\nEnable smart card authentication for all users.\r\nEnsure Domain Controllers have limited connectivity to the network until MS14-068 is patched\r\n(kb3011780). The challenge is that the patch has to be applied after DCPromo is complete.\r\nSecurity software that prevents LSASS patching may mitigate the issue.\r\nApplication whitelisting (ex. AppLocker) can prevent unapproved applications from running on Domain\r\nControllers.\r\nEnabling Process Logging on Domain Controllers provides additional data on what applications (exes) are\r\nexecuted on Domain Controllers.\r\nEnable LSASS as a protected process on Windows Server 2012 R2 (Mimikatz can bypass with a driver, but\r\nthat should make some noise in the event logs):\r\nhttp://adsecurity.org/?p=1275\r\nPage 5 of 7\n\nThe LSA, which includes the Local Security Authority Server Service (LSASS) process, validates users\r\nfor local and remote sign-ins and enforces local security policies. The Windows 8.1 operating system\r\nprovides additional protection for the LSA to prevent reading memory and code injection by non-protected processes. This provides added security for the credentials that the LSA stores and manages.\r\nTo enable LSA protection on a single computer\r\n1. Open the Registry Editor (RegEdit.exe), and navigate to the registry key that is located at:\r\nHKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa.\r\n2. Set the value of the registry key to: “RunAsPPL”=dword:00000001.\r\n3. Restart the computer.\r\nTo enable LSA protection using Group Policy\r\n1. Open the Group Policy Management Console (GPMC).\r\n2. Create a new GPO that is linked at the domain level or that is linked to the organizational unit\r\nthat contains your computer accounts. Or you can select a GPO that is already deployed.\r\n3. Right-click the GPO, and then click Edit to open the Group Policy Management Editor.\r\n4. Expand Computer Configuration, expand Preferences, and then expand Windows Settings.\r\n5. Right-click Registry, point to New, and then click Registry Item. The New Registry\r\nProperties dialog box appears.\r\n6. In the Hive list, click HKEY_LOCAL_MACHINE.\r\n7. In the Key Path list, browse to SYSTEM\\CurrentControlSet\\Control\\Lsa.\r\n8. In the Value name box, type RunAsPPL.\r\n9. In the Value type box, click the REG_DWORD.\r\n10. In the Value data box, type 00000001.\r\n11. Click OK.\r\n Mimikatz bypassing LSA Protection:\r\nhttp://adsecurity.org/?p=1275\r\nPage 6 of 7\n\n(Visited 22,640 times, 1 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\nSource: http://adsecurity.org/?p=1275\r\nhttp://adsecurity.org/?p=1275\r\nPage 7 of 7\n\n http://adsecurity.org/?p=1275 \nEvent 4611: A trusted logon process has been registered with the Local Security Authority.\nIf Process Tracking (logging) is enabled, there are two events that are logged reliably.\nEvent 4688: A new process has been created. \n Page 3 of 7", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "http://adsecurity.org/?p=1275" ], "report_names": [ "?p=1275" ], "threat_actors": [], "ts_created_at": 1775438947, "ts_updated_at": 1775791277, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/ba87117f68c6ab9f9cf1f009375f36c4153acf91.pdf", "text": "https://archive.orkl.eu/ba87117f68c6ab9f9cf1f009375f36c4153acf91.txt", "img": "https://archive.orkl.eu/ba87117f68c6ab9f9cf1f009375f36c4153acf91.jpg" } }