Malware Configuration Parameters

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Malware Configuration Parameters

Kirillov, Ivan A.

All,

 

As part of the MAEC v4.1 update, we plan on adding the capability to natively capture any configuration parameters used by a malware instance, likely as part of the Malware Subject in the MAEC Package. I’m reaching out to see if there’s any sense of a “common” set of parameters out there that we could enumerate as part of a controlled vocabulary? Or are configuration parameters so varied that it would difficult and not useful to try to enumerate them?

 

Also, our proposed structure for capturing configuration parameters will be a basic name/value pair:

 

<Configuration_Parameter>

   <Name>the name of the configuration parameter</Name>

   <Value>the value of the configuration parameter</Value>

</Configuration_Parameter>

 

If the community deems the vocabulary worthwhile, then we’ll allow for it to be used in the Name field (though it won’t be a necessity if one wishes to use a value not present in the vocabulary). 

 

Any thoughts on this?

 

Regards,

Ivan Kirillov

MAEC Project

MITRE

Reply | Threaded
Open this post in threaded view
|

RE: Malware Configuration Parameters

Kirillov, Ivan A.
Hi Dave,

Thanks for the feedback. My definition of configuration parameter would be something like "a setting that can be configured for a malware instance, whether through a toolkit or builder upon creation,  dynamically through a configuration file, or some other means". Thus, the first of entities you described, along with the XOR key and anything that Zeus or another family would include in its config blob would all be amenable for inclusion. However, the focus would likely be on more metadata related parameters like group id, encryption password, XOR key, etc. - basically, things that typically aren't discernable through dynamic analysis (as opposed to mutex, registry key etc., which we could capture through Actions and Objects).

Basically, we think it would be useful to have a standard way of capturing these properties, especially given today's popularity of malware builders and toolkits. Do you feel that it would be possible to enumerate/standardize upon a useful subset of these properties, i.e. are there commonalities here among malware that we could capture? Or are configuration parameters so disparate that we should just implement the key/value structure described and not try to construct a vocabulary for capturing them?

Regards,
Ivan

-----Original Message-----
From: Proulx, David J.
Sent: Wednesday, December 18, 2013 1:58 PM
To: Kirillov, Ivan A.; maec-discussion-list Malware Attribute Enumeration Discussion
Subject: RE: Malware Configuration Parameters

Ivan,

I'm not quite sure what you're defining as a configuration parameter, but if
you look at something like PIVY, you've got an encryption password, a group
id, mutex, process it injects into, startup registry key, install path,
proxy aware.  You could also consider something like an XOR key that is used
to obfuscate traffic and can be changed between instances.  Some of these
things apply to other families of malware, but in most cases they're built
into the binary - so is that a configuration parameter?  In other cases,
there's malware that's meant to be started from a command line with input
parameters, or there's something like Zeus which downloads an encrypted
config blob.  Is this more like the info you're trying to characterize?

Thanks.
Dave.


>-----Original Message-----
>From: [hidden email] [mailto:owner-maec-
>[hidden email]] On Behalf Of Kirillov, Ivan A.
>Sent: Tuesday, December 17, 2013 11:04 AM
>To: maec-discussion-list Malware Attribute Enumeration Discussion
>Subject: Malware Configuration Parameters
>
>All,
>
>
>
>As part of the MAEC v4.1 update, we plan on adding the capability to
natively
>capture any configuration parameters used by a malware instance, likely as
>part of the Malware Subject in the MAEC Package. I'm reaching out to see if
>there's any sense of a "common" set of parameters out there that we could
>enumerate as part of a controlled vocabulary? Or are configuration
>parameters so varied that it would difficult and not useful to try to
enumerate
>them?
>
>
>
>Also, our proposed structure for capturing configuration parameters will be
a

>basic name/value pair:
>
>
>
><Configuration_Parameter>
>
>   <Name>the name of the configuration parameter</Name>
>
>   <Value>the value of the configuration parameter</Value>
>
></Configuration_Parameter>
>
>
>
>If the community deems the vocabulary worthwhile, then we'll allow for it
to
>be used in the Name field (though it won't be a necessity if one wishes to
use

>a value not present in the vocabulary).
>
>
>
>Any thoughts on this?
>
>
>
>Regards,
>
>Ivan Kirillov
>
>MAEC Project
>
>MITRE
Reply | Threaded
Open this post in threaded view
|

RE: Malware Configuration Parameters

Back, Greg
I think it would definitely be useful to include a vocabulary, particularly since there are so many names for the same things (campaign ID, group ID, instance ID), (encryption key, encryption password, password). On the other hand, the "correct" names are often not known unless you have access to the source code or the builder, so it might be difficult to achieve consensus. Sometimes a "configuration setting" is useful for identifying samples, even if it's purpose is unknown.

Greg

>-----Original Message-----
>From: [hidden email] [mailto:owner-maec-
>[hidden email]] On Behalf Of Kirillov, Ivan A.
>Sent: Wednesday, December 18, 2013 2:49 PM
>To: Proulx, David J.; maec-discussion-list Malware Attribute Enumeration
>Discussion
>Subject: RE: Malware Configuration Parameters
>
>Hi Dave,
>
>Thanks for the feedback. My definition of configuration parameter would be
>something like "a setting that can be configured for a malware instance,
>whether through a toolkit or builder upon creation,  dynamically through a
>configuration file, or some other means". Thus, the first of entities you
>described, along with the XOR key and anything that Zeus or another family
>would include in its config blob would all be amenable for inclusion. However,
>the focus would likely be on more metadata related parameters like group id,
>encryption password, XOR key, etc. - basically, things that typically aren't
>discernable through dynamic analysis (as opposed to mutex, registry key etc.,
>which we could capture through Actions and Objects).
>
>Basically, we think it would be useful to have a standard way of capturing
>these properties, especially given today's popularity of malware builders and
>toolkits. Do you feel that it would be possible to enumerate/standardize upon
>a useful subset of these properties, i.e. are there commonalities here among
>malware that we could capture? Or are configuration parameters so disparate
>that we should just implement the key/value structure described and not try
>to construct a vocabulary for capturing them?
>
>Regards,
>Ivan
>
>-----Original Message-----
>From: Proulx, David J.
>Sent: Wednesday, December 18, 2013 1:58 PM
>To: Kirillov, Ivan A.; maec-discussion-list Malware Attribute Enumeration
>Discussion
>Subject: RE: Malware Configuration Parameters
>
>Ivan,
>
>I'm not quite sure what you're defining as a configuration parameter, but if
>you look at something like PIVY, you've got an encryption password, a group
>id, mutex, process it injects into, startup registry key, install path,
>proxy aware.  You could also consider something like an XOR key that is used
>to obfuscate traffic and can be changed between instances.  Some of these
>things apply to other families of malware, but in most cases they're built
>into the binary - so is that a configuration parameter?  In other cases,
>there's malware that's meant to be started from a command line with input
>parameters, or there's something like Zeus which downloads an encrypted
>config blob.  Is this more like the info you're trying to characterize?
>
>Thanks.
>Dave.
>
>
>>-----Original Message-----
>>From: [hidden email] [mailto:owner-maec-
>>[hidden email]] On Behalf Of Kirillov, Ivan A.
>>Sent: Tuesday, December 17, 2013 11:04 AM
>>To: maec-discussion-list Malware Attribute Enumeration Discussion
>>Subject: Malware Configuration Parameters
>>
>>All,
>>
>>
>>
>>As part of the MAEC v4.1 update, we plan on adding the capability to
>natively
>>capture any configuration parameters used by a malware instance, likely as
>>part of the Malware Subject in the MAEC Package. I'm reaching out to see if
>>there's any sense of a "common" set of parameters out there that we could
>>enumerate as part of a controlled vocabulary? Or are configuration
>>parameters so varied that it would difficult and not useful to try to
>enumerate
>>them?
>>
>>
>>
>>Also, our proposed structure for capturing configuration parameters will be
>a
>>basic name/value pair:
>>
>>
>>
>><Configuration_Parameter>
>>
>>   <Name>the name of the configuration parameter</Name>
>>
>>   <Value>the value of the configuration parameter</Value>
>>
>></Configuration_Parameter>
>>
>>
>>
>>If the community deems the vocabulary worthwhile, then we'll allow for it
>to
>>be used in the Name field (though it won't be a necessity if one wishes to
>use
>>a value not present in the vocabulary).
>>
>>
>>
>>Any thoughts on this?
>>
>>
>>
>>Regards,
>>
>>Ivan Kirillov
>>
>>MAEC Project
>>
>>MITRE