Join our Newsletter — 33% off our NHI Course
Home› FAQ› Threats, Abuse & Incident Response› What is an example of a logic bomb…
Threats, Abuse & Incident Response

What is an example of a logic bomb or time bomb in practice?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated October 20, 2026 Domain: Threats, Abuse & Incident Response

A logic bomb is malicious code that activates when a condition is met, and a time bomb activates at a set time. In practice, this can mean a script that deletes files after an employee is removed or a scheduled task that disables services on a date. Monitor privileged changes, persistence, and delayed execution paths.

What a logic bomb looks like in a real environment

An example in practice is a malicious script or scheduled job that stays dormant until a trigger condition is met, then deletes data, disables services, or sabotages a workflow. The trigger can be a date, a system event, or a specific account state, which makes the payload look normal until the moment it executes.

What makes this different from ordinary malware is the delay and the hidden condition. The code is often placed where it blends into legitimate administration, so the security problem is less about noisy execution and more about who can create, modify, or retain delayed-action code paths.

How time bombs are used for delayed sabotage

A time bomb is the simpler case: the payload activates at a predefined time rather than waiting for a business condition. In practice, that might be a task scheduled to run after offboarding, a dormant batch job that corrupts records at month-end, or a script that disables monitoring after a chosen date.

Because the activation point is predictable, time bombs are often planted to create disruption after the attacker has had time to avoid detection or after trust in the original change has faded. The practical danger is that the malicious logic can survive normal testing if the trigger is outside the test window.

Why these attacks are hard to spot before they fire

logic bomb and time bombs are effective because they exploit persistence, delayed execution, and administrative trust. They may live inside a script, automation pipeline, deployment artifact, or maintenance task, so the code itself can appear legitimate until its hidden condition is satisfied.

Malware Guide helps place delayed-action code in the wider malware landscape, including payloads that rely on environmental triggers, embedded logic, and evasive behavior. That framing matters because the defensive question is not only “is this malicious?” but also “can this code remain dormant long enough to bypass routine review?”

Detection usually depends on finding the trigger relationship, not just the payload. Reviewers need to inspect unusual conditional branches, delayed tasks, privileged scripts, and changes that create future-state behavior rather than immediate effects.

Risk and Threat Considerations

These attacks are especially dangerous when privileged users, automation accounts, or maintenance tooling can alter production systems without tight review. A malicious trigger can convert an apparently routine change into delayed sabotage, data destruction, or service interruption long after the original deployment.

Failure mechanism: The attacker or insider hides destructive logic behind a condition that normal testing does not reach, then waits for the trigger to occur, or creates the trigger themselves by changing account state, dates, or environment conditions.

Impact: The result can be silent persistence followed by sudden disruption, with damaged files, disabled services, corrupted records, and a harder incident timeline because the malicious action may happen well after the code was introduced.

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 CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
MITRE ATT&CKT1053 — Scheduled Task/JobTime bombs often run through scheduled execution paths.
T1204 — User ExecutionLogic bombs can be triggered by user actions or account-state changes.
Recommendation — Hunt for suspicious scheduled jobs and correlate them with delayed payload activation. Review execution paths that depend on user action or account conditions.
CIS Controls v8CIS-8 — Audit Log ManagementDelayed sabotage is easier to catch when task, change, and execution logs are retained.
Recommendation — Centralize and review logs for privileged changes and scheduled execution.
NIST SP 800-53 Rev 5AU-6 — Audit Review, Analysis, and ReportingLogic bombs require review of logs and anomalous delayed activity.
CM-3 — Configuration Change ControlMalicious triggers often enter through unauthorized or weakly reviewed changes.
Recommendation — Analyze audit records for privilege changes and delayed execution patterns. Require approval and traceability for changes that create dormant execution paths.

Practitioner Guidance

What to verify: Treat delayed execution paths as sensitive change points. Review scheduled tasks, startup scripts, CI/CD jobs, offboarding automation, and any code that changes behavior based on time, user state, or environment variables.

Decision rule: If a change can execute later without a human present, require stronger approval, logging, and rollback evidence than for ordinary code. If it can delete data, disable services, or alter security controls, assume it needs the same scrutiny as a privileged configuration change.

What good looks like: You can explain who created the logic, what condition activates it, when it can run, and how the trigger is monitored or removed. The safest outcome is not just detection after the fact, but prevention of hidden delayed-action code entering production.

Practitioner takeaway: The key control is not merely scanning for malware signatures, it is controlling who can introduce dormant behavior and proving that scheduled or condition-based execution is intentional, visible, and reversible.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org