From thread to call scope for basic rules #951
Replies: 2 comments 6 replies
-
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. |
Beta Was this translation helpful? Give feedback.
-
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! |
Beta Was this translation helpful? Give feedback.
-
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: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 usedynamic: 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!
Beta Was this translation helpful? Give feedback.
All reactions