I've been seeing a series of Excel files recently that seem to be
triggering a bug of some kind.
These are not matched by any stock signatures (yet), so I've been using
clamscan --leave-temps to extract components for signatures.
Most of the time I just create hashes of a component from one sample
Excel file, and quickly confirm that all apparently related files in the
series are detected.
However, several sets have been causing grief in both creating a
matching signature at all, and in the test scan.
Just as an example, two recent files I submitted to virustotal.com:
904ccc07615ed320fe38252436e195f56edb0205bcf42ee90f22e2c45098bf33
04115742b211846e372301dce9bdc499fbb8749b194de81422a8e790bff055fa
Both have several extracted component files that are very similar or
identical:
6f48510eb90b6ad5186b4461f56266ae67d705a7fece8e56eca2c4296474eb19:219257:e3af082cc2ec644830a69ddafe5abe31_1
9ab4792a6626012a5238d383f1222c8d248c385e13c067731e6b98c9e0d87a4d:18025:xlm_macros.8ccda3bd23
However, clamscan -d test.hdb on one of these files produces a result
like this:
Invoice 251064533 QT8094914.xls:
e3af082cc2ec644830a69ddafe5abe31_1.UNOFFICIAL FOUND
Invoice 251064533 QT8094914.xls: OK
and a summary of "0 infected files".
clamscan --allmatch produces, not the pair of distinct matches I
expected, but:
Invoice 251064533 QT8094914.xls:
e3af082cc2ec644830a69ddafe5abe31_1.UNOFFICIAL FOUND
Invoice 251064533 QT8094914.xls:
e3af082cc2ec644830a69ddafe5abe31_1.UNOFFICIAL FOUND
Also, regular pattern signatures (created by a script I haven't modified
in a long time) from either the raw files or one or another of the
component files don't appear to match, even if I copy the component
files out of where --leave-temps drops them into an alternate working
directory. (I might be misremembering that last, I've tried a lot of
combinations of signature types, creation methods, and target files
before starting to write this.)
After chasing various parts of the files dropped by --leave-temps, I've
found a solution for one series (the ones I checked on virustotal) by
hand-constructing a pattern signature from the vba_project* file, but
not all of the broader set have macros or VBA in them.
"file" says that ole2-tmp*/e3af082cc2ec644830a69ddafe5abe31_1 file is
"Applesoft BASIC program data", but all I really care about is that it's
commonly invariant between apparently related .xls files, and has
historically been a good choice for a quick hash signature. It isn't on
this recent set of files.
xlm_macros.* has been identical within several sets of these files, but
none of the signatures seem to actually match it. I don't understand
enough about either the structure of Office document files or how ClamAV
breaks them down for scanning to have a good idea why.
-kgd
_______________________________________________
clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users
Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq
http://www.clamav.net/contact.html#ml
triggering a bug of some kind.
These are not matched by any stock signatures (yet), so I've been using
clamscan --leave-temps to extract components for signatures.
Most of the time I just create hashes of a component from one sample
Excel file, and quickly confirm that all apparently related files in the
series are detected.
However, several sets have been causing grief in both creating a
matching signature at all, and in the test scan.
Just as an example, two recent files I submitted to virustotal.com:
904ccc07615ed320fe38252436e195f56edb0205bcf42ee90f22e2c45098bf33
04115742b211846e372301dce9bdc499fbb8749b194de81422a8e790bff055fa
Both have several extracted component files that are very similar or
identical:
6f48510eb90b6ad5186b4461f56266ae67d705a7fece8e56eca2c4296474eb19:219257:e3af082cc2ec644830a69ddafe5abe31_1
9ab4792a6626012a5238d383f1222c8d248c385e13c067731e6b98c9e0d87a4d:18025:xlm_macros.8ccda3bd23
However, clamscan -d test.hdb on one of these files produces a result
like this:
Invoice 251064533 QT8094914.xls:
e3af082cc2ec644830a69ddafe5abe31_1.UNOFFICIAL FOUND
Invoice 251064533 QT8094914.xls: OK
and a summary of "0 infected files".
clamscan --allmatch produces, not the pair of distinct matches I
expected, but:
Invoice 251064533 QT8094914.xls:
e3af082cc2ec644830a69ddafe5abe31_1.UNOFFICIAL FOUND
Invoice 251064533 QT8094914.xls:
e3af082cc2ec644830a69ddafe5abe31_1.UNOFFICIAL FOUND
Also, regular pattern signatures (created by a script I haven't modified
in a long time) from either the raw files or one or another of the
component files don't appear to match, even if I copy the component
files out of where --leave-temps drops them into an alternate working
directory. (I might be misremembering that last, I've tried a lot of
combinations of signature types, creation methods, and target files
before starting to write this.)
After chasing various parts of the files dropped by --leave-temps, I've
found a solution for one series (the ones I checked on virustotal) by
hand-constructing a pattern signature from the vba_project* file, but
not all of the broader set have macros or VBA in them.
"file" says that ole2-tmp*/e3af082cc2ec644830a69ddafe5abe31_1 file is
"Applesoft BASIC program data", but all I really care about is that it's
commonly invariant between apparently related .xls files, and has
historically been a good choice for a quick hash signature. It isn't on
this recent set of files.
xlm_macros.* has been identical within several sets of these files, but
none of the signatures seem to actually match it. I don't understand
enough about either the structure of Office document files or how ClamAV
breaks them down for scanning to have a good idea why.
-kgd
_______________________________________________
clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users
Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq
http://www.clamav.net/contact.html#ml