Adversaries may abuse task scheduling functionality to facilitate initial or recurring execution of malicious code. On Android and iOS, APIs and libraries exist to facilitate scheduling tasks to execute at a specified date, time, or interval.
On Android, the WorkManager API allows asynchronous tasks to be scheduled with the system. WorkManager was introduced to unify task scheduling on Android, using JobScheduler, GcmNetworkManager, and AlarmManager internally. WorkManager offers a lot of flexibility for scheduling, including periodically, one time, or constraint-based (e.g. only when the device is charging).[1]
On iOS, the NSBackgroundActivityScheduler API allows asynchronous tasks to be scheduled with the system. The tasks can be scheduled to be repeating or non-repeating, however, the system chooses when the tasks will be executed. The app can choose the interval for repeating tasks, or the delay between scheduling and execution for one-time tasks.[2]
| ID | Name | Description |
|---|---|---|
| S1083 | Chameleon |
Chameleon has used the AlarmManager API to schedule tasks.[3] |
| S1231 | GodFather |
GodFather has utilized a timer to initiate a WebSocket connection.[4] |
| S0536 | GPlayed |
GPlayed has used timers to enable Wi-Fi, ping the C2 server, register the device with the C2, and register wake locks on the system.[5] |
| S0545 | TERRACOTTA |
TERRACOTTA has used timer events in React Native to initiate the foreground service.[6] |
| S0558 | Tiktok Pro |
Tiktok Pro has contained an alarm that triggers every three minutes and timers for communicating with the C2.[7] |
This type of attack technique cannot be easily mitigated with preventive controls since it is based on the abuse of system features.
| ID | Name | Analytic ID | Analytic Description |
|---|---|---|---|
| DET0707 | Detection of Scheduled Task/Job | AN1829 |
The defender correlates creation or registration of deferred, repeating, or constraint-based background work with later task execution in the same app context, especially when the task executes without recent user interaction, from background state, or with follow-on file, sensor, or network behavior inconsistent with the app's declared role. The analytic prioritizes Android-observable control-plane effects: WorkManager enqueue operations, JobScheduler or AlarmManager scheduling, later wake or execution of the scheduled work, and post-trigger activity such as network sessions, local staging, or sensor access. |
| AN1830 |
The defender correlates creation of background scheduler activity with later execution of repeating or deferred work by the same managed app, then raises confidence when the triggered activity produces network, local-write, or other app behavior that occurs outside expected user context. Because iOS exposes weaker direct scheduling observability in many enterprise environments, the analytic anchors first on managed app posture and lifecycle-to-network or lifecycle-to-file effects, with NSBackgroundActivityScheduler-related behavior treated as strongest when runtime telemetry can observe background scheduler usage or execution callbacks. |