This investigation is published in three parts. Follow the links below to navigate through our findings:

• FSB’s matryoshka #1/3 – GammaPhish and GammaWorm
• FSB’s matryoshka #2/3 – GammaLoad
• (coming soon) FSB’s matryoshka #3/3 – GammaSteel

Key Takeaways

• Gamaredon is a cyberespionage group specialized in long-term and persistent intrusion operations targeting Ukraine. Officially operated by Russia’s FSB, the group is focusing government, military, and critical infrastructure networks, and is still actively operating at the time of this publication.
• This report analyses over a decade of malware families and establishes a unified naming taxonomy to cut through the fragmented nomenclature.
• The infection chain is designed to be invisible: by hiding inside legitimate Windows features and abusing trusted platforms like Telegram, Cloudflare, and standard cloud storage, Gamaredon leaves almost no trace on infected machines.
• Once inside a network, malware spreads physically, infecting USB drives to jump across air-gapped systems and steals documents whether they are stored, being transferred, or actively edited in real time.
• Every step of the infection chain doubles as a backdoor, giving operators the ability to push new commands, update configurations, or deploy additional payloads, ensuring permanent access to compromised hosts.
• Sekoia’s TDR team tracked and reconstructed this entire infection chain to anticipate the threat, protect our worldwide clients, and contribute to countering operations that directly target the sovereignty of democratic states.

Introduction

The Sekoia.io Threat Detection & Research (TDR) team continuously monitors Gamaredon (aka UAC-0010, Armagedon), an FSB operated Russian intrusion-set historically targeting Ukrainian governmental and critical infrastructure. In our last report FSB’s matryoshka #1/3, we detailed the early stages of their January 2026 infection chain, focusing specifically on their initial access and propagation mechanisms.

Tracking Gamaredon’s ongoing campaigns presents significant challenges due to the rapid development cycle and the cybersecurity industry’s fragmented naming conventions. Over the past decade, their espionage arsenal has heavily evolved, shifting from the Pteranodon framework to highly modular, standalone payloads tracked under various names. To cut through this complexity and bring clarity to their current capabilities, Sekoia.io aligns with CERT-UA’s taxonomy, grouping the malware by its primary function: 

• GammaPhish (initial access)
• GammaLoad (intermediary loaders)
• GammaWorm (worm)
• GammaSteel (stealer)
• GammaWipe (wiper)

Note: We use the term loader when the execution chain remains entirely in-memory without writing files to disk, whereas dropper refers to stages where a file is written to the file system.

Building upon our initial publication, and thanks to over 70 artifacts retrieved by a trusted partner alongside our own live interactions with Gamaredon’s C2 staging infrastructure, we are continuing our series documenting Gamaredon 2026 arsenal. This second report focuses exclusively on GammaLoad, providing a technical analysis of the intermediary components used by Gamaredon to stage and deploy their final payload, GammaSteel, that will be analysed in the next report.

Infection chain

GammaLoad : loaders loading loaders

In this section, we will examine GammaLoad, a collection of VBScripts designed to ensure continuous access and deploy payloads over time by leveraging Dead Drop Resolvers (DDR).

It stores and updates its active C2 configuration within the Windows registry (HKCU\Console, the same location used by GammaWorm). This registry caching mechanism ensures that whenever GammaLoad is triggered again, it can resume communications using the most recent valid infrastructure. 

By combining artifacts from a compromised host with live network replay, we successfully triggered the execution flow, which consists of three distinct stages:

• First Stage (loader): fingerprints the host and uses a failover mechanism to find an active C2. It prioritizes cached URLs in the registry before falling back to legitimate DDR services (Telegraph, Telegram, Check-Host) to fetch and execute the next stage.
• Second Stage (dropper): Unlike the first stage, this script fetches the next payload and writes it to an Alternate Data Stream (ADS) within %TEMP%. It then establishes persistence by creating a scheduled task to execute this ADS before terminating.
• Third Stage (PowerShell loader): Executed regularly by the scheduled task, this obfuscated loader spawns a hidden PowerShell process. It fetches, XOR-decrypts, and executes the payload in-memory.

Ultimately, this multi-stage staging is designed to retrieve and execute GammaSteel.

This demonstrates a multi-stage mechanism: loaders actively loading other loaders. Interestingly, this TTP is not novel for Gamaredon. As early as 2015, the LookingGlass report Operation Armageddon: Cyber Espionage as a Strategic Component of Russian Modern Warfare noted that parts of the infection chain contained “several observed instances of multistage payloads with up to three levels of nested SFX archives before the ultimate malware is reached.” This historical behavior from 2015 mirrors the GammaLoad execution chain we observed in 2026.

First stage

For our analysis, we will examine the in-memory VBScript code identified by the MD5 hash bf94f4056627907d86ce1cae8b44c67a, which can also be considered as a loader. We assess that this stage is executed from GammaWorm or GammaPhish, entirely in-memory. Its primary objective is to update network configuration, fingerprint the victim, retrieve and execute the next payload stage before ending.

Upon initialisation, the loader fingerprints the host by retrieving the %COMPUTERNAME% and the hexadecimal serial number of the system drive, allowing Gamaredon to uniquely identify machines.

The loader uses a priority-based failover mechanism to find a C2 server. It iterates through a specific sequence of registry keys to find an active URL. If these keys are empty or the connection fails, it initiates a recovery phase using hardcoded DDR. There is a 1 to 3-second pause between each request, and the code does not run in a loop; its purpose is a one-shot execution.

The chronological execution flow and corresponding registry interactions are detailed below:

Priority	Source / Mechanism	Registry Key Access (HKCU\Console\)	Action
1	Registry key	Read: HistoryURL	Attempt cached C2
2	Registry key	Read: WindowsResponby	Attempt cached C2
3	Registry key	Read: CloudURL	Attempt cached C2
4	Registry key	Read: IpURL	Attempt cached C2
5	DDR: Telegraph	Write: CloudURL	Scrape, update, request
6	DDR: Telegram	Write: CloudURL	Scrape, update, request
7	DDR: Check-Host	Write: IpURL	Scrape, update, request
8	DDR: Telegram	[No key written]	Scrape, request

Once a valid C2 URL is obtained, the loader generates an HTTP GET request designed to blend with legitimate traffic by dynamically generating random URL endpoints, filenames, and extensions. The resulting URL structure looks like this:

The operator explicitly employs the User-Agent header to exfiltrate the host fingerprint method as it is embedded within a crafted User-Agent string using custom delimiters.

Field	Pattern / Value
URL schema	http(s)://[C2]/[WORD]/[INT]/[INT]/[RANDOM_STRING]/[INT].[EXT]
Path words	follow, sat, component, misfortune, endanger, menace, reproof, artistic, list, mosquito
Integers	Between 1 and 1,000
Random char	7 – 11 random alphanumeric characters
Extensions	.mov, .ato, .php, .spl, .xml, .spl, .htm, .rmvb, .xhtm, .gtp, .aspx, .bin, .asp,.swf, .jsp, .dbc, .cs, .mbx, .js, .cc, .asf, .kfx, .swf, .ega, .download, .brk, .html
Hardcoded User-Agent	Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; rv:11.0) like Gecko
User-Agent schema	Mozilla/5.0 … [SEP1][COMPUTER NAME][SEP2][SERIAL DISK HEXA][SEP3]/=[RANDOM]/= …
Fingerprint separators	Sep 1: ##, !!, ??, ==, ::Sep 2: _, @, #, =, %, ?, !Sep 3: ::, ?
Content-Length	2114

Note: We observe a Content-Length value for a GET request, which is a significant anomaly.

The loader processes HTTP responses based on the status code, serving two distinct functions: payload execution or configuration updates.

• Payload execution: If the response code is 200 OK and the body size exceeds 1,000 bytes, the loader treats the content as the next-stage VBScript. It executes this payload immediately via ExecuteGlobal(). Simultaneously, it updates HKCU\Console\HistoryURL with the current successful URL to ensure a functional C2 for the next loop iteration.

Configuration update:  If the response code is 404 Not Found, the loader implements an update mechanism. It scans the response body for a string containing https, and if found, it is interpreted as a new C2 URL. The loader updates both HKCU\Console\WindowsResponby and HKCU\Console\HistoryURL with this new address, also to ensure a functional C2 for the next loop iteration.

If cached registry keys fail, the loader queries legitimate third-party services to resolve a fresh C2 address from Telegraph, Telegram or Check-Host.

The table below provides a listing of the DDR, the URLs extracted, and the specific registry keys populated upon successful retrieval:

Hardcoded URL	Extracted URL(deobfuscated)	Registry Target HKCU\Console\
hxxps://te.legra[.]ph/fxpppscdlw-12-27	hxxps://[email protected][.]dev/libertarian	CloudURL
hxxps://telegram[.]me/s/akatachi	exemption-transportation-kilometers-berkeley	CloudURL
hxxps://check-host[.]net/ip-info?host=snterval.selltosell.ru	172.86.76[.]132	IpURL
hxxps://telegram[.]me/s/oberfarir	144.172.88[.]24	[no key written]

Note: The string exemption-transportation-kilometers-berkeley is appended to the .trycloudflare[.]com domain.

Upon successful extraction from any of these sources, the loader immediately sends a GET request and commits the active URL to the registry. 

Note: It is worth noting that a variant of this first stage, which uses almost the same mechanisms, employs BITSadmin to download and execute payloads.

During our analysis, we successfully triggered the payload delivery mechanism from the C2 endpoint hxxps://[email protected][.]dev/vehis. This resulted in the retrieval of another VBScript loader designed to execute a second loader.

Second stage

On 23 January 2026, we fetched the second stage (md5sum: a2c6e01001c62f6198e31a9d603977c6), which can be considered as a dropper. At the time of analysis, the CloudURL variable resolved to hxxps://[email protected][.]dev/vehis.

The dropper uses Base64 encoding, obfuscated with && markers inserted every 54 characters. The first stage decodes this blob and executes it directly in-memory using ExecuteGlobal().

Upon execution, the dropper writes to the registry with two hardcoded C2 values that it will use:

• The value hxxps://vids-road-christina-guards.trycloudflare[.]com written in HKCU\Console\HistoryURL
• The value hxxp://172.86.72[.]243 written in HKCU\Console\WindowsResponby

The dropper employs the same cascading GET request mechanism and the same registry keys observed in the first stages. It prioritises cached registry values before falling back to DDR. Notably, the only hardcoded domain is dayobtvoyu[.]ru. The handling of HTTP 200 OK and 404 Not Found status codes remains consistent with previous stages. However, rather than executing the next stage in-memory, the dropper decodes the VBScript from the C2 and writes the cleaned payload to an ADS at %TEMP%\:divedz0f.

Once the payload is successfully written to the ADS, the dropper stops network iterations and it registers a scheduled task named \Windows\ApplicationData\DsSvcCleanup, configured to execute this ADS every 11 minutes:

wscript.exe "%TEMP%\:divedz0f" [RANDOM ARGS] //b //e:vbscript

The dropper terminates after creating the scheduled task. We succeeded in retrieving the payload executed by the scheduled task by using the C2 endpoint hxxps://vids-road-christina-guards.trycloudflare[.]com. It is once again another loader, the third stage.

Third stage

This third stage (md5sum: d2a6009587b3cb73355c2d1e53d5cdfa), yet again, can be considered as a VBScript loader.

The retrieved code employs ROT13 obfuscation and is scheduled for execution at 11-minute intervals through a scheduled task. Upon de-obfuscation, it instantiates a hidden PowerShell process via the command WScript.Shell.Run "powershell.exe -nol -nop -encodedcommand [Base64 payload]", 0. The arguments -nol (for NoLogo) and -nop (for NoProfile) are used to suppress the startup banner and bypass user profile loading.

This Base64-encoded payload functions as a loader. Initially, it disables SSL certificate validation via [System.Net.ServicePointManager]::ServerCertificateValidationCallback={$true};. Following this, it initiates a cascading connection attempt to three hardcoded endpoints. The script uses $webClient.DownloadString($url) within a loop. Since this method throws an exception upon receiving HTTP error codes (e.g., 404, 500), the script relies on exception handling to retry the GET request, ensuring the script only proceeds when a valid HTTP 200 OK status is received.

Upon a successful response, the content is immediately Base64 decoded and then decrypted via XOR using a hardcoded key.

The resulting code is then executed in-memory via Invoke-Expression. We successfully acquired the final payload by querying the C2 hxxps://insight-sweet-drainage-appreciated.trycloudflare[.]com/log/. This code is an obfuscated PowerShell script identified as the final implant, featuring stealer capabilities and called GammaSteel, which will be analysed in the next report.

Conclusion

In this analysis, GammaLoad can be defined as a multi-stage of loaders executing loaders, illustrating Gamaredon’s signature “matryoshka” architecture. They are non-persistent because they execute entirely in-memory and will not survive a system reboot. Instead, the task of establishing GammaLoad’s persistence is highly likely handled separately by Gamaredon.

Throughout this infection chain, GammaLoad stores active C2 configuration in the registry and relies on DDRs hosted on trusted third-party platforms, ensures continuity of access and enables the operator to deploy and execute arbitrary payload hiding in legitimate service traffic.Sekoia.io’s TDR team will continue to track this campaign closely and enhance our detections of this intrusion set. Future reports in this series will lead into the final stage of the infection chain, GammaSteel.

IOCs

The file hashes below represent a subset of the hundreds of IOCs identified during this investigation. Complete IOCs list, including network indicators (IPs, C2 infrastructure, URLs and domains) is available via the Sekoia Intelligence feed and to Sekoia Defend customers.

We welcome peer-to-peer collaboration. If you are an analyst tracking this intrusion-set and wish to exchange data, please contact us at tdr[at]sekoia.io.

Payloads

Stage 1 bf94f4056627907d86ce1cae8b44c67a

Stage 2 a2c6e01001c62f6198e31a9d603977c6

Stage 3 d2a6009587b3cb73355c2d1e53d5cdfa

DDR

hxxps://telegram[.]me/s/oberfarir

C2

hxxps://insight-sweet-drainage-appreciated.trycloudflare[.]com/log

172.86.76[.]132

Thank you for reading this blog post. Please don’t hesitate to provide your feedback on our publications by clicking here. You can also contact us at tdr[at]sekoia.io for further discussions or future IOCs.

Share this post: