VMware Carbon Black EDR Server 7.7.0 Release Notes

VMware Carbon Black EDR 7.7.0 \| 14 JUL 2022 \| Build 7.7.0.220712 Check for additions and updates to these release notes.

VMware Carbon Black EDR 7.7.0 | 14 JUL 2022 | Build 7.7.0.220712

Check for additions and updates to these release notes.

What's New

VMware Carbon Black EDR 7.7.0 is a Minor (Feature) release of the VMware Carbon Black EDR (formerly CB Response) server and console. This release delivers a containerized distribution of Carbon Black EDR Server for on-prem customers, Microsoft Active Directory (AD) Integration for on-prem customers, filtering enhancements on the Sensors page, audit logging enhancements for Isolate/Unisolate actions, a new option in the cbcheck command line interface (CLI) utility for managing sensor versions, and support of RHEL 8.6.

Carbon Black EDR no longer supports Red Hat Enterprise Linux (RHEL) / CentOS 6.x as of this release.

Components Included in this Release
- Server version 7.7.0.220712
- Windows Sensor version 7.3.1.18323: Release Notes
- macOS Sensor version 7.2.2.16783: Release Notes
- Linux Sensor version 7.1.0.98326: Release Notes
Each release of Carbon Black EDR software is cumulative and includes changes and fixes from all previous releases.
Containerized Carbon Black EDR Server

Carbon Black EDR Server 7.7.0 introduces a containerized offering of Carbon Black EDR Server for on-prem EDR customers. For the foreseeable future, Carbon Black EDR Server will be offered as two distinct distributions: the traditional, RPM-based distribution and the new, container-based distribution. The container-based distribution simplifies installation and upgrade because all Carbon Black EDR Server components and dependencies are packaged into a container image. It also provides superior flexibility for which operating system (OS) on which you host Carbon Black EDR Server. See the VMware Carbon Black EDR Containerized Server Guide for more information.
Active Directory (AD) Integration

Carbon Black EDR Server 7.7.0 introduces an integration between Carbon Black EDR and Microsoft Active Directory (AD) for on-prem Carbon Black EDR customers. The integration provides simplified, centralized management of Carbon Black EDR user authorization, authentication, team memberships, and feature-level enhanced permissions for customers who leverage Microsoft AD. This initial implementation delivers file-based configuration of the integration with Microsoft AD or OpenLDAP and supports connection via LDAP, LDAPS, or LDAP + TLS (STARTTLS). See the "Active Directory" section of the VMware Carbon Black EDR Integration Guide for more information.
Isolate/Unisolate Audit Logging Enhancements

Carbon Black Server 7.7.0 introduces audit logging of sensor Isolate host and Remove Isolation actions in a new Isolation Audit section of the Status History panel on the Sensor Details page. The Isolation Audit section includes the timestamp of the activity, the action (Isolation or Remove Isolation), User Details (the Username and first and last name of the user who performed the activity), User IP Address, and Notes. Notes are sourced from a new, optional capability to record a note when performing the Isolate host or Remove Isolation action on a sensor. See the VMware Carbon Black EDR 7.7 User Guide for more information.
Sensors Page Filtering Enhancements

Carbon Black EDR Server 7.7.0 introduces numerous enhancements to the Sensors page, including the ability to filter sensors by Sensor Status (Online, Offline, Uninstalled/Uninstall Pending, Isolated, Not isolated). See the VMware Carbon Black EDR 7.7 User Guide for more information.
Coreservices API Payload Validation Enhancements

Carbon Black EDR Server 7.7.0 introduces validation of all payload-tagged create (POST) and update (PUT) Coreservices API requests against expected model schemas. The validation does not apply to requests from the Carbon Black EDR console, as it is a trusted source and thus does not compromise user experience nor response time. The feature is controlled by a cb.conf flag, ValidateApiPayloadSchema, which is disabled by default. The feature is a great value-add to all customers requesting Carbon Black EDR APIs through custom scripts or CURL or any other client outside the scope of Carbon Black EDR. This ensures a smooth client-to-server transaction, as an API would not receive any unwanted fields/properties nor their types and values as part of their payloads. See the VMware Carbon Black EDR Server Configuration Guide and the "EDR REST API Quick Start" section of the VMware Carbon Black EDR API Developer Guide for more information.
New Option in cbcheck CLI Utility for Managing Sensor Builds

Carbon Black EDR Server 7.7.0 introduces a new option in the cbcheck CLI utility to manage sensor builds. This option provides greater control over the sensor versions that are stored and presented for deployment by the Carbon Black EDR Server. I.E. cbcheck sensor-builds: -r/--remove VERSION_STRING, where VERSION_STRING is a string in the format "<platform>: <version>", for example, "windows: 007.001.001.16959". This is the format returned by sensor_builds -L.

If the specified version is found on the system, Carbon Black EDR will remove the package using rpm -e and then update the database using the same code as sensor-builds -u. The result is that the files will be removed on disk as well as the corresponding entries in the sensor_build_packages table. The associated entry in the sensor_builds table will be retained, but with all of its flags set to False to indicate that this version is not available for installation/upgrade/downgrade.

This command will not remove any sensor installers that were installed as part of a Carbon Black EDR product installation or upgrade. If you want to remove any of these installers, you must delete the installer files from disk and then execute cbcheck sensor-builds -u.

While this command would only remove a single sensor installer version, it can easily be incorporated into a bash script to invoke the command repeatedly, based on the contents of a file, where each line contains a version string, as defined above.

For example: assuming the existence of such a bash script, called cb-remove-sensors:

Execute /usr/share/cb/cbcheck sensor-builds -L > sensor_builds.txt.

Edit the file sensor_builds.txt, removing all versions to be retained, and leaving the versions to be removed.

Execute cb-remove-sensors sensor_builds.txt.

Documentation

This document supplements other Carbon Black documentation. Supplemental release documentation can be found in the Carbon Black EDR section of docs.vmware.com.

In addition to this document, you should have access to the following key documentation for VMware Carbon Black EDR Server 7.7.0:

VMware Carbon Black EDR 7.7 User Guide: Describes how to use the Carbon Black EDR servers that collect information from endpoint sensors and correlate endpoint data with threat intelligence.
VMware Carbon Black EDR 7.7 Server / Cluster Management Guide: Describes installation, configuration, and upgrade of RPM-based Carbon Black EDR servers.
VMware Carbon Black EDR 7.7 Containerized Server Guide: Describes installation and migration of Carbon Black EDR containerized servers.
VMware Carbon Black EDR 7.7 Server Configuration Guide: Contains details about cb.conf parameters.
VMware Carbon Black EDR 7.7 Unified View Guide: Describes the installation and use of the VMware Carbon Black EDR Unified View server. Information on server hardware sizing requirements and software platform support is included.
VMware Carbon Black EDR Operating Environment Requirements: Describes base requirements and scalability information for installing Carbon Black EDR on-prem servers.

[On-Prem Only] Prepare for Server Installation or Upgrade

This section describes the requirements and key information that is needed before installing a VMware Carbon Black EDR server. All on-premises users, whether upgrading or installing a new server, should review this section before proceeding. See the appropriate section of the VMware Carbon Black EDR 7.7 Server/Cluster Management Guide for specific installation instructions for your situation:

To install a new VMware Carbon Black EDR server, see “Installing the VMware Carbon Black EDR Server”.
To upgrade an existing VMware Carbon Black EDR server, see “Upgrading the VMware Carbon Black EDR Server”.
To install and migrate to Containerized Carbon Black EDR Server (Server 7.7.0+), see the VMware Carbon Black EDR Containerized Server Guide.

Customers on Server 5.x, please note:

Direct upgrades from Server 5.x to Server 7.x are not supported. See the VMware Carbon Black EDR 7.7 Server/Cluster Management Guide and this VMware Carbon Black User Exchange announcement for more information.

Yum URLs

VMware Carbon Black EDR Server software packages are maintained at the Carbon Black yum repository (yum.distro.carbonblack.io). The links will not work until the on-prem General Availability (GA) date.

The following links use variables to make sure you install the correct version of VMware Carbon Black EDR, based on your machine’s operating system version and architecture.

Use caution when pointing to the yum repository. Different versions of the product are available on different branches, as follows:

Specific version: The 7.7.0 version is available from the Carbon Black yum repository, that is specified in the following base URL:

baseurl=https://yum.distro.carbonblack.io/enterprise/7.7.0-1/$releasever/$basearch

This link is available as long as this specific release is available. It can be used even after later versions have been released, and it can be useful if you want to add servers to your environment while maintaining the same version.

Latest version: The latest supported version of the VMware Carbon Black EDR server is available from the Carbon Black yum repository, that is specified in the following base URL:

baseurl=https://yum.distro.carbonblack.io/enterprise/stable/$releasever/$basearch/

This URL will point to version 7.7.0-1 until a newer release becomes available, at which time it will automatically point to the newer release.

Note:

Communication with this repository is over HTTPS and requires appropriate SSL keys and certificates. During the Carbon Black EDR server install or upgrade process, other core CentOS packages can be installed to meet various dependencies. The standard mode of operation for the yum package manager in CentOS is to first retrieve a list of available mirror servers from http://mirror.centos.org:80, and then select a mirror from which to download the dependency packages. If a VMware Carbon Black EDR server is installed behind a firewall, local network and system administrators must make sure that the host machine can communicate with standard CentOS yum repositories.

Installing Containerized Carbon Black EDR

See the VMware Carbon Black EDR Containerized Server Guide for instructions on how to download and install the Carbon Black EDR Server container image.

[On-Prem Only] System Requirements

Operating system support for the server and sensors is listed here for your convenience. The VMware Carbon Black EDR 7.7 Operating Environment Requirements document describes the full hardware and software platform requirements for the VMware Carbon Black EDR server and provides the current requirements and recommendations for systems that are running the sensor.

Both upgrading and new customers must meet all of the requirements specified here and in the VMware Carbon Black EDR Operating Environment Requirements document before proceeding.

Server / Console Operating Systems

Note: Carbon Black EDR no longer supports Red Hat Enterprise Linux (RHEL) / CentOS 6.x as of this release.

For best performance, Carbon Black recommends running the latest supported software versions for RPM-based Carbon Black EDR installations:

Red Hat Enterprise Linux (RHEL) / CentOS 7.3 - 7.9 (64-bit)
Red Hat Enterprise Linux (RHEL) / CentOS 8.1 - 8.6 (64-bit)
CentOS 8.2 - 8.4 (64-bit)

However, if the customers are pinning dependencies to a specific OS version, the product only supports the following software versions for RPM-based Carbon Black EDR Server and Unified View:

Red Hat Enterprise Linux (RHEL) / CentOS 7.5 - 7.9 (64-bit)
Red Hat Enterprise Linux (RHEL) / CentOS 8.2 - 8.6 (64-bit)
CentOS 8.2 - 8.4 (64-bit)

Note: Versions 7.3, 7.4, and 8.1 (64-bit) of CentOS/RHEL are not supported if customers are pinning dependencies.

Installation and testing are performed on default install, using the minimal distribution and the distribution’s official package repositories. Customized Linux installations must be individually evaluated.

For containerized on-prem Carbon Black EDR Server installations, the product supports any operating system that is capable of running:

Docker 1.13
Docker CE 20.10.14

Sensor Operating Systems (for Endpoints and Servers)

For the current list of supported operating systems for VMware Carbon Black EDR sensors, see https://docs.vmware.com/en/VMware-Carbon-Black-EDR/index.html.

Note: Non-RHEL/CentOS distributions or modified RHEL/CentOS environments (those built on the RHEL platform) are not supported.

Configure Sensor Update Settings Before Upgrading Server

VMware Carbon Black EDR 7.7.0 comes with updated sensor versions. Servers and sensors can be upgraded independently, and sensors can be upgraded by sensor groups.

Decide whether you want the new sensor to be deployed immediately to existing sensor installations, or install only the server updates first. Carbon Black recommends a gradual upgrade of sensors to avoid network and server performance impact. We strongly recommend that you review your sensor group upgrade policies before upgrading your server, to avoid inadvertently upgrading all sensors at the same time. For detailed information on Sensor Group Upgrade Policy, see the Sensor Group section of the VMware Carbon Black EDR 7.7 User Guide.

To configure the deployment of new sensors by using the VMware Carbon Black EDR web console, follow the instructions in the VMware Carbon Black EDR Sensor Installation Guide.

Third-Party Software Updates

Com.google.protobuf-java 3.19.3 → 3.20.0
EHCache 2.10.6 → 3.10.0
Google GSon 2.8.6 → 2.9.0
Jackson-databind 2.11.4 → 2.13.2
Log4J 2.17.1 → 2.17.2
Logback 1.2.3 → 1.2.10
Netty Project 4.1.72 → 4.1.76
PostgreSQL 13.5 → 13.7
Python 3.9.5 → 3.10.4
Redis 6.0.16 → 7.0.0

Resolved Issues

CB-35678: On the Search Threat Reports page, sorting of the results could be inconsistent
CB-36455: On the Sensors page, the buttons above the Sensors table were misaligned
CB-36818, EA-1958: Watchlist query that contains a “%” and/or “=” could not be edited
CB-36831: Moving many (>50) sensors to a different Sensor Group at a time could result in poor page performance
CB-36852: Threat Intelligence Feed via API

A fix for an issue, in which an attempt to rename a built-in Threat Intelligence Feed via API would result in an improper 500 error response. Now, since built-in Threat Intelligence Feeds are protected from renaming and removal, a proper 400 error response is returned when a rename attempt is made.
CB-18655, EA-11065: Triage Alerts page

A fix for an issue on the Triage Alerts page, in which after marking one or more alerts as “False Positive”, selection of “Ignore future events from these reports?” in the subsequent pop-up did not properly work.
CB-18695, EA-11801: An attempt to modify an existing ingress filter via API would fail
CB-38271, EA-14772: An update to our Ingress Filter documentation on the Carbon Black Developer Network to clarify the expected format for netconn_filters
CB-32635, EA-17022, EA-15952: An attempt to create a new watchlist or use the ‘Try it Out’ feature on the Watchlists page could fail
CB-36242, EA-18567: An attempt to rename a Sensor Group would result in a delay and/or the change would not be accepted and saved
CB-35994, EA-19104: An enhancement to add the hostname value to watchlist.storage.hit.process events that are forwarded through Event Forwarder
CB-36012: Specifying an invalid IP address in a GET /v1/sensor API call would produce a 500 error response

Now, entering an invalid IP address produces a 400 error response with a relevant error message.
CB-36013: Entering an excessively high inactive_filter_days value in a GET /v1/sensor API call would produce a 500 error response

Now, entering an invalid value produces a 400 error response with a relevant error message.
CB-36846, EA-19622: VMware Carbon Black EDR Server Cluster Management Guide

An update to the VMware Carbon Black EDR Server Cluster Management Guide to instruct customers on establishing and using an SSH connection prior to changing a cluster from using the root user to a non-root user.
CB-36883, EA-19627: Search Threat Reports page

An issue on the Search Threat Reports page, in which a search for a domain criteria that included a ‘.’ in the domain, like vmware.com, would result in a failed search.
CB-37258: On the Process Analysis page, selection of a new process in the process tree could fail
CB-37434, EA-19968: Using /cbssl restore would fail if --no-encryption was used when creating a backup using cbssl backup
CB-37778, EA-20276: An instance was unable to fetch the correct license information

An instance was unable to fetch the correct license information and consequently the license would be processed as being expired, when in fact it was valid.
CB-37847: On the Investigations page, in which the text displayed for tagged fileless scriptload events with a large number characters could overflow

A fix for an issue on the Investigations page, in which the text displayed for tagged fileless scriptload events with a large number characters could overflow the page, making the event content difficult to read and potentially consuming the whole page.
CB-37954: cbcluster add-node and cbcluster change-node commands

An update to the cbcluster add-node and cbcluster change-node commands and the respective documentation to replace the objectionable term “master” with “primary”.
CB-37977: Incorrect data volume mount point

A fix for an issue, in which if the data volume mount point is incorrect and cbserver is started, an improper, confusing error message was returned. Now, a proper, more intuitive error message is returned.
CB-38089, CB-37634, CB-37633: Filemod, regmod, and fileless scriptload events

Filemod, regmod, and fileless scriptload events (the event types that can contain data with an embedded pipe “|” character) could fail to render properly in the UI.
CB-38111, EA-20372: Event Forwarder failed to forward specific event types in some cases, even when that event type was selected in the Event Forwarder configuration UI
CB-38213: Heads Up Display (HUD) Sensors widget

On the Heads Up Display (HUD) Sensors widget, listed sensors could accidentally have actions applied to them even when they are not being viewed. This was due to persistence of the checkbox selections when switching the Sensor Group selection.
CB-38367, EA-20554: When IPv6 is disabled, ReverseProxyIP is in IPv4 format only

An update to the VMware Carbon Black EDR Server Cluster Management Guide to clarify that when IPv6 is disabled, ReverseProxyIP is in IPv4 format only.
CB-38352, EA-20676: Entering a “%” in the query text entry field of the Create Watchlist pop-up would freeze the UI
CB-38377: Heads Up Display (HUD) Unresolved Alerts widget

An issue on the Heads Up Display (HUD) Unresolved Alerts widget view, in which marking one or more selected alert(s) with a resolution status would fail and result in a 500 error response.
CB-38473, EA-20514: A fix for an issue, in which queries for Fileless Scriptload > Command line contents did not support search using tokens (fragments of the command line contents)

Querying only supported exact matches with the full command line contents or searches using wildcards. Now, users can search for fragments of captured fileless scriptload command line contents.
CB-38523: There was limited ability to create or edit a Watchlist query containing an “=” symbol
CB-38695: When viewing a Sensor Group’s settings on the Sensors page, clicking on “Collapse all sections” would fail to collapse the Isolation Exclusions section

Known Issues

CB-39853: A change in Server 7.7.0 causes Event Forwarder to fail to start due to an authentication conflict between Carbon Black EDR Server and Event Forwarder

We are releasing a new version of Event Forwarder to resolve this issue as soon as possible.

In the meantime, the Carbon Black EDR team is applying a fix to Hosted Carbon Black EDR customer instances. On-prem Carbon Black EDR customers who encounter this issue should contact VMware Carbon Black Support.

See https://community.carbonblack.com/t5/Endpoint-Detection-and-Response/VMware-Carbon-Black-EDR-Event-Forwarder-Fails-to-Start-Following/td-p/113798 (on-prem Carbon Black EDR) or https://community.carbonblack.com/t5/Hosted-EDR-Discussions/VMware-Carbon-Black-Hosted-EDR-Event-Forwarder-Fails-to-Start/td-p/113796 (Hosted Carbon Black EDR) for more information.
CB-39854: Upgrade to Server 7.7.0 can fail if duplicate IP addresses exist in the nginx_approvedlist table (known as the nginx_whitelist table in pre-7.7.0 versions)

See https://community.carbonblack.com/t5/Endpoint-Detection-and-Response/VMware-Carbon-Black-EDR-Upgrade-to-Server-7-7-0-Fails-if/td-p/113801.
CB-39319: Migrating an RPM-based installation of EDR Server to a containerized installation of EDR Server

In Carbon Black EDR Server 7.7.0, after migrating an RPM-based installation of Carbon Black EDR Server to a containerized installation of Carbon Black EDR Server, the original, RPM-based installation can still be started. Starting the RPM-based installation while the containerized installation is active can result in interoperability issues.

We instruct customers to shutdown the original, RPM-based installation of Carbon Black EDR Server prior to migrating to the containerized installation of Carbon Black EDR Server; however, startup of the original, RPM-based installation should be prevented when a containerized installation is active.
CB-39412: Event Forwarder UI

In a containerized installation of Carbon Black EDR Server 7.7.0, the Event Forwarder UI is configured to control future releases of Event Forwarder, beginning with version 3.8.2.

Until Event Forwarder 3.8.2 is released, installed, and configured, Event Forwarder must be configured via the /etc/cb/integrations/cb-event-forwarder/cb-event-forwarder.conf configuration file.
CB-39746: URL in an email alert

The URL contained in an email alert is in the form of the hostname, not the fully qualified domain name (FQDN). Therefore, the URL may not successfully link to the alert in the Carbon Black EDR console for emails that are reviewed outside of a locally-resolving DNS zone.
CB-39320: cb-rabbitmq service fails to properly start

In Carbon Black EDR Server 7.7.0, the cb-rabbitmq service fails to properly start following the removal of a minion node from a cluster using the /edr-docker cluster remove-node operation.
CB-39786: In Carbon Black EDR Server 7.7.0, attempting a large, bulk resolution of Alerts can result in a timeout
CB-39497: In Carbon Black EDR Server 7.7.0, on the Investigations page, events of different types that occurred around the same time can be improperly overlaid instead of stacked
CB-39411: Yara Manager UI Configuration in Containerized Carbon Black EDR

Yara Manager UI configuration for the Yara connector does not work in Containerized Carbon Black EDR Server because Yara Manager code is not included in the Carbon Black EDR Server container image. The Yara Connector and Yara Manager will exist in their own container image, which does not yet exist as of the Server 7.7.0 release. Containerized Carbon Black EDR Server must be connected to containerized Yara Connector and Yara Manager (after they are released) for Yara Manager UI configuration to work.
CB-39413, EA-19397: In Carbon Black EDR Server 7.7.0, on the Binary Search page, the bars in the Host Count graph can appear improperly thin
CB-33355: In some cases, a process Watchlist will produce more hits than alerts

When a Watchlist query is executed using the original terms (e.g. process_name:notepad.exe), both the original segment (with events) and the tagged segment (without events) are returned, and both results appear on the Watchlists page. This makes it appear that there have been two hits, when in fact, there was only one. The result is two apparent hits, but only one alert, which is deceptive.
CB-39384: AD Integration feature, Carbon Black EDR Server queries group membership

In the AD Integration feature introduced in this release, Carbon Black EDR Server queries group membership using the “memberOf” attribute for integration with Active Directory and the “member” attribute for integration with LDAP. However, a different group membership attribute, “memberUid”, must be used for integration with OpenLDAP or FreeIPA.
CB-39347: Users are unable to connect to an AD server via LDAP using the default user, ‘cn’

In the AD Integration feature introduced in this release, users are unable to connect to an AD server via LDAP using the default user, ‘cn’. The leading ‘cn=’ is hard-coded, when it should be configurable.
CB-35669: In Carbon Black EDR Server 7.5.0 - 7.7.0, on the Triage Alerts Page, an invalid search with malformed syntax fails silently, without an error message

In previous versions, an invalid query would return an error message of “Malformed syntax in search query.” Via the API, a malformed query submitted on Server 7.5.0 or 7.5.1 returns a 500 error with no error message, whereas a malformed query submitted on previous versions returns a 400 error with the “Malformed syntax in search query.” error message.
CB-35668: In Carbon Black EDR Server 7.5.0 - 7.7.0, in the Configure Watchlist Expiration panel on the Watchlists page, a whole number must be entered for the watchlist expiration duration

In Carbon Black EDR Server 7.5.0 - 7.7.0, in the Configure Watchlist Expiration panel on the Watchlists page, a whole number must be entered for the watchlist expiration duration in order to save, even when the first option, “Do not mark watchlists as expired if they have no hits.” is selected. The configuration should successfully save when “Do not mark watchlists as expired if they have no hits.” is selected and the “Notify me when watchlists have not received hits in” value is blank.
CB-35335: In Carbon Black EDR Server 7.5.0 - 7.7.0, Live Query page

In Carbon Black EDR Server 7.5.0 - 7.7.0, a user with “No Access” to a particular sensor group will experience an infinite loading indicator on the Live Query page when they try to execute a Live Query that includes that sensor group.
CB-35148: In Carbon Black EDR Server 7.5.0 - 7.7.0, when using the GET /v3/{guid}/event API (or GET /v5/{guid}/event), submitted child process events of type "2" (other exec) do not properly store the process PID
CB-35139: In Carbon Black EDR Server 7.5.0 - 7.7.0, Binary Search searches can sometimes return zero results when there are matching results that should be returned
CB-31662: Watchlist query in the Create Watchlist modal does not properly wrap text if the text starts with “-”

When creating a Watchlist, the Watchlist query in the Create Watchlist modal does not properly wrap text if the text starts with “-”. The “-” creates a line break; thus, the subsequent text is displayed on the following line. This is an issue on Google Chrome/Chromium.
CB-37654: Query Requires Double Quotation Marks

In Server 7.6.0, on the Process Search page, a process query built with Add search terms > Choose criteria > Fileless > Command line contents > [Insert text] only returns the proper results if the user encloses the query in double quotation marks (““ ””).
CB-33586: Red dot does not display

In Server 7.5.0, on the Process Search page, a process that has a Threat Intelligence Feed hit tag in one segment may not display the feed hit icon (a red dot) when “Group by process” is selected.
CB-35139: Binary Search searches sometimes return zero results

In Server 7.5.0, Binary Search searches can sometimes return zero results when there are matching results that should be returned.
CB-35147: Submitted child process events of type "2" (other exec) do not properly store the process PID

In Server 7.5.0, when using the GET /v3/{guid}/event API (or GET /v5/{guid}/event), submitted child process events of type "2" (other exec) do not properly store the process PID
CB-35148: Process information not properly returned

In Server 7.5.0, when using the GET/v1/process/{guid}/{segmentid}/preview API, process information is not properly returned.
CB-35335: A user with “No Access” to a particular sensor group will experience an infinite loading indicator on the Live Query page

In Server 7.5.0, a user with “No Access” to a particular sensor group will experience an infinite loading indicator on the Live Query page when they try to execute a Live Query that includes that sensor group.
CB-35668: In the Configure Watchlist Expiration panel on the Watchlists page, a whole number must be entered to save

In Server 7.5.0, in the Configure Watchlist Expiration panel on the Watchlists page, a whole number must be entered for the watchlist expiration duration in order to save, even when the first option, “Do not mark watchlists as expired if they have no hits.” is selected. The configuration should successfully save when “Do not mark watchlists as expired if they have no hits.” is selected and the “Notify me when watchlists have not received hits in” value is blank.
CB-33352: cb-enterprise fails to install on RHEL/CentOS 8 with FIPS 140-2 enabled

This issue is due to a change in Red Hat 8 that affected Paramiko (https://bugzilla.redhat.com/show_bug.cgi?id=1778939).

Use RHEL/CentOS 7 if you enable FIPS 140-2.
CB-31136: Live Query fails to take the SensorInactiveFilterDays setting into account

Live Query fails to take the SensorInactiveFilterDays setting into account when determining which sensors to target. The sensor count on the right side of the ‘Current query’ bar shows all targeted sensors, while the quantity of targeted sensors in the ‘Run New Query’ pop-up does account for SensorInactiveFilterDays, and will sometimes show a lower number.
CB-24519: Older files did not get SHA-256 values

After an upgrade of server and sensor, older files did not get SHA-256 values. When an older file is executed, it creates a process event that contains SHA-256. When a user clicks the link, the binary store shows no SHA-256.
CB-20565: Cannot enable or disable Alliance Sharing

When using a custom email server, you cannot enable or disable Alliance Sharing.

Disable the custom email server, make the change, and re-enable the custom email server.
CB-18936: Malformed CSV Export

The CSV export of the user activity audit is malformed in certain cases.
CB-18927: The CSV export of Recently Observed Hosts has no header row.
CB-37645: Process Analysis page can present fileless_scriptload events with corrupted fileless_scriptload_cmdline content

Large (>64KB) scripts in Windows Sensor 7.2.0 - 7.2.2 can be reported incorrectly, which causes corrupted fileless_scriptload_cmdline data to be sent to the Carbon Black EDR Server. The bug is fixed in Windows Sensor 7.3.0 [CB-37282].The result of this bug is that the Process Analysis page can present fileless_scriptload events with corrupted fileless_scriptload_cmdline content. In this case, the corrupted content is replaced with the error message, “<Corrupt command line data found>”.
CB-35669: On the Triage Alerts Page, an invalid search with malformed syntax fails silently, without an error message

In Server 7.5.0 - 7.6.2, on the Triage Alerts Page, an invalid search with malformed syntax fails silently, without an error message. In previous versions, an invalid query would return an error message of “Malformed syntax in search query.” Via the API, a malformed query submitted on Server 7.5.0 or 7.5.1 returns a 500 error with no error message, whereas a malformed query submitted on previous versions returns a 400 error with the “Malformed syntax in search query.” error message.

Contacting Support

VMware Carbon Black EDR server and sensor update releases are covered under the Carbon Black Customer Maintenance Agreement. Technical Support can assist with any issues that might develop. Our Professional Services organization is also available to help ensure a smooth and efficient upgrade or installation.

Use one of the following channels to request support or ask support questions:

Web:User Exchange
Email: [email protected]
Phone: 877.248.9098

Reporting Problems

When contacting Carbon Black Technical Support, provide the following required information:

Contact: Your name, company name, telephone number, and email address
Product version: Product name (VMware Carbon Black EDR server and sensor versions)
Hardware configuration: Hardware configuration of the VMware Carbon Black EDR server (processor, memory, and RAM)
Document version: For documentation issues, specify the version and/or date of the manual or document you are using
Problem: Action causing the problem, the error message returned, and event log output (as appropriate)
Problem Severity: Critical, serious, minor, or enhancement request

Note: Before performing an upgrade, Carbon Black recommends you review the related content on the User Exchange and the release documentation location, the Carbon Black EDR section of docs.vmware.com.