Every developer I know has, at some point, gotten the panicked message from a friend or family member: “I think my phone is hacked, can you look at it?” Because most non-technical guides online are either overly alarmist or dangerously oversimplified (“just factory reset it!”), I wanted to write the version I actually use — a methodical, developer-level process for confirming compromise, removing it, and locking the device down afterward, using real tools instead of guesswork.
Step 1: Confirm Compromise Before Acting
Before doing anything destructive, gather evidence. Overreacting (wiping a device that wasn’t actually compromised) destroys forensic value and doesn’t fix the real problem if the issue was, say, a compromised cloud account rather than the device itself.
Common Signs of a Compromised Mobile Device
| Symptom | Possible Cause |
|---|---|
| Rapid battery drain | Background spyware/malware, cryptomining |
| Unusual data usage | Data exfiltration to a remote command-and-control server |
| Unknown apps installed | Sideloaded malware or unauthorized app installation |
| Unexpected pop-ups/ads | Adware, potentially bundled with a legitimate-looking app |
| Device running hot when idle | Background malicious processes |
| SMS/calls you didn’t make | SMS trojan or premium-rate fraud malware |
| Accounts showing unfamiliar login activity | Credential compromise, possibly independent of device malware |
| Settings changed without your input (Accessibility Service, Device Admin enabled) | Malware that escalated permissions post-install |
Step 2: Triage With ADB (Android) or Configuration Profiles (iOS)
Android Triage
# Confirm device connection
adb devices
# List third-party (user-installed) apps
adb shell pm list packages -3
# Check for suspicious accessibility services enabled
adb shell settings get secure enabled_accessibility_services
# Check for device admin apps (used by malware to resist removal)
adb shell dumpsys device_policy | grep -i admin
# Review recent app installs by checking install timestamps
adb shell pm list packages -3 -f | while read -r line; do
pkg=$(echo "$line" | sed 's/package://' | cut -d= -f2)
adb shell dumpsys package "$pkg" | grep -E "firstInstallTime|lastUpdateTime"
done
iOS Triage
iOS’s sandboxing model makes traditional malware less common, but configuration profile abuse, malicious MDM enrollment, and jailbreak-based compromise do occur.
# Check for installed configuration profiles (Settings app, or via libimobiledevice on a connected Mac/PC)
ideviceprofile list
# Look for unexpected MDM enrollment
# Settings -> General -> VPN & Device Management
Any unfamiliar configuration profile or MDM enrollment the user didn’t set up themselves is a strong compromise indicator on iOS, since this is one of the primary mechanisms used for legitimate remote management — and abused for illegitimate surveillance (commonly in stalkerware cases).
Step 3: Identify and Remove the Malicious App(s)
flowchart TD
A[Symptoms Reported] --> B[Connect via ADB / Inspect Profiles]
B --> C[Enumerate Installed Apps & Permissions]
C --> D{Suspicious App Identified?}
D -->|Yes| E[Revoke Device Admin / Accessibility First]
E --> F[Uninstall via adb uninstall or Settings]
F --> G[Pull APK for Analysis if Needed]
D -->|No, but symptoms persist| H[Check Account-Level Compromise]
G --> I[Verify Removal & Monitor]
H --> I
Malware often grants itself Device Admin or Accessibility Service privileges specifically to resist uninstallation attempts. Always revoke those privileges first, or the standard uninstall path may fail or be silently blocked.
# Revoke device admin rights before uninstalling
adb shell dpm remove-active-admin com.suspicious.app/.AdminReceiver
# Then uninstall
adb uninstall com.suspicious.app
# Verify it's gone
adb shell pm list packages -3 | grep suspicious
On the device UI itself (when ADB access isn’t available or convenient): Settings → Apps → [App Name] → Uninstall. If uninstall is greyed out, check Settings → Security → Device Admin Apps and deactivate the suspicious entry first.
Step 4: Address Account-Level Compromise (Often the Real Root Cause)
A huge number of “my phone is hacked” cases are actually account-level compromises — someone’s Google, Apple, or app-specific account credentials were phished or reused from a breached password database, and the “hacking” symptoms the user sees are really just unauthorized access to synced data, not device-level malware at all.
# Check Google account recent security activity
# (via browser) https://myaccount.google.com/security
# Review connected devices under the account
# https://myaccount.google.com/device-activity
Checklist for account hardening:
- Change the account password immediately, using a unique, strong password (ideally generated by a password manager).
- Enable multi-factor authentication (preferably an authenticator app or hardware security key over SMS-based MFA, since SMS is vulnerable to SIM-swapping).
- Review and revoke unfamiliar connected apps/devices under account security settings.
- Check for unauthorized email forwarding rules (a common persistence technique after account compromise) in Gmail/Outlook settings.
- Review recovery email/phone number settings, since attackers sometimes change these to maintain access even after a password reset.
Step 5: Deep Clean and Verification
For Android devices with confirmed or suspected deep compromise (e.g., a malicious app that gained system-level persistence, or symptoms that persist after standard removal):
# Full backup of user data before wiping (photos, documents — NOT apps, to avoid reinstalling malware)
adb pull /sdcard/DCIM ./backup_dcim
adb pull /sdcard/Documents ./backup_docs
# Factory reset via ADB (requires appropriate permissions/OEM unlock in some cases)
adb shell am broadcast -a android.intent.action.MASTER_CLEAR
# Alternatively via Settings -> System -> Reset Options -> Erase All Data (Factory Reset)
After a factory reset, do not restore from a full device backup if malware was suspected — full backups can reintroduce the malicious app along with your data. Instead, selectively restore photos, documents, and contacts, and manually reinstall apps from official stores only.
Step 6: Post-Incident Hardening
flowchart LR
A[Device Cleaned] --> B[Enable Play Protect / App Store Verification]
B --> C[Disable Sideloading / Unknown Sources]
C --> D[Enable Biometric + Strong PIN Lock]
D --> E[Enable Find My Device / Find My iPhone]
E --> F[Apply OS and App Updates]
F --> G[Enable MFA on All Accounts]
G --> H[Periodic ADB/Permission Audits]
- Disable installation from unknown sources (Settings → Security) unless you have a specific, ongoing need for sideloading.
- Keep the OS and apps updated — many mobile compromises exploit known, already-patched vulnerabilities on out-of-date devices.
- Enable Google Play Protect / equivalent built-in scanning, and don’t disable it for convenience.
- Set a strong screen lock (biometric plus a PIN/password fallback, not a simple pattern), since physical access is a common precursor to spyware/stalkerware installation.
- Enable Find My Device (Android) / Find My iPhone (iOS) for remote lock and wipe capability if the device is lost or stolen in the future.
Special Case: Stalkerware and Targeted Surveillance
If the compromise appears targeted — a partner, family member, or employer with unusual insight into the victim’s activity, location, or messages — treat this differently from generic malware. Stalkerware apps are specifically designed to hide from the app drawer and standard uninstall paths, often disguising themselves as system utilities.
- Look for apps with generic names (“System Update,” “Device Health”) with excessive permissions (location, microphone, SMS, call logs).
- Be cautious about how removal is communicated if there’s a safety concern — abruptly removing stalkerware can alert an abuser to being discovered, which may create real-world safety risks. Organizations like the Coalition Against Stalkerware provide guidance specifically for this scenario, including safety planning before removal.
Handling Enterprise and BYOD Scenarios
If the compromised device is enrolled in a corporate Mobile Device Management (MDM) or Enterprise Mobility Management (EMM) platform, the process shifts somewhat. IT and security teams typically have visibility and remote action capability that individual users don’t, and coordinating through that channel first avoids duplicated or conflicting remediation steps.
- Check MDM compliance status first. Most MDM platforms (Intune, Jamf, Google Workspace endpoint management) flag devices that fall out of compliance — unexpected root/jailbreak status, disabled security features, or unapproved app installs — often before the user even notices symptoms.
- Use remote wipe capability judiciously. Enterprise-managed devices typically support selective wipe (removing only corporate data/profile) versus full wipe (erasing the entire device). Understand which is appropriate before triggering either, since a full wipe on a BYOD device destroys the employee’s personal data too.
- Rotate any credentials cached on the device, including VPN certificates, email tokens, and single sign-on session tokens, since a compromised device may have exposed more than just what’s visible through a manual app review.
- File an incident report through your organization’s formal security incident process, even if the device is fully remediated — this creates a record that helps identify patterns if multiple devices show similar compromise indicators, which could point to a broader phishing campaign or targeted attack against the organization.
For personally owned devices without any enterprise management, the responsibility falls entirely on the individual (or the developer helping them), which is exactly the scenario this guide is built around — but it’s worth recognizing when a case has moved beyond a single-device problem into something that needs organizational visibility.
Common Mistakes
- Wiping the device before gathering any evidence of what actually happened, especially in cases that might need law enforcement involvement.
- Restoring a full backup after a factory reset, silently reinstalling the same malware that was just removed.
- Focusing only on the device while ignoring account-level compromise, leaving the actual root cause unaddressed.
- Assuming a factory reset alone re-secures the device without also addressing account credentials, MFA, and update hygiene.
- Removing stalkerware without considering the physical safety implications for the victim.
Preventing Repeat Compromise Long-Term
Once a device is clean and accounts are secured, the final piece is building habits that meaningfully reduce the chance of a repeat incident, rather than just reacting the next time symptoms appear.
- Establish a recurring review cadence. Once every few months, walk through installed apps and their permissions, even without any symptoms prompting it — many compromises go unnoticed for extended periods precisely because nothing dramatic happens on the surface.
- Be deliberate about app installation sources. Sideloading occasionally makes sense for legitimate reasons (testing your own app builds, installing software unavailable in your region’s app store), but each sideloaded app should be a conscious decision, not a default habit.
- Treat SMS-based links and unexpected attachments with the same suspicion on mobile as you would on a desktop email client. Mobile phishing (sometimes called “smishing”) is a major and growing initial vector into personal devices, precisely because people tend to apply less scrutiny to a text message than to an email.
- Keep a mental model of what “normal” looks like for your device’s battery, data usage, and installed app count, so that deviations are easier to notice quickly rather than months later.
FAQs
Is a factory reset always necessary to remove malware? Not always — many Android malware infections can be fully removed by uninstalling the specific malicious app (after revoking any device admin/accessibility privileges it granted itself). Factory reset is a stronger, last-resort option for deeper or uncertain compromises.
Can iPhones get malware the same way Android phones do? Less commonly, due to Apple’s app sandboxing and App Store review process, but iOS devices can still be compromised via malicious configuration profiles, phishing leading to account compromise, or (rarely) sophisticated zero-click exploits, particularly against high-risk individuals.
How do I know if it’s a device problem or an account problem? Check account security activity pages (Google/Apple) for unfamiliar logins or devices first — if you see unauthorized access there but no suspicious apps on the device itself, it’s likely an account-level compromise, not device malware.
Should I involve law enforcement? For cases involving financial fraud, stalkerware from an abusive partner, or targeted surveillance, yes — document evidence first where safely possible, and report to appropriate authorities or platforms like the FBI’s IC3 (for the US) or your local equivalent.
Will antivirus apps catch everything? No single tool guarantees complete detection. Built-in protections (Play Protect, App Store review) plus careful permission auditing (as covered in this guide) provide much stronger practical protection than relying on a single third-party antivirus app alone.
Summary and Recommendations
Removing a hacker from a mobile device is rarely just about deleting one bad app — it’s a process: confirm compromise with real evidence, identify and remove malicious software (revoking its self-granted privileges first), address the very common possibility of account-level compromise, clean and selectively restore data, and harden the device against reinfection. Treat stalkerware cases with extra care given the potential safety implications. Done properly, this process gives both you and the device owner real confidence the problem is actually solved, not just hidden.