From thread to call scope for basic rules

[jorik-utwente]

Background

We got false positives when testing the existing rules on cape reports of real-world malware samples.
After some investigation, we found that most persistence rules use dynamic: thread, which can be troublesome.

E.g., for persist-via-run-registry-key.yml, a matching behavior for the current rule would be:

• referencing HKCU/HKLM (this also occurs in registry reads),
• the string "Software\Microsoft\Windows\CurrentVersion" (frequently used location in general, not only for persistence)
• the string "Run" (This word occurs a lot)

These three behaviors have to occur in the same thread. As a result, we saw false positives where the program just read some registry keys and also mentioned the string "run" someplace, e.g. in a file read or another registry read.

To decrease the false positives, it would make sense to change the dynamic scope to call.

Changing from thread to call

To be able to use dynamic: call instead in the persistence rules, set-registry-value should also use dynamic: call (otherwise capa won't run). Would it be possible to change this, or will this break other rules? Otherwise, can I make a new set-registry-value-call-only rule?

I have created new persistence rules that I want to create a PR for, but they rely on set-registry-value, write-file-on-windows, move-file, etc. to have a call scope instead of thread scope. So I am looking for a way to do this properly.

Thanks!

[mr-tz]

Hello, we've also noticed various false positives recently due to the thread scope being to large.

For now the best approach is to reduce the scopes or, if that's not possible, to disable the rules for dynamic analysis.

Thanks for all the details here. Your suggestions sound good. Feel free to put in a PR and, if needed, we can further discuss there.

[mr-tz]

Sidenote: a cool research project would be to see how analysis of the static file (e.g. function boundaries) and the dynamic sandbox results could be combined.

Alternatively, how can capa otherwise limit the scope to something sensical (like only x events/calls away).

[jorik-utwente]

Thanks for your reply! Would you suggest making a PR that changes the scope of existing rules such as set-registry-value or creating a new set-registry-value-call-scope rule instead?

The change should not result in any new false negatives for the analysis of Cape reports since setting registry keys always happens in a single Windows API call. But perhaps if other analysis systems also use the rules, it could break something, but I am only familiar with Cape.

[mr-tz]

I'd prefer to only have one rule so would say to update the scope of the existing rules.
Other analysis systems also are affected by FPs so it's great if we can reduce those.

[jorik-utwente]

Alright, thanks for your input!

[williballenthin]

Moritz (@mr-tz) and I discussed today the idea of introducing a new scope, tentatively called "sequence", for matching across calls that are close to one another. In practice, we could use something like a sliding window over N calls and match features within each region. We suspect this would capture the common dynamic analysis use case of matching a small number of closely related API calls.

I don't think it would take too much code, at least an initial, unoptimized implementation.

I don't think that we (@mr-tz or I) are going to work on it in the short term, but we will keep the idea around for next year's GSoC program. Of course, any external contributor is welcomed to take a stab. Chat with us first about the design and we'll share some guidance!

[williballenthin]

"sequence" may not be the right name because we would not encoding ordering of the calls. But we do mean across a small number of contiguous API calls within one thread.

[jorik-utwente]

This sounds like an interesting idea! There are definitely some rules that will benefit from this addition.

For common API calls like file/registry reads/writes this is not needed currently. The handles used in API calls are resolved in the Cape report to the actual file names. So it is not necessary to first check if a file handle is created for a specific path, and then soon after the handle is used to read/write. The path is put automatically in the read/write API call by cape, so only a call scope is required.

But for more advanced behavior this could be super helpful.

Another option would be to enable matching with 'tokens'. E.g. OpenFile returns a value A, and then we only match ReadFile if A is used as a (first) argument.
However, this idea would lead to even more work, as you would probably want to be able to match specific arguments. E.g. be able to specifically match the hFile argument for ReadFile.

[williballenthin]

Another option would be to enable matching with 'tokens'. E.g. OpenFile returns a value A, and then we only match ReadFile if A is used as a (first) argument.

This would be really nice, and @mr-tz and I discussed this a bit, including "liveness tracking" of handles. I suspect it would work pretty well, though it requires a bunch more work (we think, like you also suggested). So, we'd propose to try the simple, naive algorithm first, and then refine only if required.