Dangerous Permissions: How Android Malware Abuses Consent

Last updated on 21 Aug 2026

Ask most people whether they review the permissions an app requests before installing it and the honest answer is no. Requests to access contacts, track location and read the calendar get tapped through with barely a pause, often by people who work in security and know better. There is a general sense that more care would be sensible. There is also a widespread assumption that the downside is modest: a bit more tracking than is ideal, nothing worth losing sleep over.

That assumption remains the single most serious security exposure the average Android user will ever create for themselves. When Corrata last examined this in 2022, the reference points were Flubot, Hydra and Autolycos. Those families are gone. The technique is not.

Every significant Android banking trojan operating today, including Anatsa, Octo, Hook and Crocodilus, depends on persuading a user to grant one or two powerful operating system capabilities. What has changed since 2022 is that Google has spent four years building defences against exactly this, and attackers have engineered around each one within months.

It is worth understanding both halves of that story.

Android permissions and consent

The first thing to grasp is the difference between what Android enforces and what Google Play enforces.

Android’s rules are enforced by the operating system. Short of running an unsafely modified build, an app cannot simply ignore them. Google Play’s rules are policy, enforced through app review. Review is a genuinely difficult job at Play’s scale, and it does not achieve full compliance. Apps installed from outside Play have historically sat outside that policy net entirely.

That distinction still matters, though it is now blurrier than it was, for reasons covered further down.

Android confusingly uses the word “permission” for the APIs an app uses to interact with the operating system, most of which never involve the user at all. It is more useful to think in three tiers.

Install-time permissions are granted automatically when the app is installed. They give an app limited access to restricted data and allow actions that minimally affect the system or other apps: sending and receiving data, downloading files, reading Bluetooth settings, running in the foreground. Not requiring consent for these is deliberate. It preserves the user’s attention for the requests that actually matter.

Runtime permissions, which Android formally classifies as “dangerous”, require an explicit consent prompt. These cover:

• Phone: making and receiving calls, and reading call logs
• SMS: reading and sending messages
• Camera and microphone
• Location, physical activity and body sensors
• Calendar and contacts
• Photos, video and audio, split into separate categories since Android 13, with partial “selected items only” access added in Android 14
• Notifications, which became a runtime permission in Android 13
• Automatic connection to nearby devices over Bluetooth or Wi-Fi

Special permissions are the third tier, and the one that matters most from a security perspective. These are not granted through a runtime dialog at all. The user has to go into Settings and turn them on deliberately, because the capability they confer is too broad for a one-tap prompt. This tier includes accessibility services, notification listener access, display over other apps, usage access, all-files access, device admin, and permission to install other apps.

Almost all serious Android malware abuse happens in that third tier.

Why accessibility services are the prize

It is obvious why granting an app your camera, microphone or SMS messages is risky. It is less obvious why accessibility services should be a concern, given the name suggests something benign.

Accessibility services exist so that people with disabilities can use their phones. The API lets an app read the contents of the screen, understand what is displayed, and perform inputs on the user’s behalf. Screen readers and alternative input systems could not function without it.

The same capabilities are exactly what an attacker wants. Once accessibility is granted, an app can observe every action the user takes, capture keystrokes, read message content, and record anything that appears on screen. It can also draw over the screen and replace what is displayed with content of its own. Malware uses this to harvest credentials, present convincing fake login pages, suppress security warnings and keep itself hidden.

Crocodilus, first documented by ThreatFabric in March 2025 and since observed worldwide, is a good illustration of how mature this has become. It monitors app launches and displays overlays over banking and cryptocurrency apps to intercept credentials. It logs every accessibility event, which functions as a keylogger without ever needing keyboard access.

It reads one-time passcodes directly off the screen while an authenticator app is open. And it can display a black overlay while muting the device, so that fraudulent transactions are carried out on a screen the victim believes is off.

SMS permission is the other perennial target. The simplest abuse is billing fraud, where a user is subscribed to a premium service and the operator’s notification is intercepted and suppressed. The more damaging use is interception of one-time passcodes sent for two-factor authentication. Combined with accessibility abuse, this gives an attacker the credentials and the second factor in a single chain.

What Google has done since 2022

Google has hardened this area substantially, in four distinct moves.

Restricted Settings, Android 13 (2022)

Apps installed from outside an app store are blocked from being granted accessibility service access and notification listener access. Android identifies these apps by the installation method used, so an APK opened from a browser, messaging app or file manager is treated as sideloaded. The user can still override this on a per-app basis, but the path is deliberately obscure.

Expanded Restricted Settings, Android 15 (2024)

The same protection was extended to cover display over other apps, usage access and device admin, closing the most obvious workarounds.

Advanced Protection Mode, Android 16 (2025)

A single setting that applies a set of hardened configurations for users at elevated risk, including journalists, activists and public figures. Among other things it blocks installation from unknown sources outright, disables 2G, restricts USB data access when locked, and reboots the device after prolonged inactivity.

Google has been testing a further extension that would prevent accessibility permission being granted to any app that does not declare itself an accessibility tool, and would automatically revoke it from apps already holding it.

Developer verification, rolling out now

This is the largest structural change to Android app distribution in years. Google’s stated rationale is that it found over ninety times more malware coming from sideloaded sources than from Google Play. From 30 September 2026, apps must be registered to a verified developer in order to be installed or updated on certified Android devices in Brazil, Indonesia, Singapore and Thailand, with global rollout planned from 2027.

Sideloading of unregistered apps remains possible through an “advanced flow” that began rolling out in August 2026, but it now carries a one-time waiting period of a day, specifically designed to break the high-pressure scam scripts that talk victims through disabling their own protections in real time.

Taken together, this is a serious body of work. It has meaningfully raised the cost of the attack.

Why it isn’t enough

It has not eliminated it.

Crocodilus is delivered by a purpose-built dropper that bypasses the Android 13 and later restrictions and installs the payload in a state where accessibility can be granted normally. It is not alone in this. Dropper development is now a distinct specialism in the mobile malware economy precisely because Restricted Settings made it necessary. The families that matter have all adapted.

The deeper issue is one of visibility rather than capability. Every control described above operates at the level of a single device, configured by a single user, with no reporting to anyone else. Advanced Protection Mode is opt-in and, by Google’s own framing, aimed at high-risk individuals rather than at a typical employee.

Restricted Settings can be overridden by the same user who was just persuaded to install the app. Developer verification will not reach most markets until 2027 and does not govern what a verified app asks for once installed.

So an IT security team asking a reasonable question, namely which devices in our fleet currently have accessibility, SMS or overlay permission granted to an app that has no business holding it, still has no way to answer it from the platform alone.

What this means for enterprise mobile fleets

The obvious response is to tell colleagues to be vigilant, review permission requests carefully and never sideload. In our experience this is close to useless on its own. Laptops still carry some residual aura of a work machine and are used with a degree of care. Phones are stitched into daily life and used informally. Consumer apps have spent fifteen years training everyone to grant whatever is asked as fast as possible.

Policy that depends on a user making the right decision at the exact moment an attacker has engineered urgency is not policy, it’s hope.

What works is making the permission itself visible to someone other than the person who granted it, and making that visibility actionable. Not a full inventory of everything an employee has installed, which is neither necessary nor proportionate, but a signal when an app on a work device has acquired a capability it has no legitimate reason to hold.

This is the gap Corrata was built to close.

Corrata identifies apps that request permissions which are not acceptable from a security perspective, alongside apps carrying known high-severity vulnerabilities. Accessibility is treated as the priority case. Where a user has granted accessibility permission to an app, Corrata surfaces the detail of that app to the security team, which serves as an early warning that a user may be exposed well before any credential theft occurs.

Crucially, this is done without inventorying every app on an employee’s phone. Corrata takes an exception reporting approach: information is shared with the service backend only when a clear security concern has been identified. Employee privacy and security visibility are usually presented as a trade-off. They do not have to be.

Detection is only half of it. Corrata provides alerting, blocking and quarantining to manage the risk once an app has been flagged. Where an app is identified as malware, the Corrata app prompts the user directly to remove it. Dangerous permission findings are handled differently, reported to the admin console rather than to the user, so that the security team decides whether a given app and permission combination is acceptable in their environment.

Corrata’s console shows the types of device threats detected, including Dangerous Permission App

Where a device cannot be trusted, it can be quarantined and denied access to corporate applications until the situation is clear. And because Corrata inspects traffic on the device, communication with command and control infrastructure can be blocked, which cuts off the exfiltration path even where a compromised app is still present.

That last point matters for the threats described earlier in this post. A trojan that has successfully bypassed Restricted Settings and obtained accessibility permission still has to reach its C2 server to receive its target list and its overlays, and still has to send the harvested credentials and passcodes somewhere. Interrupting that traffic breaks the attack chain at the point the attacker cannot design around.

Where this leaves us

The openness of the Android ecosystem has brought real capability and real benefit to billions of people. That same flexibility creates work for those of us trying to keep organisations safe.

The direction of travel is encouraging. Google is closing the gaps faster than it was in 2022, and developer verification in particular will change the economics of malicious distribution once it reaches scale. But the pattern of the last four years is consistent: each control raises the cost of the attack without ending it, and the interval between a defence shipping and a working bypass appearing is measured in months.

For anyone responsible for a fleet of devices, the practical conclusion has not changed since 2022. User consent is the weakest link in mobile security, and it cannot be defended by asking users to be more careful.

Frequently asked questions

Is the nearby devices permission safe?

For most apps, yes. Nearby devices covers scanning for and connecting to Bluetooth and Wi-Fi devices. It is actually more privacy-protective than what it replaced, because before Android 12 an app had to request full location permission just to scan for Bluetooth. Question it when an app has no obvious reason to connect to anything. A headphone or smartwatch app needs it. A torch or photo editor does not.

Which Android permission can be used to steal your contacts?

READ_CONTACTS. It gives an app your entire address book, including names, numbers, email addresses and any notes stored against a contact. Android classifies it as dangerous, so an app must ask explicitly and you can revoke it under Settings, Apps, Permissions. On a work phone the exposure extends beyond the individual to colleagues, customers and suppliers who never consented to anything.

What are dangerous permissions on Android?

Dangerous permissions are capabilities that require explicit user consent because they access sensitive data or affect privacy: contacts, camera, microphone, location, calendar, SMS, call logs, photos and body sensors. Lower-risk permissions such as internet access are granted automatically at install. A third and more powerful group, including accessibility services and display over other apps, must be enabled manually in Settings, and this is where most malware abuse occurs.

Why is accessibility permission considered the most dangerous?

Because it lets an app read everything on screen and act on the user’s behalf. It can capture keystrokes and message content, log every interaction, and draw its own content over other apps. Attackers use it to place fake login pages over banking apps, harvest credentials and one-time passcodes, and conceal their presence. Very few legitimate apps need it, which makes it a useful signal for a security team.

How can an organisation see which apps have risky permissions?

Android offers no native way to see this across a fleet, because every control Google has built is configured on a single device by the person holding it. Mobile threat defence fills that gap. Corrata identifies apps requesting permissions that are unacceptable from a security perspective and reports them to the admin console, using exception reporting so a full inventory of an employee’s apps is never collected. Alerting, blocking and quarantining are then available to manage the risk.