About Integrity Failures and Device Tampering
The Eclypsium interface tracks three methods of potential device tampering: known implant, unknown binary/integrity failure, and baseline anomalies. This article explains each method in detail and provides guidance on locating this information within the platform.
Known Implant
When a system scan detects indicators of compromise caused by a known implant, the dashboard will display the alert as "Implant(s) Detected".
Click on the red number above "Implant(s) Detected" to view the complete list of devices with known implants.
Unknown Binary / Integrity Failure
An Integrity Failure identifies firmware components that are unrecognized by Eclypsium, which may indicate potential tampering. To investigate, navigate to the specific device's details and expand the Integrity Status section.
Unknown Binaries
A system containing firmware binaries that are not included in the Eclypsium vendor-sourced whitelist will display Unknown Binaries.
A system with unknown binaries may potentially contain an unknown implant, but it could also be innocuous. This situation can arise in the following cases:
- The system is from a low-volume manufacturer.
- The vendor is not regularly monitored by Eclypsium.
- The firmware is still under evaluation by Eclypsium.
To reduce false positives, you can enable the High Confidence Mode configuration option under Settings > Reputation.
If the firmware is a known-good version included in Eclypsium's whitelist, please submit the result to Eclypsium for further research.
Binaries Failed Analysis
In conjunction with an Unknown Binary, you may encounter the Failed Analysis status. This indicates that the binary, even if hidden under High Confidence Mode, has been flagged as suspicious by the Eclypsium platform’s heuristic and static analysis.
Examples of suspicious behavior include:
- A UEFI firmware binary containing an NTFS file system driver (which is considered out-of-spec for UEFI).
- The presence of other code deemed suspicious.
Baseline Deviation
The last category, Baseline deviation, is the strictest of the three. Baseline deviations occur when a system with an established baseline in the Eclypsium interface experiences changes to one or more firmware components or settings. These changes might be due to:
- A user applying a vendor-original firmware update.
- Adjustments to firmware-related settings (e.g., disabling firmware write protection) without any firmware component or version change.
While such deviations may not directly indicate the presence of an implant, they could signify preparatory actions that set the stage for a future implant.
Related Articles
About Events and Incidents
This document provides a structured overview of key security-related incidents logged by ThinkShield Firmware Assurance. Events are categorized based on their nature, severity, and potential impact. Each event includes a brief description, its ...
Manifest Synchronization Error: WsusCatalog2.zip Failed Integrity Validation
Symptom In either the Lenovo Patch.log, the AutoPublish.log or both, the following error is present: Manifest synchronization error. Code=Failed, message=File 'C:\Users\USERNAME\Lenovo\Lenovo Patch\WsusCatalog2.zip' failed integrity validation: ...
About Device Statuses
Status The Status refers to the platform state of a device and indicates its onboarding stage. Devices can have one of three statuses: Active: The device is fully onboarded, provisioned, and actively reporting data. Pending: The device is either ...
Using Device Lookup
The Device Lookup page serves as a comprehensive information source, consolidating all data related to an individual device within the TSFA system. Designed to provide detailed insights, it facilitates the management and troubleshooting of devices. ...
Managing Devices within TSFA
To access devices within your organization's portal, navigate to Devices Manager > Devices. Device Table The Device Table provides regular information pertaining to each device, such as Device Name and Type, Serial Number, License, etc. It also ...