Timeroasting: Abusing NTP Authentication in Active Directory

Timeroasting: Abusing NTP Authentication in Active Directory - article cover image Active Directory
Time it takes to read this article 7 minutes.

Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.

Introduction

Timeroasting is an offline password-cracking technique that abuses the way Windows domain controllers authenticate NTP time responses to computers. Disclosed by Tom Tervoort of Secura, it exploits MS-SNTP — Microsoft’s authenticated Network Time Protocol extension — to extract a crackable representation of a computer account’s password hash from a domain controller without any authentication at all. Where Kerberoasting needs a valid domain credential, Timeroasting needs only the ability to send UDP packets to the DC’s time service.

The technique is notable for two reasons. First, it is fully pre-authentication: an attacker on the network — no domain account, no foothold — can harvest hashes for every machine account by iterating over RIDs. Second, it doubles as an unauthenticated RID enumeration primitive, because the DC only produces a valid response for RIDs that map to real accounts. A closely related variant, sometimes called Trustroasting, targets inter-domain trust accounts the same way. Because it relies on a documented protocol behavior rather than a bug, there is no CVE to patch — it is a design property to be mitigated, not a vulnerability to fix.

Attack Prerequisites

Timeroasting’s requirements are strikingly low, which is exactly why it matters:

  • Network reachability to a domain controller’s NTP service on UDP/123. No credentials of any kind are required.
  • Knowledge (or brute-forcing) of account RIDs — the relative identifier portion of a computer or trust account’s SID. RIDs are small integers you can simply iterate.
  • Offline cracking resources to attack the recovered material, plus a realistic hope that *some* targeted account has a weak or predictable password.
  • For maximum value: targets whose passwords are not the default random 120-character machine secret — e.g. manually reset computer accounts, appliances, or trust accounts.

How It Works

Standard NTP has an optional authentication field, and Microsoft repurposed it in MS-SNTP so that domain-joined clients can verify a time response really came from their DC. When a Windows client requests time with authentication, it places the RID of its own computer account into the request’s key identifier. The DC looks up that account’s password hash, computes a message authenticator over the NTP response, and returns it. The client, which knows its own hash, recomputes the same value to confirm authenticity.

The authenticator is computed as a hash over the NT hash (the MD4 of the account password) concatenated with the NTP response bytes. Crucially, the DC will perform this computation for any RID an *unauthenticated* requester specifies — it does not verify that the caller actually owns that account. So an attacker sends a crafted authenticated NTP request naming, say, RID 1103, and the DC returns a response plus an authenticator that is a cryptographic function of RID 1103’s password hash and known plaintext (the response the attacker just received). That is a classic offline-crackable structure: known message, unknown key, published algorithm.

Two consequences fall out. First, the attacker can iterate RIDs and, for each real account, collect a hash to crack offline — no login, no lockout, no Event 4768/4771 authentication failures. Second, because the DC only returns a meaningful authenticator for RIDs that resolve to accounts, the *presence or absence* of a response leaks which RIDs exist, giving unauthenticated enumeration of computer and trust accounts. The economics favor the attacker: machine-account passwords are normally random and uncrackable, but the harvesting is free and silent, so any account whose password was manually set, never rotated, or belongs to a non-Windows device becomes a realistic crack.

Vulnerable Code / Configuration

There is no misconfigured file to point at — the behavior is the DC’s default MS-SNTP handling. What varies is *which accounts are actually crackable*, and that comes down to password hygiene on machine and trust accounts. The conceptual authenticator computation the DC performs is:

# Conceptual MS-SNTP authenticator (what the DC returns for a given RID):
#   crypto_checksum = HASH( NT_hash(account_password) || ntp_response_bytes )
#
# Attacker knows: the RID they chose, and the ntp_response_bytes returned.
# Attacker does NOT know: NT_hash(account_password)  <- the crack target.
#
# The DC computes this for ANY requested RID, without authenticating the caller.
TEXT

Accounts that should be safe (random machine secrets) versus accounts that are exposed (manually set / stale) look like this in the directory. Stale computer accounts with old pwdLastSet values and trust accounts are the interesting harvest:

# Machine accounts whose password has not rotated recently (rotation = 30 days by default)
Get-ADComputer -Filter * -Properties pwdLastSet, PasswordLastSet |
  Where-Object { $_.PasswordLastSet -lt (Get-Date).AddDays(-90) } |
  Select Name, PasswordLastSet

# Interdomain trust accounts (targets of 'Trustroasting'); RID -> account mapping
Get-ADObject -Filter { objectClass -eq 'trustedDomain' } -Properties trustPartner
PowerShell

The registry value that governs whether the DC even *rotates* machine passwords (and thus whether stale hashes linger) is client-side, but the DC-side takeaway is that disabling the authenticated-NTP response path is not generally supported without breaking time authentication — which is why mitigation focuses on password strength and network exposure:

# Client-side machine password rotation control (context, not an exploit primitive):
HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
  DisablePasswordChange = 0   # if set to 1, machine password never rotates -> stale, crackable
  MaximumPasswordAge    = 30  # default rotation window in days
TEXT

Walkthrough / Exploitation

Secura published a reference implementation, timeroast.py (SecuraBV/Timeroast), that sends the crafted authenticated NTP requests, iterates RIDs, and emits the recovered hashes in a format ready for offline cracking. The core run needs nothing but the DC address:

# Harvest MS-SNTP authenticators for a range of RIDs from the DC (no creds)
python3 timeroast.py 10.0.0.10 -o timeroast_hashes.txt

# Narrow or widen the RID sweep as needed:
python3 timeroast.py 10.0.0.10 --rids 1000-5000 -o timeroast_hashes.txt
Bash

Each output line ties a RID to a crackable authenticator. Resolve interesting RIDs back to account names once you have *any* read access, or infer them from the enumeration itself. The repository ships a companion cracker, and the hash format is designed to be fed to a standard offline cracker with a wordlist or mask:

# Crack with the bundled companion script (pure Python) against a wordlist
python3 timecrack.py timeroast_hashes.txt wordlist.txt

# The hashes are structured for offline attack: known message, unknown NT-hash key.
# Focus effort on non-random passwords (appliances, manually reset machine accounts).
Bash

The enumeration side effect is valuable on its own. Because only real RIDs yield authenticators, sweeping the RID space maps the domain’s computer and trust accounts with no credentials — useful reconnaissance that precedes noisier authenticated techniques:

# Use the RID sweep purely to enumerate which accounts exist (unauthenticated recon)
python3 timeroast.py 10.0.0.10 --rids 1000-20000 -o /dev/stdout | \
  awk -F: '{print "RID present:", $1}'
Bash

The chain is opportunistic but real. A cracked trust account password enables forging inter-realm tickets across the trust; a cracked computer account can be leveraged for Resource-Based Constrained Delegation (RBCD) or as a stepping stone; and even the enumeration alone feeds targeted password spraying and Kerberoasting once a foothold is obtained. Timeroasting rarely ends an engagement by itself, but it is a quiet, credential-free opening move.

Note: Realistic expectations matter: default Windows machine-account passwords are 120-ish characters of randomness and rotate every 30 days, so they are effectively uncrackable. Timeroasting pays off against the *exceptions* — accounts with DisablePasswordChange=1, non-Windows devices that set their own weak machine secret, decommissioned-but-not-deleted computers, and trust accounts. Do not expect to crack a healthy domain’s workstations; do expect to find the neglected corners.

Opsec: Timeroasting is exceptionally quiet. It generates no Kerberos pre-auth failures, no account lockouts, and no logon events, because it never authenticates. The footprint is unusual NTP traffic — a burst of authenticated MS-SNTP requests cycling through RIDs from one source — which most environments do not monitor at all. That stealth is the technique’s real advantage over roasting methods that touch the KDC.

Detection and Defense

Because the behavior is by design, defense is about password strength, exposure reduction, and NTP-layer monitoring:

  • Ensure machine-account passwords rotate — do not set DisablePasswordChange=1; keep the default 30-day rotation so hashes never become stable crack targets.
  • Give non-Windows and appliance machine accounts strong, random passwords, since these are the accounts most likely to have weak, human-set secrets.
  • Harden and rotate trust account passwords and audit trusts; a cracked trust key enables cross-realm ticket forgery.
  • Restrict NTP exposure — only domain members need the DC’s authenticated time service, so limit UDP/123 to expected client ranges at the firewall and watch for RID-cycling NTP request bursts from a single source.
  • Baseline NTP traffic and alert on high-volume authenticated SNTP requests iterating key identifiers, which is the signature of a RID sweep.
  • Delete stale computer and trust accounts promptly; decommissioned objects with old passwords are prime harvest targets.

Real-World Impact

Timeroasting reframed a decade-old, obscure MS-SNTP behavior as a practical, credential-free harvesting technique, and it filled a real gap in the offensive toolkit: a way to collect account hashes and enumerate machines *before* obtaining any domain credential. In practice its impact is concentrated on the accounts organizations forget — legacy devices, appliances that join the domain with weak secrets, and long-lived trust accounts — but because harvesting is silent and unauthenticated, it costs an attacker almost nothing to try on every engagement. Its recognition also drove renewed attention to machine-account password hygiene and trust management, areas that had long been assumed ‘safe by default.’

Conclusion

Timeroasting is a reminder that authentication protocols bolted onto legacy services can leak more than intended. By answering authenticated-time requests for any RID an unauthenticated caller names, a domain controller hands out offline-crackable material for its machine and trust accounts and confirms which accounts exist — all without a single logon event. The defenses are unglamorous but effective: rotate machine passwords, give appliances and trusts strong secrets, prune stale accounts, and watch the NTP layer you probably are not watching today. Do that, and Timeroasting collects nothing but noise.

You Might Also Like

If you found this useful, these related deep-dives cover adjacent techniques and their defenses:

Comments

Copied title and URL