TimeRoasting

Reading time: 4 minutes

timeRoasting, the main cause is the outdated authentication mechanism left by Microsoft in its extension to NTP servers, known as MS-SNTP. In this mechanism, clients can directly use any computer account's Relative Identifier (RID), and the domain controller will use the computer account's NTLM hash (generated by MD4) as the key to generate the Message Authentication Code (MAC) of the response packet.

Attackers can exploit this mechanism to obtain equivalent hash values of arbitrary computer accounts without authentication. Clearly, we can use tools like Hashcat for brute-forcing.

The specific mechanism can be viewed in section 3.1.5.1 "Authentication Request Behavior" of the official Windows documentation for MS-SNTP protocol.

In the document, section 3.1.5.1 covers Authentication Request Behavior. It can be seen that when the ExtendedAuthenticatorSupported ADM element is set to false, the original Markdown format is retained.

Quoted in the original article：

If the ExtendedAuthenticatorSupported ADM element is false, the client MUST construct a Client NTP Request message. The Client NTP Request message length is 68 bytes. The client sets the Authenticator field of the Client NTP Request message as described in section 2.2.1, writing the least significant 31 bits of the RID value into the least significant 31 bits of the Key Identifier subfield of the authenticator, and then writing the Key Selector value into the most significant bit of the Key Identifier subfield.

In document section 4 Protocol Examples point 3

Quoted in the original article：

3. After receiving the request, the server verifies that the received message size is 68 bytes. If it is not, the server either drops the request (if the message size does not equal 48 bytes) or treats it as an unauthenticated request (if the message size is 48 bytes). Assuming that the received message size is 68 bytes, the server extracts the RID from the received message. The server uses it to call the NetrLogonComputeServerDigest method (as specified in [MS-NRPC] section 3.5.4.8.2) to compute the crypto-checksums and select the crypto-checksum based on the most significant bit of the Key Identifier subfield from the received message, as specified in section 3.2.5. The server then sends a response to the client, setting the Key Identifier field to 0 and the Crypto-Checksum field to the computed crypto-checksum.

According to the description in the Microsoft official document above, users do not need any authentication; they only need to fill in the RID to initiate a request, and then they can obtain the cryptographic checksum. The cryptographic checksum is explained in section 3.2.5.1.1 of the document.

Quoted in the original article：

The server retrieves the RID from the least significant 31 bits of the Key Identifier subfield of the Authenticator field of the Client NTP Request message. The server uses the NetrLogonComputeServerDigest method (as specified in [MS-NRPC] section 3.5.4.8.2) to compute crypto-checksums with the following input parameters:

The cryptographic checksum is calculated using MD5, and the specific process can be referred to in the content of the document. This gives us the opportunity to perform a roasting attack.

how to attack

Quote to https://swisskyrepo.github.io/InternalAllTheThings/active-directory/ad-roasting-timeroasting/

SecuraBV/Timeroast - Timeroasting scripts by Tom Tervoort

sudo ./timeroast.py 10.0.0.42 | tee ntp-hashes.txt
hashcat -m 31300 ntp-hashes.txt