design registry 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 registry 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 Registry feature.

open questions include:

• how to represent operations, like read/write/create/delete
• how to represent registry keys versus registry values
• how to represent the data written/read from a value
• how to combine all the above with logic, like value data = 0x1 AND (path = foo OR path = bar), or not. and how this affects rule syntax

[yelhamer]

syntax:

As @mr-tz suggested, I think it would be better for the syntax to be similar to that of the property features. This way, there would be more cohesion across the capa rule format, which would make it easier for people to get up to speed with it and write & contribute new rules.

the feature would support the same access modes as the _AccessFeature class currently does (read and write), in addition to a delete mode.

implementation:

I am not sure if we can use the _AccessFeature class to represent access modes for both the property features as well as the HBI ones. I think we should be able to, but I'd love to hear your thoughts on this.

rule examples

1. Persistence using the registry keys:

rule:
  meta:
    name: Establish persistence via Registry autorun
    scope: process
    att&ck:
      - Persistence::Boot or Logon Autostart Execution [T1547.001]
    examples:
      - 1D751C9AA079CC2D42D07D7964D5FAE375127EFA6CA1AC2DFECFD481FE796FBC # https://www.picussecurity.com/resource/blog/the-christmas-card-you-never-wanted-a-new-wave-of-emotet-is-back-to-wreak-havoc
  features:
    - or:
      - registry/write: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
      - registry/write: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
      - registry/write: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce
      - registry/write: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce

2. Defense evasion using the registry:

rule:
  meta:
    name: Store configuration in Registry (OceanLotus)
    scope: process
    att&ck:
      - Defense Evasion::Modify Registry [T1112](https://attack.mitre.org/techniques/T1112)
      - Defense Evasion::Fileless Storage [T1027](https://attack.mitre.org/techniques/T1027)
    examples:
      - 0ABE0A3B1FD81272417471E7E5CC489B234A9F84909B019D5F63AF702B4058C5 # https://www.welivesecurity.com/2019/03/20/fake-or-fake-keeping-up-with-oceanlotus-decoys/
  features:
    - thread:
      - and:
        - registry/read: HKCU\SOFTWARE\Classes\CLSID\{E08A0F4B-1F65-4D4D-9A09-BD4625B9C5A1}\Model
        - registry/write: HKCU\SOFTWARE\Classes\CLSID\{E08A0F4B-1F65-4D4D-9A09-BD4625B9C5A1}\Model

[mr-tz]

This looks pretty good. Would this be equivalent to, for example:

    - thread:
      - and:
        - call:
          - and:
            - match: write registry
            - string: HKCU\SOFTWARE\Classes\CLSID\{E08A0F4B-1F65-4D4D-9A09-BD4625B9C5A1}
            - string: Model

[yelhamer]

@mr-tz the rule using the registry feature should detect all the capabilities extracted by the rule you mentioned, but for the other way around I think the registry keyword based rule should detect more (hopefully?).

i am unsure of how common it is for malware to use powershell to interact with the registry. if it is indeed common, then i think the registry-based rule should detect more (given that sandboxes don't analyze the malware-created powershell processes.

thoughts?

[williballenthin]

ah, interesting, so @yelhamer can you clarify how this rule is intended to match? does it match features extracted from the API trace or from a sandbox summary report or something else? or both?

[williballenthin]

is it worthwhile to explore how to match also:

1. registry path by regex/substring
2. the values being set, such as a run key pointing towards a file in the temp directory

also, can you spend a little time defining exactly how the path is constructed? is it the key path + a value name? or only the key path?

[yelhamer]

@williballenthin, initially i was planning on extracting this feature from the summary reports, but extracting it from api reports does seem like it would be nice to have (i think?). Do you think it would be doable? i guess we'd have to match each extracted api feature to see if it's registry related, and if it is we'd yield that api feature as well as the registry feature (based on args).

for defining the path, i think we can do both (key plus key and value name). this cape report (0da82f67e6bb6e7295bb4a9ad3d7f17f1edd0ef5099d262ec28641d7d68ca219) includes the registry accesses for the parent keys up until the value version (presumably the sample is enumerating that registry entry):

thoughts on adding the registry feature this way? do you think it can be just replaced by api call matching?

[williballenthin]

i was planning on extracting this feature from the summary reports

I think this is the easiest place to start. extracting artifacts from API calls seems feasible, but will need even more logic to implement. so lets begin with the summary artifacts as reported by sandboxes.

[r0ny123]

This looks pretty good. Would this be equivalent to, for example:

    - thread:
      - and:
        - call:
          - and:
            - match: write registry
            - string: HKCU\SOFTWARE\Classes\CLSID\{E08A0F4B-1F65-4D4D-9A09-BD4625B9C5A1}
            - string: Model

I think we can break write and registry into two parts so the above one turns into e.g.

- thread:
      - and:
        - call:
          - and:
            - match: registry
            - operation: write
            - key: HKCU\SOFTWARE\Classes\CLSID\{E08A0F4B-1F65-4D4D-9A09-BD4625B9C5A1}
            - value: Model

What do you guys think?

[mr-tz]

That could also work. My main focus here was to not introduce new syntax but see if/how we could do this with our current features. And then add syntactic sugar/translation or do something more advanced down the road.