Just Another IT Security Blog

It's been over a year since the last time I posted anything so I'll give a quick update. The whole AFL thing didn't pan out as much as I'd like as I never really made time for it. I did add another child into the world so I got that going for me. As for work, I'm still at Cisco Talos doing the Detection Response Team (DRT) stuff, basically creating rules for Snort and sigs for ClamAV. That's going ok, gets a little mundane at times as I'm a researcher by trade and love looking into different things, especially mobile stuff, but overall I feel it's going well. At least no one has told me otherwise. That's pretty much it for me over the last year so lets start on some new exciting info. I recently went to TROOPERS  for TROOPERS19 and it was awesome. For those that don't know, it is a computer security conference in Heidelberg, Germany that takes place in March time frame. The city of Heidelberg was beautiful and the content of the conference was

Over the course of my INFOSEC career I've worked in many different positions. IDS, network analysis, pentester, mobile application testing and a few others but one area has always stoked my interest. Vulnerability development is an area I wish I knew more about along with having a better grasp of reversing software. So over the next few months I've decided to try and fuel that interest by jumping into the world of fuzzing. I have chosen to start messing around with american fuzzy lop (AFL)  and see if I can find my first CVE. So here goes nothing.

It's been a few months since my last post and I thought that a post about what items might be considered suspicious in an APK would be good to have. There is only two main items that I can think of but should provide a researcher with an idea of when they might need to reverse an application to figure out exactly what it is doing. Permissions In order for applications to access certain features of an Android device they must request access to the corresponding permissions for that feature. Such as, if an application wants to send SMS it must request access to that feature. This is usually done on install. When you choose to install a new application the user has to grant or deny access. This is the only time a user is prompted to allow access as the application will not request permissions when running. This can be dangerous if you allow access to an application and do not know what it is actually requesting access to. Permissions are a good place to start with when trying to

Hope you brought your shovel as we start to take apart this malware and look at it's internal code. To get started we will need to pull the APK from the device to our local system. To do this you will need to turn on usb debugging on the phone or emulator from the settings menu of Android (Check out this link if you don't know how https://www.kingoapp.com/root-tutorials/how-to-enable-usb-debugging-mode-on-android.htm ). Now that you have your phone/emulator connected to your system you can now download the malicious APK. In our case we already have the APK but for those situations when you might now already have it downloaded you use the adb pull   command (e.g. adb pull /data/app/bad.apk)to pull the package from the device. After you have completed this process we can now start the static analysis of APK. The main tool for performing static analysis of the APK is a decompiler. I prefer JEB ( https://www.pnfsoftware.com/jeb2/ ) but it requires a subscription. A free decomp

In the previous post I covered how to get an Android image running in an emulator and how to install the malicious APK to the device. This post will focus on performing some basic dynamic analysis of the APK in the emulator. The first thing we need to do is start our device. I've found the best way to do this that allows me to save the network traffic is with the command line tool ' emulator '. If you type ' emulator -help ' you will get a ton of arguments which this command takes but thankfully for us we only need a few of them. We start our device with the command emulator -avd  MyDevice -qemu -tcpdump traffic.pcap. This will start the device and save out a pcap of the network connections to the file specified. TestAndroid - Galaxy Nexus Android v4.2.1  Now its time to get to work. I pulled done a sample from VirusTotal that I've worked with before which is called MisoSMS . This malware was found targeting users in Asia and FireEye did a good writeup o

Over the last year I have been performing research on mobile devices. My last job had me analyzing the security of Android applications and recently I found my new job drawing on my past experience to help someone analyze some Android malware. First we started to do some research on potential solutions that could help automate analysis or at least do some type of dynamic analysis and that is were I stumbled onto CuckooDroid (https://github.com/idanr1986/cuckoo-droid). After a day or two of  messing with CuckooDroid I decided that it was a little overkill for what I needed to do which was grab a PCAP of the traffic. In one of my next post I'll cover setting it up but for now here is what you need to do if you want to do a quick and easy analysis of an Android malware sample.  1) Install Android Studio (http://developer.android.com/sdk/installing/index.html) 2) Use the SDK Manager to install the SDKs and Images to work for the malware you are going to be analyzing. 3)