A logic bomb is malicious code planted inside a system that stays dormant until a specific trigger — a date, a missing name on a payroll list, a keystroke — sets it off. It is sabotage with a timer: nothing appears wrong until the condition is met, then programs are deleted, data destroyed or access handed over. This guide explains how logic bombs work, real cases that shaped the risk, and how a small business defends against a threat that hides inside its own trusted software.
TL;DR
- A logic bomb is dormant malicious code that detonates when a specific condition is met — a date, a payroll change, a file's absence.
- Classic cases involve insiders: a systems administrator who crashed over 1,000 servers at UBS PaineWebber in 2002, and a contractor whose time bomb was caught before detonation at Fannie Mae in 2008.
- It differs from other malware in one key way: it does not arrive by infection, it is planted inside existing trusted software.
- Code review, least privilege, offboarding controls and change detection are the defences that matter.
- Cyber Aware's human risk reporting addresses the insider-risk dimension of the threat.
What a logic bomb is
A logic bomb is not a piece of malware that infects a machine. It is a fragment of malicious logic hidden inside software that already has legitimate reasons to be there — an in-house application, a payroll script, an admin tool, even a commercial product's update mechanism. It sits inert until its trigger condition fires, then executes its payload: delete files, corrupt data, disable systems, or open a door for someone else.
Two features define the class:
- Dormancy. Nothing observable happens until the trigger. Scans find nothing because there is nothing anomalous to find — the malicious code lives inside code the business runs every day.
- A deliberate trigger. The detonation condition is chosen by whoever planted it: a future date (a "time bomb"), a file's existence or absence, a specific user account appearing or disappearing, a database value, a keystroke sequence.
How logic bombs get planted
Because a logic bomb must be written into a system, the planting almost always involves someone with legitimate access:
- Insider code. A developer or IT administrator inserts the payload into an application they maintain — the classic scenario, and the one behind the famous cases.
- Vendor or contractor code. Malicious logic in a contractor's deliverable or a vendor's update — the Fannie Mae case was exactly this: a contractor with privileged access.
- Compromised updates. An attacker who compromises a vendor's update pipeline plants a time bomb that ships to every customer — the mechanism used by the 2017 NotPetya outbreak (see the worm guide).
- Dependency and build-system compromise. Malicious logic injected into the pipeline that builds your software, waiting on a trigger.
Famous logic bomb cases
- UBS PaineWebber (2002). Systems administrator Roger Duronio planted a logic bomb that crashed more than 1,000 servers, then bought put options betting the firm's stock would fall. He was caught because the trade was traceable.
- Fannie Mae (2008). Contractor Jonathan U. Master planted a logic bomb scheduled to detonate months after his termination. It was found before it fired — because a colleague reviewing his last changes spotted the anomaly and escalated.
Note the pattern: in every famous case, the bomb was caught by a human noticing an anomaly — a colleague reviewing scripts, a monitoring alert, an investigation — not by antivirus. That is the defence in miniature.
What a logic bomb costs a business
The direct damage is whatever the payload does: servers wiped, records destroyed, production halted, backups deleted as a second-stage sabotage. The indirect damage is trust: a logic bomb means an insider or a trusted vendor deliberately attacked the business from within its own trusted code.
The blast radius scales with privilege. A bomb planted by a database administrator can destroy the data the business runs on; one planted in a payroll script hits every employee's pay run. In Australia, the destruction of personal or health information can also trigger notification obligations under the Privacy Act — a data-breach exposure on top of the operational loss, and the same exposure any ransomware incident carries.
Logic bomb vs time bomb vs other malware
| Trigger | Delivery | Who plants it | Main defence | |
|---|---|---|---|---|
| Logic bomb | Any condition | Planted in trusted code | Insiders, vendors, compromised updates | Code review, least privilege |
| Time bomb | A date or time | Same — planted | Insiders, compromised updates | Change detection, monitoring |
| Worm | None — spreads automatically | Self-spreads across networks | Nobody — self-replicating | Patching, segmentation |
| Trojan | A user running it | Disguised as useful software | Attackers via a lure | Trained staff |
The distinction matters for the defence: worms and trojans are stopped by patching and training, but a logic bomb is stopped by process — controls over who can change code and when.
How to defend against logic bombs
- Least privilege with separation of duties. No single person should be able to write, approve and deploy changes to critical systems alone. Two-person review on payroll, finance and production systems.
- Change detection on critical code and scripts. Version-control everything, including admin scripts and cron jobs, so changes have an author and a review — and are visible when someone leaves.
- Strong offboarding. Revoke access the moment employment ends, and review recent changes by departing staff. Most famous logic bomb cases were planted on the way out.
- Monitor for dormant anomalies. Watch for scripts or scheduled tasks that reference dates, names or files unusual for their purpose. A task that checks "if my user account is deleted" is not a backup script.
- Audit vendor and contractor code before deployment, and keep update channels signed and verified.
- Keep tested, offline backups — the last line when sabotage destroys live data.
- Treat insider risk as a training topic. Staff who know how to report concerns about a colleague's behaviour, and managers who know what to escalate, are the human detection layer. Cyber Aware's human risk reporting gives managers a per-person view of who clicks, who reports and who might need attention — and a cyber security gap assessment shows where privilege, offboarding and change controls are missing.
Why this matters for Australian businesses
Logic bombs are rare in small business, but the conditions that create them are not: an outsourced developer, a single admin managing everything, no code review, offboarding handled by email. The Essential 8's restriction of administrative privileges and multi-factor authentication directly shrink the blast radius, and SMB1001 expects documented offboarding. A business that can evidence those controls removes both the opportunity and the temptation.
FAQ
What is a logic bomb in simple terms? Malicious code hidden inside a legitimate program that does nothing until a specific condition is met — then it destroys data or systems. It is sabotage on a timer.
How is a logic bomb different from a virus? A virus spreads itself between machines; a logic bomb does not spread at all. It is planted in one place, waits for its trigger and detonates there — usually placed by someone who already had legitimate access.
Who typically plants logic bombs? Disgruntled employees, departing IT staff and contractors, and attackers who compromise a vendor's update pipeline. The common factor is existing trusted access.
Can antivirus detect a logic bomb? Usually not, because it does not arrive as a malicious file and stays dormant. It is found by code review, change detection, access monitoring and people noticing anomalies.
What triggers a logic bomb? Anything programmable: a date, a file appearing or disappearing, a payroll record changing, an account being disabled. The trigger is chosen to maximise damage or delay detection.
How do I protect my business from insider sabotage? Least privilege, separation of duties, version-controlled changes with review, immediate access revocation at offboarding, and tested backups. Those controls make most logic bomb scenarios impossible to plant or harmless to survive.
One last thing
Do one check this week: list every scheduled task, cron job and script that runs automatically in your critical systems, and confirm you can name the person who created each and when it was last reviewed. Any entry with no owner and no review date is exactly where a logic bomb hides.
Related guides
- What is a worm? — the self-spreading opposite: no insider needed.
- What is ransomware? — the external attack with similar destruction outcomes.
- Human risk reporting — the insider-risk visibility that complements technical controls.