Determining who is behind a malware campaign can be a challenging endeavour. Threat actors generally don’t leave easily identifiable signatures in software designed to disrupt or otherwise harm an adversary. However, by comparing key pieces of information with known sources, it is possible to determine when a campaign was likely perpetrated by a certain group. This is even more true when the group has existed for many years and has many pieces of evidence to compare. Recently, we uncovered the Operation Earth Kitsune campaign and published a detailed analysis of its tactics, techniques, and procedures (TTPs). While analysing the technical details of this malware, which includes two new espionage backdoors, we noticed striking similarities to other malware attributed to the threat actor known as APT37, also known as Reaper or Group 123. We hope our thorough analysis of Operation Earth Kitsune will help others with data points for attribution in the future.
By some accounts, this group has been active since 2012, so there are many examples attributed to them to compare. It is important to note that previous analysis of suspected APT37 activities from different security vendors date from 2016, and the captured samples for the Operation Earth Kitsune have been developed recently. Because of this, finding code similarity is unlikely. However, we were able to match some code reuse in one of the espionage backdoor’s functionalities. In that sense, we are emphasising TTPs correlation in this case. In other words, even when the new samples are developed, the attacker may have reused many of the operational techniques.
Another important consideration for attribution is that we have some historical background for Operation Earth Kitsune. Previously, we uncovered two different campaigns in 2019 under the name of SLUB malware. Operation Earth Kitsune is a continuation of those campaigns. Consequently, some of the attribution indicators will span and include the previous SLUB malware campaigns.
The following sections describe the different correlations and are divided into two main categories:
- Correlation related to the malware author developing environment
- Correlation associated with TTPs
Note that some leads are stronger than others; however, when combined, they suggest that the same threat actor behind malware previously attributed to APT37 is likely responsible for Operation Earth Kitsune.
Malware author’s developer environment
When determining attribution, the most interesting leads are the ones that can deduce information about the malware author’s working environment. Sometimes, these leads can determine the preferred languages used in the developers’ environment. There are also times when developers intentionally remove these associations and plant misleading information to avoid attribution. That action by itself potentially introduces other leads that developers may forget to clean.
Operating system language version
During the analysis of the samples captured from the previous campaign related to SLUB in 2019, one of the samples, the SLUB loader exploiting CVE-2019-0803, contained a version resource section that included intentionally misleading planted data. Figure 1 shows this:
This kind of misleading version data is quite common and does not have information relevant to attribution. However, there is a secondary effect when the version resource is added to a binary. For this, we are assuming this binary was compiled with a Visual Studio toolchain, which is indicated for various compiler identification tools. When the version resource is compiled into the binary, a language ID is generated and created not in the resource payload but in the internal structure of the resource information that is not visible with Windows Explorer. What is interesting is that this language ID is not determined by the Visual Studio current language. Instead, it is determined by the operating system language at the time of the version resource inclusion. Viewing this language ID requires the use of other tools. Figure 2 shows the language ID for the SLUB dropper.
We found this type of OS language leak in prior samples attributed to APT37. One of the previous malware families attributed to APT37 is known as Freenki. Some Freenki samples had leaked the OS language ID through this same mechanism. The image (Figure 3) taken from an analysis of Freenki shows that the same logic applies when the resource is compiled into the binary.
We assume there are multiple developers within APT37, and not all of them follow the same practices. As such, not all samples may have the embedded resource that leaks the same OS language. However, this commonality is just the first of many that lead us to believe the team attributed to the Freenki malware is the same team behind Operation Earth Kitsune.2
Leaked assert path and external blog references
Sometimes, the malware authors know that releasing symbol information is dangerous from an attribution point of view since it can reveal information about the working environment. That information often gets stripped from binaries. However, that is not the only scenario where malware developers leak path information about their environment. In some instances, malware projects require external libraries, and some libraries used the “assert()” mechanism to help the developers debug unexpected conditions. In these cases, the compiler includes a path to the source code file along with those “assert()” calls. These paths leak information about the third-party libraries’ installed paths. In our case, the samples from the Operation Earth Kitsune implemented the Mattermost command and control (C2) communication and leaked a local path. Figure 4 shows the leaked path.
Public references to this path (the path to the c++ boost library) consist of Korean language blogs explaining how to set up a developer environment configuration using the same path. We can also determine that this configuration was created manually because the default path installation does not support static compilation. Here is a translation of the relevant section:
Well, in the end, I modified the project configuration file as below, but it doesn't seem like best practice. There seems to be a neat way to do it, but I seek advice from experienced people.
It is also important to note that the same paths leaked through all the SLUB samples. This includes samples from the older SLUB campaign in 2019 and the new version that supports Mattermost.
These two indicators reveal that the malware author used an “assert()” path and referenced an external blog in the same manner as previously analysed malware.
In our previous detailed analysis of Operation Earth Kitsune, one of the delivery architecture for the espionage backdoors is designed as shown in Figure 6.
While this mechanism may sound quite common in other campaigns, what is interesting is the details they have in common with previous campaigns attributed to APT37. In 2017, Palo Alto’s Unit 42 detailed their findings around the Freenki malware. Even though this analysis was three years before Operation Earth Kitsune, the attackers appear to have reused the same TTPs for delivering the malware.
Figure 7 shows delivery PowerShell script sections for both campaigns.
The following TTPs are common in both campaigns related to the scripts in Figure 7:
- Both have compromised websites where the malware samples are hosted and delivered to victim machines.
- Both use PowerShell scripts to download and run the samples.
- Both PowerShell scripts download multiple malware to the victim machine. It appears the attacker is willing to implement multiple mechanisms for infecting the victim machine once it is compromised.
- Both use different samples for the multiple malware downloaded.
- Both use JPG as a delivering extension.
- Multiple samples are delivered at the same time. In both cases, at least one sample received command line arguments.
What got our attention is that the samples were renamed to be similar to the naming convention of Windows update files (i.e., “Windows-KB275122-x86.exe”). While analysing the samples that have been previously attributed to APT37, we noticed that the persistence mechanism in Operation Earth Kitsune uses the same naming convention to auto-start itself through the Windows run registry key. We also found that older samples from the previous SLUB campaigns in 2019 used a similar naming convention. Figure 9 shows that SLUB used “Windows-RT-KB-2937636.dll,” while Freenki used “Windows-KB275122-x86.exe.”
We can see how the Freenki malware, previous SLUB campaigns, and Operation Earth Kitsune share many common TTPs in their delivery and persistence mechanisms. However, these are not the only commonalities. Again, on its own, this might not be coincidental. However, our analysis shows further similarities that imply correlation.
GNUBoard compromised web sites
In the blog describing Operation Earth Kitsune, we noted sites using the GNUBoard Content Management System (CMS) had been compromised and were used to host malware. The malware campaigns previously attributed to APT37 also extensively used the exploitation of web sites hosted with GNUBoard CMS. While analysing multiple samples, we found indicators of this strategy across the various campaigns. Figure 10 shows an example attributed to APT37 and Operation Earth Kitsune as a comparison. The SLUB campaign also exploited and used GNUBoard websites as part of the infrastructure.
As mentioned in the previous report on Operation Earth Kitsune, one of the espionage backdoors, named agfSpy, received a “JSON” configuration with a list of native Windows commands to execute. The output of those commands is exfiltrated back to the agfSpy command and control (C2) server. While analysing one malware previously attributed to APT37, it executed practically the same command sequences including the paths and extensions. Even when the threat actor was not using the “JSON” format, the commands embedded in the various samples show a surprising amount of similarities. Figure 11 shows a comparison of the exfiltration commands between malware previously attributed to APT37 and Operation Earth Kitsune. Note the following similarities:
- The usage of paths C:\Users and D:\ are similar
- The searching patterns are very similar
- The extension list is very similar.
Note that we are comparting a sample from 2016 with agfSpy, which is from 2020. It makes sense that new campaigns coming from the same authors/groups will add new extensions like “.xlsx” to support updated versions of Office documents. It is also clear that the actual interest is on the “.hwp” extension for Korean Office document listing support during exfiltration.
When doing attribution, finding code sharing between different samples is one of the most desired discoveries. However, in our case, this was difficult as we are comparing samples from 2016-2017 to those developed in 2020. At the same time, practically all code for the SLUB malware was created from scratch. Also, dneSpy and agfSpy are based on custom and newly developed code. That makes it difficult to match code similarities, and that is why many of the indicators of code sharing are sparse across different samples.
However, one feature that is present in the previous malware attributed to APT37 and Operation Earth Kitsune is the screenshot capture. We tried to find how this feature evolved across previous samples and the older SLUB samples. During the analysis, we found a clear indication of code sharing for the screenshot functionality. Figure 12 shows a comparison between the two samples. While this code may have some related “internet code sharing post” origin, both samples share it. They also have some changes that make sense, such as removing the error “failed to take…,” since this is not required for the malware functionality. It is likely a late refactor to the code.
Analysing the compile time of binaries between different samples can also provide a level of correlation between samples. While malware authors can fake this, useful information can still be gleaned with enough samples. In our case, we collected many samples across 2020, and we found that the compile dates and times follow a logical timeline according to the malicious activity. Based on our analysis, we believe the malware author did not fake the compile times of the binaries. Other public references also used the compiled binary time of samples attributed to APT37. When compared to the compile times seen in Operation Earth Kitsune, there are several similarities.
The compile times that are listed on binaries provide an estimate of the threat actor's working hours and help approximate possible time zones where the malware was developed. It is fair to assume that the developers work on daily working times. When you have many samples to analyse, you can refine that expectation over time. Figure 14 (below) shows a raw comparison across many samples using two time zones. We can see how the UTC+9 time zone matches those previously attributed to APT37 and those from Operation Earth Kitsune. These both equate to the daily working times for that time zone.
During the capture of samples for Operation Earth Kitsune, we managed to dump information about the Mattermost server using its API and the token used by the malware itself. Mattermost was being used as a C2 channel for the malware. Part of the dumped information contained the action of the user with administration roles on the system. That user was doing manual activities the majority of the time. At the same time, we were able to locate the Mattermost server hosted in Greece, and that gave us the current time zone of the Mattermost server. Having that reference, we plotted the actions of all users whose information we could obtain. It is important to remember that, except for the administrator user, all other accounts were used as part of the malware deployment (SLUB malware). Figure 15 shows a plot with “Y” representing the number of actions. For example, an action for the SYSTEM_ADMIN could be to create a user, add a user to a channel, etc. The “X” axis represents the hour of the day (in 24 hours). No months are plotted, so this figure is like compressing all the activity across the full 2020-year in one day just to show the active hours in a day. All the plots are located in UTC+9.
Figure 15 shows that User_3 and User_4 have like random counts. This is because those accounts are actually the ones the malware used during the infection logging activities to the Mattermost server. However, the SYSTEM_ADMIN account has a different pattern because the actions are mostly due to manual administration activities. Unsurprisingly, the SYSTEM_ADMIN hours perfectly line up with the daily working hours at UTC+9.
While no attribution is perfect, there are striking similarities between the malware attributed to APT37 and Operation Earth Kitsune. Little can be gleaned from each individual piece, but when viewed as a whole, the group behind Operation Earth Kitsune is likely the same one behind the Freenki malware and other malware campaigns attributed to APT37. This is somewhat surprising, considering Operation Earth Kitsune’s espionage tools were entirely fresh-developed.
We can summarise the correlated indicators in a general form as:
- Use of Korean language in the system environment of the developers
- Reuse of multiple TTPs during operation deployments:
- GNUBoard compromised web sites
- Some code reuse, even when the samples are completely different otherwise
- Working hours for both matches
- Exfiltration techniques and information interest are very similar if not fully matched
- Multiple malware samples deployed at the same time
- A similar organisation in the deployment architecture
- Reliance on public services and watering hole attacks to compromised victims
While it is always possible for another group to imitate the TTPs of a different group to confuse attribution, there does not seem to be any indication of that here. Instead, what we see in SLUB and Operation Earth Kitsune is the evolution of an advanced threat actor over time: one that builds on what worked in the past to become more efficient in the present.