{
	"id": "6b9046db-1904-40d1-bf30-c371aa5d0995",
	"created_at": "2026-04-06T00:10:33.371204Z",
	"updated_at": "2026-04-10T03:20:51.189763Z",
	"deleted_at": null,
	"sha1_hash": "3e96960bfe2fc2366db1023bdd2da78d05d7c24a",
	"title": "Mimikatz and DCSync and ExtraSids, Oh My",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2143162,
	"plain_text": "Mimikatz and DCSync and ExtraSids, Oh My\r\nPublished: 2015-09-22 · Archived: 2026-04-05 13:38:09 UTC\r\nEdit: Benjamin reached out and corrected me on a few points, which I’ve updated throughout the post.\r\nImportantly, with the ExtraSids (/sids) for the injected Golden Ticket, you need to specify S-1-5-21domain-516\r\n(“Domain Controllers”) and S-1-5-9 (“Enterprise Domain Controllers”), as well as the SECONDARY$ domain\r\ncontroller SID in order to properly slip by some of the event logging.\r\nBenjamin Delpy is constantly adding new features to Mimikatz. In June, he added the ability to include ExtraSids\r\nin golden tickets. This was built in coordination with Sean Metcalf‘s work on the subject, and something I talked\r\nabout here.\r\nBenjamin and Vincent Le Toux also recently added the ability to abuse the MS-DRSR protocol for domain\r\ncontroller replication, in order to recover hashes from a DC without code execution. I touched on this briefly in\r\nthe post detailing Empire’s v1.2 release (and in a demonstration video) but I wanted to revisit the subject and\r\nshow how these two new features can be combined into a single attack chain. If you’re interested in Active\r\nDirectory attacks, be sure to check out Sean’s “Red vs. Blue: Modern Active Directory Attacks \u0026 Defense” talk at\r\nDerbycon, Friday at 3:00pm. I hear he’ll be dropping some interesting information applicable to this post :)\r\nSidenote: if you want to compile the newest version of Mimikatz for PowerSploit’s Invoke-Mimikatz, just grab\r\nBenjamin’s source code, open it up in Visual Studio, select the “Second_Release_PowerShell” target option and\r\ncompile for both Win32 and x64.\r\nThen transform the resulting powerkatz.dlls to a base64 string using base64 -w 0 powerkatz.dll in Linux. You\r\ncan now replace the $PEBytes32 and $PEBytes64 strings at the bottom of Invoke-Mimikatz.ps1. Empire keeps a\r\nseparately updated version of Invoke-Mimikatz with a few additional tweaks.\r\nScenario\r\nLet’s say you’re operating in the following example network:\r\nhttps://blog.harmj0y.net/redteaming/mimikatz-and-dcsync-and-extrasids-oh-my/\r\nPage 1 of 13\n\nYou land on a machine in the dev.testlab.local domain, and there is tight network filtering from here to the others\r\nin the forest; i.e. you can talk to your SECONDARY.dev.testlab.local domain controller but to few machines in\r\nother domains. We’ve seen this setup a few times in the field, where an organization keeps the forest root\r\nrelatively ‘sparse’ and keeps less trusted subsidiaries/groups in a segmented domain.\r\nAfter some user-hunting and some lateral spread, you end up on workstation WINDOWS3 with domain\r\nadministrator credentials for dev.testlab.local. From this point historically, you would often compromise/exfil the\r\nNTDS.dit of one of DEV’s domain controllers, and then start the process of hopping through the trust mesh. While\r\nwe were usually successful in cross-domain compromise, this process often took a good a good bit of time and\r\neffort. Let’s see how we can use some of these new school techniques to speed up the process.\r\nStep 1: Enumerate the Forest\r\nFirst let’s do a bit of network and domain situationalf awareness. We can enumerate the current trusts in the forest\r\nin a few different ways- my preference is to use PowerView 2.0 and run Get-NetForestDomain or Invoke-MapDomainTrust -LDAP to recursively map all trust relationships in the forest:\r\nhttps://blog.harmj0y.net/redteaming/mimikatz-and-dcsync-and-extrasids-oh-my/\r\nPage 2 of 13\n\nThis is also possible through Empire with the situational_awareness/network/mapdomaintrusts module.\r\nStep 2: DCSync the Child\r\nNow let’s extract the krbtgt account hash from a dev.testlab.local domain controller. Instead of having to install\r\nan agent, we can now use Mimikatz’ DCSync to extract the hash. One thing to note is that you need to specify\r\n“\u003cNT4_DOMAINNAME\u003e\\krbtgt” for the specified user for this to work properly (you can find the domain\r\nshortname easily with whoami or other methods). In this case we’re using DEV.\r\nhttps://blog.harmj0y.net/redteaming/mimikatz-and-dcsync-and-extrasids-oh-my/\r\nPage 3 of 13\n\nHere’s how it looks in our environment with Invoke-Mimikatz. Note that you need to use -Command\r\n‘”COMMAND”‘ when running any custom commands through Invoke-Mimikatz (double quotes embedded in\r\nsingle quotes):\r\nAnd here’s how we can execute the same functionality through Empire:\r\nhttps://blog.harmj0y.net/redteaming/mimikatz-and-dcsync-and-extrasids-oh-my/\r\nPage 4 of 13\n\nOne nice note- Empire will now parse the DCSync output and save the output into the credential store:\r\nStep 3: ExtraSids to Hop up the Trust\r\nNow let’s use this compromised child DC krbtgt hash to compromise the forest root (and therefore the\r\nentire forest). The demo video showed doing this straight from the same original workstation, but in our scenario\r\nwe run into a problem: we can’t talk directly to the domain controller for the testlab.local root. Happily for us,\r\ndomain controllers in a forest have to be able to talk to each other for replication and shared authentication, so at a\r\nminimum in our scenario, the DC for dev.testlab.local will have communication open to a DC in testlab.local.\r\nTo hop up the trust, we need a few pieces of information:\r\nthe krbtgt hash for the child domain (dev.testlab.local), which we just extracted with DCSync\r\nhttps://blog.harmj0y.net/redteaming/mimikatz-and-dcsync-and-extrasids-oh-my/\r\nPage 5 of 13\n\nthe SID for dev.testlab.local, also in the DCSync output\r\nthe name of the target DEV user for the ticket\r\nIn this case it’s going to be SECONDARY$, the name of DEV’s domain controller machine\r\naccount. More on this shortly.\r\nthe fully qualified domain name of the forest root (in our PowerView output)\r\nthe SID of the “Enterprise Admins” group of the root\r\nedit: the SID of the “Domain Controllers” group (S-1-5-21domain-516), the SID of “Enterprise Domain\r\nControllers” (S-1-5-9), and the SID of the SECONDARY$ domain controller (which you can get with ‘Get-NetComputer SECONDARY.dev.testlab.local’ from PowerView), in this case S-1-5-21-4275052721-\r\n3205085442-2770241942-1002.\r\nTo get the FQDN of the forest root, we could use PowerView with Get-NetForestDomain or Get-NetDomainTrust, or the following one-liner:\r\n([System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest())[0].RootDomain.Name\r\nThen we need the SID of the forest root. I’m sure there are better ways to do this, but one easy one is to resolve\r\nthe ‘krbtgt’ account for the domain:\r\n(New-Object System.Security.Principal.NTAccount(\"testlab.local\",\"krbtgt\")).Translate([System.Security\r\nThen we just replace the -502 in the SID with -519 to get our Enterprise Admins SID for testlab.local (in this\r\ncase S-1-5-21-456218688-4216621462-1491369290-519) edit: with the -516 “Domain Controllers” SID (in this\r\ncase S-1-5-21-456218688-4216621462-1491369290-516). The Mimikatz command we’re going to ultimately use\r\nto build our trust-hopping ticket is:\r\nkerberos::golden /user:SECONDARY$ /krbtgt:8b7c904343e530c4f81c53e8f614caf7 /domain:dev.testlab.local\r\nEdit: kerberos::golden /user:SECONDARY$ /krbtgt:8b7c904343e530c4f81c53e8f614caf7 /domain:dev.testlab\r\nSo we have a few options here. We could use Empire to WMI to the DC for dev.testlab.local and then run the\r\ncredentials/mimikatz/golden_ticket module with the necessary information. For the Golden Ticket creation, we\r\ncan use the saved krbtgt hash from the DCSync output, setting CredID to 1, the user to SECONDARY$, and the\r\nsids to S-1-5-21-456218688-4216621462-1491369290-519 edit: S-1-5-21-456218688-4216621462-1491369290-\r\n516,S-1-5-9:\r\nhttps://blog.harmj0y.net/redteaming/mimikatz-and-dcsync-and-extrasids-oh-my/\r\nPage 6 of 13\n\nWe could also RDP to the DEV domain controller, use a download cradle to load up Mimikatz, and run our\r\nspecified command. In either case, we now have administrator access to the domain controller (PRIMARY) for\r\nthe testlab.local forest root!\r\nStep 4: DCSync the Forest Root\r\nWe now have all the privileges needed to compromise the krbtgt hash of the forest root. This time our command\r\nwill be a bit more complex. One thing we need is the domain NT4 shortname of the forest root. You can use this\r\nGist, or you can translate the username to a SID and back again. In our case, the shortname is TESTLAB.\r\nHere is the command we’ll be using:\r\nhttps://blog.harmj0y.net/redteaming/mimikatz-and-dcsync-and-extrasids-oh-my/\r\nPage 7 of 13\n\nlsadump::dcsync /user:TESTLAB\\krbtgt /domain:testlab.local\r\nIf testlab.local had multiple domain controllers and we wanted to specify a particular one, we could use the\r\n/dc:DC.FQDN flag as well. This is how it looks through Empire:\r\nIf we want a single Invoke-Mimikatz command to build/inject the Golden Ticket, DCSync the root, and then\r\npurge current tickets from the session, we can do that by space separating the double quoted Mimikatz commands:\r\nInvoke-Mimikatz -Command '\"kerberos::golden /user:SECONDARY$ /krbtgt:8b7c904343e530c4f81c53e8f614caf7\r\nedit: Invoke-Mimikatz -Command '\"kerberos::golden /user:SECONDARY$ /krbtgt:8b7c904343e530c4f81c53e8f6\r\nAnd if the SECONDARY domain controller allows PSRemoting, we don’t even have to RDP, and can perform the\r\nentire attack chain from our WINDOWS3 workstation! Because we’re constructing and injecting a new TGT, we\r\ndon’t have to worry about the Kerberos double-hop problem:\r\nhttps://blog.harmj0y.net/redteaming/mimikatz-and-dcsync-and-extrasids-oh-my/\r\nPage 8 of 13\n\nInvoke-Mimikatz -Command '\"kerberos::golden /user:SECONDARY$ /krbtgt:8b7c904343e530c4f81c53e8f614caf7\r\nedit: Invoke-Mimikatz -Command '\"kerberos::golden /user:SECONDARY$ /krbtgt:8b7c904343e530c4f81c53e8f6\r\nhttps://blog.harmj0y.net/redteaming/mimikatz-and-dcsync-and-extrasids-oh-my/\r\nPage 9 of 13\n\nNow why did we use the SECONDARY$ account (the domain controller for the child) when building our ticket,\r\nas opposed to a normal *-500 Administrator account? edit: And why use the “Domain Controllers” and\r\nhttps://blog.harmj0y.net/redteaming/mimikatz-and-dcsync-and-extrasids-oh-my/\r\nPage 10 of 13\n\n“Enterprise Domain Controllers” SIDs when creating the ticket? @gentilkiwi explains in the following tweets:\r\nDuring the execution of our first DCSync, we had to use our current dev.testlab.local Domain Admin credentials,\r\nwhich causes log entries as Delpy describes above. Once we gain the krbtgt hash of the DEV domain controller\r\n(through DCSync or other methods), we can be sneakier in attacking the forest root. If we create our Golden\r\nTicket (as we did above) such that the user account in the PAC is the machine account of the DC we’re currently\r\noperating from (in our case SECONDARY$), but the ExtraSids contains the “Enterprise Admins” SID for the\r\nforest root edit: the Domain Controllers SID for the forest root and the “Enterprise Domain Controllers” SID, we\r\nhttps://blog.harmj0y.net/redteaming/mimikatz-and-dcsync-and-extrasids-oh-my/\r\nPage 11 of 13\n\nshould be able to DCSync the krbtgt hash of the root without creating additional logs! This is something others\r\nhave already started to touch on.\r\nEdit: because /id defaults to domain-500, the /user and /id for this ticket won’t match, meaning it will only work\r\nfor 20 minutes. This is all the time we need, but if you would like it to last longer, you can enumerate the full SID\r\nof the SECONDARY.dev.testlab.local domain controller and set that for the /id argument. Note: I haven’t tested\r\nthis thoroughly as far as log generation, so if the described behavior isn’t accurate, please let me know and I will\r\ncorrect the description.\r\nWrapup\r\nAt this point, with the krbtgt hash of the forest root, we can build Golden Tickets on demand to compromise any\r\nmachine in the testlab.local forest. By taking advantage of Mimikatz’ new features and Sean’s new work, we can\r\nquickly and easily turn the compromise of any domain administrator credentials in the forest into a total forest\r\ncompromise. One interesting defensive note (that reiterates Microsoft’s description that the domain is not a trust\r\nboundary): it’s not sufficient to change all domain passwords and roll the krbtgt account hash of just the root\r\ndomain (or the compromised domain), you need to roll the krbtgt hash for ALL domains in the forest. Or just:\r\nhttps://blog.harmj0y.net/redteaming/mimikatz-and-dcsync-and-extrasids-oh-my/\r\nPage 12 of 13\n\nSource: https://blog.harmj0y.net/redteaming/mimikatz-and-dcsync-and-extrasids-oh-my/\r\nhttps://blog.harmj0y.net/redteaming/mimikatz-and-dcsync-and-extrasids-oh-my/\r\nPage 13 of 13\n\n  https://blog.harmj0y.net/redteaming/mimikatz-and-dcsync-and-extrasids-oh-my/     \nNow why did we use the SECONDARY$ account (the domain controller for the child) when building our ticket,\nas opposed to a normal *-500 Administrator account? edit: And why use the “Domain Controllers” and\n   Page 10 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://blog.harmj0y.net/redteaming/mimikatz-and-dcsync-and-extrasids-oh-my/"
	],
	"report_names": [
		"mimikatz-and-dcsync-and-extrasids-oh-my"
	],
	"threat_actors": [],
	"ts_created_at": 1775434233,
	"ts_updated_at": 1775791251,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/3e96960bfe2fc2366db1023bdd2da78d05d7c24a.pdf",
		"text": "https://archive.orkl.eu/3e96960bfe2fc2366db1023bdd2da78d05d7c24a.txt",
		"img": "https://archive.orkl.eu/3e96960bfe2fc2366db1023bdd2da78d05d7c24a.jpg"
	}
}