Mobile T1398 Boot or Logon Initialization Scripts: Finding and Removing Footholds on Android and iOS

Mobile T1398 Boot or Logon Initialization Scripts is an adversary using code that runs automatically when a phone starts so that their foothold returns after every reboot. MITRE ATT&CK for Mobile v20 lists it under the Persistence tactic for both Android and iOS, and notes that true initialisation scripts belong to the operating system and cannot be touched unless the device is rooted or jailbroken. In practice the procedure examples split into two very different things: deep compromises that rewrite protected boot files, and ordinary apps that simply ask to be started at boot. This guide is for mobile security engineers, MDM administrators and incident responders who need to tell those apart, detect them with the telemetry they actually have, and close them with boot integrity, attestation and app vetting. For the matrix overview see the MITRE ATT&CK for Mobile Guide.

Key takeaways

• Two tiers, two responses. Modifying a real init script (OldBoot) requires a compromised system partition; registering for the boot broadcast (AhRat, BOULDSPY) only requires an installed app.
• Boot integrity is the main control. All four ATT&CK mitigations for T1398 (Security Updates, Attestation, Lock Bootloader, System Partition Integrity) protect the chain of trust, not the app layer.
• Android reports its boot state. The enterprise SecurityLog TAG_OS_STARTUP event records the Verified Boot state (green, yellow, orange) and dm-verity mode at every start.
• Reboots matter on iOS. ThreatFabric found the iOS LightSpy implant used a jailbreak that does not survive a reboot, so its boot plist only re-ran on a device the attacker could re-exploit.
• App-layer boot start is normal. BOOT_COMPLETED is an exempted broadcast many legitimate apps use, so detection has to combine it with provenance, permissions and network behaviour.

What T1398 covers on Android and iOS

ATT&CK describes T1398 as adversaries using scripts automatically executed at boot or logon initialisation to establish persistence, and states that these scripts are part of the operating system and not accessible to the user unless the device has been rooted or jailbroken. The technique has no sub-techniques. The Enterprise equivalent is covered in the MITRE ATT&CK T1037 Boot or Logon Initialization Scripts guide; on a phone the user has no shell, no logon script folder and no startup directory, so the attack surface is much narrower.

• Android: the init process and its scripts live on verified, read-only partitions. Modifying them means defeating Android Verified Boot, which builds a chain of trust from a hardware-protected root of trust through the bootloader to the boot, system and vendor partitions, with each stage checking the next before handing over execution.
• iOS: the Boot ROM contains the Apple root CA public key and verifies iBoot (or LLB on A9 and earlier) before it runs, and iBoot verifies the kernel. A failure to verify sends the device to DFU or Recovery mode. Persistent changes to launch configuration therefore depend on a jailbreak.
• App-level start at boot: on Android, ACTION_BOOT_COMPLETED and ACTION_LOCKED_BOOT_COMPLETED are exempted from the implicit broadcast restriction because many apps need them to schedule jobs and alarms. ATT&CK records malicious apps using this path under T1398 even though no system script changes.

Procedure examples and what they teach

ATT&CK v20 lists four software entries for T1398. They are summarised as ATT&CK and the cited researchers state them.

Prevention: the four ATT&CK mitigations in practice

For the app-layer cases, the controls are app source policy (managed Google Play, Apple Business Manager or App Store only), blocking installs from unknown sources, Google Play Protect, and reviewing which apps hold boot-time receivers. For people at high risk of targeted spyware, Apple Lockdown Mode (iOS 16 and later) blocks most message attachment types and some complex web technologies, which narrows the delivery paths used to reach a jailbreak in the first place. See the Apple Lockdown Mode Guide and the Android Advanced Protection guide.

Detection with the telemetry you actually have

ATT&CK v20 detection guidance for T1398 asks defenders to correlate application permission data, host status from MDM and network flow metadata, alert on state changes that do not fit the device baseline or approved policy, and not to infer API calls or file activity that management data cannot show. That last point matters: an MDM does not see init scripts.

• Android boot state: on company-owned devices with security logging enabled, each TAG_OS_STARTUP event (API level 28 and later) carries the Verified Boot state and the dm-verity mode (enforcing, eio or disabled). Green means a full chain of trust; orange means the device may be freely modified. Alert on anything other than green with enforcing.
• Android app start: TAG_APP_PROCESS_START records process name, UID and the SHA-256 hash of the base APK, so a process starting seconds after TAG_OS_STARTUP can be tied to an exact APK. TAG_PACKAGE_INSTALLED (API level 34) gives the install record for that package.
• Attestation verdicts: a Play Integrity device verdict that drops from MEETS_DEVICE_INTEGRITY to blank indicates signs of attack or system compromise such as rooting. On iOS, failed or missing managed device attestation and jailbreak signals from an MTD agent are the equivalent.
• Network: Android Enterprise network logging (DNS and connect events) or per-app VPN flow data on both platforms can show beaconing that starts at boot before the user opens any app.
• Forensics: the Mobile Verification Toolkit from Amnesty International Security Lab checks iOS backups, filesystem dumps and sysdiagnose archives, and Android backups, against published indicators. Use it with consent and as part of the Mobile Spyware Infection Response Playbook.

How to implement

1. Baseline: export device inventory with OS version, patch level and attestation status. List devices that cannot attest or are out of vendor support.
2. Turn on logging: enable security logging and network logging on company-owned Android devices, and confirm the events reach the SIEM. Check retention, because the device buffer is limited.
3. Audit mode first: run compliance rules for boot state, patch age and attestation in report-only mode for two to four weeks to find legacy models and false positives.
4. Enforce in rings: move IT staff, then high-risk roles, then everyone to conditional access that blocks non-compliant devices from corporate apps. Rollback is switching the rule back to report-only; keep a documented exception path for devices awaiting replacement.
5. App layer: restrict app sources, then review apps that start at boot and also hold sensitive permissions, starting with those outside your approved catalogue.
6. Response: for a broken chain of trust, quarantine, preserve evidence, then reflash or replace; for an app-layer case, remove the app, revoke tokens it could reach and check other devices for the same package hash.

Decision guidance

• Small organisations: MDM compliance on OS version plus attestation-based conditional access covers most of T1398. Skip SIEM collection of device logs until you have someone to read them.
• Large or regulated organisations: add Android security log collection, MTD, and a forensic route (MVT or a specialist) for executives and staff at risk of targeted spyware.
• BYOD: work profile and user-enrolment modes limit what you can see. Rely on app-level attestation in your own apps (Play Integrity, App Attest) and gate access on it rather than expecting boot telemetry. See the Mobile App Attestation guide.

Where identity fits

A device that persists through reboot keeps every token cached on it. Session tokens, OAuth refresh tokens and MDM enrolment certificates on a compromised device should be treated as exposed: revoke them centrally rather than relying on a wipe, and bind access to device compliance so a failed attestation cuts access automatically. See the Mobile Access Credentials guide.

Detection and measurement

• Share of company-owned Android devices reporting TAG_OS_STARTUP as green with dm-verity enforcing (target 100 percent).
• Share of managed devices passing attestation at last check-in, per platform.
• Devices below the minimum OS or patch level, and median days to bring them into compliance.
• Number of boot-start apps outside the approved catalogue, trending down.
• Time from failed attestation to blocked access (target: next token refresh).

Framework mapping

Common failure patterns

• Treating any boot receiver as malware: alerting on BOOT_COMPLETED alone floods analysts, because it is a normal, exempted broadcast.
• Trusting a factory reset after boot partition tampering: a factory reset is designed to erase user data, not to repair a tampered boot image. Our recommendation is to reflash a signed image or retire the device.
• Vetting only the first install: AhRat arrived in an update to an app that had been clean for almost a year.
• Allowing unattested devices "temporarily": exceptions for old models become permanent and are exactly the devices where boot integrity is weakest.
• Logging enabled but not collected: security log events stay on the device unless the DPC retrieves and forwards them.

Practitioner checklist

• Enforce minimum OS and patch levels on both platforms through MDM.
• Gate corporate access on attestation (Play Integrity device verdict, managed device attestation).
• Treat Verified Boot orange or dm-verity disabled as non-compliant.
• Enable and forward Android security and network logs on company-owned devices.
• Restrict app sources and keep Google Play Protect on.
• Review boot-start apps that also hold sensitive permissions or reach unknown hosts.
• Offer Lockdown Mode or Advanced Protection to high-risk users.
• Reflash or replace, never just reset, devices with a broken chain of trust, and revoke their tokens.

Standards and references

• MITRE ATT&CK: Boot or Logon Initialization Scripts (Mobile T1398)
• Android Open Source Project: Verified Boot
• Android Developers: SecurityLog
• Android Developers: Implicit broadcast exceptions
• Android Developers: Play Integrity API integrity verdicts
• Apple: Boot process for iPhone and iPad devices
• ESET: Android app breaking bad, AhRat analysis
• ThreatFabric: LightSpy implant for iOS

Related NHI Mgmt Group resources: MITRE ATT&CK for Mobile Guide · Firmware and Boot Security Guide · Mobile Device Management Security Guide · Mobile Forensics Guide · Mobile Malware Guide