How attackers use overlay attacks to commit mobile fraud

An overlay attack puts a window drawn by another app on top of your app, so that the user types credentials into, or taps on, something the attacker controls. It is an Android attack: it depends on the permission to draw over other apps, which iOS does not grant to third-party apps. To evaluate the risk, a mobile security team needs three things: an understanding of the attack behaviour, a short list of the screens and permissions that matter, and a response policy that does not punish people who rely on assistive technology. This article covers all three for Android apps, and notes where iOS differs.

Behaviour: what an overlay attack looks like

Overlay fraud comes in two shapes. In a credential overlay, malware waits until the banking or wallet app comes to the foreground, then draws a pixel-perfect copy of its login or card screen on top. The user sees the familiar screen and types into the fake one. In tapjacking, the overlay is mostly transparent: the user believes they are tapping something harmless while the touch lands on a real button underneath, such as “Confirm transfer” or “Allow”.

Most overlay families pair the overlay with an accessibility service. The overlay collects what the user types; the accessibility service reads screen content, detects which app is open and can perform taps on the user’s behalf. That pairing is why this article treats overlays and accessibility together.

Malicious interaction or assistive technology?

The difficulty is that every capability above also has a legitimate use. Screen dimmers, blue-light filters, chat bubbles, floating video players and screen readers use the same Android features. Treating every overlay or accessibility service as hostile would lock out real customers, some of whom depend on those tools to use your app at all.

Otukan detects on Android when another app draws over or obscures a protected screen, and identifies accessibility services that interact with your app during sensitive flows. It sends both as signals, so the decision stays with your policy rather than with a fixed rule.

Why this is an Android attack

Android has tightened overlay rules steadily, and each change narrowed the attack without removing it. Knowing the dates helps a team decide which protections come from the operating system on their minimum supported version and which the app must add itself.

iOS works differently. A third-party iOS app cannot draw over another app, so the credential overlay described above has no direct equivalent there. Fraud on iOS reaches users through phishing pages, fake apps and social engineering instead. Otukan builds its overlay detection for Android and never carries an Android assumption over to iOS.

Sensitive flows: screens, actions and permissions

You do not need to protect every screen. Overlay attacks target the moments where the user enters a secret or approves money movement. Start with this list and adapt it to your app.

What the app can do with platform features

Android gives developers two useful controls for the screens above. A view can discard touches that arrive while another window covers it, and, from Android 12, an activity can hide non-system overlays while it is visible. Neither is a full answer on its own: the first only covers the views you mark, and the second only applies on newer versions. They are, however, cheap to adopt.

// Manifest (Android 12, API level 31, onwards):
// <uses-permission android:name="android.permission.HIDE_OVERLAY_WINDOWS" />

class ConfirmTransferActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_confirm_transfer)

        // Hide other apps' overlays while this screen is visible.
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) {
            window.setHideOverlayWindows(true)
        }

        // Ignore touches that arrive while another window covers the button.
        findViewById<Button>(R.id.confirm).filterTouchesWhenObscured = true
    }
}

Runtime detection adds what these settings cannot: evidence. Knowing that a covering window appeared on the login screen, and which kind of service was active, lets your backend weigh the session and lets your fraud team see the pattern across users.

Accessibility: permitted services and proportionate recovery

The accessibility question is where overlay defences most often go wrong. A blanket block on accessibility services turns away users of screen readers and switch access, and many markets expect financial apps to remain usable with them. The goal is to separate services the user relies on from services that act inside your app without being asked.

A proportionate policy moves through clear steps:

• Observe. Record overlay and accessibility signals per screen, with no change for the user, and learn how often they fire across your real audience.
• Warn. Tell the user plainly that another app is covering the screen, and how to close it.
• Restrict. Disable the sensitive action, keep the rest of the app usable, and offer another route such as a second factor or a branch visit.
• Terminate. End the session only when several strong signals combine on a money-moving step.

Every restriction needs a recovery path. Support staff should be able to see which signal fired and guide the user to remove a suspicious app, rather than asking them to switch off assistive tools they need.

For Android specifics, see overlay attack detection. Accessibility malware on its own is covered on Android accessibility malware.

Before you ship overlay protection

• List the screens where users enter secrets or approve money movement.
• Mark confirmation buttons to reject obscured touches, and test them with an authorised overlay test app.
• Hide non-system overlays on those screens from Android 12 onwards.
• Run a regression pass with a screen reader, switch access and a screen dimmer enabled.
• Decide the response for each screen and write down the recovery path for genuine users.
• Confirm the backend receives overlay and accessibility signals with login and payment requests.