Is your request based on a publicly known cryptographic schema and where can we find information about?

Yes. The request concerns a legacy type of password-based cryptographic MAC (the Server NTP Response "Crypto-Checksum") that Active Directory domain controllers can be forced to use to authenticate NTP responses. The scheme is specified in [MS-SNTP] section 3.2.5.1.1, which refers to the definition from section 3.5.4.8.2 of [MS-NRPC].

Describe alternatives you've considered

The scheme uses the simple composition MD5(MD4(UTF-16LE(password)) || NTP-response) where NTP-response is exactly 48 bytes long. I initially tried to specify this as a dynamic hash format in John the Ripper, where the NTP response was treated as a salt. Unfortunately 48 bytes exceeded the maximal salt length, so this was not possible.

Provide an example hash/database/file and a known correct password

Hash: 55265c2d9510284b3ad62ab7d5cae532
Salt: 1c0111e900000000000a24124c4f434ce6e13d4de4200050e1b8428bffbfcd0ae6e16cdc7817804fe6e16cdc7817f412
Password: legacycomp1

Explain how the cryptographic schema is implemented

An NTLM hash of the password is concatenated with the salt (actually an NTP response message) and then hashed using MD5. A Python implementation is as follows:

import hashlib

def compute_hash(password, salt):
  return hashlib.md5(hashlib.new('md4', password.encode('utf-16le')).digest() + salt).digest()

Describe the known limitations of the algorithm

The salt should be exactly 48 bytes long.

Where do you typically find the algorithm

The algorithm is used by Windows Active Directory domain controllers in order to authenticate NTP responses.

Additional context

This hash type would be very useful for exploiting a "Timeroasting" attack, a technique a discovered that allows an unauthenticated attacker to effectively extract hashes of all the computer account passwords in the domain.

This sound a bit useless, since computer accounts are set to long random strings by default. However, there turn out to be a variety of situations in which this is not the case, and the computer password is instead identical to the computer name, or has been manually changed to a value chosen by a sysadmin. In those cases offline brute-force and dictionary attacks become viable. An advantage of "timeroasting" over regular Kerberoasting (which is also possible against computer account passwords) is that it is (still) more stealthy and does not require any AD user account.

I implemented a Timeroasting script, as well as a highly inefficient dictionary-based cracking tool that can be found here.

Note: when doing a Timeroasting with a fixed reference time in the NTP request (as my script does), the responses will share an identical prefix of about +/- 20 bytes. Therefore it can be expected that most or all salts in the hash file will share a prefix. Some per-password precomputation may be possible to reduce the amount of work that has to be performed per hash.