The endpoint telemetry page: inventory, DNS, logons, USB, scripts and FIM
One host, seven tabs. What each of the sensor 1.7.0 telemetry channels actually reports on Windows, Linux and macOS, and where each one reports nothing at all.
Sensor 1.7.0 added five new telemetry channels on top of what earlier sensors already reported: package inventory, DNS queries, logon activity, removable-storage (USB) connections, and PowerShell script-block text. Read together with the file-integrity change feed and the vulnerability findings that already existed, that is seven distinct things worth reading about one host, and the endpoint telemetry page is where they live: pick a host, then read across seven tabs. This article is a reference for each tab, written at the same level of honesty the product itself uses — most of these channels report genuinely different things on Windows than they do on Linux or macOS, sometimes nothing at all, and the gaps are as much a part of using this page correctly as the fields that are populated.
Getting to the page
The page lives under Endpoints and response -> Telemetry in the sidebar, at /xdr/telemetry. A host picker at the top of the page — a plain dropdown listing every enrolled sensor by hostname and platform — drives all seven tabs beneath it; switching the dropdown reloads every tab for the newly selected host.
You can also reach it already pointed at a specific machine: the endpoint detail drawer on the ordinary endpoint list has a View telemetry button that links straight here with that host pre-selected. The link validates the host against your tenant's own sensor list before selecting it, so a stale or copied link can never silently select somebody else's endpoint or a machine that has since been removed — it falls back to the picker's own default (the first sensor) instead. A later manual switch in the dropdown, or a plain page refresh, is never silently reverted back to the link's original target.
Inventory and Vulnerabilities: established behaviour, briefly
These two tabs are not new to this wave — they reuse the package-inventory and vulnerability-matching surface that already existed, shown here per host rather than only in the tenant-wide exposure views. Inventory lists every package the sensor's inventory channel reported for this host: name, version, ecosystem and source. Vulnerabilities lists this host's open findings from the OSV and CISA KEV matching pass, filtered to the packages this specific host reported. Full detail on how the matching works, what an ecosystem string does and does not cover, and what the tenant-wide posture score means is in Exposure: vulnerabilities and posture — this page is the per-host window onto the same data, not a separate feature.
DNS: different fields on different platforms, and a Linux gap that needs your action
The DNS tab lists queried domain names with a record type, a results field, and when the query happened. Which of those two middle fields is populated depends entirely on the platform, and this is a case where the honest answer is that each field is simply empty on the platform that does not report it — not a bug, not a future fix, a real difference in what each operating system's own DNS subsystem exposes.
| Platform | Source | Populates | Does not populate |
|---|---|---|---|
| Windows | ETW, Microsoft-Windows-DNS-Client event 3008 (query completed) | query_results — the raw, semicolon-separated answer records | query_type is left empty |
| Linux | systemd-resolved's own log, read via journalctl | query_type — the DNS record type queried | query_results is left empty |
| macOS | Not attempted | Nothing — the tab is empty on this platform | No DNS channel exists on macOS at all this wave |
macOS has no DNS collector at all — this was not attempted in this wave, and unlike the Linux case there is no equivalent single log-level toggle that would make it cheap to add later. If you are relying on DNS visibility as part of your detection story, treat it as a Windows-and-suitably-configured-Linux capability today, not a fleet-wide one.
Logons: rich on Windows, thin everywhere else
The Logons tab is the clearest illustration on this page of how differently three operating systems expose the same concept. Windows treats a logon, a logoff and a failed logon as three distinct, well-documented event types, each with a real set of fields. Linux and macOS both collapse the same idea into one undifferentiated event type with much less to say about it.
| Platform | Source | Event types | Fields you actually get |
|---|---|---|---|
| Windows | Security event log 4624 (success) / 4634 (logoff) / 4625 (failure) | logon_success, logoff, logon_failure — genuinely distinguishable | User, source IP, workstation, logon type, and a status field |
| Linux | auditd — USER_LOGIN, USER_START, CRED_ACQ | One undifferentiated logon event type | No username field is collected at all — the user_name column falls back to the numeric uid, which is the best identity available from this source |
| macOS | Unified log, loginwindow subsystem | One undifferentiated logon event type | No fixed schema — whatever Apple's own logging happens to emit that day, preserved in the raw payload rather than mapped to named columns |
USB: three platforms, three field names, one normalised pair
The USB tab reports removable-storage connect and disconnect events with a device string, a vendor and a model. Behind that one vendor/model pair, each platform is reading a genuinely different underlying source, with a different natural precision:
- Windows reads the
USBSTORregistry key — a history of mass-storage devices that have ever been attached, not a live device list. A friendly-name string is what stands in for vendor and model here, not a literal serial number or device class field. Disconnected, on Windows, means the device is no longer in the registry snapshot the sensor last read — not a precise unplug timestamp. A device removed between polls is seen as gone at the next poll, whenever that happens to fall. - Linux reads
/sys/block/*/removable, with vendor and model taken from the device's owndevice/vendoranddevice/modelsysfs files when present. - macOS reads
system_profiler SPUSBDataTypeand reports the device's vendor and product identifiers.
All three are normalised into the same vendor/model pair shown in the table so the tab reads consistently across a mixed fleet, but the underlying precision is only as good as whichever platform reported the row. Do not read a blank or generic-looking vendor string as a sensor defect — it is frequently the honest limit of what that platform's own USB subsystem exposes.
Scripts: Windows-only, and not reassembled
The Scripts tab shows PowerShell script-block text captured from Windows event 4104 (Microsoft-Windows-PowerShell/Operational) — the same event most mainstream EDR products build their PowerShell visibility on. This channel is Windows-only this wave; there is no equivalent on Linux or macOS.
The Flagged column shows whether a script block matched the suspicious-PowerShell detection described in Behavioural detections and attack coverage — a fixed list of static indicators, not a general-purpose script analyser. A script block with no match is not a certified-safe verdict; it is simply one that did not trip the specific indicators the rule looks for.
FIM: the change feed, now with an actor on two platforms
The FIM tab is the same change feed described in full in File integrity monitoring — every add, modify and delete the sensor's watcher reported for this host, with a change kind and a timestamp. What is new this wave is the Actor (user / process) column: when who-data attribution succeeded, it names the user and process responsible for the change. When it did not — or could not — the column reads Not attributed rather than showing a blank cell, so you can tell the difference between "nobody could be attributed" and a column that simply has nothing to say.
| Platform | What is needed | What the sensor does itself |
|---|---|---|
| Windows | Object-access auditing (a SACL) already configured on the watched path | Listens for Security event 4663 once any FIM spec on the host requests who-data. Does not enable the underlying auditing itself — that is a real, invasive Security-log volume change, and it is left to an operator or policy to turn on. Without it, the actor fields stay empty exactly as before this wave. |
| Linux | auditctl present on the host | Installs a watch (auditctl -w <path> -p wa -k qorionix_fim) for each who-data-requesting FIM root itself — this one step it does take automatically, best-effort, and it is a no-op if auditctl is not available. |
| macOS | An Apple Endpoint Security entitlement | Not implemented. macOS FIM never shows an actor, regardless of the who-data setting on the watch — this product has no distribution story for that entitlement yet. |
So a Windows host with no auditing configured and a macOS host will both show Not attributed on every row, for two entirely different reasons — one is a configuration gap you can close yourself, the other is a platform capability the product does not have yet. If actor attribution matters to you on a specific host, check which situation you are in before assuming a policy change will fix it.
Known wrinkles worth knowing about
- Every channel is gated by policy. DNS, logon, USB and script collection are each independently controlled by the host's collection settings. A tab reading empty may mean nothing happened, or it may mean the channel is switched off for that host's policy — the empty-state hints on each tab say which telemetry channel needs enabling, but they cannot tell you whether it is off or simply quiet.
- Package inventory reports once at sensor start, then only on a real change (or once every 24 hours regardless, whichever comes first) — so a newly enrolled host may take a short while to show its first inventory snapshot, and the Inventory tab is not a live, continuously refreshed view of installed software.
What to read next
- What the sensor collects — the full picture of every channel the sensor reports, telemetry breadth included.
- Behavioural detections and attack coverage — the three detections built on this wave's new channels, and their own platform caveats.
- File integrity monitoring — the FIM policy kind, watch-path configuration, and the rest of the watcher's limitations.
- Exposure: vulnerabilities and posture — the tenant-wide view behind the Inventory and Vulnerabilities tabs.
- Sensor 1.7.0: install and verification, platform by platform — installing the sensor version that ships these channels.