A logic bomb is a snippet of malicious code that is intentionally inserted into other software.
Logic bombs are triggered when a certain condition is met.
The code may lie dormant for a long time and remain undetected until the bomb is triggered.
When the bomb is activated, it can have devastating effects on the software, causing it to malfunction, delete data, or even grant unauthorized access to sensitive information.
The attack can also be designed to spread to other systems or cause damage to a wider network.
The malicious code is hidden within an otherwise legitimate software package.
It can be introduced at any point in the software supply chain.
ID:T0150
Type:Technique
Tactic:Execution
Summary:Runtime logic bomb
State:Draft
Mitigations
ID
TYPE
SUMMARY
DESCRIPTION
M1500
Mitigation
Mitigation Verify third-party artifacts and open-source libraries Verify third-party artifacts used in code are trusted and have not been infected by a malicious actor before use.
This can be accomplished, for example, by comparing the checksum of the dependency to its checksum in a trusted source. If a difference arises, this may be a sign that someone interfered and added malicious code. If this dependency is used, it will infect the environment and could end in a massive breach, leaving the organization exposed to data leaks and more.
M1501
Mitigation
Mitigation Require SBOM from all third-party suppliers An SBOM for every third-party artifact helps to ensure an artifact is safe to use and fully compliant.
This file lists all important metadata, especially all the dependencies of an artifact, and allows for verification of each dependency. If one of the dependencies/artifacts is attacked or has a new vulnerability (e.g., the “SolarWinds” or even “log4j” attack), it is easier to detect what has been affected by this incident because dependencies in use are listed in the SBOM file
M1502
Mitigation
Mitigation Define trusted package managers and repositories When pulling a package by name, the package manager might look for it in several package registries, some of which may be untrusted or badly configured.
If the package is pulled from such a registry, there is a higher likelihood that it could prove malicious. In order to avoid this, configure packages to be pulled from trusted package registries.
M1503
Mitigation
Mitigation Implement SCA analysis Component Analysis is the process of identifying potential areas of risk from the use of third-party and open-source software and hardware components.
The best option for implementing SCA analysis is integration of SCA analysis tools into your CI/CD environment in order to scan your source code dependencies before the release.
Detections
ID
TYPE
SUMMARY
DESCRIPTION
D1500
Detection
Detection Configure monitoring of used artifacts and open-source libraries Implement regular scanning of used artifacts and open-source libraries for known vulnerabilities.
Set up monitoring of reported issues based on regular scanning results.
AppSec teams are overwhelmed by useless alerts, managing numerous applications with vulnerabilities across various kill-chain stages, making them increasingly susceptible to successful attacks.
