Evaluate anti spyware protection by following the victim’s journey, deciding which spyware behaviours your app can see from inside, and testing responses that stop the harm without locking genuine customers out. Mobile spyware that targets apps usually watches screens, reads notifications or input, or lets a fraudster drive the session remotely. An app can detect much of that on its own screens. It cannot scan the whole device or confirm an infection the way incident responders do. This guide covers Android and iOS, which expose very different behaviours, and is written for fraud and security teams working together.
The Otukan control is covered on anti spyware.
Attack behaviour
Start with how customers become victims, then list what the spyware does once it is in place.
Victim journey
- How does the spyware reach the phone: a link in a message, a fake app update, a caller asking the customer to install something?
- What permission or setting does the customer grant along the way, such as accessibility access or screen sharing?
- What happens next in your app: a login, a code entry, a transfer approved while someone else watches?
- Where do complaints arrive first: support calls, disputes, app reviews?
Observable behaviour
| Behaviour | What it harms | Android | iOS |
|---|---|---|---|
| Screen recording or casting | Codes, balances, personal data on screen | Capture callbacks on recent releases; secure screens are excluded from capture | Capture and mirroring state visible to the app |
| Overlay on the app | Credentials typed into a fake layer | Signals the app can check | Third-party apps cannot draw over other apps |
| Accessibility service reading or tapping | Screen content and actions | Enabled services visible within package visibility rules | Not available to third-party apps |
| Notification reading | One-time codes in notifications | Other apps can hold notification access; keep codes out of notification text | Not available to third-party apps |
| Keyboard capture | Passwords and codes | Keyboard learning can be limited on sensitive fields | Third-party keyboards can be declined |
| Remote control | A fraudster drives the session | Combined screen and input signals | Screen sharing state |
- Which rows match the cases your fraud team has seen?
- Which screens show the data a spyware operator wants most?
Detection limits
Be clear about three different jobs before comparing solutions.
| Job | Question it answers | Who does it |
|---|---|---|
| App-visible signals | Is something watching or driving this app, right now? | The app, with a solution such as Otukan |
| Whole-device scanning | Which installed apps are malicious? | Platform protections and device security products |
| Incident confirmation | Was this customer’s phone compromised, and how? | Forensic and incident response teams |
An in-app solution that claims to do all three deserves hard questions. Ask each option:
- Which behaviours does it detect on Android, and which on iOS, listed separately?
- Does it detect behaviour aimed at your screens, or rely on lists of known app names?
- What permissions does it need, and would they pass your store review?
- How does it tell a screen reader or password manager apart from spyware?
How Otukan answers. Otukan detects recording, casting and mirroring while your sensitive screens are shown, and on Android it detects overlays and accessibility services acting on your screens. It protects sensitive screens from capture and sensitive fields from third-party keyboards, and it flags remote control during a session. It reports what it saw to your backend; it does not claim to scan the device or diagnose an infection.
Response
A spyware signal usually means the customer is a victim, not an attacker. Test responses that respect that.
Proportionate controls
- On balance and history screens, hide sensitive values while capture is active.
- On code entry and login, pause and warn when an overlay or active accessibility service is seen.
- On transfers and payee changes, hold the action and route it to your fraud engine.
- Decide which flows end the session and which only record the signal.
Support paths
- Write the in-app message: what happened, what the customer should do, how to reach you.
- Give support staff a script that explains the signal without accusing the customer.
- Decide how a held transaction is released after the customer is verified.
Legitimate tools
- Run each sensitive flow with a screen reader, a password manager and an approved remote support tool.
- Confirm each one completes, perhaps with a step-up, and record any false signal.
How Otukan answers. Otukan applies the response you set per flow (observe, warn, restrict or terminate) and sends the signal with the request so your fraud engine can hold or release it. We reproduce each behaviour with a test app in an authorised lab, never on a customer’s device, and confirm your agreed assistive tools stay unaffected.
In-app malware signals are covered on mobile app malware detection, and the wider programme is covered on mobile fraud prevention. Evaluating malware detection is covered on the malware detection solution guide.