Android.Bankun And Other Android Obfuscation Tactics: A New Malware Era
There’s one variant of Android.Bankun that is particularly interesting to me. When you look
at the manifest it doesn’t have even one permission. Even the most simple apps have at least
internet permissions. Having no permissions isn’t a red flag for being malicious though.
In fact, it may even make you lean towards it being legitimate. However, there is one thing
that gives Android.Bankun a red flag though. The package name of com.google.bankun
instantly makes me think something is fishy.
To the average user the word‚ Google’ is seen as a word to be trusted. This is especially true when it comes to the Android operating system which is of course created by the search engine giant. Malware authors now this and heavily use it to disguise their malicious intent. Mobile threat researchers like myself also know this and end up looking twice whenever we see ‚Google’ being used. Diving into the code, we see a simple application whose code all resides in one plainly named default class, MainActivity. A great place to start is on the “onCreate” function which is run whenever the app is opened. Let’s take a look (Figure 1). Looking at the code, we can see that it calls “isAvilible” with parameters of different package names. The “isAvilible” function looks to see if that package name is installed and returns ‘true’ if it is installed which triggers the “if...else” statement to be ran. Let’s look at the first “if...else” statement with “com.kbcard. kbkookmincard”. If you look in the Google Play market you’ll see that “com kbcard.kbkookmincard” is an app called “KB Kookmin Card Mobile Home”. It appears to be a Korean banking app. Whenever “KB Kookmin Card Mobile Home” exists, the malicious app will uninstall the app using the “uninstallApk” function after getting root access from the “getRootAhth” function. It then calls “installZxingApk” with the
value of ‘i’ which is ‘1’ for this “if...else” statement. Let’s look at the “installZxingApk” function (Figure 2).
Under the “installZxingApk” function, it appears to be grabbing a file in the assets folder. The name of the file is the parameter variable that was used to call “installZxingApk”. For our example, we know that the value is ‘1’ from the “if...else” statement in class “MainActivity”. In other words, a file named “1.apk” located in the assets folder is being called and then installed. So, let’s see if there is an APK in the assets folder of the malicious app named “1.apk” (Figure 3).
There it is! Along with several other APKs for other “if...else” statements to use.
To test this malicious app out, I grabbed the legitimate “KB Kookmin Card Mobile Home” and installed it. Here it is sitting in my test phone’s memory (Figure 4).
Then ran the malicious app and this popped up (Figure 5).
There’s the app getting root access. Now, you should probably say “what in the...” and click ‘Deny’,
but that’s no fun so let’s click ‘Allow’. We then get this (Figure 6).
What’s this? Maybe an update of my banking app “KB Kookmin Card Mobile Home?” Lets click ‘Install’. Looking at the icon for this app nothing looks different:
It listens for any incoming SMS and phone calls and when one comes in, it gathers information such as time of call/SMS, telephone number, SMS message body, call length time, etc. It also steals your contact list and adds contact entries, sends SMS messages in the background, steals email through gmail and who knows what else. All of this from an APK that has no permissions.
Android.Bankun is just one example of how malware authors evade detection. A typical user may not
think twice when they see something starting with the name “com.google”, even if it asking for superuser permissions. Malware authors are ‘banking’ on this (pun intended). The most common evasion tactic is using the same package name as a legitimate app. In many cases, the app will run just like the legitimate version, but do something malicious in the background. Turning function and class names into something generic like “a”, “b”, “c” and so forth, also makes it tougher to track down malicious code. Using encoding/decoding tactics within the code also makes it harder to see what the true intent may be. Android.Bankun didn’t use any obfuscation to hide the APKs in the assets folder, but other malware authors will part the APK files out into multiple files in the assets folder with generic file types. The malicious app then puts the files back together into a malicious APK before installing it.
Mobile malware is evolving rapidly. We are coming into a new era where the typical user may not own a laptop anymore, but instead several Android devices like a tablet and mobile phone. You better believe that malware authors see this trend. They are only getting started with new ways to attempt to evade us all.
There’s one variant of Android.Bankun that is particularly interesting to me. When you look
at the manifest it doesn’t have even one permission. Even the most simple apps have at least
internet permissions. Having no permissions isn’t a red flag for being malicious though.
In fact, it may even make you lean towards it being legitimate. However, there is one thing
that gives Android.Bankun a red flag though. The package name of com.google.bankun
instantly makes me think something is fishy.
To the average user the word‚ Google’ is seen as a word to be trusted. This is especially true when it comes to the Android operating system which is of course created by the search engine giant. Malware authors now this and heavily use it to disguise their malicious intent. Mobile threat researchers like myself also know this and end up looking twice whenever we see ‚Google’ being used. Diving into the code, we see a simple application whose code all resides in one plainly named default class, MainActivity. A great place to start is on the “onCreate” function which is run whenever the app is opened. Let’s take a look (Figure 1). Looking at the code, we can see that it calls “isAvilible” with parameters of different package names. The “isAvilible” function looks to see if that package name is installed and returns ‘true’ if it is installed which triggers the “if...else” statement to be ran. Let’s look at the first “if...else” statement with “com.kbcard. kbkookmincard”. If you look in the Google Play market you’ll see that “com kbcard.kbkookmincard” is an app called “KB Kookmin Card Mobile Home”. It appears to be a Korean banking app. Whenever “KB Kookmin Card Mobile Home” exists, the malicious app will uninstall the app using the “uninstallApk” function after getting root access from the “getRootAhth” function. It then calls “installZxingApk” with the
value of ‘i’ which is ‘1’ for this “if...else” statement. Let’s look at the “installZxingApk” function (Figure 2).
Under the “installZxingApk” function, it appears to be grabbing a file in the assets folder. The name of the file is the parameter variable that was used to call “installZxingApk”. For our example, we know that the value is ‘1’ from the “if...else” statement in class “MainActivity”. In other words, a file named “1.apk” located in the assets folder is being called and then installed. So, let’s see if there is an APK in the assets folder of the malicious app named “1.apk” (Figure 3).
There it is! Along with several other APKs for other “if...else” statements to use.
To test this malicious app out, I grabbed the legitimate “KB Kookmin Card Mobile Home” and installed it. Here it is sitting in my test phone’s memory (Figure 4).
Then ran the malicious app and this popped up (Figure 5).
There’s the app getting root access. Now, you should probably say “what in the...” and click ‘Deny’,
but that’s no fun so let’s click ‘Allow’. We then get this (Figure 6).
What’s this? Maybe an update of my banking app “KB Kookmin Card Mobile Home?” Lets click ‘Install’. Looking at the icon for this app nothing looks different:
Now let’s look in the phone’s memory again (Figure 7). The APK “com.kbcard.kbkookmincard-1.apk” has been replaced with “com.googles.smsservicesone-1.apk”, or better known as “1.apk” from our malicious apps asset folder. So what does “1.apk” do? It’s another malicious app that pretends to be “KB Kookmin Card Mobile Home” (Figure 8). Not only does this nasty app steal sensitive banking info, it also does several other malicious activities.
It listens for any incoming SMS and phone calls and when one comes in, it gathers information such as time of call/SMS, telephone number, SMS message body, call length time, etc. It also steals your contact list and adds contact entries, sends SMS messages in the background, steals email through gmail and who knows what else. All of this from an APK that has no permissions.
Android.Bankun is just one example of how malware authors evade detection. A typical user may not
think twice when they see something starting with the name “com.google”, even if it asking for superuser permissions. Malware authors are ‘banking’ on this (pun intended). The most common evasion tactic is using the same package name as a legitimate app. In many cases, the app will run just like the legitimate version, but do something malicious in the background. Turning function and class names into something generic like “a”, “b”, “c” and so forth, also makes it tougher to track down malicious code. Using encoding/decoding tactics within the code also makes it harder to see what the true intent may be. Android.Bankun didn’t use any obfuscation to hide the APKs in the assets folder, but other malware authors will part the APK files out into multiple files in the assets folder with generic file types. The malicious app then puts the files back together into a malicious APK before installing it.
Mobile malware is evolving rapidly. We are coming into a new era where the typical user may not own a laptop anymore, but instead several Android devices like a tablet and mobile phone. You better believe that malware authors see this trend. They are only getting started with new ways to attempt to evade us all.