-Fibratus detects, protects, and eradicates advanced adversary tradecraft by scrutinizing
-and asserting a wide spectrum of system events against a behavior-driven [rule engine](https://www.fibratus.io/#/filters/rules) and [YARA](https://www.fibratus.io/#/yara/introduction) memory scanner.
+Fibratus detects and eradicates advanced attacker tradecraft by scrutinizing and asserting a wide spectrum of [system events](https://fibratus.io/docs/telemetry/events) against a behavior-driven [rule engine](https://fibratus.io/docs/rules) and [YARA](https://fibratus.io/docs/yara) memory scanner.
-Events can also be shipped to a wide array of [output sinks](https://www.fibratus.io/#/outputs/introduction) or dumped to [capture](https://www.fibratus.io/#/captures/introduction) files for local inspection and forensics analysis. You can use [filaments](https://www.fibratus.io/#/filaments/introduction) to extend Fibratus with your own arsenal of tools and so leverage the power of the Python ecosystem.
+Events can be routed to a wide range of [output sinks](https://fibratus.io/docs/telemetry/outputs) or written to [capture](https://fibratus.io/docs/captures) files for local inspection and forensic analysis. With [filaments](https://fibratus.io/docs/filaments), you can extend Fibratus with your own tooling and tap into the full power of the Python ecosystem.
-In a nutshell, the Fibratus mantra is defined by the pillars of **realtime behavior detection**, **memory scanning**, and **forensics** capabilities.
+In a nutshell, the Fibratus mantra is built on three pillars: **realtime behavior detection**, **memory scanning**, and **forensics**.
+
-### Installation
-
-- Download the latest [MSI package](https://github.com/rabbitstack/fibratus/releases) and follow the [UI](https://www.fibratus.io/#/setup/installation) wizard or
-alternatively install via `msiexec` in silent mode
-
-```
-$ msiexec /i fibratus-2.4.0-amd64.msi /qn
-```
-
-### Quick start
-
----
-
-- spin up a command line prompt
-- list credentials from the vault by using the `VaultCmd` tool
-
-```
-$ VaultCmd.exe /listcreds:"Windows Credentials" /all
-```
-
-`Credential discovery via VaultCmd tool` rule should trigger and emit the alert to the [Eventlog](https://www.fibratus.io/#/alerts/senders/eventlog). Check the short demo [here](https://www.fibratus.io/alerts/senders/images/eventlog.gif).
-
-### Documentation
-
-To fully exploit and learn about Fibratus capabilities, read the [docs](https://www.fibratus.io).
-
-### Rules
-
-Detection rules live in the [`rules`](/rules) directory of this repository. The CLI provides a set of
-commands to explore the rule catalog, validate the rules, or [create a new rule](https://github.com/rabbitstack/fibratus/tree/master/rules#structure) from the template.
+### Installation and Quick start
-To describe all rules in the catalog, use the `fibratus rules list` command. It is possible to pass the
-`-s` flag to show rules summary by MITRE tactics and techniques.
+For installation and [quick start](https://www.fibratus.io/docs/setup/quick-start) instructions, go [here](https://www.fibratus.io/docs/setup/installation).
### Contributing
diff --git a/docs/.nojekyll b/docs/.nojekyll
deleted file mode 100644
index e69de29bb..000000000
diff --git a/docs/CNAME b/docs/CNAME
deleted file mode 100644
index 1a307fbab..000000000
--- a/docs/CNAME
+++ /dev/null
@@ -1 +0,0 @@
-www.fibratus.io
\ No newline at end of file
diff --git a/docs/README.md b/docs/README.md
index 5a797bc87..45e34c7c0 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -1,8 +1,32 @@
-# Welcome to Fibratus Docs!
+# Documentation
-Fibratus documentation is built with [docsify](https://docsify.js.org/#/) site generator. docsify generates the documentation website on the fly by parsing the Markdown files. To preview the docs while you're editing, you can use the `docsify` CLI tool.
+The **`docs/` directory** serves as the canonical source of all user-facing documentation. It contains Markdown files that are not merely static content, but structured inputs consumed by Fibratus’ custom [documentation](https://fibratus.io/docs) engine, which powers the website experience.
-- download [Node.JS](https://nodejs.org/en/download/)
-- `npm install -g docsify`
-- go to the `docs` directory and run `docsify serve`
-- browse the docs on `http://localhost:3000`
+At a high level, this directory is designed to balance **readability for contributors** with **rich rendering capabilities** on the site. While everything is written in Markdown, the files follow conventions and include custom extensions that the rendering engine interprets to produce a more dynamic and navigable documentation UI.
+
+### Purpose and Structure
+
+The `docs/` directory organizes documentation into logical sections such as:
+
+* **Getting started** (installation, quickstart guides)
+* **Core concepts** (filaments, telemetry, rules engine)
+* **Configuration** (YAML/CLI flags, environment setup)
+* **Reference material** (field descriptions, functions, operators)
+
+Each section is typically represented as a subdirectory, with Markdown files forming individual pages. File names and folder hierarchy directly map to the website’s routing and sidebar navigation.
+
+### Custom Markdown Extensions
+
+Although the files use standard Markdown syntax, they also leverage custom directives and components understood by the Fibratus documentation engine. These may include:
+
+* **Admonitions** (e.g., notes, warnings, tips)
+* **Code block enhancements** with syntax highlighting tailored to Fibratus DSLs
+* **Cross-references** that resolve to internal documentation links
+
+### Linking and Navigation
+
+Internal links between documents are written using relative paths, but the engine resolves and validates them at build time. It also:
+
+* Builds the **sidebar tree** from directory structure
+* Generates **breadcrumbs and navigation controls**
+* Ensures **consistent URL routing** across the site
diff --git a/docs/_coverpage.md b/docs/_coverpage.md
deleted file mode 100755
index f8132ec34..000000000
--- a/docs/_coverpage.md
+++ /dev/null
@@ -1,20 +0,0 @@
-
-
-
-
-The email alerts have the following sections:
-
-- Date, time, and the hostname where the alert was triggered
-- Alert severity given by the `severity` attribute
-- Alert title as specified the `name` attribute
-- Alert description as specified by the `output` attribute
-- Links with MITRE tactic, technique, and sub-technique
-- The list of security events involved in the incident. For each event, the name, timestamp, and excerpt are shown. Next, all event attributes and process state information is represented.
-
-#### Killing processes
-
-`kill` action terminates the process involved in matched rule condition. Fibratus needs to acquire the process handle with the `PROCESS_TERMINATE` access rights to successfully kill the process.
-
-```yaml
-action:
- - name: kill
-```
-
-#### Isolating endpoints
-
-`isolate` action isolates the host by installing **Windows Filtering Platform** (WFP) rules. To revert the effects of the `isolate` action, simply restart the Fibratus service. The action can be combined with other actions. For example, the following snippet will kill the process and isolate the endpoint.
-
-
-```yaml
-action:
- - name: kill
- - name: isolate
-```
-
-### Advanced patterns
-
-Adversaries often employ sophisticated techniques which may be daunting to detect without combining events from different data sources. For example, detecting a remote connection attempt followed by the execution of a command shell by the same process that initiated the connection can't be expressed with a simple rule expecting to match on a single event. Enter `sequence` rules.
-
-#### Sequences
-
-In a nutshell, sequences permit state tracking of an ordered series of events over a short period of time. Let's peer into the structure of sequence-powered rules. Sequence rules start with the `sequence` keyword as you can observe in the `LSASS memory dumping via legitimate or offensive tools` rule's condition. Sequence consists of two or more expressions surrounded by vertical bars or pipes. For the sequence to match, all expressions need to match successively in time.
-
-```yaml
-name: LSASS memory dumping via legitimate or offensive tools
-id: 335795af-246b-483e-8657-09a30c102e63
-version: 1.0.0
-description: |
- Detects an attempt to dump the LSAAS memory to the disk by employing legitimate
- tools such as procdump, Task Manager, Process Explorer or built-in Windows tools
- such as comsvcs.dll.
-labels:
- tactic.id: TA0006
- tactic.name: Credential Access
- tactic.ref: https://attack.mitre.org/tactics/TA0006/
- technique.id: T1003
- technique.name: OS Credential Dumping
- technique.ref: https://attack.mitre.org/techniques/T1003/
- subtechnique.id: T1003.001
- subtechnique.name: LSASS Memory
- subtechnique.ref: https://attack.mitre.org/techniques/T1003/001/
-references:
- - https://redcanary.com/threat-detection-report/techniques/lsass-memory/
- - https://www.deepinstinct.com/blog/lsass-memory-dumps-are-stealthier-than-ever-before
-
-condition: >
- sequence
- maxspan 2m
- by ps.uuid
- |open_process
- and
- ps.access.mask.names in ('ALL_ACCESS', 'CREATE_PROCESS', 'VM_READ')
- and
- kevt.arg[exe] imatches '?:\\Windows\\System32\\lsass.exe'
- and
- not
- ps.exe imatches
- (
- '?:\\Windows\\System32\\svchost.exe',
- '?:\\ProgramData\\Microsoft\\Windows Defender\\*\\MsMpEng.exe'
- )
- |
- |write_minidump_file|
-
-output: >
- Detected an attempt by `%1.ps.name` process to access and read
- the memory of the **Local Security And Authority Subsystem Service**
- and subsequently write the `%2.file.name` dump file to the disk device
-severity: critical
-
-min-engine-version: 2.0.0
-```
-
-The sequence behavior can be controlled by the following statements:
-
-- `maxspan` defines the time window in duration units, such as `2s`, `2m`, or `2h` for two minutes, two hours, and two days respectively. The time window dictates how long each expression in the sequence is expecting to wait for events that could result in expression evaluating to true. For example, by examining the above snippet, the sequence starts by detecting process handle acquisition on the `lsass` process. Since this is the first expression in the sequence, the time window constraint doesn't kick in yet. After the first expression evaluates to true, the next one, expecting to detect creation of the minidump file, will evaluate only if the `CreateFile` event arrives within the 2 minutes time frame. Otherwise, the deadline is reached and the entire sequence is discarded.
-- `by` enables event stitching by any of the [filter fields](filters/fields). It guarantees that only events sharing certain properties will be eligible for matching. Continuing the example from previous rule, the sequence can match only if `OpenProcess` and `CreateFile` events are generated by the same process. Specifically, events are joined by the `ps.uuid` field which is meant to offer a more robust version of the `ps.pid` field that is resistant to being repeated. A variation of the `by` statement allows establishing a joining criteria separately on each expression in the sequence. Let's take a look at the following rule:
-
-```yaml
-sequence
-maxspan 1h
- |write_file
- and
- file.extension iin executable_extensions
- and
- ps.name iin msoffice_binaries
- | by file.name
- |spawn_process
- and
- ps.name iin msoffice_binaries
- | by ps.child.exe
-```
-
-As we can observe, the `by` statement is anchored to each expression but using a different join field. This rule would only match if the file being written is equal to the spawned process executable image.
-Of course, it is possible to omit both `maxspan` and `by` statements. However, such rules are rarely used to express behaviors that require relationships between events, instead, a mere temporally connection.
-
-#### Aliases
-
-In certain situations, expressing event stitching relations may require more complex heuristics. Imagine a detection rule checking the presence of a created filename against the list of values obtained in subsequent sequence expression. An avid reader may immediately realize this sort of joining is not attainable by means of the `by` statement. Luckily, a more flexible solution exists in form of the `as` statement. This statement allows creating aliases which can be referenced in sequence expressions by using **bound fields**. Bound field is essentially a regular filter field prefixed with an alias. Let's see another example.
-
-```yaml
-sequence
-maxspan 5m
- |create_file
- and
- file.name imatches '?:\\Windows\\System32\\*.dll'
- | as e1
- |modify_registry
- and
- registry.key.name ~= 'HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa\\Notification Packages'
- and
- get_reg_value(registry.key.name) iin (base($e1.file.name, false))
- |
-```
-
-The first expression in the sequence detects the creation of a DLL file in the system directory. Once this expression evaluates to true, the event that triggered it is accessible via the `e1` alias. The second expression will detect registry modifications on the specified value, and if eligible, it will use the `get_reg_value` function to query the value, which, in this case,contains the `MULTI_SZ` content. The retrieved list of strings is compared against the filename from the event matching the first expression. The `$e1.file.name` bound field is responsible for consulting the filename field value from the referenced expression's matching event.
diff --git a/docs/images/architecture.png b/docs/images/architecture.png
new file mode 100644
index 000000000..bb2d30437
Binary files /dev/null and b/docs/images/architecture.png differ
diff --git a/docs/images/callstacks.png b/docs/images/callstacks.png
new file mode 100644
index 000000000..d3103f43f
Binary files /dev/null and b/docs/images/callstacks.png differ
diff --git a/docs/images/fibratus-term.gif b/docs/images/fibratus-term.gif
deleted file mode 100644
index 32027b7bb..000000000
Binary files a/docs/images/fibratus-term.gif and /dev/null differ
diff --git a/docs/images/fibratus-term.png b/docs/images/fibratus-term.png
deleted file mode 100755
index 4ed41e31b..000000000
Binary files a/docs/images/fibratus-term.png and /dev/null differ
diff --git a/docs/images/filter.png b/docs/images/filter.png
new file mode 100644
index 000000000..640612d2a
Binary files /dev/null and b/docs/images/filter.png differ
diff --git a/docs/images/invalid-filter.png b/docs/images/invalid-filter.png
new file mode 100644
index 000000000..0d5b29a5f
Binary files /dev/null and b/docs/images/invalid-filter.png differ
diff --git a/docs/images/realtime-detection.gif b/docs/images/realtime-detection.gif
new file mode 100644
index 000000000..a461ba54d
Binary files /dev/null and b/docs/images/realtime-detection.gif differ
diff --git a/docs/images/rule-format.png b/docs/images/rule-format.png
new file mode 100644
index 000000000..4a2b49318
Binary files /dev/null and b/docs/images/rule-format.png differ
diff --git a/docs/images/telemetry-exploration.gif b/docs/images/telemetry-exploration.gif
new file mode 100644
index 000000000..165042789
Binary files /dev/null and b/docs/images/telemetry-exploration.gif differ
diff --git a/docs/index.html b/docs/index.html
deleted file mode 100755
index 26051212e..000000000
--- a/docs/index.html
+++ /dev/null
@@ -1,59 +0,0 @@
-
-
-
-
- Fibratus
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
diff --git a/docs/kevents/anatomy.md b/docs/kevents/anatomy.md
deleted file mode 100755
index 2b9ef3199..000000000
--- a/docs/kevents/anatomy.md
+++ /dev/null
@@ -1,82 +0,0 @@
-# Anatomy Of An Event
-
-The **Event** or `kevent` as referred to in Fibratus internal lingo is the fundamental building block that encapsulates the state of the event. The [ETW](https://docs.microsoft.com/en-us/windows/win32/etw/event-tracing-portal) **Kernel Logger** provider produces the flow of events in their raw format. This means that the vast majority of the event's parameters lack a meaningful context needed for an intuitive human interpretation. To clarify the previous statement, here are some concrete examples:
-
-- registry keys containing partial paths are typically not very useful. Think of `Settings/Control Panel` key that actually represents the fully qualified `HKEY_CURRENT_USER/Settings/Control Panel` path. Fibratus makes sure to run a hook in the early stage of the kernel event stream to figure out the remaining key name. Aside from this, root keys are represented in the native object manager format, e.g. `REGISTRY\MACHINE` is the key name for the `HKEY_CURRENT_MACHINE` root level key. Fibratus normalizes native root keys to well-known names.
-- missing file names in `ReadFile` or `WriteFile` events. These events only contain the address of the file object that obviously doesn't give any hints about the file involved in the I/O operation. Fibratus strives for a best-effort file name resolution. Similarly to native registry key names, the Kernel Logger emits files names in DOS device name format, e.g. `Device\HardDisk4\Windows\System32\kernel32.dll`. Fibratus maps DOS device names to drive letters.
-- handle type names are given as integer values. Fibratus takes care of mapping type identifiers to human-readable handle type names such as `File`, `Mutant` or `Key`.
-
-However, this is not the only heavy-lifting task Fibratus does to produce high-quality events. Additionally, events are enriched with various parameters that are not originally present in the ETW payloads.
-
-### Canonical fields
-
-Each 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 event.
-- **TID** is the thread identifier connected to the 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. Possible category types are: `registry`, `file`, `net`, `process`, `thread`, `image` and `handle`.
-- **Description** is a short explanation about the purpose of the event. For example, `CreateFile` 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](/kevents/process) events section.
-
-### Callstack
-
-Callstack reconstructs the sequence of function calls that led to the current thread state. When stack enrichment is enabled (controlled by the `--kstream.stack-enrichment` configuration flag), return addresses obtained directly from kernel space, are symbolized and enriched with a vital context that can be leveraged to boost behavioral detections and reduce false positive alerts. A typical callstack summary is depicted in the snippet above:
-
-```
-0x7ffb5c1d0396 C:\WINDOWS\System32\KERNELBASE.dll!CreateProcessW+0x66
-0x7ffb5d8e61f4 C:\WINDOWS\System32\KERNEL32.DLL!CreateProcessW+0x54
-0x7ffb5c1d0396 C:\WINDOWS\System32\KERNELBASE.dll!CreateProcessW+0x61
-0x7ffb3138592e C:\Program Files\JetBrains\GoLand 2021.2.3\jbr\bin\java.dll!Java_java_lang_ProcessImpl_waitForTimeoutInterruptibly+0x3a2
-0x7ffb313853b2 C:\Program Files\JetBrains\GoLand 2021.2.3\jbr\bin\java.dll!Java_java_lang_ProcessImpl_create+0x10a
-0x2638e59e0a5 unbacked!?
-```
-
-Each line is comprised of:
-
-- function call return address (e.g. `0x7ffb5c1d0396`)
-- full path of the image/module containing the executed function. If the call is invoked from a floating memory region, then the module name is marked as `unbacked`
-- name of the symbol mapping to the return address (e.g. `CreateProcessW`)
-- offset within the function body
-
-Stack enrichment is performed for the following event set:
-
-- `CreateProcess`
-- `CreateThread`
-- `TerminateThread`
-- `SetThreadContext`
-- `LoadImage`
-- `RegCreateKey`
-- `RegDeleteKey`
-- `RegSetValue`
-- `RegDeleteValue`
-- `CreateFile`
-- `DeleteFile`
-- `RenameFile`
-- `VirtualAlloc`
-- `OpenProcess`
-- `OpenThread`
-- `CreateSymbolicLinkObject`
-- `SubmitThreadpoolWork`
-- `SubmitThreadpoolCallback`
-- `SetThreadpoolTimer`
-
-
-To enable stack enrichment for kernel space return addresses, the `symbolize-kernel-addresses` config option needs to be set to `true`. Callstack data is used by [filter fields](/filters/fields?id=callstack) to permit crafting advanced detection rules.
-
-### 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](/transformers/introduction). 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.
diff --git a/docs/kevents/driver.md b/docs/kevents/driver.md
deleted file mode 100644
index 9ceeab740..000000000
--- a/docs/kevents/driver.md
+++ /dev/null
@@ -1,15 +0,0 @@
-# Driver events
-
-#### LoadDriver
-
-Driver loading events are triggered when the driver object is loaded into the kernel. Regular `LoadImage` events are triggered when the kernel driver is loaded or when the driver is unloaded, the `UnloadImage` event is received.
-
-An alternative route for detecting driver loading events is based on observing the [handle manager](kevents/handle.md) events. For example, a filter expression for pinpointing such events could be arranged as follows.
-
-```
-kevt.name = 'CreateHandle'
- and
-handle.type = 'Driver'
-```
-
-Rule writers are encouraged to use the `load_driver` macro from the [macro library](https://github.com/rabbitstack/fibratus/blob/master/rules/macros/macros.yml). This macro seamlessly handles the detection of driver loading depending on whether direct events are available or handle manager tracking is required.
diff --git a/docs/kevents/file.md b/docs/kevents/file.md
deleted file mode 100755
index 4234ac20d..000000000
--- a/docs/kevents/file.md
+++ /dev/null
@@ -1,112 +0,0 @@
-# File events
-
-File events encompass a variety of file system related activities such as creating or opening directories/files/devices, writing or reading data, altering file metadata and so on.
-
-#### CreateFile
-
-The `CreateFile` event is triggered when the kernel serves create/open requests for files or I/O devices. The most commonly used I/O devices are as follows: file, file stream, directory, physical disk, volume, console buffer, tape drive, communications resource, mailslot, and pipe. `CreateFile` events have the following parameters:
-
-- `file_object` is the file object pointer as seen from the kernel perspective. You can use this parameter to correlate file events.
-- `file_name` represents the file/directory or device name (e.g. `C:\ProgramData\AVG\Antivirus\psi.db-journal`)
-- `irp` is the I/O request packet value that identifies the file system activity.
-- `tid` is the thread identifier that initiated the I/O operation.
-- `create_disposition` identifies the file system operation performed on the file or device:
- - `SUPERSEDE` replaces the file if it already exists, otherwise creates a new file
- - `OPEN` opens the file if it exists
- - `CREATE` creates a new file or fails if the file already exists
- - `OPENIF` opens the file if it already exists, otherwise creates a new file
- - `OVERWRITE` opens and overwrites the file if it already exists
- - `OVERWRITEIF` opens and overwrites the file if it already exists, otherwise creates a new file
-- `create_options` the options to be applied when creating or opening the file, as a compatible combination of the following values: `DIRECTORY_FILE`,`WRITE_THROUGH`, `SEQUENTIAL_ONLY`, `NO_INTERMEDIATE_BUFFERING`, `SYNCHRONOUS_IO_ALERT`, `SYNCHRONOUS_IO_NONALERT`, `NON_DIRECTORY_FILE`, `CREATE_TREE_CONNECTION`, `COMPLETE_IF_OPLOCKED`, `NO_EA_KNOWLEDGE`, `OPEN_REMOTE_INSTANCE`, `RANDOM_ACCESS`, `DELETE_ON_CLOSE`,`OPEN_BY_FILE_ID`, `FOR_BACKUP_INTENT`, `NO_COMPRESSION`, `OPEN_REQUIRING_OPLOCK`,`DISALLOW_EXCLUSIVE`, `RESERVE_OPFILTER`, `OPEN_REPARSE_POINT`, `OPEN_NO_RECALL` and `OPEN_FOR_FREE_SPACE_QUERY`.
-- `share_mask` specifies the sharing mode of the file or device, which can be the combination of `READ`, `WRITE`, and `DELETE` values. This flag determines the permission granularity which enables a process to share a file or device while another process has the file or device open.
-- `type` defines the file type. Possible values are `File`, `Directory`, `Pipe`, `Console`, `Mailslot`, `Other`, `Unknown`.
-- `attributes` denotes the file attributes. Possible values are `READONLY`, `HIDDEN`, `SYSTEM`, `DIRECTORY`, `COMPRESSED`, `ENCRYPTED`, `JUNCTION`, `SPARSE`,`TEMPORARY`, `DEVICE`, `NORMAL`, `OFFLINE`, `UNINDEXED`, `STREAM`, `VIRTUAL`, `NOSCRUB`, `RECALLOPEN`, `RECALLACCESS`, `PINNED`, `UNPINNED`, `UNKNOWN`.
-- `status` represents the system status message (e.g. `Success`)
-- `is_dll` determines if the created file is a DLL object. Only present when `create_disposition != OPEN`.
-- `is_driver` determines if the created file is a driver. Only present when `create_disposition != OPEN`.
-- `is_exec` determines if the created file is an executable image. Only present when `create_disposition != OPEN`.
-
-#### WriteFile and ReadFile
-
-These events occur when a process writes data to a file or reads data from the file or I/O device. They contain the following parameters:
-
-- `file_object` is the file object pointer as seen from the kernel perspective. You can use this parameter to correlate file events.
-- `file_name` represents the file/directory or device name the data is written to or read from.
-- `irp` is the I/O request packet value that identifies the file system activity.
-- `io_size` specifies the number of bytes read or written.
-- `offset` determines the offset in the file where the data is read or written.
-- `type` defines the file type. Possible values are `File`, `Directory`, `Pipe`, `Console`, `Mailslot`, `Other`, `Unknown`.
-
-
-#### DeleteFile
-
-Removes the file from the file system. This event contains the following parameters:
-
-- `file_object` is the file object pointer as seen from the kernel perspective. You can use this parameter to correlate file events.
-- `file_name` represents the file/directory that was removed
-- `irp` is the I/O request packet value that identifies the file system activity.
-- `type` defines the file type. Possible values are `File`, `Directory`, `Pipe`, `Console`, `Mailslot`, `Other`, `Unknown`.
-
-#### RenameFile
-
-Renames the file or directory in the file system.
-
-- `file_object` is the file object pointer as seen from the kernel perspective.
-- `file_name` represents the file/directory that was renamed.
-- `irp` is the I/O request packet value that identifies the file system activity.
-- `type` defines the file type. Possible values are `File`, `Directory`, `Pipe`, `Console`, `Mailslot`, `Other`, `Unknown`.
-
-#### CloseFile
-
-Closes the handle to opened file. This event is excluded by default.
-
-- `file_object` is the file object pointer as seen from the kernel perspective.
-- `file_name` represents the file/directory that was closed.
-- `irp` is the I/O request packet value that identifies the file system activity.
-- `type` defines the file type. Possible values are `File`, `Directory`, `Pipe`, `Console`, `Mailslot`, `Other`, `Unknown`.
-
-
-#### SetFileInformation
-
-Sets the file information for the file according to the file information class.
-
-- `class` identifies the file information class. For example, the `Basic` information class means the process altered file timestamps or basic attributes. Refer to [this](https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/ne-wdm-_file_information_class) link for a full list of the file information class enumerations.
-- `file_object` is the file object pointer as seen from the kernel perspective.
-- `file_name` represents the file whose information class was set.
-- `irp` is the I/O request packet value that identifies the file system activity.
-- `type` defines the file type. Possible values are `File`, `Pipe`, `Mailslot`, `Other`, `Unknown`.
-
-
-#### EnumDirectory
-
-The `EnumDirectory` event is triggered in response to directory enumeration requests.
-
-- `dir` specifies the directory that was requested for enumeration.
-- `file_name` is the pattern for directory enumeration.
-- `class` identifies the requested directory enumeration class.
-- `file_object` is the file object pointer as seen from the kernel perspective.
-- `irp` is the I/O request packet value that identifies the file system activity.
-
-#### MapViewFile
-
-Maps a view of a file mapping into the process address space. These events contain the following parameters:
-
-- `file_key` is the address of the file object for which the mapping is performed.
-- `offset` represents the file offset where the view is to begin.
-- `pid` is the process identifier where the file mapping is performed.
-- `protection` specifies the page protection of the file mapping object. Can be the compatible combination of the following values: `READONLY`, `EXECUTE`, `EXECUTE_READ`, `READWRITE`, `WRITECOPY`, `NOCACHE`, `EXECUTE_WRITECOPY` and `EXECUTE_READWRITE`.
-- `section_type` describes the type of the mapped section. It can be `DATA`, `IMAGE`, `IMAGE_NO_EXECUTE`, `PAGEFILE` or `PHYSICAL`.
-- `view_base` is the base memory address in the process address space where mapping begins.
-- `view_size` represents the number of bytes of a file mapping to map to a view.
-
-#### UnmapViewFile
-
-Unmaps a mapped view of a file from the process's virtual address space.
-
-- `file_key` is the address of the file object for which the unmapping is performed.
-- `offset` represents the file offset where the view to unmap begins.
-- `pid` is the process identifier where the file unmapping is performed.
-- `protection` specifies the page protection of the file mapping object that is being unmapped. Can be the compatible combination of the following values: `READONLY`, `EXECUTE`, `EXECUTE_READ`, `READWRITE`, `WRITECOPY`, `NOCACHE`, `EXECUTE_WRITECOPY` and `EXECUTE_READWRITE`.
-- `section_type` describes the type of the unmapped section. It can be `DATA`, `IMAGE`, `IMAGE_NO_EXECUTE`, `PAGEFILE` or `PHYSICAL`.
-- `view_base` is the base memory address in the process address space where unmapping begins.
-- `view_size` represents the number of bytes of a file mapping to unmap.
diff --git a/docs/kevents/handle.md b/docs/kevents/handle.md
deleted file mode 100755
index a67144b17..000000000
--- a/docs/kevents/handle.md
+++ /dev/null
@@ -1,40 +0,0 @@
-# Handle events
-
-The object manager produces handle events to provision or dispose Windows resources allocated to processes. Resources can be threads, registry keys, files, synchronization primitives and so on.
-
-!> Handle events can be quite voluminous and they are disabled by default. To enable the collection of handle events either run Fibratus with the `--kstream.enable-handle=true` flag or activate them permanently by editing the config file.
-
-#### CreateHandle
-
-Provisions a new handle in the address space of the calling process. The following parameters are associated with the `CreateHandle` event:
-
-- `handle_id` represents the unique identifier of the handle.
-- `handle_object` represents the address of the kernel object to which the handle is associated
-- `handle_name` denotes the handle name. (e.g. `\RPC Control\OLEA61B27E13E028C4EA6C286932E80`)
-- `type_id` designates the handle type. (e.g. `ALPC Port`, `File`, `Key`)
-
-#### CloseHandle
-
-The `CloseHandle` event is triggered when the handle is released by the process. It contains the same set of parameters found in the `CreateHandle` event.
-
-#### DuplicateHandle
-
-This event is fired when the process duplicates an object handle. The following parameters are present in `DuplicateHandle` events:
-
-- `handle_id` represents the duplicated handle identifier.
-- `handle_object` represents the address of the duplicated kernel object
-- `handle_source_id` represents the identifier of the handle to be duplicated.
-- `type_id` designates the duplicated handle type. (e.g. `DxgkCompositionObject`)
-- `pid`, `exe`, `name` represent the source process identifier, process executable path, and the process image name respectively.
-
-### Handle state {docsify-ignore}
-
-During bootstrap, Fibratus builds a snapshot of currently allocated handles. Similarly, when a new process is created Fibratus fetches its handles and attaches them to the process state. However, to optimize memory utilization, the initial handle snapshot and process handle table initialization are disabled by default. You can enable both features by modifying the `--handle.init-snapshot=true` and `--handle.enumerate-handles` config flags respectively or changing the corresponding key in the configuration file.
-
-The handle state contains:
-
-- handle name
-- handle type
-- the address of the kernel object
-- handle identifier
-- additional metadata such as `ALPC` port information or mutant count
diff --git a/docs/kevents/image.md b/docs/kevents/image.md
deleted file mode 100755
index fc700f936..000000000
--- a/docs/kevents/image.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Image events
-
-Image events occur when a process loads/unloads a dynamic linked library, executable or the kernel driver. The loading can happen in the local or remote process. These events are represented by `LoadImage` and `UnloadImage` types respectively. The following list describes all available parameters present in DLL events.
-
-- `file_name` denotes the full path name of the image file. (e.g. `C:\Windows\system32\kernel32.dll`)
-- `image_size` represents the image size in bytes.
-- `checksum` represents the image checksum digest.
-- `base_address` is the base address of the process in which the image is loaded/unloaded.
-- `default_address` represents the image's base address.
-- `pid` that specifies the process identifier where the image was loaded/unloaded.
-
-
-Additionally, `LoadImage` events contain the following parameters.
-
-- `is_dll` determines if the image is a DLL object.
-- `is_driver` determines if the image is a kernel driver.
-- `is_exec` determines if the image being loaded is an executable.
diff --git a/docs/kevents/mem.md b/docs/kevents/mem.md
deleted file mode 100644
index 54f160e95..000000000
--- a/docs/kevents/mem.md
+++ /dev/null
@@ -1,24 +0,0 @@
-# Memory events
-
-Memory events include reserving, committing, or freeing the state of a region of pages in the virtual process address space.
-
-#### VirtualAlloc
-
-Allocates, commits, or changes the state of a region of pages in the virtual address space. If the `pid` parameter is different than the calling process id, memory allocation is performed in the address space of another process. `VirtualAlloc` events carry the following parameters:
-
-- `alloc_type` designates the type of memory allocation. It can be the combination of `COMMIT`, `RESERVE`, `RESET`, `RESET_UNDO`, `PHYSICAL`, `LARGE_PAGES`, `TOP_DOWN`, and `WRITE_WATCH`.
-- `base_address` is the starting address of the allocated region.
-- `page_type` represents the type of pages in the allocated region. It can be one of `IMAGE`, `MAPPED`, or `PRIVATE`.
-- `protection` designates the memory protection for the region of allocated pages. It can be the combination of `EXECUTE`, `EXECUTE_READ`, `EXECUTE_READWRITE`, `EXECUTE_WRITECOPY`, `NOACCESS`, `READONLY`, `READWRITE`, `WRITECOPY`, `TARGETS_INVALID`, `TARGETS_NO_UPDATE`, `GUARD`, `NOCACHE`, and `WRITECOMBINE`.
-- `protection_mask` is an abbreviated form of the pages protection flag. e.g. `RWX`
-- `region_size` is the size of the allocated region in bytes.
-- `pid`, `exe`, `name` represent process identifier, process executable path, and the image name of the process into which the region is allocated.
-
-#### VirtualFree
-
-Releases, decommits, or releases and decommits a region of pages within the virtual process address space. If the `pid` parameter is different than the calling process id, memory release is performed in the address space of another process. `VirtualFree` events contain the following parameters:
-
-- `alloc_type` designates the type of free operation that can be `DECOMMIT` or `RELEASE`.
-- `base_address` is the base address of the region of pages to be freed.
-- `region_size` represents the size of the region of memory to be freed, in bytes.
-- `pid`, `exe`, `name` represent process identifier, process executable path, and the image name of the process for which the pages are freed.
diff --git a/docs/kevents/network.md b/docs/kevents/network.md
deleted file mode 100755
index eacdd56d1..000000000
--- a/docs/kevents/network.md
+++ /dev/null
@@ -1,87 +0,0 @@
-# Network events
-
-Interprocess communication via TCP/UDP sockets produces all sorts of network events including, sending and receiving data, retransmitting TCP segments or connecting to sockets.
-
-#### Connect
-
-Establishes a connection to the stream-oriented socket. `Connect` events have the following parameters:
-
-- `dip` represents the destination IPv4/IPv6 address of the communication endpoint.
-- `sip` represents the source IPv4/IPv6 address of the local process.
-- `dport` identifies the destination port.
-- `sport` identifies the source port.
-- `l4_proto` denotes the type of the Layer 4 protocol. Possible values are `tcp`, `udp`.
-- `dport_name` represents the destination port name per [IANA](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt) port to service mappings.
-- `sport_name` represents the source port name per [IANA](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt) port to service mappings.
-
-The remaining network events share the same parameters as the `Connect` event.
-
-#### Accept
-
-Accepts the connection request from the socket queue.
-
-#### Send
-
-Sends data over the wire. The kernel generates `Send` events when a process transports data to local or remote endpoint.
-
-#### Recv
-
-Receives data from the socket. The kernel produces `Recv` events when a process is ready to consume data sent by local or remote socket.
-
-#### Disconnect
-
-Terminates data reception on the socket.
-
-
-#### Reconnect
-
-Reconnects to the socket.
-
-#### Retransmit
-
-Retransmits unacknowledged TCP segments. The kernel networking stack generates retransmissions when packets are dropped due to network congestion, packets arriving out of order and other reasons.
-
-### DNS queries/responses
-
-DNS telemetry uncovers all DNS query/reply interactions. More specifically, `QueryDns` and `ReplyDns` events are fired when the process sends a query to the name server and when it receives the response from the DNS server, respectively. DNS events are collected by default, but it is possible to disable them by setting the `kstream.enable-dns` config flag to `false`.
-
-#### QueryDns
-
-Sends a query to the name server. This event has the following parameters:
-
-- `name` represents the DNS query (e.g. `www.iana.org`)
-- `options` represents the DNS options. It can be the combination of the following values: `STANDARD`, `ACCEPT_TRUNCATED_RESPONSE`, `USE_TCP_ONLY`, `NO_RECURSION`, `BYPASS_CACHE`, `NO_WIRE_QUERY`, `NO_LOCAL_NAME`, `NO_NETBT`,
-`WIRE_ONLY`, `RETURN_MESSAGE`, `MULTICAST_ONLY`, `NO_MULTICAST`, `TREAT_AS_FQDN`, `ADDRCONFIG`, `DUAL_ADDR`, `MULTICAST_WAIT`,
-`MULTICAST_VERIFY`, `DONT_RESET_TTL_VALUES`, `DISABLE_IDN_ENCODING`, `APPEND_MULTILABEL`.
-- `rr` specifies the type of the resource record. It can be one of `A`,`NS`, `MD`, `MF`, `CNAME`, `SOA`, `MB`, `MG`, `MR`, `NULL`, `WKS`, `PTR`,`HINFO`, `MINFO`, `MX`, `TEXT`, `RP`, `AFSDB`, `X25`, `ISDN`, `NSAPPTR`, `SIG`, `KEY`, `PX`, `GPOS`,
-`AAAA`, `LOC`, `NXT`, `EID`, `NIMLOC`, `SRV`, `ATMA`, `NAPTR`, `KX`, `CERT`, `A6`, `DNAME`, `SINK`, `OPT`, `DS`, `RRSIG`,
-`NSEC`, `DNSKEY` `DHCID`, `UINFO`, `UID`, `GID`, `UNSPEC`, `ADDRS`, `TKEY`, `TSIG`, `IXFR`, `AXFR`, `MAILB`, `MAILA`, `ANY`,
-`WINS`, `WINSR`.
-
-#### ReplyDns
-
-Receives the response from the DNS server. DNS reply events contain the following parameters:
-
-- `name` represents the DNS query (e.g. `www.iana.org`)
-- `answers` contains the response answers (e.g. `151.101.194.132`, `151.101.130.132`)
-- `options` represents the DNS options. It can be the combination of the following values: `STANDARD`, `ACCEPT_TRUNCATED_RESPONSE`, `USE_TCP_ONLY`, `NO_RECURSION`, `BYPASS_CACHE`, `NO_WIRE_QUERY`, `NO_LOCAL_NAME`, `NO_NETBT`,
-`WIRE_ONLY`, `RETURN_MESSAGE`, `MULTICAST_ONLY`, `NO_MULTICAST`, `TREAT_AS_FQDN`, `ADDRCONFIG`, `DUAL_ADDR`, `MULTICAST_WAIT`,
-`MULTICAST_VERIFY`, `DONT_RESET_TTL_VALUES`, `DISABLE_IDN_ENCODING`, `APPEND_MULTILABEL`.
-- `rr` specifies the type of the resource record. It can be one of `A`,`NS`, `MD`, `MF`, `CNAME`, `SOA`, `MB`, `MG`, `MR`, `NULL`, `WKS`, `PTR`,`HINFO`, `MINFO`, `MX`, `TEXT`, `RP`, `AFSDB`, `X25`, `ISDN`, `NSAPPTR`, `SIG`, `KEY`, `PX`, `GPOS`,
-`AAAA`, `LOC`, `NXT`, `EID`, `NIMLOC`, `SRV`, `ATMA`, `NAPTR`, `KX`, `CERT`, `A6`, `DNAME`, `SINK`, `OPT`, `DS`, `RRSIG`,
-`NSEC`, `DNSKEY` `DHCID`, `UINFO`, `UID`, `GID`, `UNSPEC`, `ADDRS`, `TKEY`, `TSIG`, `IXFR`, `AXFR`, `MAILB`, `MAILA`, `ANY`,
-`WINS`, `WINSR`.
-- `rcode` designates the DNS response code. It can be one of `NOERROR`, `FORMERR`, `SERVFAIL`, `NXDOMAIN`, `NOTIMP`, `REFUSED`,
-`YXDOMAIN`, `YXRRSET`, `NXRRSET`, `NOTAUTH`, `NOTZONE`, `BADSIG`, `BADKEY`, `BADTIME`, `BADNAME`, `INVALID`, `NXDOMAIN`.
-
-### DNS reverse lookups
-
-Fibratus can perform reverse DNS lookups on IP addresses and return a list of domain names that correspond to a particular IP address.
-
-For example, `47.224.186.35.bc.googleusercontent.com` is the reverse lookup representation of the Google IP address.
-
-You can use domain names in [filters](filters/introduction) in conjunction with the `matches`, `contains` or `in` operators. For example, the following filter would match all events that have at least one domain ending with `.domain.`
-
-```
-net.sip.names matches ('*.domain.')
-```
diff --git a/docs/kevents/object.md b/docs/kevents/object.md
deleted file mode 100644
index beba65ab3..000000000
--- a/docs/kevents/object.md
+++ /dev/null
@@ -1,10 +0,0 @@
-# Object manager events
-
-#### CreateSymbolicLinkObject
-
-`CreateSymbolicLinkObject` event is fired when the symbolic link within the object manager directory. This event has the following parameters:
-
-- `source` identifies the parameter that represents the source symbolic link object or other kernel object.
-- `target` identifies the parameter that represents the target symbolic link object or other kernel object.
-- `desired_access` denotes the access rights for the target symbolic link object. Can be the combination of `DELETE`, `READ_CONTROL`, `WRITE_DAC`, `WRITE_OWNER`, `SYNCHRONIZE`, `STANDARD_RIGHTS_REQUIRED`, `STANDARD_RIGHTS_ALL`, `ACCESS_SYSTEM_SECURITY`, `MAXIMUM_ALLOWED`, `GENERIC_READ`, `GENERIC_WRITE`, `GENERIC_EXECUTE`, `GENERIC_ALL`.
-- `status` represents the outcome of the operation.
\ No newline at end of file
diff --git a/docs/kevents/process.md b/docs/kevents/process.md
deleted file mode 100755
index 5bacbb5d6..000000000
--- a/docs/kevents/process.md
+++ /dev/null
@@ -1,52 +0,0 @@
-# Process events
-
-#### CreateProcess and TerminateProcess
-
-Process events are fired up as a stimulus to the process' life-cycle changes. When the kernel puts into motion a process or terminates it, the `CreateProcess` and `TerminateProcess` events are emitted respectively. The following list summarizes all the distinct event parameters that are associated with process events.
-
-- `pid` is the process' identifier. This value is valid from the time a process is created until it is terminated.
-- `tid` is the thread identifier inside process address space that generated the event.
-- `ppid` represents the parent identifier of the child process. Process identifier numbers are reused, so they only identify a process for the lifetime of that process. It is possible that the process identified by `ppid` is terminated, so `ppid` may not refer to a running process. It is also possible that `ppid` incorrectly refers to a process that reuses a process identifier.
-- `real_ppid` is the process identifier useful for detecting process spoofing.
-- `name` is the process' image name including file extension (e.g. `cmd.exe`).
-- `cmdline` is the full process' command line (e.g. `C:\Windows\system32\cmd.exe /cdir /-C /W`).
-- `exe` is the full name of the process' executable (e.g. `C:\Windows\system32\cmd.exe`)
-- `sid` is the security identifier under which this process is run. (e.g. `S-1-5-18`)
-- `kproc` represents the address of the process object in the kernel.
-- `directory_table_base` represents the address of the directory table that holds process' memory page mappings.
-- `session_id` is the unique identifier for the current session under which process was started or terminated.
-- `status` is the exit status of the started/stopped process.
-- `start_time` designates the instant when the process was started.
-- `domain` represents the domain name under which the process is started.
-- `username` represents the username that started the process.
-- `flags` represents process creation flags. Can be `WOW64`, `PROTECTED`, or `PACKAGED` to designate 32-bit process is created in 64-bit Windows system, process is to be run as a protected process, or a process packaged with the **MSIX** technology respectively.
-
-#### OpenProcess
-
-`OpenProcess` event is triggered when a process tries to acquire an existing local process object. This event contains the following parameters:
-
-- `desired_access` is the hexadecimal value that represents the desired access to the process object.
-- `desired_access_names` is the list of human-readable desired access strings (e.g. `TERMINATE,QUERY_INFORMATION`). For a full list and detailed explanation of available access rights, head to the official [docs](https://docs.microsoft.com/en-us/windows/win32/procthread/process-security-and-access-rights).
-- `name` is the name of the local process that was opened.
-- `exe` is the full path of the local process object that was open.
-- `pid` is the identifier of the local process that was opened.
-- `status` contains the result of the process object open operation. (e.g. `Success`)
-
-### Process state {docsify-ignore}
-
-Fibratus keeps a snapshot of all running processes including their state such as basic process attributes, allocated file handles, dynamically-linked libraries, PE (Portable Executable) metadata and other resources. The snapshot is updated dynamically as processes get spawn or die. Each time a kernel event is triggered, its process' state is fetched from the snapshot and attached to the event. This state machine semantically enriches each individual event with the aim on providing a powerful context for [filtering](/filters/introduction.md) and [scripting](/filaments/introduction.md).
-
-Process state comprises the following attributes and resources:
-
-- process name
-- process identifier as well as its parent process identifier
-- process command line
-- current working directory
-- process SID
-- session identifier
-- environment variables
-- threads
-- modules
-- handles
-- memory mappings
-- PE metadata
diff --git a/docs/kevents/registry.md b/docs/kevents/registry.md
deleted file mode 100755
index 041f777a1..000000000
--- a/docs/kevents/registry.md
+++ /dev/null
@@ -1,49 +0,0 @@
-# Registry events
-
-Registry events are triggered when processes access or modify the registry structure.
-
-#### RegCreateKey
-
-Creates a new registry key or opens the key if it already exists. This event has the following parameters:
-
-- `key_handle` represents the handle to the registry key. In reality, this value represents the address of the KCB (Key Control Block) structure in kernel space.
-- `key_name` is the name of the registry key including the root key. (e.g. `HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control`)
-- `status` contains the result of the registry operation (e.g. `key not found`)
-
-#### RegDeleteKey
-
-Deletes a subkey and all its values. This event has the same group of parameters as the `RegCreateKey` event.
-
-#### RegOpenKey
-
-Opens a registry key. This event has the same group of parameters as the `RegCreateKey` event.
-
-#### RegCloseKey
-
-Closes the registry key. This event has the same group of parameters as the `RegCreateKey` event.
-
-#### RegQueryKey
-
-Enumerates the subkeys of the specified key. The first subkey is referenced by index number 0, the second key by 1, and so on.
-
-- `key_handle` represents the handle to the registry key.
-- `key_name` is the name of the registry key whose subkeys are enumerated.
-- `status` contains the result of the registry operation (e.g. `key not found`)
-
-#### RegQueryValue
-
-Fetches the data associated with the value of a registry key. This event has the same group of parameters as the `RegCreateKey` event, except that the base name of the registry key path is the value name.
-
-#### RegSetValue
-
-Sets the data associated with the value of a registry key. This event contains the following parameters:
-
-- `key_handle` represents the handle to the registry key.
-- `key_name` represents the fully qualified name of the registry value whose data is modified
-- `status` contains the result of the registry operation (e.g. `success`)
-- `value` contains the payload of the value being set
-- `type` represents the registry value type. Possible value are: `REG_DWORD`, `REG_QWORD`, `REG_SZ`, `REG_EXPAND_SZ`, `REG_MULTI_SZ`, `REG_BINARY`, `UNKNOWN`.
-
-#### RegDeleteValue
-
-Deletes the registry value. This event has the same parameters as the `RegCreateKey` event.
diff --git a/docs/kevents/thread.md b/docs/kevents/thread.md
deleted file mode 100755
index 0e9bf8715..000000000
--- a/docs/kevents/thread.md
+++ /dev/null
@@ -1,78 +0,0 @@
-# Thread events
-
-#### CreateThread and TerminateThread
-
-Thread events notify the creation (`CreateThread`) or termination (`TerminateThread`) of threads within the process' address space. In situations where a process spawns a remote thread that runs in other process' address space, the `CreateThread` event is also triggered.
-Thread events are comprised of the following parameters:
-
-- `pid` identifies the process where the thread was created. If this value is not equal to the `pid` of the process generating the event, then the thread is created in remote process.
-- `tid` represents the identifier of the freshly spawn thread.
-- `base_prio` is the scheduler priority of the thread.
-- `page_prio` is a memory page priority hint for memory pages accessed by the thread.
-- `io_prio` represents an I/O priority hint for scheduling I/O operations generated by the thread.
-- `ustack_base` is the base address of the thread's user space stack.
-- `ustack_limit` is the limit of the thread's user space stack.
-- `kstack_base` is the base address of the thread's kernel space stack.
-- `kstack_limit` is the limit of the thread's kernel space stack.
-- `start_address` is the start address of the function to be executed by the thread.
-- `start_address_symbol` the symbol the represents the thread start address (e.g. `LoadLibraryEx`). Only present in `CreateThread` events.
-- `start_address_module` the module that maps to the thread start address (e.g. `ntdll.dll`). Only present in `CreateThread` events.
-- `teb` is the address of the Thread Environment Block (TEB).
-
-
-#### OpenThread
-
-`OpenProcess` event is triggered when a process opens an existing local thread object. This event contains the following parameters:
-
-- `desired_access` is the hexadecimal value that represents the desired access to the thread object.
-- `desired_access_names` is the list of human-readable desired access strings (e.g. `QUERY_LIMITED_INFORMATION`). For a full list and detailed explanation of available access rights, head to the official [docs](https://docs.microsoft.com/en-us/windows/win32/procthread/thread-security-and-access-rights).
-- `name` is the name of the local process whose thread object was open.
-- `exe` is the full path of the local process image whose thread object was open.
-- `pid` is the identifier of the local process whose thread object was opened.
-- `tid` is the identifier of the local thread that was opened.
-- `status` contains the result of the thread object open operation. (e.g. `Success`)
-
-#### SetThreadContext
-
-`SetThreadContext` sets the thread context. Thread context represents the set of CPU registers.
-
-- `status` contains the result of operation. (e.g. `Success`)
-
-## Thread pool events {docsify-ignore}
-
-A thread pool is a collection of worker threads that efficiently execute asynchronous callbacks on behalf of the application. The thread pool is primarily used to reduce the number of application threads and provide management of the worker threads.
-
-
-#### SubmitThreadpoolWork
-
-Enqueues the work item to the thread pool. This event has the following parameters:
-
-- `pool_id` represents the thread pool identifier.
-- `task_id` represents the thread pool task identifier.
-- `callback` represents the address of the callback function.
-- `context` represents the address of the callback context.
-- `subprocess_tag` represents the thread pool identifier.
-- `pool_id` represents the service identifier associated with the thread pool.
-- `callback_symbol` represents the callback symbol (e.g. `RtlCaputreContext`)
-- `callback_module` represents the module containing the callback symbol (e.g. `C:\Windows\System32\ntdll.dll`)
-- `context_rip` represents the value of instruction pointer contained in the callback context.
-- `context_rip_symbol` represents the symbol name associated with the instruction pointer in callback context.
-- `context_rip_module` represents the module name associated with the instruction pointer in callback context.
-
-
-#### SubmitThreadpoolCallback
-
-Submits the thread pool callback for execution within the work item. This event has the same parameter set as the `SubmitThreadpoolWork` events.
-
-
-#### SetThreadpoolTimer
-
-Sets the thread pool timer object. This event consists of the following parameters:
-
-- `duetime` represents the timer due time.
-- `subqueue` represents the memory address of the timer subqueue.
-- `timer` represents the memory address of the timer object.
-- `period` represents the period of the timer.
-- `window` represents the timer tolerate period.
-- `absolute` indicates if the timer is absolute or relative.
-
diff --git a/docs/logo.png b/docs/logo.png
deleted file mode 100644
index 14546ce8a..000000000
Binary files a/docs/logo.png and /dev/null differ
diff --git a/docs/nav.md b/docs/nav.md
deleted file mode 100755
index a095bc7ad..000000000
--- a/docs/nav.md
+++ /dev/null
@@ -1 +0,0 @@
-
fibratus
diff --git a/docs/outputs/console.md b/docs/outputs/console.md
deleted file mode 100644
index 587ed860c..000000000
--- a/docs/outputs/console.md
+++ /dev/null
@@ -1,81 +0,0 @@
-# Console
-
-Console is the default output. It renders the inbound event flow onto the console. The console output tends to reduce the number of I/O syscalls by buffering the incoming event lines.
-
-### Configuration {docsify-ignore}
-
-The console output configuration is located in the `outputs.console` section.
-
-#### enabled
-
-Indicates whether the console output is active.
-
-**default**: `true`
-
-#### format
-
-Specifies the console output format. The `pretty` format dictates that formatting is accomplished by replacing the specifiers in the template. The `json` format outputs the event as a raw JSON string.
-
-**default**: `pretty`
-
-#### kv-delimiter
-
-Specifies the separator that's rendered between the event parameter's key and its value.
-
-**default**: `➜`
-
-#### template
-
-Defines the template that's used in the event formatter. For more details, see the next section.
-
-**default**: `{{ .Seq }} {{ .Timestamp }} - {{ .CPU }} {{ .Process }} ({{ .Pid }}) - {{ .Type }} ({{ .Kparams }})`
-
-### Templates {docsify-ignore}
-
-The template consists of a collection of named placeholders that event formatter replaces with desired values. The syntax of the template resembles the Go [template](https://golang.org/pkg/text/template/) engine constructs, excepts the event formatter lacks advanced templating features such as loops , functions or `if` statements.
-
-The following field modifiers are supported:
-
-- `.Seq`
-- `.Timestamp`
-- `.Pid`
-- `.Ppid`
-- `.Pexe`
-- `.Pcomm`
-- `.Pname`
-- `.Cwd`
-- `.Exe`
-- `.Comm`
-- `.Tid`
-- `.Sid`
-- `.Process`
-- `.Category`
-- `.Description`
-- `.CPU`
-- `.Type`
-- `.Kparams`
-- `.Meta`
-- `.Host`
-- `.PE`
-- `.Kparams.`
-- `.Callstack`
-
-**Examples**
-
-- `{{ .Type }} on file ({{ .Kparams.File_name }})`
-
- renders
-
- `CreateFile on file C:\ProgramData\AVG\Antivirus\psi.db-journal`
-
-- `{{ .Seq }} {{ .Process }} ({{ .Cwd }}) {{ .Ppid }} ({{ .Sid }})`
-
- renders
-
- `1999 cmd.exe (C:/Windows/System32) 2324 (nedo/archrabbit)`
-
-- `{{ .Seq }} {{.CPU}} - ({{.Type}}) Pid: {{ .Kparams.Pid }} {{ .Meta }}`
-
- renders
-
- `1999 4 - (CreateProcess) Pid: 1232 env: prod, az: east`
diff --git a/docs/outputs/elasticsearch.md b/docs/outputs/elasticsearch.md
deleted file mode 100644
index 546899845..000000000
--- a/docs/outputs/elasticsearch.md
+++ /dev/null
@@ -1,173 +0,0 @@
-# Elasticsearch
-
-The Elasticsearch output ships kernel events to the `_bulk` [API endpoint](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-bulk.html). Events are batched and flushed when the interval specified by `flush-period` elapses.
-
-### Configuration {docsify-ignore}
-
-The Elasticsearch output configuration is located in the `outputs.elasticsearch` section.
-
-#### enabled
-
-Indicates whether the Elasticsearch output is enabled.
-
-**default**: `false`
-
-#### servers
-
-Defines the URL endpoints of the Elasticsearch nodes.
-
-**default**: `http://localhost:9200`
-
-#### timeout
-
-Represents the initial HTTP connection timeout when connecting to the Elasticsearch cluster.
-
-**default**: `5s`
-
-#### flush-period
-
-Specifies when to flush the bulk at the end of the given interval.
-
-**default**: `1s`
-
-#### bulk-workers
-
-Determines the number of workers that commit docs to Elasticsearch. Higher values maximize the throughout at the cost of increased CPU utilization.
-
-**default**: `1`
-
-#### healthcheck
-
-Enables or disables nodes health checking.
-
-**default**: `true`
-
-#### healthcheck-interval
-
-Specifies the interval for checking if the Elasticsearch nodes are available.
-
-**default**: `10s`
-
-#### healthcheck-timeout
-
-Specifies the timeout for periodic node health checks.
-
-**default**: `5s`
-
-#### username
-
-Identifies the user name for the basic HTTP authentication.
-
-#### password
-
-Identifies the password for the basic HTTP authentication.
-
-#### sniff
-
-Enables the discovery of all Elasticsearch nodes in the cluster. This avoids populating the list of available Elasticsearch nodes.
-
-**default**: `false`
-
-#### trace-log
-
-Determines if the Elasticsearch client trace log is enabled. Useful for troubleshooting.
-
-**default**: `false`
-
-#### gzip-compression
-
-Determines if the `gzip` compression is enabled for Elasticsearch documents.
-
-**default**: `false`
-
-#### template-name
-
-Specifies the name of the index template.
-
-**default**: `fibratus`
-
-#### template-config
-
-Contains the full JSON body of the index template. For more information refer to [index templates](https://www.elastic.co/guide/en/elasticsearch/reference/current/index-templates.html).
-
-**default**:
-
-```
-{
- "index_patterns": [ "{{ fibratus* }}" ],
- "settings": {
- "index": {
- "refresh_interval": "5s",
- "number_of_shards": 1,
- "number_of_replicas": 1
- }
- },
- "mappings": {
- "properties": {
- "seq": { "type": "long" },
- "pid": { "type": "long" },
- "tid": { "type": "long" },
- "cpu": { "type": "short" },
-
- "name": { "type": "keyword" },
- "category": { "type": "keyword" },
- "description": { "type": "text" },
- "host": { "type": "keyword" },
-
- "timestamp": { "type": "date" },
-
- "kparams": {
- "type": "nested",
- "properties": {
- "dip": { "type": "ip" },
- "sip": { "type": "ip" }
- }
- },
-
- "ps": {
- "type": "nested",
- "properties": {
- "pid": { "type": "long" },
- "ppid": { "type": "long" },
- "name": { "type": "keyword" },
- "comm": { "type": "text" },
- "exe": { "type": "text" },
- "cwd": { "type": "text" },
- "sid": { "type": "keyword" },
- "sessionid": { "type": "short" }
- }
- }
- }
- }
-}
-```
-
-#### index-name
-
-Represents the target index for kernel events. It allows time specifiers to create indices per time frame. For example, `fibratus-%Y-%m` generates the index name with current year and month. Supported time specifiers are:
-
-- `%Y` current year in `YYYY` format (`2020`)
-- `%y` current year in `YY` format (`20`)
-- `%m` current month (`01`)
-- `%d` current day (`02`)
-- `%H` current hour (`15`)
-
-**default**: `fibratus`
-
-#### tls-key
-
-Path to the public/private key file.
-
-#### tls-cert
-
-Path to the certificate file.
-
-#### tls-ca
-
-Represents the path of the certificate file that is associated with the Certification Authority (CA).
-
-#### tls-insecure-skip-verify
-
-Indicates if the chain and host verification stage is skipped.
-
-**default**: `false`
diff --git a/docs/outputs/eventlog.md b/docs/outputs/eventlog.md
deleted file mode 100644
index e1dbc7b4a..000000000
--- a/docs/outputs/eventlog.md
+++ /dev/null
@@ -1,139 +0,0 @@
-# Eventlog
-
-Exports events via [Windows Event Log](https://docs.microsoft.com/en-us/windows/win32/wes/windows-event-log) API that can be explored with the [Event Viewer](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc766042(v=ws.11)) management tool. The screenshots below illustrate event logs produced by Fibratus. The `General` tab reveals the event type that was generated. Each log event pertains to the specific `Task Category` that directly maps to the internal event category. Similar to [sysmon](https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon), Fibratus classifies each event with a custom `Event ID`.
-
-
-
-
-
-The `Details` tab shows extended event data including event parameters, process, and thread information. It is possible to customize the rendering template to influence the constructed event data. This is achieved by changing the [`eventlog.template`](outputs/eventlog?id=template) configuration property.
-
-
+
-There are two flavors of Windows MSI installers:
+Head over to the [downloads](https://fibratus.io/downloads) page and pick your release artifact. Latest releases are recommended as they ship with new features, bug fixes and tend to improve the performance.
-- __full installers__ ship with all features ([captures](captures/introduction), [filaments](filaments/introduction), [yara](yara/introduction)) and bundle the embedded Python distribution
-- __slim installers__ support less features but are more portable and have lower disk space requirements
++> To confirm the integrity of the downloaded MSI, calculate its SHA256 hash and compare it with the hash listed on the release download page. Use this command to compute the SHA256 hash `Get-FileHash -Path fibratus-[version]-amd64.msi -Algorithm SHA256`
+
+!> There are two flavors of Windows MSI packages: **full** and **slim** installers. Full installers ship with all features including [captures](../captures.md), [filaments](../filaments.md), [yara](../yara.md) and bundle the embedded **Python** distribution. Slim installers lack the aforementioned features but have lower disk space footprint.
+
+
+
+
+
+Double-click the MSI package and follow the UI wizard or alternatively install via `msiexec` in silent mode:
+
+
+$ msiexec /i fibratus-[version]-amd64.msi /qn
+
+
+
+
+
The installer will automatically register and start Fibratus as **Windows Service**. To verify if the service is running correctly, spin up a command line prompt and execute the following command:
-```
+
$ fibratus service status
+
Fibratus service is running
-```
-If you're able to see the output like in the snippet above, congratulations! You have successfully installed Fibratus. Jump to [quick start](/setup/quick-start).
+
+
+
+
+
+
+If you're able to see the output like in the terminal above, congratulations! You have successfully installed Fibratus. Jump to [quick start](/setup/quick-start).
+
+
-### Uninstall {docsify-ignore}
+
-To remove Fibratus from your system, head to the **Control Panel > Programs and Features** and start the uninstall process. The uninstaller will make sure to stop/remove the Windows Service and get rid of all installation data.
+### Uninstall
-## Building from source {docsify-ignore}
+To remove Fibratus from your system, head to the **Control Panel > Programs and Features** and start the uninstall process. The uninstaller will make sure to stop/remove the Windows Service and get rid of all installation data. Alternatively, uninstall from the command line with `msiexec`
+
+
+$ msiexec.exe /x fibratus-[version]-amd64.msi
+
+
+
+## Building from source
To build Fibratus directly from source code you have to satisfy the following requirements:
-- Go compiler 1.21+
+- [Go 1.26+](https://go.dev/doc/install)
+- [git](https://git-scm.com/install/windows)
- C compiler (optional)
- Python headers (optional)
- [libyara](https://github.com/VirusTotal/yara/tree/master/libyara) (optional)
-### Installing dependencies {docsify-ignore}
+### Installing dependencies
+
+!> You can skip this step if you're not interested in capture, YARA, and filaments features, as they require interoperability with [`cgo`](https://go.dev/wiki/cgo)
+
+
+
+
+
+[Download](https://www.msys2.org/) the `msys2` installer and follow the instructions [here](https://www.msys2.org/).
+
+
+
+
+Launch the `msys2` shell which by default located in `C:\msys2\msys2.exe`. You can also access it from the `MSYS2 64-bit` Start Menu item.
+
+
+
+
+Install the `MinGW` compiler toolchain along with other dependencies.
+
+
+$ pacman -S base-devel mingw-w64-x86_64-openssl mingw-w64-x86_64-gcc mingw-w64-x86_64-pkg-config automake libtool autoconf
+
+
+
+
+
+
+[Download](https://www.python.org/ftp/python/3.7.9/python-3.7.9-amd64.exe) and install `Python 3.7`. Assuming the Python distribution was installed in `C:\Python37`, set the `PKG_CONFIG_PATH` environment variable to the location of the `pkg-config` directory within the `fibratus` directory.
+
+
+$ set PKG_CONFIG_PATH=[pkg-config absolute path]
+
+
+
+
+
+
+Clone the `yara` repository into the path visible to the `msys2` environment. This is ideally done from the `MSYS2 64-bit` shell. Next, build the `libyara` library.
+
+
+
+$ pacman -S git
+$ git clone https://github.com/VirusTotal/yara.git
+$ cd yara
+$ autoreconf -fiv
+$ ./configure --host=x86_64-w64-mingw32
+$ make install
+
+
+
+
+
+
+
+### Building
+
+Optional dependencies are only required if you plan to build features that interoperate with C code. By default, the Go compiler ignores any features that rely on [cgo](https://golang.org/cmd/cgo/), but you can control which features are included in Fibratus using the following build flags:
+
+- `filament` compiles Fibratus with [filaments](../filaments.md) support
+- `cap` compiles Fibratus with support for capturing/replaying [capture](../captures.md) files
+- `yara` builds Fibratus with [YARA](https://virustotal.github.io/yara/) memory scanning capabilities
+
+!> The build flags are injected via the `TAGS` environment variable. It needs to be set prior to running the build script, for example, running the folllwing snippet from Powershell terminal: `$env:TAGS="filament,cap,yara"`
+
+To build the binary run the following commands from `Powershell` terminal.
+
+
+
+
+
+Clone the Fibratus repository to the location of your choice.
+
+
+$ git clone https://github.com/rabbitstack/fibratus.git
-!> You can skip this step if you're not interested in building features that interop with the C code.
+
-1. Download the `msys2` installer and follow the instructions [here](https://www.msys2.org/).
- - open the `msys2` shell (by default located in `C:\msys2\msys2.exe`). You can also access it from the `MSYS2 64-bit` Start Menu item.
- - install the `MinGW` compiler toolchain along with other dependencies:
- - `pacman -S base-devel mingw-w64-x86_64-openssl mingw-w64-x86_64-gcc mingw-w64-x86_64-pkg-config automake libtool autoconf`
-2. [Download](https://www.python.org/ftp/python/3.7.9/python-3.7.9-amd64.exe) and install the `Python 3.7`. Assuming the Python distribution was installed in `C:\Python37`, set the `PKG_CONFIG_PATH` environment variable to the location of the `pkg-config` directory within the `fibratus` directory.
- - `set PKG_CONFIG_PATH=`
-3. Build `libyara`
- - clone the `yara` repository into the path visible to the `msys2` environment. This is ideally done from the `MSYS2 64-bit` shell.
- - `pacman -S git`
- - `git clone https://github.com/VirusTotal/yara.git`
- - go to the `yara` repository you previously cloned. Run the following commands:
- - `autoreconf -fiv`
- - `./configure --host=x86_64-w64-mingw32`
- - `make install`
+
-### Building the executable {docsify-ignore}
+
-The **optional dependencies are only needed** if you'll be building features that interop with the C code. The Go compiler is instructed to ignore all features that trigger the [cgo](https://golang.org/cmd/cgo/), but you can control which features are built into Fibratus through the following build flags:
+Launch the `make` script to initiate the build process.
-- `filament`: compiles Fibratus with filaments support
-- `kcap`: compiles Fibratus with support for capturing/replaying kcap files
-- `yara`: builds Fibratus with support for [Yara](https://virustotal.github.io/yara/) pattern matching
+
-To build the Fibratus binary without filament, kcap nor yara features, run the following command from the `cmd` shell and within the`fibratus` directory:
+$ cd fibratus
+$ ./make
-```
-$ make
-```
+
-To produce the Fibratus binary with the filaments support, you would run the following commands:
+After compilation completes, the `fibratus.exe` binary can be found in the `cmd\fibratus` directory.
-```
-$ set TAGS=filament
-$ make
-```
+
-In either case, the resulting binary is placed in the `cmd\fibratus` directory.
+
diff --git a/docs/setup/quick-start.md b/docs/setup/quick-start.md
index 4f401b0c0..46d4f2529 100644
--- a/docs/setup/quick-start.md
+++ b/docs/setup/quick-start.md
@@ -1,59 +1,68 @@
-# Quick start
+# Quick Start
-By default, Fibratus operates in rule engine mode. It loads the rule set from the `%PROGRAM FILES%\Fibratus\Rules` directory and sends security alerts to [Eventlog](/alerts/senders/eventlog) or other configurable [sinks](/alerts/senders). Optionally, it takes response actions when the rule is fired, such as killing the process. To see Fibratus in action, we can trigger a rule by performing the following actions:
+##### By default, Fibratus operates in rule engine mode observing the system activity and alerting when the rule policy is violated. Fibratus sends security alerts to [Eventlog](../rules/actions/alert.md) or other configurable [senders](../rules/actions/alert.md) and remmediates threats via response actions. To see Fibratus in action, we can trigger a rule by executing a native Windows binary.
-- spin up a command line prompt
-- list credentials from the vault by using the `VaultCmd` tool
-```
+
+## Realtime Detection
+
+
+
+
+
+Spin up a command line prompt and run the `VaultCmd.exe` command. This command lists the credentials stored in the Credential Manager.
+
+
$ VaultCmd.exe /listcreds:"Windows Credentials" /all
-```
+
+
+
+
+
+
+Hit `⊞ Win` + `R` key combination to bring the Run dialog. Type `evtwvr.msc` to open the Event Viewer snap-in.
+
+
+
+
+
-- `Credential discovery via VaultCmd tool` rule should trigger displaying the alert in the Eventlog `Application` channel.
+Navigate to the Eventlog `Application` channel. `Credential Manager access via known tools` rule should trigger under `Fibratus` event source.
-To learn more about detection rules, head to [rules](/filters/rules).
+
-### Event forwarding {docsify-ignore}
+
-To start forwarding events to [output](/outputs/introduction) sinks, run Fibratus from the command line in event forwarding mode:
+
-```
-$ fibratus service stop
-$ fibratus run --forward
-```
+To learn more about detection rules, head to [rules](../rules.md).
-The continuous stream of events will start rendering on the console.
+## Telemetry Exploration
-```
- ...
-681951 2020-11-07 14:24:57.1839809 +0100 CET - 2 cmd.exe (6328) - CreateFile (file_name➜ C:\WINDOWS\system32\config\systemprofile\AppData\Local\Microsoft\WindowsApps\, file_object➜ ffffa88c7ea077d0, irp➜ ffffa88c746b2a88, operation➜ supersede, share_mask➜ rw-, type➜ directory)
-681952 2020-11-07 14:24:57.1840451 +0100 CET - 2 cmd.exe (6328) - RegOpenKey (key_handle➜ 0, key_name➜ HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsStore, status➜ key not found)
-681953 2020-11-07 14:24:57.1840626 +0100 CET - 2 cmd.exe (6328) - RegOpenKey (key_handle➜ 0, key_name➜ HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\StateSeparation\RedirectionMap\Keys, status➜ key not found)
-681954 2020-11-07 14:24:57.1840751 +0100 CET - 2 cmd.exe (6328) - RegOpenKey (key_handle➜ 0, key_name➜ HKEY_LOCAL_MACHINE\Software\Microsoft\LanguageOverlay\OverlayPackages\en-US, status➜ key not found)
-681955 2020-11-07 14:24:57.1841104 +0100 CET - 2 cmd.exe (6328) - CreateFile (file_name➜ C:\WINDOWS\system32\en-US\cmd.exe.mui, file_object➜ ffffa88c7ea077d0, irp➜ ffffa88c746b2a88, operation➜ open, share_mask➜ r-d, type➜ directory)
-681956 2020-11-07 14:24:57.1848044 +0100 CET - 2 cmd.exe (6328) - TerminateThread (base_prio➜ 8, entrypoint➜ 7ff7762382b0, io_prio➜ 2, kstack➜ fffff10cf0785000, kstack_limit➜ fffff10cf077e000, page_prio➜ 5, pid➜ 6328, tid➜ 11716, ustack➜ d020700000, ustack_limit➜ d020604000)
-681957 2020-11-07 14:24:57.1848713 +0100 CET - 2 cmd.exe (6328) - UnloadImage (base_address➜ 7ff776220000, default_address➜ 7ff776220000, file_name➜ C:\Windows\System32\cmd.exe, image_size➜ 413696, pid➜ 6328)
-681958 2020-11-07 14:24:57.1848779 +0100 CET - 2 cmd.exe (6328) - UnloadImage (base_address➜ 7fffaaba0000, default_address➜ 7fffaaba0000, file_name➜ C:\Program Files\AVG\Antivirus\aswhook.dll, image_size➜ 73728, pid➜ 6328)
-681959 2020-11-07 14:24:57.1848954 +0100 CET - 2 cmd.exe (6328) - UnloadImage (base_address➜ 7fffc97a0000, default_address➜ 7fffc97a0000, file_name➜ C:\Windows\System32\KernelBase.dll, image_size➜ 2764800, pid➜ 6328)
-681967 2020-11-07 14:24:57.184997 +0100 CET - 2 erl.exe (5236) - TerminateProcess (comm➜ C:\WINDOWS\system32\cmd.exe /c handle.exe /accepteula -s -p 5236 2> nul, directory_table_base➜ 2300cb000, exe➜ C:\WINDOWS\system32\cmd.exe, exit_status➜ 1, kproc➜ ffffa88c70ee7080, name➜ cmd.exe, pid➜ 6328, ppid➜ 5236, session_id➜ 0, sid➜ NT AUTHORITY\SYSTEM)
-681968 2020-11-07 14:24:57.1853111 +0100 CET - 2 (6328) - RegOpenKey (key_handle➜ ffffc980980b55f0, key_name➜ HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\bam\State\UserSettings\S-1-5-18, status➜ success)
-681969 2020-11-07 14:24:57.1853224 +0100 CET - 2 (6328) - RegQueryValue (key_handle➜ ffffc980abd657d0, key_name➜ HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\bam\State\UserSettings\S-1-5-18\\Device\HarddiskVolume4\Windows\System32\cmd.exe, status➜ key not found)
-681970 2020-11-07 14:24:57.1853581 +0100 CET - 5 aswidsagent.exe (7812) - CreateFile (file_name➜ C:\WINDOWS\SYSTEM32\CMD.EXE, file_object➜ ffffa88c7a8053e0, irp➜ ffffa88c7b711608, operation➜ open, share_mask➜ rw-, type➜ file)
-681971 2020-11-07 14:24:57.185952 +0100 CET - 4 AVGSvc.exe (4000) - CreateFile (file_name➜ C:\ProgramData\AVG\Antivirus\psi.db-journal, file_object➜ ffffa88c7ea02500, irp➜ ffffa88c73ff8a88, operation➜ supersede, share_mask➜ rw-, type➜ directory)
-681972 2020-11-07 14:24:57.1860706 +0100 CET - 4 AVGSvc.exe (4000) - ReadFile (file_name➜ C:\ProgramData\AVG\Antivirus\psi.db, file_object➜ ffffa88c72c7c260, io_size➜ 16, irp➜ ffffa88c73ff8a88, offset➜ 24, type➜ file)
- ...
-```
+**Detection** and **Protection** is Fibratus' primary operating mode. However, you can access live kernel telemetry by running Fibratus in event forwarder mode as a `CLI` tool.
-Each line is comprised of the following fields:
+!> If Fibratus is already running as Windows Service, **stop** the service before running the CLI tool.
+
+To gain access to the live kernel telemetry, run the following command from an elevataed terminal.
+
+
+$ fibratus run "ps.name = 'svchost.exe'" --forward
+
+
+
+The argument passed to the `run` command is a [filter](../telemetry/filtering.md) expression. You’ll learn more about filters in the upcoming section, but in short, they enable fine-grained inspection of kernel events. In this example, only events generated by the `svchost.exe` process are accepted and streamed to the [output](../telemetry/outputs/outputs.md) sinks.
+
+Once the command is run, a continuous stream of events is rendered on the console, as shown below. [Console](../telemetry/outputs/console.md) is the default output sink, but you can also route the telemetry to Elasticsearch, HTTP or other destinations.
+
+
+
+
+Each individual event line is comprised of the following segments:
- monotonic sequence value
-- timestamp of event occurrence
+- timestamp of event occurrence and the delta from previous event
- CPU where the event was captured
-- the process name and the pid that produced the event
+- process name and the `pid` that produced the event
- event type
- event parameters
-A different [rendering template](/outputs/console?id=templates) can be used to customize the line format or you can opt to change the output format to, for example, JSON.
-
-The console output is the default events output, even though you can route the event flow to [Elasticsearch](https://www.elastic.co/elasticsearch/) or [RabbitMQ](https://www.rabbitmq.com/) sinks, just to name a few. [Learn](/outputs/introduction) more about output sinks.
-
-To stop Fibratus, hit the `Ctr-C` key combination.
+To stop Fibratus CLI, hit the `Ctr` + `C` key combination.
diff --git a/docs/telemetry/callstacks.md b/docs/telemetry/callstacks.md
new file mode 100644
index 000000000..32fc9ae14
--- /dev/null
+++ b/docs/telemetry/callstacks.md
@@ -0,0 +1,42 @@
+# Callstacks
+
+##### Callstack reconstructs the sequence of function calls that led to the current thread state. Return addresses obtained directly from kernel space, are symbolized and enriched with a vital context that can be leveraged to boost behavioral detections and reduce false positive alerts.
+
+By resolving raw instruction pointers into human-readable symbols such as module paths, function names, and offsets, Fibratus enables analysts to trace behavior back to its true origin, even across user-mode and kernel-mode boundaries. This capability is particularly valuable for detecting stealthy or indirect activity as it exposes the full execution path rather than relying solely on the initiating process. Callstacks can be filtered, symbolized, and enriched with metadata, allowing them to be incorporated into [detection rules](../rules/fields.md) and forensic workflows for high-fidelity behavioral analysis.
+
+A typical callstack summary is depicted in the screenshot below, delineating kernel, system, and user frames provenance.
+
+!> For the [console](outputs/console.md) output to render callstack frames, the template shall define the `{{ .Callstack }}` segment. Segments can be customized by overriding the default [rendering template](outputs/console?id=templates).
+
+
+
+Each line corresponds to the frame stack consisting of:
+
+- function call return address, for example, `0x7ffb5c1d0396`
+- full path of the module containing the executed function, such as `C:\Windows\System32\kernel32.dll`. If the call is invoked from a floating memory region, then the module name is marked as `unbacked`
+- name of the symbol mapping to the return address, for example, `CreateProcessAsUserW`
+- offset within the symbol
+
+Stack enrichment is applied to the following event types:
+
+- `CreateProcess`
+- `CreateThread`
+- `TerminateThread`
+- `SetThreadContext`
+- `LoadImage`
+- `RegCreateKey`
+- `RegDeleteKey`
+- `RegSetValue`
+- `RegDeleteValue`
+- `CreateFile`
+- `DeleteFile`
+- `RenameFile`
+- `VirtualAlloc`
+- `OpenProcess`
+- `OpenThread`
+- `CreateSymbolicLinkObject`
+- `SubmitThreadpoolWork`
+- `SubmitThreadpoolCallback`
+- `SetThreadpoolTimer`
+
+Stack enrichment is enabled by default, but can be controlled via `--eventsource.stack-enrichment` configuration flag. To enable stack enrichment for kernel space return addresses, the `symbolize-kernel-addresses` config option needs to be set to `true`
diff --git a/docs/telemetry/evasions.md b/docs/telemetry/evasions.md
new file mode 100644
index 000000000..62325bc59
--- /dev/null
+++ b/docs/telemetry/evasions.md
@@ -0,0 +1,23 @@
+# Evasions
+
+##### The evasion scanner is a behavioral analysis component designed to detect techniques that attempt to bypass traditional monitoring and security controls. It introduces a modular architecture that leverages a set of pluggable *evasion detectors*, each responsible for identifying a specific class of evasion behavior at runtime.
+
+At its core, the evasion scanner operates as a lightweight layer that integrates with the event processing pipeline. Rather than generating standalone alerts, it enriches existing events with additional context when suspicious behavior is observed. This design allows evasion signals to be correlated with other telemetry, preserving full execution context.
+
+Each evasion scanner encapsulates logic for identifying a particular technique. Available scannners focus on detecting [direct](https://docs.redteamleaders.com/offensive-security/defense-evasion/direct-syscall-execution-in-windows) and [indirect](https://redops.at/en/blog/direct-syscalls-vs-indirect-syscalls) system call evasion, where user-mode hooks are bypassed by invoking system calls outside of standard API pathways.
+
+### Evasion behaviour enrichment
+
+When an event is captured, the evasion scanner passes it through the registered detectors. If a detector identifies a known evasion pattern, then the event is annotated with **evasion metadata**. This metadata describes the type of evasion technique observed.
+The enrichment occurs inline, without interrupting the event flow ensuring minimal overhead while still surfacing high-value behavioral signals.
+The evasion metadata is designed to be consumable by the **rule engine**, enabling **precise** and **expressive** detections.
+
+### Direct syscall
+
+**Direct** syscall scanner hunts for adversary techniques to bypass traditional user-mode API monitoring and security
+hooks by invoking system calls directly, but does so in a way that evades detection or analysis.
+A direct syscall bypasses Windows API functions and calls the underlying system call directly using the `syscall` instruction, skipping the `NTDLL` stub that normally performs the transition to kernel mode.
+
+### Indirect syscall
+
+**Indirect** syscall scanner flags attempts to execute the `syscall` instruction diverting the execution flow into a legitimate, clean ntdll stub that performs the syscall on process behalf. This achieves code origin legitimacy, since the execution lands in text of a signed Microsoft `NTDLL` module. Stack frames look identical to a normal API call, which achieves call stack normalization.
diff --git a/docs/telemetry/events.md b/docs/telemetry/events.md
new file mode 100644
index 000000000..b1db9803f
--- /dev/null
+++ b/docs/telemetry/events.md
@@ -0,0 +1,38 @@
+# Anatomy Of An Event
+
+**Event** encapsulates the state that is fundamental for assertion against the rule engine. Most [ETW](https://docs.microsoft.com/en-us/windows/win32/etw/event-tracing-portal) providers such as **Kernel Logger** produce the flow of events in raw format. This means that the vast majority of the event's parameters lack a meaningful context needed for an intuitive human interpretation. To clarify the previous statement, here are some concrete examples:
+
+- Registry keys containing partial paths are typically not very useful. Think of `Settings/Control Panel` key that actually represents the fully qualified `HKEY_CURRENT_USER/Settings/Control Panel` path. Fibratus makes sure to run a hook in the early stage of the event stream to reconstruct the full registry path. Aside from this, root keys are represented in the native object manager format, for example, `REGISTRY\MACHINE` is the key name for the `HKEY_CURRENT_MACHINE` root level key. Fibratus normalizes native root keys to well-known names.
+- Missing file paths in `ReadFile` or `WriteFile` events. These events contain only the address of the file object that obviously doesn't give any hints about the file path involved in the I/O operation. Fibratus strives for a best-effort file name resolution. Similarly to native registry key names, the Kernel Logger emits files names in DOS device name format, for example, `Device\HardDisk4\Windows\System32\kernel32.dll`. Fibratus maps DOS device names to drive letters.
+- Handle type names are given as integer values. Fibratus takes care of mapping type identifiers to human-readable handle type names such as `File`, `Mutant` or `Key`.
+
+This is not the only heavy-lifting tasks Fibratus performs to produce high-quality events. Additionally, events are enriched with various parameters that are not originally present in ETW payloads.
+
+### Canonical fields
+
+Each 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. Canonical fields include:
+
+- `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. On machine reboot, the sequence value is reset.
+- `PID` represents the process identifier that triggered the event
+- `TID` is the thread identifier connected to the event
+- `CPU` designates the logical CPU core on which the event was originated
+- `Name` is the human-readable event name such as `CreateProcess` or `VirtualAlloc`
+- `Timestamp` denotes the timestamp expressed in nanosecond precision as the instant the event occurred
+- `Category` designates the category to which the event pertains, for example, `file` or `thread`
+- `Host` represents the host name where the event was produced
+
+### Parameters
+
+Internally, event parameters are modeled as a collection of key/value pairs. 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. Parameter types can be scalar values, strings, slices, enumerations, and timestamps among others.
+
+### Process state
+
+Each event has attached process state that represents the contextual information about the process including its name, command line, user, token integrity level, allocated resources such as handles, dynamically-linked libraries, environment variables and other attributes. The process state internals are thoroughly explained in the [Process](events/process.md) events section.
+
+### Callstacks
+
+[Callstacks](callstacks.md) provide detailed insight into the execution context of system events by capturing the sequence of function calls (stack frames) that led to a particular action, such as a file write, process creation, or registry state manipulation.
+
+### Metadata
+
+Metadata are arbitrary tags composed of key/value pairs. Event metadata are decorated via [transformers](transformers.md). Tags can hold any string values employed for filtering, grouping or other purposes.
diff --git a/docs/telemetry/events/file.md b/docs/telemetry/events/file.md
new file mode 100644
index 000000000..4bca2bbd7
--- /dev/null
+++ b/docs/telemetry/events/file.md
@@ -0,0 +1,72 @@
+# File Events
+
+##### File events encompass a variety of file system related activities such as creating or opening directories/files/devices, writing or reading data, altering file metadata and so on.
+
+### `CreateFile`
+
+The `CreateFile` event is triggered when the kernel serves create/open requests for files or I/O devices. The most commonly used I/O devices are as follows: file, file stream, directory, physical disk, volume, console buffer, tape drive, communications resource, mailslot, and pipe. `CreateFile` events have the following parameters:
+
+| PARAMETER | DESCRIPTION |
+| :--- | :---- |
+| `file_object` | File object pointer as seen from the kernel perspective. You can use this parameter to correlate file events. |
+| `file_path` | File/directory path or device name, for example, `C:\ProgramData\AVG\Antivirus\psi.db-journal` |
+| `irp` | I/O request packet value that identifies the file system activity. |
+| `tid` | Thread identifier that initiated the I/O operation. |
+| `create_disposition` | Identifies the file system operation performed on the file or device. Can be `SUPERSEDE` (replaces the file if it already exists, otherwise creates a new file), `OPEN` (opens the file if it exists), `CREATE` (creates a new file or fails if the file already exists), `OPENIF` (opens the file if it already exists, otherwise creates a new file), `OVERWRITE` (opens and overwrites the file if it already exists) and `OVERWRITEIF` (opens and overwrites the file if it already exists, otherwise creates a new file). |
+| `create_options` | Options to be applied when creating or opening the file, as a compatible combination of the following values: `DIRECTORY_FILE`, `WRITE_THROUGH`, `SEQUENTIAL_ONLY`, `NO_INTERMEDIATE_BUFFERING`, `SYNCHRONOUS_IO_ALERT`, `SYNCHRONOUS_IO_NONALERT`, `NON_DIRECTORY_FILE`, `CREATE_TREE_CONNECTION`, `COMPLETE_IF_OPLOCKED`, `NO_EA_KNOWLEDGE`, `OPEN_REMOTE_INSTANCE`, `RANDOM_ACCESS`, `DELETE_ON_CLOSE`,`OPEN_BY_FILE_ID`, `FOR_BACKUP_INTENT`, `NO_COMPRESSION`, `OPEN_REQUIRING_OPLOCK`,`DISALLOW_EXCLUSIVE`, `RESERVE_OPFILTER`, `OPEN_REPARSE_POINT`, `OPEN_NO_RECALL` and `OPEN_FOR_FREE_SPACE_QUERY` |
+| `share_mask` | Specifies the sharing mode of the file or device, which can be the combination of `READ`, `WRITE`, and `DELETE` values. This flag determines the permission granularity which enables a process to share a file or device while another process has the file or device open. |
+| `type` | Idefines the file type. Possible values are `File`, `Directory`, `Pipe`, `Console`, `Mailslot`, `Other`, `Unknown` |
+| `attributes` | Denotes the file attributes. Possible values are `READONLY`, `HIDDEN`, `SYSTEM`, `DIRECTORY`, `COMPRESSED`, `ENCRYPTED`, `JUNCTION`, `SPARSE`,`TEMPORARY`, `DEVICE`, `NORMAL`, `OFFLINE`, `UNINDEXED`, `STREAM`, `VIRTUAL`, `NOSCRUB`, `RECALLOPEN`, `RECALLACCESS`, `PINNED`, `UNPINNED`, `UNKNOWN` |
+| `status` | Represents the system status message, for example, `Success` |
+
+
+### `WriteFile` `ReadFile`
+
+`WriteFile` and `ReadFile` events occur when a process writes data to a file or reads data from the file or I/O device respectively. They contain the following parameters:
+
+| PARAMETER | DESCRIPTION |
+| :--- | :---- |
+| `file_object` | File object pointer as seen from the kernel perspective. You can use this parameter to correlate file events. |
+| `file_path` | Represents the file/directory or device name the data is written to or read from. |
+| `irp` | I/O request packet value that identifies the file system activity. |
+| `io_size` | Specifies the number of bytes read or written. |
+| `offset` | Offset in the file where the data is read or written. |
+| `type` | Defines the file type. Possible values include `File`, `Directory`, `Pipe`, `Console`, `Mailslot`, `Other`, `Unknown` |
+
+
+### `DeleteFile` `RenameFile` `CloseFile`
+
+`DeleteFile` is fired when the file is removed from the file system. `RenameFile` signals file or directory renaming. `CloseFile` fires when file handle is closed. These events share the following parameters:
+
+| PARAMETER | DESCRIPTION |
+| :--- | :---- |
+| `file_object` | File object pointer as seen from the kernel perspective. You can use this parameter to correlate file events. |
+| `file_path` | Represents the file path/directory involved in the operation. |
+| `irp` | I/O request packet value that identifies the file system activity. |
+| `type` | Defines the file type. Possible values include `File`, `Directory`, `Pipe`, `Console`, `Mailslot`, `Other`, `Unknown` |
+
+
+### `SetFileInformation`
+
+`SetFileInformation` is published when the file metadata are manipulated for the given information class. The event contains the following parameters:
+
+| PARAMETER | DESCRIPTION |
+| :--- | :---- |
+| `class` | File information class. For example, the `Basic` information class means the process altered file timestamps or basic attributes. Refer to [this](https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/ne-wdm-_file_information_class) link for a full list of the file information class enumerations. |
+| `file_object` | File object pointer as seen from the kernel perspective. |
+| `file_path` | Represents the file whose information class is manipulated. |
+| `irp` | I/O request packet value that identifies the file system activity. |
+| `type` | Defines the file type. Possible values include `File`, `Pipe`, `Mailslot`, `Other`, `Unknown` |
+
+
+### `EnumDirectory`
+
+The `EnumDirectory` event is triggered in response to directory enumeration requests. The event has the following parameters:
+
+| PARAMETER | DESCRIPTION |
+| :--- | :---- |
+| `dir` | Specifies the directory that was requested for enumeration. |
+| `file_path` | Pattern for directory enumeration, for example, `*` |
+| `class` | Identifies the requested directory enumeration class. |
+| `file_object` | File object pointer as seen from the kernel perspective. |
+| `irp` | I/O request packet value that identifies the file system activity. |
diff --git a/docs/telemetry/events/handle.md b/docs/telemetry/events/handle.md
new file mode 100644
index 000000000..cd4900787
--- /dev/null
+++ b/docs/telemetry/events/handle.md
@@ -0,0 +1,53 @@
+# Handle Events
+
+##### The object manager produces handle events to provision or dispose resources allocated to processes. Resources can be threads, registry keys, files, synchronization primitives and so on. **Fibratus** captures handle creation, destruction, and duplication operations.
+
+?> Handle events are voluminous and they are disabled by default. To enable the collection of handle events either run Fibratus with the `--eventsource.enable-handle=true` flag or activate it permanently by editing the config file.
+
+### `CreateHandle`
+
+`CreateHandle` is captured when the object manager provisions a new handle in the address space of the calling process. The following parameters are associated with the `CreateHandle` event:
+
+| PARAMETER | DESCRIPTION |
+| :--- | :---- |
+| `handle_id` | Unique identifier of the handle. |
+| `handle_object` | Address of the kernel object to which the handle is associated. |
+| `type_id` | Handle type, for example, `File` or `Key` |
+
+### `CloseHandle`
+
+`CloseHandle` event is triggered when the handle is released by the process. It contains the following parameters:
+
+| PARAMETER | DESCRIPTION |
+| :--- | :---- |
+| `handle_id` | Unique identifier of the handle. |
+| `handle_name` | Handle name, for example, `\RPC Control\OLEA61B27E13E028C4EA6C286932E80` |
+| `handle_object` | Address of the kernel object to which the handle is associated. |
+| `type_id` | Handle type, for example, `File` or `Key` |
+
+
+### `DuplicateHandle`
+
+`DuplicateHandle` event is fired when the process duplicates an object handle. The following parameters are present in this event:
+
+| PARAMETER | DESCRIPTION |
+| :--- | :---- |
+| `handle_id` | Duplicated handle identifier. |
+| `handle_object` | Address of the duplicated kernel object. |
+| `handle_source_id` | Identifier of the handle to be duplicated. |
+| `type_id` | Duplicated handle type, for example, `DxgkCompositionObject` |
+| `pid` | Process identifier from which the handle is duplicated. |
+| `exe` | Process executable path from which the handle is duplicated. |
+| `name` | Process name from which the handle is duplicated. |
+
+### Handle state
+
+During bootstrap, Fibratus builds a snapshot of currently allocated handles. Similarly, when a new process is created Fibratus fetches its handles and attaches them to the process state. However, to optimize memory utilization, the initial handle snapshot and process handle table initialization are disabled by default. You can enable both features by modifying the `--handle.init-snapshot=true` and `--handle.enumerate-handles` config flags respectively or changing the corresponding key in the configuration file.
+
+The handle state contains:
+
+- handle name
+- handle type
+- the address of the kernel object
+- handle identifier
+- additional metadata such as `ALPC` port information or mutant count
diff --git a/docs/telemetry/events/memory.md b/docs/telemetry/events/memory.md
new file mode 100644
index 000000000..185f67139
--- /dev/null
+++ b/docs/telemetry/events/memory.md
@@ -0,0 +1,61 @@
+# Memory Events
+
+##### Memory events include reserving, committing, or freeing the state of a region of pages, and also, mapping/unmapping the section view into/from the virtual process address space.
+
+### `VirtualAlloc`
+
+`VirtualAlloc` event is published in response to memory allocation of a region of pages in the virtual address space. If the `pid` parameter is different than the calling process id, memory allocation is performed in the address space of another process. `VirtualAlloc` events carry the following parameters:
+
+| PARAMETER | DESCRIPTION |
+| :--- | :---- |
+| `alloc_type` | designates the type of memory allocation. It can be the combination of `COMMIT`, `RESERVE`, `RESET`, `RESET_UNDO`, `PHYSICAL`, `LARGE_PAGES`, `TOP_DOWN`, and `WRITE_WATCH` |
+| `base_address` | Starting address of the allocated region. |
+| `page_type` | Type of pages in the allocated region. It can be one of `IMAGE`, `MAPPED`, or `PRIVATE` |
+| `protection` | Memory protection for the region of allocated pages. It can be the combination of `EXECUTE`, `EXECUTE_READ`, `EXECUTE_READWRITE`, `EXECUTE_WRITECOPY`, `NOACCESS`, `READONLY`, `READWRITE`, `WRITECOPY`, `TARGETS_INVALID`, `TARGETS_NO_UPDATE`, `GUARD`, `NOCACHE`, and `WRITECOMBINE` |
+| `protection_mask` | Abbreviated form of the pages protection flag, for example, `RWX` |
+| `region_size` | Size of the allocated region in bytes. |
+| `pid` | Process identifier where the memory allocation occurs. |
+| `exe` | Process executable path where the memory allocation occurs. |
+| `name` | Process name where the memory allocation occurs. |
+
+### `VirtualFree`
+
+`VirtualFree` event is captured when the memory manager releases, decommits, or releases and decommits a region of pages within the virtual process address space. If the `pid` parameter is different than the calling process id, memory release is performed in the address space of another process. `VirtualFree` events contain the following parameters:
+
+| PARAMETER | DESCRIPTION |
+| :--- | :---- |
+| `alloc_type` | designates the type of a freed memory region. It can be the combination of `COMMIT`, `RESERVE`, `RESET`, `RESET_UNDO`, `PHYSICAL`, `LARGE_PAGES`, `TOP_DOWN`, and `WRITE_WATCH` |
+| `base_address` | Starting address of the freed region. |
+| `region_size` | Size of the freed region in bytes. |
+| `pid` | Process identifier where the memory release occurs. |
+| `exe` | Process executable path where the memory release occurs. |
+| `name` | Process name where the memory release occurs. |
+
+
+### `MapViewFile`
+
+`MapViewFile` is published when the view of a file mapping is mapped into the process address space. This event contain the following parameters:
+
+| PARAMETER | DESCRIPTION |
+| :--- | :---- |
+| `file_key` | Address of the file object for which the mapping is performed. |
+| `offset` | File offset where the view is to begin. |
+| `pid` | Process identifier where the file mapping is performed. |
+| `protection` | Specifies the page protection of the file mapping object. Can be the compatible combination of the following values: `READONLY`, `EXECUTE`, `EXECUTE_READ`, `READWRITE`, `WRITECOPY`, `NOCACHE`, `EXECUTE_WRITECOPY` and `EXECUTE_READWRITE`
+| `section_type` | Type of the mapped section. It can be `DATA`, `IMAGE`, `IMAGE_NO_EXECUTE`, `PAGEFILE` or `PHYSICAL` |
+| `view_base` | Base memory address in the process address space where mapping begins. |
+| `view_size` | Number of bytes of a file mapping to map to a view. |
+
+### `UnmapViewFile`
+
+`UnmapViewFile` trigger as a response to unmapping a mapped view of a file from the process's virtual address space. This event has the following parameters:
+
+| PARAMETER | DESCRIPTION |
+| :--- | :---- |
+| `file_key` | Address of the file object for which the unmapping is performed. |
+| `offset` | File offset where the view to unmap begins. |
+| `pid` | Process identifier where the file unmapping is performed. |
+| `protection` | specifies the page protection of the file mapping object that is being unmapped. Can be the compatible combination of the following values: `READONLY`, `EXECUTE`, `EXECUTE_READ`, `READWRITE`, `WRITECOPY`, `NOCACHE`, `EXECUTE_WRITECOPY` and `EXECUTE_READWRITE` |
+| `section_type` | Type of the unmapped section. It can be `DATA`, `IMAGE`, `IMAGE_NO_EXECUTE`, `PAGEFILE` or `PHYSICAL` |
+| `view_base` | Base memory address in the process address space where unmapping begins. |
+| `view_size` | Number of bytes of a file mapping to unmap. |
diff --git a/docs/telemetry/events/module.md b/docs/telemetry/events/module.md
new file mode 100644
index 000000000..870b0e436
--- /dev/null
+++ b/docs/telemetry/events/module.md
@@ -0,0 +1,16 @@
+# Module Events
+
+##### Module events occur when a process loads/unloads a dynamic linked library, executable or a kernel driver. The loading can happen in the local or remote process. These events are represented by `LoadModule` and `UnloadModule` types respectively. The following list describes all available parameters present in module events captured by **Fibratus**
+
+### `LoadModule` `UnloadModule`
+
+| PARAMETER | DESCRIPTION |
+| :--- | :---- |
+| `file_path` | Full path name of the module file, for example, `C:\Windows\system32\kernel32.dll` |
+| `module_size` | Represents the size of the mapped module region. |
+| `checksum` | Represents the module checksum digest. |
+| `base_address` | Base address of the process in which the image is loaded/unloaded. |
+| `default_address` | Represents the module base address. |
+| `pid` | Specifies the process identifier where the module is loaded/unloaded. |
+| `signature_type` | Describes the type of the digital signature. Can be `NONE`, `EMBEDDED`, `CACHED`, `CATALOG_CACHED`, `CATALOG_UNCACHED`, `CATALOG_HINT`, `PACKAGE_CATALOG` and `FILE_VERIFIED`. This parameter is a best-effort hint. The kernel doesn't always verify signatures on module load and can report false positives for the signature type. |
+| `signature_level` | Describes the signature level. This parameter is a best-effort hint. The kernel doesn't always verify signatures on module load and can report false positives for the signature level. |
diff --git a/docs/telemetry/events/network.md b/docs/telemetry/events/network.md
new file mode 100644
index 000000000..b2cd3b1e7
--- /dev/null
+++ b/docs/telemetry/events/network.md
@@ -0,0 +1,57 @@
+# Network Events
+
+##### Interprocess communication via TCP/UDP sockets produces all sorts of network events including, sending and receiving data, retransmitting TCP segments or connecting to sockets. DNS events are also classified as a subset of network events.
+
+### TCP/UDP events
+
+Fibratus captures TCP and UDP network events at a low level, providing detailed visibility into how processes communicate over the network. By leveraging Windows kernel telemetry, it records connection attempts, accepted connections, data transfers, and endpoint metadata such as IP addresses and ports, all correlated back to the originating process. The following network signals are surfaced:
+
+- `Connect` establishes a connection to the stream-oriented socket.
+- `Accept` accepts the connection request from the socket queue.
+- `Send` transports data to local or remote endpoint.
+- `Recv` consumes data sent by local or remote socket.
+- `Disconnect` terminates data reception on the socket.
+- `Reconnect` reconnects to the socket.
+- `Retransmit` retransmits unacknowledged TCP segments.
+
+All TPC/UDP network events share the same parameter set:
+
+| PARAMETER | DESCRIPTION |
+| :--- | :---- |
+| `dip` | Destination IPv4/IPv6 address of the communication endpoint. |
+| `sip` | Source IPv4/IPv6 address of the local process. |
+| `dport` | Destination port. |
+|`sport` | Source port. |
+| `l4_proto` | Type of the Layer 4 protocol. Possible values are `tcp`, `udp` |
+| `dport_name` | Destination port name per [IANA](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt) port to service mappings. |
+| `sport_name` | Source port name per [IANA](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt) port to service mappings. |
+
+
+### DNS events
+
+DNS telemetry uncovers all DNS query/reply interactions. More specifically, `QueryDns` and `ReplyDns` events are fired when the process sends a query to the name server and when it receives the response from the DNS server, respectively. DNS events are collected by default, but it is possible to disable them by setting the `eventsource.enable-dns` config flag to `false`.
+
+`QueryDns` event is generated when a query is sent to the name server. This event has the following parameters:
+
+| PARAMETER | DESCRIPTION |
+| :--- | :---- |
+| `name` | DNS query, for example, `www.iana.org` |
+| `options` | DNS query options. It can be the combination of the following values: `STANDARD`, `ACCEPT_TRUNCATED_RESPONSE`, `USE_TCP_ONLY`, `NO_RECURSION`, `BYPASS_CACHE`, `NO_WIRE_QUERY`, `NO_LOCAL_NAME`, `NO_NETBT`, `WIRE_ONLY`, `RETURN_MESSAGE`, `MULTICAST_ONLY`, `NO_MULTICAST`, `TREAT_AS_FQDN`, `ADDRCONFIG`, `DUAL_ADDR`, `MULTICAST_WAIT`, `MULTICAST_VERIFY`, `DONT_RESET_TTL_VALUES`, `DISABLE_IDN_ENCODING`, `APPEND_MULTILABEL` |
+| `rr` | Type of the resource record. It can be one of `A`,`NS`, `MD`, `MF`, `CNAME`, `SOA`, `MB`, `MG`, `MR`, `NULL`, `WKS`, `PTR`,`HINFO`, `MINFO`, `MX`, `TEXT`, `RP`, `AFSDB`, `X25`, `ISDN`, `NSAPPTR`, `SIG`, `KEY`, `PX`, `GPOS`,`AAAA`, `LOC`, `NXT`, `EID`, `NIMLOC`, `SRV`, `ATMA`, `NAPTR`, `KX`, `CERT`, `A6`, `DNAME`, `SINK`, `OPT`, `DS`, `RRSIG`,`NSEC`, `DNSKEY` `DHCID`, `UINFO`, `UID`, `GID`, `UNSPEC`, `ADDRS`, `TKEY`, `TSIG`, `IXFR`, `AXFR`, `MAILB`, `MAILA`, `ANY`, `WINS`, `WINSR` |
+
+
+`ReplyDns` event is captured when the the response is received by the DNS server. DNS reply events contain the following parameters:
+
+| PARAMETER | DESCRIPTION |
+| :--- | :---- |
+| `name` | DNS query linked to the response, for example, `www.iana.org` |
+| `answers` | Response answers, for example, `151.101.194.132`
+| `options` | DNS response options. It can be the combination of the following values: `STANDARD`, `ACCEPT_TRUNCATED_RESPONSE`, `USE_TCP_ONLY`, `NO_RECURSION`, `BYPASS_CACHE`, `NO_WIRE_QUERY`, `NO_LOCAL_NAME`, `NO_NETBT`, `WIRE_ONLY`, `RETURN_MESSAGE`, `MULTICAST_ONLY`, `NO_MULTICAST`, `TREAT_AS_FQDN`, `ADDRCONFIG`, `DUAL_ADDR`, `MULTICAST_WAIT`, `MULTICAST_VERIFY`, `DONT_RESET_TTL_VALUES`, `DISABLE_IDN_ENCODING`, `APPEND_MULTILABEL`.
+| `rr` | Type of the resource record. It can be one of `A`,`NS`, `MD`, `MF`, `CNAME`, `SOA`, `MB`, `MG`, `MR`, `NULL`, `WKS`, `PTR`,`HINFO`, `MINFO`, `MX`, `TEXT`, `RP`, `AFSDB`, `X25`, `ISDN`, `NSAPPTR`, `SIG`, `KEY`, `PX`, `GPOS`,`AAAA`, `LOC`, `NXT`, `EID`, `NIMLOC`, `SRV`, `ATMA`, `NAPTR`, `KX`, `CERT`, `A6`, `DNAME`, `SINK`, `OPT`, `DS`, `RRSIG`, `NSEC`, `DNSKEY` `DHCID`, `UINFO`, `UID`, `GID`, `UNSPEC`, `ADDRS`, `TKEY`, `TSIG`, `IXFR`, `AXFR`, `MAILB`, `MAILA`, `ANY`, `WINS`, `WINSR` |
+| `rcode` | DNS response code. It can be one of `NOERROR`, `FORMERR`, `SERVFAIL`, `NXDOMAIN`, `NOTIMP`, `REFUSED`,`YXDOMAIN`, `YXRRSET`, `NXRRSET`, `NOTAUTH`, `NOTZONE`, `BADSIG`, `BADKEY`, `BADTIME`, `BADNAME`, `INVALID`, `NXDOMAIN` |
+
+### DNS reverse lookups
+
+Fibratus supports reverse DNS resolution for IP addresses, enabling the retrieval of domain names associated with a given network endpoint. For instance, `47.224.186.35.bc.googleusercontent.com` represents the reverse DNS entry for a Google-owned IP address.
+
+Resolved domain names can be incorporated into detection rules via [filter fields](../../rules/fields.md) to enhance network event analysis.
diff --git a/docs/telemetry/events/object.md b/docs/telemetry/events/object.md
new file mode 100644
index 000000000..dfbace29b
--- /dev/null
+++ b/docs/telemetry/events/object.md
@@ -0,0 +1,16 @@
+# Object Manager Events
+
+##### **Fibratus** captures the `CreateSymbolicLinkObject` event when a symbolic link object is created via native APIs. The Windows kernel emits an event that includes key metadata such as the link name, target path, and the process responsible for the operation.
+
+### `CreateSymbolicLinkObject`
+
+This visibility is particularly valuable because symbolic links are often leveraged by both legitimate system components and adversaries to redirect access to sensitive resources or obscure execution paths. By capturing these events in real time and correlating them with other system activity, Fibratus allows analysts to detect anomalous link creation patterns, trace their origin, and incorporate them into behavioral detections.
+
+`CreateSymbolicLinkObject` has the following parameters:
+
+| PARAMETER | DESCRIPTION |
+| :--- | :---- |
+| `source` | Source symbolic link object or other kernel object, for example, `DosDevices\PROCEXP152` |
+| `target` | Target symbolic link object or other kernel object, for example, `\Device\PROCEXP152` |
+| `desired_access` | Access rights for the target symbolic link object. Can be the combination of `DELETE`, `READ_CONTROL`, `WRITE_DAC`, `WRITE_OWNER`, `SYNCHRONIZE`, `STANDARD_RIGHTS_REQUIRED`, `STANDARD_RIGHTS_ALL`, `ACCESS_SYSTEM_SECURITY`, `MAXIMUM_ALLOWED`, `GENERIC_READ`, `GENERIC_WRITE`, `GENERIC_EXECUTE`, `GENERIC_ALL` |
+| `status` | System status code that represents the outcome of the operation. |
diff --git a/docs/telemetry/events/process.md b/docs/telemetry/events/process.md
new file mode 100644
index 000000000..0f400a2ce
--- /dev/null
+++ b/docs/telemetry/events/process.md
@@ -0,0 +1,58 @@
+# Process Events
+
+##### Process events are fired as a stimulus to the process life-cycle changes. When the kernel puts into motion a process or terminates it, the `CreateProcess` and `TerminateProcess` events are emitted respectively. `OpenProcess` event fires when the process attemps to acquire an existing local process object. The following sections summarize all the distinct event parameters that are associated with process events captured by **Fibratus**
+
+### `CreateProcess` `TerminateProcess`
+
+| PARAMETER | DESCRIPTION |
+| :--- | :---- |
+| `pid` | Process identifier. This value is valid from the time a process is created until it is terminated. |
+| `tid` | Thread identifier inside process address space that generated the event. |
+| `ppid` | Parent identifier of the child process. Process identifier numbers are reused, so they only identify a process for the lifetime of that process. It is possible that the process identified by `ppid` is terminated, so `ppid` may not refer to a running process. It is also possible that `ppid` incorrectly refers to a process that reuses a process identifier. |
+| `real_ppid` | Real parent process identifier useful for detecting process spoofing. |
+| `name` | Process name including file extension, for example, `cmd.exe` |
+| `cmdline` | Full process command line, for example, `C:\Windows\system32\cmd.exe /cdir /-C /W`) |
+| `exe` | Full name of the process executable, for example, `C:\Windows\system32\cmd.exe` |
+| `sid` | Security identifier under which this process runs, for example, `S-1-5-18` |
+| `kproc` | Represents the address of the `KPROCESS` object in the kernel. |
+| `directory_table_base` | Represents the address of the directory table that holds process memory page mappings. |
+| `session_id` | Unique identifier for the current session under which process was started or terminated. |
+| `status` | Exit status of the started/stopped process. |
+| `start_time` | Designates the instant when the process was started. Start time is available only in `CreateProcess` events. |
+| `domain` | Represents the domain name under which the process is started. |
+| `username` | Represents the username that started the process. |
+| `flags` | Represents process creation flags. Can be `WOW64`, `PROTECTED`, or `PACKAGED` to designate 32-bit process is created in 64-bit Windows system, process is to be run as a protected process, or a process packaged with the [MSIX](https://learn.microsoft.com/en-us/windows/msix/overview) technology respectively. |
+| `token_integrity_level` | Process token integrity level. Can be `PROTECTED`, `SYSTEM`, `HIGH`, `MEDIUM`, `MEDIUM+`, `LOW` and `UNTRUSTED`. |
+| `token_is_elevated` | Indicates if the process token is elevated. |
+| `token_elevation_type` | Indicates the process token elevation type. Can be `FULL` or `LIMITED`. |
+
+### `OpenProcess`
+
+| PARAMETER | DESCRIPTION |
+| :--- | :---- |
+| `desired_access` | Value that represents the desired access bitmask to the process object. |
+| `desired_access_names` | List of human-readable desired access strings, for example, `TERMINATE,QUERY_INFORMATION`. For a full list and detailed explanation of available access rights, head to the official [docs](https://docs.microsoft.com/en-us/windows/win32/procthread/process-security-and-access-rights). |
+| `name` | Name of the local process that was opened. |
+| `exe` | Full path of the local process object that was open. |
+| `pid` | Process identifier of the local process that was opened. |
+| `status` | System status of the open operation, for example, `Success` |
+
+## Process state
+
+Fibratus keeps a snapshot of all running processes including their state such as basic process attributes, allocated file handles, dynamically-linked libraries, PE (Portable Executable) metadata and other resources. The snapshot is updated dynamically as processes get spawn or die. Each time an event is captured, its **process state** is fetched from the snapshot and attached to the event. This state machine semantically enriches each individual event with the aim on providing a powerful context for [rules](../../rules.md), [filtering](../filtering.md), and [scripting](../../filaments.md).
+
+Process state comprises the following attributes and resources:
+
+- process name
+- process identifier as well as its parent process identifier
+- process command line
+- current working directory
+- process SID
+- session identifier
+- process token properties
+- environment variables
+- threads
+- modules
+- handles
+- memory mappings
+- PE metadata
diff --git a/docs/telemetry/events/registry.md b/docs/telemetry/events/registry.md
new file mode 100644
index 000000000..272d131fc
--- /dev/null
+++ b/docs/telemetry/events/registry.md
@@ -0,0 +1,47 @@
+# Registry Events
+
+##### Registry events are triggered when processes access or modify the registry structure, such as creating new keys, altering registry key values or opening a handle to the registry key.
+
+### `RegCreateKey` `RegDeleteKey` `RegOpenKey` `RegCloseKey` `RegQueryKey`
+
+Creates a new registry key or opens the key if it already exists. Deletes a subkey and all its values. Opens a registry key. Closes the registry key. Enumerates the subkeys of the specified key. All of these events share a common parameter schema:
+
+| PARAMETER | DESCRIPTION |
+| :--- | :---- |
+| `key_handle` | Represents the address of the [KCB](https://learn.microsoft.com/en-us/windows-hardware/drivers/debuggercmds/-regkcb) (Key Control Block) structure in kernel space. |
+| `key_path` | Full registry path involved in the operation, for example, `HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control` |
+| `status` | System status code of the registry operation, for example, `More data is available` |
+
+### `RegQueryValue`
+
+`RegQueryValue` is captured when the process retrieves the data from registry value. This event contains the following parameters:
+
+| PARAMETER | DESCRIPTION |
+| :--- | :---- |
+| `key_handle` | Represents the address of the [KCB](https://learn.microsoft.com/en-us/windows-hardware/drivers/debuggercmds/-regkcb) (Key Control Block) structure in kernel space. |
+| `key_path` | Full path of the registry value, for example, `HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System\GpSvcDebugLevel` |
+| `status` | System status code of the registry operation, for example, `The system cannot find the file specified` |
+
+
+### `RegSetValue`
+
+`RegSetValue` event is triggered when registry data is set in the value. This event contains the following parameters:
+
+| PARAMETER | DESCRIPTION |
+| :--- | :---- |
+| `key_handle` | Represents the address of the [KCB](https://learn.microsoft.com/en-us/windows-hardware/drivers/debuggercmds/-regkcb) (Key Control Block) structure in kernel space. |
+| `key_path` | Full path of the registry value, for example, `HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System\GpSvcDebugLevel` |
+| `status` | System status code of the registry operation, for example, `Success` |
+| `data` | Value data being stored. |
+| `value_type` | Registry value type. Possible values include `REG_DWORD`, `REG_QWORD`, `REG_SZ`, `REG_EXPAND_SZ`, `REG_MULTI_SZ`, `REG_BINARY`, `UNKNOWN` |
+
+### `RegDeleteValue`
+
+`RegDeleteValue` is captured when the registry values is deleted. This event contains the following parameters:
+
+| PARAMETER | DESCRIPTION |
+| :--- | :---- |
+| `key_handle` | Represents the address of the [KCB](https://learn.microsoft.com/en-us/windows-hardware/drivers/debuggercmds/-regkcb) (Key Control Block) structure in kernel space. |
+| `key_path` | Full path of the registry value, for example, `HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\System\GpSvcDebugLevel` |
+| `status` | System status code of the registry operation, for example, `Success` |
+| `value_type` | Registry value type. Possible values include `REG_DWORD`, `REG_QWORD`, `REG_SZ`, `REG_EXPAND_SZ`, `REG_MULTI_SZ`, `REG_BINARY`, `UNKNOWN` |
\ No newline at end of file
diff --git a/docs/telemetry/events/thread.md b/docs/telemetry/events/thread.md
new file mode 100644
index 000000000..b5217636b
--- /dev/null
+++ b/docs/telemetry/events/thread.md
@@ -0,0 +1,91 @@
+# Thread Events
+
+##### Thread events notify the creation or termination of threads within the process address space via `CreateThread` and `TerminateThread` events respectively. When the thread object is acquired, the `OpenThread` event is fired. Processes can manipulate thread context of local or remote threads. Under this circumstances the `SetThreadContext` is triggered. The following sections summarize all the distinct event parameters that are associated with thread events captured by **Fibratus**
+
+### `CreateThread`
+
+| PARAMETER | DESCRIPTION |
+| :--- | :---- |
+| `pid` | Process identifier where the thread has been spawned. If this value is not equal to the `pid` of the process generating the event, then the thread is created in the virtual address space of another process using the [`CreateRemoteThread`](https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createremotethread) API function. |
+| `tid` | Represents the identifier of the freshly spawn thread. |
+| `base_prio`| Scheduler priority for the new thread. |
+|`page_prio` | Memory page priority hint for memory pages accessed by the thread. |
+| `io_prio` | I/O priority hint for scheduling I/O operations generated by the thread. |
+| `ustack_base` | Base address of the thread's user space stack. |
+| `ustack_limit`| Limit of the thread's user space stack. |
+| `kstack_base` | Base address of the thread's kernel space stack. |
+| `kstack_limit` | Limit of the thread's kernel space stack. |
+| `start_address` | Start address of the function to be executed by the thread. |
+| `start_address_symbol` | Symbol the represents the thread start address, for example, `LoadLibraryEx` |
+| `start_address_module` | Module that maps to the thread start address, for example, `ntdll.dll` |
+| `teb` | Address of the [`TEB`](https://learn.microsoft.com/en-us/windows/win32/api/winternl/ns-winternl-teb) (Thread Environment Block) structure that describes the state of a thread. |
+
+### `TerminateThread`
+
+| PARAMETER | DESCRIPTION |
+| :--- | :---- |
+| `pid` | Process identifier where the thread has been terminated. |
+| `tid` | Represents the identifier of the terminated thread. |
+| `base_prio`| Scheduler priority of the thread. |
+|`page_prio` | Memory page priority hint for memory pages accessed by the thread. |
+| `io_prio` | I/O priority hint for scheduling I/O operations generated by the thread. |
+| `ustack_base` | Base address of the thread's user space stack. |
+| `ustack_limit`| Limit of the thread's user space stack. |
+| `kstack_base` | Base address of the thread's kernel space stack. |
+| `kstack_limit` | Limit of the thread's kernel space stack. |
+| `start_address` | Start address of the function thread used to execute. |
+| `teb` | Address of the [`TEB`](https://learn.microsoft.com/en-us/windows/win32/api/winternl/ns-winternl-teb) (Thread Environment Block) structure that describes the state of a thread. |
+
+### `OpenThread`
+
+| PARAMETER | DESCRIPTION |
+| :--- | :---- |
+| `desired_access` | Value that represents the desired access to the thread object. |
+| `desired_access_names` | List of human-readable desired access strings, for example, `QUERY_LIMITED_INFORMATION`. For a full list and detailed explanation of available access rights, head to the official [docs](https://docs.microsoft.com/en-us/windows/win32/procthread/thread-security-and-access-rights).
+| `name` | Name of the local process whose thread object was open. |
+| `exe` | Full path of the local process image whose thread object was open. |
+| `pid` | Identifier of the local process whose thread object was opened. |
+| `tid` | Identifier of the local thread that was opened. |
+| `status` | System status of the thread object open operation, for example, `Success` |
+
+### `SetThreadContext`
+
+| PARAMETER | DESCRIPTION |
+| :--- | :---- |
+| `status` | System status of the thread context set operation, for example, `Access denied` |
+
+## Thread pool events
+
+A thread pool is a collection of worker threads that efficiently execute asynchronous callbacks on behalf of the application. The thread pool is primarily used to reduce the number of application threads and provide management of the worker threads. Fibratus collects the following thread pool telemetry.
+
+
+### `SubmitThreadpoolWork` `SubmitThreadpoolCallback`
+
+`SubmitThreadpoolWork` enqueues the work item to the thread pool. `SubmitThreadpoolCallback` submits the thread pool callback for execution within the work item. These events has the following parameters:
+
+| PARAMETER | DESCRIPTION |
+| :--- | :---- |
+| `pool_id` | Represents the thread pool identifier. |
+| `task_id` | Represents the thread pool task identifier. |
+| `callback`| Represents the address of the callback function |
+| `context` | Represents the address of the callback context. |
+| `subprocess_tag` | Represents the service identifier associated with the thread pool. |
+| `callback_symbol` | Represents the callback symbol, for example, `RtlCaputreContext` |
+| `callback_module` | Represents the module containing the callback symbol, for example, `C:\Windows\System32\ntdll.dll` |
+| `context_rip` | Represents the value of instruction pointer contained in the callback context |
+| `context_rip_symbol` | Represents the symbol name associated with the instruction pointer in callback context. |
+| `context_rip_module` | Represents the module name associated with the instruction pointer in callback context. |
+
+
+### `SetThreadpoolTimer`
+
+Sets the thread pool timer object. This event consists of the following parameters:
+
+| PARAMETER | DESCRIPTION |
+| :--- | :---- |
+| `duetime` | Represents the timer due time. |
+| `subqueue` | Represents the memory address of the timer subqueue. |
+| `timer` | Represents the memory address of the timer object. |
+| `period` | Represents the period of the timer. |
+| `window` | Represents the timer tolerate period. |
+| `absolute` | Indicates if the timer is absolute or relative. |
diff --git a/docs/telemetry/filtering.md b/docs/telemetry/filtering.md
new file mode 100644
index 000000000..226e1c8b5
--- /dev/null
+++ b/docs/telemetry/filtering.md
@@ -0,0 +1,140 @@
+# Filtering
+
+##### Modern systems generate an **overwhelming volume of events**, making it difficult to extract meaningful insights or focus on specific behaviors. **Fibratus** provides a powerful and expressive filtering engine that allows to narrow down event streams, isolate suspicious activity and drive investigations or postmortem analysis. Filters are the foundation of detection [rules](../rules.md) logic.
+
+## Anatomy of a filter
+
+At its core, a filter expression consists of `LHS` (Left Hand Side) and `RHS` (Right Hand Side) components connected by a binary, logical, or string operator as depicited in the image below.
+
+
+
+!> A special case are boolean fields that can appear alone in the filter expression. For example, `module.is_dll` is the boolean shortcut of `module.is_dll = true`
+
+Suppose we want to filter all events generated by `cmd.exe`, `powershell.exe` or `winword.exe` processes. We would write the following filter expression.
+
+```python
+ps.name in ('cmd.exe', 'powershell.exe', 'winword.exe')
+```
+
+### LHS
+
+The LHS component is typically a [field](../rules/fields.md) however it can also be a [function](../rules/functions.md) result. Examples of field names are `ps.name` or `evt.pid`. Fields contain values extracted from event parameters, callstack frames, or process context.
+
+### RHS
+
+The RHS component can be of several types including strings, numbers, IP addresses, boolean values, field references and collections. Here are some examples:
+
+| TYPE | EXPRESSION |
+| :--- | :---- |
+| string | `file.name = 'cmd.exe'` |
+| number | `ps.pid = 4` |
+| boolean | `dll.signature.exists = true` |
+| network address | `net.sip = 127.0.0.1` |
+| field reference | `evt.pid != ps.pid` |
+| collection | `ps.name in ('cmd.exe', 'powershell.exe')` |
+
+
+String values must be enclosed in single quotes `''`. If a string contains characters that would make it an invalid identifier, those characters need to be escaped. For instance, path delimiters (backslashes) and quotation marks require escaping:
+
+```python
+file.path = 'C:\\Windows\\System32'
+```
+
+Filter expressions also support standard escape sequences, such as the newline character.
+
+### Operators
+
+Operators define how LHS and RHS are evaluated. They fall into several categories:
+
+| TYPE | OPERATORS |
+| :--- | :---- |
+| Comparison | `=` `!=` `>` `<` `>=` `<=` |
+| Logical | `and` `or` `not` |
+| String | `and` `or` `not` |
+| Logical | `contains` `startswith` `endswith` `matches` `icontains` `istartswith` `iendswith` `imatches` |
+| Membership | `in` `iin` |
+| Negation | `not` |
+
+Operator precedence determines how expressions are evaluated. For example, `A or B and C` is interpreted as `A or (B and C)`.
+When necessary, use parentheses to make intent explicit and avoid subtle bugs.
+
+### Functions
+
+[Functions](../rules/functions.md) can be used on either side of the expression, or even nested. This enables on-the-fly transformation of event fields and constants, making filters more robust and adaptable to variations in data. For instance, `lower(file.name) = 'cmd.exe'` ensures the comparison is case-insensitive, while `base(ltrim(file.path, 'C:'), false) in suspicious_files` demonstrates function composition, where the file path is first trimmed and then reduced to its base name before being matched against a list of suspicious files.
+
+### Errors
+
+If a filter contains a syntax error, a hint indicates the position of the error in the expression. By highlighting the exact offset where parsing fails, the hint enables precise debugging of filters, helping users quickly identify issues such as token mismatches, missing delimiters, invalid string escapes, or invalid operator usage without manually inspecting the entire expression.
+
+
+
+## Filtering in different contexts
+
+As described in the [quick start](../setup/quick-start.md), filters can be applied at different stages of event collection and processing. Filter expressions are passed as command-line arguments to the `run`, `capture`, and `replay` commands.
+
+!> If you're using PowerShell, wrap the entire filter expression in quotes `fibratus run --forward "evt.category = 'net'"`
+
+### Filtering with `run`
+
+The `run` command evaluates the filter expression against each incoming event. Events that don’t match are discarded and never forwarded to the output sink.
+
+For example, the following command captures only events that originate from the `cmd.exe` or `svchost.exe` processes.
+
+
+$ fibratus run --forward ps.name in ('cmd.exe', 'svchost.exe')
+
+
+
+### Filtering with `capture`
+
+The `capture` command persists only those events that match the filter. [Captures](../captures.md) are thoroughly explained in the upcoming section. In this example, only `registry` events are written to the output file.
+
+
+$ fibratus capture evt.category = 'registry' -o events
+
+
+
+### Filtering with `replay`
+
+When [replaying](../captures.md) events from a capture file, filters can narrow down the replay scope. For instance, the following command replays only events that modify registry values:
+
+
+$ fibratus replay evt.name = 'RegSetValue' -k events
+
+
+
+### Filtering in `filaments`
+
+Filters can also be applied during [filament](../filaments.md) execution. If a filter is defined both in the `run` command and via the `set_filter` function, the filament-level filter takes precedence.
+
+## Exclusions
+
+In some cases, you may want to exclude specific events, either by process image name or event type after they are captured from kernel buffers. Additionally, the kernel stream consumer can be configured to ignore entire categories of events at the [Event Tracing for Windows](https://docs.microsoft.com/en-us/windows/win32/etw/event-tracing-portal) session level.
+
+Disabling event categories at this stage can significantly reduce system overhead, especially when dealing with high-volume telemetry that isn’t relevant to your use case.
+
+### Event source configuration
+
+These options are defined in the `eventsource` section of the configuration file and control which events are collected:
+
+* `enable-thread` collect thread-related events
+* `enable-registry` collect registry events
+* `enable-net` collect network events
+* `enable-fileio` collect file system events
+* `enable-module` collect module load/unload events
+* `enable-handle` collect handle events
+* `enable-audit-api` collect kernel audit API calls
+* `enable-mem` collect memory events
+* `enable-dns` collect DNS telemetry
+* `enable-threadpool` collect thread pool telemetry
+
+Disabling unnecessary categories helps reduce both event volume and processing cost.
+
+### Excluding events and processes
+
+To permanently exclude specific events or processes from the event stream, use the `eventsource.blacklist` section:
+
+* `events` defines a list of event names to drop, for example, `CloseFile`
+* `images` defines a list of case-sensitive process image names (including extensions). Any event generated by these processes is discarded
+
+This approach is useful for filtering out noisy or irrelevant sources before they reach downstream processing.
diff --git a/docs/telemetry/outputs.md b/docs/telemetry/outputs.md
new file mode 100644
index 000000000..1acb17a5b
--- /dev/null
+++ b/docs/telemetry/outputs.md
@@ -0,0 +1,19 @@
+# Outputs
+
+##### Fibratus provides a wide range of output sinks for transmitting telemetry events. While local [captures](../../captures.md) are often sufficient for inspection and analysis, the event stream can also be forwarded to external systems such as message brokers or search and analytics platforms, for example, RabbitMQ or Elasticsearch, enabling centralized processing, storage, and observability at scale.
+
+Each output exposes a comprehensive set of configuration options, allowing you to fine-tune how events are transmitted and integrated with downstream systems.
+
+### Event serialization
+
+Events are serialized in JSON format by default. Since each event may contain a large number of attributes, you can control which fields are included in the serialized output via the `event` section of the configuration file.
+
+The following options determine which parts of the process state are included:
+
+* `serialize-threads` include thread metadata
+* `serialize-modules` include loaded modules (e.g. DLLs)
+* `serialize-handles` include allocated process handles
+* `serialize-pe` include [Portable Executable](https://en.wikipedia.org/wiki/Portable_Executable) (PE) metadata
+* `serialize-envs` include environment variables
+
+Adjusting these settings allows you to balance the level of detail against performance and storage considerations.
diff --git a/docs/telemetry/outputs/console.md b/docs/telemetry/outputs/console.md
new file mode 100644
index 000000000..4f0aa63bd
--- /dev/null
+++ b/docs/telemetry/outputs/console.md
@@ -0,0 +1,64 @@
+# Console
+
+##### The console is the default output sink. It renders incoming events directly to standard output, providing a real-time view of the event stream. To improve performance, the console output is buffered, reducing the number of I/O system calls required to write event data.
+
+## Configuration
+
+The console output configuration is located in the `outputs.console` section.
+
+### `enabled`
+
+Indicates whether the console output is active.
+
+### `format`
+
+Specifies the console output format. The `pretty` format dictates that formatting is accomplished by replacing the specifiers in the template. The `json` format outputs the event as a raw JSON string.
+
+### `kv-delimiter`
+
+Specifies the separator rendered between the event parameter's key and its value.
+
+
+### `template`
+
+Defines the template used in the event formatter. For more details, see the next section.
+
+### `colorize`
+
+Indicates if the console output is colorized.
+
+## Templates
+
+The template consists of a collection of named placeholders that event formatter replaces with desired values. The syntax of the template resembles the Go [template](https://golang.org/pkg/text/template/) engine constructs, excepts the event formatter lacks advanced templating features such as loops, functions or `if` statements.
+
+The following field modifiers are supported:
+
+- `.Seq`
+- `.Timestamp`
+- `.Pid`
+- `.Ppid`
+- `.Pexe`
+- `.Pcmd`
+- `.Pname`
+- `.Cwd`
+- `.Exe`
+- `.Cmd`
+- `.Tid`
+- `.Sid`
+- `.Process`
+- `.Category`
+- `.Description`
+- `.CPU`
+- `.Type`
+- `.Params`
+- `.Meta`
+- `.Host`
+- `.PE`
+- `.Params.`
+- `.Callstack`
+
+The default template is defined as:
+
+```python
+{{ .Seq }} {{ .Timestamp }} - {{ .CPU }} {{ .Process }} ({{ .Pid }}) - {{ .Type }} ({{ .Params }})
+```
diff --git a/docs/telemetry/outputs/elasticsearch.md b/docs/telemetry/outputs/elasticsearch.md
new file mode 100644
index 000000000..1078e0fb8
--- /dev/null
+++ b/docs/telemetry/outputs/elasticsearch.md
@@ -0,0 +1,93 @@
+# Elasticsearch
+
+##### The Elasticsearch output ships events to the Elasticsearch `_bulk` [API endpoint](https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-bulk.html). Events are collected into batches and flushed at intervals defined by the `flush-period` config option, ensuring efficient indexing while minimizing request overhead.
+
+## Configuration
+
+The Elasticsearch output configuration is located in the `outputs.elasticsearch` section.
+
+### `enabled`
+
+Indicates whether the Elasticsearch output is enabled.
+
+### `servers`
+
+Defines the URL endpoints of the Elasticsearch nodes.
+
+### `timeout`
+
+Represents the initial HTTP connection timeout when connecting to the Elasticsearch cluster.
+
+### `flush-period`
+
+Specifies when to flush the bulk at the end of the given interval.
+
+### `bulk-workers`
+
+Determines the number of workers that commit docs to Elasticsearch. Higher values maximize the throughout at the cost of increased CPU utilization.
+
+### `healthcheck`
+
+Enables or disables nodes health checking.
+
+### `healthcheck-interval`
+
+Specifies the interval for checking if the Elasticsearch nodes are available.
+
+### `healthcheck-timeout`
+
+Specifies the timeout for periodic node health checks.
+
+### `username`
+
+Identifies the user name for the basic HTTP authentication.
+
+### `password`
+
+Identifies the password for the basic HTTP authentication.
+
+### `sniff`
+
+Enables the discovery of all Elasticsearch nodes in the cluster. This avoids populating the list of available Elasticsearch nodes.
+
+### `trace-log`
+
+Determines if the Elasticsearch client trace log is enabled. Useful for troubleshooting.
+
+### `gzip-compression`
+
+Determines if the `gzip` compression is enabled for Elasticsearch documents.
+
+### `template-name`
+
+Specifies the name of the index template.
+
+### `template-config`
+
+Contains the full JSON body of the index template. For more information refer to [index templates](https://www.elastic.co/guide/en/elasticsearch/reference/current/index-templates.html).
+
+### `index-name`
+
+Represents the target index for the telemetry. It allows time specifiers to create indices per time frame. For example, `fibratus-%Y-%m` generates the index name with current year and month. Supported time specifiers are:
+
+- `%Y` current year in `YYYY` format (`2020`)
+- `%y` current year in `YY` format (`20`)
+- `%m` current month (`01`)
+- `%d` current day (`02`)
+- `%H` current hour (`15`)
+
+### `tls-key`
+
+Path to the public/private key file.
+
+### `tls-cert`
+
+Path to the certificate file.
+
+### `tls-ca`
+
+Represents the path of the certificate file that is associated with the Certification Authority (CA).
+
+### `tls-insecure-skip-verify`
+
+Indicates if the chain and host verification stage is skipped.
diff --git a/docs/telemetry/outputs/eventlog.md b/docs/telemetry/outputs/eventlog.md
new file mode 100644
index 000000000..ca6955466
--- /dev/null
+++ b/docs/telemetry/outputs/eventlog.md
@@ -0,0 +1,23 @@
+# Eventlog
+
+##### Exports events via [Windows Event Log](https://docs.microsoft.com/en-us/windows/win32/wes/windows-event-log) API that can be explored with the [Event Viewer](https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc766042(v=ws.11)) management tool. Fibratus classifies each event with a custom `Event ID`
+
+## Configuration
+
+The Eventlog output configuration is located in the `outputs.eventlog` section.
+
+### `enabled`
+
+Indicates whether the Eventlog output is enabled.
+
+### `level`
+
+Specifies the eventlog level associated with the event logs produced by Fibratus. You can specify one of the following values `info`, `INFO`, `warn`, `warning`, `WARN`, `WARNING`, `erro`, `ERRO`, `error`, `ERROR`
+
+### `remote-host`
+
+Address of the remote eventlog service.
+
+### `template`
+
+Custom Go [template](https://pkg.go.dev/text/template) for rendering the eventlog message.
diff --git a/docs/outputs/http.md b/docs/telemetry/outputs/http.md
similarity index 58%
rename from docs/outputs/http.md
rename to docs/telemetry/outputs/http.md
index 4c8fdb276..608b75897 100644
--- a/docs/outputs/http.md
+++ b/docs/telemetry/outputs/http.md
@@ -1,83 +1,71 @@
# HTTP
-Sends events to local/remote endpoints via HTTP protocol. Requests are serialized to the data format specified by the `serializer` property, which by default encodes events as `JSON` payloads. HTTP requests are randomly load-balanced across endpoints defined in the `endpoints` config property.
+##### Sends events to local/remote endpoints via HTTP protocol. Requests are serialized to the data format specified by the `serializer` property, which by default encodes events as `JSON` payloads. HTTP requests are randomly load-balanced across endpoints defined in the `endpoints` config property.
-### Configuration {docsify-ignore}
+## Configuration
The HTTP output configuration is located in the `outputs.http` section.
-#### enabled
+### `enabled`
Indicates whether the HTTP output is enabled.
-**default**: `false`
-
-#### endpoints
+### `endpoints`
Specifies a list of endpoints to which the events are forwarded. Each of the endpoints must contain the HTTP protocol scheme, that can be `http` or `https`.
-#### timeout
+### `timeout`
Represents the timeout for the HTTP requests.
-**default**: `5s`
-
-#### proxy-url
+### `proxy-url`
Specifies the HTTP proxy URL. It overrides the HTTP proxy URL as indicated by the environment variables.
-#### proxy-username
+### `proxy-username`
The username for HTTP proxy authentication.
-#### proxy-password
+### `proxy-password`
The password for HTTP proxy authentication.
-#### method
+### `method`
Determines the HTTP verb to use in requests.
-**default**: `POST`
-
-#### serializer
+### `serializer`
-Specifies the event serializer type.
+Specifies the event serializer type. `json` is the default serializer.
-**default**: `json`
-
-#### username
+### `username`
Username for the basic HTTP authentication.
-#### password
+### `password`
Password for the basic HTTP authentication.
-#### enable-gzip
+### `enable-gzip`
If enabled, the HTTP body is compressed with the `gzip` compression.
-**default**: `false`
-
-#### headers
+### `headers`
Represents a list of arbitrary headers to include in HTTP requests.
-#### tls-key
+### `tls-key`
Path to the public/private key file.
-#### tls-cert
+### `tls-cert`
Path to the certificate file.
-#### tls-ca
+### `tls-ca`
Represents the path of the certificate file that is associated with the Certification Authority (CA).
-#### tls-insecure-skip-verify
+### `tls-insecure-skip-verify`
Indicates if the chain and host verification stage is skipped.
-
-**default**: `false`
diff --git a/docs/telemetry/outputs/null.md b/docs/telemetry/outputs/null.md
new file mode 100644
index 000000000..c2d6a431e
--- /dev/null
+++ b/docs/telemetry/outputs/null.md
@@ -0,0 +1,3 @@
+# Null
+
+##### The null output devours kernel events the same way a black hole swallows the light. This output is useful in case you want to snooze the event stream.
diff --git a/docs/outputs/rabbitmq.md b/docs/telemetry/outputs/rabbitmq.md
similarity index 67%
rename from docs/outputs/rabbitmq.md
rename to docs/telemetry/outputs/rabbitmq.md
index 94612b313..ce0bfb0fc 100644
--- a/docs/outputs/rabbitmq.md
+++ b/docs/telemetry/outputs/rabbitmq.md
@@ -1,96 +1,83 @@
# RabbitMQ
-The RabbitMQ output sends events to the [RabbitMQ](https://www.rabbitmq.com/) message broker. Various events are buffered and sent as part of a single AMQP message.
+##### The RabbitMQ output transmits events to the [RabbitMQ](https://www.rabbitmq.com/) messaging system. Events are buffered and published in batches as a single AMQP message to improve transmission efficiency and reduce overhead.
-### Configuration {docsify-ignore}
+
+## Configuration
The RabbitMQ output configuration is located in the `outputs.amqp` section.
-#### enabled
+### `enabled`
Specifies whether the RabbitMQ output sink is enabled.
-**default**: `false`
-#### url
+### `url`
Represents the AMQP connection string.
-**default**: `amqp://localhost:5672`
-#### timeout
+### `timeout`
Specifies the AMQP connection timeout.
-**default**: `5s`
-#### exchange
+### `exchange`
Specifies the target AMQP exchange name that receives inbound event message flow.
-**default**: `fibratus`
-#### exchange-type
+### `exchange-type`
Represents the AMQP exchange type. Available exchange type include common types are `direct`, `fanout`,
`topic`, `header`, and `x-consistent-hash`. To learn more about exchange types, refer to the RabbitMQ [docs](https://www.rabbitmq.com/tutorials/amqp-concepts.html#exchanges).
-#### routing-key
+### `routing-key`
Represents the static routing key to link exchanges with queues.
-**default**: `fibratus`
-
-#### vhost
+### `vhost`
Represents the AMQP virtual host name.
-**default**: `/`
-
-#### durable
+### `durable`
Indicates if the exchange is marked as durable. Durable exchanges can survive broker restarts.
-**default**: `false`
-#### passive
+### `passive`
Indicates if the server checks whether the exchange already exists and raises an error if it doesn't exist.
-**default**: `false`
-#### delivery-mode
+### `delivery-mode`
Determines if a published message is persistent or transient.
-**default**: `transient`
-
-#### username
+### `username`
The username for the plain authentication method.
-#### password
+### `password`
The password for the plain authentication method.
-#### headers
+### `headers`
Designates a collection of static headers that are added to each published message.
-#### tls-key
+### `tls-key`
Path to the public/private key file.
-#### tls-cert
+### `tls-cert`
Path to the certificate file.
-#### tls-ca
+### `tls-ca`
Represents the path of the certificate file that is associated with the Certification Authority (CA).
-#### tls-insecure-skip-verify
+### `tls-insecure-skip-verify`
Indicates if the chain and host verification stage is skipped.
-
-**default**: `false`
diff --git a/docs/telemetry/transformers.md b/docs/telemetry/transformers.md
new file mode 100644
index 000000000..dec03c5e0
--- /dev/null
+++ b/docs/telemetry/transformers.md
@@ -0,0 +1,5 @@
+# Transformers
+
+##### Transformers are responsible for mutating, parsing, or enriching events before they hit the output sink. Transformers are applied sequentially to every event routed to the output sink.
+
+You can parameterize transformers via the `yml` configuration in the `transformers` section.
diff --git a/docs/telemetry/transformers/remove.md b/docs/telemetry/transformers/remove.md
new file mode 100644
index 000000000..010ec3517
--- /dev/null
+++ b/docs/telemetry/transformers/remove.md
@@ -0,0 +1,15 @@
+# Remove
+
+##### The `remove` transform is used to exclude specific parameters from an event before it is forwarded or persisted. This is useful for reducing payload size, removing sensitive fields, or tailoring events to the needs of downstream consumers.
+
+## Configuration
+
+The `remove` transformer configuration is located in the `transformers.remove` section.
+
+### `enabled`
+
+Indicates if the `remove` transformer is enabled.
+
+### `params`
+
+Represents the list of parameters that are removed from the event.
diff --git a/docs/telemetry/transformers/rename.md b/docs/telemetry/transformers/rename.md
new file mode 100644
index 000000000..c60087ef5
--- /dev/null
+++ b/docs/telemetry/transformers/rename.md
@@ -0,0 +1,23 @@
+# Rename
+
+##### The `rename` transform is used to rename one or more event parameters before the event is emitted or forwarded. This is useful for standardizing field names, resolving naming conflicts, or adapting the event schema to match downstream expectations.
+
+## Configuration
+
+The `rename` transformer configuration is located in the `transformers.rename` section.
+
+### `enabled`
+
+Indicates if the `rename` transformer is enabled.
+
+### `params`
+
+Defines a list of mappings between original and new parameter names. The `old` key specifies the existing parameter name in the event, while the `new` key defines the name it should be renamed to during transformation. As an example, the following configuration renames the `username` parameter to `user` and `dport` parameter to `dst_port`
+
+```yaml
+params:
+ - old: username
+ new: user
+ - old: dport
+ new: dst_post
+```
diff --git a/docs/telemetry/transformers/replace.md b/docs/telemetry/transformers/replace.md
new file mode 100644
index 000000000..24c77017f
--- /dev/null
+++ b/docs/telemetry/transformers/replace.md
@@ -0,0 +1,23 @@
+# Replace
+
+##### The `replace` transformer substitutes all non-overlapping occurrences of a specified substring within string parameters. This is useful for normalizing values, redacting sensitive information, or standardizing event data before it is forwarded or stored. The transformation operates on a simple find-and-replace basis, scanning the target parameter and replacing every match with the configured replacement string.
+
+
+## Configuration
+
+The `replace` transformer configuration is located in the `transformers.replace` section.
+
+### `enabled`
+
+Indicates if the `replace` transformer is enabled.
+
+### `replacements`
+
+Defines a list of parameter replacement rules. Each rule targets a specific event parameter identified by the `param` key. Within that parameter, every occurrence of the substring specified in `old` is replaced with the value defined in `new`. As an example, the following config replaces the `HKEY_LOCAL_MACHINE` substring in the `key_path` parameter value with `HKLM`.
+
+```yaml
+replacements:
+ - param: key_path
+ old: HKEY_LOCAL_MACHINE
+ new: HKLM
+```
diff --git a/docs/telemetry/transformers/tags.md b/docs/telemetry/transformers/tags.md
new file mode 100644
index 000000000..174fa1b8c
--- /dev/null
+++ b/docs/telemetry/transformers/tags.md
@@ -0,0 +1,18 @@
+# Tags
+
+##### The `tags` transformer appends custom tags to an event’s metadata field. This allows events to be enriched with additional contextual labels that can later be used for filtering, classification, or routing. Tags are typically used to mark events with domain-specific or operational metadata—such as environment, source category, or processing stage without modifying the original event payload.
+
+
+## Configuration
+
+The `tags` transformer configuration is located in the `transformers.tags` section.
+
+### `enabled`
+
+Indicates if the `tags` transformer is enabled.
+
+### `tags`
+
+Defines the list of tags to be appended to the event metadata. Each value is added as a static label, enriching the event with additional contextual information.
+
+Tag values can also be dynamically resolved from environment variables by enclosing the variable name in `%`, for example, `%ENV_VAR%`. This allows tags to reflect runtime configuration without requiring changes to the static configuration file.
diff --git a/docs/telemetry/transformers/trim.md b/docs/telemetry/transformers/trim.md
new file mode 100644
index 000000000..21722a07d
--- /dev/null
+++ b/docs/telemetry/transformers/trim.md
@@ -0,0 +1,30 @@
+# Trim
+
+##### The `trim` transformer removes specified prefixes and/or suffixes from string event parameters. This is useful for normalizing values by stripping redundant or contextual markers, such as path segments, protocol prefixes, or formatting artifacts. The transformation operates only on string parameters and ensures that only the defined leading or trailing substrings are removed, leaving the core value intact.
+
+## Configuration
+
+The `trim` transformer configuration is located in the `transformers.trim` section.
+
+### `enabled`
+
+Indicates if the `trim` transformer is enabled.
+
+### `prefixes`
+
+Contains the list of parameter names and prefixes that are trimmed from the parameter's value.
+
+### `suffixes`
+
+Contains the list of parameter names and suffixes that are trimmed from the parameter's value.
+
+As an example, the following config trims the `HKEY_LOCAL_MACHINE` prefix and the `Keys` suffix from the `key_path` parameter value.
+
+```yaml
+prefixes:
+- param: key_path
+ trim: HKEY_LOCAL_MACHINE
+suffixes:
+- param: key_path
+ trim: Keys
+```
diff --git a/docs/themes/fibratus.css b/docs/themes/fibratus.css
deleted file mode 100755
index 243857082..000000000
--- a/docs/themes/fibratus.css
+++ /dev/null
@@ -1,1194 +0,0 @@
-@import url("https://fonts.googleapis.com/css?family=Roboto+Mono|Source+Code+Pro|Oxygen+Mono|Nova+Mono|Source+Sans+Pro:300,400,600");
-* {
- -webkit-font-smoothing: antialiased;
- -webkit-overflow-scrolling: touch;
- -webkit-tap-highlight-color: rgba(0, 0, 0, 0);
- -webkit-text-size-adjust: none;
- -webkit-touch-callout: none;
- box-sizing: border-box
-}
-
-body:not(.ready) {
- overflow: hidden
-}
-
-body:not(.ready) .app-nav,
-body:not(.ready)>nav,
-body:not(.ready) [data-cloak] {
- display: none
-}
-
-div#app {
- font-size: 30px;
- font-weight: lighter;
- margin: 40vh auto;
- text-align: center
-}
-
-div#app:empty:before {
- content: "Loading Fibratus Docs..."
-}
-
-footer span {
- font-size: 10px;
-}
-
-footer {
- text-align: center;
-}
-
-.search input {
- background-color: #F7F7F7;
- border-radius:5px;
- text-indent: 23px;
- -moz-border-radius:5px;
- -webkit-border-radius:5px;
-}
-
-.search .input-wrap::before {
- font-family: "FontAwesome";
- content: "\f002";
- position: relative;
- left: 8px;
- top: -2px;
- color: #d6e0f0;
- height: 24px;
- width: 0;
- overflow: visible;
- display: inline-block;
- line-height: 24px;
- z-index: 1;
-}
-
-.fast-icon {
- color: #ffba00;
-}
-
-.extensible-icon {
- color: #5D99E5;
-}
-
-.comprehensive-icon {
- color: #738FD6;
-}
-
-.operator > p {
- background-color: rgba(0, 27, 61, 0.03);
- border-left: 4px solid #6da9e2 !important;
- border-radius: 5px;
- color: #001b3d;
- font-weight: 600;
- font-size: .95em;
- padding: 0.7em 0.6em;
-}
-
-
-p.center {
- text-align: center;
- font-size: 30px;
-}
-
-.inner-icon {
- border-top: 1px solid #ffba00;
- color: #ffba00;
- font-size: 1.5em;
- margin-bottom: -.5em;
- margin-top: 1em;
- text-align: center;
-}
-
-.emoji {
- height: 1.2rem;
- vertical-align: middle
-}
-
-.progress {
- background-color: var(--theme-color, #42b983);
- height: 2px;
- left: 0;
- position: fixed;
- right: 0;
- top: 0;
- transition: width .2s, opacity .4s;
- width: 0;
- z-index: 999999
-}
-
-.hero-icon-left {
- font-size: 100px;
- color: #b6d4f0;
- float: left;
- margin-left: -10px;
- margin-bottom: 2px;
- margin-top: -10px;
- margin-right: 15px;
- --ionicon-stroke-width: 16px;
-}
-
-.search .search-keyword,
-.search a:hover {
- color: var(--theme-color, #42b983)
-}
-
-.search .search-keyword {
- font-style: normal;
- font-weight: 700
-}
-
-.hydrated {
- top: 3px;
- position: relative;
-}
-
-body,
-html {
- height: 100%
-}
-
-body {
- -moz-osx-font-smoothing: grayscale;
- -webkit-font-smoothing: antialiased;
- color: #34495e;
- font-family: Jost, Source Sans Pro, Helvetica Neue, Arial, sans-serif;
- font-size: 18px;
- letter-spacing: 0;
- margin: 0;
- overflow-x: hidden
-}
-
-img {
- max-width: 100%
-}
-
-a[disabled] {
- cursor: not-allowed;
- opacity: .6
-}
-
-kbd {
- border: 1px solid #ccc;
- border-radius: 3px;
- display: inline-block;
- font-size: 12px!important;
- line-height: 12px;
- margin-bottom: 3px;
- padding: 3px 5px;
- vertical-align: middle
-}
-
-li input[type=checkbox] {
- margin: 0 .2em .25em 0;
- vertical-align: middle
-}
-
-.app-nav {
- margin: 0;
- top: 0;
- position: fixed;
- right: 0;
- text-align: right;
- z-index: 10;
- background-color: #6da9e2;
- width: 100%;
- height: 0px;
- display: none;
-}
-
-.app-nav.no-badge {
- margin-right: 0px
-}
-
-.app-nav p {
- margin: 0
-}
-
-.app-nav>a {
- margin: 0 0rem;
- padding: 5px 0
-}
-
-.app-nav li,
-.app-nav ul {
- display: inline-block;
- list-style: none;
- top: -12px;
- margin-right: 10px;
-}
-
-.app-nav a {
- border-radius: 1rem;
- border: 1px solid var(--theme-color, #42b983);
- box-sizing: border-box;
- color: var(--theme-color, #42b983);
- display: inline-block;
- font-size: 0.6rem;
- font-weight: 600;
- letter-spacing: .1rem;
- margin: .1rem .1rem;
- padding: .4em .4rem;
- text-decoration: none;
- transition: all .15s ease;
- background-color: #4787BE;
- color: #F7F7F7
-}
-
-.sidebar-margin-nocover {
- margin-top: 0px;
-}
-
-.app-nav a.active {
- color: #fff;
-}
-.app-nav a:hover {
- background-color: #5894ce;
- opacity: .8
-}
-
-.app-nav li {
- display: inline-block;
- margin: 0 0.2rem;
- padding: 0px 0;
- position: relative
-}
-
-.app-nav li ul {
- background-color: #fff;
- border: 1px solid;
- border-color: #ddd #ddd #ccc;
- border-radius: 4px;
- box-sizing: border-box;
- display: none;
- max-height: calc(100vh - 81px);
- overflow-y: auto;
- padding: 10px 0;
- position: absolute;
- right: -15px;
- text-align: left;
- top: 100%;
- white-space: nowrap
-}
-
-.app-nav li ul li {
- display: block;
- font-size: 14px;
- line-height: 1rem;
- margin: 8px 14px;
- white-space: nowrap
-}
-
-.app-nav li ul a {
- display: block;
- font-size: inherit;
- margin: 0;
- padding: 0;
-}
-
-.app-nav li ul a.active {
- border-bottom: 0;
-}
-
-.app-nav li:hover ul {
- display: block
-}
-
-.app-nav .logo {
- color: #F7F7F7;
- font-size: 1.7rem;
- font-weight: 400;
- margin-left: 25px;
- margin-top: 2px;
- position: absolute;
- text-align: right;
- display: none;
- cursor: pointer;
- letter-spacing: 2px;
-}
-
-.github-corner {
- border-bottom: 0;
- position: fixed;
- right: 0;
- text-decoration: none;
- top: 0;
- z-index: 1
-}
-
-.github-corner:hover .octo-arm {
- -webkit-animation: octocat-wave .56s ease-in-out;
- animation: octocat-wave .56s ease-in-out
-}
-
-.github-corner svg {
- color: #fff;
- fill: var(--theme-color, #42b983);
- height: 80px;
- width: 80px
-}
-
-main {
- display: block;
- position: relative;
- width: 100vw;
- height: 100%;
- z-index: 0
-}
-
-main.hidden {
- display: none
-}
-
-.anchor {
- display: inline-block;
- text-decoration: none;
- transition: all .3s
-}
-
-.anchor span {
- color: #34495e
-}
-
-.anchor span:h {
- color: #6da9e2
-}
-
-.anchor:hover {
- text-decoration: none;
-}
-
-.ml-auto {
- margin-left: auto;
-}
-
-.mr-auto {
- margin-right: auto;
-}
-
-.divider-custom {
- margin: 1.25rem 0 1.5rem;
- width: 100%;
- display: flex;
- justify-content: center;
- align-items: center;
-}
-
-.divider-custom.divider-light .divider-custom-line {
- background-color: #2c3e50;
-}
-
-.divider-custom .divider-custom-line {
- width: 100%;
- max-width: 7rem;
- height: 0.25rem;
- background-color: #2c3e50;
- border-radius: 1rem;
- border-color: #2c3e50 !important;
-}
-
-.divider-custom .divider-custom-icon {
- color: #2c3e50 !important;
- font-size: 2rem;
-}
-
-.sidebar {
- border-right: 1px solid rgba(0, 0, 0, .07);
- overflow-y: auto;
- padding: 10px 10px 0;
- position: absolute;
- top: 0;
- bottom: 0;
- left: 0;
- transition: transform .25s ease-out;
- width: 300px;
- z-index: 20;
- background-color: #F7F7F7;
-}
-
-.sidebar>h1 {
- margin: 0 auto 1rem;
- font-size: 1.5rem;
- font-weight: 300;
- text-align: center
-}
-
-.sidebar>h1 a {
- color: inherit;
- text-decoration: none
-}
-
-.sidebar>h1 .app-nav {
- display: block;
- position: static
-}
-
-.sidebar .sidebar-nav {
- line-height: 1.7em;
- padding-bottom: 40px
-}
-
-.sidebar li.collapse .app-sub-sidebar {
- display: none
-}
-
-.sidebar ul {
- margin: 0 0 0 8px;
- padding: 0;
-}
-
-.sidebar li>p {
- font-weight: 700;
- margin: 0
-}
-
-.sidebar ul,
-.sidebar ul li {
- list-style: none;
- line-height: 20px;
- margin-bottom: -4px;
-}
-
-.sidebar ul li:hover {
- cursor: pointer;
- color: #6da9e2;
-}
-
-.sidebar ul +ul {
- max-height:0;
- overflow:hidden;
- transition:0.5s linear;
-}
-
-.sidebar ul li {
- border-bottom: none;
- display: block;
- padding: 4px 8px;
- font-size: 19px;
- font-weight: 500;
-}
-
-.sidebar ul li ul {
- border-left: 1px solid rgba(0, 0, 0, .07);
-}
-
-.sidebar ul li ul {
- padding-left: 1px
-}
-
-.sidebar::-webkit-scrollbar {
- width: 4px
-}
-
-.sidebar::-webkit-scrollbar-thumb {
- background: transparent;
- border-radius: 4px
-}
-
-.sidebar:hover::-webkit-scrollbar-thumb {
- background: hsla(0, 0%, 53.3%, .4)
-}
-
-.sidebar:hover::-webkit-scrollbar-track {
- background: hsla(0, 0%, 53.3%, .1)
-}
-
-.sidebar-toggle {
- background-color: transparent;
- border: 0;
- outline: none;
- padding: 10px;
- position: absolute;
- bottom: 0;
- left: 0;
- text-align: center;
- transition: opacity .3s;
- width: 284px;
- z-index: 30
-}
-
-.sidebar-toggle .sidebar-toggle-button:hover {
- opacity: .4
-}
-
-.sidebar-toggle span {
- background-color: var(--theme-color, #42b983);
- display: block;
- margin-bottom: 4px;
- width: 16px;
- height: 2px
-}
-
-body.sticky .sidebar,
-body.sticky .sidebar-toggle {
- margin-top: 0px;
- position: fixed;
-}
-
-body.sticky .page_toc {
- margin-top: 15px;
-}
-
-body.sticky .app-nav .logo {
- display: none;
-}
-
-.page_toc ul a:hover span {
- color: #6da9e2 !important;
-}
-
-.page_toc ul a {
- font-size: 17px !important;
-}
-
-.page_toc .active {
- border-left: 3px solid !important;
-}
-
-.page_toc {
- padding-left: 12px !important;
-}
-
-.content {
- padding-top: 30px;
- position: absolute;
- top: 0;
- right: 0;
- bottom: 0;
- left: 300px;
- transition: left .25s ease;
- background-color: #F7F7F7;
-}
-
-.markdown-section {
- margin: 0 auto;
- max-width: 80%;
- padding: 30px 15px 40px;
- position: relative;
-}
-
-.markdown-section>* {
- box-sizing: border-box;
- font-size: inherit
-}
-
-.markdown-section>:first-child {
- margin-top: 0!important
-}
-
-.markdown-section hr {
- border: none;
- border-bottom: 1px solid #eee;
- margin: 2em 0
-}
-
-.markdown-section iframe {
- border: 1px solid #eee;
- width: 1px;
- min-width: 100%
-}
-
-.markdown-section table {
- border-collapse: collapse;
- border-spacing: 0;
- display: block;
- margin-bottom: 1rem;
- overflow: auto;
- width: 100%
-}
-
-.markdown-section th {
- font-weight: 700
-}
-
-.markdown-section td,
-.markdown-section th {
- border: 1px solid #ddd;
- padding: 6px 13px
-}
-
-.markdown-section tr {
- border-top: 1px solid #ccc
-}
-
-.markdown-section p.tip,
-.markdown-section tr:nth-child(2n) {
- background-color: rgba(0, 27, 61, 0.03);
-}
-
-.markdown-section p.tip {
- border-bottom-right-radius: 2px;
- border-left: 4px solid #f66;
- border-top-right-radius: 2px;
- margin: 2em 0;
- padding: 12px 24px 12px 30px;
- position: relative
-}
-
-.markdown-section p.tip:before {
- background-color: #f66;
- border-radius: 100%;
- color: #fff;
- content: "!";
- font-family: Dosis, Source Sans Pro, Helvetica Neue, Arial, sans-serif;
- font-size: 14px;
- font-weight: 700;
- left: -12px;
- line-height: 20px;
- position: absolute;
- height: 20px;
- width: 20px;
- text-align: center;
- top: 14px
-}
-
-.markdown-section p.tip code {
- background-color: #efefef
-}
-
-.markdown-section p.tip em {
- color: #34495e
-}
-
-.markdown-section p.warn {
- background: rgba(66, 185, 131, .1);
- border-radius: 2px;
- padding: 1rem
-}
-
-.markdown-section ul.task-list>li {
- list-style-type: none
-}
-
-body.close .sidebar {
- transform: translateX(-300px)
-}
-
-body.close .sidebar-toggle {
- width: auto
-}
-
-body.close .content {
- left: 0
-}
-
-@media print {
- .app-nav,
- .github-corner,
- .sidebar,
- .sidebar-toggle {
- display: none
- }
-}
-
-
-@media screen and (max-width: 1300px) {
- .page_toc {
- display: none;
- }
-}
-
-@media screen and (max-width: 768px) {
- .github-corner,
- .sidebar,
- .sidebar-toggle {
- position: fixed;
- }
- .app-nav {
- margin-top: 16px;
- }
- .app-nav li ul {
- top: 30px;
- }
- main {
- height: auto;
- overflow-x: hidden;
- }
- .sidebar {
- left: -300px;
- transition: transform 0.25s ease-out;
- }
- .content {
- left: 0;
- max-width: 100vw;
- position: static;
- padding-top: 20px;
- transition: transform 0.25s ease;
- }
- .app-nav,
- .github-corner {
- transition: transform 0.25s ease-out;
- }
- .sidebar-toggle {
- background-color: transparent;
- width: auto;
- padding: 30px 30px 10px 10px;
- }
- body.close .sidebar {
- transform: translateX(300px);
- }
- body.close .sidebar-toggle {
- background-color: hsla(0, 0%, 100%, 0.8);
- transition: background-color 1s;
- width: 284px;
- padding: 10px;
- }
- body.close .content {
- transform: translateX(300px);
- }
- body.close .app-nav,
- body.close .github-corner {
- display: none;
- }
- .github-corner:hover .octo-arm {
- -webkit-animation: none;
- animation: none;
- }
- .github-corner .octo-arm {
- -webkit-animation: octocat-wave 0.56s ease-in-out;
- animation: octocat-wave 0.56s ease-in-out;
- }
- .page_toc {
- display: none;
- }
-}
-
-@keyframes octocat-wave {
- 0%,
- to {
- transform: rotate(0)
- }
- 20%,
- 60% {
- transform: rotate(-25deg)
- }
- 40%,
- 80% {
- transform: rotate(10deg)
- }
-}
-
-section.cover {
- align-items: center;
- background-position: 50%;
- background-repeat: no-repeat;
- background-size: cover;
- height: 205vh;
- display: none;
-}
-
-section.cover.show {
- display: flex;
- background: linear-gradient(#1180e0,#c7def4) !important;
-}
-
-section.cover.has-mask .mask {
- background-color: #fff;
- opacity: .8;
- position: absolute;
- top: 0;
- height: 100%;
- width: 100%
-}
-
-section.cover .cover-main {
- flex: 1;
- margin: -20px 16px 0px;
- text-align: center;
- position: relative;
-}
-
-section.cover .cover-main img {
- margin-top: 45px;
-}
-
-section.cover a {
- color: inherit
-}
-
-section.cover a,
-section.cover a:hover {
- text-decoration: none
-}
-
-section.cover p {
- line-height: 1.5rem;
- margin: 1em 0
-}
-
-section.cover h1 {
- color: #fff;
- font-size: 2.5rem;
- font-weight: 300;
- margin: .625rem 0 2.5rem;
- position: relative;
- text-align: center
-}
-
-section.cover h1 a {
- display: block
-}
-
-section.cover h1 small {
- bottom: -.4375rem;
- font-size: 1rem;
- position: absolute
-}
-
-section.cover blockquote {
- font-size: 1.5rem;
- text-align: center
-}
-
-section.cover ul {
- line-height: 1.8;
- list-style-type: none;
- margin: 1em auto;
- max-width: 500px;
- padding: 0
-}
-
-section.cover .cover-main>p:nth-last-child(2) a {
- background: linear-gradient(340.87deg,#777ce0 -5.97%,#60cefd 100.83%);
- box-shadow: 0px 20px 30px -3px rgba(112,153,234,.45);
- border-radius: 2rem;
- border: 1px solid var(--theme-color, #42b983);
- box-sizing: border-box;
- color: #34495e;
- display: inline-block;
- font-size: 1.05rem;
- letter-spacing: .1rem;
- margin: .5rem 1rem;
- padding: .75em 2rem;
- text-decoration: none;
- transition: .3s all ease-in-out;
-}
-
-section.cover .cover-main {
- position: relative;
- top: 0px;
-}
-
-section.cover .cover-main>p:nth-last-child(2) a:hover {
- color: inherit;
- opacity: .8;
-}
-
-section.cover .cover-main h1 {
- font-size: 3.5rem;
-}
-
-section.cover blockquote>p>a {
- border-bottom: 2px solid var(--theme-color, #42b983);
- transition: color .3s
-}
-
-section.cover blockquote>p>a:hover {
- color: var(--theme-color, #42b983)
-}
-
-section.cover .cover-main div {
- position: relative;
-}
-
-.sidebar,
-body {
- background-color: #F7F7F7;
-}
-
-.sidebar {
- color: #364149
-}
-
-.sidebar li {
- margin: 10px 0
-}
-
-.sidebar ul li a {
- color: #505d6b;
- font-size: 16px;
- font-weight: 500;
- overflow: hidden;
- text-decoration: none;
- text-overflow: ellipsis;
- white-space: nowrap;
-}
-
-.sidebar ul li a:hover {
- text-decoration: underline
-}
-
-.sidebar ul li ul {
- padding: -1;
- margin: 0
-}
-
-.sidebar ul li.active>a {
- color: var(--theme-color, #42b983);
- font-weight: 600
-}
-
-.app-sub-sidebar li:before {
- padding-right: 4px;
- float: left
-}
-
-.markdown-section h1,
-.markdown-section h2,
-.markdown-section h3,
-.markdown-section h4,
-.markdown-section strong {
- color: #2c3e50;
- font-weight: 600
-}
-
-.markdown-section h4 {
- border-bottom: 1px solid rgba(0, 0, 0,.045);
-}
-
-.markdown-section h2.center {
- color: #2c3e50;
- font-weight: 600;
- text-align: center;
-}
-
-.markdown-section a {
- color: var(--theme-color, #42b983);
- font-weight: 600
-}
-
-.markdown-section h1 {
- font-size: 2rem;
- margin: 0 0 1rem;
- border-bottom: 1px solid rgba(0, 0, 0,.075);
-}
-
-.markdown-section h2 {
- font-size: 1.75rem;
- margin: 45px 0 .8rem
-}
-
-.markdown-section h3 {
- font-size: 1.5rem;
- margin: 40px 0 .6rem
-}
-
-.markdown-section h4 {
- font-size: 1.25rem
-}
-
-.markdown-section h5 {
- font-size: 1rem
-}
-
-.markdown-section h6 {
- color: #777;
- font-size: 1rem
-}
-
-.markdown-section figure,
-.markdown-section p {
- margin: 1.2em 0
-}
-
-.markdown-section ol,
-.markdown-section p,
-.markdown-section ul {
- line-height: 1.6rem;
- word-spacing: .05rem
-}
-
-.markdown-section ol,
-.markdown-section ul {
- padding-left: 1.5rem
-}
-
-.markdown-section blockquote {
- border-left: 4px solid var(--theme-color, #42b983);
- color: #858585;
- margin: 2em 0;
- padding-left: 20px
-}
-
-.markdown-section blockquote p {
- font-weight: 600;
- margin-left: 0
-}
-
-.markdown-section iframe {
- margin: 1em 0
-}
-
-.markdown-section em {
- color: #6da9e2
-}
-
-.pagination-item-title:hover {
- color: #6da9e2
-}
-
-.markdown-section code {
- border-radius: 5px;
- color: #5894ce;
- font-size: .8rem;
- margin: 0 2px;
- padding: 3px 5px;
- white-space: pre-wrap;
- font-weight: 600;
-}
-
-.markdown-section code,
-.markdown-section pre {
- background-color: rgba(0, 27, 61, 0.03);
- font-family: Nova Mono, Oxygen Mono, Source Code Pro, Roboto Mono, Monaco, courier, monospace
-}
-
-.markdown-section pre {
- font-family: Nova Mono, Source Code Pro, Roboto Mono, Monaco, courier, monospace;
- -moz-osx-font-smoothing: initial;
- -webkit-font-smoothing: initial;
- line-height: 1.5rem;
- margin: 1.2em 0;
- overflow: auto;
- padding: 0 1.4rem;
- position: relative;
- word-wrap: normal;
- border-radius: 5px;
-}
-
-.token.cdata,
-.token.comment,
-.token.doctype,
-.token.prolog {
- color: #8e908c
-}
-
-.token.namespace {
- opacity: .7
-}
-
-.token.boolean,
-.token.number {
- color: #c76b29
-}
-
-.token.punctuation {
- color: #525252
-}
-
-.token.property {
- color: #c08b30
-}
-
-.token.tag {
- color: #2973b7
-}
-
-.token.string {
- color: var(--theme-color, #42b983)
-}
-
-.token.selector {
- color: #6679cc
-}
-
-.token.attr-name {
- color: #2973b7
-}
-
-.language-css .token.string,
-.style .token.string,
-.token.entity,
-.token.url {
- color: #22a2c9
-}
-
-.token.attr-value,
-.token.control,
-.token.directive,
-.token.unit {
- color: var(--theme-color, #42b983)
-}
-
-.token.function,
-.token.keyword {
- color: #e96900
-}
-
-.token.atrule,
-.token.regex,
-.token.statement {
- color: #22a2c9
-}
-
-.token.placeholder,
-.token.variable {
- color: #3d8fd1
-}
-
-.token.deleted {
- text-decoration: line-through
-}
-
-.token.inserted {
- border-bottom: 1px dotted #202746;
- text-decoration: none
-}
-
-.token.italic {
- font-style: italic
-}
-
-.token.bold,
-.token.important {
- font-weight: 700
-}
-
-.token.important {
- color: #c94922
-}
-
-.token.entity {
- cursor: help
-}
-
-.markdown-section pre>code {
- -moz-osx-font-smoothing: initial;
- -webkit-font-smoothing: initial;
- background-color: #f8f8f8a3;
- border-radius: 0px;
- color: #5994CE;
- display: block;
- font-family: Nova Mono, Oxygen Mono, Source Code Pro, Roboto Mono, Monaco, courier, monospace;
- font-size: .85rem;
- line-height: inherit;
- margin: 0 2px;
- max-width: inherit;
- overflow: inherit;
- padding: 1.2em 5px;
- white-space: inherit
-}
-
-.markdown-section code:after,
-.markdown-section code:before {
- letter-spacing: .05rem
-}
-
-code .token {
- -moz-osx-font-smoothing: initial;
- -webkit-font-smoothing: initial;
- min-height: 1.5rem;
- position: relative;
- left: auto
-}
-
-pre:after {
- color: #ccc;
- content: attr(data-lang);
- font-size: .6rem;
- font-weight: 600;
- height: 15px;
- line-height: 15px;
- padding: 5px 10px 0;
- position: absolute;
- right: 0;
- text-align: right;
- top: 0
-}
diff --git a/docs/transformers/introduction.md b/docs/transformers/introduction.md
deleted file mode 100644
index bf413dc7c..000000000
--- a/docs/transformers/introduction.md
+++ /dev/null
@@ -1,5 +0,0 @@
-# Parsing, Enriching, Transforming
-
-Transformers are responsible for mutating, parsing, or enriching kernel events before they hit the output sink. They offer a fair amount of flexibility to shape the structure of the event parameters. Transformers are applied sequentially to every event routed to the output sink.
-
-You can parameterize transformers via the `yml` configuration in the `transformers` section.
diff --git a/docs/transformers/remove.md b/docs/transformers/remove.md
deleted file mode 100644
index 69279ca72..000000000
--- a/docs/transformers/remove.md
+++ /dev/null
@@ -1,50 +0,0 @@
-# Remove
-
-The `remove` transform drops parameters from the event. Given the following event parameters:
-
-```
-{
- 'file_name': 'C:\WINDOWS\system32\config\systemprofile\AppData\WindowsApps\',
- 'file_object': 'ffffa88c7ea077d0',
- 'irp': 'ffffa88c746b2a88',
- 'operation': 'supersede',
- 'share_mask': 'rw-',
- 'type': 'directory'
-}
-```
-
-And the `remove` transformer configuration:
-
-```
-transformers:
- remove:
- enabled: true
- kparams:
- - irp
- - share_mask
- - file_object
-```
-
-The event will contain the following parameters:
-
-```
-{
- 'file_name': 'C:\WINDOWS\system32\config\systemprofile\AppData\WindowsApps\',
- 'operation': 'supersede',
- 'type': 'directory'
-}
-```
-
-### Configuration {docsify-ignore}
-
-The `remove` transformer configuration is located in the `transformers.remove` section.
-
-#### enabled
-
-Indicates if the `remove` transformer is enabled.
-
-**default**: `false`
-
-#### kparams
-
-Represents the list of parameters that are removed from the event.
diff --git a/docs/transformers/rename.md b/docs/transformers/rename.md
deleted file mode 100644
index 10ceca259..000000000
--- a/docs/transformers/rename.md
+++ /dev/null
@@ -1,54 +0,0 @@
-# Rename
-
-The `rename` transform rename one or more parameters. Given the following event parameters:
-
-```
-{
- 'file_name': 'C:\WINDOWS\system32\config\systemprofile\AppData\WindowsApps\',
- 'file_object': 'ffffa88c7ea077d0',
- 'irp': 'ffffa88c746b2a88',
- 'operation': 'supersede',
- 'share_mask': 'rw-',
- 'type': 'directory'
-}
-```
-
-And the `rename` transformer configuration:
-
-```
-transformers:
- rename:
- enabled: true
- kparams:
- - old: file_name
- new: file
- - old: file_object
- new: fobj
-```
-
-The event will contain the following parameters:
-
-```
-{
- 'name': 'C:\WINDOWS\system32\config\systemprofile\AppData\WindowsApps\',
- 'fobj': 'ffffa88c7ea077d0',
- 'irp': 'ffffa88c746b2a88',
- 'operation': 'supersede',
- 'share_mask': 'rw-',
- 'type': 'directory'
-}
-```
-
-### Configuration {docsify-ignore}
-
-The `rename` transformer configuration is located in the `transformers.rename` section.
-
-#### enabled
-
-Indicates if the `rename` transformer is enabled.
-
-**default**: `false`
-
-#### kparams
-
-Contains the list of old/new parameter name mappings. `old` key represents the original parameter name, while `new` is the new parameter name.
diff --git a/docs/transformers/replace.md b/docs/transformers/replace.md
deleted file mode 100644
index f7e96e6d3..000000000
--- a/docs/transformers/replace.md
+++ /dev/null
@@ -1,46 +0,0 @@
-# Replace
-
-The `replace` transformer replaces all non-overlapping instances of string parameters with the specified substring. Given the following event parameters:
-
-```
-{
- 'key_handle': 0,
- 'key_name': 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\StateSeparation\Keys',
- 'status': 'key not found'
-}
-```
-
-And the `replace` transformer configuration:
-
-```
-replace:
- enabled: true
- replacements:
- - kparam: key_name
- old: HKEY_LOCAL_MACHINE
- new: HKLM
-```
-
-The transformer produces the following parameters:
-
-```
-{
- 'key_handle': 0,
- 'key_name': 'HKLM\System\CurrentControlSet\Control\StateSeparation\Keys',
- 'status': 'key not found'
-}
-```
-
-### Configuration {docsify-ignore}
-
-The `replace` transformer configuration is located in the `transformers.replace` section.
-
-#### enabled
-
-Indicates if the `replace` transformer is enabled.
-
-**default**: `false`
-
-#### replacements
-
-Contains the list of parameter replacements. For each target event parameter identified by the `kparam` key, `old` represent the substring that will be replaced by the `new` substring.
diff --git a/docs/transformers/tags.md b/docs/transformers/tags.md
deleted file mode 100644
index 43f071b8f..000000000
--- a/docs/transformers/tags.md
+++ /dev/null
@@ -1,27 +0,0 @@
-# Tags
-
-The `tags` transformer appends custom tags to event's metadata field.
-
-### Configuration {docsify-ignore}
-
-The `tags` transformer configuration is located in the `transformers.tags` section.
-
-#### enabled
-
-Indicates if the `tags` transformer is enabled.
-
-**default**: `false`
-
-#### tags
-
-Contains the list of tags that are appended to event metadata. Values can be fetched from environment variables by enclosing them in `%`. Example:
-
-```
-tags:
- enabled: true
- tags:
- - key: env
- value: prod
- - key: drive
- value: %HOMEDRIVE%
-```
diff --git a/docs/transformers/trim.md b/docs/transformers/trim.md
deleted file mode 100644
index 224c325a2..000000000
--- a/docs/transformers/trim.md
+++ /dev/null
@@ -1,52 +0,0 @@
-# Trim
-
-The `trim` transformer cuts off specified prefixes/suffixes from the string event parameters. Given the following event parameters:
-
-```
-{
- 'key_handle': 0,
- 'key_name': 'HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\StateSeparation\Keys',
- 'status': 'key not found'
-}
-```
-
-And the `trim` transformer configuration:
-
-```
-replace:
- enabled: true
- prefixes:
- - kparam: key_name
- trim: HKEY_LOCAL_MACHINE
- suffixes:
- - kparam: key_name
- trim: Keys
-```
-
-The transformer produces the following parameters:
-
-```
-{
- 'key_handle': 0,
- 'key_name': '\System\CurrentControlSet\Control\StateSeparation\',
- 'status': 'key not found'
-}
-```
-
-### Configuration {docsify-ignore}
-
-The `trim` transformer configuration is located in the `transformers.trim` section.
-
-#### enabled
-
-Indicates if the `trim` transformer is enabled.
-
-**default**: `false`
-
-#### prefixes
-
-Contains the list of parameter names and prefixes that are trimmed from the parameter's value.
-
-#### suffixes
-
-Contains the list of parameter names and suffixes that are trimmed from the parameter's value.
diff --git a/docs/troubleshooting.md b/docs/troubleshooting.md
new file mode 100644
index 000000000..fa7ae8664
--- /dev/null
+++ b/docs/troubleshooting.md
@@ -0,0 +1,74 @@
+# Troubleshooting
+
+## Logs
+
+Fibratus logs various diagnostics and error messages to log files residing in the `%PROGRAM FILES%\Fibratus\Logs` directory. Logs serve as an invaluable resource for debugging or chasing code bugs.
+
+It's possible to influence the behavior of how log file are written. The configuration options are stored in the `logging` section of the `yml` file.
+
+### `level`
+
+Specifies the minimum allowed log level. Anything logged below this log level will not get dumped to a file or stdout stream. Possible values are `debug`, `info`, `warn`, `error`, `panic`.
+
+### `max-age`
+
+Represents the maximum number of days to retain old log files based on the timestamp encoded in their filename. By default, all log files are retained.
+
+
+### `max-backup`
+
+Specifies the maximum number of old log files to retain.
+
+
+### `max-size`
+
+Specifies the maximum size in megabytes of the log file before it gets rotated.
+
+### `formatter`
+
+Represents the log file format. Possible values are `text` or `json`. By default, Fibratus will dump the logs in JSON format.
+
+
+### `path`
+
+Represents the alternative paths for storing the logs.
+
+### `log-stdout`
+
+Indicates whether log lines are written to standard output in addition to writing them to log files.
+
+
+## Profiling
+
+[pprof](https://golang.org/pkg/net/http/pprof/) is an extremely useful profiling facility that lets you collect CPU profiles, traces and heap allocation profiles among others. With `pprof` it is easy to spot top CPU consumers or find opportunities for code optimizations.
+
+To get the profile, you can use the `go tool pprof` tool. The pprof HTTP handlers are exposed on `localhost:8482` by default. To override the TCP port or the transport protocol, modify the `api.transport` configuration option. For example, getting the CPU profile could be accomplished with the following command:
+
+
+$ go tool pprof http://localhost:8482/debug/pprof/profile
+
+
+
+The profile can be saved to the disk by typing `proto` in the interactive `pprof` CLI.
+
+## Stats
+
+Sometimes you need to go beyond surface-level visibility and understand how Fibratus itself is behaving under the hood. Especially when troubleshooting performance issues, validating pipeline behavior, or tuning rules. For that, Fibratus exposes a rich set of internal telemetry and runtime metrics.
+
+These metrics are made available via Go’s [expvar](https://golang.org/pkg/expvar/) interface, which provides a lightweight, structured way to inspect counters, gauges, and other runtime values directly from within the application.
+
+To quickly explore the metrics, you can use the built-in CLI command:
+
+
+$ fibratus stats
+
+
+
+This command surfaces a snapshot of Fibratus’ internal state, including event throughput, queue depths, dropped events, and other operational signals. It’s particularly useful for:
+
+* Diagnosing bottlenecks in event processing pipelines
+* Verifying that filters and rules are behaving as expected
+* Monitoring resource utilization trends over time
+* Gaining confidence in system stability during high event volumes
+
+Because these metrics are exposed via [expvar](https://golang.org/pkg/expvar/), they can also be integrated with external observability tools or scraped programmatically, making it easier to incorporate Fibratus into a broader monitoring and alerting ecosystem.
diff --git a/docs/troubleshooting/logs.md b/docs/troubleshooting/logs.md
deleted file mode 100644
index 7e2c18e52..000000000
--- a/docs/troubleshooting/logs.md
+++ /dev/null
@@ -1,47 +0,0 @@
-# Logs
-
-Fibratus logs various diagnostics and error messages to log files residing in the `%PROGRAM FILES%\Fibratus\Logs` directory. Logs serve as an invaluable resource for debugging or chasing down issues in Fibratus.
-
-### Configuration {docsify-ignore}
-
-It's possible to influence the behavior of how log file are written. The configuration options are stored in the `logging` section of the `yml` file.
-
-#### level
-
-Specifies the minimum allowed log level. Anything logged below this log level will not get dumped to a file or stdout stream. Possible values are `debug`, `info`, `warn`, `error`, `panic`.
-
-**default**: `info`
-
-#### max-age
-
-Represents the maximum number of days to retain old log files based on the timestamp encoded in their filename. By default, all log files are retained.
-
-**default**: `0`
-
-#### max-backup
-
-Specifies the maximum number of old log files to retain.
-
-**default**: `15`
-
-#### max-size
-
-Specifies the maximum size in megabytes of the log file before it gets rotated.
-
-**default**: `100`
-
-#### formatter
-
-Represents the log file format. Possible values are `text` or `json`. By default, Fibratus will dump the logs in JSON format.
-
-**default**: `json`
-
-#### path
-
-Represents the alternative paths for storing the logs.
-
-#### log-stdout
-
-Indicates whether log lines are written to standard output in addition to writing them to log files.
-
-**default**: `false`
diff --git a/docs/troubleshooting/pprof.md b/docs/troubleshooting/pprof.md
deleted file mode 100644
index a97391bf5..000000000
--- a/docs/troubleshooting/pprof.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# Profiling
-
-[pprof](https://golang.org/pkg/net/http/pprof/) is an extremely useful profiling facility that lets you collect CPU profiles, traces and heap allocation profiles among others. With `pprof` it is easy to spot top CPU consumers or find opportunities for code optimizations.
-
-To get the profile, you can use the `go tool pprof` tool. The pprof HTTP handlers are exposed on `localhost:8482` by default. To override the TCP port or the transport protocol, modify the `api.transport` configuration option. For example, getting the CPU profile could be accomplished with the following command:
-
-```
-$ go tool pprof http://localhost:8482/debug/pprof/profile
-```
diff --git a/docs/troubleshooting/stats.md b/docs/troubleshooting/stats.md
deleted file mode 100644
index 07a296943..000000000
--- a/docs/troubleshooting/stats.md
+++ /dev/null
@@ -1,3 +0,0 @@
-# Stats
-
-Sometimes it is useful to dive into the internal Fibratus telemetry to get various metrics about its inner workings. Fibratus exposes its internal metrics through the [expvar](https://golang.org/pkg/expvar/) interface. To explore the metrics you can execute the `fibratus stats` command.
diff --git a/docs/yara.md b/docs/yara.md
new file mode 100644
index 000000000..5d0d4b797
--- /dev/null
+++ b/docs/yara.md
@@ -0,0 +1,97 @@
+# Memory scanning
+
+##### [YARA](https://virustotal.github.io/yara/) is a widely adopted framework for binary pattern matching and malware classification. It allows to define rules that describe suspicious or malicious artifacts based on strings, byte patterns, and binary format properties.
+
+Fibratus integrates YARA directly into its event processing pipeline to enable real-time scanning of memory and binaries, focusing on in-memory threats such as fileless malware, suspicious [PE](https://learn.microsoft.com/en-us/windows/win32/debug/pe-format) artifacts, and abnormal memory behavior.
+
+Memory or binary scanning is triggered in response to various behavioral signals:
+
+- new process creation
+- loading of an unsigned/untrusted executable/DLL or when the executable/DLL is loaded from the unbacked memory region
+- creation of executable, DLL, or driver PE files
+- creation of [ADS](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/e2b19412-a925-4360-b009-86e3b8a020c8) (Alternate Data Streams)
+- RWX memory allocations
+- mapping of a suspicious view of section
+- writing a binary registry value
+
+Fibratus embeds [`libyara`](https://yara.readthedocs.io/en/stable/capi.html) via native bindings. The YARA engine is statically linked so no additional installation is required. Rules are compiled and executed inside the Fibratus runtime.
+
+!> Fibratus detection rules use a custom, purpose-built format tailored to its event processing and detection model. In contrast, YARA rules follow a widely adopted industry standard for pattern matching and malware classification. Because they serve different purposes and operate independently, Fibratus does not include built-in YARA rules. However, you can integrate and run community-maintained [YARA rules](https://github.com/yara-rules/rules) alongside Fibratus.
+
+
+## Scanning
+
+The YARA scanner is disabled by default. To enable it, set the `yara.enabled` option in the configuration file.
+
+For the scanner to function, YARA rules must be compiled and loaded into the engine. You can do this by specifying file system paths in the `yara.rule.paths` configuration option. These directories are scanned recursively for `.yar` files. Alternatively, rules can be defined inline as strings directly within the configuration file.
+
+Alerts generated from rule matches are automatically dispatched through all configured alert senders.
+When an event matches a YARA rule, its metadata is enriched with the corresponding match details. The `yara.matches` field contains a JSON array where each object represents a YARA rule match.
+
+## Configuration
+
+YARA scanner related options are located in the `yara` section of the configuration file.
+
+### `enabled`
+
+Indicates if the YARA scanner is enabled.
+
+### `rule`
+
+The `rule` key contains various nested keys. The `paths` key identifies directories that contain YARA rule definitions. It is also possible to link each directory to YARA namespace. The `strings` key allows defining inline YARA rules. Example:
+
+```python
+rule:
+ paths:
+ - path: C:\\yara-rules
+ namespace: default
+ - path: C:\\pdf-rules
+ namespace: pdf
+
+ strings:
+ - string: rule test : tag1 { meta: author = \"Hilko Bengen\" strings: $a = \"abc\" fullword condition: $a }
+ namespace: notepad
+```
+
+### `alert-template`
+
+Specifies templates for the alert text in Go [templating](https://golang.org/pkg/text/template) language.
+
+### `fastscan`
+
+Determines when multiple matches of the same string can be avoided when not necessary.
+
+### `scan-timeout`
+
+Specifies the timeout for the scanner. If the timeout is reached, the scan operation is cancelled.
+
+### `skip-files`
+
+Indicates whether file scanning is disabled. This affects the scan triggered by image loading, create file, and file mapping operations.
+
+### `skip-allocs`
+
+Indicates whether scanning on suspicious memory allocations is disabled.
+
+
+### `skip-mmaps`
+
+Indicates whether scanning on suspicious mappings of sections is disabled.
+
+### `skip-registry`
+
+Indicates whether registry value scanning is disabled.
+
+
+### `excluded-files`
+
+Contains the list of the comma-separated file paths that shouldn't be scanned. Wildcard matching is supported. For example:
+
+```python
+excluded-files:
+ - ?:\\Windows\\System32\\kernel32.dll
+```
+
+### `excluded-procs`
+
+Contains the list of the comma-separated process executable paths that shouldn't be scanned. Wildcard matching is supported.
diff --git a/docs/yara/alerts.md b/docs/yara/alerts.md
deleted file mode 100644
index 8dd379e38..000000000
--- a/docs/yara/alerts.md
+++ /dev/null
@@ -1,39 +0,0 @@
-# Alerts
-
-Alerts on rule matches are automatically sent via all active alert senders.
-
-## Event metadata {docsify-ignore}
-
-When the event triggers a specific YARA rule, its metadata is automatically decorated with the rule matches.
-The `yara.matches` tag contains the JSON array payload where each object represents the YARA rule match. For example:
-
-```json
-[
- {
- "rule": "AnglerEKredirector ",
- "namespace": "EK",
- "tags": null,
- "metas": [
- {
- "identifier": "description",
- "value": "Angler Exploit Kit Redirector"
- }
- ],
- "strings": "..."
- },
- {
- "rule": "angler_flash_uncompressed ",
- "namespace": "EK",
- "tags": [
- "exploitkit"
- ],
- "metas": [
- {
- "identifier": "description",
- "value": "Angler Exploit Kit Detection"
- }
- ],
- "strings": "..."
- }
-]
-```
diff --git a/docs/yara/introduction.md b/docs/yara/introduction.md
deleted file mode 100644
index e8c0fe145..000000000
--- a/docs/yara/introduction.md
+++ /dev/null
@@ -1,15 +0,0 @@
-# Pattern Matching Swiss Knife
-
-[YARA](https://virustotal.github.io/yara/) is a prominent tool for binary pattern matching that aims to streamline and accelerate the classification of malware specimens. Fibratus interacts with the `libyara` through C bindings. The `libyara` dependency is statically linked, so no further software needs to be installed.
-
-**Fibratus/YARA** tandem aims to detect in-memory threats and malicious **PE** files by reacting on various signals including:
-
-- new process creation
-- loading of an unsigned/untrusted executable/DLL or when the executable/DLL is loaded from the unbacked memory region
-- creation of executable, DLL, or driver PE files
-- creation of [ADS](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/e2b19412-a925-4360-b009-86e3b8a020c8) (Alternate Data Streams)
-- RWX memory allocations
-- mapping of a suspicious view of section
-- writing a binary registry value
-
-The YARA scanner is not enabled by default, but you can do that by modifying the `yara.enabled` key in the configuration file.
diff --git a/docs/yara/scanning.md b/docs/yara/scanning.md
deleted file mode 100644
index dcbe3d556..000000000
--- a/docs/yara/scanning.md
+++ /dev/null
@@ -1,86 +0,0 @@
-# Scanning Processes
-
-For the YARA scanner to operate correctly, the rules have to be compiled and loaded into the engine. This is accomplished by providing file system paths with YARA rule definitions in the `rule.paths` configuration keys. The directories are scanned recursively for any `.yar` file. Alternatively, it is possible to provide the rules as inline strings directly in the Fibratus configuration file.
-
-### Configuration {docsify-ignore}
-
-YARA scanner related options are located in the `yara` section of the configuration file.
-
-#### enabled
-
-Indicates if the YARA scanner is enabled. When enabled, each newly created process is scanned for pattern matches.
-
-**default**: `false`
-
-#### rule
-
-The `rule` key contains various nested keys. The `paths` key identifies directories that hold the YARA rule definitions. It is also possible to link each directory to YARA namespace. The `strings` key allows for defining inline YARA rules. Example:
-
-```
-rule:
- paths:
- - path: C:\\yara-rules
- namespace: default
- - path: C:\\pdf-rules
- namespace: pdf
-
- strings:
- - string: rule test : tag1 { meta: author = \"Hilko Bengen\" strings: $a = \"abc\" fullword condition: $a }
- namespace: notepad
-```
-
-#### alert-template:
-
-Specifies templates for the alert text in Go [templating](https://golang.org/pkg/text/template) language.
-
-
-#### fastscan
-
-Determines when multiple matches of the same string can be avoided when not necessary.
-
-**default**: `true`
-
-#### scan-timeout
-
-Specifies the timeout for the scanner. If the timeout is reached, the scan operation is cancelled.
-
-**default**: `20s`
-
-#### skip-files
-
-Indicates whether file scanning is enabled. This affects the scan triggered by the image loading, create file, and file mapping operations.
-
-**default**: `false`
-
-#### skip-allocs
-
-Indicates whether scanning on suspicious memory allocations is disabled.
-
-**default**: `false`
-
-#### skip-mmaps
-
-Indicates whether scanning on suspicious mappings of sections is disabled.
-
-**default**: `false`
-
-
-#### skip-registry
-
-Indicates whether registry value scanning is disabled.
-
-**default**: `false`
-
-
-#### excluded-files
-
-Contains the list of the comma-separated file paths that shouldn't be scanned. Wildcard matching is possible. For example:
-
-```
-excluded-files:
- - ?:\\Windows\\System32\\kernel32.dll
-```
-
-#### excluded-procs
-
-Contains the list of the comma-separated process image paths that shouldn't be scanned. Wildcard matching is possible.
diff --git a/logo.png b/logo.png
deleted file mode 100644
index 715f8fa05..000000000
Binary files a/logo.png and /dev/null differ
diff --git a/logo.svg b/logo.svg
new file mode 100644
index 000000000..d2936f265
--- /dev/null
+++ b/logo.svg
@@ -0,0 +1 @@
+
\ No newline at end of file
diff --git a/rules/README.md b/rules/README.md
index f735475b4..ca73990d2 100644
--- a/rules/README.md
+++ b/rules/README.md
@@ -6,7 +6,7 @@
-This directory contains a catalog of detection rules modeled around the prominent [MITRE ATT&CK](https://attack.mitre.org/) framework. The goal is to provide a direct mapping of tactics, techniques, and sub-techniques for each rule. The following sections introduce the general structure, design guidelines, and best practices to keep in mind when creating new rules.
+This directory contains a catalog of detection rules mapped to [MITRE ATT&CK](https://attack.mitre.org/) framework. The goal is to provide a direct mapping of tactics, techniques, and sub-techniques for each rule. The following sections introduce the general structure, design guidelines, and best practices to keep in mind when creating new rules.
## Structure
@@ -28,7 +28,7 @@ required attributes such as rule identifier, name, and the minimum engine versio
### Read the docs
-This should be your starting point. Before trying to write new rules, explore the [docs](https://www.fibratus.io/#/filters/introduction) to learn about [filter expressions](https://www.fibratus.io/#/filters/filtering) fundamentals, [operators](https://www.fibratus.io/#/filters/operators), [functions](https://www.fibratus.io/#/filters/functions), [filter fields](https://www.fibratus.io/#/filters/fields) reference, and [rule engine](https://www.fibratus.io/#/filters/rules) specifics.
+This should be your starting point. Before trying to write new rules, explore the [docs](https://www.fibratus.io/docs/rules) to learn about [operators](https://www.fibratus.io/docs/rules/operators), [functions](https://www.fibratus.io/docs/rules/functions), [filter fields](https://www.fibratus.io/docs//rules/fields) reference.
### Stick to naming nomenclature
@@ -55,4 +55,4 @@ Fibratus comes with a [macros](https://www.fibratus.io/#/filters/rules?id=macros
### Formatting styles
-Pay attention to rule condition/action formatting style. If the rule consists of multiple or large expressions, it is desirable to split each spanning expression on a new line and properly indent the `and`, `or`, or `not` operators. By default, we use 1 space tab for indenting operators and rule actions. This notably improves readability and prevents formatting inconsistencies.
+Pay attention to rule condition/action formatting style. If the rule consists of multiple or large expressions, it is desirable to split each spanning expression on a new line. This notably improves readability and prevents formatting inconsistencies.
+
+ 
+
+
-
-
-
-
-
-