lsadump::sam fails to parse legacy 16-byte NTLM hash (Missing SAM_HASH header) on Win10 22H2

I encountered Unknow SAM_HASH revision errors while using lsadump::sam on a Windows 10 22H2 (10.0.19045.6466) environment.

Error Logs: ERROR kuhl_m_lsadump_getHash ; Unknow SAM_HASH revision (26408) ** LMHash ERROR kuhl_m_lsadump_getHash ;Unknow SAM_HASH revision (3250) **NTLMHash

The problem was identified as follows: The NTLM hash length in the V value is exactly 16 bytes. Mimikatz expects a SAM_HASH header (Revision 1 or 2), but in this case, the header is missing, and the first 4 bytes of the encrypted data are being misinterpreted as the Revision

The 16-byte data stored in the SAM hive is verified to be $DES(NTHash, k1) + DES(NTHash, k2)$ (Level 2 encryption), as described in Fig. 3 of the Oprea paper (https://acad.ro/sectii2002/proceedings/doc2013-3s/05-OPREA.pdf).

Standard behavior (even on XP/Win7/Win10 1507) usually stores a 20-byte structure: PEKID (2 bytes) + Revision (2 bytes) + Encrypted Hash (16 bytes). Could Mimikatz be updated to handle cases where the hash length is exactly 16 bytes? I am happy to provide more hex dumps if needed for verification. Thanks a lot!

Actual NTLMHash: 607DED595AD323520B6D188ECC9E5437 RID: 000001f4 (Administrator) Raw data in SAM: 4073B20C81FCC8A92393134006097A08