Just Published! Threat Report: Exposing Malware in Linux-Based Multi-Cloud Environments | Download Now

Discrepancy between Carbon Black Response and Signature Status

Discrepancy between Carbon Black Response and Signature Status

Version

This solution applies to all Carbon Black Response versions.


Issue

A discrepancy between the signature status of a particular binary in the Carbon Black UI and what was previously reported for the same binary.

Symptoms

For example the Carbon Black Binary Analysis page may show a binary's signature status as Unsigned, meanwhile an external service shows that the binary is in fact Signed with a Publisher present. The following will be present in the %WINDIR%\CarbonBlack\Sensor.log:

2015-02-20 23:34:06: cb_event_converter.cpp(3679): Call 'hr = _HandleFileScanResult(ev, fGenerateModuleInfoEvents, out_messages)' Failed --> 0x80070057

Similarly the Microsoft Windows CAPI Operational Event Viewer logs may show a "WinVerifyTrust" or "TRUST_NO_E_SIGNATURE" error message, as the Sensor relies on this Windows API for obtaining the signature.


Cause
The issue resides on the Windows endpoint and a possible outdated or missing Windows catalog file. For example a single host observes a binary and properly collects the signature status. When that exact same binary is observed on another host, the Carbon Black Binary Solr document is overwritten with the signature status that was obtained on the most recent host to observe the binary. If the latest Windows host to observe this binary experienced a problem and reports, for example an Unsigned status, the binary Signature Status will be updated in Carbon Black to be "Unsigned".

Solution

None - while misleading the Sensor is functioning as designed. The issue is with the Windows endpoint. Suggest investigating the endpoint in question to ensure the Microsoft catalog file is accurate and recent.

Labels (1)
Was this article helpful? Yes No
No ratings
Article Information
Author:
Creation Date:
‎05-11-2015
Views:
1136
Contributors