How to Access User Guide and Helpful Documents:

The CBC user guide provides an in-depth guide to many topics within the Carbon Black Cloud. The user guide is accessible through the console under the “help” section. The guide is divided into various topics from sensor installation to detailed guides for each page within the console.

User Guide:

The guide is accessible at this link: VMware Carbon Black Cloud User Guide

Useful Links:

Below are some useful links that can provide general information about the CBC Sensor and Console.

Accessing Release Notes:

Another useful location on the User eXchange is the release note section, found here: Carbon Black Cloud Sensor/Console Release Notes

REPCLI – The Command Line Tool:

What Is REPCLI:

The REPCLI utility is a command line interface for the CBC sensor. Each CBC sensor comes with REPCLI access for limited commands, but to enable the full scope of the utility an authenticated user SID must be specified. While any account can pass basic REPCLI commands, the authenticated commands—including the commands to enable sensor bypass locally or force a sensor to check in with the console—must be issued from the account with the specified SID. The REPCLI user SID can be either a group or an individual user, depending on preference.

VMware Carbon Black recommends enabling authenticated commands by specifying a REPCLI user as this troubleshooting capability is imperative in troubleshooting disconnected sensors and can often prevent having to perform a reinstallation of the sensor to resolve issues. Below are a few of the guides that provide an overview of the REPCLI utility:

How to Use REPCLI:

The REPCLI tool must be accessed through the command prompt, and for any authenticated commands the command prompt must be executed as the authorized SID. Below are some guides for the REPCLI utility that offer more detail:

Why Enable REPCLI:

The REPCLI tool expands the sensor’s capabilities and allows for more options when troubleshooting the sensor if it is offline. Some common use cases are below:

Common Issue Types:

Interoperability Issues

Symptoms:

The symptoms of an interoperability issue may vary depending on the applications involved. The most common presentations are overutilization of resources and / or an unexpected application crash.

Diagnostics:

When troubleshooting an interoperability issue, the first step is to collect all possible diagnostics to ensure the Red Canary support team has the data needed to investigate further. It is critical to collect these diagnostics before uninstalling the sensor. The diagnostics available will depend on the OS of the device. See below for details:

Windows:

For Windows devices, two items are useful to the investigation: sensor logs, and process monitor. For more information about collecting these logs, please see the guides below:

MacOS

For Mac devices the best available data will be the sensor logs which can be gathered as shown below:

How To Collect Sensor Logs Locally (Mac)

Linux:

Linux also only requires the sensor logs, pulled as shown below:

How to Collect Sensor logs locally (Linux)

How to troubleshoot:

Troubleshooting Unexpected Crashes

In the case the application is crashing, the first step is to ensure that the issue is not an unexpected block. This is best accomplished by searching the investigate page for the device name and the TTPs policy_deny or the ttp policy_terminate:

Additionally, data can be limited further by setting a custom filter for the approximate time of the crash:

If no results are returned from these searches, it is a good indication that the application is crashing without the sensor intentionally blocking, which is indicative of an interop issue. Otherwise, it is likely an unexpected block and should be investigated as such.

Troubleshooting Resource Overutilization

If the issue presents as resource overutilization, the first step is to determine if the issue can be replicated. If the issue presents under specific conditions, put the sensor into bypass and check if the issue persists. As sensor bypass mimics uninstall, if the issue continues to present it is possible that the sensor is not the cause. If the issue is resolved, it indicates an interoperability issue with the sensor.

Temporary Solutions for Interoperability Issues

Any time an interoperability issue occurs, it is best practice to collect all possible data—see diagnostics for more information—and open a support ticket. This ensures that Red Canary can resolve the issue by the most secure means, and possibly look at accounting for the interop issue in future sensor versions. Once the data has been collected, depending on the criticality of the issue, a bypass or API bypass rule can help alleviate the issue in the short term.

To identify the path needed to bypass, identify the application that is crashing or causing the resource overutilization. Once the application is identified, identify the paths that contain the application processes. Once this data is collected, bypass rules can be constructed to alleviate the issue.

In the example below, the problem application would reside C:\users\jdoe\failing application\ and its subfolders:

Navigate to the enforce drop down then select the policies option in the CBC console menu. Select “Policies” page, then select the desired policy and the “Prevention” tab:
Select the “+” next to permissions to expand the section. Next, select the “Add application path option at the bottom of the section.
Input the desired application path, then select “Performs any operation” or “Performs and API operation” and bypass. If it is unclear whether to choose “Performs any api operation” or “Performs any operation”, start by trying to bypass only API operations as this is more limited. When inputting the path, a single “*” character will include a single folder, while a “**” is recursive and will include all sub-folders.

In this example, the “failing application” folder and all sub folders would be API bypassed if they were located within the C:\users\ directory.

4. Once the path is entered, select the “Confirm” button then “Save” to update the policy. Please wait ten minutes to allow time for the sensors to update their policy before retesting.

Important Reminder

A bypass or API bypass rule always results in a lower security posture. A bypass rule causes the sensor to stop monitoring, reporting on, or blocking anything at the targeted path. Because of this, any bypass rule should be as specific as reasonably possible, and if a bypass rule is needed, Red Canary recommends opening a ticket with a support to investigate further.

To ensure the support ticket is handled as efficaciously as possible, please provide the following when opening tickets regarding interoperability issues:

Device name in the Carbon Black Cloud Console
Application experiencing interoperability
Date/Time interoperability occurred
Application actions performed or blocked
Are results the same if Sensor is placed in Bypass?
Remove Sensor from Bypass and attempt to implement a Permissions rule
Test using a Permissions rule
Is the interoperability issue reproducible?
1. If yes, collect 2 separate Procmon logs:
2. Steps for Windows 3.3.x.x Sensor and earlierorsteps for Windows 3.4.x.x Sensor and higher
  1. Procmon with the Sensor Active and with the issue reproduced
  2. Procmon with the Sensor in Bypass taking the same steps as above
3. After collecting Procmon logs, request Sensor logs:
4. Collecting Sensor Logs Windows
5. Collecting Sensor Logs Mac

Unexpected Blocks

Unexpected or false positive blocks are most frequently caused by side effects of path-based policy. Path-based policy supersedes reputation-based policy rules, so if a specific path is denied it will not be allowed to execute regardless of its reputation. Alternatively, some false positives may be caused by inaccurate reputation being assigned to a file.