Welcome to our brand new blog series, Triage Insights!
What is this new series about?
In this series, we would like to pick some latest/trending/interesting malware based on our currently supported platforms and conduct some hands-on malware analysis through our lovely Triage Sandbox.
By studying malware, we can gain insight into their behaviors, tactics, potential targets, and other factors. In addition, we will also provide some ideas and tips from a malware analyst’s perspective on how to perform further in-depth analysis of malware and speed up the whole process of malware analysis, making malware analysis easier.
What is this series aiming for?
In the field of malware analysis, static and dynamic analysis are essential and complementary techniques. Static analysis involves dissecting large and intricate codebases, which can be laborious and time-intensive for analysts. Dynamic analysis, on the other hand, demands substantial setup effort, configuring virtual environments, and tweaking settings while also considering potential impacts on the analyst’s own system due to malware behavior.
In response to these challenges, an online sandbox emerges as a comprehensive solution. We aim to share what can be achieved with Triage Sandbox, alleviating the complexities associated with both static and dynamic analyses.
If you have limited knowledge about malware but wish to examine whether an unknown file has the potential to behave maliciously, simply upload the file to Triage Sandbox. We’ll identify any suspicious activity and give you a risk score, so you can determine if the file is up to no good.
Triage Sandbox has also proven invaluable to those in the field of malware analysis. It speeds up the initial analysis by providing multiple customizable settings, high interactivity, easy one-click access to download payloads and network packets, and easy-to-read reports. Best of all, it’s free for individual users and researchers on the Triage public cloud!
How do we pick malware?
Malware will be picked for this series based on a set of criteria, including but not limited to:
- Recently popular.
- The old family reappears.
- Any new findings or interesting behaviors we’ve discovered
If you come across any interesting things regarding malware on Triage that you’d like to share, or if you’re interested in learning more about Triage, please feel free to let us know. We are passionate about working with you to explore and fight malware.
Now, let’s begin our very first Triage Insight series.
In today’s blog, we’ll explore the Octo malware family – an Android banking trojan initially discovered by ThreatFabric on underground forums. In the last year, we’ve added detections and implemented a configuration extractor to dump its C2 (Command and Control) information.
Notably, we have recently observed a significant number of Octo samples appearing in the public Triage cloud, accompanied by numerous new C2 domains and targeting more applications such as banking, payment, and crypto wallets. It seems that this malware is still continually being developed and distributed. As a result, we want to pick this malware family as our first target to go over a thorough step-by-step analysis via our Triage Sandbox.
Octo Malware Analysis
Targeted Sample Information
Report Link: https://tria.ge/231101-1wx7cadf5y
To get this sample or other related ones from Triage, simply search for the hash or malware family name on the Triage cloud. For detailed search guidelines, you can refer to the search page.
To submit a sample to Triage, there are three options:
- Upload the file directly via Web UI.
- Fetch the file from a given URL.
- Use Triage API, for more information about API check out our official documentation.
If you want to submit a file again from an existing sample, no worries! You can simply resubmit it without worrying about messing up your environment.
On the submission page, you can customize settings for the analysis on the right-hand side. If you don’t select, Triage will automatically detect the file type and launch an Android VM. Custom settings include various operating systems (Windows, macOS, Android, Linux), the language used by the system, network settings, timeout, and default browser.
When selecting the Android platform, we offer four different OS options with different architectures: Android 10 (x64), Android 11 (x64-arm64), Android 13 (x64-arm64), and Android 9 (x86-arm). It is recommended to select all four operating systems during analysis, as most Android mobile phones use the ARM architecture as their CPU. If only the x64 architecture is selected, some applications may fail to run due to unsupported CPU architecture.
Interacting in Triage Monitor
Once you start the analysis, you will get into Triage Live Monitor. From there, you can control the virtual hosts you selected and simulate behaviors like typing or scrolling the screen. You can also enter text or click more screens in the application to trigger hidden malware behaviors.
You can switch between different Android VMs by clicking on the tabs above or the virtual machine windows in the Live Monitor on the left-hand side.
For the Android platform, Triage allows the malware to perform all dangerous behaviors by automatically granting requested permissions without human interaction.
Upon completion of all VMs, you can access the overview report, static report, and individual analysis report for each selected VM.
Let’s start with the overview report.
The General section shows some basic information about the target file, including file name, file size, hash, and SSDEEP. Additionally, on the right, there will be the risk score for the file and the tags associated with the file. If there is a red tag, it means it is a known malware family, just like OCTO in this analysis.
Sometimes, you may notice that a malware sample may be associated with more than one malware family. It suggests that the malware may have originated from an earlier malware family or shared code with another malware family. This information is useful for malware analysts as it helps them research the evolution of the malware and its similarities with other malware families.
In the Malware Config section, you can find configurations regarding the particular malware family, such as its Command and Control (C2), version number, botnet number, encryption method (with its key), User-Agent, and other relevant attributes. Our team of analysts has created a handy way to extract these malware configurations, enabling Triage to quickly retrieve malware configurations once it detects a known malware family.
Let’s take a look at Octo. We’ve extracted all the potential C2 and the encryption key for AES. If you want to explore this malware further and conduct further analysis, like figuring out what kind of data exactly is being sent to the C2 or decrypting encrypted files or strings, having this information is super useful.
Moving on to the Targets section, it not only displays the malware family that Triage identifies but also shows all the malicious activities performed by malware in all VMs. It provides a comprehensive overview of the malware’s intentions.
As shown in the above image, we can see that Octo can make use of the framework’s Accessibility service and query a list of all the installed applications on the device, which is very common in banking trojans, because theys will look for the target banking applications that the user has installed and attempt to overlay a fake login page on top of it to intercept the user’s credentials.
Octo also has the capability to read phone information and acquire the wake lock to keep the device awake, enabling continuous execution of malicious activities such as data stealing or sending sensitive data to the C2.
Also, disabling battery optimizations and removing a system notification are both indicators that this malware wants to perform malicious activities without the user’s knowledge.
Last but not least, it is important to note that loading dropped Dex/Jar files is a significant indicator of potential malware. It is because it involves loading extra files/codes during runtime, which is often a technique called dynamic code loading (DCL), used by threat actors to conceal their payloads from malware analysts and anti-virus software. According to a threat trends report by the Google Cloud security team earlier this year, malware authors commonly use this way to sneak malicious payloads into the Google Play Store.
In Triage, we will list these additional payloads for you to download, and you can easily download them with one click in each VM report that has this behavior.
Next is the Static Report, where you can find static information for a given file you are analyzing. It can give you broad ideas to help you conduct further analysis of the malware.
In the Signatures section, Triage displays all the dangerous framework permissions that have been requested. It gives an overview of the type of actions the malware is attempting to perform. For instance, in this Octo sample, there are 5 requested permissions, which include:
|Allows an application to receive SMS messages.
|Allows an application to read SMS messages.
|Allows an application to send SMS messages.
|Allows read only access to phone state, including the current cellular network information, the status of any ongoing calls, and a list of any PhoneAccounts registered on the device.
|Allows an application to initiate a phone call without going through the Dialer user interface for the user to confirm the call.
By checking the permission information listed here, you can check whether the Android APIs corresponding to these permissions are being utilized in the malware codebase. It helps to verify if the malware is abusing these permissions, making it easier for analysts to discover any code evidence related to malicious behaviors.
In the Files section, you can find a list of the Activities, Receivers, and Services associated with the application. This information can be greatly useful for identifying any malicious behaviors in the code during static analysis. It can help you determine the entry point of the application, where SMS is being sent or received, where AccessibilityService is being utilized, etc.
Activities section of the static report
Receivers section of the static report
Services section of the static report
However, if you attempt to open Octo’s APK directly with a reverse engineering tool such as Jadx (see image below), you will find that the above code under
com.broughtbluea class is missing. It indicates that its code is most likely dynamically loaded at runtime, a common evasion technique used by malware to evade static analysis. But there is no need to worry, as we will show you how to overcome it with the help of Triage in the following sections.
For every VM that you have selected, there will be separate reports available that provide details about its network, signature, processes, replay monitors, and downloads.
Let’s take a look at the first VM result for its Signatures section:
From here, you can see the malware family along with its description, as well as the Octo payload detected by our Yara rules, which indicate that these payloads are using the DCL technique we mentioned earlier, and then all detected by Triage.
After expanding the IoCs
Loads dropped Dex/Jar, you can get the names of all payloads, and download the corresponding payloads from the
Downloads section at the bottom according to these names.
In the Network section, you can easily view the comprehensive flow of network requests, including TCP and UDP. Such information will help analysts further validate the C2 and the data the malware is trying to send as well as how it interacts with the C2 server in this particular environment.
In this Octo sample, it will use
h[xx]ps://pakuxxxnatationclass2[.]net/Njk4Zjk4YjdjODY3/ as its C2 server.
If you wish to analyze the entire network packet, you can utilize tools like Wireshark. To do so, you can download either PCAP or PCAPNG from the top left corner of the page for further analysis.
In addition, Triage Sandbox provides easy access to decrypted HTTPS traffic. To access the traffic, all you need to do is download the PCAPNG (PCAP Next Generation) file that contains the full decrypted SSL/TLS traffic dump with HTTPS already decrypted. To inspect the traffic, simply open it using Wireshark/TShark (version 3 or later).
Now, let’s figure out what data Octo is trying to send or receive through HTTPS traffic. After opening the PCAPNG with Wireshark, it is clear that all HTTPS traffic has been decrypted.
However, it seems that the data is encrypted additionally somehow and cannot be accessed easily. To find out the content of the data, we must have a look at the DEX payload (you can find it in the
Downloads section) and analyze how it is encrypted. After digging into the code, we found that Octo uses the
Cgoto.m140try method to encrypt all JSON data before transmitting it. The
m140try method definition indicates that the way of the encryption is AES with ECB mode and then encoded via Base64.
The method used for communicating with the C2 server
The method used for encrypting the JSON data
To obtain the AES key value, the malware first decrypts the encrypted string using RC4 and then hashes the result using MD5. After that, the AES key value is
54569d2aaae7176335a67bf72e86736f. It’s interesting to note that the hexadecimal format of this value is exactly the same as the AES key value extracted from the previous malware config section, which is
Once we have the AES key in hand, we can use tools like CyberChef to decrypt the data that has been encrypted and hidden in the HTTPS traffic. After decryption, we can explore the contents and figure out what it’s all about.
With the help of Replay Monitor, you can review all the past operations on this VM and observe the behaviors of this malware throughout the entire process. Taking Octo as an example, we can see that after requesting multiple dangerous permissions, the user is constantly prompted to turn off Google Play Protect scanning to prevent detection by Google Play.
Within the Downloads section, you can find files used by this application in the sandbox environment. It includes the payload that has been dropped and any files that have been generated or downloaded during the application’s execution. You can also resubmit these files from this section.
In the image below, you can find the name corresponding to the
Loads dropped Dex/Jar behavior mentioned in the Signatures section. One of the Indicators of Compromise (IOCs) is
/data/user/0/com.broughtbluea/cache/pxcpq, By clicking this download button, you can obtain the DEX payload designed for Octo’s dynamic loading, which contains the code concealed by the malware author.
Let’s open this file with Jadx again, then you can find that the concealed code mentioned earlier will be brought to light here.
By leveraging Triage in malware analysis, analysts can benefit from more than just malware detection. Triage offers valuable guidance during both static and dynamic analysis, allowing analysts to focus on the most critical aspects of the targeted malware. Furthermore, Triage simplifies virtual machine settings, making it possible to analyze most malware by using default settings. Best of all, there is no need to worry about malware affecting your environment.
During our analysis of Octo, we found that the majority of malicious code was not available through static analysis of the APK file itself. To obtain the dropped DEX payloads, analysts had to set up a virtual machine or use a real Android phone as the execution environment and manually extract the dropped payloads. However, with the use of Triage, this process becomes much smoother and more efficient.
Triage also comes in handy when dealing with a vast amount of malware that needs to be analyzed. It provides quick access to configurations like C2 and encryption keys, along with dynamically dropped payloads and network packets. It greatly accelerates the thorough analysis process and minimizes the effort and time put in by malware analysts.
Targeted apps (found in the sample
231101-1wx7cadf5y we analyzed for this blog)
All Octo sha256 from public Triage:
All Octo C2 extracted from our config extraction: