RAGBAZthe five-phase loop
A repeatable investigation loop and the six persistence surfaces it targets. This is the conceptual spine every lab hangs from.
DFIR, not pentesting
You are not attacking a target — you are examining a device you own for indicators of compromise. That single reframe changes the mindset from "can I break in" to "what would persistence look like, and where does it hide." Everything below follows from that question.
the loop
Decide if volatile state matters before touching anything. If yes, do not reboot. Weigh network isolation — it preserves data but can tip off an operator. Document the starting state.
Turn symptoms into testable hypotheses: battery/thermal, data volume, unknown apps, unprompted 2FA, overlays. A lead, never a verdict.
Collect to the workstation. Analyze offline. Never trust the subject device to narrate its own state.
Work the six persistence surfaces. The question is always how something survives reboot and resists removal — not merely whether something bad is installed.
IOC list, timeline, confidence level, remediation. For confirmed deep compromise, the honest recommendation is often reflash, not removal.
six persistence surfaces
A backdoor's job is to persist and hide. Learn to check these six places reflexively and you catch the overwhelming majority of stalkerware and commodity RATs.
| surface | why attackers abuse it | where to look |
|---|---|---|
| device admin | Resists uninstall; can lock or wipe. The skill is distinguishing legitimate MDM from stalkerware. | dumpsys device_policy |
| accessibility | Screen-read + input injection. The single most abused surface — banking trojans and RATs live here. | settings get secure enabled_accessibility_services |
| notification listeners | Reads every notification, including OTP / 2FA codes and message previews. | settings get secure enabled_notification_listeners |
| boot receivers | The classic reboot-persistence mechanism. | dumpsys package r android.intent.action.BOOT_COMPLETED |
| overlay | SYSTEM_ALERT_WINDOW — draw over other apps; with accessibility, enables credential-phishing overlays. | dumpsys package | grep SYSTEM_ALERT_WINDOW |
| sideload source | Apps whose installer is null / shell bypassed store review. | pm list packages -i <pkg> |
the caveat that matters most
A sophisticated rootkit with kernel-level access can lie to ADB, hiding its own processes and files from the very queries the triage tools run. Lean on integrity signals it cannot fake from userspace — verified-boot state and bootloader lock — and finish with offline imaging and known-good comparison. A clean triage output does not equal a clean device.