Malware & Threats
Logic Bomb
A logic bomb is malicious code hidden within a legitimate program or system that lies dormant until a specific condition is met, such as a date, an event, or a trigger, at which point it executes its harmful payload.
In plain terms
A logic bomb is a trap set in software. It sits quietly inside an otherwise normal program and does nothing until a specific trigger fires, like a certain date or a particular event, then unleashes its damage. Because it waits, it can be planted long before it goes off.
A logic bomb is malicious code embedded within a legitimate program or system that remains inactive until a predefined condition is satisfied, at which point it executes a harmful payload. The defining feature is the conditional trigger: rather than acting immediately, the code waits, monitoring for the circumstance that will set it off. This dormancy is precisely what makes a logic bomb dangerous and hard to find, because for most of its existence it does nothing observably malicious and blends into otherwise normal software.
The trigger that activates a logic bomb can take many forms. A common one is a specific date or time, in which case the construct is sometimes called a time bomb, set to detonate on an anniversary, a particular day, or after a countdown. Other triggers include the occurrence or absence of an event, such as a particular user logging in or being removed from a payroll system, a file appearing or disappearing, a certain number of executions, a database reaching a threshold, or a check that an employee’s account still exists. The logic can be arbitrarily specific, which lets the attacker control exactly when and under what circumstances the damage occurs.
When triggered, the payload can be anything malicious. Logic bombs have been used to delete files, corrupt databases, wipe systems, disable services, lock users out, exfiltrate or alter data, or otherwise sabotage operations. Because the payload runs from within trusted software and at a moment chosen by the attacker, it can be both destructive and difficult to attribute, especially if the person who planted it has since left or distanced themselves from the system.
Logic bombs are strongly associated with insider threats. A disgruntled employee, contractor, or administrator with legitimate access to code or systems is well positioned to insert a logic bomb, often timing it to activate after their departure or in response to an event such as being terminated or removed from a system. There have been real cases of administrators planting logic bombs intended to destroy data or disrupt operations as retaliation. This insider connection is part of what distinguishes logic bombs from much other malware: they are frequently introduced not through external intrusion but by someone trusted, hidden inside changes that appear legitimate at the time they are made.
The dormancy of logic bombs makes them especially challenging to detect. They produce no malicious behavior until the trigger fires, so behavioral monitoring may see nothing unusual for long periods, and the malicious code can be small and well-concealed within a large, legitimate codebase. Detection therefore leans heavily on prevention and inspection: code review to catch suspicious conditional logic, particularly checks tied to dates, specific users, or employment status; change management and version control so that modifications are tracked and attributable; and separation of duties so that no single person can introduce and deploy code unreviewed. Integrity monitoring can flag unexpected changes to files and systems.
Mitigating the broader risk combines technical and organizational measures. Strict access controls and the principle of least privilege limit who can modify critical code and systems. Mandatory peer review of code changes reduces the chance that hidden conditional payloads slip through. Prompt and complete deprovisioning of access when people leave removes the ability to plant or trigger such code afterward, and reduces the appeal of triggers tied to account status. Reliable, isolated backups support recovery if a logic bomb does detonate. Together these reduce both the opportunity to plant a logic bomb and the impact if one activates.
In practice, a logic bomb is a patient, conditional threat that hides inside trusted software and waits for the right moment to cause harm. Its reliance on a trigger gives it stealth and timing, and its frequent ties to insiders make it as much a personnel and process problem as a technical one. The defenses that matter most are code review, change control, separation of duties, rigorous access management, and dependable backups, reflecting that the best way to deal with a hidden time bomb is to make it hard to plant and to limit what it can reach when it goes off.