Well, in this case ClamAV supports YARA enough to get: ~/tmp$ clamscan -d keymarble.yara keymarble-dummy keymarble-dummy: YARA.rsa_modulus.UNOFFICIAL FOUND
----------- SCAN SUMMARY ----------- Known viruses: 1 Engine version: 0.100.0 Scanned directories: 0 Scanned files: 1 Infected files: 1 Data scanned: 0.00 MB Data read: 0.00 MB (ratio 0.00:1) Time: 0.006 sec (0 m 0 s) The question is whether one should copy keymarble.yara to /var/lib/clamav/, on a production server where ClamAV is used to scan email. It is useless if ClamAV catches keymarble already. It is also useless/harmful if $n is a bogus string. More basic question: Is ClamAV staff monitoring US-CERT's alerts, and updating ClamAV database on good rules? I'd also appreciate generic opinions about US-CERT. I'm not a careful analyst, so maybe I'm wrong, but it seems to me they are getting weaker and weaker, since about 2013, when they changed alert message format (introducing html and dropping pgp). For example, last year's TA17-293A[*] would have blocked any file containing the string "icon.png"... Best Ale -- [*] https://www.us-cert.gov/ncas/alerts/TA17-293A On Sat 11/Aug/2018 03:17:33 +0200 Al Varnell wrote: > I'm not sure how widely Yara is being used in current A-V scanning, but I > would have to guess it's not fully implemented by many. I am aware that the > current ClamAV scanner does not handle all the latest features and there are > only UNOFFICIAL rule available, so the scanner on VirusTotal would not be > expected to detect your dummy since it only uses official signatures. > > There may also be an issue with the file type. ClamAV first does a check for > file type before applying signature matches, so it would probably be looking > for a PE file which your dummy does not appear to be. Other scanners probably > do something similar. > > Sorry, but my Yara knowledge is too limited to offer more. > > Sent from my iPad > > -Al- > ClamXAV User > >> On Aug 10, 2018, at 09:06, Alessandro Vesely <ves...@tana.it> wrote: >> >> Hi all, >> has anybody seen this Malware Analysis Report (AR18-221A) >> MAR-10135536-17 – North Korean Trojan: KEYMARBLE >> https://www.us-cert.gov/ncas/analysis-reports/AR18-221A >> ? >> >> I created a file "keymarble-dummy", whose hex dump looks like so: >> >> 00000000 4d 5a 74 68 69 73 20 69 73 20 61 20 64 75 6d 6d |MZthis is a >> dumm| >> 00000010 79 20 6b 65 79 6d 61 72 62 6c 65 20 66 69 6c 65 |y keymarble >> file| >> 00000020 20 63 72 65 61 74 65 64 20 66 6f 72 20 6d 61 6b | created for >> mak| >> 00000030 69 6e 67 20 74 65 73 74 73 0a 00 00 40 00 00 00 |ing >> tests...@...| >> 00000040 50 45 62 63 39 62 37 35 61 33 31 31 37 37 35 38 >> |PEbc9b75a3117758| >> 00000050 37 32 34 35 33 30 35 63 64 34 31 38 62 38 64 66 >> |7245305cd418b8df| >> 00000060 37 38 36 35 32 64 31 63 30 33 65 39 64 61 30 63 >> |78652d1c03e9da0c| >> 00000070 66 63 39 31 30 64 36 64 33 38 65 65 34 31 39 31 >> |fc910d6d38ee4191| >> 00000080 64 34 30 0a 00 |d40..| >> >> It matches the Yara rule in AR18-221A (see also below). >> However, according to virustotal, my dummy file is clean: >> https://www.virustotal.com/#/file/662ddd0a2af6c4ecf7234ef5541e559cfc7d6cedc0f475c3a2f64ced3869e366/detection >> >> But AR18-221A mentions a number of AV products which would report it's a >> Win32 Trojan. >> >> Hence, they all must use more sophisticated techniques than that simple Yara >> rule? >> IOW: the rule matches more files than it should? (It wouldn't be the first >> time US-CERT proposes Yara rules which would produce FPs if enabled.) >> >> Otherwise, is the rule wrong? When re-wrapped and commented, it looks like >> so: >> >> rule rsa_modulus >> { >> meta: >> Author="NCCIC trusted 3rd party" >> Incident="10135536" >> Date = "2018/04/19" >> category = "hidden_cobra" >> family = "n/a" >> description = "n/a" >> >> strings: >> // This is a "text" string, although it looks like a hex dump >> // (except for having an odd number of digits) >> $n = >> "bc9b75a31177587245305cd418b8df78652d1c03e9da0cfc910d6d38ee4191d40" >> >> condition: >> // MZ signature and PE signature at offset stored in MZ header at >> 0x3C and $n >> (uint16(0) == 0x5A4D and uint16(uint32(0x3c)) == 0x4550) and any of >> them >> } >> >> >> Any recommendation about using that rule? >> >> TIA >> Ale _______________________________________________ clamav-users mailing list clamav-users@lists.clamav.net http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
