Re: [clamav-users] Keymarble Yara rule?

[Al Varnell]

Yes, I'm fully aware of that. There have been exceptions made for certain 
individuals engaged in malware research, but I was turned down and told to use 
the ClamAV account, but they weren't willing to share unless I went through a 
tedious vetting process.

-Al-

On Fri, Aug 17, 2018 at 04:38 AM, Alessandro Vesely wrote:
> On Wed 15/Aug/2018 01:48:07 +0200 Al Varnell wrote:
> 
>> Sorry, I wasn't clear. I meant the malware sample, not your dummy.
> 
> To retrieve a sample from VirusTotal, one must work for a _company_ subscribed
> to their premium services...
> 
> Best
> 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

Re: [clamav-users] Keymarble Yara rule?

[Alessandro Vesely]

On Wed 15/Aug/2018 01:48:07 +0200 Al Varnell wrote:

> Sorry, I wasn't clear. I meant the malware sample, not your dummy.

To retrieve a sample from VirusTotal, one must work for a _company_ subscribed
to their premium services...

Best
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

Re: [clamav-users] Keymarble Yara rule?

[Al Varnell]

Sorry, I wasn't clear. I meant the malware sample, not your dummy.

-Al-

On Tue, Aug 14, 2018 at 11:24 AM, Alessandro Vesely wrote:
> On Mon 13/Aug/2018 00:27:55 +0200 Al Varnell wrote:
> 
>> I don't quite understand why you think it might not detect it. 
>> 
>> Text strings are not required to have an even number of digits. The hex
>> equivalent to that string would be: {62 63 39 [...] 34 30}. As
>> long as the string appears in a file, it should match.
> 
> That's right.
> 
> I thought it is unlikely to find a 65 bytes binary sequence, so it looked 
> wrong to me.  Perhaps, that's a wrong conjecture, since a malware writer may 
> want to hard code crypto data in the executable.  The sequence doesn't seem 
> to be code.
> 
>> I'd have to have the actual sample file in order to say anything more about 
>> it.
> 
> I don't attach it, as it may appear to be a (broken) executable.  Using an 
> xxd[*] dump (instead of hd) solves the problem since xxd is reversible and 
> idempotent:
> 
> ~/tmp$ diff -s <(xxd -g 1 keymarble-dummy) <(xxd -g 1 keymarble-dummy|xxd 
> -r|xxd -g 1)
> Files /dev/fd/63 and /dev/fd/62 are identical
> 
> So you can copy the following to a file and revert to binary:
> 
> ~/tmp$ xxd -g 1 keymarble-dummy
> : 4d 5a 74 68 69 73 20 69 73 20 61 20 64 75 6d 6d  MZthis is a dumm
> 0010: 79 20 6b 65 79 6d 61 72 62 6c 65 20 66 69 6c 65  y keymarble file
> 0020: 20 63 72 65 61 74 65 64 20 66 6f 72 20 6d 61 6b   created for mak
> 0030: 69 6e 67 20 74 65 73 74 73 0a 00 00 40 00 00 00  ing tests...@...
> 0040: 50 45 62 63 39 62 37 35 61 33 31 31 37 37 35 38  PEbc9b75a3117758
> 0050: 37 32 34 35 33 30 35 63 64 34 31 38 62 38 64 66  7245305cd418b8df
> 0060: 37 38 36 35 32 64 31 63 30 33 65 39 64 61 30 63  78652d1c03e9da0c
> 0070: 66 63 39 31 30 64 36 64 33 38 65 65 34 31 39 31  fc910d6d38ee4191
> 0080: 64 34 30 0a 00
> 
> Best
> 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

Re: [clamav-users] Keymarble Yara rule?

[Alessandro Vesely]

On Mon 13/Aug/2018 00:27:55 +0200 Al Varnell wrote:

> I don't quite understand why you think it might not detect it. 
> 
> Text strings are not required to have an even number of digits. The hex
> equivalent to that string would be: {62 63 39 [...] 34 30}. As
> long as the string appears in a file, it should match.

That's right.

I thought it is unlikely to find a 65 bytes binary sequence, so it looked wrong 
to me.  Perhaps, that's a wrong conjecture, since a malware writer may want to 
hard code crypto data in the executable.  The sequence doesn't seem to be code.

> I'd have to have the actual sample file in order to say anything more about 
> it.

I don't attach it, as it may appear to be a (broken) executable.  Using an 
xxd[*] dump (instead of hd) solves the problem since xxd is reversible and 
idempotent:

~/tmp$ diff -s <(xxd -g 1 keymarble-dummy) <(xxd -g 1 keymarble-dummy|xxd 
-r|xxd -g 1)
Files /dev/fd/63 and /dev/fd/62 are identical

So you can copy the following to a file and revert to binary:

~/tmp$ xxd -g 1 keymarble-dummy
: 4d 5a 74 68 69 73 20 69 73 20 61 20 64 75 6d 6d  MZthis is a dumm
0010: 79 20 6b 65 79 6d 61 72 62 6c 65 20 66 69 6c 65  y keymarble file
0020: 20 63 72 65 61 74 65 64 20 66 6f 72 20 6d 61 6b   created for mak
0030: 69 6e 67 20 74 65 73 74 73 0a 00 00 40 00 00 00  ing tests...@...
0040: 50 45 62 63 39 62 37 35 61 33 31 31 37 37 35 38  PEbc9b75a3117758
0050: 37 32 34 35 33 30 35 63 64 34 31 38 62 38 64 66  7245305cd418b8df
0060: 37 38 36 35 32 64 31 63 30 33 65 39 64 61 30 63  78652d1c03e9da0c
0070: 66 63 39 31 30 64 36 64 33 38 65 65 34 31 39 31  fc910d6d38ee4191
0080: 64 34 30 0a 00

Best
Ale
-- 

[*] https://github.com/jnweiger/xxd
(But it's probably already installed on your box.)
___
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

Re: [clamav-users] Keymarble Yara rule?

[Alessandro Vesely]

On Sun 12/Aug/2018 14:04:06 +0200 Arnaud Jacques wrote:

> 
> 
> Le 12/08/2018 à 13:59, Alessandro Vesely a écrit :
>> On Sat 11/Aug/2018 19:43:34 +0200 G.w. Haywood wrote:
>>
>>> Hi there,
>>>
>>> On Sat, 11 Aug 2018, Alessandro Vesely wrote:
>>>
>>> Re: Keymarble Yara rule?
   4d 5a 74 68 69 73 20 69  73 20 61 20 64 75 6d 6d  |MZthis is a 
 dumm|
 0010  79 20 6b 65 79 6d 61 72  62 6c 65 20 66 69 6c 65  |y keymarble 
 file|
 0020  20 63 72 65 61 74 65 64  20 66 6f 72 20 6d 61 6b  | created for 
 mak|
 0030  69 6e 67 20 74 65 73 74  73 0a 00 00 40 00 00 00  |ing 
 tests...@...|
 0040  50 45 62 63 39 62 37 35  61 33 31 31 37 37 35 38  
 |PEbc9b75a3117758|
 ...
     (uint16(0) == 0x5A4D and uint16(uint32(0x3c)) == 0x4550) and
 any of them
>>>
>>> The second offset looks wrong to me.
>>>
>>
>> Why?  uint32(0x3c) is 0x0040...
> 
> Because, each line is 16 bytes long (0x10).
> 
> So "0040" is in hexadecimal, not decimal.

Hm... yes, addresses in the first column are hex too.  "PE" is there.
___
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

Re: [clamav-users] Keymarble Yara rule?

[Al Varnell]

I don't quite understand why you think it might not detect it. 

Text strings are not required to have an even number of digits. The hex 
equivalent to that string would be: {62 63 39 62 37 35 61 33 31 31 37 37 35 38 
37 32 34 35 33 30 35 63 64 34 31 38 62 38 64 66 37 38 36 35 32 64 31 63 30 33 
65 39 64 61 30 63 66 63 39 31 30 64 36 64 33 38 65 65 34 31 39 31 64 34 30}. As 
long as the string appears in a file, it should match.

I'd have to have the actual sample file in order to say anything more about it.

-Al-

On Sun, Aug 12, 2018 at 04:56 AM, Alessandro Vesely wrote:
> I'd be curious to know if NCCIC's Yara rule would detect it, because of:
> 
>strings:
>// This is a "text" string, although it looks like a hex dump
>// (except for having an odd number of digits)
>$n = 
> "bc9b75a31177587245305cd418b8df78652d1c03e9da0cfc910d6d38ee4191d40"
> 
> (Recall that hex strings in Yara require curly braces, for example:
>$h = 
> {bc9b75a31177587245305cd418b8df78652d1c03e9da0cfc910d6d38ee4191d400}
___
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

Re: [clamav-users] Keymarble Yara rule?

[Arnaud Jacques]

Le 12/08/2018 à 13:59, Alessandro Vesely a écrit :

On Sat 11/Aug/2018 19:43:34 +0200 G.w. Haywood wrote:


Hi there,

On Sat, 11 Aug 2018, Alessandro Vesely wrote:

Re: Keymarble Yara rule?

  4d 5a 74 68 69 73 20 69  73 20 61 20 64 75 6d 6d  |MZthis is a dumm|
0010  79 20 6b 65 79 6d 61 72  62 6c 65 20 66 69 6c 65  |y keymarble file|
0020  20 63 72 65 61 74 65 64  20 66 6f 72 20 6d 61 6b  | created for mak|
0030  69 6e 67 20 74 65 73 74  73 0a 00 00 40 00 00 00  |ing tests...@...|
0040  50 45 62 63 39 62 37 35  61 33 31 31 37 37 35 38  |PEbc9b75a3117758|
...
    (uint16(0) == 0x5A4D and uint16(uint32(0x3c)) == 0x4550) and
any of them


The second offset looks wrong to me.



Why?  uint32(0x3c) is 0x0040...


Because, each line is 16 bytes long (0x10).

So "0040" is in hexadecimal, not decimal.

--
Cordialement / Best regards,

Arnaud Jacques
Gérant de SecuriteInfo.com

Téléphone : +33-(0)3.44.39.76.46
E-mail : a...@securiteinfo.com
Site web : https://www.securiteinfo.com
Facebook : https://www.facebook.com/pages/SecuriteInfocom/132872523492286
Twitter : @SecuriteInfoCom

Securiteinfo.com
La Sécurité Informatique - La Sécurité des Informations.
266, rue de Villers
60123 Bonneuil en Valois
___
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

Re: [clamav-users] Keymarble Yara rule?

[Alessandro Vesely]

On Sat 11/Aug/2018 19:43:34 +0200 G.w. Haywood wrote:

> Hi there,
> 
> On Sat, 11 Aug 2018, Alessandro Vesely wrote:
> 
> Re: Keymarble Yara rule?
>>   4d 5a 74 68 69 73 20 69  73 20 61 20 64 75 6d 6d  |MZthis is a 
>> dumm|
>> 0010  79 20 6b 65 79 6d 61 72  62 6c 65 20 66 69 6c 65  |y keymarble 
>> file|
>> 0020  20 63 72 65 61 74 65 64  20 66 6f 72 20 6d 61 6b  | created for 
>> mak|
>> 0030  69 6e 67 20 74 65 73 74  73 0a 00 00 40 00 00 00  |ing 
>> tests...@...|
>> 0040  50 45 62 63 39 62 37 35  61 33 31 31 37 37 35 38  
>> |PEbc9b75a3117758|
>> ...
>>    (uint16(0) == 0x5A4D and uint16(uint32(0x3c)) == 0x4550) and
>> any of them
> 
> The second offset looks wrong to me.
> 

Why?  uint32(0x3c) is 0x0040...
___
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

Re: [clamav-users] Keymarble Yara rule?

[Alessandro Vesely]

On Sat 11/Aug/2018 23:11:07 +0200 Al Varnell wrote: 

> Here's the VirusTotal page on this file
> 
> and it does show that ClamAV detects it as Win.Trojan.Agent-6641267-0
> which was just added yesterday

Thanks a lot!  That solves my doubt.  Yet, I'd be curious to know if NCCIC's 
Yara rule would detect it, because of:

strings:
// This is a "text" string, although it looks like a hex dump
// (except for having an odd number of digits)
$n = "bc9b75a31177587245305cd418b8df78652d1c03e9da0cfc910d6d38ee4191d40"

(Recall that hex strings in Yara require curly braces, for example:
$h = 
{bc9b75a31177587245305cd418b8df78652d1c03e9da0cfc910d6d38ee4191d400}
)


Best
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

Re: [clamav-users] Keymarble Yara rule?

[Al Varnell]

Here's the VirusTotal page on this file
>
and it does show that ClamAV detects it as Win.Trojan.Agent-6641267-0 which was 
just added yesterday by daily - 24829 and is a MD5 hash:
[daily.hsb] 
704d491c155aad996f16377a35732cb4:126976:Win.Trojan.Agent-6641267-0:73

so yes, ClamAV should catch it already.

-Al-

On Sat, Aug 11, 2018 at 04:04 AM, Alessandro Vesely wrote:
> 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
___
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

Re: [clamav-users] Keymarble Yara rule?

[G.W. Haywood]

Hi there,

On Sat, 11 Aug 2018, Alessandro Vesely wrote:

Re: Keymarble Yara rule?

  4d 5a 74 68 69 73 20 69  73 20 61 20 64 75 6d 6d  |MZthis is a dumm|
0010  79 20 6b 65 79 6d 61 72  62 6c 65 20 66 69 6c 65  |y keymarble file|
0020  20 63 72 65 61 74 65 64  20 66 6f 72 20 6d 61 6b  | created for mak|
0030  69 6e 67 20 74 65 73 74  73 0a 00 00 40 00 00 00  |ing tests...@...|
0040  50 45 62 63 39 62 37 35  61 33 31 31 37 37 35 38  |PEbc9b75a3117758|
...
   (uint16(0) == 0x5A4D and uint16(uint32(0x3c)) == 0x4550) and any of them


The second offset looks wrong to me.

--

73,
Ged.
___
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

Re: [clamav-users] Keymarble Yara rule?

[Alessandro Vesely]

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  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:
>> 
>>   4d 5a 74 68 69 73 20 69  73 20 61 20 64 75 6d 6d  |MZthis is a 
>> dumm|
>> 0010  79 20 6b 65 79 6d 61 72  62 6c 65 20 66 69 6c 65  |y keymarble 
>> file|
>> 0020  20 63 72 65 61 74 65 64  20 66 6f 72 20 6d 61 6b  | created for 
>> mak|
>> 0030  69 6e 67 20 74 65 73 74  73 0a 00 00 40 00 00 00  |ing 
>> tests...@...|
>> 0040  50 45 62 63 39 62 37 35  61 33 31 31 37 37 35 38  
>> |PEbc9b75a3117758|
>> 0050  37 32 34 35 33 30 35 63  64 34 31 38 62 38 64 66  
>> |7245305cd418b8df|
>> 0060  37 38 36 35 32 64 31 63  30 33 65 39 64 61 30 63  
>> |78652d1c03e9da0c|
>> 0070  66 63 39 31 30 64 36 64  33 38 65 65 34 31 39 31  
>> |fc910d6d38ee4191|
>> 0080  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

Re: [clamav-users] Keymarble Yara rule?

[Al Varnell]

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  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:
> 
>   4d 5a 74 68 69 73 20 69  73 20 61 20 64 75 6d 6d  |MZthis is a dumm|
> 0010  79 20 6b 65 79 6d 61 72  62 6c 65 20 66 69 6c 65  |y keymarble file|
> 0020  20 63 72 65 61 74 65 64  20 66 6f 72 20 6d 61 6b  | created for mak|
> 0030  69 6e 67 20 74 65 73 74  73 0a 00 00 40 00 00 00  |ing tests...@...|
> 0040  50 45 62 63 39 62 37 35  61 33 31 31 37 37 35 38  |PEbc9b75a3117758|
> 0050  37 32 34 35 33 30 35 63  64 34 31 38 62 38 64 66  |7245305cd418b8df|
> 0060  37 38 36 35 32 64 31 63  30 33 65 39 64 61 30 63  |78652d1c03e9da0c|
> 0070  66 63 39 31 30 64 36 64  33 38 65 65 34 31 39 31  |fc910d6d38ee4191|
> 0080  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