Investigating some hardening techniques from a CraxsRAT Brazilian variant
The increase in mobile malware threats is evident, especially when discussing threat actors targeting financial institutions, as the Avast Q1/2023 Threat Report pointed out.
A few months ago I came across an interesting CraxsRAT malware variant, where tools like VirusTotal, hybrid-analysis, and Mobsf were unable to decompile the artifact. After reading some blog posts recently, I decided to add my two cents with this case.
Threat actors
(If you prefer, you can go straight to the analysis section).
So, during the artifact analysis, I found references to the threat actor TheGoiano, responsible for the dissemination of the famous variant BRATA RAT.
Once I identified the possible threat actor, I looked for references until I came across a YouTube video demonstrating the use of a new builder tool.
Based on the code structure, layout, and functionalities, I noticed the similarity with the CypherRAT and CraxsRAT malwares, even more so when analyzing the CypherRAT builder and source code, but I’ll talk about that later.
Both malwares were developed by the Syrian threat actor EVLF, which recently announced that will no longer support the tool.
Analysis
I started trying to decompile the GhostRAT APK artifact using apktool, but I got an error that extended to tools like jadx and mobsf.
Realizing that the error was happening while loading the Resource Table, I decided to take a look at the file before decompression and saw the following structure.
I was quite intrigued by the unusual directory structure and continued the analysis investigating the permissions and services using aapt (Android Asset Packaging Tool).
Those excessive permissions and AccessibilityService references are strong indications of RAT (Remote Access Trojan) malware.
Then, I tried to use apktool again adding the -r flag to prevent resources from being decoded, and started to analyze the code, which was also obfuscated.
During the code analysis, I noticed the similarity with the CypherRAT when inspecting the communication with C2, in addition to the permissions and services.
After dynamically analyzing the malware behavior and knowing that this was a variant, I decided to stop there and move to understand how this malware was being protected against decompilation tools.
The “hardening”
As previously mentioned, one of the malware strings referred to goianorat and, when I visited the threat actor YouTube channel, I saw during the new malware builder demonstration that there were references to “Confusing AndroidManifest” and “Protecting Resource Table”.
I started looking for the original source code (before build), as a way to accelerate the analysis 🤓 and waded through dark valleys of l00ters offering extremely suspicious versions until I got an older version of CypherRAT.
Then, I browsed to the step where the protections were applied trying to understand the techniques, but guess what? These protections were not introduced in this version or were previously removed. 😟
Back to square one and looking for references about APK bad formatting, I came across some posts and a very interesting presentation, explaining how Android interprets information from resources and compression structure. For example, it’s possible to add additional package names in the AndroidManifest.xml file and Android interprets “which is right”.
From there, I proceeded to analyze the resources.arsc hexadecimal and I had a happy surprise.
In the hex code, there was a reference to the ARSCLib project that is designed to be independent of aapt/aapt2, and looking at the developer’s repository I found a tool called APKEditor that uses this project as a base.
Besides the threat actor giving a star to the project (ksksks), the APKEditor output is pretty similar to the malware builder and, by analyzing the code, it’s possible to identify the protection methods invoked.
In short, these methods are responsible for causing bad formatting in the AndroidManifest, ZIP compression - creating folders with the resources’ name, and the Resource Table, so the malware was able to trick decompiling software when working with this structure.
Conclusion
I wanted to demonstrate in this post how this process of understanding more about the artifact and its build was. I didn’t go into detail on how Android interprets the artifact, as there are amazing references that I left in this post, but I’ll come back with some summary on this topic.
References
https://www.cyfirma.com/outofband/unmasking-evlf-dev-the-creator-of-cypherrat-and-craxsrat/
http://maldr0id.blogspot.com/2014/09/having-fun-with-androidmanifestxml.html
https://www.youtube.com/watch?v=ozfYqsPNc3o
https://blog.csdn.net/song6974272/article/details/119991751
https://github.com/REAndroid/APKEditor
https://github.com/REAndroid/ARSCLib
