Guards for rules with multiple "formats"

[mr-tz]

Create a standard to guard rules with multiple formats, e.g. binary, script, and .NET.

I like the idea of matches: xyz technology where we expect the former to be included in all rule blocks matching xyz technology. We can then maintain the onexyz technology rule.

Originally posted by @mike-hunhoff in https://github.com/mandiant/capa-rules/pull/601#discussion_r941582347

Options include

• format: ...
• matches:
• ...

Refs

• https://github.com/mandiant/capa/discussions/1106#discussioncomment-3202916

[mike-hunhoff]

1. "matches XYZ..." rules

Support a "matches" rule for each technology we support, similar to our existing rule "complied to the .NET platform"

e.g.

  features:
    - or:
      - and:
        - match: compiled to Windows PE
        - or:
          - api: kernel32.OpenMutex
          - match: create mutex
        - optional:
          - or:
            - api: kernel32.GetLastError
            - number: 2 = ERROR_FILE_NOT_FOUND
            - number: 0xB7 = ERROR_ALREADY_EXISTS
      - and:
        - or:
          - match: compiled to .NET platform
          - match: source code using C#
        - or:
          - api: System.Threading.Mutex::OpenExisting
          - api: System.Threading.Mutex::TryOpenExisting

Pros:

• easier to maintain as we can group all of the features to detect XYZ technology in a single rule
• may not require adding logic to capa as we utilize existing features to detect technologies
• does not require overloading a single feature to support multiple technologies e.g. format

Cons:

• may be more difficult to short circuit rule matching
• overkill for technologies that can be detected using single format characteristic e.g. -format: pe

2. format feature for all supported technologies

Another suggestion is to add a format feature for each technology capa supports e.g.

- format: pe
- format: elf
- format: dotnet
- format: csharp
- format: javascript
- format: python

e.g.

  features:
    - or:
      - and:
        - format: pe
        - or:
          - api: kernel32.OpenMutex
          - match: create mutex
        - optional:
          - or:
            - api: kernel32.GetLastError
            - number: 2 = ERROR_FILE_NOT_FOUND
            - number: 0xB7 = ERROR_ALREADY_EXISTS
      - and:
        - or:
          - format: dotnet
          - format: csharp 
        - or:
          - api: System.Threading.Mutex::OpenExisting
          - api: System.Threading.Mutex::TryOpenExisting

Pros:

• does not require maintaining new "matches" rules for each technology
• may be easier to short circuit rule matching

Cons:

• format name may become too overloaded e.g. does -format: python really fit
• may require additional logic be added to capa to properly detect the various formats