Client Recorder Extension overview

The Client Recorder Extension is a feature common to the Tanium Enforce, Tanium Integrity Monitor, Tanium Map, and Tanium Threat Response solution modules. It continuously saves event data on each endpoint. The Client Recorder Extension monitors the endpoint kernel and other low-level subsystems to capture a variety of events.

Traditional disk and memory forensics techniques can successfully reconstruct fragments of endpoint activity, but are limited to the evidence that is natively preserved by the underlying operating system. This type of evidence from a period of interest can rapidly degrade as time elapses. In contrast, the Client Recorder Extension maintains a complete, easy-to-interpret history of events so you can replay recent system events.

Even an idle system quickly accumulates data. The Client Recorder Extension returns event information based on a subscription that a module provides. Subscriptions can save event information in a number of ways, for example in JSON format or in a database. Modules can retain up to several months of historical data. You can customize the amount of local storage that is consumed by the Client Recorder Extension, and create subscriptions to capture specific types of recorded evidence.

Types of recorded events

The Client Recorder Extension captures a broad range of events, that include additional context and metadata. Recorded event examples include:

• process execution
• file system activity
• file read events
• registry changes
• network connections
• driver and library loads
• user authentication
• http headers

• operating system state changes (login/logout)

You can specify which process, registry, network, file, and security events to record, depending on whether or not they apply to the operating systems of the endpoints. The Client Recorder Extension does not collect any information regarding the output redirection. As the Client Recorder Extension works at the process level, the Client Recorder Extension does not include shell builtins, such as '|', "<", ">", or ">>" as part of the process for a command line and treats commands separated by these into multiple processes and handles each of the processes individually.

For example, the command ps aux | grep root is interpreted as two commands:

ps aux

and

grep root

Similarly, the command svnadmin dump c:\path\to\myrepo | 7z a -si svndump.7z is interpreted as two commands:

svnadmin dump c:\path\to\myrepo

and

7z a -si svndump.7z

Each of these processes share the same parent process.

For more meaningful data and to retain data for longer periods, consider excluding events that occur frequently; for example, LanguageList registry values are a verbose event on Windows endpoints.

Image load and Registry

[Windows only] Changes to the registry, such as the creation, renaming, or alteration of registry keys and values. Includes the associated process and user context. Image Loads record the process GUID and ensuring a correct PID match.

Network

Network connection events, including the associated process and user context. Events are recorded for all inbound and outbound TCP connections. The Client Recorder Extension tracks the bind system call for network events. For Linux endpoints that use auditd as an event source, all outgoing connections do not display local address and port information. For Linux endpoints that use eBPF as an event source, outgoing connections display local address and port information.

File

File system events, such as files written to directory locations on the endpoint. The associated process and user context are included. When a process is executed, the original login user - if it exists - is recorded. For example if a user creates an SSH connection to an endpoint, and then becomes some other user, the user name is the user the process executed as but the login user is the original user who logged in. This can be useful for filtering events for a certain user or user id.

Examples of file system events include a malware file copied to a location that Windows Update uses, or content changes made to a file. The Client Recorder Extension nomalizes file paths to provide support for symlinks.

File read events are useful for determining if someone other than a certain user has tried to read a file. Custom auditd rules are required to enable read events. File open read will behave similarly to File Open Write. To support file read auditing, users with administrative permissions can upload a new segment of auditd rules through the Client Recorder Extension for Linux. Custom audit rules allow the administrator to manage their own rules into auditd using the following commands:

• recorder.register-user-defined-audit-rules
• recorder.get-user-defined-audit-rules
• recorder.remove-user-defined-audit-rules

On successful addition of user defined rules, Client Extensions - Status reports:

{

"domain": "recorder",

"name": "has_user_defined_audit_rules",

"value": "true"

}

On failure to refresh rules with custom rules, the custom rules are removed. Only rules starting with -a or -A are accepted. Rules with dir= or path= check the dir/path if it exists on the local system before they are added. If custom audit rules produce an error when loading rules, the custom rules are removed and a health check presented.

You can view file read events in the recorder database, through integrations to Stream, in Detect signals, and in journal subscriptions.

Security

Security events such as authentication, privilege escalation, and more. This event type includes logon events.

DNS

[Windows 8.1 or later and Linux endpoints that use eBPF as an event source] Request information, including the process path, user, query, response, and the type of operation. On Windows and Linux endpoints where eBPF is enabled, DNS events are only recorded when you use the system DNS client. DNS events for applications that use their own DNS client are not recorded. For example, nslookup and Google Chrome.

HTTP Headers

[Windows only] Returns HTTP header information from connections on endpoints including the time connections occurred, the connection ID of the connection, the remote (destination) address, and the header name and value.

SYSTEM EVENTS

System level events capture when a user logs in or off.

System events provide common client extension infrastructure to other Tanium modules to notify them when a user logs in or off. This has the effect of the recorder pipeline being ‘on’ by default on Windows endpoints (connecting to ETW). System events are not stored in a database without a Threat Response recorder configuration.

Sources of Client Recorder Extension data on Windows

The Client Recorder Extension gathers data from multiple sources into a database and/or journal feeds. Kernel events are gathered from Windows tools. On Windows endpoints, the Tanium Driver is recommended to provide additional information about the executed processes.

Some features of the Client Recorder Extension require specific versions of Windows.

Sources of Client Recorder Extension data on Linux

The Client Recorder Extension for Linux uses netlink and the Linux audit subsystem to collect events. Auditd needs to be installed but is not required to be running for netlink unicast or multicast mode.  Use the Client Extensions - Status sensor to check the event source for a Linux endpoint.

Extended Berkeley Packet Filter (eBPF)

eBPF is an open source kernel module framework that generates instrumentation in the kernel. It provides stable performance and has not been attributed to crashes. Fundamental to the architecture of this framework is the inability to loop and consequently it cannot cause endpoints to become unresponsive. This kernel module creates a new data source for Linux events.

eBPF provides an event source for process, file, and network events and serves as a replacement for auditd. Security events continue to come from auditd - however no rules need to be added to auditd. Security events that continue to come from auditd include:

• Anomalous Failure Messages

• Anomalous System or File Access

• Credential Acquired

• Credential Disposed

• Credential Refreshed

• Group Account Changes

• Group Added

• Group Deleted

• Group ID Changed

• Group Password Auth

• Labeled Security Protection Profile Events

• SE Linux User Error

• System Changes

• User Account Lock Changes

• User Account Modified

• User Added

• User Auth Token Modified

• User Authenticated

• User DAC Check

• User Deleted

• User Login

• User Logout

• User Management Data

• User Session Ended

• User Session Started

• User Space Hotplug Device

• User Space Messages

By default, eBPF is enabled on supported operating systems. To disable eBPF use the CX.recorder.BPFEnableBPF configuration setting. On endpoints with RHEL and CentOS versions 7.8 to 8.2 and OEL versions 8.3+, a BCC library is added to the endpoint. The Recorder eBPF program is compiled on the endpoint when eBPF is enabled. This program is recompiled every time the endpoint is restarted.

Kernel Driver (kaudit)

The kaudit process is a part of the Linux kernel responsible for the kernel audit events and forwards audited events to the uauditd process. Audited events are defined by a rules file. This rules file is called audit.rules and is located at /etc/audit/audit.rules. Additional rules files that can be read into the kauditd process and added to the audit.rules file are located in /etc/audit/rules.d/.

Client Recorder Extension by default does not load the Tanium rules if raw logging is enabled. If you are upgrading from Client Recorder Extension 2.1 and have Raw Logging enabled, the 2.2 upgrade removes the Tanium rules.

Netlink

Netlink is a mechanism provided by the Linux kernel to communicate between userspace and kernel space. Netlink enables the Linux Recorder to record event data directly to the Linux Kernel bypassing the auditd and audispd processes. The netlink socket can operate in unicast mode on all kernels, or in multicast mode on kernel versions 3.16 and later. When the Linux Recorder starts, it attempts to connect to the netlink socket in unicast mode, then multicast mode. If it is unable to connect with netlink it will fall back to the audispd plugin and TaniumAuditPipe. Subscribing to netlink in multicast or unicast mode performs more efficiently on the endpoint than the audispd plugin and TaniumAuditPipe. Auditd is installed and not running. Recorder uses the auditd libraries, but does not require auditd to be running.

There are two client configuration options for configuring netlink. If either of these options are toggled, the recorder functions in an ‘only connect via netlink’ configuration.

CX.recorder.AuditdEnableAudispdFallback

Allow getting events from audispd/TaniumAuditPipe. Run the Recorder - Set Recorder Extension Setting [Linux] package to enable this setting.

Default value: 1

CX.recorder.AuditdStopAuditdService

Stops the auditd service. For example, stops the auditd service so recorder can use the unicast or multicast netlink socket. Run the Recorder - Set Recorder Extension Setting [Linux] package to enable this setting. 

Default value: 0

Audit Daemon (auditd)

This process communicates to the to the kernel via the netlink socket. For most Linux versions this is limited to a single listener. This process writes to audit log files or forwards events to the audispd process for dispatching.

The Client Recorder Extension for Linux requires an application that is started by auditd. In the Client Recorder Extension for Linux, the Tanium Auditpipe is the application that auditd starts. When a Client Recorder Extension configuration is provided, auditd is restarted, and in turn starts the Tanium Auditpipe. When a configuration is removed, auditd also restarts. For this reason you can see auditd starting and stopping when Client Recorder Extension configurations are added or removed.

The log_format parameter in auditd.conf has been deprecated in versions of auditd 2.5.2 and later. The log_format parameter has two settings:

RAW
NOLOG

If the auditd.conf contains log_format = NOLOG on these versions of auditd, the audispd process does not start. To disable RAW logging on these versions, change the following parameters in auditd.conf:

write_logs = NO
log_format = RAW

When the Client Recorder Extension starts on an endpoint that has auditd version 2.5.2 or later, it changes log_format = NOLOG to log_format = RAW. If the write_log parameter is detected in auditd.conf, the value of the log_format parameter is not changed. If the write_log parameter is not detected, it is added to auditd.conf corresponding to RAW or NOLOG.

For example:

If log_format = NOLOG and write_logs is not set, the Client Recorder Extension sets log_format = RAW and write_logs = NO
If log_format = NOLOG and write_logs = YES, the Client Recorder Extension sets log_format = RAW and does not make changes to the value of the write_logs parameter.

When the Client Recorder Extension starts on an endpoint that has a version of auditd earlier than 2.5.2, the write_logs parameter is removed.

Audit Dispatcher (audispd)

This process is an event multiplexor that helps overcome limitations of single listener socket. This process consumes audit events from the auditd process and dispatches them to child plugins that want to analyze events in real-time. The Client Recorder Extension is an example of one of these child plugins. The configuration for these child plugins is found under /etc/audisp/plugins.d/.

Sources of Client Recorder Extension data on Mac

On Mac endpoints, the Client Recorder Extension collects data from:

• The OpenBSM auditing system that is installed in all Mac releases from 10.8 to current.
• FSevents, which enables applications to register for notifications of changes to a directory tree.
• Kextd, which provides information about kernel extensions.

The Client Recorder Extension connects to a clone of /dev/auditpipe to record events. When the recorder is installed on a Mac endpoint, /etc/security/audit_class is updated with a Tanium Recorder entry to map subscribed events at runtime. The Client Recorder Extension then clones /dev/auditpipe and configures the copy to use the tan audit class. When the Client Recorder Extension configuration is read, the types of wanted events are translated to the appropriate system calls to monitor, and those calls are then mapped to the tan audit class. This prevents the Client Recorder Extension from writing the audited events to the audit.log of the endpoint and allows the Client Recorder Extension to be very selective about which system calls are monitored.

Process Events

Command Lines of Process

Process Hashes

Network Events

File Events