Change dynamic scope to call for atomic operations

[jorik-utwente]

To reduce false positives, we change the dynamic scope of a couple of operations to call.
E.g., writing to the registry is always done in one Windows API call, so we change the scope from thread to call.

Original discussion: #951

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[williballenthin]

here's where things can get tricky: the scope of create or open file is (fortunately) also call, but in some other rules is a larger scope (like thread), which is impossible to match.

so, i think this change is fine.

but we should be aware that in other scenarios, there's some tricky things we might have to fix.

[williballenthin]

thank you!

[mr-tz]

our rule parser doesn't like a call subscope in a file-wide call scope: call subscope supported only for the process and thread scopes - that's why the rule was as is, I assume

[mr-tz]

this works here:

rule:
  meta:
    name: copy file
    namespace: host-interaction/file-system/copy
    authors:
      - [email protected]
      - [email protected]
    scopes:
      static: function
      dynamic: call
    mbc:
      - File System::Copy File [C0045]
    examples:
      - Practical Malware Analysis Lab 01-01.exe_:0x401440
  features:
    - or:
      - api: kernel32.CopyFile
      - api: kernel32.CopyFileEx
      - api: CopyFile2
      - api: CopyFileTransacted
      - api: LZCopy
      - api: System.IO.FileInfo::CopyTo
      - api: System.IO.File::Copy
      # static
      - basic block:
        - and:
          - number: 2 = FO_COPY
          - or:
            - api: kernel32.SHFileOperation
      # dynamic
      - and:
        - number: 2 = FO_COPY
        - or:
          - api: kernel32.SHFileOperation

[jorik-utwente]

Hmm okay. The problem with this fix is that for static analysis the dynamic part will also match, and doesn't have the basic block scope (as pointed out here: #952 (comment) ). There is no way to make part of the features only apply to dynamic analysis, is there?

[mr-tz]

Oh, yes, that's not what we want.
I think we'd have to change the rule parser to properly handle this. @williballenthin, what do you think?

[williballenthin]

This makes sense to me. +1

[mr-tz]

mandiant/capa#2490

[mr-tz]

Thanks for all your suggestions, @jorik-utwente! I'm back this week to work on getting the improvements merged.