This site will be decommissioned on January 30th 2025. After that date content will be available at techdocs.broadcom.com.

 

VMware Carbon Black EDR Server 7.6.2 | 02 MAR 2022 | Build 7.6.2.220314

Check for additions and updates to these release notes.

What's New

Important: A version of Server 7.6.2 that was not intended for general availability was accidentally released to on-prem customers on Tuesday, 8 March 2022. This version contains a bug that can result in a failure to store collected process events. The bug is fixed in the official GA version, released on 16 March 2022. If you installed Server 7.6.2 prior to 16 March, please upgrade to the latest version immediately!

VMware Carbon Black EDR 7.6.2 is a maintenance release of the VMware Carbon Black EDR server and console. This release delivers bug fixes, security enhancements, and support of RHEL 8.5.

  • Components Included in this Release

    Each release of VMware Carbon Black EDR software is cumulative and includes changes and fixes from all previous releases.

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.6.2:

  • VMware Carbon Black EDR 7.6 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.6 Server / Cluster Management Guide: Describes installation, configuration, and upgrade of Carbon Black EDR servers.
  • VMware Carbon Black EDR 7.6 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.

[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.6 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”.

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.6 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.6.2 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.6.2-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.6.2-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 VMware 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.

[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.6 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 7.6 Operating Environment Requirements document before proceeding.

Server / Console Operating Systems

For best performance, Carbon Black recommends running the latest supported software versions:

  • CentOS 6.7 - 6.10 (64-bit)
  • CentOS 7.3 - 7.9 (64-bit)
  • CentOS 8.1 - 8.4 (64-bit)
  • Red Hat Enterprise Linux (RHEL) 6.7 - 6.10 (64-bit)
  • Red Hat Enterprise Linux (RHEL) 7.3 - 7.9 (64-bit)
  • Red Hat Enterprise Linux (RHEL) 8.1 - 8.5 (64-bit)

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.

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

  • CentOS 6.7 - 6.10 (64-bit)
  • CentOS 7.5 - 7.9 (64-bit)
  • CentOS 8.2 - 8.4 (64-bit)
  • Red Hat Enterprise Linux (RHEL) 6.7 - 6.10 (64-bit)
  • Red Hat Enterprise Linux (RHEL) 7.5 - 7.9 (64-bit)
  • Red Hat Enterprise Linux (RHEL) 8.2 - 8.5 (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.

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.6.2 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.6 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 7.6 Sensor Installation Guide.

Third-Party Software Updates

  1. Apache Log4J: 2.17.0 → 2.17.1
  2. Apache Solr: 8.11.0 → 8.11.1
  3. Marked.js: 2.0.6 → 4.0.12
  4. PostgreSQL JDBC: 42.2.23 → 42.3.2

Resolved Issues

  • CB-38345: In Server 7.6.0 and 7.6.1, some Threat Intelligence Feeds failed to render properly.

  • CB-38090: The Carbon Black EDR Sensor was unable to check-in and/or register under certain rare conditions

  • CB-38081: Process Search

    A Process Search that contained an empty space due to the copying of a carriage return character or other non-printable unicode character would return zero results.

  • CB-38080: In Server 7.6.0 and 7.6.1, DatastoreEnableSensorPriority would crash if the sensor backlog exceeded 2GB

  • CB-37866: Hosted EDR customers with clustered EDR Server nodes

    In Server 7.6.0 and 7.6.1, the /api/approvedlist/apply call to apply an approvedlisted value to a minion did not work for Hosted EDR customers with clustered EDR Server nodes.

  • CB-37846: Process Analysis Page

    In Server 7.6.0 and 7.6.1, on the Process Analysis page, the count presented as “_ computer(s) have seen this in _ processes:” would always display, “0 computer(s) have seen this in 0 processes:”, even when, in fact, the count is greater than 0.

  • CB-37811: In previous versions, the upgrade of EDR Server could lead to the creation of duplicate Solr writer cores

  • CB-37809: CSV export of a Sensors list

    In Server 7.6.0 and 7.6.1, the CSV export of a Sensors list did not work properly if there were >1,000 sensors selected. In this case, a JSON file was downloaded instead and an error was indicated.

  • CB-37715: In Server 7.6.0 and 7.6.1, datagrid could time-out during startup, causing startup to fail

  • CB-37654: In Server 7.6.0 and 7.6.1, the error message presented as a result of an invalid process query could be inaccurate

  • CB-37584: Add-node command failed due to a missing redis certificate

    If a cluster of EDR Server nodes was installed prior to Server 7.5.1 and then the customer upgrades to Server 7.5.1 or 7.5.2, the add-node command fails due to a missing redis certificate. New 7.5.1 or 7.5.2 server clusters would not encounter this issue because cbinit creates the redis certificate.

  • CB-37555: In Server 7.5.0 - 7.6.1, on the Process Analysis page, the MD5 hash for a filemod action that modifies a file signature does not appear in the console

  • CB-37475: In Server 7.5.0 - 7.6.1, on the Process Analysis page, filemod “Last wrote to” events do not appear in the console when they should

  • CB-37416: invalid and empty Indicator of Compromise (IOC) queries could be added as a Threat Intelligence Feed Report IOC query

    Invalid and empty Indicator of Compromise (IOC) queries could be added as a Threat Intelligence Feed Report IOC query, which could result in data ingestion issues. This issue is resolved in Server 7.6.2: IOC queries must contain appropriately structured values, and if not, an attempt to add an improperly structured IOC query will result in an error.

  • CB-37338: Negation of multiple terms that appear in both cbevents and cbmodules cores returned invalid data

  • CB-37204: Some sensor facet queries produced results that could not be converted to JSON

  • CB-37185: Cbcluster add-node command did not support offline cached installations of EDR

    The cbcluster add-node command did not support offline cached installations of EDR. Add-node assumes EDR pulls cb-enterprise and rsync from their repositories, not from cached files on the system. Server 7.6.2 supports offline, cached installations of the product.

  • CB-37148: Sensor upgrades could fail following a server migration

  • CB-36821: Specifying an IP address in a Process Search query

    In Server 7.6.0 and 7.6.1, when specifying an IP address in a Process Search query, where one of the quads contains non-octal values but has a leading 0 (i.e. "ipaddr:127.33.44.0209"), the resulting call returns a 500 error response. In Server 7.6.2 - a leading 0 in a non-octal IPv4 quad now results in a 400 error response.

  • CB-36374: In Server 7.5.0 - 7.6.1, the Yara Manager icon did not display properly in the left-hand navigation panel when enabled on a Hosted EDR instance

  • CB-32829: Netconn_count range searches could produce inconsistent results

  • CB-27046: Watchlist notifications could be delayed.

    Watchlist notifications are now sent as they are collected, rather than in batches all at once.

  • CB-38518: EDR Server stopped processing some events after submit

Known Issues

  • 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-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:

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.

check-circle-line exclamation-circle-line close-line
Scroll to top icon