{ "id": "f93321ec-62fa-48a6-85cc-608c74ed6045", "created_at": "2026-04-06T00:13:35.394431Z", "updated_at": "2026-04-10T03:32:26.655957Z", "deleted_at": null, "sha1_hash": "38b5bf31befbda5484188ef18734eb55bc559365", "title": "From Two Permissions to Complete Control of the UI Feedback Loop", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 201928, "plain_text": "From Two Permissions to Complete Control of the UI Feedback\r\nLoop\r\nBy Yanick Fratantonio, Chenxiong Qian, Simon Pak Chung, Wenke Lee\r\nArchived: 2026-04-05 13:02:43 UTC\r\nCloak \u0026 Dagger\r\nAttacks · Demos · The Team · Publications · Disclosure · FAQ · Press · Contact us\r\nCloak \u0026 Dagger is a new class of potential attacks affecting Android devices. These attacks allow a malicious app\r\nto completely control the UI feedback loop and take over the device — without giving the user a chance to notice\r\nthe malicious activity. These attacks only require two permissions that, in case the app is installed from the Play\r\nStore, the user does not need to explicitly grant and for which she is not even notified. Our user study indicates\r\nthat these attacks are practical. These attacks affect all recent versions of Android (including the latest version,\r\nAndroid 7.1.2), and they are yet to be fixed.\r\nTL;DR — Main Takeaways\r\nWe uncover a series of vulnerabilities and design shortcomings affecting the Android UI.\r\nThese attacks abuse one or both of the SYSTEM_ALERT_WINDOW (\"draw on top\") and\r\nBIND_ACCESSIBILITY_SERVICE (\"a11y\").\r\nIf the malicious app is installed from the Play Store, the user is not notified about the permissions and she\r\ndoes not need to explicitly grant them for the attacks to succeed. In fact, in this scenario, \"draw on top\" is\r\nautomatically granted, and this permission is enough to lure the user into unknowingly enable a11y\r\n(through clickjacking).\r\nThe possible attacks include advanced clickjacking, unconstrained keystroke recording, stealthy phishing,\r\nthe silent installation of a God-mode app (with all permissions enabled), and silent phone unlocking +\r\narbitrary actions (while keeping the screen off). See the full list below.\r\nThese attacks are practical: we performed a user study (with 20 human subjects), and no user understood\r\nwhat happened.\r\nMost of these attacks are due to design issues, and they are thus challenging to prevent. In fact, one may\r\nsay that some of these functionality work \"as intended\"; Nonetheless, this work shows that this\r\nfunctionality can be abused.\r\nTo date, all these attacks are still practical (see \"Which versions of Android are affected\" and \"Responsible\r\nDisclosure\" below).\r\nList of Attacks\r\nAttacks that abuse the “draw on top” permission:\r\nhttp://cloak-and-dagger.org/\r\nPage 1 of 8\n\nContext-aware clickjacking \u0026 Context hiding: two techniques that make luring the user to enable the\r\naccessibility service practical, even when the latest security mechanisms (e.g., \"obscured flag\") are\r\ncorrectly implemented and enabled. (Note: others have identified ways to use clickjacking to get a11y. See\r\n\"FAQ\" below.)\r\nInvisible Grid Attack, allowing unconstrained keystroke recording, including password, private messages,\r\netc.\r\nAttacks that abuse “accessibility service” permission:\r\nUnconstrained keystroke recording, including passwords. According to the documentation, this should not\r\nbe possible (See \"security note\" here)\r\nSecurity PIN stealing\r\nDevice unlock through PIN injection + perform arbitrary actions while keeping the screen off!\r\nStealing two-factor authentication tokens (SMS-based, Google Authenticator, and other app-based tokens)\r\nAd hijacking\r\nWeb exploration\r\nAttacks that abuse both permissions:\r\nSilent installation of God-mode app (with all permissions enabled)\r\nStealthy phishing (for which the user finds herself logged in, as she would expect)\r\nWhich versions of Android are affected?\r\nHere is the current status (as of June 19th, 2017). Previous versions are very likely to be vulnerable as well.\r\nAttacks\r\nAndroid 5.1.1\r\n(32.0%*)\r\nAndroid 6.0.1\r\n(31.2%)\r\nAndroid 7.1.2\r\n(7.1%)\r\nInvisible Grid Attack vulnerable vulnerable vulnerable\r\nClickjacking → a11y vulnerable vulnerable vulnerable\r\nSilent God-Mode vulnerable vulnerable vulnerable**\r\nStealthy Phishing vulnerable vulnerable vulnerable\r\nPIN stealing vulnerable vulnerable vulnerable\r\nPhone Unlocking (while screen off) vulnerable vulnerable vulnerable\r\nLeaky a11y (passwords, 2FA\r\ntokens, CCs)\r\nvulnerable vulnerable vulnerable***\r\n*Relative numbers of devices running a given version of Android. The numbers are taken from Google's\r\ndashboard, and they are clustered by Android \"main versions\", e.g., \"Android 5.X\".\r\nhttp://cloak-and-dagger.org/\r\nPage 2 of 8\n\n** Google implemented a partial fix (only on Android 7.1.2): \"on top\" overlays do not appear anymore whenever\r\nan app's permission list is shown. However, this is only used for \"normal\" permissions, and not for \"special\"\r\npermissions, such as \"draw on top\" and a11y. This is problematic: since the \"clickjacking → a11y\" is still possible,\r\na malicious app can use the \"Phone Unlocking (while keeping the screen off) attack\" to enable these permissions\r\nwhile keeping the screen off, thus making the silent installation of a God-mode app still practical. We suggest\r\nGoogle to extend their protection mechanism to the entire Settings app (or, at the very least, to \"special\"\r\npermissions as well).\r\n*** Although Google marked our bug report as \"Won't fix\", we noticed that the Google keyboard actually\r\nreceived an update that, at first glance, seems to avoid leaking passwords. In fact, when typing passwords, the\r\naccessibility events generated by the Keyboard app itself now contains \"Dot\" instead of the actual character.\r\nHowever, we found a workaround for our attack: each accessibility event has access to the \"hashcode\" of the node\r\ngenerating the event. Since it's possible to enumerate the widgets and their hashcodes (which are designed to be\r\npseudo-unique), the hashcodes are enough to determine which keyboard's button was actually clicked by the user.\r\nDemos\r\nInvisible Grid Attack\r\nEtt fel inträffade.\r\nDet går inte att köra JavaScript.\r\nContext-aware/hiding Clickjacking + Silent God-mode Install Attack\r\nEtt fel inträffade.\r\nDet går inte att köra JavaScript.\r\nhttp://cloak-and-dagger.org/\r\nPage 3 of 8\n\nStealthy Phishing Attack\r\nEtt fel inträffade.\r\nDet går inte att köra JavaScript.\r\nThe Team\r\nYanick Fratantonio (@reyammer), University of California, Santa Barbara (soon at EURECOM!)\r\nChenxiong Qian, Georgia Institute of Technology\r\nSimon Pak Ho Chung, Georgia Institute of Technology\r\nWenke Lee, Georgia Institute of Technology\r\nYou can reach us by sending an email to team@cloak-and-dagger.org\r\nPublications\r\nCloak and Dagger: From Two Permissions to Complete Control of the UI Feedback Loop\r\nYanick Fratantonio, Chenxiong Qian, Simon P. Chung, Wenke Lee.\r\nIn the Proceedings of the IEEE Symposium on Security and Privacy (S\u0026P), San Jose, CA, May 2017.\r\n[PDF] [Slides] [Talk] Distinguished Practical Paper Award!\r\nBlack Hat USA, Las Vegas, NV, July 2017.\r\n[Black Hat White Paper] [Slides] [Talk]\r\nPlease use the following bibtex entry to cite our work:\r\n @InProceedings{fratantonio17:cloakdagger,\r\n author = {Fratantonio, Yanick and Qian, Chenxiong and Chung, Simon and Lee, Wenke},\r\n title = {{Cloak and Dagger: From Two Permissions to Complete Control of the UI Feedback Lo\r\n booktitle = {Proceedings of the IEEE Symposium on Security and Privacy (Oakland)},\r\n month = {May},\r\n year = {2017},\r\n address = {San Jose, CA}\r\n }\r\n \r\nhttp://cloak-and-dagger.org/\r\nPage 4 of 8\n\nResponsible Disclosure\r\nWe responsibly disclosed our findings to Google's Android security team. A timeline of the disclosure steps and\r\nresponses from Google are posted here (we will keep this updated as time passes):\r\nAugust 22nd, 2016 — We opened several issues on the bug tracker for the Android Open Source Project\r\n(AOSP).\r\nAugust 31st, 2016 — Android security team sets severity as \"Moderate\" for one of the bugs (\"draw on top\"\r\n→ unconstrained keystroke recording).\r\nSeptember 30th, 2016 — Android security team marks one of the reported bugs (\"a11y\" → unconstrained\r\nkeystroke recording + leaking security PIN + unlocking device while keeping the screen off) as \"work as\r\nintended\".\r\nOctober 10th, 2016 — We follow up pointing out that the Accessibility Service's documentation states that\r\na11y should not be able to access passwords (see \"security note\"), and that a11y should not be able to\r\nunlock the device and perform arbitrary actions while keeping the screen off.\r\nOctober 13th, 2016 — Android security team states that \"The password will be repeated if the user\r\nexplicitly turns that on in settings under Settings → Accessibility → Speak passwords. The option is off by\r\ndefault. If the user explicitly enables this feature, it is not a security vulnerability.\"\r\nOctober 14th, 2016 — We follow up clarifying that our attack works even without this feature (In fact, our\r\nreport does not even mention that.)\r\nOctober 18th, 2016 — Android security team marks this bug as \"High severity\".\r\nNovember 28th, 2016 — Android security team downgrades this bug as \"not a security issue\" and marks it\r\nas \"Won't Fix (Intended Behavior)\" because \"limiting those services would render the device unusable\".\r\nDecember 19th, 2016 — A draft of our IEEE S\u0026P'17 paper is shared with Adrian Ludwig, director of\r\nAndroid Security.\r\nMarch 15th, 2017 — We follow up, pointing out that the documentation states otherwise. We also follow\r\nup on all the other bugs we opened, asking for a status update.\r\nMay 3rd, 2017 — We follow up a second time asking for a status update for the bugs we reported.\r\nMay 4th, 2017 — Android security team keeps our a11y findings as \"won't fix\", but they state they will\r\nupdate the documentation. We did not receive updates about the other bugs we reported.\r\nMay 8th, 2017 — We have a telco with the anti-malware and a11y Google teams during which we\r\nthoroughly discussed all the details of our research.\r\nMay 19th, 2017 — The a11y team confirms the a11y-related issues we reported as \"won't fix\".\r\nMay 22nd, 2017 — This website and our research paper at IEEE S\u0026P are made public.\r\nCurrent — All the attacks discussed by this work are still practical, even with latest version of Android\r\n(Android 7.1.2, with security patches of June 5th installed).\r\nFrequently Asked Questions\r\nHow can an app stealthily obtain the two permissions?\r\nA malicious app can declare the \"draw on top\" and the a11y permissions through its manifest file. If the\r\napp is hosted and installed through the Google Play Store, the attacks will not require the user to explicitly\r\nnotify the user about the two permissions. In fact, in this scenario, the \"draw on top\" permission is\r\nhttp://cloak-and-dagger.org/\r\nPage 5 of 8\n\nautomatically granted, and this work shows how it is possible to get access to a11y (through clickjacking)\r\neven when the latest security mechanisms are enabled and correctly implemented.\r\nWhy is the \"draw on top\" permission automatically granted?\r\nThis behavior appears to be a deliberate decision by Google, and not an oversight. To the best of our\r\nunderstanding, Google's rationale behind this decision is that an explicit security prompt would interfere\r\ntoo much with the user experience, especially because it is requested by apps used by hundreds of millions\r\nof users. For example, Facebook requires this permission to implement \"Android chat heads\", one of its\r\nvery popular features.\r\nAre these permissions shown to the user after the app is installed?\r\nThey are not. For Android 5 (or older versions), the list of permissions requested by the app is shown at\r\ninstallation time: however, the \"draw on top\" and the a11y are not included in this list (because they are\r\ntreated as \"special\"). For Android 6 (and later), the list of permissions is not shown to the user at\r\ninstallation time (and, as mentioned above, the \"draw on top\" is automatically granted).\r\nHow difficult is it to get an app with these two permissions approved to the Google Play Store?\r\nA quick experiment shows that it is trivial to get such an app accepted on the Google Play Store. In\r\nparticular, we submitted an app requiring these two permissions and containing a non-obfuscated\r\nfunctionality to download and execute arbitrary code (attempting to simulate a clearly-malicious behavior):\r\nthis app got approved after just a few hours (and it is still available on the Google Play Store).\r\nWhat do you recommend to users?\r\nWe recommend users to check which applications have access to the \"draw on top\" and the a11y\r\npermissions. Unfortunately, both permissions are considered \"special\" and, for this reason, certain versions\r\nof Android may show \"no permission required\" even if, in fact, the app has access to both the permissions\r\nrequired for our attack. Here we provide instructions for several versions of Android (if you have\r\nrecommendations regarding instructions for others Android versions, please let us know and we will post\r\nthem here):\r\nAndroid 7.1.2:\r\n—   \"draw on top\" permission: Settings → Apps → \"Gear symbol\" (top-right) → Special\r\naccess → Draw over other apps.\r\n—   a11y: Settings → Accessibility → Services: check which apps require a11y.\r\nAndroid 6.0.1:\r\n—   \"draw on top\" permission: Settings → Apps → \"Gear symbol\" (top-right) → Draw over\r\nother apps.\r\n—   a11y: Settings → Accessibility → Services: check which apps require a11y.\r\nAndroid 5.1.1:\r\n—   \"draw on top\" permission: Settings → Apps → click on individual app and look for\r\n\"draw over other apps\"\r\n—   a11y: Settings → Accessibility → Services: check which apps require a11y.\r\nThis work shows that the user should not consider her device's UI as a trusted source of\r\ninformation. Thus, from a conceptual point of view, the user should rely on other means than the\r\ndevice's UI itself. An alternative solution is to use command line tools (such as adb ) or to\r\ndetermine the permissions requested by each app through the Play Store website. For example, to\r\ncheck the permissions of the official LastPass app (which requires both permissions), you can go to\r\nhttp://cloak-and-dagger.org/\r\nPage 6 of 8\n\nits Play Store page, scroll down, and click \"View details\" under \"Permissions\". The \"draw on top\"\r\npermission will appear under the \"Others\" / \"draw over other apps\" label, while the a11y will appear\r\nunder \"Others\" / \"bind to an accessibility service\".\r\nWhy are these bugs not fixed yet?\r\nSome of the issues uncovered by this work are design-related issues — not simple bugs — and it thus\r\nnecessarily takes more time to fix them. Moreover, these are not \"classic\" low-level issues, but UI-related\r\nproblems. These issues may be more challenging to fix since changes may introduce backward\r\ncompatibility issues and changes that are \"visible\" to end users. Finally, some of the bugs were marked as\r\n\"won't fix\", and they will thus not be fixed.\r\nAre these attacks practical?\r\nWe believe so. We performed a user study with 20 human subjects, and none detected to be under attack.\r\nWe report more details in our paper.\r\nThese permissions have been abused by existing works. What is the difference?\r\nPrevious work has shown that, for example, ransomware abuses the \"draw on top\" permission to create\r\ninescapable fullscreen overlays and block the device. In this work, instead, we show how to abuse these\r\npermissions to mount stealthy attacks, for which the user does not even suspect she has been infected.\r\nAre you the first ones to use clickjacking to enable a11y?\r\nNope! Actually, while we independently had the idea of mixing the two permissions, we discovered the\r\npossibility to use clickjacking to obtain a11y thanks to a blog post from other researchers. The article also\r\ndiscusses 1) how Google attempted to address the problem by relying on the \"obscured flag\" mechanism,\r\n2) how a problem in the defense's implementation makes the attack still possible, and 3) that Google\r\nconsidered this new new attack to be not practical and marked this as \"won't fix\". This blog post motivated\r\nus to work in this direction: among the other attacks we uncovered, we show how the \"obscured flag\"\r\ndefense mechanism is vulnerable even if it were implemented correctly, how it can be abused as a powerful\r\nside-channel (see \"Invisible Grid Attack\"), and how these attacks are extremely stealthy and practical (as\r\nshowed by our user study). We hope our work will motivate Google to patch these vulnerabilities.\r\nThese are \"just\" UI issues. Why should I care?\r\nWe hope that this work shows to both app and system developers how UI issues can be as powerful as\r\nclassic low-level bugs (e.g., buffer overflows), and that should be considered as first-class bugs.\r\nWhat do you think Google should do?\r\nOther than suggesting Google to fix the reported bugs and to implement the defense mechanism proposed\r\nin our paper, we have a number of short-term recommendations:\r\nDo not automatically grant the \"draw on top\" permission.\r\nPerform extensive vetting on apps requiring both permissions.\r\nThe \"draw on top\" and a11y should be listed under the apps' \"normal\" permissions (currently, the\r\nuser needs to navigate to a special, dedicated menu).\r\nDisable all overlays when the user is interacting with the Settings app.\r\nWhat is Google's official reply to the press coverage?\r\nAccording to several news articles, a Google spokesperson said: \"We've been in close touch with the\r\nresearchers and, as always, we appreciate their efforts to help keep our users safer. We have updated\r\nhttp://cloak-and-dagger.org/\r\nPage 7 of 8\n\nGoogle Play Protect — our security services on all Android devices with Google Play — to detect and\r\nprevent the installation of these apps. Prior to this report, we had already built new security protections into\r\nAndroid O that will further strengthen our protection from these issues moving forward.\"\r\nWill you make the proof-of-concept publicly available?\r\nSince it is still possible to launch these attacks against real users, we will not publicly disclose the proof-of-concept (for now). However, upon request, we will be happy to share the PoC with selected security\r\nresearchers.\r\nDo you have a question that is not covered here? Send us an email!\r\nPress Coverage\r\nThis work received significant press coverage. Here there are some articles: NewsWeek, The Register, ThreatPost,\r\nTechCrunch, The Hacker News, On The Wire, Kaspersky Blog, Daily Mail, International Business Times,\r\nAndroid Central, Android Police, EndGadget, Mashable, ComputerBild (in German), Android Authority,\r\nSoftPedia, HelpNetSecurity, XDA Developers, The Hill, SlashGear, Express UK, Malaysia Sun, Indipendent UK,\r\nSecurity Now, Silicon UK, Graham Cluley, The Merkle, Inc., 9to5google, NowSecure, Gigazine (in Japanese),\r\nScience Daily, Security Affairs, CanalTech (in Portuguese), CyberScoop, Info Security, Appelmo (in Italian),\r\nHeadLines.nl (in Dutch), Android Planet (in Dutch), DobreProgramy (in Polish), WccfTech, BGR, AppInformers,\r\nGadgets 360, Android Headlines, TelePolis (in Polish), Redes Zone (in Spanish), Chip Online TR (in Turkish),\r\nMojAndroid (in Slovak), N+1 (in Spanish), Popular Mechanics, Android World (in Italian), Unwire (in Chinese),\r\niDevice (in Romanian), Digital (in Bulgarian), NhipSongs (in Vietnamese), Cepkolik (in Turkish), ITMedia (in\r\nJapanese), TekCrispy (in Spanish), 3DNews (in Russian), Libero.it (in Italian), QDSS (in Italian), Xakep (in\r\nRussian), Unboxholics, Neowin, Blasting News, KCRA, HotForSecurity, SpiceWorks, Latest HackingNews,\r\nDeccanChronicle, MobileSyrup, HackRead, RapidMobile, Noah Conference, Digital Trends, AndroNews (in\r\nGerman), Conservative Angle, Tech Hook, GSM Portal, Live 24 News, TiotsGoa, Atman, DailyUpdate,\r\nKalen2utech, MyBroadBand, PC Tablet, Sohu, Digi163, ITWire, BGR India, TechNews Inc., Thaivisa, Ausdroid,\r\nKoco, The Christian Post, TechDroider, PPPFocus, Security Intelligence, GuidingTech, OpenSourceforu,\r\nSensorTech, EMGIGroup, TcInet, FileHippo, Heise (in German), KCCI, NextInpact, BTCoin Info, Blorge, Yahoo!\r\nTech, Bit Media, HappyTech, Generation NT, GBHackers, TechGround News, AntiCorruption, Notebook Check,\r\nSecurity Online, TecnoExplora, The Viral News, KakNut, HackersPortugal, Spinonews, LongRoom, TechGossip,\r\nTechStutn, Craw, Uroft, Bongo Gadgets, UK Star, Best of Viral, Breaking Tech (in Italian), Android-IT, Irish Sun,\r\nTeknoFormat (in Turkish), WinFuture (in German), F-Hack (in Italian), WLWT News, RadioRegional (in\r\nPortuguese), TVBS (in Chinese), NewReport (in Greek), CERT Italia (in Italian), Mobil Mania (in Czech),\r\nAndroid Community, Ifnar (in Chinese), Sina (in Chinese), Viet Times (in Vietnamese).\r\n©2017 all rights are reserved to the respective authors.\r\nSource: http://cloak-and-dagger.org/\r\nhttp://cloak-and-dagger.org/\r\nPage 8 of 8", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "http://cloak-and-dagger.org/" ], "report_names": [ "cloak-and-dagger.org" ], "threat_actors": [ { "id": "9de1979b-40fc-44dc-855d-193edda4f3b8", "created_at": "2025-08-07T02:03:24.92723Z", "updated_at": "2026-04-10T02:00:03.755516Z", "deleted_at": null, "main_name": "GOLD LOCUST", "aliases": [ "Anunak", "Carbanak", "Carbon Spider ", "FIN7 ", "Silicon " ], "source_name": "Secureworks:GOLD LOCUST", "tools": [ "Carbanak" ], "source_id": "Secureworks", "reports": null }, { "id": "cfdd35af-bd12-4c03-8737-08fca638346d", "created_at": "2022-10-25T16:07:24.165595Z", "updated_at": "2026-04-10T02:00:04.887031Z", "deleted_at": null, "main_name": "Sea Turtle", "aliases": [ "Cosmic Wolf", "Marbled Dust", "Silicon", "Teal Kurma", "UNC1326" ], "source_name": "ETDA:Sea Turtle", "tools": [ "Drupalgeddon" ], "source_id": "ETDA", "reports": null }, { "id": "33ae2a40-02cd-4dba-8461-d0a50e75578b", "created_at": "2023-01-06T13:46:38.947314Z", "updated_at": "2026-04-10T02:00:03.155091Z", "deleted_at": null, "main_name": "Sea Turtle", "aliases": [ "UNC1326", "COSMIC WOLF", "Marbled Dust", "SILICON", "Teal Kurma" ], "source_name": "MISPGALAXY:Sea Turtle", "tools": [], "source_id": "MISPGALAXY", "reports": null }, { "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 }, { "id": "62b1b01f-168d-42db-afa1-29d794abc25f", "created_at": "2025-04-23T02:00:55.22426Z", "updated_at": "2026-04-10T02:00:05.358041Z", "deleted_at": null, "main_name": "Sea Turtle", "aliases": [ "Sea Turtle", "Teal Kurma", "Marbled Dust", "Cosmic Wolf", "SILICON" ], "source_name": "MITRE:Sea Turtle", "tools": [ "SnappyTCP" ], "source_id": "MITRE", "reports": null } ], "ts_created_at": 1775434415, "ts_updated_at": 1775791946, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/38b5bf31befbda5484188ef18734eb55bc559365.pdf", "text": "https://archive.orkl.eu/38b5bf31befbda5484188ef18734eb55bc559365.txt", "img": "https://archive.orkl.eu/38b5bf31befbda5484188ef18734eb55bc559365.jpg" } }