Should malware Identification rules be allowed in this repo?

[Still34]

Summary

It looks like the majority of existing rules describe either a potential behavior or known identifiers associated with certain events or library. While I understand capa is more or less meant to describe the behaviors of the currently inspected executable, rather than known malware patterns (typically Yara is used instead for this), are we allowed to submit rules that would identify parts of a known malware family?

For example, families such as PlugX have known identifiers built into each module, should the contributors be allowed to submit rules that would identify such part? And if so, under what namespace?

[mr-tz]

Yes, absolutely! We should probably create a new namespace and/or maybe add a new malware-family meta field.

Feel free to propose a first rule (or a few) and we can discuss based on a concrete example.

[Still34]

Awesome, here's one I wrote earlier today for detecting known PlugX modules: https://github.com/Still34/azura-yara/blob/main/capa/malware/apt/match-known-plugx-module.yml#L14

It's not perfect, as ideally it should look for hexadecimal numbers that are formatted like YYYYMMDD instead of hardcoded known date stamps (e.g., 0x20120225), though I'm not too sure what would be the most ideal and performant way to write it (regex would be expensive).

[mr-tz]

I like the malware namespace you suggest. It should also include the family name.

The rule naming can then focus on the capability, functionality, etc (the name here could be a little more specific).

In the meta section we could then also add maec/malware-family or similar so the output and other tools can leverage the result.

What do you think on your adapted rule: rules/malware/plugx/match-known-module.yml?

# generated using capa explorer for IDA Pro
rule:
  meta:
    name: match known module
    namespace: malware/plugx
    maec/malware-family: PlugX
    author: still@teamt5.org
    scope: function
    references:
      - https://circl.lu/assets/files/tr-12/tr-12-circl-plugx-analysis-v1.pdf
      ...
    examples:
      - 64E9F62840DB2F65FC717CFAF99081F9:0x10024950
  features:
    - and:
      - or:
        - description: module timestamp
        - number: 0x20120225
        ...
      - or:
        - number: 0x1001 = get system information
        ...

[Still34]

Sounds good to me.