TTP Tuesday: Operator x Android

Providing the initial steps to Operator supporting mobile capabilities

Each year, Google and Apple have pushed the bar in what you can achieve on mobile operating systems. Likely most, if not all of us, carry mobile devices. It would be extremely difficult to be without some type of mobile device today. It's not too far of a stretch that most, if not all of us, use our mobile devices for both personal and professional purposes. If your company allows you to put email on your mobile devices, it's a good chance that not only do you have it, but your company likely controls some part of the device’s security. You likely blend professional tasks on personal devices and this becomes a huge issue for infosec in general. For blue teams, it's finding the balance between allowing users to safely conduct business, but not intruding on privacy. For anything offensively, it's a huge security hole that has too much liability to test on actual users. 

In searching for a middle ground, I believe information security professionals should have mobile testing environments that replicate the ideal environment of their user base on the network. Then provide those environments to the appropriate personnel to conduct offensive simulations on them. This information could then drive your defensive team in providing informative Public Service Announcements (PSAs) to all users. It could also drive updated configurations of mobile device managed services, where they can further adapt to the changing security landscape. This would provide a good overall capturing of security risk, without all the personal liability of performing offensive techniques on personal mobile devices.

When David tasked me to look into mobile capabilities for Operator, I had a few things I felt are must haves. Obviously, it has to create some value. Secondly, it must be something that you can easily perform testing on. Lastly, I wanted to avoid doing anything that completely removes a lot of the work that we have been currently working on with Operator TTP deployment. I didn't want to at least initially, create a capability that segments off Operator users from launching TTPs from either the Operate or Editor tabs.   

For ease of use, it’s important that Operator users don't have to rely on having a physical Android phone in order to test these things within their environment. I also didn't want to, at least in getting started, force users to potentially need to root Android devices to perform testing. So in searching for a solution, I believe SickCodes Android emulator on Github is a great solution without having to completely mess with Android Studio out of the box or pay $400/yr for Genymotion. I utilize quite a few things SickCodes has developed and I like the environments that are available. Dock-droid basically runs emulated Android using QEMU within a Docker container for easy setup. It has a bunch of features including running on either x86-64 or ARM architecture, ADB access, virtualization wifi so you can share host IP and have internet access, access to the Google Play Store, root user privileges, and you can even pass-through hardware like GPS dongles, storage devices, and webcams. Sure it's not as easy as Genymotion but, as long as you are comfortable with Docker containers, you should have no issues in getting this working great within your environment. Also it should be mentioned that if you have a different route you want to take or have something like Genymotion than those should work as well.   

Android runs each application in a restricted sandbox and requires that applications request specific permissions in order to interact with other apps or the system. For this reason, I fairly quickly ditched creating our own Android specific agent. Later down the road, I think creating a specific Android agent would be nice to have, but it would have been extremely limited given our timelines and I don't think it would have been as valuable in the short term. It would have also likely removed the ability to launch TTPs from Operator and instead forced us to put capabilities within the Android application itself.

I turned my attention to using a Linux terminal emulator application called Termux. Termux emulates features from the Linux terminal and provides some extremely nice capabilities to Android in general. This application is super convenient because it's on the Google Play Store (although it's out of date and the developers want you to use FDroid instead) and it doesn't require root user access to get started. Termux has quite a few packages from Termux itself that makes things easier when working in this environment like root-repo and proot/termux-chroot that provides the full Linux file system hierarchy which Termux doesnt out of the box use. There is a lot you can do within Termux so I would recommend playing around with it. You can even install things like Wireshark, NMap, and Metasploit and then control that using our agent within Operator if you wanted. 

I currently have a specific Android Schism agent working within Termux that will allow you to interact with Operator and the Android emulator. To get this working, you will either need to install Schism directly within the Termux environment or be root within Android and move it from the ‘sdcard/Downloads’ directory to ‘data/data/com.termux/files/home’ and then chmod 777 the file. You will also need to install the pip requests package (python -m pip install requests). Doing this will also allow you to execute quite a few Linux/SH commands within the Termux environment. To get ADB working, which provides more detailed Android internal data, you will need to connect to the ADB server within the Termux application. To understand how to setup ADB, refer back to the SickCodes README file where it details how you can connect to it. This will allow you to run the Android specific ADB commands that we have provided within Operator. 

Currently, we have quite a few Android specific ADB commands you can try. While within an ADB shell some of these commands will require root access to perform like installing applications (which requires root to access the system file directory). We also have the ability to perform things like screen record and capture, device backup for extraction, a list of installed applications, remove ADB logs for clean up, get system processes, and create new users. As mentioned earlier you can also perform some Linux shell commands within the Termux environment. In going through just the Discovery tactics, around 15 or so TTPs will provide back information.    

There are quite a bit of things you need to do to get everything working and I understand at least for the initial setup you might run into some issues, but once you get it working it works quite well.

I intend to distribute a YouTube tutorial to better outline how to set up the Android environment step-by-step as it is now, and then also improve the process over time to make it easier to set up. I will also be pushing out further Android ADB TTPs, working on getting Pneuma on Android, and also getting Operator headless with team capabilities working. I believe we can get Operator headless working within Termux which would allow you to have someone walk within environments hands free while allowing someone at home base to discover and execute TTPs on W-LAN.

Lastly, without making too many promises I intend to look at Apple’s iOS as well. Apple’s iOS will be a much bigger task and I wouldn't expect the newest iOS version to be included but, I think it would be interesting to get some things working like root detection. Also iOS actually has a better usable stock back end to execute things once the device is rooted and you have access to it.

Staying up to date

Thanks for reading our latest TTP Tuesday release! Please subscribe and reach out with any feedback. We love to hear from our community!

There are several ways to follow us and learn more about Prelude and our team members:

Get our products

Download Prelude Operator: https://www.prelude.org/download/current
See the latest kill chain and TTP Releases: https://chains.prelude.org/
See our open-source repositories: https://github.com/preludeorg

Join our community

Discord: https://discord.gg/gzUv4XNquu
Reddit: https://www.reddit.com/r/preludeorg/
Twitter: https://twitter.com/preludeorg

Read, watch, and listen

Listen to our Podcast: https://anchor.fm/preludeorg
Read our blog: https://feed.prelude.org
Watch our live streams: https://www.twitch.tv/preludeorg
Watch our pre-recorded content: https://www.youtube.com/c/preludeorg

Follow our team

David: privateducky
Alex: khyberspache
Kris: Xanthonus
Octavia: VVX7
Sam: wasupwithuman