{ "id": "d29aaf27-c832-4a3b-83e9-a1b24108a0e9", "created_at": "2026-04-06T00:12:21.588489Z", "updated_at": "2026-04-10T03:22:09.372239Z", "deleted_at": null, "sha1_hash": "827b517f14aa4450b096f71660fb614ee7de75f9", "title": "‘SAW’-ing through the UI: Android overlay malware and the System Alert Window permission explained", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 234914, "plain_text": "‘SAW’-ing through the UI: Android overlay malware and the\r\nSystem Alert Window permission explained\r\nPublished: 2017-05-25 · Archived: 2026-04-05 23:51:12 UTC\r\nOver the past month, we’ve talked about a troublesome Android app permission called\r\n`SYSTEM_ALERT_WINDOW` a few times. This week, researchers from University of California Santa Barbara\r\nand Georgia Institute of Technology released details about “Cloak and Dagger” a collection of attacks that take\r\nadvantage of this permission. Customers1 have asked me about `SYSTEM_ALERT_WINDOW` (abbreviated\r\nSAW for the purposes of my oh-so-witty headline) and how malware might abuse the Android overlay view to\r\nsteal log-in credentials and the like from Android users. I wanted to explain the Android app permission in plain\r\nlanguage, how it might be abused, and finally what people can do to mitigate the risk.\r\nWhat is Android screen overlay and what’s it for?\r\nAn Android overlay, screen overlay, or “Draw On Top”, allows an app to display content over another app. The\r\nAndroid app permission SYSTEM_ALERT_WINDOW  makes this possible. If you’ve ever used an app like Facebook\r\nMessenger or Lastpass, you’ve experienced screen overlay in action. Basically, the permission allows a developer\r\nto display content on the screen of your Android device after some trigger event.\r\nhttps://www.nowsecure.com/blog/2017/05/25/android-overlay-malware-system-alert-window-permission/\r\nPage 1 of 5\n\nFor example, you may have seen the cute notification bubble in Facebook Messenger (also called a “chat head” —\r\nsee the screenshot above) that includes a contact’s photo. If you tap the chat head, it leads to a pop-out version of\r\nthe Messenger app. Have you noticed that you never gave Facebook Messenger permission to display that bubble?\r\nWhat Kinds of Testing Do You Need?\r\nWHAT TO READ NEXT:\r\nUse this mobile app security testing checklist to take the attacker’s point-of-view on real iOS and Android devices.\r\nhttps://www.nowsecure.com/blog/2017/05/25/android-overlay-malware-system-alert-window-permission/\r\nPage 2 of 5\n\nAndroid Marshmallow (specifically Android 6 API Level 23), introduced the requesting of permissions at runtime.\r\nIf an app wanted to access your calendar, camera, and other functionalities, the user needed to grant the\r\npermission. Unfortunately, that’s not always true of SYSTEM_ALERT_WINDOW . If a developer targets a lower API\r\nlevel like API level 22 in Android 5 (Lollipop), the Google Play store grants the permission without a runtime\r\nprompt. If your device uses Android 6.0.1 or higher and you install an app requesting the SYSTEM_ALERT_WINDOW\r\npermission, it’s granted by default! What this all means is that the only time a user will manually grant the “Draw\r\nOver App” permission is if they run Android 6.0.0 and the app is built for API level 23 or above, or when side-loading an app from a third-party Android app store (something we usually recommend against for security’s\r\nsake).\r\nIn one example of Android overlay malware, a malicious flashlight app actually turned out to be\r\nbanking trojan malware.\r\nThis blows my mind, because if someone were so inclined, they could potentially compromise a user’s phone with\r\nthe SYSTEM_ALERT_WINDOW permission using Android overlay malware. Overlay malware is not a new\r\nconcept, and the Google Play Store has published a number of malicious apps that abused the Android screen\r\noverlay. The apps typically pose as something harmless. In one example of Android overlay malware discovered\r\nby ESET,  a malicious flashlight app actually turned out to be banking trojan malware.\r\nMobile Risk Tracker\r\nNew NowSecure MobileRiskTracker™ – A Game Changer with Live Industry AppSec Scores\r\nPotential abuses of the System Alert Window permission\r\nGenerally, these attacks play out something like this\r\n1. A user downloads the malicious app\r\n2. A trigger activates the use of the SYSTEM_ALERT_WINDOW permission to display content over the top of the\r\nUI\r\n3. The screen asks the user for information, such as credentials, and the user divulges that information to\r\nmake the screen overlay go away\r\nThe SYSTEM_ALERT_WINDOW permission makes a number of attacks possible, but overlay attacks seem to be the\r\nmost prominent at this time. Once a malicious app has been installed on your device, the app will wait for the user\r\nto launch a target app. When the target app is launched, the malicious app produces an overlay to trick users into\r\nentering their credentials into a phony login screen. The user’s credentials are then sent to the attacker’s server.\r\nThe animation below demonstrates what an attack might look like on a victim’s phone. You can find the sample\r\nmalware I used for the demonstration on GitHub: https://github.com/geeksonsecurity/android-overlay-malware-example.\r\nhttps://www.nowsecure.com/blog/2017/05/25/android-overlay-malware-system-alert-window-permission/\r\nPage 3 of 5\n\nHere’s what you’re seeing in the video:\r\n1. The user launches the Skype app\r\n2. The phony login screen is overlaid on top of the authentic login page\r\n3. After information is entered into the malicious screen, you see the actual Skype login page\r\nAndroid overlay attacks and ransomware\r\nWith ransomware concerns rising in the wake of the WannaCry attack earlier this month, there have been some\r\nsuggestions that overlay screens could be used to launch a ransomware attack on Android devices. This is pure\r\nspeculation, but malware could potentially display an overlay screen demanding credit card information to make it\r\ngo away. It’s possible some users will fall for the ploy when in reality their files weren’t encrypted or inaccessible\r\nand they could have exited the app via other means.\r\nWith that said, the Cloak and Dagger researchers have published a video demonstration of a clickjacking attack\r\nthat might make such an attack possible. An overlay screen is displayed on top of the UI that includes “holes” that\r\na user can be persuaded to click. Essentially, the user is “clicking through” the overlay screen to certain areas of a\r\nUI behind it. The clickjacking technique leverages both the SYSTEM_ALERT_WINDOW and\r\nBIND_ACCESSIBILITY_SERVICE . Such a technique could be repeated multiple times resulting in the user\r\nunknowingly clicking the settings interface to grant an app enough permissions culminating in the complete\r\ntakeover of an Android device.\r\nAlso of concern is that nothing currently indicates to an app that another app is overlaying its UI. And this may be\r\npossible via apps published on the Google Play store, not a third-party app store. While it might be tempting to\r\ncall this a bug that can be patched, it seems like a fundamental flaw in Android’s permissions design.\r\nHow can I protect myself against abuse of the System Alert Window permission?\r\nhttps://www.nowsecure.com/blog/2017/05/25/android-overlay-malware-system-alert-window-permission/\r\nPage 4 of 5\n\nAccording to the Cloak and Dagger paper, an estimated 10 percent of apps on the Google Play store use the\r\nSYSTEM_ALERT_WINDOW permission. While an administrator might tempted to prohibit users from installing apps\r\nthat request SYSTEM_ALERT_WINDOW , doing so would likely result in a staff revolt.\r\nSome of the most popular apps on the store call on the SYSTEM_ALERT_WINDOW — not just malware. Users can see\r\nwhat apps have the permission using the instructions in the table below (instructions may not apply to all devices).\r\nVersion How to review apps with Draw Over Other Apps permission\r\nAndroid 7 Settings \u003e Apps \u003e “Gear symbol” \u003e Special Access \u003e Draw over other apps\r\nAndroid 6 Settings \u003e Apps \u003e “Gear symbol” \u003e Draw over other apps\r\nAndroid 5 Settings \u003e Apps \u003e Select app and look for “draw over other apps”\r\nIn addition, before downloading an app, you can check to see if the app uses the `SYSTEM_ALERT_WINDOW`\r\npermission by reading the “Permission Details” on the app’s page in the Google Play Store and looking for a\r\n“draw over other apps” bullet.\r\nWhat makes these `SYSTEM_ALERT_WINDOW`-based attacks so scary is Google’s app vetting process has\r\nfailed to identify a few of these apps before they’re published on the public app store. Google has, however,\r\nstarted tackling this issue in Android O. There are reports that the beta version of Android O includes a mechanism\r\nthat will notify users that app overlay is taking place. While this is a step in the right direction, Google might need\r\nto consider treating the overlay permission in the same way it treats camera permissions. Still, users stuck on older\r\nversions of Android could still fall victim.\r\nSuch security issues demonstrate the importance of enterprises vetting third-party mobile apps for security,\r\nprivacy and compliance issues before employees install them on their mobile devices and continuously monitoring\r\nthe entire mobile app portfolio for visibility into risks.\r\n1\r\n Special thanks to Dan Dumitrescu, security specialist at a financial institution.\r\nSource: https://www.nowsecure.com/blog/2017/05/25/android-overlay-malware-system-alert-window-permission/\r\nhttps://www.nowsecure.com/blog/2017/05/25/android-overlay-malware-system-alert-window-permission/\r\nPage 5 of 5", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://www.nowsecure.com/blog/2017/05/25/android-overlay-malware-system-alert-window-permission/" ], "report_names": [ "android-overlay-malware-system-alert-window-permission" ], "threat_actors": [ { "id": "75108fc1-7f6a-450e-b024-10284f3f62bb", "created_at": "2024-11-01T02:00:52.756877Z", "updated_at": "2026-04-10T02:00:05.273746Z", "deleted_at": null, "main_name": "Play", "aliases": null, "source_name": "MITRE:Play", "tools": [ "Nltest", "AdFind", "PsExec", "Wevtutil", "Cobalt Strike", "Playcrypt", "Mimikatz" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1775434341, "ts_updated_at": 1775791329, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/827b517f14aa4450b096f71660fb614ee7de75f9.pdf", "text": "https://archive.orkl.eu/827b517f14aa4450b096f71660fb614ee7de75f9.txt", "img": "https://archive.orkl.eu/827b517f14aa4450b096f71660fb614ee7de75f9.jpg" } }