T1398: Boot or Logon Initialization Scripts
Adversaries may use scripts automatically executed at boot or logon initialization to establish persistence. Initialization scripts are part of the underlying operating system and are not accessible to the user unless the device has been rooted or jailbroken.
Analyst context for executives and security teams
Boot or logon initialization scripts matter because they can give malware persistence on Android or iOS at a level ordinary users usually cannot inspect. MITRE notes these scripts are part of the underlying OS and are only accessible when a device is rooted or jailbroken, so this behavior is a signal that mobile device integrity, not just app hygiene, may be at issue.
Executive priority
Treat this as a mobile trust and access-control problem. Leaders should ask whether enterprise access depends on device integrity signals such as update status, attestation, locked bootloaders, and Android Verified Boot where available. The business decision is whether rooted, jailbroken, outdated, or integrity-failing devices are allowed to reach sensitive enterprise resources, and whether audit evidence exists to prove that policy is enforced.
Technical view
For SOC, IR, mobile security, and detection engineering teams, validate coverage for Android and iOS devices where boot/logon initialization persistence could indicate root or jailbreak-level compromise. ATT&CK does not provide detection text for T1398, but a related detection strategy, DET0654, exists. Use the mitigation relationships as validation anchors: confirm security patch level visibility, remote attestation results where available, bootloader lock state checks, and Android system partition integrity/Verified Boot status. Relationship context also shows this technique is used by multiple mobile software entries, including OldBoot, BOULDSPY, AhRat, and LightSpy, so mobile malware triage should include persistence and device integrity review when those families or similar behaviors are in scope.
Likely telemetry
- Mobile device management or enterprise mobility inventory showing OS version and security patch level
- Remote attestation results where available, such as Android SafetyNet or Samsung Knox TIMA Attestation as referenced by ATT&CK mitigation context
- Bootloader lock-state or device integrity posture checks where supported
- Android Verified Boot or system partition integrity status where available
- Root or jailbreak status from managed mobile security controls
Detection direction
- Do not rely on user-visible indicators; MITRE states the relevant initialization scripts are not accessible to the user unless the device is rooted or jailbroken.
- Validate whether DET0654 or equivalent local detections are actually implemented, since the ATT&CK object itself provides no official detection procedure.
- Tune alerts around combinations of root/jailbreak indicators, failed attestation, unlocked bootloader state, missing security updates, or failed system partition integrity rather than treating any single weak signal as conclusive.
- Check for blind spots on unmanaged BYOD devices, older devices, devices without timely security updates, and platforms where attestation or integrity reporting is unavailable or not collected.
- During IR, preserve the distinction between suspected persistence and confirmed OS-level modification; local forensic evidence is required before making compromise conclusions.
Mitigation priorities
- Prioritize security updates: require recent mobile OS/security patch levels and restrict enterprise access from devices that have not installed recent updates, consistent with M1001.
- Use remote attestation where available and prohibit devices that fail attestation from accessing enterprise resources, consistent with M1002.
- Perform periodic checks that supported bootloaders remain locked, consistent with M1003.
- For Android, ensure Verified Boot/system partition integrity capability is present and enabled where supported, consistent with M1004 and the Android Verified Boot reference.
- Decommission or block devices that no longer receive security updates when they cannot meet enterprise trust requirements.
Analyst notes and limits
This technique is in the mobile ATT&CK domain and lists Android and iOS as platforms. Tactics are not specified in the supplied object, and the official description frames the behavior as persistence through boot or logon initialization scripts. The strongest relationship-backed defensive themes are device integrity, patch currency, attestation, locked bootloaders, and Android system partition integrity.
ATT&CK provides no official detection text for this object, and the supplied DET0654 relationship does not include implementation details. The object does not provide procedure-level details for each related malware entry here. Local mobile management, attestation, access-control, and forensic evidence are required to assess actual exposure or detection coverage.
Boot or Logon Initialization Scripts
Adversaries may use scripts automatically executed at boot or logon initialization to establish persistence. Initialization scripts are part of the underlying operating system and are not accessible to the user unless the device has been rooted or jailbroken.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Groups, software, and campaigns
S0285: OldBoot
S1095: AhRat
AhRat is an Android remote access tool based on the open-source AhMyth remote access tool. AhRat initially spread in August 2022 on the Google Play Store via an update containing malicious code to the previously benign application, “iRecorder – Screen Recorder,” which itself was released in September 2021.[1]
S1079: BOULDSPY
S1185: LightSpy
First observed in 2018, LightSpy is a modular malware family that initially targeted iOS devices in Southern Asia before expanding to Android and macOS platforms. It consists of a downloader, a main executable that manages network communications, and functionality-specific modules, typically implemented as `.dylib` files (iOS, macOS) or `.apk` files (Android). LightSpy can collect VoIP call recordings, SMS messages, and credential stores, which are then exfiltrated to a command and control (C2) server.[1]
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.1 | Current bundle | 7fec5fef98b5… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Android-VerifiedBoot
Android. (n.d.). Verified Boot. Retrieved December 21, 2016.
Open source URL -
[2]
NIST Mobile Threat Catalogue APP-26Open source URL
-
[3]
NIST Mobile Threat Catalogue APP-27Open source URL
-
[4]
mitre-attack T1398Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.