Android Incident Response Lab 1

Introduction

Incident response is often described as a 6 step process. These 6 steps help an organisation formulate a plan for responding to cyber security incidents and help keep future incidents at bay.

During this lab, we focus on some simple techniques to triage key Android logs to help investigate the depth of a compromise on an Android device.

TL;DR

Using Android Debug Bridge (ADB) gain shell access to your Android device and use the following commands when performing incident response.  They help you understand what processes are running and what network connections are coming from those processes.

netstat -etu
ps -ef

Make sure you look at the UID output of these commands, on Android every app runs as a different user ID, you can therefore tie together a running process with its corresponding network connections.

Setup

In order to run through this lab, you’ll need the following:

1.  An Android device
2. Android Debug Bridge (ADB) installed on your computer 
3. A suitable USB cable to connect to your Android device 

To install ADB on your computer, follow the respective steps for your device (whether Windows, Mac or Linux) available on the android website.

Connecting to your device via ADB

In order to connect to your device via ADB, you will need to have developer mode and USB debugging enabled. 

To enable developer mode:

1. First go into settings
2. Select “About phone”
3. Find your build number and tap it seven times (on Samsung devices it’s within “Software information”)

To enable USB debugging:

1. Head back to settings
2. Select developer options
3. Scroll until you find USB debugging and turn it on

On Android 9 and above you will need to do the below:

1. Head back to settings
2. Open settings and select advanced
3. Open developer options
4. Scroll until you find USB debugging and turn it on

Plug in your Android device now. When prompted whether you want to allow USB debugging from this computer click “OK”.

Open up a terminal or command prompt and navigate to the directory where ADB resides (as downloaded in the setup phase). Now within your terminal prompt issue the following command.

adb devices

You should receive a response that looks like the following:

The following command will enable you to jump into the Android shell.  As Android is based on the Linux operating system you’ll see many similarities, but with a few extra restrictions than you might be used to on a standard Linux device.

adb shell

And that does it for the setup, we’re ready to rock and roll!

Gathering Information

In order to start listing running apps and associated network connections, you’ll have to understand a key security principle of the Android architecture.

Every app installed by a user will be running under a different user ID (UID). That’s right every single app which is installed on Android (apart from system apps) has its own user account associated with it.

At the top of a new document in your favourite text editor we will add the local device date and time.  To do this issue the following command within your adb shell.

date

Listing Running apps

Within the Android shell that we have open, type the following command:

ps -e

ps is a useful tool pre-installed on many distributions of Linux, it makes it easy to collect running processes on the device. The -e option tells ps to display all running processes on the device. Prepare yourself, the output of running apps will be quite a long one.  Take a copy of the output and paste it into your favourite text editor.

Listing Network Traffic

Many malicious apps will maintain a persistent foothold with their command and control (C2) server.  In order to spot this, gaining a view of the current network traffic on the device is a useful exercise.  To do this we simply use netstat. The switch -e gives us extended information, -t includes TCP traffic and -u ensures that UDP traffic is also included.

netstat -etu

Paste the output of this command into your favourite text editor.

Mapping Running apps to their Respective Network Traffic

The way in which we’ll map the network traffic and running processes together is by UID. In the below screenshot you can see that I’ve taken the user “u0_a163” and “u0_a169” and filtered the results of both ps and netstat by these users.  By using these users, I can identify the apps associated to the traffic. In the below screenshot, we identify the egress http traffic which has recently entered the CLOSE_WAIT state to be coming from com.sun.latest. We also identify a strange app with a current established connection on port 4444 named com.asjudiiqmm.ubtknjpzyx.

Conclusion

To conclude this lab, we’ve now got the tools we need to identify whether an app is running and has current persistent network connections. This could be a crucial step in identifying the capabilities of a malicious app.

If you’re concerned about an app which you’ve analysed on your device, the next step would be to proxy your traffic through a tool like fiddler. This would allow you to analyse and understand a bit more about what this network traffic consists of.

Continuous monitoring of your Android devices is a great practice whether in your personal or professional life. At traced, we offer a free app for Android which allows you to do exactly that. Give it a download from the Google Play Store and let us know what you think!