CherryLoader: A New Go-based Loader Discovered in Recent Intrusions

Share :


Arctic Wolf Labs has been tracking two recent intrusions where threat actors leveraged a new Go-based malware downloader we are calling “CherryLoader” that allowed them to swap exploits without recompiling code. The loader’s icon and name masqueraded as the legitimate CherryTree note taking application to trick the victims. In the intrusions we investigated, CherryLoader was used to drop one of two privilege escalation tools, PrintSpoofer or JuicyPotatoNG, which would then run a batch file to establish persistence on the victim device.

Key Takeaways

  • Arctic Wolf has observed a new loader, dubbed “CherryLoader”, written in Go used in recent intrusions.
  • The loader contains modularized features that allow the threat actor to swap exploits without recompiling code.
  • CherryLoader drops two publicly available privilege escalation exploits.
  • CherryLoader’s attack chain leverages process ghosting and allows threat actors to elevate privileges and establish persistence on victim machines.

Technical Analysis

Based on incident response data and additional analysis, the threat actors initially leveraged the IP address 141.11.187[.]70 to serve the victim CherryLoader and associated files. Two files were downloaded from that IP, a password protected rar file (Packed.rar) and an executable (main.exe) used to unpack Packed.rar.

The Packed.rar file contained a Golang binary (cherrytree.exe) along with three additional files, NuxtSharp.Data, Spof.Data, and Juicy.Data. Cherrytree.exe was stripped and had its import address table destroyed to hinder analysis efforts.

Using static analysis, a unique reference for the project was found, revealing the author’s original project name “XorRunPeGoler”.

After CherryLoader and its associated files were extracted from the .rar file, the threat actors invoked CherryLoader using the following command:

Cherrytree.exe 405060EEw@! NuxtSharp.Data Spof.Data

Upon execution, the binary checks the arguments passed to it and compares the first argument (password) against a hardcoded MD5 password hash. If the hashes match, the binary proceeds to the next step, if not, CherryLoader quits.

The binary then allocates memory to read and decrypt the file passed via the second argument (NuxtSharp.Data). The file is then decrypted with a simple XOR algorithm.

To start the XOR loop, CherryLoader copies the XOR key “Kry” and allocates memory for the decrypted data. It then iterates over the NuxtSharp.Data file byte by byte and XORs the bytes with a letter that corresponds to an index in [“K”, “r”, “y”]. The index is limited with a modulus of 3 to avoid out of bounds access.

Notably, the decryption algorithm does not rely on the entered password, therefore, it can be patched, rendering the password argument useless. The password check is likely in place to deter analysis of the file. A python script to demonstrate the decryption process can be found here.

After the XOR loop completes and the file (NuxtSharp.Data) has been decrypted in memory, GetProcAddress is used to dynamically locate CreateFileW which saves the decrypted file as File.log in the %TEMP% directory.

After saving File.log to disk, the sample will dynamically locate the CreateProcessW function to run cmd.exe which, in turn, will run File.log as its child process:

cmd.exe /c File.log Spof.Data 123 12.log

After running the cmd.exe process, it dynamically locates and calls DeleteFileW and RemoveDirectoryW to delete any evidence in the %TEMP% directory.

File.log (a.k.a NuxtSharp.Data)

Filename File.log
SHA256 e0f53fb3651caf5eb3b30603064d527b9ac9243f8e682e4367616484ec708976

File.log is a PE file written in C and appears to have symbols referring to an original project named NuxtSharp. File.log represents the next stage in the attack chain which begins by decrypting Spof.Data.

Decrypting the Spoofer

CherryLoader runs File.log as a process with three additional arguments. The main function of the File.log executable will facilitate the passing of arguments to a function that will later decrypt and load the binary from memory.

File.log starts by creating a file named 12.log (the last argument specified on the command line). File.log then opens the encrypted Spof.Data file (first argument) and reads the data into a buffer for decryption.

Spof.Data is encrypted using AES ECB (Rijndael); the key “123” was passed as the second argument in the initial command line.

Notably, one of the other files found with CherryLoader, Juicy.Data, used the same encryption algorithm and key. Arctic Wolf has created a Python script that will aid in decrypting both Spof.Data and Juicy.Data, the script can be found in the appendix here.

Evasion Attempt (Process Ghosting)

Once File.log has completed the decryption of Spof.Data, it attempts to create a new process named 12.log using a fileless technique known as Process ghosting. This technique is modular in design and will allow the threat actor to leverage other exploit code in place of Spof.Data.  In this case, Juicy.Data which contains a different exploit, can be swapped in place without recompiling File.log.

The process ghosting technique starts by creating a file using the CreateFile API with the DELETE flag set as its dwDesiredAccess parameter.

Then, it uses NtSetInformationFile API to set the FileInformation parameter which points to a FILE_DISPOSITION_INFORMATION structure; this structure has single Boolean parameter, called DeleteFile which, when set, causes the operating system to delete the file when it is closed.

File.log then writes the decrypted binary into a newly created file using the WriteFile API and then it creates an image section using NtCreateSection:

Once the image section is created, it then uses CreateFileMappingA and MapViewOfFile to map the created file into memory.

After creating the file mapping, it closes the handles to the mapped files, resulting in the deletion of the previously created file.

File.log then creates a new process leveraging the previously mapped section.

Once the created process is complete, it then retrieves the environment variables using CreateEnvironmentBlock, and the RtlCreateProcessParameters functions to set the arguments and the environment of the newly created process.

Before creating a new thread of execution, File.log will allocate memory into the newly created process using VirutalAllocEx and calls the WriteProcessMemory and ReadProcessMemory functions to set the base address, process parameters, and environment data into the newly allocated memory.

Finally, it creates a new thread using a handle to the newly created process and the NtCreateThreadEx function to start the execution of the 12.log process.

After successful thread creation, it prints “Success – Threat ID” to the terminal with an ironic misspelling of the word “Threat” instead of Thread.

Privilege Escalation

The newly created process 12.log (Spof.Data) is linked to a publicly available privilege escalation tool named PrintSpoofer that abuses the SeImpersonatePrivilege on Windows 10 and Server 2016/2019. The strings in the binary contained the name of the author for the PrintSpoofer tool.

Similarly, based on the file’s strings, Juicy.Data was another publicly available privilege escalation tool named JuicyPotatoNG.

The encrypted and executables had three things in common:

  • They were both publicly available privilege escalation tools
  • Naming convention followed the original project name:
    • Open source PrintSpoofer named
    • Open source JuicyPotatoNG named
  • They both attempt to run user.bat after successfully escalating privileges.


After successfully escalating privileges, and, will attempt to run a batch file script called user.bat. The batch file script is not obfuscated and will perform the following:

  • First it creates an administrator account with a misspelled username Administrater and the password 102030TTYG@
  • Whitelist the exe process in Microsoft Defender (Ngrok is a reverse proxy, which can be used to connect to an internal service that is not exposed externally or allowed through an external firewall)
  • Sets an exclusion for .exe files in Windows defender
  • Disable Microsoft defender AntiSpyware (Effectively disabling Windows Defender)
  • Enable remote connections and add firewall rules to allow RDP connections on port 3389
  • Restart the windows service termservice (remote desktop service)

The goal of this stage is to establish persistence on the victim’s machine.


CherryLoader is newly identified multi-stage downloader that leverages different encryption methods and other anti-analysis techniques in an attempt to detonate alternative, publicly available privilege escalation exploits without having to recompile any code.

Encryption methods include simple XOR as well as AES; Anti-analysis techniques includes a password provision and process ghosting; exploits in the package analyzed include PrintSpoofer and JuicyPotatoNG.

Arctic Wolf is committed to ending cyber risk and when active intrusions are identified we are quick to protect our customers.  In response to the intrusion, Arctic Wolf has detections in place to alert upon malicious activity found by the CherryLoader and the accompanying modules.

Customers can further protect their systems by ensuring they have regularly patched their software, limited the ability to create or audit the creation of administrator accounts, audit firewall modifications, audit the disablement of Windows Defender, audit Remote Desktop services, and the use of reverse proxy tools like ngrok.


XOR Decryption Script for NuxtSharp.Data

The following Python script performs the same decryption function as Cherrytree.exe. It XORs each byte with one of the three characters in the [“K”, “r”, “y”] array:

from pathlib import Path
key = "Kry"

file = Path("NuxtSharp.Data")

with"rb") as enc_file:
	dec_file = Path("dec_NuxtSharp")
	file_content =

	kry_index = 0

	with'wb') as decrypted_file:
		for enc_byte in file_content:
			dec_byte = bytes([enc_byte ^ ord(key[kry_index])])
			kry_index = (kry_index + 1) %3

Another way to draw the same conclusion, is through data analysis of the file, as the XOR key would overwrite the null bytes with the corresponding letter as seen in the following figure:

AES Decryption Script for Spof.Data and Juicy.Data

The following Python script performs the same decryption function as File.log. It uses the AES ECB algorithm and the provided AES key to do so.

#command line to decrypt Spof.Data -f Spof.Data -k 123

#command line to decrypt Juicy.Data -f Juicy.Data -k 123
from Crypto.Cipher import AES
from pathlib import Path
import click

@click.option("-k", "--key", required=True, help="AES Key for ECB Decryption")
@click.option("-f", "--file", required=True, help="File to decrypt")
def decrypt(file, key, output):
	file = Path(file)

	if not file.exists():
		print("[!] File does not exist.")

	output_file_name = "decrypted_" +
	output_file = Path(output_file_name)

	key = bytes(key, 'utf-8').ljust(16, b'\0')

	ecb = , AES.MODE_ECB)

	with'rb') as encrypted_file:

Indicators of Compromise (IOCs)

Indicator Type Context
141.11.187[.]70 IP Address IP used to download Packed.rar and main.exe
50f7f8a8d1bd904ad7430226782d35d649e655974e848ff58d80eafedd377ee9 SHA256 main.exe
f9373383d2a1cea0179d016b4496475d44262945ab5fb6ff28cd156187c6ff6a SHA256 Packed.rar
8c42321dd19bf4c8d2ef11885664e79b0064194e3222d73f00f4a1d67672f7fc SHA256 cherrytree.exe/CherryLoader
7936b3d7d512c3a89914595c5048bce3c07bb872af59304fed95c567694230b0 SHA256 NuxtSharp.Data (Encrypted)
e0f53fb3651caf5eb3b30603064d527b9ac9243f8e682e4367616484ec708976 SHA256 NuxtSharp.Data (Decrypted)
08b8d8f8317936dad4f34676823b2eeb4fe99b0f4c213224e035b403e1e76cc0 SHA256 Spof.Data (Encrypted)
92263e5085cb3fe58fd5803536c80c5c1084500c79fc026367a15b0f04ca0142 SHA256 Spof.Data/PrintSpoofer (Decrypted)
9e6338674cd29066a4daad4ac54f01d272040d4947de39cfdf562e59af7c1318 SHA256 (Encrypted)
3641f3ddeb7583051f81ac15542850a1fba7591372389411a4b86363fdf02e78 SHA256 Juicy.Data (Decrypted)
438c7ef49fbadd67bf809f7e3e239557e1d18d4c80e42c57f9479a89e3672fd9 SHA256 User.bat


By Hady Azzam, Christopher Prest, and Steven Campbell

Hady Azzam | Senior Security Researcher

Hady is a Senior security researcher at Arctic Wolf Labs focusing on malware analysis and detection research, He has over six years of cumulative experience in reverse engineering and strong passion for novel security research.

Christopher Prest | Lead Security Researcher

Christopher is a lead security researcher and a 17 year veteran in Software and Application security development, coupled with 2 years of cutting edge detection engineering and security research. A seasoned expert, Christopher focuses on Malware analysis and reverse engineering to shape the future of cybersecurity.

Steven Campbell | Senior Threat Intelligence Researcher

Steven Campbell is a Senior Threat Intelligence Researcher at Arctic Wolf Labs and has more than eight years of experience in intelligence analysis and security research. He has a strong background in infrastructure analysis and adversary tradecraft.

Hady Azzam, Christopher Prest, and Steven Campbell

Hady Azzam, Christopher Prest, and Steven Campbell

Share :
Table of Contents
Subscribe to our Monthly Newsletter