Carbon Black Cloud Windows Sensor Release Notes

Carbon Black Cloud Windows Sensor Release Notes

3.7.0.1503

This release updates osqueryi.exe to version 4.8.0, and includes bug fixes and improvements.


3.7.0.1411

This release updates osqueryi.exe to version 4.7.0, and includes bug fixes and improvements.


3.7.0.1253

Sensor Installer Rollback

Build-to-build, version-to-version upgrade rollback is now fully supported when upgrading from version 3.7 and later sensors. The following table describes rollbacks that various Carbon Black Cloud sensor versions support. rollbacks.png

For more details about rollback functionality, see the VMware Carbon Black Cloud Sensor Installation Guide.

Enterprise EDR Hash Banning

This feature provides Enterprise EDR users with the ability to ban files by hash, thus preventing files from:

  • Being opened with execute access
  • Starting a process from a file
  • Being loaded as a module in a process
  • Being loaded as a script
  • Being loaded as a driver

For more details, see https://community.carbonblack.com/t5/Enterprise-EDR-Discussions/Announcing-Hash-Banning-for-Enterpri...

Ransomware Boot Record Protection

A new disk driver (cbdisk.sys) helps protect against the most dangerous types of ransomware that attempt to corrupt the boot record of an endpoint. This type of ransomware encrypts files and alters the master boot record (MBR) and partition boot record (PBR), rendering the device unusable.

Important Note: A reboot is required after install/upgrade/cloning a golden VM image to fully leverage our ransomware protection capabilities. This new disk driver should be added to any previously set AV exclusions.

SHA-2 Windows Updates Required for Continued Support of Windows 7 and Windows Server 2008 R2

Microsoft no longer allows code-signing using SHA1. To continue running VMware Carbon Black Cloud Windows sensor version 3.7+, the KB4474419 patch should be applied to applicable operating systems. Our Carbon Black Cloud sensor - OS Support article on UEX reflects this change.

Automatic re-registration of VMware Carbon Black Cloud Windows sensors in Citrix PVS environments

The 3.7 Windows sensor supports a new cfg.ini parameter AutoReRegisterForCitrix = True for automatically re-registering Windows sensor on VDI clones in Citrix PVS environments.


3.6.0.2127

SHA-2 Windows Updates Required for Continued Support of Windows 7 and Windows Server 2008 R2

Microsoft is no longer allowing code signing using SHA1. To continue running our latest Carbon Black Cloud Windows 3.6 sensor version (3.6.0.2127+), the KB4474419 patch should be applied to applicable operating systems. Our Carbon Black Cloud sensor - OS Support article on UEX has been updated to reflect this change.


3.6.0.2076

This updated Windows sensor version includes fixes and performance improvements.


3.6.0.1979

This updated Windows sensor version includes fixes and performance improvements.


3.6.0.1941

osquery version update 4.5.1

This updated Windows sensor includes the most recent version of osquery (4.5.1). See the Carbon Black Cloud Sensor Support for osquery document for a full list of sensor versions and supported schema versions.


3.6.0.1897 (This sensor is no longer available for download)

osquery version update 4.5.0

This updated Windows sensor includes the most recent version of osquery (4.5.0). See the Carbon Black Cloud Sensor Support for osquery document for a full breakdown of sensor versions and supported schema versions.

This update lets you query the Windows event log. Users can now craft custom queries or use new out-of-the-box queries from our Threat Analysis Unit to pull back artifacts from Windows event logs on demand. These artifacts include event ID, the time an event occurred, the source or channel of the event, the provider name and guid associated with an event, the severity level of an event, and more.

This version also includes Windows support for the yara table and no longer requires an on-disk signature to be present.


3.6

VMware Carbon Black Cloud sensor version 3.6 is for Windows only. See supported operating systems on the UEX: Carbon Black Cloud sensor support.

osquery 4.4.0

The 3.6 Windows sensor introduces osquery version 4.4.0. Learn more about version 4.4.0 here: https://github.com/osquery/osquery/releases/tag/4.4.0

Firewall exclusion

The 3.6 Windows sensor leverages a content management system to enable the dynamic configuration of prevention features. Prior to installing or upgrading to 3.6, if you have restrictive firewall policies active in your environment, you might need to add a new firewall/proxy exclusion for the sensor to be fully functional.

Add a new network/proxy exclusion for a direct connection over TCP/443 to https://content.carbonblack.io 

Enterprise EDR, AMSI Prevention, and Unified Binary Store require the exclusion to work with the 3.6 sensor. 

To learn more about the sensor communication requirements, see Carbon Black Cloud: What Ports must be opened on the Firewall and Proxy Servers? 

Sensor install/uninstall improvements

With the Carbon Black Cloud Windows 3.6 sensor, the install and uninstall experience is strengthened on the endpoint. If a failure occurs during an initial install of the product or during an uninstall, the endpoint will be returned to the state it was in prior to the attempt. 

To learn more about Windows sensor installation and uninstallation, see the Sensor Install Guide on the UEX or in your VMware Carbon Black Cloud Console under the Help menu in the top bar

AMSI Prevention and visibility (Endpoint Standard) 

VMware Carbon Black Cloud has extended its default prevention capabilities for script-based Windows attacks, built on Microsoft Anti-Malware Scan Interface (AMSI). This extension of the AMSI integration expands on existing PowerShell preventions with improved ease of use and a better security posture. 

This release includes the ability for the sensor to dynamically leverage AMSI metadata to define and configure prevention logic. These updated, high-fidelity prevention rules are being crafted by VMware Carbon Black’s Threat Analysis Unit to include frequently used off-the-shelf attacker frameworks that are regularly seen in script-based attacks.

AMSI prevention and visibility is only supported on Windows 10 and greater and requires sensor version 3.6+. AMSI prevention and visibility will be rolled out in a staggered manner to customers. No action is required by the customer. 

Sensors that are registered with the following backend instances can use the functionality on the listed date.

URL 

Date 

https://dashboard.confer.net 

8/31 

https://defense.conferdeploy.net/ 

8/31 

https://defense-eu.conferdeploy.net 

9/7 

https://defense-prodnrt.conferdeploy.net/ 

9/7 

https://defense-prod05.conferdeploy.net 

9/14 

 

Sensor logs locations

Previous versions of the sensor stored logs in the \Program Files\Confer\Logs\ directory. 

The Windows 3.6 sensor stores some logs in Program Files and some logs in ProgramData: 

  • \Program Files\Confer\Logs\ 
  • \ProgramData\CarbonBlack\Logs\

Throughout 3.6 maintenance releases, we will move all logs to ProgramData to better align with Microsoft guidelines.

VDI improvements

The VDI workflow is improved with the Windows 3.6 sensor. Re-registering is less restrictive and easier. VDI clones and re-registered devices inherit the policy of the primary image if one exists. Otherwise, clones and re-registered devices are assigned the Virtual Desktop policy or the Standard policy in that order. Additionally, if an organization is using sensor groupsthe new device will be moved to the appropriate policy when the metadata matches. See the Sensor Installation Guide for full VDI considerations and see the in-product User Guide for more information about sensor groups.  

 


 

3.5

VMware Carbon Black Cloud sensor version 3.5 is for Windows only. This release is Generally
Available.

Notes:

 

Disable services associated with malware

Malicious services that run at start-up have the potential to execute and impact the endpoint
before the sensor starts up. A new feature finds all malicious services associated with Known
Malware hashes and puts them in a disabled state. The services remain in disabled state across
reboots, and therefore cannot execute at startup. If a service binary in question was not
malicious or if some other tool is used to clean the malware, then the sensor will not
automatically enable the service again. To re-enable the service you must manually do so by
using LiveResponse or other standard tools. The feature is enabled by default and can be
disabled by a request to Support.

The command for the remediation through CB LiveResponse is:

  1. Query the service start type exec: execfg sc.exe qc <servicename>
  2. Change the start type using the command: execfg sc.exe config
    <servicename> start=<starttype>

The possible start types are: boot | system | auto | demand | disabled | delayed-auto

The event that is sent during the service disable contains the original start type and displays in
the user interface. The user needs this data to return the start type to its original value. If the
start type changes to boot, auto or delayed-auto, they must reboot.

Removal of registry keys during deletion

Deletion of files, both manual and through the Malware Removal workflow, previously did not
attempt to remove registry keys that were created by the malware. When requested to delete a
file, the Windows 3.5 sensor also removes RunOnce registry keys from the HKLM hive that reference the malicious binary that is being deleted. Other auto-start registry keys referencing the malware might remain.

Offline installer

The Windows 3.5 sensor supports offline installs to support machines that are configured in an offline environment. The feature is enabled during a command line installation by adding the flag “OFFLINE_INSTALL=1”. The sensor connects with the Carbon Black Cloud backend and accesses a policy when network connectivity is restored. The sensor does not provide any visibility or protection until it is connected to the backend.

To use the feature, ensure that there is a host or network level firewall rule in place to prevent the master image from connecting to the Carbon Black Cloud devices URL. Then, Install the sensor using the OFFLINE_INSTALL parameter and any other parameter that is typically used during a command line install (aside from PROXY). Clone or restore to snapshot. Each snapshot and clone appears as a new device in the backend console and are not treated as a VDI clone unless you explicitly install with VDI=1 or used the repCLI reregister command. Otherwise, console admins are responsible for cleaning up old clones, either manually or via API.

Note: If a user changes the company code in the backend, you can no longer make new clones that haven’t registered yet because those clones will continue to try to use the original company code. If you change the company code, you must create new images using the new company code.

Endpoint management improvements

The Windows 3.5 sensor effectively handles non-persistent domain disconnections. Previously, the sensor applied the default policy when the AD attribute was cleared (in instances such as off-network without VPN). Now, the sensor maintains the desired AD group and the desired policy. The distinguished name is not cleared unless the machine is not registered as part of the domain.

In the Endpoints page, the Windows 3.5 sensor reports who is logged into an endpoint every 8 hours instead of reporting the user who installed the sensor. If there is no interactive user logged in to the endpoint within the 8 hour window, you might get a non-interactive user name such as “Windows Manager\DWM-2”. In the case of multiple logged-in users, the most recently logged-in user is associated with the endpoint.

Improved capability to identify command interpreters

CB Defense has improved its methods for identifying a process as a command interpreter or as
a script host. By integrating with the yara binary pattern matching utility, the Windows 3.5 sensor
better protects against threats where an attacker brings their own copy of standard operating
system interpreters or tries to hide by running tools with non-standard names. Customers who
are already leveraging the Tries to invoke command interpreter rule immediately benefit from
this update.

As part of this update, Carbon Black’s Threat Analysis Unit (TAU) can dynamically update the
definition of what it means to be a command interpreter.

Improved Netconn detection for proxy servers

With the Windows 3.4 sensor, CB ThreatHunter customers who are using a proxy server in their
environment saw most (all) outbound network connections being reported with the proxy's address and host name as the destination. The Windows 3.5 sensor improves reporting of network events to report the actual destination IP and hostname, rather than those of the intermediate proxy.

Note: This functionality is enabled in the Windows 3.5 sensor, but will not be available for use until a future Carbon Black Cloud console release.

CB ThreatHunter hash blacklisting

The Windows 3.5 sensor enables blacklisting of files by hash for CB ThreatHunter. Once a hash is added to the company blacklist it is prevented from the following:

  • Being opened with execute access
  • Starting a process from a file
  • Being loaded as a module in a process
  • Being loaded as a script

Processes that have the blacklisted hash loaded at the time the hash is added to the blacklist are
terminated shortly after the sensor receives the updated reputation.

Note: This functionality is enabled in the Windows 3.5 sensor, but will not be available for use until a future Carbon Black Cloud console release.

Dynamic tamper protection

The Windows 3.5 sensor has improved methods for identifying tamper events. The improvements help prevent access to sensor files and reduce interoperability issues with third-party products.

AMSI logging

The Windows 3.5 sensor enables the collection of deobfuscated command line data through AMSI for CB ThreatHunter customers. For more information on AMSI, see https://docs.microsoft.com/en-us/windows/win32/amsi/antimalware-scan-interface-portal.

In the cloud console, this integration will manifest in the form of filess_scriptload events, which represents processes that executed commands in fileless execution context. More information will be provided in the backend release notes for the February 18th UI release.

Updated 09/02/2020:

Sensor check-in time update

The sensor check in time is reduced from 5 minutes to 1 minute. The maximum expected latency for establishing a Live Response session should now be 60 seconds (assuming the device is online and running a 3.5 or newer sensor version). Other operations might also complete faster.
The Last check in value in the console will not necessarily update faster because of performance/scale reasons.

Comments

Windows sensor release notes for sensor version 3.6.0.1941 are published.

Windows sensor release notes for sensor version 3.6.0.2076 are published.

Windows sensor release notes for sensor version 3.7.0.1253 are published.

Windows 3.7 sensor release notes are published for GA.

Windows sensor 3.6.0.2076 maintenance release notes are published.

Windows sensor 3.7.0.1411 release notes are published.

Windows sensor 3.7.0.1503 release notes are published.

Article Information
Author:
Creation Date:
‎02-04-2020
Views:
1604
Contributors