Client Recorder Extension overview

The Client Recorder Extension is a feature common to the 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.

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, such as an HTTP request to an internet location, 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. All outgoing connections do not 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, CX 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

[Windows and Linux only] Security events such as authentication, privilege escalation, and more. This event type includes logon events.

DNS

[Windows 8.1 or later] Request information, including the process path, user, query, response, and the type of operation.

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.

Table 1:   Client Recorder Extension features - Windows
Feature Windows Server 2008 R2 Windows Server 2012 Windows Server 2012 R2 or later Windows 7 Windows 8 Windows 8.1 or later
DNS events Not Available Not Available Available Not Available Not Available Available
Process hashes and command-line information Requires Tanium driver Tanium driver recommended Tanium driver recommended Requires Tanium driver Tanium driver recommended Tanium driver recommended
Driver loads Available Available Available Available Available Available

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 cx-status sensor to check the event source for a Linux endpoint.

 

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. If you require RAW logs for some particular rules because of compliance reasons, consult your TAM.

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 multicast mode, then unicast 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 has the least performance impact on the endpoint. Auditd is installed and not running. Recorder uses the auditd libraries, but does not require auditd to be running.

For maximum performance netlink is highly recommended. If netlink connects successfully, the audispd plugin and TaniumAuditPipe are removed. On new kernels Recorder installations should automatically use netlink on their first boot.

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/.

The recording of DNS events is not available on Linux.

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

The recording of security and DNS events is not available on Mac.

Last updated: 10/26/2020 1:20 PM | Feedback