Closed subvert0r closed 5 months ago
Hi @subvert0r ,
Thanks for raising this issue. Under which circumstances do you observe lost events, i.e. rule context or when setting the filter with both event type and registry key name conditions?
I would be happy to jump in and triage this. ETW keeps a series of session buffers. Events may be lost if all buffers are full and the consumer can't keep up with the event rate. Also mind, events may arrive with a certain amount of delay (30s or more).
I'm have already invested some time to improve the response speed. Starting from 2.2.0, system providers will be able to run in its own session as per https://github.com/rabbitstack/fibratus/pull/245. Initial testing is revealing one second granularity alerts originated by runtime rules. For example, trying to dump LSASS memory, triggers the respective rule immediately.
Hey @subvert0r ,
Did you have a chance to follow up with this?
Steps to reproduce :
PPLBlade creates a service (and deletes it very quick after loading the driver) which causes
services.exe
to set values related to service creation inHKLM\System\CurrentControlSet\Services\PPLBlade
When logging
RegSetValues
withProcmon
, I can see that for exampleservices.exe
creates theImagePath
value under that registry path and does aRegSetValue
for setting it's value, but Fibratus doesnt log this. Ran it many times, all failed.Overall It seems like Fibratus does miss a lot of
RegSetValues
, could this be a limitation of ETW which Fibratus is using to log registry writes? I have tweaked with ETW kernel trace and user trace for registry operations before, and remember that sometimes it only provided partial registry path in some registry events, could this be the reason fibratus is missing some registry operations altogether?