design filename HBI feature for use in dynamic analysis

[williballenthin]

let's discuss the requirements and sketch a design for how this feature should look and act. the idea is to represent a file name or path artifact that is manipulated during a dynamic analysis session.

this should include how the rule syntax changes, the format of the feature and properties of the feature, and at least two example rules showing how the feature would be used.

once we're happy with the design, then lets plan for opening a standalone PR with the file path feature.

open questions include:

• how to represent operations, like read/write/create/delete
• how to represent paths versus names versus volumes versus streams, etc.
• how to represent the data written/read from a file
• how to combine all the above with logic, or not. and how this affects rule syntax

[yelhamer]

For this feature, I propose to have a syntax similar to that of other HBI-based features; that is, a filename keyword that has modifiers (read, write, delete). Additionally, I think it would be a nice addition to support UNIX-like wildcards such as: ?, *, and {}. Example:

rule:
  meta:
    name: persistence via ssh
    scope: file
  features:
    - filename/write: "/home/*/.ssh/authorized_keys"

Another example:

rule:
  meta:
    name: persistence via cron
    scope: file
  features:
    - filename/write: "/etc/cron.{daily,hourly,monthly,weekly}/*"

The pros are that this format is widely known, in addition to it being easy to parse — as opposed to regex — and quite expressive.
These features could also be extracted at call or instruction scope levels.

[mr-tz]

This looks like a good start. How do you envision addressing paths vs. files? Would it be filename: C:\Windows for example?

[yelhamer]

Hmm, good point. Maybe treat directories as files as well (like you suggest)?

[mr-tz]

For that general case I'd then suggest file or path.