|
|
28183
|
Add support for patterns/regular expression in attributes |
Open |
2010-10-29 |
|
Priority:
Medium
| Date Closed:
n/a
|
|
Details:
We need to add support for patterns (through regular expressions) as attributes for things like object names, ip addresses, etc. OVAL's implementation of the 'pattern match' datatype may be a good reference for how to do this.
|
|
Follow-ups:
n/a
|
|
|
28186
|
Add support for characterization of environmentally sensitive action attributes |
Open |
2010-10-29 |
|
Priority:
Low
| Date Closed:
n/a
|
|
Details:
It could be useful to characterize action attributes as being environmentally sensitive (or not), particularly for triage and detection. For instance, GetLocalTime() could be used as an input into the CreateFile API call to always set the creation time of a file as being equivalent to the current system clock time.
|
|
Follow-ups:
n/a
|
|
|
28184
|
Add support for tagging of behaviors with regards to 'phase' of execution |
Open |
2010-10-29 |
|
Priority:
Low
| Date Closed:
n/a
|
|
Details:
It would be useful to tag behaviors/actions based on where they belong in the "phase" of malware execution. For instance, separating behaviors based on whether they belong to the "unpacking" phase or the actual execution that follows.
|
|
Follow-ups:
n/a
|
|
|
28185
|
Add support for characterization of whether or not an action/behavior can be counteracted |
Open |
2010-10-29 |
|
Priority:
Low
| Date Closed:
n/a
|
|
Details:
It would be useful to allow for the identification of blockable actions/behaviors, or those that can somehow be counteracted.
|
|
Follow-ups:
n/a
|
|
|
28187
|
Add support for document metadata attributes |
Open |
2010-10-29 |
|
Priority:
Medium
| Date Closed:
n/a
|
|
Details:
The toolkits that are used to create malicious documents (e.g., PDFs, Office documents) may set the metadata of these documents, which can be used to identify the toolkit used to create the document, the author of the toolkit, etc. We should add attributes for document metadata.
|
|
Follow-ups:
n/a
|
|
|
28188
|
Add support for defining the composition of strings |
Open |
2010-10-29 |
|
Priority:
Medium
| Date Closed:
n/a
|
|
Details:
Many strings created by malware (things like file names) are either randomized in some fashion or created based on some local entity, such as the hostname. Currently we have no way of specifying this, and so we should think about how to add this capability into MAEC.
|
|
Follow-ups:
n/a
|
|
|
28189
|
Add support for attributes of specific file types |
Open |
2010-10-29 |
|
Priority:
Medium
| Date Closed:
n/a
|
|
Details:
While we currently support a broad range of object characteristics that are applicable to files in general, it would be useful to have the capability of characterizing the attributes (mainly structural) of specific file types, such as PE executables. This would make MAEC amenable to the sharing of more low-level analysis data, such as that extracted through various tools intended for this purpose.
|
|
Follow-ups:
n/a
|
|
|
28191
|
Add more detailed support for packing and obfuscation attributes |
Open |
2010-10-29 |
|
Priority:
Medium
| Date Closed:
n/a
|
|
Details:
MAEC should be able to describe characteristics of packing, obfuscation, and anti-debugging techniques. Also need to define relationships between artifacts (e.g., between packed and unpacked files). Note, this should include efforts to hide in the network.
|
|
Follow-ups:
n/a
|
|
|
28611
|
Add extended/new network attributes |
Open |
2010-12-02 |
|
Priority:
Medium
| Date Closed:
n/a
|
|
Details:
Netflow
*Source/Dest. IP
*Source/Dest.
*Port
*Layer 3 Protocol
*Layer 7 Protocol
*ICMP type/code
*IP Version
*Payload w/ offsets
*Number of TCP resets
*ARP packet rate
Specific layer 7 protocol attributes
-HTTP
*Client Headers
*Server Headers
-IRC
*Server
*Channel
*Password
*Channel key
*Mode
*Nick
*Realname
*etc.
-SMTP
*Envelope info
-DNS
*Query info
*Reply info
-FTP
-SMB
Metadata
*User Agent
*SSL Certs.
*Others?
|
|
Follow-ups:
n/a
|
|
|
28690
|
Add languages/translation attributes and elements for strings |
Open |
2010-12-10 |
|
Priority:
Medium
| Date Closed:
n/a
|
|
Details:
Since strings contained in binaries may be in a language other than English, we need to add an attribute for specifying the particular language. Also, it may be worthwhile to add a field for holding the translation of the string.
|
|
Follow-ups:
n/a
|
|
|
28190
|
Add support for attributes gleaned from memory forensics |
Open |
2010-10-29 |
|
Priority:
Medium
| Date Closed:
n/a
|
|
Details:
MAEC should be able to handle the information that can be gleaned from memory forensics. We will probably need to add new objects (e.g., memory, processes) and attributes. We may also need new actions and action implementations (e.g., there may be differences between dynamic analysis and memory forensics analysis). This is also tied into the notion of using MAEC to profile so-called 'indicators' of malware.
|
|
Follow-ups:
Date Added: 2010-12-10 19:07:55
Volatility plugins page: http://www.forensicswiki.org/wiki/List_of_Volatility_Plugins
|
|
|
28674
|
Add an encoding method for CodeType/CodeSegment elements |
Closed |
2010-12-09 |
|
Priority:
Medium High
| Date Closed:
2011-01-19 16:22:31
|
|
Details:
Currently, we use the CodeType element as a way of specifying/transporting code snippets. The issue is that, at the moment, this is done in cleartext as a simple string. Therefore, things like shellcode could trigger IPS and other systems when attempting to transport such code snippets in a MAEC bundle.
As such, we need to define an encoding mechanism to be used for this element, in order to have the ability to share code snippets without having them triggering any IDS or other signature based detection mechanisms. One idea is to use something like an inline XOR key, as specified by RFC 5901: http://tools.ietf.org/html/rfc5901#section-5.9.5
|
|
Follow-ups:
Date Added: 2011-01-19 16:22:31
Implemented in schema version 1.1 using RFC-5901 XOR encoding.
|
|
|
28720
|
Update MAEC Schema Versioning |
Closed |
2010-12-15 |
|
Priority:
Medium High
| Date Closed:
2011-01-05 20:50:32
|
|
Details:
Right now, the MAEC schema is versioned solely through the 'version' attribute of the xs:schema element. However, this is not the best way to do this as this is not an enforceable constraint. Therefore, we need to find and implement a different solution, perhaps using the targetNamespace attribute, similarly to the way OVAL does this.
|
|
Follow-ups:
Date Added: 2011-01-05 20:50:32
Namespace based versioning was added on 01/05.
Current namespaces:
MAEC 'core' schema: http://maec.mitre.org/XMLSchema/maec-core-1
MAEC 'objects' schema: http://maec.mitre.org/XMLSchema/maec-objects-1
MAEC 'enumerations' schema: http://maec.mitre.org/XMLSchema/maec-enumerations-1
Date Added: 2011-01-19 16:23:12
Implemented in schema version 1.1.
|
|
|
28270
|
APICall/CodeType elements under ActionImplementationType should be optional |
Closed |
2010-11-08 |
|
Priority:
Medium High
| Date Closed:
2010-11-23 16:18:55
|
|
Details:
These elements should be made optional, as it is possible to have cases where we we may have knowledge of some action-specific attributes without actually knowing the specifics regarding how the action was implemented.
|
|
Follow-ups:
Date Added: 2010-11-23 16:18:55
Change added on 11/23.
Date Added: 2011-01-19 16:23:36
Implemented in schema version 1.1.
|
|
|
28223
|
Add support for incoming/outgoing sockets |
Closed |
2010-11-02 |
|
Priority:
Medium
| Date Closed:
2010-11-23 16:17:33
|
|
Details:
We need to add support for differentiating between locally and externally (outgoing) bound sockets.
|
|
Follow-ups:
Date Added: 2010-11-23 16:17:33
Added support for externally bound addresses on 11/23.
Date Added: 2011-01-19 16:23:52
Implemented in schema version 1.1.
|
|
|
28193
|
Add processor family class attribute for shellcode in code_snippet type |
Closed |
2010-10-29 |
|
Priority:
Medium High
| Date Closed:
2010-11-23 15:40:52
|
|
Details:
We need to add support for defining the processor family of the code used in the code_snippet type, especially for shellcode. As Jose Nazario points out: "this pops out as potentially problematic for people at some point in the future, or
people who don't know that i386 instruction sets are commonly assumed
in our business."
|
|
Follow-ups:
Date Added: 2010-11-23 15:40:52
Added on 11/23.
Date Added: 2011-01-19 16:24:05
Implemented in schema version 1.1.
|
|
|
28151
|
Add support for Handles in Process Objects |
Closed |
2010-10-26 |
|
Priority:
Medium
| Date Closed:
2010-11-23 15:27:13
|
|
Details:
Proposed by Cem Gurkok:
<Object id="6" Object_Type="Process">
<Process_Attributes>
<Handles>
<Handle>
<Name>
8934723902138
</Name>
</Handle>
</Handles>
</Process_Attributes>
</Object>
|
|
Follow-ups:
Date Added: 2010-11-23 15:27:13
Added on 11/23.
Date Added: 2011-01-19 16:24:18
Implemented in schema version 1.1.
|
