Add Ability for Capturing Malware Development Environment

[ikiril01]

We should investigate adding a capability for capturing the particular development environment used in developing a malware instance, capable of being used for things other than just Windows PE binaries and inclusive of exploit kits and the like.

[ikiril01]

We may be able to use the CybOX ToolInformationType.

[ikiril01]

We should consider adding our own controlled vocabulary, for use in the Type field of the CybOX ToolInformationType.

[ikiril01]

Possibilities for the controlled vocabulary:

• Builder
• Compiler
• Linker
• Packer
• Crypter

Others?

[ikiril01]

Notional implementation:

• Add MalwareDevelopmentEnvironmentType with the following properties:
  • Tools (ToolListType): The Tools field captures one or more tools used in the development of the malware instance.
• Add Development_Environment field of MalwareDevelopmentEnvironmentType to MalwareSubjectType in MAEC Package Schema

[chahan]

Would it be worthwhile to include additional vocabulary/details related to dynamic versus runtime linking? Or even other IAT anti-reversing type methods?

[ikiril01]

Definitely worthwhile, I think! The question is whether these are really properties of the development environment or inherent capabilities or features of the malware? The usage of dynamic versus runtime linking does seem related to the development of malware, and would make good sense to add to the MalwareDevelopmentEnvironmentType. I'm not super knowledgable about IAT anti-reversing but I'm wondering if it would fall under the Anti-Code Analysis/Code Obfuscation in the capabilities hierarchy and thus be best captured there?

[chahan]

While it is a technique to make reversing difficult, I don't think it should be considered obfuscation or anti-reversing. I would be interested to hear what @gtback has to say.

[chahan]

But would obfuscation be better considered as a collection of runtime linking and other methods? And how would that relate to methods that a packer uses to truly hide valuable information within a binary?

[chahan]

Would it also make sense to include some generic term for strings related to the developer's environment such as the location of symbols within the filesystem?

[gtback]

Is the intention that this would be information that could be derived from the malware itself, or that it would require some external information source?

I also think that if you're trying to describe the general process of compiling a binary (Windows PE or otherwise), it shouldn't be something specific to MAEC, particularly since that is, in my experience, tangential to the intent or deliberate actions of the malware author.

[ikiril01]

The overall intent for this type is to capture information related to how the malware was developed, primarily in terms of the tools that were used. At the moment we have no way of saying that a particular malware instance was "built with builder x version 1.23456", for instance. There are often particular signatures associated with these sorts of tools, so this information could be determined from the malware itself. It also might make sense to add some other non-tool specific properties that might be useful to capture; I certainly agree that we're not trying to go as far as capturing the process of compiling a binary, though if it can be determined that it was compiled or linked with a particular tool, we should have the ability to state this.

Good point about IAT, @chahan. I think run-time linking is similar in that it is often, though not always, used for Obfuscation. We do have packing, code encryption, and other techniques that are almost exclusively used for obfuscation under the Anti-Code Analysis/Code Obfuscation branch of the capabilities at the moment. As far as the generic strings related to the developer's environment, I think it may be useful to consider adding a structure that can capture what's contained in a .pdb or dbg files (which can be embedded in PE binaries, if I'm not mistaken).