Mobile T1603 Scheduled Task/Job: Android and iOS Guide

Mobile malware needs to run again after the user closes it, and the same scheduling APIs that let a legitimate app sync email or upload logs let a malicious one beacon to its operator every few minutes. MITRE ATT&CK for Mobile records this as T1603 Scheduled Task/Job, under both Execution and Persistence, and lists it for Android and iOS. This guide explains the scheduling APIs on each platform, what ATT&CK's procedure examples show, the platform limits that constrain abuse, and how to detect it through app vetting, managed device policy and forensics. It is for mobile security engineers, app vetting teams and SOC analysts, and builds on the MITRE ATT&CK for Mobile Guide. For the Windows, Linux and macOS equivalent, see T1053 Scheduled Task/Job Defensive Guide.

Key takeaways

Scheduling is ordinary app behaviour. WorkManager, JobScheduler and AlarmManager on Android and the BackgroundTasks framework on iOS are used by most apps, so the signal is what a scheduled task does, not that one exists.
The OS sets the limits. Android WorkManager periodic work has a 15-minute minimum interval, Android 14 denies exact alarm permission by default to most new apps, and on iOS the system decides when background work actually runs.
Detection is mostly pre-deployment. ATT&CK's analytics for both platforms say to detect this technique primarily during app vetting or controlled analysis rather than expecting a live device SOC feed.
Look for background activity without a user. The core analytic is a scheduled task that triggers network traffic, file writes or sensor access while the app is in the background or the device is locked.
Stopping it means removing the app. Scheduled work persists across app restarts and reboots, so containment is uninstalling the app, not killing a process.

What T1603 covers

ATT&CK describes T1603 as adversaries abusing task scheduling to run malicious code initially or repeatedly, using the APIs and libraries Android and iOS provide to schedule tasks at a set date, time or interval.

Attribute	ATT&CK v20 Mobile value
ID and name	T1603 Scheduled Task/Job
Tactics	Execution, Persistence
Platforms	Android, iOS
Sub-techniques	None
Mitigations listed	None mapped to the technique
Detection strategy	DET0707 Detection of Scheduled Task/Job (one Android and one iOS analytic)
Enterprise counterpart	T1053 Scheduled Task/Job

The scheduling APIs on each platform

Platforms are listed alphabetically, with matching depth.

Android

ATT&CK notes that WorkManager unifies task scheduling on Android, using JobScheduler, GcmNetworkManager and AlarmManager internally. Android's documentation describes WorkManager as storing scheduled work in an internally managed SQLite database and ensuring it persists and is rescheduled across device reboots. It supports immediate, long-running and deferrable work, periodic schedules and constraints such as running only on an unmetered network or while charging, and it respects power-saving features such as Doze. AlarmManager exact alarms can wake a device from Doze, and Android advises using them only for precise events such as calendar alerts.

iOS

ATT&CK names NSBackgroundActivityScheduler as the iOS API, stating that apps choose the interval or delay while the system chooses when tasks actually run. Apple's documentation lists NSBackgroundActivityScheduler for macOS (10.10 and later), not iOS. On iOS and iPadOS 13 and later, Apple's BackgroundTasks framework provides BGTaskScheduler, which Apple describes as giving an app a way to run code even when it is suspended. Apps must declare their task identifiers in the BGTaskSchedulerPermittedIdentifiers Info.plist key, and app refresh tasks (BGAppRefreshTask) require the fetch background mode. ATT&CK's own iOS analytic refers to BGTask registration, so defenders should look at both APIs.

Aspect	Android	iOS
Main APIs	`WorkManager`, `JobScheduler`, `AlarmManager`	`BGTaskScheduler` (BackgroundTasks framework, iOS 13+); ATT&CK also names `NSBackgroundActivityScheduler`
Declared in the app package	`SCHEDULE_EXACT_ALARM` or `USE_EXACT_ALARM` permission for exact alarms	`BGTaskSchedulerPermittedIdentifiers` and `UIBackgroundModes` in Info.plist
Who controls timing	App sets schedule within OS limits: periodic WorkManager work has a 15-minute minimum interval	System decides when tasks run
Persistence	WorkManager work survives app restarts and reboots	Tasks are scheduled through the system scheduler, which launches the app to run them
Where to review it	Manifest permissions, dynamic API trace	Info.plist keys, dynamic API trace

Platform limits that constrain abuse

Exact alarms on Android 14: SCHEDULE_EXACT_ALARM is no longer pre-granted to most newly installed apps targeting Android 13 or higher; without it, setExact(), setExactAndAllowWhileIdle() and setAlarmClock() throw a SecurityException. Users grant it in Settings under Special app access, Alarms and reminders, and USE_EXACT_ALARM is limited by Play policy to calendar and alarm clock apps. An unexpected app on that list deserves a look.
Battery allowlist: apps on the power allowlist can always call exact alarms; malware that persuades a user to exempt it from battery optimisation gains that ability, so treat allowlist membership as a review item.
iOS scheduling discipline: background tasks run only when the system schedules them, and Apple's App Review Guideline 2.5.2 bars apps from downloading code that changes their functionality, which limits what a scheduled task in a store app can do.

What the procedure examples show

Software	Behaviour recorded by ATT&CK
Chameleon	Used the `AlarmManager` API to schedule tasks
GodFather	Used a timer to start a WebSocket connection
GPlayed	Used timers to enable Wi-Fi, ping its C2 server, register the device and register wake locks
TERRACOTTA	Used timer events in React Native to start its foreground service
Tiktok Pro	Contained an alarm that triggers every three minutes and timers for C2 communication

All five are Android software in ATT&CK; the technique has no iOS procedure example in v20. The pattern is consistent: scheduling is used to keep command and control alive and to restart services. For context on these families, see the Android Banking Trojans Guide and the Mobile Malware Guide.

Detection

ATT&CK's DET0707 has one analytic per platform. Both correlate a dynamic API trace with forensic or filesystem evidence of what the task did.

Platform	API trace signal	Effect signal
Android	App enqueues WorkManager work, schedules a JobScheduler job or sets a repeating AlarmManager alarm and is not on an approved scheduler apps list	Task creates a file, accesses a sensor or opens a network connection immediately after firing, with no recent user interaction
iOS	Managed app creates an `NSBackgroundActivityScheduler` activity or registers a repeating BGTask outside its approved function	Task produces network, local write or sensor activity while the app is in the background or the device is locked, with no user trigger

App vetting: run new apps and updates in an instrumented environment for long enough to see periodic behaviour (at least several 15-minute cycles on Android), with the screen locked, and record outbound connections per wake-up.
Static review: on Android, flag SCHEDULE_EXACT_ALARM, USE_EXACT_ALARM and battery optimisation exemption requests in non-calendar apps; on iOS, review UIBackgroundModes and BGTaskSchedulerPermittedIdentifiers against the app's stated purpose.
Network telemetry: MTD agents and network proxies can show regular beacons from a device at fixed intervals while it is idle; correlate with the app inventory.
Forensics: for a suspected compromise, acquire the device and inspect app containers; WorkManager's SQLite store is part of the app's data. See the Mobile Forensics Guide and Mobile Verification Toolkit (MVT).

Prevention and response

Control app sources: on Android Enterprise, keep untrustedAppsPolicy at DISALLOW_INSTALL and googlePlayProtectVerifyApps at VERIFY_APPS_ENFORCED (both documented defaults); on iOS, keep apps in App Store or managed distribution. See the Android Enterprise Security Guide and iOS and iPadOS Enterprise Security Guide.
Maintain an approved scheduler list: record which managed apps legitimately use exact alarms or background tasks; this is the $ApprovedSchedulerApps$ baseline in ATT&CK's analytics.
Review special access: periodically check apps holding Alarms and reminders access or battery optimisation exemption on managed Android devices.
Contain by removal: because scheduled work survives reboots, uninstall the app (which removes its scheduled work and data) and block corporate access until it is gone; preserve first if the user is a likely target.
Revoke what the app could reach: if the app held corporate tokens or ran in the work profile, revoke its sessions and rotate any credentials it could read.

Where identity fits

Legitimate scheduled work often carries credentials: a sync job refreshing an OAuth token, a log uploader with an API key. A malicious task with the same access beacons using the user's or the app's tokens. Keep tokens used in background work short-lived and scoped, store them in the platform keystore or keychain, and make sure revoking a user's sessions also invalidates tokens held by their mobile apps. See Mobile Access Credentials.

Measuring it

Vetting coverage: percentage of approved apps whose current version had a dynamic run long enough to observe periodic behaviour.
Special access drift: number of managed Android apps holding exact alarm access or battery exemption outside the approved list (target zero).
Idle beaconing: count of devices showing fixed-interval outbound traffic from unapproved apps while idle, and the time to triage each.
Removal time: median time from detection to uninstall and access block.

Common failure patterns

Short vetting runs: dynamic analysis that lasts a few minutes with the screen on never sees a task scheduled for 15 minutes later with the device locked.
Killing the app instead of removing it: force-stopping or rebooting leaves scheduled work in place.
Battery exemption granted on request: users accept prompts to disable battery optimisation, giving malware the exact alarms it needs.
Assuming iOS is immune: ATT&CK lists iOS for this technique; background task declarations still need review in vetting.
No baseline: without a list of apps expected to schedule work, every alert is a guess.

Framework mapping

Framework	Reference	Relevance to T1603
NIST CSF 2.0	PR.PS-05, DE.CM-09	Prevent unauthorised software; monitor runtime environments
NIST SP 800-53 Rev 5	AC-19, CM-7, SA-11, SI-3, SI-4	Mobile device access control, least functionality, developer testing, malicious code protection, system monitoring
CIS Controls v8.1	Control 2 (Inventory and Control of Software Assets), Control 10 (Malware Defenses)	Approved apps; malware defences
ISO/IEC 27001:2022 Annex A	A.8.1, A.8.7, A.8.16	User endpoint devices, protection against malware, monitoring activities
ATT&CK Enterprise	T1053	Same behaviour on desktop and server platforms

Practitioner checklist

Keep untrusted installs blocked and Play Protect verification enforced on Android Enterprise; keep iOS apps in managed distribution.
Build an approved scheduler apps list for both platforms.
Run dynamic vetting long enough, with the screen locked, to see periodic behaviour.
Flag exact alarm permissions and battery optimisation exemptions in non-calendar Android apps.
Review UIBackgroundModes and BGTaskSchedulerPermittedIdentifiers for iOS apps.
Contain by uninstalling, not force-stopping, and revoke the app's tokens.
Keep background work tokens short-lived and stored in the keystore or keychain.

Mobile T1603 Scheduled Task/Job: Spotting Malicious Execution on Android and iOS