Logic bomb

A logic bomb always has two parts, and it is worth separating them because they are defended differently. There is the trigger: the condition the code checks over and over while doing nothing else. And there is the payload: whatever happens once that condition is met.

The trigger is usually trivial to write and hard to tell apart from a legitimate check. A date and time. An account existing, or ceasing to exist, in the directory. A particular file still being in place. A counter reaching a number. A process starting. Taken one at a time, none of those checks looks malicious: they are exactly what any scheduled job does.

The payload, by contrast, is nothing special: deleting files, encrypting a volume, quietly corrupting a database, or opening access for later. That is why a logic bomb is not a family of malware with behaviour of its own, but a way of delivering it: what defines it is the delay, not the damage.

The detection problem is that while it is dormant there is nothing to detect. Behavioural tooling sees no behaviour, because there is none: the code only checks a condition that has not been met yet. Signature-based detection only helps if someone has seen that specific code before, which is not the case when it was written by a person with legitimate access to the repository.

The second problem is time. If months pass between planting and firing, the backup retention window can be shorter than that interval, and every available backup already contains the bomb. Restoring reinstalls the problem. This is why an immutable backup with long retention is worth far more here than a recent one.

The third is who it comes from. The logic bomb is the classic insider threat case, because its natural trigger is “when my account stops existing”. Whoever plants it does not need to break in: they are already inside, and often authorised to ship code.

You do not find a logic bomb by running a scanner, because there is nothing to scan. You look for the conditions that let someone plant one unnoticed. On an internal test we look at who can deploy code or change scheduled tasks without a second person reviewing it, whether repositories and the deployment chain keep a log that the person deploying cannot erase, and whether offboarding actually removes access to code and automation rather than just to email.

In code review, the signal is a conditional that depends on a date, on an account existing, or on a specific identifier, at a point where the business logic has no reason to care about any of those. And the finding is written against the process, not the file: if one person can put code into production with no review and no trace, the problem is not whether there is a bomb in there today.