A software time bomb is code designed to trigger an action at a particular date, time, or elapsed interval. When the action is malicious—such as deleting files, disabling systems, or launching another payload—the time bomb is a time-based form of logic bomb. A date check is not automatically malware: trial software, certificates, subscriptions, and planned feature flags also use legitimate expiration logic.
Is a time bomb a computer virus?
Not necessarily. A time bomb describes the trigger for an action, while a virus is malware that replicates by infecting other content. A virus, worm, Trojan, insider-planted script, or otherwise legitimate program can contain time-triggered behavior. Classification depends on how the code spreads and what it does, not only on the date check.
Time bomb versus logic bomb
A logic bomb activates when a chosen condition becomes true. The condition might be a date, a missing employee account, a database value, a number of program launches, or the presence of a file. A time bomb specifically uses time or an interval as its trigger, so it is best understood as one subtype of logic bomb.
A scheduled task is simply an operating-system mechanism. It becomes suspicious when an unauthorized task launches harmful code, uses deceptive paths, or is inconsistent with the host's role.
How malicious time bombs work
- The code establishes persistence in an application, script, service, scheduled task, cron job, firmware component, or startup item.
- It reads a clock, counter, or stored timestamp and remains inactive until the trigger condition is satisfied.
- At activation, it runs a payload such as data deletion, encryption, service disruption, credential theft, or installation of additional malware.
- It may remove itself, alter logs, or reset the trigger in an attempt to hide the cause.
The delay can allow malicious code to survive initial testing or separate the visible damage from the original compromise.
Possible warning signs
- An unknown scheduled task or cron job points to a temporary, user-writable, or unusual script location.
- A program contains an undocumented date check or behaves differently after a certain date or number of launches.
- Many files change at the same timestamp without an approved maintenance job.
- Source-control, deployment, or administrative logs show unauthorized code changes involving timers or expiration conditions.
- A disabled user, removed file, or changed system value is checked before a destructive action.
None of these signs proves malicious intent by itself. Backup agents, update systems, certificate renewal, log rotation, batch jobs, and license enforcement also run on schedules.
How defenders investigate
- Preserve the system clock, timezone, logs, scheduled-task configuration, and relevant code before changing anything.
- Compare suspicious jobs and binaries with approved deployment records and known-good versions.
- Review who created or modified the task, script, service, or application and from which account or management system.
- Use code review, behavioral monitoring, file-integrity data, and isolated analysis to identify the trigger and payload.
- Search other systems for the same path, hash, task name, command, or timestamp.
Do not set the clock forward on a production system to “test” a suspected time bomb. Doing so can trigger the payload and can also disrupt authentication, certificates, databases, logs, and distributed services.
Response steps
- If harmful activation may be imminent, isolate affected systems through the organization's incident-response process.
- Protect offline or immutable backups and confirm that the malicious code is not present in restore images.
- Disable the trigger only after preserving evidence and understanding dependencies.
- Revoke compromised accounts and code-signing or deployment credentials.
- Restore trusted code and configurations, then monitor past the expected trigger time.
Prevention
- Require peer review and signed, traceable deployments for production code.
- Restrict who can create scheduled tasks, services, automation jobs, and startup scripts.
- Alert on unauthorized changes to critical code and configuration.
- Separate developer, deployment, and backup privileges.
- Maintain tested backups that ordinary administrator accounts cannot rewrite.
- Document legitimate expiration and scheduled behavior so defenders can distinguish it from abuse.