I believe that automating the analysis process is a common challenge among malware analysts, as it can significantly enhance the efficiency of their daily incident investigations. Cloud-based technologies (CI/CD, serverless, Infrastructure as code (IaC), and so on) are great solutions that can automate Malware Analysis Operations (MAOps) efficiently. In this article, I’ll introduce how JPCERT/CC automates malware analysis on the cloud, based on the following case studies.
- C2 server malware monitoring
- Cloud-based malware hunting
- YARA CI/CD system
- Cloud-based surface analysis system
- Cloud-based memory forensics
C2 server malware monitoring
Monitoring C2 servers is important for understanding attacker activity, and many malware analysts do it on a regular basis. However, if you access C2 servers too many times, you may be blocked by attackers and may even become a target of the attack. However, these problems can be solved by using cloud services.
JPCERT/CC monitors the C2 server used for lucky visitor scams using cloud services. Attackers send commands from their C2 servers to the defaced sites to redirect visitors to the scam site. The redirect URLs sent from C2 servers change periodically, and thus you can find new redirect URLs if you keep monitoring C2 servers.
In response to this kind of attack, JPCERT/CC automated the process of discovering C2 servers as well as collecting and denylisting the redirect URLs to block redirects to the lucky visitor scam site. This process flow is shown in Figure 1.
The system runs on AWS as shown in Figure 2. The serverless service Lambda scans C2 servers and sends the results to Google Safe Browsing via a GitHub action. By monitoring C2 servers on the cloud, you can easily avoid access restrictions made by the attackers by setting a different region.
JPCERT/CC’s C2 server monitoring results (a list of redirect URLs) have been made available at GitHub.
Cloud-based malware hunting
Malware analysts routinely hunt for malware in order to gather Indicators of Compromise (IoC) and other information. They continually download malware from VirusTotal and other resources to analyse. However, it is impossible to manually analyse every single malware type because new ones are created by bad actors on a daily basis. To deal with this, it’s possible to build an automated analysis system easily using cloud services.
JPCERT/CC operates a system that automatically collects Cobalt Strike Beacons from the Internet and stores the analysis results. Figure 3 shows the operational flow of the system. There are a number of Cobalt Strike C2 servers on the Internet, and data from many researchers is available on open platforms such as VirusTotal. Based on these sources of information, JPCERT/CC’s system investigates C2 servers and automatically collects and analyses samples.
This system was developed using AWS serverless services and GitHub. The key points — connection to C2 servers and malware analysis — are conducted on Lambda. In addition to automatically collecting C2 server information, we are also preparing an API to manually investigate them (API Gateway). Unfortunately, open source data alone does not cover all C2 servers so when an unknown C2 server is discovered, it needs to be analysed manually. However, if an API is prepared in this way, it is possible to investigate C2 servers without downloading samples, by simply providing the URL.
JPCERT/CC’s analysis results of Cobalt Strike Beacon collection system have been available at GitHub.
YARA CI/CD system
Although various tools for automated YARA rule creation have been released, there is currently no tool that can be considered standardized. As manually creating YARA rules for malware analysis is a time-consuming task, automating YARA rule creation is an important challenge. Although there is no automatic YARA rule creation method applicable to all types of malware, automation is possible by using pattern samples.
JPCERT/CC operates a system that automatically generates YARA for malware with specific patterns using a CI/CD system that generates YARA rules for HUI Loader, which is a malware group that has been used by threat actors such as APT10, Blue Termite, A41APT, and so on. HUI Loader loads the encoded malware that serves as the main body, decodes it, and executes it in memory. See our Analysis of HUI Loader for more information.
A common problem with loader malware is that although the loader is often detected when threat hunting, the encoded malware that it loads often cannot be found. However, because the encoding algorithm of the loader is known, it is possible to create YARA rules to detect the encoded malware in such cases. Figure 5 shows the operation flow of this system.
This system also uses AWS serverless services and GitHub. It automatically collects samples from VirusTotal, analyses them, generates YARA rules, and applies the rules to VirusTotal to collect new samples. So far, we have introduced three kinds of automation systems as examples, but you can actually achieve pretty much anything on AWS as long as you can use Lambda and S3.
JPCERT/CC’s analysis results of HUI Loader have been made available at GitHub.
Cloud-based surface analysis system
Malware analysts gather information on the latest malware from reports and blog posts published by security vendors. However, vendors often give unique names to the same type of malware or publish only hash values. Therefore, it can be difficult to compare a type of malware to the one that your organization recognizes based on the content of the report alone.
However, if you can instantly identify a type of malware from the hash values in the report (based on scan results with your YARA rules for example), you can find the connection between the report and the information your organization is collecting, which can increase the speed of your research.
Cloud services can be used for this purpose as well. Specifically, this problem can be solved by building a system that operates with the flow shown in Figure 7. A web browser plug-in is used to send the hash value information to the analysis system, which downloads the malware from VirusTotal, analyses it using various analysis tools such as YARA scan, and shows the results (Figure 8).
This system can be built on AWS and works as shown in Figure 9. Hash values sent from a web browser plug-in are received by API Gateway, which triggers Docker with AWS Batch to analyse the malware. The analysis results are saved as HTML in S3 and emailed by SNS. Many researchers post malware hash values on Twitter, so you can also automate a function that collects and analyses this information.
Furthermore, by converting such an analysis system to IaC, new analysis tools can be easily incorporated. For example, you can create scripts to extract the configuration information of a specific type of malware and incorporate it into your IaC, where it can be applied to the cloud more easily. A Terraform version of the analysis system described above is available at GitHub.
Cloud-based memory forensics
During incident investigation, there are cases where a large number of devices need to be investigated at the same time. Performing memory forensics on multiple devices simultaneously can be a challenging task, as a single device may struggle to handle the load, and the duration of the process can significantly vary depending on the specifications of the devices involved. These problems can be solved by using cloud services. Figure 10 shows a memory forensic system built on AWS.
When a memory image is saved in S3, it triggers Batch to launch Docker, and the memory image is analysed by Volatility Framework, a memory forensics tool. The analysis results are saved as HTML in S3 while being emailed by SNS. As shown in Figure 11, analysis becomes more efficient by referring to past results instead of repeating the same process. In this system, since Docker is launched by Batch for each memory image analysis, multiple devices can be analysed at the same time.
The Terraform code to build the above system has been made available at GitHub.
In closing
This article has presented just a few examples of using cloud services for MAOps. There is still a lot of potential for further use. I hope using cloud services can make your daily malware analysis more efficient!
Shusei Tomonaga has been the Incident Response Group Manager at JPCERT/CC since 2012, engaged in malware analysis and forensics investigation and is especially interested in analysing incidents of targeted attacks.
Adapted from the original post at JPCERT/CC Eyes.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.