Evaluate phishing and smishing detection at the points where a campaign has to touch your app, because that is where it can be stopped. The lure itself arrives by text, messaging app or email, and filtering it is the job of carriers and the operating system. Otukan catches what follows inside your app: a counterfeit copy installed from a link, harvested credentials replayed from an unfamiliar device or an automated session, and smishing-delivered malware acting on your screens on Android. Prove each signal in an authorised lab, confirm genuine customers stay quiet, then set a response per flow on Android and iOS.
Attack behaviour: from message to account
A phishing campaign is a short chain. Only some links in it run inside your app, and those are the ones worth measuring.
The victim journey
| Stage | What the attacker does | Visible to your app |
|---|---|---|
| Lure | Sends a text about a parcel, a blocked card or a tax refund, with a link | No |
| Landing | A fake web page collects the password and the one-time code | No, though the stolen details reappear later |
| Install | The link offers a lookalike app, a repackaged copy of yours or a helper app that asks for accessibility access | Partly: integrity, installation source and malware behaviour |
| Use | Stolen credentials are entered into your genuine app from the attacker’s device or tooling | Yes: unbound device, emulator, automation |
| Cash-out | Payee change, transfer or limit increase | Yes, as the flow the other signals are weighed against |
How smishing differs on each platform
On Android, a text link can lead to an app installed from outside the store. That app may be a copy of yours with a modified login, or malware that later draws over your screens or reads them through accessibility. On iOS, installing apps outside the App Store is more restricted, so smishing there mostly aims at passwords and one-time codes typed into a fake page. The signals that matter differ, and Otukan scopes each one to its platform.
Detection limits: app signals versus device scanning
A sound evaluation separates what the app sees from what only a device scanner, a carrier or an investigator can see. Otukan owns the first part.
What Otukan reports from inside your app
- A repackaged or modified copy of your app, through integrity checks on code, resources and signing identity.
- On Android, the source your app was installed from.
- A login from a device not bound to the account, or from an emulator or scripted session.
- On Android, overlays and accessibility services acting on your screens.
What sits outside app visibility
Otukan does not read text messages, messaging apps or browser history, and it is not a whole-device scanner. The fake website sits outside the app, and confirming that a specific customer was phished is a job for your fraud team, your records and the customer. Otukan labels every signal as a detection, so your team can match it to confirmed cases.
Behaviour-to-signal matrix
This is the table your team fills in during evaluation. Each row pairs an authorised reproduction with a negative control.
| Behaviour reproduced | Expected signal | Negative control that should stay quiet |
|---|---|---|
| Repackaged copy of your app installed from a link | Integrity signal from the copy | Store release on a clean device |
| Your app installed from an unknown source (Android) | Installation-source signal | Store install and any enterprise channel you declare |
| Harvested credentials used on a second device | Unbound-device signal at login | Genuine customer on an enrolled device |
| Credential stuffing from an emulator | Emulator and automation signals | Your QA devices, declared in the policy |
| Malware drawing over the login screen (Android) | Overlay signal | Assistive tools the customer relies on |
Response: proportionate controls and support
Phishing victims are your customers. The response should stop the attacker’s session while keeping the genuine owner’s route open.
- Start in observe. Measure how often each signal appears among real users before changing any journey.
- Step up on unfamiliar devices. A login from an unbound device asks for verification the attacker is unlikely to hold.
- Hold the cash-out steps. New payees, limit changes and device enrolment wait when phishing signals are present.
- Explain in plain words. The app tells the customer what was noticed and that your staff will never send a link asking for a code.
- Recover inside the genuine app. Reset credentials, remove unknown devices and re-enrol the phone the customer actually holds.
Support teams need the same view. When a customer calls about a blocked step, the agent should see which signal fired and on which platform, and walk the customer through recovery rather than repeat the check.
For the full set of fraud controls, see mobile fraud prevention. Coached payments without stolen credentials are covered on social engineering protection.
If your app is already in the stores, you can request a free App Exposure Check of the public release.