Rules engine prevents VirtualAlloc events propagation

[iterat0r]

Testing new feature to trigger Yara scan when VirtualAlloc with RWX flags occurs, I notice this event is not being captured when rules engine is enabled since the scan does not start after calling VirtualAlloc form multiples processes and works only in three scenarios:

1. Compiling Fibratus with Yara feature only (this is the setup used to implement scan trigger after VirtualAlloc w/ RWX)
2. Enabling forwarding (which disables the rule engine)
3. Deleting the rules files to prevent loading them into Fibratus app (so it can be a filter which propagates itself to events processing).

I tried to determine where this happens in the source code, but I thought developers could find the issue or identify if it is a bug or not much faster.

[rabbitstack]

The rule engine dynamically enables/disables events. It does so by parsing the entire ruleset and extracting all event types referenced in the rules. If the event is not used by any rules, it is discarded early in the processing pipeline to alleviate the load, and don't pay the price for something that is not used anyway. Makes sense, right? What we need is an extra condition in the event discarding logic to allow VirtualAlloc events if the YARA scanner is enabled.

Could you please raise a separate issue for the second problem including the exact commands that you're using to trigger the rules and if possible, generate a capture while those commands are executed to ease the troubleshooting? In 2.2.1, rules were adjusted to reduce the false positive rate, so that may explain why you're getting fewer alerts. Nevertheless, if you don't get a match each time for the same input, that could indicate a possible bug in the code.

Thanks!

[iterat0r]

Hi @rabbitstack ok, I'm going to check this out... thanks

[iterat0r]

@rabbitstack, the filter you mentioned works, it would be like this in controller_windows.go/NewController :

if ktype == ktypes.VirtualAlloc && c.Yara.Enabled {
        c.Kstream.EnableMemKevents = true
	continue
}

Another option is to allow precedence of the config file over the rules compilation by removing c.Kstream.EnableMemKevents = r.HasMemEvents, of course user has to enable memory events first (this was the first thing I tried to make the yara scan for virtualalloc to work). In this case the filter would be:

if ktype == ktypes.VirtualAlloc && c.Yara.Enabled {
	continue
}

Let me know if this has sense for you to make the PR

[rabbitstack]

In my opinion, the first proposal makes more sense. Just a nit. Reverse the conditions such as:

if c.Yara.Enabled && ktype == ktypes.VirtualAlloc {
        c.Kstream.EnableMemKevents = true
	continue
}

If you're willing to submit the PR and link it to this issue, I would be grateful. TIA!