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.
