What the sensor collects

Two different people need this article and they need it for opposite reasons. The first is answering a privacy question — from a works council, a data protection officer, or an employee who noticed a new service on their laptop — and needs to know exactly what leaves the machine. The second is trying to work out why a particular attack technique never produces an alert, and needs to know what the sensor cannot see. Both questions have the same answer, so both are here.

The short version: the sensor reports which processes started and stopped, and which files were created, changed or deleted in a few named directory trees. It does not report network connections, it does not read file contents into the platform, and it does not record what anyone types or looks at.

The shape of an event

Telemetry is organised into four channels — process, file, network and auth — of which the network channel currently carries nothing, for reasons covered below. These are the event type names the sensor emits, and they are the words you will see in a hunt query or on an incident timeline:

process_exec
process_exit
file_create
file_modify
file_delete
file_rename
heartbeat
auditd_record
log_stream

file_rename is declared but never emitted. A rename arrives as a delete of the old path plus a create of the new one, and the detection engine reassembles the pair by matching file size within a burst. If you write a hunt looking for file_rename, it will return nothing — that is the reason.

A process_exec event always carries the platform, process id, parent process id, a process identifier, the process name and the hostname. It carries these only where the platform could supply them: the executable path, the full command line, the owning user, the session id, the start time, and the same set again for the parent.

Each process gets an identifier derived from the hostname, the process id and the exact start time. A bare process id is not an identity — process ids are recycled within minutes on a busy machine — so this is what lets the platform join a child to its parent and draw a process tree without confusing two machines' processes.

File events carry the path, the extension, the size and an entropy score — a measure of how random the bytes look, which is high for encrypted or compressed data. On a modification the event also carries the previous size, the previous entropy and the change between them. A folder full of documents whose entropy jumps to near-random in ninety seconds is what ransomware looks like from here.

Windows

Process data comes from the live process table through Win32 calls: a snapshot of every process, its parent, its image path, its creation time, its terminal-services session and its owning account, plus the command line read out of the process's own memory.

• No ETW. There is no Event Tracing for Windows consumer in the sensor. A real one against the kernel process and file providers remains the right long-term source and is not implemented.
• No Sysmon. The sensor neither requires nor reads Sysmon.
• No tasklist. An earlier version shelled out to it and reported almost nothing useful; that was removed.
• Command lines from protected processes are unavailable. Reading another process's command line needs at least equal privilege and the same architecture. The System process, csrss and antivirus services refuse the read. The event is still emitted with the identifier, parent and name so the tree stays connected.

File watching covers %PUBLIC% and each user's Documents, Desktop, Downloads and Pictures folders, falling back to C:\Users. It deliberately does not walk C:\. Scanning the system volume every few seconds would cost more than it detects and would drown the burst signal in Windows Update churn.

Linux

Three collectors run at once. The process-table differ reading /proc is the source of record: it always works, it carries the parent link and the command line, and it needs nothing installed. The file watcher covers /home, /srv and /var/www by default. The third is a tail of the audit log, /var/log/audit/audit.log, which is the only source of syscall-level context.

From an audit record the sensor keeps a fixed field list and nothing else: pid, ppid, uid, euid, auid, gid, comm, exe, name, type, syscall, success. Execution records become process_exec; everything else becomes auditd_record. Where auditd is not present — a container, most non-RHEL defaults — that collector falls back to a 30-second heartbeat and the other two keep working.

There is no eBPF collector in the packages you download. The build tag exists, the compiled program lives outside the distribution build, and it is excluded from released artefacts.

macOS

For completeness, and with the caveat that there is no installable macOS package today. The macOS collectors read the process table by running ps on an interval, watch Documents, Desktop and Downloads under each home directory, and stream the security subsystem's unified-log lines as log_stream events on the auth channel.

Apple's Endpoint Security framework is not used. It is the correct long-term source and would give real-time execution events with parent context, but it needs an Apple-granted entitlement the agent does not hold. macOS 11 and later also require Full Disk Access before the file and process channels see much of anything.

What is not collected

• No network connections. No source or destination addresses, no ports, no DNS lookups, no domains, no URLs, no TLS metadata. The network channel name exists in the code; nothing is emitted on it.
• No Windows registry activity. A registry_set event type appears in the hunt query schema, but no sensor emits it, so a hunt for it returns nothing.
• No file contents. Entropy is calculated on the machine from the first 64 KiB of a file; the number leaves, the bytes do not.
• No keystrokes, no screen capture, no clipboard, no webcam, no microphone. None of these exist anywhere in the sensor.
• No browser history, no email content, no document content, no messaging content.
• No screenshots or recordings of user sessions. Session recording exists elsewhere in Qorionix, for privileged sessions an administrator deliberately opens through the platform. The endpoint sensor is no part of that.

The personal data that is in there

Being precise about this is more useful than reassurance. The telemetry does contain data about identifiable people:

• Account names. The user a process runs as, and on Linux the numeric user ids from audit records. On Windows an account whose identifier cannot be resolved to a name is reported as the raw identifier rather than dropped.
• Hostnames, which in most organisations name a person or a desk.
• File paths inside home directories, including file names — the path, extension and size of a document, though never its contents. A file called resignation-letter-draft.docx in someone's Documents folder produces an event containing that name.
• Full command lines. This is the one to think hardest about. Command lines are captured verbatim, and anything typed on a command line — including a password or an API key passed as an argument — is captured with it. That is also precisely why command lines are collected: attack techniques live there. If your teams pass secrets as command-line arguments, this is a good moment to stop, independently of us.

Paths are recorded exactly as they appear on the machine, without rewriting, so the evidence in an investigation matches what an engineer would see if they walked over to the desk. You can change which directory trees are watched by setting ZQ_WATCH_PATHS on the service.

Intervals and bounds

The first snapshot and first file scan after a restart are baseline-only, because reporting every already-running process as just executed on each start is exactly the alert fatigue that makes small organisations abandon an endpoint product. If the upload queue is full, events are dropped rather than stalling collection — a stalled collector makes the next comparison span a long gap and loses far more.

What this bounds — the honest part

What we cannot see decides what can never be detected, whatever the rule set says. Four consequences, stated plainly:

Threat-intelligence matching is file-hash only

Because there are no network events, there is nothing for a malicious domain, IP address or URL indicator to match against. Those indicators are still collected from your feeds and are still useful when you look something up by hand, but nothing in the product automatically compares them against endpoint activity. File-hash matching does happen automatically — on the completion of a live-response file fetch.

Command-and-control over ordinary web traffic is a published gap

The technique of hiding instructions in normal-looking HTTPS traffic is one we list as uncovered, with the missing network telemetry named as the blocker. We publish that rather than let the coverage map imply otherwise.

A process that lives less than two seconds may be missed

The sensor samples; it is not a kernel callback. That trade buys an agent with no driver and no dependency on your operating system's internals, which is why it installs across a mixed fleet without a project. It is still a real gap and we state it as one.

File events are not attributed to a process

The sensor sees that a burst of files changed, not which process changed them. Attribution of a ransomware burst to a specific process comes from correlating the process tree around it, not from the file events themselves.

What to do next

1. The endpoint list and endpoint health — how to tell a machine is still sending any of this.
2. Installing the sensor on Windows and on Linux — the two platforms you can deploy today.
3. What Qorionix does, and what it does not — the same honesty applied to the whole platform.