Extracting C&C from Android Malware

Even though AndroRat (http://www.symantec.com/connect/blogs/remote-access-tool-takes-aim-android-apk-binder) had been around for eons and the source code was made available (https://github.com/DesignativeDave/androrat) but there are many new ones popping out everyday.

Today I will go through with you on how we can make Profiler work extra hard for us.  I will try to fill in required information about where to look out for information and how decode some of the information.

[ 1st Sample used in the analysis ]

MD5: 8BF31084E55D3A83FE6C382986F95C1C
SHA256: DC9A0322CA263D733F91182F1E655A11CBA28DC766031CE0665B6005900450D7

[ Part 1 : Getting Started ]

For those who want to follow along, this is a link to the .apk file. Do note, this is a MALICIOUS file, so please do the analysis in a “safe” environment. The password to the attachment is “infected29A

Now, let’s start getting our hands dirty…and open the suspicious .apk file.  Firstly, we are going to go through the source code and find out what is the important information that we can extract out.

One of the things that malware analyst are interested in is the “Command & Control” of the malware.

As the source code of the malware was made public, we can see where the IP address for the C&C is stored in my/app/client/ProcessCommand.java as shown in the image below.

As Profiler provides SDK for us to analyse DEX and extract relevant Dalvik code, we will be making use of that today by creating “Actions”.  In order to make an action out of it, go to “Extensions” in the main window, then select the Actions tab and click on “Open user plugin directory” as shown below.

[ Scripting the C&C Extraction ]

Create the following file, “androrat.py” in there.  The code for “androrat.py” is shown below:

Next, click on “Open user configuration file” and paste the following:

Save the file, close it. Then click on “Refresh extensions“. You should already see your action among the list.

Now, if you open the .apk file, “double-click” on “classes.dex” and then press “Ctrl+R” you should see your action under the DEX category at the top.

As we can see from the image below after executing the action, you will get the C&C address and port number at the “output” tab as shown below.

The C&C is “http://shoppingapp[.]no-ip[.]biz” and the port number is “81”.

The purpose of this post is to give a better technical understanding of how easy it is to script in Profiler and how malware analysts can easily retrieve important information using static analysis.

The SDK in Profiler gives users the possibility to inspect the code in Dalvik and to extract other important information.

Just by looking at code snippet we showed you, it’s extremely easy for everyone to expand on it and write new utilities.

[ 2nd Sample used in the analysis ]

MD5: 30C385C2928408126F7553134585286E
SHA256: 9E1BEE43A501132DA732D1287126632438B91A9FCBF37AFDA7B8597055960877

The 2nd sample that we will be looking at is OmniRat. The detection rate for OmniRat is just moderate, 20/54 in VT.

The actual piece of malicious code is actually Base64 encoded and hidden away in the resources.asrc file as you can see in the image below

From the image below, we could extract the APK and even inspect it on the fly.
So select the the Base64 encoded string in the resources.asrc file and then press Ctrl+E and click on the filters button on the bottom right.

Now let’s add in 2 filters:
1.) basic/replace in Bytes mode (in: 00 out:) to remove all null bytes
2.) then from_base64 filter.

Now let’s just give it embedded.apk as the filename and add the file as embedded and inspect it.

We can re-apply what we did with the 1st sample using the script which I’ve attached here.

As shown in the image below, the C&C is “strippermona2[.]no-ip[.]info:200”.

We hope you enjoyed reading this and would be happy to receive your feedback!

BlueBox Android Challenge

Some weeks (? I don’t even remember the time frame) ago I was made aware by a friend of this challenge. Basically injection of Dalvik code through native code. I found some minutes this morning to look into it and while I’m sure somebody else has already solved it, it’s a nice way of showing a bit of how to reverse engineer Android applications with the Profiler.

The first problem we encounter is that the APK (which is a Zip archive) has been tampered with. It asks incorrectly for a decryption key because all file headers have had their GeneralPurposeBit modifed, e.g.:

A few lines of code to fix this field for all file entries in the Zip archive:

Now we can explore the contents of the APK with the Profiler. We have the usual ‘classes.dex’ file plus the native library ‘lib/armeabi/libnet.so’. Let’s open the library with IDA. You’ll notice the functions it contains aren’t many and just by looking at them we’ll stumble at this function:

It’s clear that at some point during the execution of the Dalvik code this function is triggered which writes the array ‘inject’ into the memory space of the DEX module. We can verify that they are indeed Dalvik opcodes with the appropriate filter. Select the bytes representing the array in the hex view and then open the filter view:

Dalvik filter

The functions called before the actual injection locate the exact position of the code. They help us as well: back to the Profiler, let’s find the method “L-ÿava/lang/String;”:”add”:


From here we get the class index and name. Just by looking at the disassembled class we’ll notice a method filled with nops:

Method with nops

The code size of the method matches the payload size (111 * 2 = 0xDE):


Let’s write back the instructions to the DEX module:

Write payload

We could do this with a filter just as well by the way:

And now we can analyze the injected code:

And that’s it. It took much more time to write the post than the rest (about 10 minutes of time if that). Reverse engineering the crackme to find the correct key is beyond the scope of the post, although I’m sure it’s fun as well.

Thanks to BlueBox for the crackme!

DEX support

Support for Android’s DEX format is the last major feature of the upcoming 0.9.0 release of the Profiler. The support includes format, layout ranges and a Dalvik disassembler. Support for APK is implicit, since support for Zip archives has been added long ago.

All sections of the format are accessible. The central point for parsing a DEX file is the Classes view. Hence it’s also the most complex view of the format.

Also accurate layout ranges can help to analyze the format.

And finally a disassembler to quickly inspect the Dalvik bytecode.

Here’s a disassembled function from the Android SDK NotePad sample:

And the original source for comparison:

Next week will be dedicated to fixing reported bugs and adding some small improvements. After that and some testing the new version should be ready, so keep tuned as the new version should be deployed soon!