Despite its increasing popularity among attackers, Android is a relatively secure system. However, even perfectly functioning apps, whose data is completely isolated, can be hijacked unnoticeably. So-called “overlay attacks” discreetly overlay legitimate applications and thus gain access to dangerous authorizations and sensitive data, e.g. from banking apps, messengers or browsers.

1. Malicious Apps on Android

2. Various Overlay Techniques
2.1. Monitoring Activities of parallel applications
2.2 Overlaying Activity components

3 Simulated attack via SMS and an Attacker Website
3.1 FakeBank App
3.2 FakeBank Attacker Website

4. Defending against Overlay Attacks

5. Defending against Accessibility Service Abuse and Keylogging using a 3rd party keyboard

6. Defending against key logging Attacks

7. Frequently Asked Questions

8. References

9. Android Overlay Malware – FakeBankTransaction (YouTube)

1. Malicious Apps on Android

Malicious Apps on Android tend to find novel approaches to exfiltrate data from their victims and elevate their privileges without the user knowing what is really happening on their device as they interact with the malicious App. Even when an App is perfectly functioning and its data is isolated from other Apps, there are still ways to bypass this security measure covertly.

Utilizing various so-called overlay attacks, a malicious App can gain dangerous permissions and enable a bad actor to initiate for example illegal bank transfers. This is possible through already known vulnerabilities in the Android OS. These attacks involve engaging the UI feedback loop and the abuse of the Android API. This leads to information extraction from Apps such as high security Banking Apps, private messaging Apps or browser Apps.

2. Various Overlay Techniques

1. Picking a victim application and finding out their package name
2. Monitoring said application using various methods
3. Hijacking hijacking the victim App by overlaying it at run time.

Figure 1: Overview of an Overlay Attack against a benign Application on the Android OS

2.1 Monitoring Activities of parallel applications

In order for an overlay attack to become successful, it needs to be able to detect activities and tasks that are launched into the foreground. This technique involves monitoring other Apps (packages) on the target device. In order to find out what packages are currently running on the device, Android offers various helper classes. Throughout the years, these helpers became harder to use on newer APIs. Google did not want developers to monitor the activities of other running Apps on the device. Here’s a short list of viable options:

• getRunningTasks() (available below Android 5.0)
• getRunningAppProcesses()
• UsageStatsManager
• Finding and monitoring the /proc//oom_score (pid – represents the process ID of the target package) file.
• Defining an android:TaskAffinity for the victim Apps package. This method is used by malware in the wild and it is known as the Strandhogg vulnerability. Apps that have their taskAffinities misconfigured can easily fall victim to these attacks.

The following source code of and Android App makes use of some of these monitoring techniques: https://github.com/geeksonsecurity/android-overlay-protection

2.2 Overlaying Activity components

After the target foreground activity has appeared to the victim, the attacker has a couple of options to choose from to determine how they want to hijack the foreground activity. Here are couple of options that have been used by malware in the wild:

• Injecting a fragment object into the foreground Task
• FLAG_ACTIVITY_NEW_TASK in order to invoke an activity above the current one
  (This can be easily removed by the user using the back button.)
• Drawing a custom View as a SYSTEM_ALERT window on top of the foreground activity
  (These Views cannot be removed by the user even if they tap on the back button. This technique is also used by ransomware on Android devices in order to create surfaces that overlay the Launcher or even the lock screen and demand the victim to pay up.)

3. Simulated attack via SMS and an Attacker Website

This attack involves sending a manipulative message via SMS to a user of a FakeBank App. The user‘s information such as the telephone number and connection to a bank institution was gained through means of social engineering and interaction with the Dark Web. The Dark Web tends to sell personal information such as telephone numbers and data that could be associated to bank customers.

The attack process is as follows:

1. Send an SMS to the telephone number that is associated to a FakeBank customer
2. Inside the SMS, state a request to install an App from the attacker website formally and try to instigate urgency
   

   Figure 2: SMS in German language to lure the user into installing an App on their device

3. The SMS also instructs the user to visit a website and download the urgently needed security update.
4. Once on the website the user may proceed to the dowload page by clicking on download. This step differs from attacks, which also ask for a telephone number and bank login credidentials before offering a download link. These websites also only let browser access them, which carry a certain User-Agent name.
5. Tapping on the download button will lead the user to the instructions page, which embeds a download button.
   

   Figure 4: The Download Page not only offers a download link but also instructions on how to install the downloaded App

6. The text is very clear on instructing the user to turn off a very important security feature that prevents users from deliberately or accidently installing Apps from unknown sources.
7. Finally, the user is to install the App from their download directory.

3.1 FakeBank App

FakeBank is a banking App for Android smartphones. When it comes to Banking App features, it tries to approximate all-in-one Banking Apps that use mTANs over SMS to validate transactions. In addition to that, this App is able to simulate server-side bank transactions over HTTP.

Figure 5: FakeBank functions as a banking App, which provides services such as viewing recent transactions and initiating them.

3.2 FakeBank Attacker Website

FakeBank Attacker Website is the website on which a malicious App (FakeBankCertificate.apk) is stored. Its purpose is to:

• Instruct the user to install the FakeBankCertificate.apk
  • Provide technical information on how to disable default security measures
  • install the FakeBankCertificate.apk from the browser
• Store the FakeBankCertificate.apk

Figure 6: The FakeBank Site is an adversary server that provides a landing page as well as installation instructions and a download link

FakeBankCertificate-App

When installed this App will try to acquire dangerous permissions to carry out data exfiltration attacks such as:

• Reading keystrokes
• Overlaying login screens of specified Apps
• Reading text fields of specified Apps
• Changing the default SMS App read and forward their content to a C2 server

All of these permissions are gained by overlaying important permission request dialogs and activities.

Figure 7: FakeBankCertificate.apk is a malicious App that abuses the operating system to attack the FakeBank banking App

4. Defending against Overlay Attacks

Sometimes it is essential that an application be able to verify that an action is being performed with the full knowledge and consent of the user, such as granting a permission request, making a purchase or clicking on an advertisement. Unfortunately, a malicious application could try to spoof the user into performing these actions, unaware, by concealing the intended purpose of the view. As a remedy, the Android framework offers a touch filtering mechanism that can be used to improve the security of views that provide access to sensitive functionality.

To enable touch filtering, call setFilterTouchesWhenObscured(boolean) or set the android:filterTouchesWhenObscured layout attribute to true. When enabled, the framework will discard touches that are received whenever the view’s window is obscured by another visible window. As a result, the view will not receive touches whenever a toast, dialog or other window appears above the view’s window.

Source: https://developer.android.com/reference/android/view/View – Security

5. Defending against Accessibility Service Abuse and Keylogging using a 3rd party keyboard

Banking Apps may provide their own implementation of the TextEdit View that don’t subscribe to operating systems accessibility services the way the built in TextEdit View does. This way inputs into various text fields can be secured, while inputting sensitive information.

Source: Vincent Haupert, Dominik Maier, Nicolas Schneider,Julian Kirsch, and Tilo Müller – The State of Android App Hardening: https://www1.cs.fau.de/filepool/projects/nomorp/nomorp-paper-dimva2018.pdf

6. Defending against key logging Attacks

Banking Apps sometimes provide their own custom made virtual keyboards to receive inputs. Banking Apps also have the ability to request the operating system to turn off screen captures on certain activities, such as in the case of entering a password or filling out a form.

Source: Vincent Haupert, Dominik Maier, Nicolas Schneider, Julian Kirsch, and Tilo Müller – The State of Android App Hardening: https://www1.cs.fau.de/filepool/projects/nomorp/nomorp-paper-dimva2018.pdf

7. Frequently Asked Questions

Q: How is the user compelled to install the Fake Bank Certificate App?

A: The way the scam message (SMS or E-Mail) is formulated, the user will get a sense of emergency and importance to follow the carefully provided instructions and install the App regardless, the warning the operating system provides when the “installation from unknown sources” gets activated. Some banking Apps are used with a companion App, which is supposed to provide a more a secure way of communicating with the bank and providing a so called “2nd App verification”. Knowing this, the user might not find the Fake Bank Certificate companion App suspicious the first time they install it.

Q: How come the hacker is able to change the transaction details such as the recipient IBAN, Name, amount to send and even the reference of transaction?

A: Not all banks verify all details of a transaction. In our short demo, the server only verified the sender’s IBAN, Name and the corresponding mTAN. In a real scenario, the attacker has the ability to request a new bank transaction and use the corresponding mTAN, which is captured from the victim’s device, to verify and finalize the transaction.

Q: Aren’t banks capable of reverting transactions? Can’t they just identify the transaction and undo it?

A: Yes, Banks might do so. Thanks to their centralized infrastructure. Unfortunately, cyber criminals do not work alone and they expect this to happen. The way they go around this security measure is to send a “money mule” (Money Mule – a person who is tasked to receive cash from ATM machines) to an ATM machine on the streets and let him take out the stolen amount in cash.

8. References

• http://www.s3.eurecom.fr/~yanick/publications/2017_oakland_cloakanddagger.pdf
• https://researchcenter.paloaltonetworks.com/2017/09/unit42-android-toast-overlay-attack-cloak-and-dagger-with-no-permissions/
• https://www.threatfabric.com/blogs/exobot_android_banking_trojan_on_the_rise.html
• https://www.threatfabric.com/blogs/mysterybot__a_new_android_banking_trojan_ready_for_android_7_and_8.html

9. Android Overlay Malware – FakeBankTransaction (YouTube)

Visite also our clip on YouTube