At ANY.RUN, the value of our product lies in its detection and analysis capabilities. Our service needs to be able to identify a threat as soon as it exhibits malicious activity. This is why we have a large team dedicated solely to discovering, analyzing, and reverse engineering new families of malware to extract the information needed to keep our system up-to-date.
In this article, we want to offer you a behind-the-scenes look at our malware analysis department, showing their complete course of action when handling a fresh sample of malicious software and know-hows they use during every stage.
Stage 1: Finding a new sample
Our team is constantly on the lookout for fresh malware samples. In this regard, our public database of submissions, which receives an inflow of thousands of daily uploads, serves as the core source for finding yet-unseen material.
Additionally, we hunt using OSINT sources and other popular platforms, including MalwareBazaar, from which we collect malicious files and links. Once we locate an object of interest, we make sure to gather as many samples of it as possible in order to examine every current variation of the malware and use the information gathered to update our service’s detection capabilities.
Tools used: ANY.RUN, MalwareBazaar, VirusShare.com, Virus.exchange.
Stage 2: Classifying the malware
In this stage, we focus on identifying the malware’s type, purpose, and origin. The interactivity offered by ANY.RUN lets us take a close look at any malware’s behavior and gain a clear insight into the intention behind the malicious program and understand what steps we need to take next.
For instance, ANY.RUN highlights the entire execution path and network traffic of any sample. As a result, we can observe the actions undertaken by the malware and easily spot its primary type, whether it is ransomware that is encrypting files on the system or a stealer that is collecting user data and sending it to its command-and-control server.
Tools used: ANY.RUN.
ANY.RUN community experts: Germán Fernández, twitter.com/1ZRR4H
The first thing I do is OSINT/CSINT on the relevant elements of the sample, such as certain strings, communications, infection chain, IPs, domains, or certificates. Then, depending on the type of threat, I analyze it in sandboxes that allow me to simulate or fake an Internet connection to avoid alerting the attackers. If I do not get a positive response, I move to the analysis in my virtual machines until I piece the puzzle together. That is the path I usually follow to find out what it is.
Stage 3: Identifying the sample’s format, language, and packer
It is no surprise that attackers often attempt to disguise the malicious file’s format by replacing its extension with a different one. Therefore, in order to ascertain the sample’s format, we employ the “file” utility or utilize Detect It Easy (DIE).
DIE is a nifty tool that additionally helps us determine the programming language, in which the binary is written, as well as the packer used for encrypting the sample.
Tools used: “File,” Detect It Easy.
Stage 4: Unpacking the sample
With the basic information in our pocket, we move on to unpacking. These days, malware developers implement a variety of ways to make it harder for cybersecurity professionals to conduct analysis. Packing is one of them.
To remove protective layers, we use a combination of different tools, including a debugger and Process Hacker 2, ProcDump, or Volatility launched in a virtualized environment, which allows us to make a proper memory dump suitable for further investigation.
It is worth noting that the entire process which will be outlined below can be carried out much faster using ANY.RUN. Our service provides a detailed execution path and documents every event happening on the system, which is related to malware’s activity, including in terms of the network traffic. The sandbox also makes it possible to download memory dumps of detected malware for closer inspection.
Now, to accomplish unpacking, we deploy a controlled virtualized environment using ANY.RUN and software like VirtualBox for running the malware without risking damage to our physical system or network.
Once the virtualized environment is set up, we launch Process Hacker, a powerful tool for monitoring and analyzing system processes. This tool allows us to closely examine the behavior of the malware as it executes, identifying any unusual or malicious activity.
Simultaneously, we can introduce a debugger, especially in case of issues with Process Hacker. Our team primarily uses x64dbg. The process of debugging involves setting breakpoints at critical spots in the code to track the program’s logic and identify the moments when it exposes its crucial elements (e.g., IP addresses). Additionally, we utilize Sysinternals utilities, such as Process Monitor, and a number of other solutions, intended for specific tasks.
Using Process Hacker, we can create a memory dump, a snapshot of the contents of a process’ memory at a specific point in time, when the code of the malware gets unpacked and exposed.
To use Process Hacker to create a memory dump:
1. Identify the process associated with the malware.
2. Capture the memory dump
3. Download it to access the unpacked binary
The unpacked binary is the file that contains the actual code of the malware, which is also often heavily encrypted and obfuscated.
As for traffic analysis, we occasionally use Wireshark, which is the most powerful tool in this regard. Yet, for the majority of tasks, ANY.RUN remains our go-to option since it allows us to study network activity in a much more convenient way.
ANY.RUN also lets you download PCAP files and SSL keys for further analysis in Wireshark. This is especially useful when your current sample has a dead C2 connection, as you can always find previous reports in the public database that contain a PCAP file from when the C2 was still active.
Tools used: ANY.RUN, x64dbg, Hacker 2, ProcDump, Volatility, Wireshark, Process Monitor and other Sysinternals utilities, and more.
Stage 5: Extracting strings
After unpacking the file, we can gain an initial look at its code by extracting the strings it contains. In rare instances when we come across relatively unsophisticated samples, already at this point we can access their data, such as:
– filenames
– domain names
– IP addresses
Yet, most of the time, string extraction yields only API calls, that reveal the functionality and compiler version of the malware. The operation is performed using the standard “Strings” command-line utility or other similar tools.
Tools used: “Strings.”
ANY.RUN community experts: James, twitter.com/James_inthe_box
[During the] first step, [I] submit the sample to almost all free sandboxes. While those are processing, using the FLARE Obfuscated String Solver, I will string the file for any quick wins to identify what the malware is, what it does, or what it is named (rare, but sometimes a sample will come unpacked). If the automated sandboxes are unable to determine what the malware is/does, then it’s time for manually running it in ANY.RUN, usually Windows 7 64-bit to start.
Stage 6: Disassembly
Once a memory dump is obtained from the system, it can be analyzed using a disassembler, such as Ghidra, Radare2, and HxD (a hex editor, which we use in other stages as well). These tools are used to disassemble and analyze the code and data stored in the memory dump. With Ghidra’s advanced features such as cross-references, function call graphs, and code coverage analysis, we can more easily reverse engineer the malware’s functionality.
Tools used: Ghidra, Radare2, HxD.
Stage 7: Extracting configuration
Once we finish the analysis, we write a config extractor, a script designed to fetch malware’s configuration files that define various parameters, such as command and control (C2) server addresses, encryption keys, and other settings that the program needs to operate.
Additionally, we create YARA and Suricata rules and use this information to update ANY.RUN, letting users access all the details they need in seconds.
Tools used: Python 3, C#, and libraries.
Conclusion
Malware analysis is indispensable in ensuring an organization’s cybersecurity. However, the process can be time-consuming and complicated. ANY.RUN provides a solution to largely automate it. With a dedicated team constantly analyzing the latest threats and expanding the service’s capabilities, ANY.RUN offers up-to-date information, including IOCs and configurations, to help organizations better protect themselves.
Our team is committed to continuous improvement and values the opportunity to learn from others. This is why we invite you to join our Discord server, a community of passionate cybersecurity professionals, and share your malware analysis methods and best practices. Let’s strengthen our skills and grow together.
Stas Gaivoronskii
Stas is a malware analyst at ANY.RUN. He has more than 11 years of experience in the digital forensics field and 4 years in malware analysis.
0 comments