Troubleshooting

If Threat Response is not performing as expected, you might need to troubleshoot issues or change settings. For more information, see Contact Tanium Support.

General troubleshooting

Managing the Threat Response workbench

Endpoint troubleshooting

Threat Response component troubleshooting

Collect logs

Collect troubleshooting information from the Threat Response service

Use Threat Response to compile a collection of logs relevant for troubleshooting. You can collect logs and other artifacts from the Threat Response service located on the server to help troubleshoot service side issues.

  1. From the Threat Response overview page, click Help , then click the Troubleshooting tab.
  2. Click Create Package. Normally creating the troubleshooting package takes a few minutes, but can take longer for large packages.
  3. When the status of the package creation is complete, click Download Package.

The log zip file might take a few moments to appear in the download folder.

Collect troubleshooting information from endpoints

You can collect logs and other artifacts from individual endpoints to help resolve issues. Collecting logs from endpoints requires a live connection to the endpoint from which you want to gather troubleshooting information.

  1. From the Main menu, click Administration > Client Management to open the Client Management Overview page.
  2. From the Client Management menu, click Client Health.
  3. In the Direct Connect section, create a live connection to the endpoint from which you want to collect troubleshooting information. For information on creating a live connection, see Connecting to live endpoints.
  4. Click the Gather tab. In the domain section select Threat Response.
  5. Click Gather from Endpoint.
  6. A package is gathered from the endpoint. The name of the link is the time stamp of the troubleshooting package. Select the Must Gather that you want to download and click Download to download a ZIP file that contains troubleshooting information.

For more information about using client health features in Client Management, see Tanium Client Management User Guide: Monitor the client health overview in Client Management and Tanium Client Management User Guide: Access detailed client health and troubleshooting information on an endpoint.

View notifications

From the Threat Response menu, click Management > System Notifications.These notifications show various Threat Response service related events and notifications. You can expand these notifications to view additional information.

  • Alert Pruning: Notifies when alerts have been pruned from the Threat Response alerts database

  • Automatic Intel Deployment Error: Threat Response has failed to deploy the Intel database
  • Intel Deployment Excluded Intel: Possible corrupted Intel database
  • Endpoint Throttle: Alerts were throttled at the endpoint level for an Intel document
  • Service Throttle Start: Alerts were throttled at the service level for an Intel document
  • Service Throttle Update: Alerts were throttled again after the original throttle start at the service level for an Intel document
  • Tanium Signal Stream Update: Threat Response updated to a new version of Tanium Signals

To delete a notification, select the row and click Delete.

View task status

You can view the status of and review other historic data for Threat Response tasks.

From the Threat Response menu, click Management > Tasks.

When troubleshooting, it is useful to identify tasks which have not been completed successfully. You can filter by task status:

  • Error
  • Incomplete
  • Not Started
  • Started

Some examples of Threat Response tasks include (but are not limited to):

  • Deploy Profile
  • Deploy Intel
  • Deploy Tools
  • Generate Live Response packages
  • Response Action
  • Start Index
  • Suppress Alerts

In the event of an error, you can locate a specific task and expand the cell to view results and metadata from log files. The data that appears in the advanced details view provides information that is useful for troubleshooting and saves the time of trying to locate debugging information in lengthy log files or in formats that are not intended to be human readable.

Remove Threat Response tools from endpoints

You can deploy an action to remove Threat Response tools from an endpoint or computer group. Separate actions are available for Windows and non-Windows endpoints.

  1. In Interact, target the endpoints from which you want to remove the tools. For example, ask a question that targets a specific operating system:
    Get Endpoint Configuration - Tools Status from all machines with Is Windows equals true
  2. In the results, select the row for Threat Response, drill down as necessary, and select the targets from which you want to remove Threat Response tools. For more information, see Tanium Interact User Guide: Drill Down.
  3. Click Deploy Action.
  4. For the Deployment Package, select Endpoint Configuration - Uninstall Tool [Windows] or Endpoint Configuration - Uninstall Tool [Non-Windows], depending on the endpoints you are targeting.

  5. For Tool Name, select Threat Response.

  6. (Optional) By default, after the tools are removed they cannot be reinstalled. To allow tools to be automatically reinstalled, clear the selection for Block reinstallation. Re-installation occurs almost immediately.

    If reinstallation is blocked, you must unblock it manually:

    • To allow Threat Response to reinstall tools, deploy the Endpoint Configuration - Unblock Tool [Windows] or Endpoint Configuration - Unblock Tool [Non-Windows] package (depending on the targeted endpoints).

    • If you reinstall tools manually, select Unblock Tool when you deploy the Endpoint Configuration - Reinstall Tool [Windows] or Endpoint Configuration - Reinstall Tool [Non-Windows] package.

  7. (Optional) To remove all Threat Response databases and logs from the endpoints, clear the selection for Soft uninstall.

    When you perform a hard uninstallation of some tools, the uninstallation also removes data that is associated with the tool from the endpoint. This data might include important historical or environmental data. If data that you want to keep is associated with the tool, make sure you perform only a soft uninstallation of the tool.

  8. (Optional) To also remove any tools that were dependencies of the Threat Response tools that are not dependencies for tools from other solutions, select Remove unreferenced dependencies.

  9. (Optional) In the Deployment Schedule section, configure a schedule for the action.

    If some target endpoints might be offline when you initially deploy the action, select Recurring Deployment and set a reissue interval.

  10. Click Show preview to continue.

  11. A results grid appears at the bottom of the page showing you the targeted endpoints for your action. If you are satisfied with the results, click Deploy Action.

If you have enabled Endpoint Configuration approval, tool removal must be approved in Endpoint Configuration before tools are removed from endpoints.

Change the Module Server address

When Threat Response is installed, the installation process fills in the Module Server IP address that the endpoints use to connect. If this address changes, you might need to update the Service Settings.

  1. From the Threat Response overview page, click Settings , then click the Service tab. Click Misc.
  2. Enter the IP address of the Module Server.
  3. Click Save.

My device has no profile or the wrong profile

The profile deployment process is the process of generating, saving, and deploying a profile from the server to the endpoint. If an endpoint, or client, does not have a profile or the incorrect profile, then the profile deployment action could have failed on the server.

Common reasons for failure include the following:

  • The profile was not sent deployed.

    • From the Threat Response menu, click Management > Profiles and make sure a profile has successfully deployed. A profile has successfully deployed if it has a green check under the status column.

    • Verify the last deployment time.

    • Verify the Profile Targeting (Computer Groups).

    • Verify the Profile Priority.

    • Verify the Profile ID on the Profiles page and compare to the output of Client Extensions - Status.

    • Verify the Profile Revision on the Profiles page and compare to the output of Client Extensions - Status.

    • From the Threat Response > Tasks page, verify that the profile was deployed successfully.

  • The profile was deployed, but it did not reach the client.

    • Verify in Endpoint Configuration that the Threat Response Profile configuration was updated.

    • Verify the Endpoint Configuration – Manifest was updated on the endpoints.

    • Verify there are no pending Endpoint Configuration Approvals.

    • Verify there are no pending Action Approvals for Endpoint Configuration.

  • The profile was deployed and received, but the client was unable to apply the correct configuration.

    • Verify the currently installed Threat Response Profile ID and revision matches the Threat Response deployed profile using the Client Extensions – Status sensor.

    • Review the <Tanium Client>\Logs\threat-response.txt log to identify issues applying the profile.

    • If endpoints are not applying configurations as expected, try creating a simple change to the profile (for example, change the description) and save the profile to increment the revision number. Then deploy the profile again. The updated revision forces the client to re-apply the entire profile.

    • Review the output of the Client Extensions – Status sensor for any health_check results.

Should none of these actions resolve the issue then a server-side troubleshooting bundle is required. For more information, see Collect Troubleshooting Bundle. Return the collected information and a detailed description of the issue seen and the steps taken to Tanium for analysis.

No alerts are generated

Outside specific testing of intel should be assumed that alert generation is a scarce occurrence. Under normal circumstances it is to be hoped that a given system does not generate alerts based on deployed intel, as such no alerts or very low numbers of alerts should be considered normal operation. The alert generation and collection process involve interaction between the client and the service of Threat Response and so validation of both of these is required to validate that the process is working as expected.

The following steps are targeted at troubleshooting a testing scenario where alert generation is expected because of user interaction on an endpoint to validate the detection and alerting process.

To validate that the service side parts of the process have been applied correctly:

  • Ensure that profile and intel have been deployed as expected and that the system shows the correct profile ID and revision and intel revision from the Client Extensions - Status sensor. If this output shows issues then the following steps would be recommended as initial remedial actions:
    • Redeploy all relevant profiles and intel from the Threat Response profiles page validate any actions do not require approval and are waiting in the queue.
    • Ensure that the Threat Response System Notifications page does not show throttle messages for the intel document in question.

Should none of these actions resolve the issue and either the profiles have not deployed, or the questions have not been issued then a server-side troubleshooting bundle is required. For more information, see Collect Troubleshooting Bundle. Return the collected information and a detailed description of the issue seen as well as the steps taken to Tanium for analysis.

If the above checks show the expected results then endpoint investigation is required. To validate that the endpoint is working as expected (these actions assume access to the endpoint is available) the following steps should be attempted:

  • Validate that the Endpoint Configuration - Tools Status sensor shows all relevant tools installed.
  • Ensure that any actions being taken to trigger alerts are starting from a new process each time they are attempted (such as, if a user is trying to trigger a signal from a command prompt then open a new command prompt for each attempt).
  • Ensure that the Threat Response System Notifications page does not show throttle messages for the intel document in question.

If one of the above actions show unexpected output, then take the following steps to try and resolve the issue:

  • Redeploy any tools that have not deployed as expected by using the Endpoint Configuration - Reinstall Tool action targeting the tool in question.
  • Wait for throttles to clear for a given intel document or attempt firing a different intel document from the endpoint.
  • Ensure commands to trigger alerts are executed in a new instance for each attempt.

If none of the above steps show an issue or provide a resolution then a client-side troubleshooting bundle is required. For more information, see Collect Troubleshooting Bundle. Return the collected information and a detailed description of the issue seen and the steps taken to Tanium via a support case for analysis.

Too many alerts are generated

Alerts are generated specifically from the endpoint as such to validate the reasoning behind this issue there is little to be done on the service side for investigation. The repercussions of too many alerts can impact the service and user interface performance of Threat Response and so remedial actions may be service side as well as client-side.

The following steps are directed at validating the source of the high number of alerts and should be performed to ensure that any remedial actions are targeted correctly:

  • Validate the intel document names and ID's associated with the number numbers of alerts using the Trends Boards, Threat Response home page graphics or the Alerts page.
  • Investigate if the alerts matches are intended or unintended based on the syntax of the indicator and the alert details provided.

Depending on the findings from the above actions there can be several courses of action that you can perform to reduce the alert load:

  • Remove the intel document from the profile associated with affected endpoints and then redeploy the profile and intel database.
  • Modify the intel document to ensure it is matching the correct artifacts or endpoint behavior and redeploy the intel document.
  • For Tanium Signal-based alerts it is possible to create a suppression rule associated with the intel document to prevent specific circumstances from creating alerts. Once configured, a suppression rule must be deployed to the endpoints using the Intel deployment action to ensure alerts are suppressed on the endpoints and on the service.
  • Configure or tune endpoint or service throttling to prevent higher than expected numbers alerts from being sent for a given intel document.
 

An alert backlog can grow on the endpoints and in the service, which could mean that the above remedial actions prevents new alerts on the endpoints, and might not resolve the situation with a very large backlog.

Should alerts continue to arrive in the user interface and cause performance issues, it is advised to create a support case with Tanium with a detailed description of the issue seen and the steps taken.

The lifetime of recorder events is too short

The lifetime of the recorder is controlled by the settings for the database from the Threat Response recorder configuration. The default values are 1 gigabyte (GB) for size and 90 days for length.

The volume of data sent to the recorder is regulated by the filters associated with its configuration. These filters are used to include or exclude specific elements of telemetry in the recorder database.

There are two possible reasons why the database does not hold events for a sufficient retention period:

  • The size of the DB is not sufficient to store all of the required data.
  • The length of time the DB will hold events is too short.

There are multiple options available to ensure the required data is recorded in the database:

  • Modify the maximum size of the recorder database.
  • Modify the maximum retention period for the recorder database.
  • Modify the filters for the configuration to reduce the recorded events in the DB.

The settings for maximum size and retention period take effect in the order that they are received by the endpoint. If the maximum database size is reached before the maximum lifetime of the database then the recorder will start pruning events from the database to ensure that it remains at the maximum size. Alternatively, if the maximum retention period is reached before the maximum size is reached then the recorder starts pruning events.

You might need to change both configurations at the same time to achieve the required outcome. Because of the uncertainty of the impact of changing the database size or the retention period these options are less optimal when trying to regulate the retention period.

If it is impossible to change the maximum size (this is the most common situation), or more control of the content of the database is required, then the alternative, and preferred, option is to utilize filters to remove unnecessary recorded telemetry from the database. This exercise requires some investigation of the database content and validate the unnecessary content and create filters for it.

When deploying filters, any process filters that are applied filters all activity from that process (there is no file, registry, etc data recorded) as such these are the broadest filters and can reduce the amount recorded telemetry quickly. Deploying other filters for the other event types (file, network, registry, security, and image events) are more specific and can be used to remove very specific events from the recorded telemetry. For additional information about filters, see Create filters.

On Linux endpoints, a System filter enables you to specify a path that is excluded from audit configuration. When providing this type of filter, be sure to provide the full path to the file.

Should there continue to be issues with the volume of data recorded then a client-side troubleshooting bundle and an export of the Recorder configuration are required. Return the collected information and a detailed description of the issue seen and the steps taken to Tanium via a support case for analysis.

File, network, or security events are not displayed on Oracle Linux server

If you are not seeing file, network, or security events in the recorder results, you can disable SELinux. When SELinux is enabled and the auditd fallback is disabled on Oracle Linux, only process information is returned. Alternatively, ensure that the Client Recorder Extension configuration parameters are set as follows:

  • CX.recorder.AuditdStopAuditdService is set to 0.
  • CX.recorder.AuditdEnableAudispdFallback is set to 1.

For more information, see Client Recorder Extension User Guide: Configuring recorded events .

Identify Linux endpoints that are missing auditd

If Linux endpoint events are not being recorded, they might be missing the audit daemon and audispd services. Ideally, the audit daemon is installed and configured before installing the Threat Response module, but it is possible for endpoints to come online at a later time.

  1. (Optional) Create the auditd package.

    You can either create a general installation package and put the logic in the scripts or you can have a simple script and put the logic in the Tanium query. See Tanium Core Platform User Guide: Creating and managing packages.

  2. Ask the question: Get Installed Application Exists[audit] from all machines with Is Linux containing "true".

  3. Deploy the appropriate auditd package to the identified endpoints.

    If you need to distribute the package to a large number of endpoints, spread the changes out over time to avoid a negative impact on the network.

Start or stop the recorder

You might need to manually start or stop the recorder.

Resolve the underlying issue and restart the recorder. Or, if you find that the recorder is using more system resources than expected, you can stop the recorder and troubleshoot the issue.

  1. Identify the computer groups that contain endpoints on which you want to stop the recorder.
  2. Deploy a profile that does not contain a recorder configuration to the computer groups you want to target.
  3. You can optionally create a live endpoint connection to specific endpoints to troubleshoot any issues.

To start the recorder, deploy a profile that has a recorder configuration to the targeted computer groups.

Configure client disk space use

You can use two configurable client settings for disk space use:

CX.core.DiskSpaceWarningPercent

CX.core.DiskSpaceCriticalPercent

Use these client settings to surface warnings about the amount of disk space left on the disk that the Tanium Client is installed on. By default, these settings are 5% and 1% respectively. CX-core checks the available disk space on the endpoint once every five minutes.

When the DiskSpaceCriticalPercent threshold is reached, IndexCX pauses indexing until the free disk space is increased above the critical threshold. Endpoints that have reached either the Warning or Critical thresholds will display a health check in the Client Extensions – Status sensor. Use the following question to list all endpoints with a disk space health check:

Get Computer Name and Client Extensions - Status contains disk space from all machines with Client Extensions - Status contains disk space

Modifying client disk space thresholds

The free disk space thresholds can be set via the command line or using a Tanium Action. For more information on modifying client settings, see Tanium Client Management User Guide: Managing client settings and Index configurations.

Command line example:

Set the warning threshold to 10 percent and the critical threshold to 5 percent:

./TaniumClient config set CX.core.DiskSpaceWarningPercent 10

./TaniumClient config set CX.core.DiskSpaceCriticalPercent 5

Tanium action example:

WindowsNon-Windows
Package: Modify Tanium Client Setting Package: Modify Tanium Client Setting [Non-Windows]
RegType: REG_DWORD Type: Numeric
ValueName: CX.core.DiskSpaceWarningPercent ValueName: CX.core.DiskSpaceWarningPercent
ValueData: 10 ValueData: 10

You can check non-default disk space settings with the question:

Get Tanium Client Explicit Setting[CX.core.DiskSpaceWarningPercent] and Tanium Client Explicit Setting[CX.core.DiskSpaceCriticalPercent] from all machines

A result of “Key/Value not found” indicates that the setting is the default value (5% for Disk Space Warning and 1% for Disk Space Critical).

Files are not being hashed or indexed

Index is optimized to minimize endpoint resource utilization. The solution indexes local file systems, computes file hashes, and gathers file attributes and magic numbers. This information is recorded in an SQLite database for detection and reporting of threat indicators for files at rest.

Index creates and maintains an inventory of the file system on an individual endpoint with the following operations:

  • Detect file changes
  • Compute file hashes
  • Calculate magic number

For more information about indexing in Threat Response, see Client Index Extension User Guide.

If the configuration does not exclude the file or location then it is possible that Index is not running on the system for some reason.

To validate that this is the case, perform the following steps:

  • Use the Client Extensions - Status  sensor to validate that Index is running and configured.
  • Validate that the scheduled action for the starting index, Threat Response - Start Index has reached the endpoint by reviewing the scheduled action and its targeting.

If the index process is not showing as running then it might be possible to restart the process by manually targeting the relevant action for the operating system in the Threat Response - Start Index (Linux/Mac/Windows) question.

Cannot establish a live connection

Live connections are established using the shared service component Direct Connect. Elements of the Direct Connect services are included in the Threat Response user interface to enable users to search for devices and make connections and the capabilities for downloading files or navigating the Recorder database are provided on top of this connection via Threat Response.

To ensure that Direct Connect is working as expected, perform the following steps:

  • Review the outputs of the Get Client Extensions - Status sensor to validate that the endpoints in question have the required endpoint tools deployed and are working as expected.
  • Review the outputs of the Direct Connect - Connection Configuration sensor to validate that the endpoints in question have the correct configuration.
  • Review the outputs of the saved question Direct Connect - Endpoint Info and ensure the endpoint in question is showing in the results (this can also serve to refresh the data that shows in the live response search bar).

Should the outputs of these commands show an issue then it might be required to force the distribution of the Direct Connect tools to the endpoint in question to ensure that it is ready to accept connections, issuing the action Endpoint Configuration - Reinstall Tool for the relevant operating system, and selecting the option for Direct Connect in the Tool Name dropdown to reinstall the tools on the endpoint.

Should there continue to be issues connecting to the endpoint then a client-side troubleshooting bundle should be collected for Direct Connect. Return the collected information and a detailed description of the issue seen and the steps taken to Tanium via a support case for analysis.

Test Live Response connections manually

To test Live Response connections manually, see Generate known_hosts and test connections.

Stream is not sending data

Stream provides the capability to send telemetry from the recorder directly to destinations outside of the Tanium infrastructure such as SIEM. The stream capability relies on the correct configuration from the service as well as access to the configured destination to be able to perform its function. It is important to first validate that the receiving side for the telemetry is configured and running as expected testing this from target endpoints is the only way to ensure that connectivity is working as expected. As with most components, there is a service and an endpoint component to troubleshooting problems.

To validate the service side components of Stream:

  • Validate that Stream and Recorder tools are deployed and reporting as expected using the Get Client Extensions - Status sensor.
  • Ensure the Stream configuration is pointing to the correct destination or URL and that any credentials are included to ensure that the endpoints have access to the destination.
  • Validate that Dry Run is not enabled in the configuration. By default, Dry Run is enabled when you create a stream configuration.
  • Ensure that any filters applied to the Stream configuration send the required telemetry from the endpoint to the destination system.
  • When deploying a custom configuration, validate that the JSON syntax is correct and that the client is able to parse and deploy the given configuration.
  • If investigating Linux systems then validate that there are no system file filters that may be preventing the Recorder from gathering the telemetry required to send.
 

Should all of the above appear to be configured and working as expected then this might indicate an endpoint issue. To validate that the endpoint is working as expected it can require access to the endpoint.

  • Ensure enough time has passed for Stream to reach the threshold of sending data, this can take some time depending on the configuration and the amount of telemetry being generated by the endpoint.
  • Ensure that the endpoint can resolve and contact the destination server for receipt of telemetry (there are many options for this but commands such as ping, host, nslookup, telnet, etc.).
  • Validate that the endpoint has recorded the events expected to be sent to the destination utilizing the live connection capability.

If after verifying the availability of the receiving side, service, and endpoint configurations and connectivity there is still no telemetry being received then a client-side troubleshooting bundle and an export of the Stream configuration are required. Return the collected information and a detailed description of the issue seen and the steps taken to Tanium via a support case for analysis.

Stream is sending too much data

The volume of data sent from any given client to the Stream destination is determined by the activity on the endpoint and the configuration that has been applied to Stream. While the volume of data is not in essence an error it is something that may cause issues on specific endpoints or on the receiving side.

There are two mechanisms available to reduce the volume of data being sent by Stream depends on the configuration and the requirements for the data being sent from each endpoint. The two options available are:

  • Disable specific event types from being sent.
  • Use filters to reduce the numbers of specific events sent.
   

Depending on the requirements for the use of the telemetry being sent from Stream, you can use one or both of these mechanisms to reduce the total amount of data being sent from the endpoints:

  • Removing an entire event type from the configuration removes all of the events of this type from the data being sent from the endpoint to the receiving side. Unlike Recorder filters, when disabling process events the other event types for the given process are sent (although the references to process in these events are no longer resolvable).
  • Utilizing filters to remove events from being sent represents a more specific reduction in data volumes. The filters available are the same as those available for the Recorder configuration and can be reused.

It should be considered that although Stream utilizes data from the Recorder, Stream is a separate subscription to the recorder data, and options including the Stream configuration do not impact the data being sent to the Recorder database, or vice versa.

Should there continue to be issues with the volume of data being sent via Stream then a client-side troubleshooting bundle and an export of the Stream configuration are required. Return the collected information and a detailed description of the issue seen and the steps taken to Tanium via a support case for analysis.

Configuration not available or not updated to the latest settings when deploying package

If a configuration is not available or has not updated to the latest settings when you deploy a Live Response package to endpoints, From the Threat Response menu, go to Management > Live Response, and click Generate Packages. You must update all Live Response packages that you deploy to endpoints to reflect updated configurations.

Action not running on endpoint

If an action is not running on an endpoint, ensure that the connection to the endpoint is working by testing the Live Response connections manually. For more information, see testing connections manually.

If the connections to remote endpoints work correctly, but actions are not running, confirm that action approval is not stopping the action from running. Action approval means that actions a user initiates cannot deploy until another user approves those actions. Approvers can be users with the Administrator reserved role or a role that grants Approve Action and Sensor read permissions. If your organization allows exceptions to approval requirements, you can configure a role that grants Bypass Action Approval permission. For more inforrmation, see Tanium Console User Guide: Managing Action Approval.

Artifacts not being copied to destination

If artifacts are not being copied to the destination, review the Live Response log in the folder that corresponds to the action ID.

In addition to the standard action logs on the endpoint (Tanium_Client_Location\Downloads\Action_###\Action_####.log), a log file of activities resides in the same directory. This file follows the naming convention: YYYYMMDDhhmm_LR.log.

When collection completes, the YYYYMMDDhhmm_LR.log is copied to the destination. The action log is not copied to the destination.

Use both the action log and the Live Response log to troubleshoot problems. The action log captures messages written to standard error (stderr).

Custom configurations are missing

The content of taniumqarantine.dat is restored to the default values every time quarantine content is updated. For example, if you upgrade Threat Response or install a newer version of the Tanium Quarantine solution, any custom configurations that you have added to the quarantine packages either by using the Live Response workbench or by editing the packages manually are overwritten with the default versions of the packages.

Keep a backup copy of any Live Response packages that contain custom configurations so that you can restore your customized packages after a tools upgrade.

Live Connections are not working while quarantined

If you are unable to make live connections to endpoints that you have quarantined, make sure that the ports that Tanium Direct Connect uses to communicate with remote endpoints are not blocked on the target endpoint, and that the IP addresses for the Tanium Module Server (or Zone Server, if applicable) are not blocked. For a list of the ports that must be enabled for remote endpoint communication, see Tanium Direct Connect User Guide: Requirements.

Live Response is not working to copy files to the destination while quarantined

If Live Response is not copying files to the destination while quarantined, make sure that all destination IP addresses and ports for the protocols you are using are defined in the quarantine configuration. For more information, see Isolating Endpoints: Reference: Custom rules and options.

Uninstall Threat Response

You might need to remove Threat Response from the Tanium Module Server for troubleshooting purposes.

  1. From the Main menu, go to Administration > Configuration > Solutions.
  2. Under Threat Response, click Uninstall. Click Proceed with Uninstall to complete the process.

Contact Tanium Support

To contact Tanium Support for help, sign in to https://support.tanium.com.