Install-Recovery.sh Persistence

What the technique is

Install-recovery.sh persistence is a legacy Android persistence method that turns a recovery-related script into a launch point for attacker commands. It matters because the script may run early in boot or during maintenance paths, giving the attacker a durable foothold that can survive ordinary app removal and remain hidden from casual inspection.

Why it works on legacy Android devices

This technique depends on trust in a system-maintained script path that is expected to execute legitimate recovery actions. On devices where that path is writable or insufficiently protected, an attacker can replace or append commands without needing a full userland implant. The persistence is especially effective when defenders do not routinely verify startup scripts, permissions, and ownership on older builds.

The defensive question is therefore not only whether a malicious file exists, but whether the execution path itself has been altered. A modified recovery script can become a control point for boot-time execution, post-update reentry, or repeated reinstatement of malware after cleanup.

What defenders should look for

Detection starts with integrity checks on the script, its parent directories, and the startup chain that invokes it. Unexpected ownership, unsafe permissions, unfamiliar command content, or a file timestamp that does not match normal device maintenance activity are all useful indicators. On a suspicious device, analysts should also compare the on-device script with known-good images or vendor baselines.

Because this is a persistence technique rather than a standalone payload, defenders should correlate it with other signs of compromise such as new autoruns, unusual shell activity, or post-boot network beacons. The presence of the script modification is often the anchor, but the surrounding process and execution history help confirm whether it was used as a living persistence path.

For broader detection and response patterns around persistence and identity-related abuse, the Identity Threat Detection and Response (ITDR) Guide is useful when the compromise chain includes stolen credentials or reused access paths. For Android-focused persistence, defenders can also compare the technique with the same kind of durable access patterns seen in Salt Typhoon telecom intrusions 2025, where long-lived access and credential abuse supported persistence.

How organisations reduce exposure

The best control is to remove the condition that makes the script writable or executable by an attacker. That means hardening device baselines, restricting shell and maintenance access, protecting partitions and startup paths, and validating that recovery-related components retain expected permissions after updates or repairs. Legacy devices are often the hardest to secure because they may retain old boot logic or vendor customisations long after modern controls became standard.

Where patching or replacement is not immediately possible, compensating controls matter: tighten physical and administrative access, monitor file integrity, and treat unsupported Android builds as higher-risk endpoints. If a device is suspected of compromise, remediation should include restoring trusted firmware or system images rather than only removing a single malicious command line, because persistence often survives partial cleanup.

Risk and Threat Considerations

This technique creates durable exposure because it abuses a path that operators may regard as routine maintenance rather than an attack surface. Once an adversary can change the script, they can re-run code at startup, survive reboots, and re-establish access after superficial remediation.

Failure mechanism: An attacker gains write access to the recovery script or its execution path, then inserts commands that execute during boot or recovery-related events, bypassing normal application-layer cleanup.

Impact: The device can remain persistently compromised, enabling repeated command execution, stealthy reinstatement of malware, and continued exposure of data, credentials, or management access tied to that endpoint.

Practitioner Guidance

What to watch for: Treat any unexpected change to install-recovery.sh, its permissions, or its parent path as a high-priority integrity event. On legacy Android fleets, this should trigger a full device trust review, not just file removal, because the persistence mechanism may indicate broader compromise of the system partition or privileged maintenance access.

Practitioner takeaway: If the boot-time script path is trusted, protect it like a control plane asset, because persistence techniques usually exploit the least-scrutinised path the device is still willing to run.

Related resources from NHI Mgmt Group

• What breaks when package install hooks or startup hooks are used as persistence mechanisms in enterprise environments?
• What breaks when malicious Python packages install persistence through cron, .pth files, and shell startup hooks?
• Why do password stealers create outsized risk even when they do not install persistence?
• Why do install-time hooks and startup persistence increase the risk of malicious npm packages?