My previous blog post “Analyzing ClamAV Signatures” is incorrect. Here is a better explanation.
I wrongly assumed that the signature printed in the debug statement would be the actual signature in the ClamAV database. That is not always the case.
So here is a better method.
First I update the signatures (yup, that’s ClamAV on Windows):
This is a standard scan:
The signature is Win.Trojan.Mimikatz-6331391-0.
Then I do a search with sigtool in the database, providing a regular expression (Mimikatz-6331391) to match signature names (this matching process is case sensitive):
And this signature is more interesting. This is an extended signature. It is composed of several fields (: is the separator). Here I have each field on a separate line:
Field 1 is the name of the signature.
Field 2 is the type of file to scan: 1 is for PE files
Field 3 is the part of the file to scan: SE1 is the second section of the PE file.
Field 4 is the hex signature: the sequence of bytes to search for in the section, expressed as hexadecimal data. {-10} is a wildcard for 0 to 10 arbitrary bytes.
Field 5 is the minimum version of the ClamAV engine that supports this type of signature.
The bytes represent strings (UNICODE and ASCII):
This signature does not trigger on the genuine mimikatz binaries:
Didier Stevens 
[…] He shows how to determine which signature ClamAv uses to detect Mimikatz and then manually decode it Analyzing ClamAV Signatures – Correction […]
Pingback by Week 28 – 2017 – This Week In 4n6 — Sunday 16 July 2017 @ 0:15
[…] Analyzing ClamAV Signatures – Correction […]
Pingback by Overview of Content Published In July | Didier Stevens — Tuesday 1 August 2017 @ 21:52