OldBoot is Android malware that targets the device at boot time so it can persist across restarts. It is associated with root-level persistence and hidden control over an infected phone. Defenders should look for signs of compromise that survive reboots, unusual system changes, and devices that cannot be cleaned without reimaging.
How OldBoot Works at the Boot Level
OldBoot is dangerous because it aims for the earliest trustworthy moment in the device lifecycle, before the user has a normal chance to notice or remove it. Boot-time malware can hook into startup paths, alter system behavior, and regain control every time the phone restarts.
That persistence changes the defensive problem from “remove a bad app” to “verify whether the operating system itself has been tampered with.” When malware survives reboot, ordinary app-level cleanup may be ineffective, and the device may remain untrustworthy until it is rebuilt from a known-good image.
Why Boot Persistence Is Hard to Remove
Boot persistence is effective because it can operate below the level where many mobile security tools and users usually look. If malware modifies startup components, hides itself from the launcher, or reintroduces malicious code during initialization, the visible symptoms may disappear while the compromise remains.
That is why defenders treat reboot-surviving changes as a strong compromise signal. A device that continues to show unusual settings, modified binaries, broken system integrity, or unexplained privilege changes after restart should be handled as potentially rooted or systemically altered, not merely “infected with an app.”
What Defenders Should Check
Exposure review starts with the device itself, then extends to the environment around it. Teams should confirm which Android devices are in use, whether any are jailbroken or rooted, and whether there are signs of sideloading, tampered system partitions, or abnormal persistence after reboot.
For evidence, compare the device state against a known-good baseline and look for configuration drift that cannot be explained by normal updates. If a phone cannot be returned to a trusted state through standard remediation, reimaging is usually the safer path than repeated cleanup attempts.
Signs worth correlating include unusual startup behavior, missing or hidden apps, unexplained accessibility or device-admin changes, and repeated reinfection after resets. Those indicators often matter more than a single malware alert because they show whether the compromise has become part of the boot chain or system state.
Security Consequences for the Device and User
Boot-time malware can create long-lived control over the phone, which raises the impact beyond simple data theft. Once the attacker can re-establish presence at startup, they may be able to observe activity, interfere with security controls, and retain access even when the user believes the device has been cleaned.
That persistence also increases the chance of credential exposure, session abuse, and continued surveillance through the handset. On mobile devices, the risk is not only that malware runs, but that it becomes a durable control point for future collection and manipulation.
Risk and Threat Considerations
OldBoot is risky because boot-level persistence makes compromise durable and makes ordinary removal steps unreliable. The main concern is not just infection, but the possibility that the operating environment itself has been altered so the attacker can keep control across restarts.
Failure mechanism: Malware that reaches startup or low-level system components can survive reboot, hide from casual inspection, and reassert control after partial cleanup or user reset attempts.
Impact: The device may remain untrusted, sensitive data may continue to be exposed, and defenders may need to reimage the phone rather than rely on app removal or routine cleanup.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1542.003 — Boot or Logon Autostart Execution | OldBoot persists by running at startup on Android devices. |
| T1012 — Query Registry | Persistence often leaves configuration and system-state traces defenders can inspect. | |
| Recommendation — Map startup persistence to T1542.003 and hunt for boot-time tampering and re-entry points. Check for abnormal startup and system-state changes that indicate persistence mechanisms. | ||
| CIS Controls v8 | CIS-10 — Malware Defenses | The term concerns malware persistence and detection on endpoints. |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | Boot compromise often relies on altered device configuration and tampered settings. | |
| Recommendation — Apply malware defenses and endpoint monitoring to detect persistent mobile compromise. Baseline mobile device configuration and investigate drift that survives reboot. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | Persistent mobile compromise threatens stored data on the device. |
| Recommendation — Protect device-stored data and assume compromised storage may expose sensitive information. | ||
Practitioner Guidance
What to watch for: Treat reboot-surviving anomalies as a system integrity problem, not a normal mobile-malware event. If the device keeps showing the same suspicious behavior after a restart, assume the compromise may be embedded in startup state or system components.
Practitioner takeaway: For suspected OldBoot-style compromise, the decision point is whether the handset can still be trusted after reboot, if not, rebuild it from a clean source rather than trying to “clean around” the persistence.