What Is a Logic Bomb? Trigger-Based Malicious Code

Most malware announces itself the moment it runs. A logic bomb does the opposite. It sits quietly inside a working program, doing nothing wrong, sometimes for months, until a condition it has been watching for comes true. Then it acts, usually to destroy or disrupt. The waiting is the point, and it is what makes a logic bomb hard to find and unsettling to defend against.

The name is apt. Like a bomb with a timer, the harmful part is armed long before it goes off, and the person who planted it is often long gone by the time it does.

The defining feature is the trigger

Strip away the drama and a logic bomb is a conditional statement with a malicious body. Some test decides whether the payload runs, and until that test passes, the surrounding program behaves exactly as expected. That is why the code survives review and testing: during every normal run, the condition is false and the harmful branch never executes.

Common triggers fall into a few families:

• Time-based. A specific date and time, an anniversary, or a fixed delay after installation. These are sometimes called time bombs.
• Event-based. A particular action or state, such as a specific file being opened, a program launching for the hundredth time, or a database reaching a certain size.
• Absence-based, or dead-man triggers. The payload fires when something expected disappears. The classic version checks whether a given employee still exists in the payroll or directory system, and detonates once that name is gone.

That last category is the one tied most closely to insiders, and it is worth its own section.

The insider angle

Logic bombs are unusual among malware because they are frequently planted by someone with legitimate access rather than delivered by an outside attacker. A developer, a system administrator, or a contractor already inside the codebase is perfectly placed to insert a few lines of conditional logic that no external firewall will ever see.

The motive is usually one of two things. Sabotage, from a disgruntled employee who wants to cause damage on the way out. Or leverage, from someone who wants to guarantee they cannot be dismissed without consequences, using a dead-man trigger tied to their own account so that removing them breaks the system.

This is why a logic bomb is as much a personnel and process problem as a technical one. The person planting it has passed every access control you have, because you gave them the access on purpose.

What the payload does

The trigger is the distinctive part. The payload is often ordinary destruction. Logic bombs commonly delete files, wipe databases, corrupt records, or disable services. When the payload's job is mass destruction of data, the behaviour overlaps directly with wipers and maps to MITRE ATT&CK Data Destruction (T1485).

Not every payload is destructive. Some are built to enable something quieter: opening a backdoor, escalating a privilege, or corrupting data slowly so the damage is hard to trace back to a cause. The trigger is what makes it a logic bomb. The payload can be anything the planter chose.

Aspect	Logic bomb	Typical outside malware
Who plants it	Often a trusted insider	Usually an external attacker
State before trigger	Dormant, behaves normally	Active on execution
How it activates	A logical condition comes true	Runs when delivered and launched
Where it hides	Inside legitimate software	A separate malicious file or process
Main defence	Code review and process controls	Perimeter and endpoint detection

How to defend against logic bombs

Because the code arrives through trusted hands and hides inside legitimate software, defence leans on engineering discipline and human process more than on scanners.

1. Mandate peer code review. No change reaches production without a second person reading it. A stray conditional checking today's date against a hardcoded value, or a query looking for a specific username, is the kind of thing a reviewer catches and an automated test never runs.
2. Require version control for everything. Every change should be attributable to an author and a commit. Trigger logic is much harder to hide when every line has a name and a history attached.
3. Enforce separation of duties. The person who writes code should not be the only person who can deploy it to production. Splitting these roles removes the single point of unchecked control.
4. Apply least privilege. The narrower an insider's access, the smaller the blast radius of anything they plant. A developer who cannot reach production databases cannot arm a bomb against them.
5. Audit before offboarding privileged staff. Before you disable a high-access account, review what that person built and deployed. This is the moment dead-man triggers are designed to exploit.
6. Monitor for the payload's actions. You may not spot the dormant trigger, but you can detect the effect: sudden mass file deletion, unexpected database drops, services being disabled. Alerting on destructive actions catches the bomb at the moment it goes off, in time to contain it.

Logic bombs are one tool in the broader insider-threat problem, and the actors who use destructive triggers overlap with sabotage and extortion crews. Our Threat Groups directory tracks the groups known for destructive payloads, so you can see how trigger-based sabotage fits alongside wiper and ransomware operations.

A logic bomb is patient by design, and that patience is what defeats point-in-time scanning. Beat it with process. Read the code, attribute every change, split the keys, and watch for the destruction the trigger was built to unleash.

Anatomy of a trigger

It is worth looking closely at the mechanism, because understanding the shape of the trigger is what lets a reviewer spot one. Every logic bomb reduces to the same skeleton: a condition that is evaluated during normal operation, and a harmful branch that runs only when the condition becomes true. The surrounding program is genuine, functioning software, and the malicious payload is a small addition tucked inside it.

The condition is where the craft lives. A crude trigger checks the current date against a hardcoded value, which is exactly the kind of comparison a careful reviewer notices because it has no legitimate business reason. More careful triggers hide the intent. The condition might be split across several places so no single line looks suspicious, or expressed in terms of a computed value rather than an obvious literal, or nested inside logic that appears to serve a real feature. A dead-man trigger, for example, might be disguised as a routine health check that quietly verifies a specific account still exists, with the destructive branch presented as ordinary error handling for when the check fails.

The payload is the second half. Because the trigger has done the work of hiding, the payload itself is often blunt: a routine that deletes files, drops database tables, or disables a service. The planter does not need the payload to be subtle, because the trigger guarantees it only runs at the chosen moment, by which time the planter is usually gone and the surrounding program has passed every test it was subjected to.

This structure explains the two defining properties of a logic bomb at once. It survives testing because the condition is false during every normal run, so the harmful branch is never exercised. And it is hard to attribute after the fact because, by the time the payload fires, the code has been in production for months and the person who wrote it may have moved on.

A worked example in plain terms

Consider a billing system maintained by a small team. One developer, anticipating a dispute with the employer, adds a few lines to a routine that runs every night. The lines check whether a particular employee record, their own, still appears in the company directory. As long as the record is present, the check passes and the nightly routine does nothing unusual. The code ships, passes review under time pressure, and runs cleanly for months.

The developer later leaves, and during offboarding their directory account is disabled and their record is removed. The next night the check fails for the first time. The harmful branch, written to look like cleanup that runs when the directory lookup returns nothing, begins deleting billing records. The damage is discovered days later when reconciliation fails, long after the trigger fired and well after the person who planted it departed.

Nothing in this sequence required an external attacker, a vulnerability, or a piece of malware crossing the perimeter. The harmful code walked in through the front door as an authorised change, sat dormant through every test, and was detonated by the organisation's own routine offboarding process. That is the pattern that makes logic bombs distinct, and it is why the defenses are as much about process as about technology.

Detection signals

A dormant logic bomb is hard to see by definition, but there are concrete signals across its lifecycle that give defenders something to watch.

In source code, the tells are conditionals with no legitimate business justification. A comparison of the current date or time against a fixed value, a check for the presence or absence of a specific user or record that no feature needs, or a countdown that decrements toward an action are all worth a second look during review. So is destructive logic that sits behind an unusual or rarely reachable branch, especially error-handling paths that do more than log and recover.

In version control, the signal is a change whose stated purpose does not match its content. A commit described as a minor fix that also touches deletion routines, or a change that adds date arithmetic to code that has no reason to care about the calendar, is the kind of mismatch history makes visible. Reviewing the diff and the commit message together, and asking whether the change does only what it claims, is often enough.

At runtime, you cannot see the dormant trigger, but you can see the payload the moment it fires. Sudden bulk deletion of files, unexpected dropping of database tables, mass modification of records, or services being disabled without a corresponding change request are the effects a destructive payload produces. Alerting on those actions does not prevent the bomb, and it catches it at detonation in time to contain the damage and begin recovery.

Behavioural and access signals add context. An insider who requests or retains access beyond what their role needs, who resists code review or separation of duties, or whose activity spikes around a period of conflict or impending departure, is not proof of anything, and it is the kind of pattern that insider-threat programs are built to weigh alongside the technical indicators.

Common mistakes in defending against logic bombs

A few recurring errors leave organisations exposed.

The first is relying on scanners to catch them. Antivirus and static analysis are tuned to recognise known-malicious patterns, and a logic bomb is bespoke code hidden inside legitimate software, often written by someone who knows exactly what the scanners look for. Treating a clean scan as assurance against logic bombs misreads what those tools can do.

The second is offboarding privileged staff without an audit. Revoking access is correct, and doing it before reviewing what the person built can be the exact action that fires a dead-man trigger. The safer sequence is to review first, then revoke, with heightened scrutiny for anyone who had the access to plant trigger logic.

The third is allowing a single person unchecked control over both writing and deploying code. When one individual can author a change and push it to production without a second set of eyes, there is no point at which a planted trigger has to survive review, because there is no review. Separation of duties removes that single point of unchecked control.

The fourth is treating logic bombs as purely a technical problem. The people best placed to plant one are trusted insiders who have passed every access control on purpose, so the defense has to include personnel process, clear conflict-resolution paths, and an insider-threat posture, alongside the engineering controls.

How logic bombs relate to other malicious code

Placing logic bombs beside neighbouring concepts sharpens what makes them distinct.

Concept	Defining trait	Relationship to logic bombs
Logic bomb	Trigger-based dormancy, then a payload	The parent concept here
Time bomb	Trigger is specifically a date or delay	A logic bomb whose condition is time
Dead-man trigger	Fires when something expected disappears	A logic bomb keyed to absence
Wiper	Payload destroys data	A common logic-bomb payload, also used alone
Backdoor	Provides hidden access	A quieter payload a logic bomb may deploy

A time bomb is simply a logic bomb whose condition is the clock. A dead-man trigger is a logic bomb whose condition is the absence of something, most often the planter's own presence in a system. A wiper describes the payload rather than the trigger, and destructive wiper behaviour is one of the most common things a logic bomb is built to unleash, which is why the two map to the same MITRE ATT&CK Data Destruction technique. A backdoor is a quieter alternative payload, chosen when the planter wants continued access rather than destruction. The trigger is the throughline that makes all of these a logic bomb, and the payload is a separate choice the planter makes.

How the idea has developed

Trigger-based malicious code is one of the older concepts in software security, predating the modern malware economy. It grew directly out of the reality that the people who build and maintain software have deep, privileged access to it, and that a small number of them, at some point, have a motive to misuse that access. The dead-man variant in particular is tied to the employment relationship, appearing wherever an individual believes their continued presence is the only thing keeping a system safe.

What has changed over time is the defensive environment, which has quietly raised the cost of planting one. Widespread adoption of version control means most changes now carry an author and a history, so slipping in unattributed trigger logic is harder than it once was. The normalisation of mandatory peer review means many changes face a second reader before they ship. Deployment pipelines that separate the author of a change from the person who releases it remove some of the single-handed control that logic bombs depend on. None of these controls is a scanner for logic bombs, and together they make the codebase a far less comfortable place to hide one. The organisations still most exposed are those that skip these disciplines under time pressure or trust.

Responding when you suspect one

If you have reason to believe a logic bomb is present, the response differs from ordinary malware handling because the threat is dormant and tied to a person. The first priority is to avoid triggering it. If the suspicion centres on a departing or departed insider, resist the reflex to immediately purge their accounts and records, since that purge may be the very condition the trigger waits for. Preserve the current state, take a snapshot or backup of the affected systems, and treat the environment as evidence.

Next, focus the review on what that person touched. Version-control history is the fastest lens: pull their commits, read the diffs against their stated purpose, and look specifically for conditionals involving dates, user or record presence, counters, or destructive branches behind unusual paths. Widen the review to code they deployed even if they did not author it, since a planter may have slipped logic into someone else's change.

While the code review proceeds, tighten runtime monitoring on the systems at risk so that if the payload does fire, you see it immediately. Alerting on bulk deletions, database drops, and service changes gives you a containment tripwire even before the trigger is found. Keeping current, tested, offline backups is the safety net underneath all of this, because it turns a successful detonation from a catastrophe into a recovery.

Throughout, treat it as an insider matter with the appropriate people involved, including human resources and, where warranted, legal counsel. The technical hunt and the personnel process run together, since the same individual who could plant the code is the one whose access and intent the investigation has to weigh.

Frequently asked questions

What is a logic bomb in simple terms? It is malicious code hidden inside a normal program that stays inactive until a specific condition is met, then runs a harmful payload. The defining feature is the trigger, the logical test that decides when the payload fires.

What is the difference between a logic bomb and a time bomb? A time bomb is a logic bomb whose trigger is specifically a date, a time, or a delay. All time bombs are logic bombs, and logic bombs can also trigger on events or on the absence of something rather than the clock.

Who plants logic bombs? Frequently a trusted insider with legitimate access to the codebase or systems, such as a developer, administrator, or contractor. The motive is usually sabotage by a disgruntled individual or leverage through a dead-man trigger tied to their own continued presence.

Can antivirus detect a logic bomb? Usually not reliably. A logic bomb is custom code hidden inside legitimate software, so there is often no known-malicious pattern for a scanner to match. Code review, version-control history, and monitoring for the payload's destructive actions are the more effective defenses.

What does a logic bomb payload do? Most often it destroys or disrupts: deleting files, dropping databases, corrupting records, or disabling services. Some payloads are quieter, opening a backdoor or escalating privileges. The trigger is what makes it a logic bomb, and the payload can be almost anything the planter chose.

How do you protect against logic bombs? Through engineering discipline and personnel process: mandatory peer code review, version control for every change, separation of duties between writing and deploying code, least privilege to limit blast radius, auditing what privileged staff built before offboarding them, and monitoring for the destructive actions a payload performs.

Why are dead-man triggers so dangerous during offboarding? Because disabling an account or removing a record can be the exact condition the trigger is waiting for. Offboarding a privileged insider without first reviewing what they built risks performing the action that detonates the bomb, which is why review should precede revocation.

Related guides

• Insider Threats Guide
• What Is a Wiper
• Secure Coding Practices
• Malware Persistence Techniques