Introduction

We recently discovered an campaign we are calling . The campaign is targeting what appears to be betting companies in , more specifically companies located in , the , and . With moderate confidence, we can attribute the campaign to a , but unfortunately cannot attribute the attack to a specific group and are not sure what the attackers are after.APTOperation Dragon CastlingSouth East AsiaTaiwanPhilippinesHong KongChinese speaking APT group

We found notable code similarity between one of the modules used by this APT group (the ) and the samples described by the in their report and in their report. Based on this, we suspect that the FFRat codebase is being shared between several Chinese adversary groups. Unfortunately, this is not sufficient for attribution as FFRat itself was never reliably attributed.MulCom backdoorFFRatBlackBerry Cylance Threat Research Team2017Palo Alto Networks2015

In this blogpost we will describe the malware used in these attacks and the backdoor planted by the APT group, as well as other malicious files used to gain persistence and access to the infected machines. We will also discuss the two infection vectors we saw being used to deliver the malware: an infected installer and exploitation of a vulnerable legitimate application, .WPSOffice

We identified a new vulnerability (CVE-2022-24934) in the WPS Office updater wpsupdate.exe, which we suspect that the attackers abused.

We would like to thank Taiwan’s for providing us with IoCs related to the infection vector.TeamT5

Infrastructure and toolset

In the diagram above, we describe the relations between the malicious files. Some of the relations might not be accurate, e.g. we are not entirely sure if the MulCom backdoor is loaded by the . However, we strongly believe that it is one of the malicious files used in this campaign. CorePlugin

Infection Vector

We’ve seen multiple infection vectors used in this campaign. Among others, an attacker sent an email with an infected installer to the support team of one of the targeted companies asking to check for a bug in their software. In this post, we are going to describe another vector we’ve seen: a fake update package. We suspect an attacker exploited a bug in the WPS updater, which is a part of the WPS Office installation package. We have contacted WPS Office team about the vulnerability (), which we discovered, and it has since been fixed.WPS Office wpsupdate.exeCVE-2022-24934

During our investigation we saw suspicious behavior in the WPS updater process. When analyzing the binary we discovered a potential security issue that allows an attacker to use the updater to communicate with a server controlled by the attacker to perform actions on the victim’s system, including downloading and running arbitrary executables. To exploit the vulnerability, a registry key under needs to be modified, and by doing this an attacker gains persistence on the system and control over the update process. In the case we analyzed, the malicious binary was downloaded from the domain , which is a domain belonging to , but the serving IP () has no relationship to the company, so we assume that it is a fake update server used by the attackers.
The downloaded binary () drops two files for sideloading: a signed and a malicious DLLHKEY_CURRENT_USER update.wps[.]cnKingsoft103.140.187.16setup_CN_2052_11.1.0.8830_PersonalDownload_Triale.exe - B9BEA7D1822D9996E0F04CB5BF5103C48828C5121B82E3EB9860E7C4577E2954QMSpeedupRocketTrayInjectHelper64.exe - Tencent Technology (a3f3bc958107258b3aa6e9e959377dfa607534cc6a426ee8ae193b463483c341) QMSpeedupRocketTrayStub64.dll.

Dropper 1 (QMSpeedupRocketTrayStub64.dll)

76adf4fd93b70c4dece4b536b4fae76793d9aa7d8d6ee1750c1ad1f0ffa75491

The first stage is a backdoor communicating with a C&C (). Before contacting the C&C server, the backdoor performs several preparational operations. It hooks three functions: , , . To get the C&C domain, it maps itself to the memory and reads data starting at the offset from the end. The domain name is not encrypted in any way and is stored as a wide string in clear text in the binary. mirrors.centos.8788912[.]comGetProcAddressFreeLibraryLdrUnloadDll1064

Then it initializes an object for a class with the named item .  The dropper uses the API Call to re-use a token from so it effectively runs under the same user. Additionally, it uses to redirect the current to of an impersonated user. For communication with C&C it constructs a UserAgent string with some system information e.g. registry values.JScriptScriptHelperImpersonateLoggedOnUser explorer.exeRegOverridePredefKey HKEY_CURRENT_USER HKEY_CURRENT_USER  Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1;.NET CLR 2.0). The information that is exfiltrated is: Internet Explorer version, Windows version, the value of the “User Agent\Post Platform”

After that, the sample constructs code to execute. The header of the code contains definitions of two variables: with the C&C domain name and a hardcoded . Then it sends the HTTP request to the response should be encrypted code that is decrypted, appended to the constructed header and executed using the class created previously.JScript serverkeyGET /api/connect,JScript JScript

At the time of analysis, the C&C was not responding, but from the telemetry data we can conclude that it was downloading the next stage from to and executing it.hxxp://mirrors.centos.8788912.com/upload/ea76ad28a3916f52a748a4f475700987.exe%ProgramData%\icbc_logtmp.exe

Dropper 2 (IcbcLog)

a428351dcb235b16dc5190c108e6734b09c3b7be93c0ef3d838cf91641b328b3

The second dropper is a runner that, when executed, tries to escalate privileges via the Escalation , then dropping a few binaries, which are stored with the following resource IDs:COM Session Moniker Privilege (MS17-012)

The encrypted payloads have the following structure:

The encryption key is a wide string starting from offset . The encrypted data starts at the offset . To decrypt the data, a SHA256 hash of the key is created using API, and is then used with a hard-coded IV to decrypt the data using API with the algorithm. After that, the decrypted data is decompressed with . To verify that the decryption went well, the of the data is computed and compared to the value at the offset of the original resource data. When all the payloads are dropped to the disk, is executed to run the next stage.0x80x528CryptHashData 0123456789abcdeCryptDecrypt AES256RtlDecompressBufferCRC320x4 bdservicehost.exe

Loader (CoreX)

97c392ca71d11de76b69d8bf6caf06fa3802d0157257764a0e3d6f0159436c42

The DLL is sideloaded during the previous stage and acts as a dropper. Similarly to , it hooks the and API functions. These hooks execute the main code of this library. The main code first checks whether it was loaded by and then it retrieves encrypted data from its resources. This data is dropped into the same folder as . The file is then loaded and decrypted using AES-256 with the following options for setup:Loader (CoreX) (Dropper 2)Dropper 1GetProcAddress FreeLibrary regsvr32.exesyscfg.dat

• Key is the computer name and IV is qwertyui12345678
• AES-256 setup parameters are embedded in the resource in the format . So you may e.g. see <key>#<IV>cbfc2vyuzckloknf#8o3yfn0uee429m8d

The main code continues to check if the process is running. is an ESET Kernel service. If the ESET Kernel service is running, it will try to remap . We assume that this is used to bypass hooking. ekrn.exeekrn.exentdll.dllntdll.dll

After a service check, it will decompress and execute shellcode, which in turn loads a DLL with the next stage. The DLL is stored, unencrypted, as part of the shellcode. The shellcode enumerates exports of and builds an array with hashes of names of all functions (windows native API system calls) then sorts them by their RVA. By doing this, the shellcode exploits the fact that the order of RVAs of functions equals the order of the corresponding syscalls, so an index of the function in this array is a syscall number, which can be called using the syscall instruction. Security solutions can therefore be bypassed based on the hooking of the API in userspace. Finally, the embedded core module DLL is loaded and executed.ntdll.dll Zw*Zw*Zw*

Proto8 (Core module)

f3ed09ee3fe869e76f34eee1ef974d1b24297a13a58ebff20ea4541b9a2d86c7

The core module is a single DLL that is responsible for setting up the malware’s working directory, loading configuration files, updating its code, loading plugins, beaconing to C&C servers and waiting for commands.

It has a cascading structure with four steps:

Step 1

The first part is dedicated to initial checks and a few evasion techniques. At first, the core module verifies that the DLL is being run by (an executable used for persistence, see below) or that it is not being run by If this check fails, the execution terminates. The DLL proceeds by hooking the and functions in order to execute the main function, similarly to the previous infection stages.spdlogd.exerundll32.exe.GetProcAddress FreeLibrary

The malware then creates a new window (named ) with a custom callback function. A message with the ID is sent to the window via which causes the aforementioned callback to execute the main function. The callback function can also process the message ID, even though no specific functionality is tied to it.Sample0x411 SendMessageW0x412

Step 2

In the second step, the module tries to self-update, load configuration files and set up its working directory (WD).

Self-update

The malware first looks for a file called – if it exists, its content is loaded into memory, executed in a new thread and a debug string is printed out. We did not come across this file, but based on its name and context, this is most likely a self update functionality.new_version.dat“run code ok”

Load configuration file and set up working directory. First, the core module configuration file inst.dat is searched for in the following three locations:inst.dat

• the directory where the core module DLL is located
• the directory where the EXE that loaded the core module DLL it is located
• C:\ProgramData\

It contains the path to the malware’s working directory in plaintext. If it is not found, a hard-coded directory name is used and the directory is created. The working directory is a location the malware uses to drop or read any files it uses in subsequent execution phases.

Load configuration file . smcache.dat

After the working directory is set up, the sample will load the configuration file from it. This file contains the domains, protocols and port numbers used to communicate with C&C servers (details in Step 4) plus a string. This string is likely used to identify the campaign or individual victims. It is used to create an empty file on the victim’s computer (see below) and it’s also sent as a part of the initial beacon when communicating with C&C servers. We refer to it as the because we have seen a few versions of smcache.dat where the content of the string was and it is also present in another configuration file with the name which has the INI file format and contains this string under the key COMMENT.smcache.dat“comment” “comment string” “the comment string here”comment.dat

Create a filelog

Right after the sample finds and reads smcache.dat, it creates a file based on the victim’s username and the comment string from smcache.dat. If the comment string is not present, it will use a default hard-coded value (for example ). Based on the extension it could be a log of some sort, but we haven’t seen any part of the malware writing into it so it could just serve as a lockfile. After the file is successfully created, the malware creates a mutex and goes on to the next step.M86_99.lck

Step 3

Next, the malware collects information about the infected environment (such as username, DNS and NetBios computer names as well as OS version and architecture) and sets up its internal structures, most notably a list of . Call objects are structures each associated with a particular function and saved into a structure in a map with hard-coded 4-byte keys. These keys are later used to call the functions based on commands from C&C servers.  “call objects”“dispatcher”

The key values (IDs) seem to be structured, where the first three bytes are always the same within a given sample, while the last byte is always the same for a given usage across all the core module samples that we’ve seen. For example, the function that calls the function is identified by the number in some versions of the core module that we’ve seen andin others. This suggests that the first three bytes of the ID number are tied to the core module version, or more likely the infrastructure version, while the last byte is the actual ID of a function. RevertToSelf 0x20210326 0x19181726

Webdav 

While initializing the call objects the core module also tries to connect to the URL with the username and password by calling . This address was not responsive at the time of analysis but is a Chinese file sharing service. Our hypothesis is that this is either a way to get plugin code or an updated version of the core module itself.hxxps://dav.jianguoyun.com/dav/12121jhksdf 121121212 WNetAddConnection3Wjianguoyun[.]com

Plugins

The core module contains a function that receives a buffer with plugin DLL data, saves it into a file with the name in the malware working directory, loads it into memory and then calls its exported function . The plugin file on disk is set to be deleted on reboot by calling with the parameter . For more information about the plugins, see the dedicated Plugins section.kbg<tick_count>.datInitCorePlugMoveFileExW MOVEFILE_DELAY_UNTIL_REBOOT

Step 4

In the final step, the malware will iterate over C&C servers contained in the smcache.dat configuration file and will try to reach each one. The structure of the config file is as follows:smcache.dat

The protocol string can have one of nine possible values:

• TCP
• HTTPS
• UDP
• DNS
• ICMP
• HTTPSIPV6
• WEB
• SSH
• HTTP

Depending on the protocol tied to the particular C&C domain, the malware sets up the connection, sends a beacon to the C&C and waits for commands.

In this blogpost, we will mainly focus on the HTTP protocol option as we’ve seen it being used by the attackers.

When using the HTTP protocol, the core module first opens two persistent request handles – one for and one for requests, both to . These handles are tested by sending an empty buffer in the request and checking the HTTP status code of the request. Following this, the malware sends the initial beacon to the C&C server by calling the API with the previously opened request handle and reads data from the request handle by calling .POST GET “/connect”POST GET InternetWriteFile POST GET InternetReadFile

The core module uses the following (mostly hard-coded) HTTP headers:

• Accept: */*
• x-cid: {<uuid>} – new uuid is generated for each request pairGET/POST
• Pragma: no-cache
• Cache-control: no-transform
• User-Agent: <user_agent> – generated from registry or hard-coded (see below)
• Host: <host_value> – C&C server domain or the value from hostcfg.dat (see below)
• Connection: Keep-Alive
• Content-Length: 4294967295 (max uint, only in the POST request)

User-Agent header

The User-Agent string is constructed from the registry the same way as in the module (including the logged-on user impersonation when accessing registry) or a hard-coded string is used if the registry access fails: .Dropper 1“Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)”

Host header

When setting up this header, the malware looks for either a resource with the or a file called if the resource is not found. If the resource or file is found, the content is used as the value in the HTTP header for all C&C communication instead of the C&C domain found in . It does not change the actual C&C domain to which the request is made – this suggests the possibility of the C&C server being behind a reverse proxy. ID 1816hostcfg.datHost smcache.dat

Initial beacon

The first data packet the malware sends to a C&C server contains a base64 encoded LZNT1-compressed buffer, including a newly generated uuid (different from the uuid used in the x-cid header), the victim’s username, OS version and architecture, computer DNS and BIOS names and the comment string found in or. The value from takes precedence if this file exists.smcache.dat comment.datcomment.dat 

In the core module sample we analyzed, there was actually a typo in the function that reads the value from– it looks for the key instead of . comment.dat “COMMNET”“COMMENT”

After this, the malware enters a loop waiting for commands from the C&C server in the form of the ID value of one of the call objects.
Each message sent to the C&C server contains a hard-coded four byte number value with the same structure as the values used as keys in the call-object map. The ID numbers associated with messages sent to C&C servers that we’ve seen are:

Interesting observations about the protocols, other than the HTTP protocol:

• HTTPS does not use persistent request handles
• HTTPS uses HTTP request with data Base64-encoded in the cookie header to send the initial beaconGET
• HTTPS, TCP and UDP use a custom “magic” header: Magic-Code: hhjjdfgh

General observations on the core module

The core samples we observed often output debug strings via and or by sending them to the C&C server. Examples of debug strings used by the core module are: its filepath at the beginning of execution, after self-update, in the hook of , and in the main C&C communicating function, etc.OutputDebugStringA OutputDebugStringW “run code ok”“In googo”GetProcAddress“recv bomb”“sent bomb”

String obfuscation

We came across samples of the core module with only cleartext strings but also samples with certain strings obfuscated by XORing them with a unique (per sample) hard-coded key.

Even within the samples that contain obfuscated strings, there are many cleartext strings present and there seems to be no logic in deciding which string will be obfuscated and which won’t. For example, most format strings are obfuscated, but important IoCs such as credentials or filenames are not.

To illustrate this: most strings in the function that retrieves a value from the comment.dat file are obfuscated and the call to is dynamically resolved by the API, but all the strings in the function that writes into the same config file are in cleartext and there is a direct call to . GetPrivateProfileStringW GetProcAddress WritePrivateProfileStringW

Overall, the core module code is quite robust and contains many failsafes and options for different scenarios (for example, the amount of possible protocols used for C&C communication), however, we probably only saw samples of this malware that are still in active development as there are many functions that are not yet implemented and only serve as placeholders.

Plugins

In the section below, we will describe the functionality of the plugins used by the to extend its functionality. Core Module (Proto8)

We are going to describe three plugins with various functionalities, such as:

• Achieving persistence
• Bypassing UAC
• Registering an RPC interface
• Creating a new account
• Backdoor capabilities

Core Plugin

0985D65FA981ABD57A4929D8ECD866FC72CE8C286BA9EB252CA180E280BD8755

This plugin is a DLL binary loaded by the fileless core module () as mentioned above. It extends the malware’s functionality by adding methods for managing additional plugins. These additional plugins  export the function which the core plugin executes.Proto8"GetPlugin"

This part uses the same command ID based calling convention as the core module (see above), adding three new methods:

All plugin binaries used by the core module are stored in the working directory under the name. After the is loaded, it first removes all plugins from the working directory – see the image below. kbg<tick_count>.datCore Plugin

Zload(Atomx.dll,xps1.dll)

2ABC43865E49F8835844D30372697FDA55992E5A6A13808CFEED1C37BA8F7876

The DLL we call is an example of a plugin loaded by the . It exports four functions: , , and . The main functionality of this plugin is setting up persistence, creating a backdoor user account, and concealing itself on the infected system. We will focus on the exported functions , and the default function, as they contain the most interesting functionality.Zload Core Plugin“GetPlugin”“Install”“core_zload””zload”zloadcore_zloadDllMain

Zload (process starter)

This function is fairly simple, its main objective is to execute another binary. It first retrieves the path to the directory where the plugin binary is located and creates a new subfolder calledin it. After this it renames and moves three files into it:Zload (<root_folder>) "mec"

• the plugin binary itself as,Zload <root_folder>\mec\logexts.dll
• <root_folder>\spdlogd.exe as and<root_folder>\mec\spdagent.exe
• <root_folder>\kb.ini as <root_folder>\mec\kb.ini

After the files are renamed and moved, it creates a new process by executing the binary (originally ).<root_folder>\mec\spdagent.exe<root_folder>\spdlogd.exe

core_zload (persistence setup)

This function is responsible for persistence which it achieves by registering itself into the list of security support providers (SSPs). Windows SSP DLLs are loaded into the process when the system boots. The code of this function is notably similar to the source code found on github.Local Security Authority (LSA)mimikat_ssp/AddSecurityPackage_RawRPC

DllMain (sideloading, setup)

The default DllMain function leverages several persistence and evasion techniques. It also allows the attacker to create a backdoor account on the infected system and lower the overall system security.

Persistence

The plugin first checks if its DLL was loaded either by the processes or. If the DLL was loaded by , it will adjust the token privileges of the current process.“lsass.exe” “spdagent.exe”“spdagent.exe”

If it was loaded by , it will retrieve the path from the configuration file and write it under the registry key . This ensures persistence, as it causes the DLL to be loaded each time the Winsock 2 library () is invoked.“lsass.exe”“kb<num>.dll”“kb.ini”HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\WinSock2\\ParametersAutodialDLL“kb<num>.dll”ws2_32.dll

Evasion

To avoid detection, the plugin first checks the list of running processes for (Kaspersky Antivirus) or and exits if either of them is found. If these processes are not found on the system, it goes on to conceal itself by changing its own process name to .“avp.exe”“NortonSecurity.exe”“explorer.exe”

The plugin also has the capability to bypass the UAC mechanisms and to elevate its process privileges through interfaces, such as .CMSTP COMCMSTPLUA {3E5FC7F9-9A51-4367-9063-A120244FBEC7}

Backdoor user account creation

Next, the plugin carries out registry manipulation (details can be found in the appendix), that lowers the system’s protection by:

• Allowing local accounts to have full admin rights when they are authenticating via network logon
• Enabling RDP connections to the machine without the user password
• Disabling admin approval on an administrator account, which means that all applications run with full administrative privileges
• Enabling anonymous SID to be part of the everyone group in Windows
• Allowing users to list users and groups in the domain“Null Session”
• Allowing users to access shared folders“Null Session”
• Setting the name of the pipe that will be accessible to “Null Session” users

After this step, the plugin changes the service startup type to . It creates a new user with the name and the password which is then added to the and groups. It also hides the new account on the logon screen.WebClient “Automatic”“DefaultAccount”“Admin@1999!”“Administrator”“Remote Desktop Users”

As the last step, the plugin checks the list of running processes for process names and and executes the file if neither of them is found.“360tray.exe”“360sd.exe”"spdlogd.exe"

MecGame(kb%num%.dll)

4C73A62A9F19EEBB4FEFF4FDB88E4682EF852E37FFF957C9E1CFF27C5E5D47AD

MecGame is another example of a plugin that can be loaded by the . Its main purpose is similar to the previously described plugin – it executes the binary and achieves persistence by registering an RPC interface with . This RPC interface represents a function that decodes and executes a base64 encoded shellcode.Core PluginZload“spdlogd.exe”UUID {1052E375-2CE2-458E-AA80-F3B7D6EA23AF}

The plugin has several methods for executing spdlogd.exe depending on the level of available privileges. It also creates a lockfile with the name or depending on the name of the process that loaded it, and deletes the files and.MecGame MSSYS.lck<UserName>-XPS.lckatomxd.dll logexts.dll

It can be installed as a service with the service name or can be loaded by any executable that connects to the internet via the library.“inteloem”Winsock2

MulCom

ABA89668C6E9681671A95B3D7A08AAE2A067DEED2D835BA6F6FD18556C88A5F2

This DLL is a backdoor module which exports four functions: , , and ; the main malicious function being .“OperateRoutineW”“StartRoutineW”“StopRoutineW””WorkRoutineW”“StartRoutineW”

For proper execution, the backdoor needs configuration data accessed through a shared object with the file mapping name either or . Unfortunately we didn’t come across the configuration data, so we are missing some information such as the C&C server domains this module uses.“Global\\4ED8FD41-2D1B-4CC3-B874-02F0C60FF9CB”"Local\\4ED8FD41-2D1B-4CC3-B874-02F0C60FF9CB”

There are 15 commands supported by this backdoor (although some of them are not implemented) referred to by the following numerical identifiers:

Communication protocol

The backdoor is capable of communicating via HTTP and TCP protocols. The data it exchanges with the C&C servers is encrypted and compressed by the RC4 and aPack algorithms respectively, using the RC4 key loaded from the configuration data object.MulCom

It is also capable of proxy server authentication using schemes such as Basic, NTLM, Negotiate or to authenticate via either the SOCKS4 and SOCKS5 protocols.

After successful authentication with a proxy server, the backdoor sends data xorred by the constant . This data is a set with the following structure:0xBC

Another interesting capability of this backdoor is the usage of layered C&C servers. If this option is enabled in the configuration object (it is not the default option), the first request goes to the first layer C&C server, which returns the IP address of the second layer. Any subsequent communication goes to the second layer directly.

As previously stated, we found several code similarities between the DLL and the (a.k.a. ).MulCom FFRat FormerFirstRAT

Conclusion

We have described a robust and modular toolset used most likely by a Chinese speaking APT group targeting gambling-related companies in South East Asia. As we mentioned in this blogpost, there are notable code similarities between samples and the backdoor. or has been publicly associated with the according to the Palo Alto Network report, which has in turn been associated with backdoors like and – tools commonly used by Chinese speaking attackers.FFRat MulCom FFRat "FormerFirstRAT'' DragonOK groupPoisonIvyPlugX

We also described two different infection vectors, one of which weaponized a vulnerable WPS Office updater. We rate the threat this infection vector represents as very high, as WPS Office claims to have 1.2 billion installations worldwide, and this vulnerability potentially allows a simple way to execute arbitrary code on any of these devices. We have contacted WPS Office about the vulnerability we discovered and it has since been fixed.

Our research points to some unanswered questions, such as reliable attribution and the attackers’ motivation.

Appendix

List of processes:

• 360sd.exe
• 360rp.exe
• 360Tray.exe
• 360Safe.exe
• 360rps.exe
• ZhuDongFangYu.exe
• kxetray.exe
• kxescore.exe
• KSafeTray.exe
• KSafe.exe
• audiodg.exe
• iexplore.exe
• MicrosoftEdge.exe
• MicrosoftEdgeCP.exe
• chrome.exe

Registry values changed by the Zload plugin:

Core module working directory (WD)

Default hard-coded WD names (created either in or in ): C:\ProgramData\%TEMP%

• spptools
• NewGame
• TspSoft
• InstallAtomx

File used to test permissions: – the WD path is written into it and then the file is deleted.game_<tick_count>.log

Hard-coded security descriptor used for WD access: . “D:(A;;GA;;;WD)(A;OICIIO;GA;;;WD)”

Lockfile name format: “<working_dir>\<victim_username>-<comment_string>.log”

Core module mutexes:

Global\sysmon-windows-%x (%x is a CRC32 of an MD5 hash of the victim’s username)

Global\IntelGameSpeed-%x (%x is a CRC32 of an MD5 hash of the victim’s username

Global\TencentSecuriryAgent-P01-%s (%s is the victim’s username)

Indicators of Compromise (IoC)

•  Repository: https://github.com/avast/ioc/tree/master/OperationDragonCastling
•  List of SHA-256: https://github.com/avast/ioc/blob/master/OperationDragonCastling/samples.sha256