In this release, the Endpoints page has several improvements. You can now reorder sensor groups in bulk, making it easier and faster to determine which groups are evaluated first. Deleting a sensor group is faster because each row has a delete button that is shown on hover. Hovering over an endpoint’s policy now shows a description of the policy.
Fixed in this release
Fixed: alerts not loading on refresh for some organizations.
TTPs for notifications are updated.
REST API query result discrepancies remediated in Status key/field.
Device Export was including deleted devices, which caused exports to fail in some cases. Deleted devices are now removed from device exports.
Deregistered devices were not being auto-deleted.
Devices only show the status of Eligible for Upgrade if the sensor version is lower than any version that is available in Endpoints > Download Sensor Kits.
Additional HTML can be included in the SIEM event connector.
In some cases, uninstalling a sensor from the console does not trigger an uninstall on the sensor.
Incorrect API URLs are displayed in the console.
An additional alert notification is sent to SIEM or API connectors when an alert is dismissed.
In rare instances, the page renders as a gray screen.
If a backend org is deregistered, sensors might not be automatically uninstalled. It is always recommended to make note of uninstall codes if they are required for uninstall.
CB Defense alerts in a CB ThreatHunter-enabled organization improperly map script loads as process creation.
Creating a connector with a similar name causes a creation failure. To work around this, make sure that any text before a space is unique for connectors.
The Alerts / Notifications API does not include the CB ThreatHunter investigate URL, which makes breaks these links.
Detection analytics improvements
In a continued effort to improve detection analytics, enhanced detection capabilities, and false positive reductions, fixes have been added. In this release, we focus primarily on attacks that leverage native Windows applications to perform malicious activity. Additionally, we focus on reducing high-impact false positives that are related to code injection and port scanning activities. You should see improved detection capability in the Alerts page.
See the following list of improvements:
CMSTP User Account Control Bypass
Improved detection of attackers that leverage CMSTP, a native-signed Windows application that manages network connections,escalates user privileges, and executes malicious activity.
Netsh Modifying Local Windows Firewall
Improved detection of attackers that leverage netsh, a native-signed signed Windows application that configures network services and modifies or disables the local Windows firewall.
Certutil Suspicious Behavior
Improved detection of attackers that leverage certutil, a native-signed Windows application that displays and modifies certificate information to perform malicious activity such as encoding/decoding other files and dropping unknown dll files to the disk.
Mshta Executing Suspicious Scripts
Eliminated False Positive alerts that were related to an uncompromised Microsoft process that triggered ransomware-related alerts.
Eliminated False Positive alerts that were related to an uncompromised multimedia application that triggered ransomware-related alerts.
Eliminated False Positive alerts that were related to an uncompromised Microsoft process that modified the Windows Explorer process.
Improved the metadata layout on the Investigate page
We reorganized the metadata and additional information so that you can find data more quickly.
Fixed in this release
Older sensors could receive a poorly formatted reputation DB, causing unexpected blocks. This is prevented on newer sensors, and this fix mitigates it for older sensors.
When searching for Threat Category: Malware on the CB Defense Alerts page, results can include non-malware results.
If no sensor detail message is entered on a policy, the sensor might display false in the sensor UI.
After whitelisting a file, reputation on the main Investigate page properly shows WHITE_LISTED while the Application tab incorrectly shows NOT_LISTED.
While the sensor will prevent the deletion, the console still allows the user to send a delete request for PSC sensor files.
When dismissing an alert, if a reason is specified, the alert dismissal might fail.
The Reputation filter on the Alerts page does not display any filter options.
When a policy rule is created for Unknown reputation files, these rules are incorrectly applying to NOT_LISTED applications. Due to the nature of UNKNOWN reputation being very transient, we recommend using both NOT_LISTED and UNKNOWN rules and having them match.
Changes to the auto-blacklist feature are not logged in the audit log.
When a hash is auto-blacklisted, an audit log entry is not added.
When exporting from the server dashboard, dismissed alerts are not exported when the Include dismissed alerts filter is enabled.
The Tags filter on the Alerts page does not populate with entered tags.
Exporting data from the PSC Dashboard can lead to timeouts when a large amount of data is exported.
Enhanced Watchlist Investigate Experience
To see the full set of processes that hit (or could have hit) on a Watchlist, clicking the Investigate button on the Watchlist details page previously took you to the Investigate page to show all search results that matched the Watchlist for all time. There was no explanation that this search experience was in the context of the Watchlist that you were just examining.
With this release, we have customized the experience of searching for all (or potential) hits for a Watchlist. Now, when you click the Investigate button on the Watchlists page, the PSC provides you with the following:
New context-specific header that includes the name of the Watchlist to reinforce that this is a Watchlist-specific customized search experience.
Toggle to enable or disable alerts for the current Watchlist.
Take Action menu to let you edit, disable or unsubscribe from the Watchlist.
June 10, 2019 release
Enhanced Watchlist Hits is more visible in Investigate page
Watchlist Hits are better integrated into the Investigate page search results.
Prior to this change, all search results for a process that had one or more Watchlist hits (thereby indicating that the process had one or more events that matched criteria on one or more subscribed Watchlists), included a red square that included the highest severity of any matching Watchlist Report:
A new orange ! icon indicates that there is at least one Watchlist hit for any process:
Click the orange ! icon to summarize the relevant findings:
Severity score for the latest hit.
Name of the Report in which the hit was found.
The query on which the hit occurred.
Time of the occurrence of the event, which was captured as a Watchlist hit.
A link that allows you to search for all Watchlist hits for this specific process (search by Process GUID which is a globally unique version of the Process ID):
Fixed in this release
Facets did not update when you navigated away from the Investigate page and then returned.
When user deleted a custom Watchlist from enabled Watchlists page, the Results section of page reported No watchlists enabled.
The progress bar on the events table on the Process Analysis page got stuck in an endless loop after the user browsed several parents up the tree.
ThreatHunter searches using the Process Search API that send parameter data with a wrong data type caused a 502 Bad Gateway error.
In the Add Query to Watchlist feature on Investigate page, when you selected the Include historical data checkbox, an Error while creating IOC message displayed, but the Watchlist was created.
Report Search on Watchlists page returned a 500 error when querying for more than 10,000 reports.
The process tree sometimes showed only one node on the Process Analysis page.
Search bar query was ignored when a user selected a filter on the Investigate page.
The First seen as field on the Binary Details page (and from the API) does not return paths in prevalence order; therefore, it is not possible to guarantee the actual first seen instance.
Text remains in Investigate Search Bar if user navigates away and uses navigation Investigate option return to the Investigate page.
Hovering the mouse on a Investigate search filter hides the percentage values.
After you deselect a selected filter on the Investigate page, an otherwise-empty search still displays search results.
Count of devices with hash on the Process Analysis page is different from count of devices on the Investigate page.
When user types - or + and then accepts a suggested search field name, the + or - character is removed from the search bar on the Investigate page.
ThreatHunter Watchlist tags do not show up on the Notes/Tags tab of the Alerts page — these are a different type of tag data.
Binary Details page crashes when UBS APIs return unexpected output.
The User Guide is missing from the Help menu for organizations that subscribe to CB ThreatHunter.
No field descriptions/examples in many suggestions for search fields on Process Analysis page.
When you search for Reports for a new Watchlist, you cannot access or add a Report that was returned by the search.
For processes that have a very large number of events, the Process Analysis page for that process can be manually reloaded to load additional events until the query is completed in the background.
Watchlist link still showing on Process Analysis page side panel after Watchlist is deleted.
If CB Defense is enabled on the PSC with WSC integration enabled, and you remove CB Defense, the WSC integration is not disabled.
When Investigate search bar overflows to multiple lines, user cannot use keyboard navigation or selection.
Searching by device_internal_ip returns no results for CBTH-native events on the Investigate page.
Rule Preview links show inconsistent result counts when you use wildcards on the Policies page.
More Watchlist Notification emails sent than number of Watchlist Hits or Alerts.
"process_publisher" searches on the Investigate page lead to signed and unsigned binaries.
Result count drops and rises when changing filters or terms on Investigate search.
When user deletes the last Report in an enabled Watchlist, the Reports tab on Watchlists page shows all available reports instead of No Reports for this Watchlist.
Report Search on Watchlists page allows user to submit search when Search Bar is empty.
On the Watchlists page, the backspace key does not behave as expected to edit a Watchlist name or description.
In the Update Watchlist API, an empty Name field is allowed.
In the Create New Report API, the API responds with 500 error if a negative timestamp is submitted.
The device_policy field is not always populated in API data or Investigate filters.
The Clear search feature on the Investigate page does not clear selected filters.
Carbon Black, Inc. | 1100 Winter Street, Waltham, MA 02451 ?USA | Tel: 617.393.7400