I had to zoom out to 80% to avoid have the left-hand menu from overlapping the text in the middle of the screen... and then I realized there was a collapse button at the bottom of the menu. Personally I think that's something the owner may want to consider tweaking the default on -- I was confused for a good 45 seconds.
Aside from that.... looks like a neat tool! Going to play with it on my win10 box.
Besides it is:
- fully programmable and extensible with Python scripts
- has out of the box alerting
- support for capture files
- highly customizable regarding transporting events to output sinks
Another one might be when a network user changes a file on a share. Let's say this is running on the file server - presumably we get the local process name, and presumably it would be running as Network Service or similar, so we wouldn't get the user that actually made the change?
Each kernel event contains a series of canonical fields that describe the nature of the event such as its name, the process identifier that generated the event and such. The following is the list of all canonical fields.
Sequence is a monotonically increasing integer value that uniquely identifies an event. The sequence value is guaranteed to increment monotonically as long as the machine is not rebooted. After the restart, the sequence is restored to the zero value.
PID represents the process identifier that triggered the kernel event.
TID is the thread identifier connected to the kernel event.
CPU designates the logical CPU core on which the event was originated.
Name is the human-readable event name such as CreateProcess or RegOpenKey.
Timestamp denotes the timestamp expressed in nanosecond precision as the instant the event occurred.
Category designates the category to which the event pertains, e.g. file or thread. Each particular category is explained thoroughly in the next sections.
Description is a short explanation about the purpose of the event. For example, CreateFile kernel event creates or opens a file, directory, I/O device, pipe, console buffer or other block/pseudo device.
Host represents the host name where the event was produced.
Parameters
Also called as kparams in Fibratus parlance, contain each of the event's parameters. Internally, they are modeled as a collection of key/value pairs where the key is mapped to the structure consisting of parameter name, parameter type and the value. An example of the parameter tuple could be the dip parameter that denotes a destination IP address with value 172.17.0.2 and therefore IPv4 type. Additionally, parameter types can be scalar values, strings, slices, enumerations, and timestamps among others.
Process state
Each event stores the process state that represents an extended information about the process including its allocated resources such as handles, dynamically-linked libraries, exported environment variables and other attributes. The process state internals are thoroughly explained in the Process events section. (https://github.com/rabbitstack/fibratus/blob/master/docs/kev...)
Metadata
Metadata are an arbitrary sequence of tags in form of key/value pairs that you can squash into the event on behalf of transformers. A tag can be virtually any string data that you find meaningful to either identify the event or apply filtering/grouping once event is persisted in the data store."
PDS: It would be interesting if a future OS -- was completely designed around such a descriptive Event Log at its heart...
That is, the future OS -- would automatically put ALL of its events into such an Event Log in memory, where programmers, through various tools and means (much like Fibratus) could ask it to filter out and log messages of interest, if they had appropriate rights.
Yes, it might be slow to do this... but perhaps there would be software/algorithmic mitigations to that...
For logging/capturing OS events (in this case, Windows 7+, but perhaps in the future, any OS, or future OS'es that are specifically designed for it),
Is it the norm now? I personally find it just a bad UI.