Security teams detect a Logic/Time Bomb by looking for code or automation that stays inactive until a date, event, account state, or trigger condition is met. Review scheduled jobs, dormant branches, and unusual conditional logic, then compare source, binaries, and deployment artefacts. Alert on unexpected delayed actions, repeated failures before activation, and unauthorised code changes.
What to look for in code and automation
A logic or time bomb is usually hidden in plain sight as condition-driven behaviour. Security teams should look for code paths that remain dormant until a date, account state, file presence, environment variable, or external event is met. That means reviewing scheduled jobs, unusual branching logic, and scripts that do nothing during normal testing but become active later.
The key question is whether the triggering condition is legitimate and expected. If the behaviour only appears under a narrow combination of inputs, or if the code has no clear business reason to wait, it deserves closer inspection. Compare source code to compiled binaries and deployment artefacts so you can spot hidden conditionals, injected payloads, or logic that was added after review.
How to validate suspicious dormant behaviour
Detection improves when teams test execution under controlled variations, not just static review. Run artefacts with different timestamps, account states, feature flags, and environment settings to see whether delayed actions appear only when a specific trigger is crossed. Repeated failures before activation, countdown logic, and hard-coded dates are all useful indicators that the code may have been designed to wait.
It also helps to compare what is deployed with what was approved. Unauthorised code changes, last-minute edits to automation, or binaries that do not match the reviewed source can reveal a planted trigger. Logging and code review should focus on changes to branching logic, timers, and conditional checks, because those are the places where a time bomb is most likely to hide.
Where detection usually succeeds or fails
Detection works best when teams combine source review, binary comparison, and runtime observation. It fails when review is limited to the obvious execution path, when automation is assumed to be benign because it has never fired, or when triggers are treated as normal business logic without challenge. Long-idle code can be more dangerous than active malware because it often escapes operational attention.
A practical detection programme also needs to separate deliberate delay from normal scheduling. Many systems use timers and deferred tasks legitimately, so the real signal is unexpected or unjustified delayed action, especially when it is paired with privilege changes, data movement, or destructive operations after a quiet period.
Risk and Threat Considerations
Logic and time bombs are risky because they turn trusted code into a latent threat. The immediate environment may look clean, yet the malicious or unsafe behaviour can still be present and simply waiting for the right trigger, which makes both security review and incident timing more difficult.
Failure mechanism: An attacker, insider, or compromised build process inserts a dormant trigger into code, automation, or a binary so the payload activates only after a date, event, or account condition is met, often bypassing routine testing and review.
Impact: The result can be delayed sabotage, unauthorised access, data destruction, service disruption, or a second-stage compromise that appears to come from trusted automation rather than an obvious malicious launch point.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1204 — User Execution | Logic bombs often activate only when a user or event triggers them. |
| Recommendation — Hunt for trigger-based execution and correlate it with suspicious follow-on actions. | ||
| NIST CSF 2.0 | PR.DS-07 — Monitor for unauthorized personnel, connections, devices, software, and code | The topic centers on detecting unauthorized code changes and dormant automation. |
| DE.CM-01 — Monitored Networks and Systems | Detecting delayed malicious actions depends on continuous monitoring of system behaviour. | |
| Recommendation — Monitor code and deployments for unauthorized changes and unexpected activation paths. Baseline normal job and process behaviour so delayed activation stands out. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Source review, artefact comparison, and suspicious logic inspection are core application security practices. |
| Recommendation — Review application logic and release artefacts for hidden conditional behaviour. | ||
Practitioner Guidance
What to prioritise: Start with automation, scheduled tasks, and recently changed code paths that include hidden timing logic, unusual branching, or access-dependent activation. Those are the places most likely to carry dormant malicious behaviour without showing it during normal operation.
What to verify: Confirm that source, build artefacts, and deployed binaries match, and that the trigger condition has a legitimate business justification. If the team cannot explain why code waits for a specific date, state, or event, treat it as a security finding, not a harmless implementation detail.
Common mistake: Treating inactivity as safety. Dormant code is not low risk just because it has not executed yet; the risk is often higher because the trigger can be engineered to evade ordinary monitoring until the moment it matters.
Practitioner takeaway: The strongest signal is not that code is broken today, but that it has a credible path to become dangerous later without warning, so detection must cover both dormant behaviour and the conditions that can wake it up.