feat: add fortinet custom parser #188
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
adampash
force-pushed
the
feat-fortinet-parser
branch
from
8d3502b
to
13ffe4e
Compare
🤖 Automated Parsing Preview 🤖Commit: Parsed JSON{
"title": "How-to Guide: Defeating an Android Packer with FRIDA",
"content": "<div><div class=\"responsivegrid aem-GridColumn aem-GridColumn--default--12\">\r\n<div class=\"aem-Grid aem-Grid--12 aem-Grid--default--12 \">\r\n \r\n <div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n<p><b><i>A FortiGuard Labs How-To Guide for Cybersecurity Threat Researchers</i></b></p>\n\n<p>Here at FortiGuard Labs we have encountered a lot of packed Android malware recently. One interesting aspect to this malware is that even though the packer being used is consistently the same, the malware that it drops changes quite frequently.</p>\n<p>Analysing packers can be very intimidating. It is generally very hard to understand the flow of the program, and the sheer amount of garbage displayed can easily scare analysts away.</p>\n<p>Because of that, we want show how we handle some of the problems that arise when analysing this kind of malware. In fact, in this blogpost we will demonstrate how to unpack the malware deployed by today’s most common dropper using only open-source free tools.</p>\n<p>The reference sample is: <i>509aa4a846c6cb52e9756a282de67da3e8ec82769bceafa1265428b1289459b3</i></p>\n<p><b>Statis Analysis</b></p>\n<p><i>Sample Overview</i></p>\n<p>First things first: We began by taking a look at what kind of APK we are dealing with.</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-image aem-GridColumn--default--none aem-GridColumn aem-GridColumn--default--10 aem-GridColumn--offset--default--1\">\n\n \n \n \n <span class=\"cmp-image--title\">Figure 1: files contained in the APK</span>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n\n<p>As can be seen, there is clearly something fishy in this sample. What is that <i>MawmjulbcbEndsqku^nd.cml </i>file?</p>\n<p>It does not hurt to start by asking the bash command <i>file</i><b><i> </i></b>what we are dealing with. Unfortunately, it did not detect any sort of file type. By looking at file with a hex editor (in this case, we actually used <a href=\"https://rada.re/r/\">radare2</a>, a great open-source reverse engineering framework), we still could not really tell what kind of file this is. </p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-image aem-GridColumn aem-GridColumn--default--12\">\n\n \n \n \n <span class=\"cmp-image--title\">Figure 2: Hex view of MawmjulbcbEndsqku^nd.cml</span>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n\n<p>These considerations, combined with the fact that the name looks like random characters, makes us consider that this may possibly be an encrypted file used by the main application.</p>\n<p>Maybe by taking a look at the Android Manifest we can gain a clearer idea of what is happening.</p>\n<p><b>Android Manifest</b></p>\n<p><i>AndroidManifest.xml</i> is an Android binary XML file that contains a lot of information about the application. It contains:</p>\n<p>-       The package name of the application, under which it will be accessible on the device</p>\n<p>-       The complete list of activities, services, and receivers used by the app (if they are not declared here, they will not be usable by the app later)</p>\n<p>-       A full list of permissions</p>\n<p>-       A full list of intent action filters used during execution</p>\n<p>-       Other usually less important stuff, like icons used, etc.</p>\n<p>The first thing we noticed was the use of completely random strings as the names for all of the components of the app. This can be an indicator of malicious intent, but it is also used by legitimate application developers to make it harder for the competition to reverse engineer their product.</p>\n<p>One of the things that first caught my attention was: with the sole exception of the Application class <i>com.asgradc.troernrn.yeSACsSs</i>, no declared Android component (activity, receiver, and service classes) were present in the decompiled <i>classes.dex </i>file. That’s odd: what’s the use of declaring non-existent classes and skipping the existing ones?</p>\n<p>It is now clear that additional external code is loaded by this APK. In addition, given the amount and nature of permissions requested—like asking to send SMS messages—we can be pretty confident that this code is up to no good.</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-image aem-GridColumn aem-GridColumn--default--12\">\n\n \n \n \n <span class=\"cmp-image--title\">Figure 3: AndroidManifest SMS filter</span>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n\n<p><b>Reversing the Packer</b></p>\n<p>There are many free options available for decompiling APKs into readable code. These include:</p>\n<p>-       Apktool : obtains the SMALI representation of the classes</p>\n<p>-       dex2jar : converts the .dex file into a jar archive which can be analysed using jd-gui</p>\n<p>-       jadx : decompiles in java all the code into a convenient GUI</p>\n<p>My personal favourite is jadx, but it is good to have options because in rare cases only some of them will be able to decompile the code.</p>\n<p>So we next started to analyse the APK on jadx. Unfortunately, things were not pretty...</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-image aem-GridColumn aem-GridColumn--default--12\">\n\n \n \n \n <span class=\"cmp-image--title\">Figure 4: Packer Application class</span>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n\n<p>In true packer fashion, we were welcomed by a lot of useless garbage: meaningless strings, meaningless computations, meaningless functions. We tried for a while to make sense out of the execution flow: if the encrypted file was to be decrypted, it would either need to call some crypto-library or have its own decrypting routine. Once the decrypting is done, it would then need to load the new file with a <a href=\"https://developer.android.com/reference/java/lang/ClassLoader\"><i>ClassLoader</i></a> Object of some kind.</p>\n<p>Unfortunately, none of these libraries were included in the APK imports. What was included were the Reflection methods that allow the file to indirectly call any loaded library. Once again, however, these reflection methods arguments were also dynamically created using a myriad of unintelligible functions.</p>\n<p>It was becoming clear that static analysis was not going to cut it. To quote George Bernard Shaw: </p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn--default--none aem-GridColumn aem-GridColumn--default--8 aem-GridColumn--offset--default--2\">\n\n<p><b><i>I learned long ago, never to wrestle with a pig. You get dirty, and besides, the pig likes it.</i></b><br>\n</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n\n<p>We were not going to wrestle with this pig any longer. There had to be a faster way.</p>\n<p><b>Dynamic Analysis</b></p>\n<p>Google provides the ability to download the SDKs used in all of its versions of Android to create emulators through Android Studio. It is perfect way to test malware like this without the risk of being infected.</p>\n<p>So we started by using the Marshmallow 6.0 emulator for this sample and installed the APK through <i>adb</i> (Android Debug Bridge). If the APK is to load a new executable file, the built-in logger of the device (or emulator in our case) should be able to pick it up.</p>\n<p>We ran the <i>adb</i> command that connects to the system logger and only selected those lines containing the package name of our dropper:</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n<p>$ adb logcat | grep "com.jgnxmcj.knreroaxvi" </p>\n<p>Then we launched the application. Among a lot of uninteresting output, we finally found what we had been looking for:<br>\n</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn--default--none aem-GridColumn aem-GridColumn--default--7 aem-GridColumn--offset--default--1\">\n\n<p>10-25 17:12:11.001 24358 24358 W dex2oat : /system/bin/dex2oat --runtime-arg -classpath --runtime-arg  --instruction-set=x86 --instruction-set-features=smp,ssse3,-sse4.1,-sse4.2,-avx,-avx2 --runtime-arg -Xrelocate --boot-image=/system/framework/boot.art --runtime-arg -Xms64m --runtime-arg -Xmx512m --instruction-set-variant=x86 --instruction-set-features=default --dex-file=/data/user/0/com.jgnxmcj.knreroaxvi/app_files/rzwohkt.jar --oat-file=/data/user/0/com.jgnxmcj.knreroaxvi/app_files/rzwohkt.dex<br>\n</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n\n<p>The APK is indeed creating a new <i>.dex</i> file. Nice. We only need to get this file and we will not need to reverse the dropper.</p>\n<p>Unfortunately, when we tried to grab that file we could not find it in <i>/data/user/0/com.jgnxmcj.knreroaxvi/app_files</i>. Apparently (and unusually, for many malware coders), these authors like to clean up after themselves by deleting the file after its use. So our next problem was, how do we stop the dropper from deleting the file?</p>\n<p>Let me introduce you to the tool of your dreams: <a href=\"https://frida.re/\">FRIDA</a></p>\n<p>FRIDA is a fantastic instrumentation kit that allows the hooking of Javascript code during the execution of the application. It is also able to modify functions, fields and much more.</p>\n<p>What we wanted to do in this case was to stop the application from deleting the <i>rzwohkt.jar </i>file so that we can pull it onto our machine for analysis.</p>\n<p>Traditionally with FRIDA, our MO would be to first find the class responsible for the deletion, then hook the method and skip it. However, we do not want to start the pig wresting match again, so we started by using dynamic analysis to exactly skip this part.</p>\n<p>We were only going to be able to bypass this if we could find out which system call is executed to finalize the deletion process. No matter where in the obfuscated code the call is made, if we hook the right native function in the system we should be able to retrieve our desired payload.</p>\n<p><b>Using Strace</b></p>\n<p>The big question next was, how could we possibly find the right function? Fortunately, there is one easy way to get a full list of all of the function calls happening during execution.</p>\n<p><a href=\"https://linux.die.net/man/1/strace\">Strace</a> is a great Linux utility tool that allows a user to get a full report of all the interactions between the processes and the Linux kernel. Because <a href=\"https://source.android.com/devices/tech/debug/strace\">Android supports it</a>, it provides us with the perfect tool for finding the function we need to hook.</p>\n\n\n \n\n</div>\n\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n\n<p>From the screenshot above, it is clear that the function we are looking for is unlink().</p>\n<p>What we needed to do next was to hook our alternative code to it in order to avoid the deletion of the file.</p>\n<p><b>FRIDA Code</b></p>\n<p>Finally, we had all of the information required. It was now time to create our FRIDA hook.</p>\n<p>First of all, we needed to run the correct <a href=\"https://github.com/frida/frida/releases\"><i>frida-server</i></a> on our mobile emulator, according to the architecture used.</p>\n<p>Now that we had a way to hook our FRIDA code, we just needed to create the script. All that was left to do was to hook the <i>unlink()</i> function and skip it. To do so, we used the <a href=\"https://www.frida.re/docs/javascript-api/#interceptor\">Interceptor.replace(target, replacement)</a> method, which allows us to replace the function at <i>target</i> with the implementation at <i>replacement</i>. We used </p>\n<p><i>Module.findExportByName(module, exp)</i> to get the pointer to our function; <i>null</i> can be passed as the module in case the module name is unknown (but it will affect speed).    <br>\n</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n<p>console.log("[*] FRIDA started");</p>\n<p>console.log("[*] skip native unlink function");</p>\n\n<p>// create a pointer to the function in the module</p>\n<p>var unlinkPtr = Module.findExportByName(null, 'unlink');</p>\n\n<p>Interceptor.replace(unlinkPtr, new NativeCallback(function (){  </p>\n<p>    console.log("[*] unlink() encountered, skipping it.");</p>\n<p>}, 'int', [])); </p>\n\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n<p>Now, whenever the <i>unlink()</i> function is called, FRIDA will intercept the call and run our code instead. In this case, it will simply output a logger string, notifying us that the call has been skipped.</p>\n<p>Finally, we only needed to attach the script to the app process. We ran <i>dropper_startup.py</i>, a quick python script that launches the application, and then attached the FRIDA script to the <i>frida-server</i>.</p>\n\n\n \n\n</div>\n\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n<p>The fact that we obtained multiple hits has to do with the facts that <i>unlink()</i> is used to also delete also files during execution. Finally, after the second unlink we were able to run:</p>\n<p>$ adb pull /data/user/0/com.jgnxmcj.knreroaxvi/app_files/rzwohkt.jar</p>\n<p>and successfully obtain our file, a jar archive containing the <i>classes.dex</i> payload </p>\n<p><b>Conclusion</b></p>\n<p>Android malware is becoming more and more sophisticated, and is evolving every day, much like the more mature Windows malware. Droppers are just one way to deploy payloads, but they are an effective one indeed. The random strings and pointless functions they use can easily trick AV engines. Fortinet clients, however, are protected from these samples using the following signatures:</p>\n<p>-       Dropper: Android/Agent.CHG!tr</p>\n<p>-       Payload: Android/Agent.ARL!tr</p>\n<p>FortiGuard Labs will continue to monitor these malware campaigns as they evolve.</p>\n<p>All the scripts used in this blog can be found on the <a href=\"https://github.com/fortiguard-lion/FRIDA-scripts\">FortiGuard Lion github page</a>.</p>\n<p><b>IOC:</b></p>\n<p>Packer: 509aa4a846c6cb52e9756a282de67da3e8ec82769bceafa1265428b1289459b3</p>\n<p>Payload: 4fa71942784c9f1d0d285dc44371d00da1f70f4da910da0ab2c41862b9e03c89</p>\n<p>-= FortiGuard Lion Team =-</p>\n<p><a href=\"https://www.fortinet.com/fortiguard/threat-intelligence/threat-research.html?utm_source=nreleaseblog&utm_campaign=2018-q2-fortiguardlabs-cta\"><i>Sign up</i></a><i> for our weekly FortiGuard Threat Brief.</i><br>\n</p>\n<p><i>Know your vulnerabilities – get the facts about your network security. A <a href=\"https://www.fortinet.com/offers/cyber-threat-assessment.html?utm_source=blog&utm_campaign=2018-q4-ctap-assessment\">Fortinet Cyber Threat Assessment</a> can help you better understand: Security and Threat Prevention, User Productivity, and Network Utilization and Performance.</i></p>\n\n\n \n\n</div>\n\n\r\n \r\n</div></div></div>",
"author": "Dario Durando",
"date_published": "2018-11-02T07:00:00.000Z",
"lead_image_url": "https://www.fortinet.com/content/dam/fortinet-blog/article-images/defeating_an_android_packer_with_frida/frida_02.png",
"dek": null,
"next_page_url": null,
"url": "https://www.fortinet.com/blog/threat-research/defeating-an-android-packer-with-frida.html",
"domain": "www.fortinet.com",
"word_count": 1765,
"direction": "ltr",
"total_pages": 1,
"rendered_pages": 1
}
|
adampash
suggested changes
Jan 14, 2019
There was a problem hiding this comment.
@WajeehZantout Good in theory, but I'm not seeing the figures in the output. LMK if you need help or if I can better explain what I'm expecting.
🤖 Automated Parsing Preview 🤖Commit: Parsed JSON{
"title": "How-to Guide: Defeating an Android Packer with FRIDA",
"content": "<div><div class=\"responsivegrid aem-GridColumn aem-GridColumn--default--12\">\r\n<div class=\"aem-Grid aem-Grid--12 aem-Grid--default--12 \">\r\n \r\n <div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n<p><b><i>A FortiGuard Labs How-To Guide for Cybersecurity Threat Researchers</i></b></p>\n\n<p>Here at FortiGuard Labs we have encountered a lot of packed Android malware recently. One interesting aspect to this malware is that even though the packer being used is consistently the same, the malware that it drops changes quite frequently.</p>\n<p>Analysing packers can be very intimidating. It is generally very hard to understand the flow of the program, and the sheer amount of garbage displayed can easily scare analysts away.</p>\n<p>Because of that, we want show how we handle some of the problems that arise when analysing this kind of malware. In fact, in this blogpost we will demonstrate how to unpack the malware deployed by today’s most common dropper using only open-source free tools.</p>\n<p>The reference sample is: <i>509aa4a846c6cb52e9756a282de67da3e8ec82769bceafa1265428b1289459b3</i></p>\n<p><b>Statis Analysis</b></p>\n<p><i>Sample Overview</i></p>\n<p>First things first: We began by taking a look at what kind of APK we are dealing with.</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-image aem-GridColumn--default--none aem-GridColumn aem-GridColumn--default--10 aem-GridColumn--offset--default--1\">\n\n \n <figure>\n <img src=\"https://www.fortinet.com/content/fortinet-blog/us/en/threat-research/defeating-an-android-packer-with-frida/_jcr_content/root/responsivegrid/image.img.png\" alt=\"Fortinet FortiGuard Labs Threat Research\">\n </figure>\n \n <span class=\"cmp-image--title\">Figure 1: files contained in the APK</span>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n\n<p>As can be seen, there is clearly something fishy in this sample. What is that <i>MawmjulbcbEndsqku^nd.cml </i>file?</p>\n<p>It does not hurt to start by asking the bash command <i>file</i><b><i> </i></b>what we are dealing with. Unfortunately, it did not detect any sort of file type. By looking at file with a hex editor (in this case, we actually used <a href=\"https://rada.re/r/\">radare2</a>, a great open-source reverse engineering framework), we still could not really tell what kind of file this is. </p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-image aem-GridColumn aem-GridColumn--default--12\">\n\n \n <figure>\n <img src=\"https://www.fortinet.com/content/fortinet-blog/us/en/threat-research/defeating-an-android-packer-with-frida/_jcr_content/root/responsivegrid/image_1091580682.img.png\" alt=\"Fortinet FortiGuard Labs Threat Research\">\n </figure>\n \n <span class=\"cmp-image--title\">Figure 2: Hex view of MawmjulbcbEndsqku^nd.cml</span>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n\n<p>These considerations, combined with the fact that the name looks like random characters, makes us consider that this may possibly be an encrypted file used by the main application.</p>\n<p>Maybe by taking a look at the Android Manifest we can gain a clearer idea of what is happening.</p>\n<p><b>Android Manifest</b></p>\n<p><i>AndroidManifest.xml</i> is an Android binary XML file that contains a lot of information about the application. It contains:</p>\n<p>-       The package name of the application, under which it will be accessible on the device</p>\n<p>-       The complete list of activities, services, and receivers used by the app (if they are not declared here, they will not be usable by the app later)</p>\n<p>-       A full list of permissions</p>\n<p>-       A full list of intent action filters used during execution</p>\n<p>-       Other usually less important stuff, like icons used, etc.</p>\n<p>The first thing we noticed was the use of completely random strings as the names for all of the components of the app. This can be an indicator of malicious intent, but it is also used by legitimate application developers to make it harder for the competition to reverse engineer their product.</p>\n<p>One of the things that first caught my attention was: with the sole exception of the Application class <i>com.asgradc.troernrn.yeSACsSs</i>, no declared Android component (activity, receiver, and service classes) were present in the decompiled <i>classes.dex </i>file. That’s odd: what’s the use of declaring non-existent classes and skipping the existing ones?</p>\n<p>It is now clear that additional external code is loaded by this APK. In addition, given the amount and nature of permissions requested—like asking to send SMS messages—we can be pretty confident that this code is up to no good.</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-image aem-GridColumn aem-GridColumn--default--12\">\n\n \n <figure>\n <img src=\"https://www.fortinet.com/content/fortinet-blog/us/en/threat-research/defeating-an-android-packer-with-frida/_jcr_content/root/responsivegrid/image_2133032318.img.png\" alt=\"Fortinet FortiGuard Labs Threat Research\">\n </figure>\n \n <span class=\"cmp-image--title\">Figure 3: AndroidManifest SMS filter</span>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n\n<p><b>Reversing the Packer</b></p>\n<p>There are many free options available for decompiling APKs into readable code. These include:</p>\n<p>-       Apktool : obtains the SMALI representation of the classes</p>\n<p>-       dex2jar : converts the .dex file into a jar archive which can be analysed using jd-gui</p>\n<p>-       jadx : decompiles in java all the code into a convenient GUI</p>\n<p>My personal favourite is jadx, but it is good to have options because in rare cases only some of them will be able to decompile the code.</p>\n<p>So we next started to analyse the APK on jadx. Unfortunately, things were not pretty...</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-image aem-GridColumn aem-GridColumn--default--12\">\n\n \n <figure>\n <img src=\"https://www.fortinet.com/content/fortinet-blog/us/en/threat-research/defeating-an-android-packer-with-frida/_jcr_content/root/responsivegrid/image_1883097380.img.png\" alt=\"Fortinet FortiGuard Labs Threat Research\">\n </figure>\n \n <span class=\"cmp-image--title\">Figure 4: Packer Application class</span>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n\n<p>In true packer fashion, we were welcomed by a lot of useless garbage: meaningless strings, meaningless computations, meaningless functions. We tried for a while to make sense out of the execution flow: if the encrypted file was to be decrypted, it would either need to call some crypto-library or have its own decrypting routine. Once the decrypting is done, it would then need to load the new file with a <a href=\"https://developer.android.com/reference/java/lang/ClassLoader\"><i>ClassLoader</i></a> Object of some kind.</p>\n<p>Unfortunately, none of these libraries were included in the APK imports. What was included were the Reflection methods that allow the file to indirectly call any loaded library. Once again, however, these reflection methods arguments were also dynamically created using a myriad of unintelligible functions.</p>\n<p>It was becoming clear that static analysis was not going to cut it. To quote George Bernard Shaw: </p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn--default--none aem-GridColumn aem-GridColumn--default--8 aem-GridColumn--offset--default--2\">\n\n<p><b><i>I learned long ago, never to wrestle with a pig. You get dirty, and besides, the pig likes it.</i></b><br>\n</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n\n<p>We were not going to wrestle with this pig any longer. There had to be a faster way.</p>\n<p><b>Dynamic Analysis</b></p>\n<p>Google provides the ability to download the SDKs used in all of its versions of Android to create emulators through Android Studio. It is perfect way to test malware like this without the risk of being infected.</p>\n<p>So we started by using the Marshmallow 6.0 emulator for this sample and installed the APK through <i>adb</i> (Android Debug Bridge). If the APK is to load a new executable file, the built-in logger of the device (or emulator in our case) should be able to pick it up.</p>\n<p>We ran the <i>adb</i> command that connects to the system logger and only selected those lines containing the package name of our dropper:</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n<p>$ adb logcat | grep "com.jgnxmcj.knreroaxvi" </p>\n<p>Then we launched the application. Among a lot of uninteresting output, we finally found what we had been looking for:<br>\n</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn--default--none aem-GridColumn aem-GridColumn--default--7 aem-GridColumn--offset--default--1\">\n\n<p>10-25 17:12:11.001 24358 24358 W dex2oat : /system/bin/dex2oat --runtime-arg -classpath --runtime-arg  --instruction-set=x86 --instruction-set-features=smp,ssse3,-sse4.1,-sse4.2,-avx,-avx2 --runtime-arg -Xrelocate --boot-image=/system/framework/boot.art --runtime-arg -Xms64m --runtime-arg -Xmx512m --instruction-set-variant=x86 --instruction-set-features=default --dex-file=/data/user/0/com.jgnxmcj.knreroaxvi/app_files/rzwohkt.jar --oat-file=/data/user/0/com.jgnxmcj.knreroaxvi/app_files/rzwohkt.dex<br>\n</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n\n<p>The APK is indeed creating a new <i>.dex</i> file. Nice. We only need to get this file and we will not need to reverse the dropper.</p>\n<p>Unfortunately, when we tried to grab that file we could not find it in <i>/data/user/0/com.jgnxmcj.knreroaxvi/app_files</i>. Apparently (and unusually, for many malware coders), these authors like to clean up after themselves by deleting the file after its use. So our next problem was, how do we stop the dropper from deleting the file?</p>\n<p>Let me introduce you to the tool of your dreams: <a href=\"https://frida.re/\">FRIDA</a></p>\n<p>FRIDA is a fantastic instrumentation kit that allows the hooking of Javascript code during the execution of the application. It is also able to modify functions, fields and much more.</p>\n<p>What we wanted to do in this case was to stop the application from deleting the <i>rzwohkt.jar </i>file so that we can pull it onto our machine for analysis.</p>\n<p>Traditionally with FRIDA, our MO would be to first find the class responsible for the deletion, then hook the method and skip it. However, we do not want to start the pig wresting match again, so we started by using dynamic analysis to exactly skip this part.</p>\n<p>We were only going to be able to bypass this if we could find out which system call is executed to finalize the deletion process. No matter where in the obfuscated code the call is made, if we hook the right native function in the system we should be able to retrieve our desired payload.</p>\n<p><b>Using Strace</b></p>\n<p>The big question next was, how could we possibly find the right function? Fortunately, there is one easy way to get a full list of all of the function calls happening during execution.</p>\n<p><a href=\"https://linux.die.net/man/1/strace\">Strace</a> is a great Linux utility tool that allows a user to get a full report of all the interactions between the processes and the Linux kernel. Because <a href=\"https://source.android.com/devices/tech/debug/strace\">Android supports it</a>, it provides us with the perfect tool for finding the function we need to hook.</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-image aem-GridColumn aem-GridColumn--default--12\">\n\n \n <figure>\n <img src=\"https://www.fortinet.com/content/fortinet-blog/us/en/threat-research/defeating-an-android-packer-with-frida/_jcr_content/root/responsivegrid/image_500264116.img.png\" alt=\"Fortinet FortiGuard Labs Threat Research\">\n </figure>\n \n <span class=\"cmp-image--title\">Figure 5: Strace output</span>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n\n<p>From the screenshot above, it is clear that the function we are looking for is unlink().</p>\n<p>What we needed to do next was to hook our alternative code to it in order to avoid the deletion of the file.</p>\n<p><b>FRIDA Code</b></p>\n<p>Finally, we had all of the information required. It was now time to create our FRIDA hook.</p>\n<p>First of all, we needed to run the correct <a href=\"https://github.com/frida/frida/releases\"><i>frida-server</i></a> on our mobile emulator, according to the architecture used.</p>\n<p>Now that we had a way to hook our FRIDA code, we just needed to create the script. All that was left to do was to hook the <i>unlink()</i> function and skip it. To do so, we used the <a href=\"https://www.frida.re/docs/javascript-api/#interceptor\">Interceptor.replace(target, replacement)</a> method, which allows us to replace the function at <i>target</i> with the implementation at <i>replacement</i>. We used </p>\n<p><i>Module.findExportByName(module, exp)</i> to get the pointer to our function; <i>null</i> can be passed as the module in case the module name is unknown (but it will affect speed).    <br>\n</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n<p>console.log("[*] FRIDA started");</p>\n<p>console.log("[*] skip native unlink function");</p>\n\n<p>// create a pointer to the function in the module</p>\n<p>var unlinkPtr = Module.findExportByName(null, 'unlink');</p>\n\n<p>Interceptor.replace(unlinkPtr, new NativeCallback(function (){  </p>\n<p>    console.log("[*] unlink() encountered, skipping it.");</p>\n<p>}, 'int', [])); </p>\n\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n<p>Now, whenever the <i>unlink()</i> function is called, FRIDA will intercept the call and run our code instead. In this case, it will simply output a logger string, notifying us that the call has been skipped.</p>\n<p>Finally, we only needed to attach the script to the app process. We ran <i>dropper_startup.py</i>, a quick python script that launches the application, and then attached the FRIDA script to the <i>frida-server</i>.</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-image aem-GridColumn aem-GridColumn--default--12\">\n\n \n <figure>\n <img src=\"https://www.fortinet.com/content/fortinet-blog/us/en/threat-research/defeating-an-android-packer-with-frida/_jcr_content/root/responsivegrid/image_673340006.img.png\" alt=\"Fortinet FortiGuard Labs Threat Research\">\n </figure>\n \n <span class=\"cmp-image--title\">Figure 6: FRIDA output</span>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n<p>The fact that we obtained multiple hits has to do with the facts that <i>unlink()</i> is used to also delete also files during execution. Finally, after the second unlink we were able to run:</p>\n<p>$ adb pull /data/user/0/com.jgnxmcj.knreroaxvi/app_files/rzwohkt.jar</p>\n<p>and successfully obtain our file, a jar archive containing the <i>classes.dex</i> payload </p>\n<p><b>Conclusion</b></p>\n<p>Android malware is becoming more and more sophisticated, and is evolving every day, much like the more mature Windows malware. Droppers are just one way to deploy payloads, but they are an effective one indeed. The random strings and pointless functions they use can easily trick AV engines. Fortinet clients, however, are protected from these samples using the following signatures:</p>\n<p>-       Dropper: Android/Agent.CHG!tr</p>\n<p>-       Payload: Android/Agent.ARL!tr</p>\n<p>FortiGuard Labs will continue to monitor these malware campaigns as they evolve.</p>\n<p>All the scripts used in this blog can be found on the <a href=\"https://github.com/fortiguard-lion/FRIDA-scripts\">FortiGuard Lion github page</a>.</p>\n<p><b>IOC:</b></p>\n<p>Packer: 509aa4a846c6cb52e9756a282de67da3e8ec82769bceafa1265428b1289459b3</p>\n<p>Payload: 4fa71942784c9f1d0d285dc44371d00da1f70f4da910da0ab2c41862b9e03c89</p>\n<p>-= FortiGuard Lion Team =-</p>\n<p><a href=\"https://www.fortinet.com/fortiguard/threat-intelligence/threat-research.html?utm_source=nreleaseblog&utm_campaign=2018-q2-fortiguardlabs-cta\"><i>Sign up</i></a><i> for our weekly FortiGuard Threat Brief.</i><br>\n</p>\n<p><i>Know your vulnerabilities – get the facts about your network security. A <a href=\"https://www.fortinet.com/offers/cyber-threat-assessment.html?utm_source=blog&utm_campaign=2018-q4-ctap-assessment\">Fortinet Cyber Threat Assessment</a> can help you better understand: Security and Threat Prevention, User Productivity, and Network Utilization and Performance.</i></p>\n\n\n \n\n</div>\n\n\r\n \r\n</div></div></div>",
"author": "Dario Durando",
"date_published": "2018-11-02T07:00:00.000Z",
"lead_image_url": "https://www.fortinet.com/content/dam/fortinet-blog/article-images/defeating_an_android_packer_with_frida/frida_02.png",
"dek": null,
"next_page_url": null,
"url": "https://www.fortinet.com/blog/threat-research/defeating-an-android-packer-with-frida.html",
"domain": "www.fortinet.com",
"word_count": 1765,
"direction": "ltr",
"total_pages": 1,
"rendered_pages": 1
}
|
🤖 Automated Parsing Preview 🤖Commit: Original Article | HTML Fixture | Parsed Content Preview Parsed JSON{
"title": "How-to Guide: Defeating an Android Packer with FRIDA",
"content": "<div><div class=\"responsivegrid aem-GridColumn aem-GridColumn--default--12\">\r\n<div class=\"aem-Grid aem-Grid--12 aem-Grid--default--12 \">\r\n \r\n <div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n<p><b><i>A FortiGuard Labs How-To Guide for Cybersecurity Threat Researchers</i></b></p>\n\n<p>Here at FortiGuard Labs we have encountered a lot of packed Android malware recently. One interesting aspect to this malware is that even though the packer being used is consistently the same, the malware that it drops changes quite frequently.</p>\n<p>Analysing packers can be very intimidating. It is generally very hard to understand the flow of the program, and the sheer amount of garbage displayed can easily scare analysts away.</p>\n<p>Because of that, we want show how we handle some of the problems that arise when analysing this kind of malware. In fact, in this blogpost we will demonstrate how to unpack the malware deployed by today’s most common dropper using only open-source free tools.</p>\n<p>The reference sample is: <i>509aa4a846c6cb52e9756a282de67da3e8ec82769bceafa1265428b1289459b3</i></p>\n<p><b>Statis Analysis</b></p>\n<p><i>Sample Overview</i></p>\n<p>First things first: We began by taking a look at what kind of APK we are dealing with.</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-image aem-GridColumn--default--none aem-GridColumn aem-GridColumn--default--10 aem-GridColumn--offset--default--1\">\n\n \n <figure>\n <img src=\"https://www.fortinet.com/content/fortinet-blog/us/en/threat-research/defeating-an-android-packer-with-frida/_jcr_content/root/responsivegrid/image.img.png\" alt=\"Fortinet FortiGuard Labs Threat Research\">\n </figure>\n \n <span class=\"cmp-image--title\">Figure 1: files contained in the APK</span>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n\n<p>As can be seen, there is clearly something fishy in this sample. What is that <i>MawmjulbcbEndsqku^nd.cml </i>file?</p>\n<p>It does not hurt to start by asking the bash command <i>file</i><b><i> </i></b>what we are dealing with. Unfortunately, it did not detect any sort of file type. By looking at file with a hex editor (in this case, we actually used <a href=\"https://rada.re/r/\">radare2</a>, a great open-source reverse engineering framework), we still could not really tell what kind of file this is. </p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-image aem-GridColumn aem-GridColumn--default--12\">\n\n \n <figure>\n <img src=\"https://www.fortinet.com/content/fortinet-blog/us/en/threat-research/defeating-an-android-packer-with-frida/_jcr_content/root/responsivegrid/image_1091580682.img.png\" alt=\"Fortinet FortiGuard Labs Threat Research\">\n </figure>\n \n <span class=\"cmp-image--title\">Figure 2: Hex view of MawmjulbcbEndsqku^nd.cml</span>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n\n<p>These considerations, combined with the fact that the name looks like random characters, makes us consider that this may possibly be an encrypted file used by the main application.</p>\n<p>Maybe by taking a look at the Android Manifest we can gain a clearer idea of what is happening.</p>\n<p><b>Android Manifest</b></p>\n<p><i>AndroidManifest.xml</i> is an Android binary XML file that contains a lot of information about the application. It contains:</p>\n<p>-       The package name of the application, under which it will be accessible on the device</p>\n<p>-       The complete list of activities, services, and receivers used by the app (if they are not declared here, they will not be usable by the app later)</p>\n<p>-       A full list of permissions</p>\n<p>-       A full list of intent action filters used during execution</p>\n<p>-       Other usually less important stuff, like icons used, etc.</p>\n<p>The first thing we noticed was the use of completely random strings as the names for all of the components of the app. This can be an indicator of malicious intent, but it is also used by legitimate application developers to make it harder for the competition to reverse engineer their product.</p>\n<p>One of the things that first caught my attention was: with the sole exception of the Application class <i>com.asgradc.troernrn.yeSACsSs</i>, no declared Android component (activity, receiver, and service classes) were present in the decompiled <i>classes.dex </i>file. That’s odd: what’s the use of declaring non-existent classes and skipping the existing ones?</p>\n<p>It is now clear that additional external code is loaded by this APK. In addition, given the amount and nature of permissions requested—like asking to send SMS messages—we can be pretty confident that this code is up to no good.</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-image aem-GridColumn aem-GridColumn--default--12\">\n\n \n <figure>\n <img src=\"https://www.fortinet.com/content/fortinet-blog/us/en/threat-research/defeating-an-android-packer-with-frida/_jcr_content/root/responsivegrid/image_2133032318.img.png\" alt=\"Fortinet FortiGuard Labs Threat Research\">\n </figure>\n \n <span class=\"cmp-image--title\">Figure 3: AndroidManifest SMS filter</span>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n\n<p><b>Reversing the Packer</b></p>\n<p>There are many free options available for decompiling APKs into readable code. These include:</p>\n<p>-       Apktool : obtains the SMALI representation of the classes</p>\n<p>-       dex2jar : converts the .dex file into a jar archive which can be analysed using jd-gui</p>\n<p>-       jadx : decompiles in java all the code into a convenient GUI</p>\n<p>My personal favourite is jadx, but it is good to have options because in rare cases only some of them will be able to decompile the code.</p>\n<p>So we next started to analyse the APK on jadx. Unfortunately, things were not pretty...</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-image aem-GridColumn aem-GridColumn--default--12\">\n\n \n <figure>\n <img src=\"https://www.fortinet.com/content/fortinet-blog/us/en/threat-research/defeating-an-android-packer-with-frida/_jcr_content/root/responsivegrid/image_1883097380.img.png\" alt=\"Fortinet FortiGuard Labs Threat Research\">\n </figure>\n \n <span class=\"cmp-image--title\">Figure 4: Packer Application class</span>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n\n<p>In true packer fashion, we were welcomed by a lot of useless garbage: meaningless strings, meaningless computations, meaningless functions. We tried for a while to make sense out of the execution flow: if the encrypted file was to be decrypted, it would either need to call some crypto-library or have its own decrypting routine. Once the decrypting is done, it would then need to load the new file with a <a href=\"https://developer.android.com/reference/java/lang/ClassLoader\"><i>ClassLoader</i></a> Object of some kind.</p>\n<p>Unfortunately, none of these libraries were included in the APK imports. What was included were the Reflection methods that allow the file to indirectly call any loaded library. Once again, however, these reflection methods arguments were also dynamically created using a myriad of unintelligible functions.</p>\n<p>It was becoming clear that static analysis was not going to cut it. To quote George Bernard Shaw: </p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn--default--none aem-GridColumn aem-GridColumn--default--8 aem-GridColumn--offset--default--2\">\n\n<p><b><i>I learned long ago, never to wrestle with a pig. You get dirty, and besides, the pig likes it.</i></b><br>\n</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n\n<p>We were not going to wrestle with this pig any longer. There had to be a faster way.</p>\n<p><b>Dynamic Analysis</b></p>\n<p>Google provides the ability to download the SDKs used in all of its versions of Android to create emulators through Android Studio. It is perfect way to test malware like this without the risk of being infected.</p>\n<p>So we started by using the Marshmallow 6.0 emulator for this sample and installed the APK through <i>adb</i> (Android Debug Bridge). If the APK is to load a new executable file, the built-in logger of the device (or emulator in our case) should be able to pick it up.</p>\n<p>We ran the <i>adb</i> command that connects to the system logger and only selected those lines containing the package name of our dropper:</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n<p>$ adb logcat | grep "com.jgnxmcj.knreroaxvi" </p>\n<p>Then we launched the application. Among a lot of uninteresting output, we finally found what we had been looking for:<br>\n</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn--default--none aem-GridColumn aem-GridColumn--default--7 aem-GridColumn--offset--default--1\">\n\n<p>10-25 17:12:11.001 24358 24358 W dex2oat : /system/bin/dex2oat --runtime-arg -classpath --runtime-arg  --instruction-set=x86 --instruction-set-features=smp,ssse3,-sse4.1,-sse4.2,-avx,-avx2 --runtime-arg -Xrelocate --boot-image=/system/framework/boot.art --runtime-arg -Xms64m --runtime-arg -Xmx512m --instruction-set-variant=x86 --instruction-set-features=default --dex-file=/data/user/0/com.jgnxmcj.knreroaxvi/app_files/rzwohkt.jar --oat-file=/data/user/0/com.jgnxmcj.knreroaxvi/app_files/rzwohkt.dex<br>\n</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n\n<p>The APK is indeed creating a new <i>.dex</i> file. Nice. We only need to get this file and we will not need to reverse the dropper.</p>\n<p>Unfortunately, when we tried to grab that file we could not find it in <i>/data/user/0/com.jgnxmcj.knreroaxvi/app_files</i>. Apparently (and unusually, for many malware coders), these authors like to clean up after themselves by deleting the file after its use. So our next problem was, how do we stop the dropper from deleting the file?</p>\n<p>Let me introduce you to the tool of your dreams: <a href=\"https://frida.re/\">FRIDA</a></p>\n<p>FRIDA is a fantastic instrumentation kit that allows the hooking of Javascript code during the execution of the application. It is also able to modify functions, fields and much more.</p>\n<p>What we wanted to do in this case was to stop the application from deleting the <i>rzwohkt.jar </i>file so that we can pull it onto our machine for analysis.</p>\n<p>Traditionally with FRIDA, our MO would be to first find the class responsible for the deletion, then hook the method and skip it. However, we do not want to start the pig wresting match again, so we started by using dynamic analysis to exactly skip this part.</p>\n<p>We were only going to be able to bypass this if we could find out which system call is executed to finalize the deletion process. No matter where in the obfuscated code the call is made, if we hook the right native function in the system we should be able to retrieve our desired payload.</p>\n<p><b>Using Strace</b></p>\n<p>The big question next was, how could we possibly find the right function? Fortunately, there is one easy way to get a full list of all of the function calls happening during execution.</p>\n<p><a href=\"https://linux.die.net/man/1/strace\">Strace</a> is a great Linux utility tool that allows a user to get a full report of all the interactions between the processes and the Linux kernel. Because <a href=\"https://source.android.com/devices/tech/debug/strace\">Android supports it</a>, it provides us with the perfect tool for finding the function we need to hook.</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-image aem-GridColumn aem-GridColumn--default--12\">\n\n \n <figure>\n <img src=\"https://www.fortinet.com/content/fortinet-blog/us/en/threat-research/defeating-an-android-packer-with-frida/_jcr_content/root/responsivegrid/image_500264116.img.png\" alt=\"Fortinet FortiGuard Labs Threat Research\">\n </figure>\n \n <span class=\"cmp-image--title\">Figure 5: Strace output</span>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n\n<p>From the screenshot above, it is clear that the function we are looking for is unlink().</p>\n<p>What we needed to do next was to hook our alternative code to it in order to avoid the deletion of the file.</p>\n<p><b>FRIDA Code</b></p>\n<p>Finally, we had all of the information required. It was now time to create our FRIDA hook.</p>\n<p>First of all, we needed to run the correct <a href=\"https://github.com/frida/frida/releases\"><i>frida-server</i></a> on our mobile emulator, according to the architecture used.</p>\n<p>Now that we had a way to hook our FRIDA code, we just needed to create the script. All that was left to do was to hook the <i>unlink()</i> function and skip it. To do so, we used the <a href=\"https://www.frida.re/docs/javascript-api/#interceptor\">Interceptor.replace(target, replacement)</a> method, which allows us to replace the function at <i>target</i> with the implementation at <i>replacement</i>. We used </p>\n<p><i>Module.findExportByName(module, exp)</i> to get the pointer to our function; <i>null</i> can be passed as the module in case the module name is unknown (but it will affect speed).    <br>\n</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n<p>console.log("[*] FRIDA started");</p>\n<p>console.log("[*] skip native unlink function");</p>\n\n<p>// create a pointer to the function in the module</p>\n<p>var unlinkPtr = Module.findExportByName(null, 'unlink');</p>\n\n<p>Interceptor.replace(unlinkPtr, new NativeCallback(function (){  </p>\n<p>    console.log("[*] unlink() encountered, skipping it.");</p>\n<p>}, 'int', [])); </p>\n\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n<p>Now, whenever the <i>unlink()</i> function is called, FRIDA will intercept the call and run our code instead. In this case, it will simply output a logger string, notifying us that the call has been skipped.</p>\n<p>Finally, we only needed to attach the script to the app process. We ran <i>dropper_startup.py</i>, a quick python script that launches the application, and then attached the FRIDA script to the <i>frida-server</i>.</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-image aem-GridColumn aem-GridColumn--default--12\">\n\n \n <figure>\n <img src=\"https://www.fortinet.com/content/fortinet-blog/us/en/threat-research/defeating-an-android-packer-with-frida/_jcr_content/root/responsivegrid/image_673340006.img.png\" alt=\"Fortinet FortiGuard Labs Threat Research\">\n </figure>\n \n <span class=\"cmp-image--title\">Figure 6: FRIDA output</span>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n<p>The fact that we obtained multiple hits has to do with the facts that <i>unlink()</i> is used to also delete also files during execution. Finally, after the second unlink we were able to run:</p>\n<p>$ adb pull /data/user/0/com.jgnxmcj.knreroaxvi/app_files/rzwohkt.jar</p>\n<p>and successfully obtain our file, a jar archive containing the <i>classes.dex</i> payload </p>\n<p><b>Conclusion</b></p>\n<p>Android malware is becoming more and more sophisticated, and is evolving every day, much like the more mature Windows malware. Droppers are just one way to deploy payloads, but they are an effective one indeed. The random strings and pointless functions they use can easily trick AV engines. Fortinet clients, however, are protected from these samples using the following signatures:</p>\n<p>-       Dropper: Android/Agent.CHG!tr</p>\n<p>-       Payload: Android/Agent.ARL!tr</p>\n<p>FortiGuard Labs will continue to monitor these malware campaigns as they evolve.</p>\n<p>All the scripts used in this blog can be found on the <a href=\"https://github.com/fortiguard-lion/FRIDA-scripts\">FortiGuard Lion github page</a>.</p>\n<p><b>IOC:</b></p>\n<p>Packer: 509aa4a846c6cb52e9756a282de67da3e8ec82769bceafa1265428b1289459b3</p>\n<p>Payload: 4fa71942784c9f1d0d285dc44371d00da1f70f4da910da0ab2c41862b9e03c89</p>\n<p>-= FortiGuard Lion Team =-</p>\n<p><a href=\"https://www.fortinet.com/fortiguard/threat-intelligence/threat-research.html?utm_source=nreleaseblog&utm_campaign=2018-q2-fortiguardlabs-cta\"><i>Sign up</i></a><i> for our weekly FortiGuard Threat Brief.</i><br>\n</p>\n<p><i>Know your vulnerabilities – get the facts about your network security. A <a href=\"https://www.fortinet.com/offers/cyber-threat-assessment.html?utm_source=blog&utm_campaign=2018-q4-ctap-assessment\">Fortinet Cyber Threat Assessment</a> can help you better understand: Security and Threat Prevention, User Productivity, and Network Utilization and Performance.</i></p>\n\n\n \n\n</div>\n\n\r\n \r\n</div></div></div>",
"author": "Dario Durando",
"date_published": "2018-11-02T07:00:00.000Z",
"lead_image_url": "https://www.fortinet.com/content/dam/fortinet-blog/article-images/defeating_an_android_packer_with_frida/frida_02.png",
"dek": null,
"next_page_url": null,
"url": "https://www.fortinet.com/blog/threat-research/defeating-an-android-packer-with-frida.html",
"domain": "www.fortinet.com",
"word_count": 1765,
"direction": "ltr",
"total_pages": 1,
"rendered_pages": 1
}
✅ All tests passed |
adampash
approved these changes
Jan 30, 2019
🤖 Automated Parsing Preview 🤖Commit: Original Article | HTML Fixture | Parsed Content Preview Parsed JSON{
"title": "How-to Guide: Defeating an Android Packer with FRIDA",
"content": "<div><div class=\"responsivegrid aem-GridColumn aem-GridColumn--default--12\">\r\n<div class=\"aem-Grid aem-Grid--12 aem-Grid--default--12 \">\r\n \r\n <div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n<p><b><i>A FortiGuard Labs How-To Guide for Cybersecurity Threat Researchers</i></b></p>\n\n<p>Here at FortiGuard Labs we have encountered a lot of packed Android malware recently. One interesting aspect to this malware is that even though the packer being used is consistently the same, the malware that it drops changes quite frequently.</p>\n<p>Analysing packers can be very intimidating. It is generally very hard to understand the flow of the program, and the sheer amount of garbage displayed can easily scare analysts away.</p>\n<p>Because of that, we want show how we handle some of the problems that arise when analysing this kind of malware. In fact, in this blogpost we will demonstrate how to unpack the malware deployed by today’s most common dropper using only open-source free tools.</p>\n<p>The reference sample is: <i>509aa4a846c6cb52e9756a282de67da3e8ec82769bceafa1265428b1289459b3</i></p>\n<p><b>Statis Analysis</b></p>\n<p><i>Sample Overview</i></p>\n<p>First things first: We began by taking a look at what kind of APK we are dealing with.</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-image aem-GridColumn--default--none aem-GridColumn aem-GridColumn--default--10 aem-GridColumn--offset--default--1\">\n\n \n <figure>\n <img src=\"https://www.fortinet.com/content/fortinet-blog/us/en/threat-research/defeating-an-android-packer-with-frida/_jcr_content/root/responsivegrid/image.img.png\" alt=\"Fortinet FortiGuard Labs Threat Research\">\n </figure>\n \n <span class=\"cmp-image--title\">Figure 1: files contained in the APK</span>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n\n<p>As can be seen, there is clearly something fishy in this sample. What is that <i>MawmjulbcbEndsqku^nd.cml </i>file?</p>\n<p>It does not hurt to start by asking the bash command <i>file</i><b><i> </i></b>what we are dealing with. Unfortunately, it did not detect any sort of file type. By looking at file with a hex editor (in this case, we actually used <a href=\"https://rada.re/r/\">radare2</a>, a great open-source reverse engineering framework), we still could not really tell what kind of file this is. </p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-image aem-GridColumn aem-GridColumn--default--12\">\n\n \n <figure>\n <img src=\"https://www.fortinet.com/content/fortinet-blog/us/en/threat-research/defeating-an-android-packer-with-frida/_jcr_content/root/responsivegrid/image_1091580682.img.png\" alt=\"Fortinet FortiGuard Labs Threat Research\">\n </figure>\n \n <span class=\"cmp-image--title\">Figure 2: Hex view of MawmjulbcbEndsqku^nd.cml</span>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n\n<p>These considerations, combined with the fact that the name looks like random characters, makes us consider that this may possibly be an encrypted file used by the main application.</p>\n<p>Maybe by taking a look at the Android Manifest we can gain a clearer idea of what is happening.</p>\n<p><b>Android Manifest</b></p>\n<p><i>AndroidManifest.xml</i> is an Android binary XML file that contains a lot of information about the application. It contains:</p>\n<p>-       The package name of the application, under which it will be accessible on the device</p>\n<p>-       The complete list of activities, services, and receivers used by the app (if they are not declared here, they will not be usable by the app later)</p>\n<p>-       A full list of permissions</p>\n<p>-       A full list of intent action filters used during execution</p>\n<p>-       Other usually less important stuff, like icons used, etc.</p>\n<p>The first thing we noticed was the use of completely random strings as the names for all of the components of the app. This can be an indicator of malicious intent, but it is also used by legitimate application developers to make it harder for the competition to reverse engineer their product.</p>\n<p>One of the things that first caught my attention was: with the sole exception of the Application class <i>com.asgradc.troernrn.yeSACsSs</i>, no declared Android component (activity, receiver, and service classes) were present in the decompiled <i>classes.dex </i>file. That’s odd: what’s the use of declaring non-existent classes and skipping the existing ones?</p>\n<p>It is now clear that additional external code is loaded by this APK. In addition, given the amount and nature of permissions requested—like asking to send SMS messages—we can be pretty confident that this code is up to no good.</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-image aem-GridColumn aem-GridColumn--default--12\">\n\n \n <figure>\n <img src=\"https://www.fortinet.com/content/fortinet-blog/us/en/threat-research/defeating-an-android-packer-with-frida/_jcr_content/root/responsivegrid/image_2133032318.img.png\" alt=\"Fortinet FortiGuard Labs Threat Research\">\n </figure>\n \n <span class=\"cmp-image--title\">Figure 3: AndroidManifest SMS filter</span>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n\n<p><b>Reversing the Packer</b></p>\n<p>There are many free options available for decompiling APKs into readable code. These include:</p>\n<p>-       Apktool : obtains the SMALI representation of the classes</p>\n<p>-       dex2jar : converts the .dex file into a jar archive which can be analysed using jd-gui</p>\n<p>-       jadx : decompiles in java all the code into a convenient GUI</p>\n<p>My personal favourite is jadx, but it is good to have options because in rare cases only some of them will be able to decompile the code.</p>\n<p>So we next started to analyse the APK on jadx. Unfortunately, things were not pretty...</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-image aem-GridColumn aem-GridColumn--default--12\">\n\n \n <figure>\n <img src=\"https://www.fortinet.com/content/fortinet-blog/us/en/threat-research/defeating-an-android-packer-with-frida/_jcr_content/root/responsivegrid/image_1883097380.img.png\" alt=\"Fortinet FortiGuard Labs Threat Research\">\n </figure>\n \n <span class=\"cmp-image--title\">Figure 4: Packer Application class</span>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n\n<p>In true packer fashion, we were welcomed by a lot of useless garbage: meaningless strings, meaningless computations, meaningless functions. We tried for a while to make sense out of the execution flow: if the encrypted file was to be decrypted, it would either need to call some crypto-library or have its own decrypting routine. Once the decrypting is done, it would then need to load the new file with a <a href=\"https://developer.android.com/reference/java/lang/ClassLoader\"><i>ClassLoader</i></a> Object of some kind.</p>\n<p>Unfortunately, none of these libraries were included in the APK imports. What was included were the Reflection methods that allow the file to indirectly call any loaded library. Once again, however, these reflection methods arguments were also dynamically created using a myriad of unintelligible functions.</p>\n<p>It was becoming clear that static analysis was not going to cut it. To quote George Bernard Shaw: </p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn--default--none aem-GridColumn aem-GridColumn--default--8 aem-GridColumn--offset--default--2\">\n\n<p><b><i>I learned long ago, never to wrestle with a pig. You get dirty, and besides, the pig likes it.</i></b><br>\n</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n\n<p>We were not going to wrestle with this pig any longer. There had to be a faster way.</p>\n<p><b>Dynamic Analysis</b></p>\n<p>Google provides the ability to download the SDKs used in all of its versions of Android to create emulators through Android Studio. It is perfect way to test malware like this without the risk of being infected.</p>\n<p>So we started by using the Marshmallow 6.0 emulator for this sample and installed the APK through <i>adb</i> (Android Debug Bridge). If the APK is to load a new executable file, the built-in logger of the device (or emulator in our case) should be able to pick it up.</p>\n<p>We ran the <i>adb</i> command that connects to the system logger and only selected those lines containing the package name of our dropper:</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n<p>$ adb logcat | grep "com.jgnxmcj.knreroaxvi" </p>\n<p>Then we launched the application. Among a lot of uninteresting output, we finally found what we had been looking for:<br>\n</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn--default--none aem-GridColumn aem-GridColumn--default--7 aem-GridColumn--offset--default--1\">\n\n<p>10-25 17:12:11.001 24358 24358 W dex2oat : /system/bin/dex2oat --runtime-arg -classpath --runtime-arg  --instruction-set=x86 --instruction-set-features=smp,ssse3,-sse4.1,-sse4.2,-avx,-avx2 --runtime-arg -Xrelocate --boot-image=/system/framework/boot.art --runtime-arg -Xms64m --runtime-arg -Xmx512m --instruction-set-variant=x86 --instruction-set-features=default --dex-file=/data/user/0/com.jgnxmcj.knreroaxvi/app_files/rzwohkt.jar --oat-file=/data/user/0/com.jgnxmcj.knreroaxvi/app_files/rzwohkt.dex<br>\n</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n\n<p>The APK is indeed creating a new <i>.dex</i> file. Nice. We only need to get this file and we will not need to reverse the dropper.</p>\n<p>Unfortunately, when we tried to grab that file we could not find it in <i>/data/user/0/com.jgnxmcj.knreroaxvi/app_files</i>. Apparently (and unusually, for many malware coders), these authors like to clean up after themselves by deleting the file after its use. So our next problem was, how do we stop the dropper from deleting the file?</p>\n<p>Let me introduce you to the tool of your dreams: <a href=\"https://frida.re/\">FRIDA</a></p>\n<p>FRIDA is a fantastic instrumentation kit that allows the hooking of Javascript code during the execution of the application. It is also able to modify functions, fields and much more.</p>\n<p>What we wanted to do in this case was to stop the application from deleting the <i>rzwohkt.jar </i>file so that we can pull it onto our machine for analysis.</p>\n<p>Traditionally with FRIDA, our MO would be to first find the class responsible for the deletion, then hook the method and skip it. However, we do not want to start the pig wresting match again, so we started by using dynamic analysis to exactly skip this part.</p>\n<p>We were only going to be able to bypass this if we could find out which system call is executed to finalize the deletion process. No matter where in the obfuscated code the call is made, if we hook the right native function in the system we should be able to retrieve our desired payload.</p>\n<p><b>Using Strace</b></p>\n<p>The big question next was, how could we possibly find the right function? Fortunately, there is one easy way to get a full list of all of the function calls happening during execution.</p>\n<p><a href=\"https://linux.die.net/man/1/strace\">Strace</a> is a great Linux utility tool that allows a user to get a full report of all the interactions between the processes and the Linux kernel. Because <a href=\"https://source.android.com/devices/tech/debug/strace\">Android supports it</a>, it provides us with the perfect tool for finding the function we need to hook.</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-image aem-GridColumn aem-GridColumn--default--12\">\n\n \n <figure>\n <img src=\"https://www.fortinet.com/content/fortinet-blog/us/en/threat-research/defeating-an-android-packer-with-frida/_jcr_content/root/responsivegrid/image_500264116.img.png\" alt=\"Fortinet FortiGuard Labs Threat Research\">\n </figure>\n \n <span class=\"cmp-image--title\">Figure 5: Strace output</span>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n\n<p>From the screenshot above, it is clear that the function we are looking for is unlink().</p>\n<p>What we needed to do next was to hook our alternative code to it in order to avoid the deletion of the file.</p>\n<p><b>FRIDA Code</b></p>\n<p>Finally, we had all of the information required. It was now time to create our FRIDA hook.</p>\n<p>First of all, we needed to run the correct <a href=\"https://github.com/frida/frida/releases\"><i>frida-server</i></a> on our mobile emulator, according to the architecture used.</p>\n<p>Now that we had a way to hook our FRIDA code, we just needed to create the script. All that was left to do was to hook the <i>unlink()</i> function and skip it. To do so, we used the <a href=\"https://www.frida.re/docs/javascript-api/#interceptor\">Interceptor.replace(target, replacement)</a> method, which allows us to replace the function at <i>target</i> with the implementation at <i>replacement</i>. We used </p>\n<p><i>Module.findExportByName(module, exp)</i> to get the pointer to our function; <i>null</i> can be passed as the module in case the module name is unknown (but it will affect speed).    <br>\n</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n<p>console.log("[*] FRIDA started");</p>\n<p>console.log("[*] skip native unlink function");</p>\n\n<p>// create a pointer to the function in the module</p>\n<p>var unlinkPtr = Module.findExportByName(null, 'unlink');</p>\n\n<p>Interceptor.replace(unlinkPtr, new NativeCallback(function (){  </p>\n<p>    console.log("[*] unlink() encountered, skipping it.");</p>\n<p>}, 'int', [])); </p>\n\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n<p>Now, whenever the <i>unlink()</i> function is called, FRIDA will intercept the call and run our code instead. In this case, it will simply output a logger string, notifying us that the call has been skipped.</p>\n<p>Finally, we only needed to attach the script to the app process. We ran <i>dropper_startup.py</i>, a quick python script that launches the application, and then attached the FRIDA script to the <i>frida-server</i>.</p>\n\n\n \n\n</div>\n<div class=\"cmp cmp-image aem-GridColumn aem-GridColumn--default--12\">\n\n \n <figure>\n <img src=\"https://www.fortinet.com/content/fortinet-blog/us/en/threat-research/defeating-an-android-packer-with-frida/_jcr_content/root/responsivegrid/image_673340006.img.png\" alt=\"Fortinet FortiGuard Labs Threat Research\">\n </figure>\n \n <span class=\"cmp-image--title\">Figure 6: FRIDA output</span>\n\n\n \n\n</div>\n<div class=\"cmp cmp-text aem-GridColumn aem-GridColumn--default--12\">\n\n<p>The fact that we obtained multiple hits has to do with the facts that <i>unlink()</i> is used to also delete also files during execution. Finally, after the second unlink we were able to run:</p>\n<p>$ adb pull /data/user/0/com.jgnxmcj.knreroaxvi/app_files/rzwohkt.jar</p>\n<p>and successfully obtain our file, a jar archive containing the <i>classes.dex</i> payload </p>\n<p><b>Conclusion</b></p>\n<p>Android malware is becoming more and more sophisticated, and is evolving every day, much like the more mature Windows malware. Droppers are just one way to deploy payloads, but they are an effective one indeed. The random strings and pointless functions they use can easily trick AV engines. Fortinet clients, however, are protected from these samples using the following signatures:</p>\n<p>-       Dropper: Android/Agent.CHG!tr</p>\n<p>-       Payload: Android/Agent.ARL!tr</p>\n<p>FortiGuard Labs will continue to monitor these malware campaigns as they evolve.</p>\n<p>All the scripts used in this blog can be found on the <a href=\"https://github.com/fortiguard-lion/FRIDA-scripts\">FortiGuard Lion github page</a>.</p>\n<p><b>IOC:</b></p>\n<p>Packer: 509aa4a846c6cb52e9756a282de67da3e8ec82769bceafa1265428b1289459b3</p>\n<p>Payload: 4fa71942784c9f1d0d285dc44371d00da1f70f4da910da0ab2c41862b9e03c89</p>\n<p>-= FortiGuard Lion Team =-</p>\n<p><a href=\"https://www.fortinet.com/fortiguard/threat-intelligence/threat-research.html?utm_source=nreleaseblog&utm_campaign=2018-q2-fortiguardlabs-cta\"><i>Sign up</i></a><i> for our weekly FortiGuard Threat Brief.</i><br>\n</p>\n<p><i>Know your vulnerabilities – get the facts about your network security. A <a href=\"https://www.fortinet.com/offers/cyber-threat-assessment.html?utm_source=blog&utm_campaign=2018-q4-ctap-assessment\">Fortinet Cyber Threat Assessment</a> can help you better understand: Security and Threat Prevention, User Productivity, and Network Utilization and Performance.</i></p>\n\n\n \n\n</div>\n\n\r\n \r\n</div></div></div>",
"author": "Dario Durando",
"date_published": "2018-11-02T07:00:00.000Z",
"lead_image_url": "https://www.fortinet.com/content/dam/fortinet-blog/article-images/defeating_an_android_packer_with_frida/frida_02.png",
"dek": null,
"next_page_url": null,
"url": "https://www.fortinet.com/blog/threat-research/defeating-an-android-packer-with-frida.html",
"domain": "www.fortinet.com",
"word_count": 1765,
"direction": "ltr",
"total_pages": 1,
"rendered_pages": 1
}
✅ All tests passed |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds a custom parser for fortinet.com that converts lazy-loaded noscript images to figures and parses the author name properly.