In this article, I distinguish between GamaLoad and Pterodo. I still consider GamaLoad a transitional stage, primarily implemented as a defensive layer to slow down analysis rather than as a fundamentally new capability. That said, there are visible changes both in payload delivery and in obfuscation.
I’ll mainly focus on what has changed since my last posts. If you’re interested in the broader context and historical behavior, have a look at the previous articles first.
For this analysis, I pulled the latest Gamaredon sample with the hash:
and dropped it straight into my tracking framework.
From a delivery perspective, not much has changed compared to Gamaredons last shift. The victim still receives a RAR archive as an attachment. When opened or extracted, it drops an HTA file into the Startup folder, infecting the system on the next reboot. A few minutes later, my tracking system already picked up the first fresh GamaLoad samples for analysis.
When comparing these new samples to the December 2025 batch, one thing immediately stood out: they are almost twice as large and noticeably more obfuscated.
(Left column: line count, right column: hash+date)
The obfuscation hasn’t just increased (which, honestly, doesn’t help much given how terrible Gamaredons obfuscation usually is :D), but it has also become slightly smarter.
Historically, their scripts contained tons of junk loops that served absolutely no purpose and could simply be deleted during manual deobfuscation. In the newer samples, however, more variables defined inside those junk blocks are later reused in the actual execution flow.
So if you’re still deobfuscating by hand or your automation isn’t fully mature yet, you’ll want to be a bit more careful here.
(Variable larkxGg is defined in the junk loop, but used after it)
The Interesting Part
A few days ago, I published an article showing how surprisingly easy it is to defend against Gamaredon by blocking a small set of Windows tools such as mshta.exe or MSXML2.XMLHTTP. If you’re honest about it, Gamaredon’s tooling is… let’s say “not exactly impressive”. Blocking a handful of abused LOLBins already makes payload delivery painfully difficult for them. Their development is slow, incremental, and often fairly predictable.
Well, i guess they noticed.
The defensive measures described in that article have now been bypassed. Don’t worry though, we’ll adjust accordingly 😁
Fallback on Fallback: Now Featuring BITS
The new GamaLoad script still relies on a familiar fallback structure to retrieve and execute payloads from their delivery infrastructure.
Conceptually, this is very simple: the script keeps trying different URLs until one successfully returns a payload. If everything fails, an empty string is returned.
What’s new is that this fallback logic now has… another fallback.
If no payload stage can be retrieved via the usual mechanisms, the script switches to downloading the payload using bitsadmin.
What is bitsadmin?
bitsadmin is a Windows utility used to control the Background Intelligent Transfer Service (BITS), which provides reliable background downloads and uploads. Attackers abuse it as a Living-off-the-Land Binary (LOLBin) to quietly retrieve payloads without dropping additional tooling onto disk.
From an attacker’s perspective, BITS has some very attractive properties:
resilient background transfers
native proxy support
high reliability on unstable networks
no obvious “malware-looking” process tree
exactly the kind of boring enterprise plumbing malware loves to hide in ^^
Why Gamaredon Switched to BITS
For years, Gamaredon heavily relied on classic LOLBins such as mshta.exe and MSXML2.XMLHTTP for payload delivery and execution. By now, these techniques are:
blocked by default in many environments (AppLocker, ASR rules, EDR hardening)
it is actively used by Windows itself (Windows Update, Defender, Office, etc.)
blocking it outright often creates operational risk in enterprise environments
its network traffic looks boring and legitimate (svchost.exe, Microsoft-like headers)
it works reliably behind proxies and restrictive networks
if your previous delivery pipeline keeps getting kicked in the teeth by defenders, BITS is a logical next step even for an actor whose tooling evolution is usually measured in geological time.
This is the result of a lengthy analysis and study of the Gamaredon UAC-0010 group. I recommend reading my previous articles for more context.
Defending against Gamaredon is uncomfortable not because the group uses particularly advanced malware, but because it forces defenders to question many assumptions that modern security strategies are built on.
Gamaredon does not rely on sophisticated exploits, stealthy implants or long-lived infrastructure. Instead it operates through large volumes of simple scripts, constantly changing delivery mechanisms and an infrastructure that is designed to burn fast and disappear. Indicators of compromise age out quickly, payloads are interchangeable and even the tooling itself adapts once it becomes the subject of analysis.
Over the past months, tracking Gamaredon has felt less like reverse engineering a malware family and more like observing a process in motion. Loader scripts evolve, obfuscation shifts slightly from wave to wave and infrastructure changes just enough to break automated collection pipelines. At times, analysis environments are actively identified and fed with destructive or misleading payloads, which turns the act of investigation itself into a signal the actor seems to react to.
This makes Gamaredon a poor fit for traditional, indicator driven defense models. Blocking hashes, domains or IP addresses provides short-lived relief at best. By the time a rule is deployed, the campaign maybe has already moved on. What remains stable is not the malware, but the behavior: how access is gained, how scripts are executed, how network communication deviates from normal client behavior and how the actor responds when it detects scrutiny.
This article focuses on defensive measures that have proven effective while actively observing Gamaredon operations in the wild. The goal is not to “out-APT” the attacker, but to break the operational assumptions that Gamaredon relies on: permissive script execution, weak visibility into client behavior and an overreliance on static threat intelligence.
Defending against Gamaredon is less about stopping a specific toolset and more about disrupting a workflow. Once that distinction is understood, the problem becomes significantly more manageable 🙂
What End Users Can Do to Reduce Risk
Remember: Gamaredon does not break into systems. It is invited in
1. Attachments are the attack surface
Gamaredon infects systems through spear phishing. End users who have received appropriate training therefore significantly reduce the risk of infection. Modern phishing campaigns, particularly those operated by actors like Gamaredon, do not rely on obvious deception or complex exploit, they exploit trust in routine actions. An email attachment that appears harmless is can be nothing more than a delivery mechanism for script execution. Shortcuts, script files or archive formats are are instructions, not documents.
For this reason, email attachments should never be opened impulsively. Files originating from unknown senders, unexpected conversations or unclear contexts must always be routed through a defined analysis workflow. This may include automated malware scanning, sandbox execution or escalation to a SOC or security team for manual review.
Treating attachments as executable content rather than documents removes a core assumption attackers rely on: that a single double-click is enough to gain a foothold.
2. “It looks normal” is not a defense
A common assumption in phishing awareness is that malicious emails will “look suspicious.” Misspelled text, strange formatting or obviously fake senders are warning signs. Campaigns operated by Gamaredon routinely break this expectation.
Many of the emails used in these operations are short, plain and unremarkable. They may not contain any obvious red flags, no unusual wording and no visual elements that stand out. In some cases, the message itself is barely relevant at all. The attachment is the real payload.
Relying on visual cues or intuition to assess whether an email is safe is therefore considered to be ineffective. A file does not need to look dangerous to be dangerous. Shortcuts, script files and archived attachments can appear entirely legitimate while silently triggering code execution in the background.
This is intentional. Gamaredon does not attempt to impress the recipient or convince them emotionally. Instead, it blends into routine communication, where opening an attachment feels like a harmless, almost automatic action.
For this reason, the absence of suspicious indicators are better off never be treated as confirmation of safety. Normal looking emails are not evidence of harmless content, they are often the environment in which these campaigns are most successful.
3. Why double-clicking is dangerous
Most people treat double-clicking as a harmless, almost meaningless action. It is how you open a document, check an image,or quickly look at a file someone sent you. From a usability perspective, that makes sense. From a security perspective, it is exactly the problem.
Not every file is a document! Many files are nothing more than instructions telling Windows to execute other programs, run scripts or fetch additional content from the internet. When you double-click those, you are not “previewing” anything. You are actively starting a process chain.
What makes this especially effective is how unspectacular it looks. In many Gamaredon cases the initial file does almost nothing visible. Maybe a window flashes, sometimes nothing happens at all. From the users point of view, that feels like a failed or broken attachment. From the attackers POV the important part already happened: code execution in user context.
This is not accidental. Gamaredon does not need the first file to be powerful. It only needs it to run. The rest can be downloaded, replaced or updated later. The initial step is small, quiet and easy to overlook.
That is why “just opening it to see what it is” is not a safe strategy. With many attachment types, execution is the first and only action. There is no confirmation dialog, no warning and no visible sign that anything meaningful happened until much later, when the real payload is already in place.
tldr: double-clicking is not a neutral action. It is a trust decision and attackers like Gamaredon build their entire delivery chain around the assumption that this trust will be given automatically. Gamaredon can be avoided if you stop trusting the files you are about to open . As Lenin said “доверяй, но проверяй” 😉
4. Update. Update. Update.
Always keep the software on your system up to date. Gamaredon has actively exploited real-world vulnerabilities, for example a WinRAR vulnerability “CVE-2025-6218” observed in campaigns since late 2025.
This vulnerability allows an attacker to place a malicious file into the Windows startup folder when an archive is opened or extracted. The user may only see a normal archive being unpacked, while persistence is already being established in the background and the system becomes infected after the next reboot. This is exactly the kind of low-effort, high-impact technique that fits Gamaredons operational model.
Keeping your software updated, especially tools that handle downloaded files such as archive managers, removes entire classes of attack techniques.
5. When to escalate
One of the most reliable defenses attackers have is silence. Not because nothing happened, but because users assume that whatever happened is probably not important enough to bother anyone with.
“This file didn’t open properly” “The window flashed and disappeared” “Nothing seems broken so it’s probably fine”
From the perspective of an attacker, this is perfect. Initial access does not necessarily need to be loud, it only needs to be unnoticed.
The first-stage file doesn’t display an error message, ransomware screen or any obvious sign of compromise. It executes, exits and waits for the next step. If no one reports it, there is nothing to investigate, nothing to contain and nothing to learn from.
Users hesitate to report something because they do not want to be wrong, do not want to interrupt anyone or assume that security teams only care once things are clearly broken. Unfortunately, by the time something is clearly broken, the attacker has already achieved most of their objectives.
From a defensive POV the ideal time to escalate is when you are unsure whether something must have happened at all and not when you are sure something malicious happened.
If an attachment behaves strangely or if a file does not open as expected, if a website triggers download you did not request or if anything simply feels off, that is already enough reason to report it. Security teams do not need certainty. They need signals. It’s better to report one more false positives to your security team then not reporting it.
Yes, most reports will turn out to be harmless. That is fine. What is not fine is missing the few cases that actually matter because no one wanted to be the person who raised a false alarm.
tldr: if something looks broken, weird or pointless, that is not a reason to ignore it. That is exactly when escalation is supposed to happen. The worst possible outcome of reporting is a short investigation. The worst possible outcome of not reporting is an attacker quietly staying in your network.
Defensive Controls for System and Network Administrators
1. Kill the script layer
Gamaredons operations depend almost entirely on script-based execution. VBScript, JS, HTA files and shortcut-based loaders are the foundational tools. Without the ability to execute scripts in user context, the majority of observed Gamaredon infection chains fail before any payload is delivered.
This makes the script execution layer a highly effective choke point for defenders.
In many environments, script interpreters such as wscript.exe, cscript.exeor mshta.exe are still broadly available to all users, despite having little to no legitimate business use. From an attackers perspective, this provides a reliable and low-friction execution environment that does not require exploits, elevated privileges or complex tooling.
Restricting or disabling these components significantly raises the cost of an attack. Blocking mshta.exe entirely, enforcing execution policies for VBScript and JScript and preventing script execution from user-writable locations such as Downloads, Tempor profile directories removes a critical assumption Gamaredon relies on: that scripts will execute by default.
Where complete blocking is not feasible, strict allow-listing needs to be applied. Script execution should be limited to known, signed,and explicitly required use cases. Everything else should fail closed.
It is important to note that this is not merely a prevention measure, but also a detection opportunity. Script-based attacks are very noisy at the process level. Parent-child relationships such as email clients spawning script hosts or shortcut files launching interpreters provide strong, behavior based signals that are far more stable than file hashes or domains.
Defenders mostly focus on detecting the final payload. Against Gamaredon, this approach is too late. By the time a second stage binary is downloaded, the attacker has already achieved their primary goal: execution. Eliminating or tightly controlling the script layer prevents this first and most critical step.
Option 1: Disable mshta.exe
mshta.exe has virtually no legitimate use in modern enterprise environments and is heavily abused by Gamaredon
This alone stops most VBS- and JS-based Gamaredon loaders. It’s also a good defense against other Threat Actors, since Gamaredon is not the only one to use the methods
Option 3: Block Script Exec from User-Writable Paths
Gamaredon relies on execution from:
Downloads
%TEMP%
%APPDATA%
Email attachment paths
Apply to:
.vbs
.js
.hta
.lnk
Prevents double-click execution even if scripts are not fully disabled
Option 4: If Blocking is impossible – Make It Visible
Some environments cannot fully disable scripts. In that case, visibility is mandatory.
Enable Script Block Logging:
Computer Configuration
> Administrative Templates
> Windows Components
> Windows PowerShell
Enable:
Turn on Script Block Logging
Turn on Module Logging
Enable Command Line Proccess Auditing
Computer Configuration
> Administrative Templates
> System
> Audit Process Creation
Enable:
Include command line in process creation events
This enables:
Event ID 4688
Parent/Child relationships:
outlook.exe > wscript.exe
explorer.exe > mshta.exe
Option 5: YARA on Email Attachments
One of the most effective defensive layer that is underestimated in Gamaredon-style campaigns is attachment scanning at the email gateway using YARA rules.
A large part of Gamaredons initial access relies on script-based loaders delivered directly as attachments (HTA, VBS, JS, LNK) most of the time inside archives (abusing Winrar CVE since end of 2025), scanning files before they ever reach the user can break the infection chain at the earliest possible stage.
YARA is particularly useful here because it does not rely on file hashes or exact filenames. Structural patterns, script constructs and typical obfuscation techniques tend to remain relatively stable even when the surrounding delivery changes. That makes YARA a good fit for detecting families of loaders rather than individual samples.
Applied at the mail gateway or in attachment processing pipelines, YARA rules can prevent execution entirely instead of trying to detect activity after the user already clicked the file. From a defensive POV, that is always the better place to intervene.
I maintain a set of YARA rules specifically focused on Gamaredon loader patterns, including HTA- and VBScript-based stages observed from older and recent campaigns. These rules are meant for legitimate research and defensive use. If you are working in a security or incident response context and want to test or deploy them, feel free to contact me and I can provide them for evaluation and tuning.
YARA will not stop infrastructure shifts or payload changes, but it is very effective at removing large parts of the delivery layer that Gamaredon depends on. Combined with script execution controls and network visibility (read above), it significantly reduces the attackers room to operate.
Option 6: Shortcut (LNK) Abuse Mitigation
Gamaredon frequently abuses .lnk files as script launchers.
Controls:
Block .lnk execution from email attachment paths
Alert on:
LNK spawning wscript, mshta, powershell
Disable preview handlers for LNK in mail clients if possible
Option 7: Block / Restrict bitsadmin
This should be an addition, not just an option As a fallback for msxmlhttp, Gamaredon introduced bitsadmin in their newest Gamaload Samples as an additional fallback, you can read more about it here.
Disabling BITS entirely is not an option in most enterprise environments. Windows Update, Defender, SCCM and many enterprise management tools depend on it. Breaking BITS usually means breaking business.
The goal is therefore not to kill BITS, but to remove its value as a reliable malware loader.
Gamaredon doesn’t need stealthy tooling. They need something that works everywhere, survives bad networks and doesn’t get blocked. If you take away that reliability, the technique quickly becomes unattractive.
Below are several practical controls that achieve exactly that:
Block bitsadmin.exe, not BITS
bitsadmin.exe is merely a legacy command-line frontend for BITS. Modern software uses PowerShell or native APIs instead. In most environments, nothing legitimate depends on interactive use of bitsadmin.exe.
Scope: non-admin or Everyone, depending on your policy
Impact
Windows Update continues to work
Defender continues to work
SCCM and management tooling remain unaffected
But… Malware loses the easiest way to create BITS jobs
Why this hurts Gamaredon
Gamaredons loaders frequently invoke BITS directly from scripts and HTA stages. They rely on simple CLI execution, not on robust API-based fallbacks. Blocking the binary often breaks the entire staging chain
Restrict Where BITS Is Allowed to Connect
BITS traffic is still regular HTTP/HTTPS traffic. It can and should be controlled at the network layer!
Control
On proxy or firewall level:
Allow BITS traffic only to:
Microsoft update endpoints
Internal patching infrastructure
Explicitly approved business domains
Block or inspect everything else.
Optional detection:
Alert on User-Agent: Microsoft BITS/* connecting to non-whitelisted domains.
Impact
Business traffic remains unaffected
Updates continue to function
External drop servers used by attackers fail reliably!
This is a strong IOC-less control that scales well in enterprise environments 🙂
Disrupt BITS Job Persistence
One of BITS advantages for attackers is job persistence: jobs survive logoffs, reboots and network interruptions.
Removing that persistence dramatically reduces reliability for staged malware delivery.
Control
Regularly purge queued jobs:
PowerShell example:
Get-BitsTransfer -AllUsers | Remove-BitsTransfer
Schedule this on workstations every 30–60 minutes (adjust to your needs)
Impact
Normal short-lived update jobs typically complete unaffected
Malware loses reliable staging and retry capability
Use caution during large enterprise software rollouts, this is also not the most effective way imo
Enforce Strong Telemetry on BITS Usage
As I already mentioned, if you cannot block it safely everywhere, make abuse visible!
Control
Enable command-line process auditing
Monitor:
Execution of bitsadmin.exe
Parent processes such as mshta.exe, wscript.exe
Correlate with network destinations and file writes
Impact
No production risk
High-quality detection signal
Low false-positive rate
Remember: BITS usage initiated from scripting engines is rarely legitimate
Behavioral Heuristics for BITS Abuse
For mature environments and advanced detection platforms:
Monitor for suspicious patterns such as:
BITS downloads into:
%TEMP%
%APPDATA%
User profile writable paths
Randomized file names
Short-lived jobs followed immediately by execution
Non-corporate TLS destinations
This can be implemented via:
ETW telemetry
Defender Advanced Hunting
Custom sensors and collectors
Provides behavioral detection without relying on static indicators
Visibility beats prevention
At minimum, you need to have visibility into:
wscript.exe (classic VBS/JS execution)
cscript.exe (same, console version)
mshta.exe (HTA execution, including embedded VBScript/JS)
powershell.exe (still relevant, second stage)
But execution alone is only half of the picture here. In Gamaredon campaigns script hosts are usually paired with built-in Windows networking components, MSXMLHTTP.
Inside the script, outbound communication is handled via this compnents (mostly):
MSXML2.XMLHTTP
MSXML2.ServerXMLHTTP
From the outside, this generally looks like a normal process making web requests. There is no external downloader, no suspicious binary and no obvious command line indicator, since everything happens inside the script host process itself.
That means defenders should not only care that a script host started, but also whether that process immediately initiated network connections. Script execution without network activity might be a test or a failure. Script execution followed by HTTP traffic is the actual attack.
If your telemetry cannot correlate:
script execution
with outbound connections
and with the destination domain or IP
then you are missing the exact phase where Gamaredon (or other Threat Actors) transitions from initial access to payload delivery.
tldr; seeing the script start is useful. Seeing the script talking to the internet is what actually tells you that the infection chain is active
Alert on Parent-Child Process Chains, Not on Filenames
Gamaredon changes filenames constantly. That is not where stability is.
What does not change:
Email client -> script host
Explorer -> shortcut -> script host
Script host -> network activity
Those relationships are far more reliable than any hash or URL
If your detection logic is still focused on “known bad files”, you are solving yesterdays problem. Behavior survives infrastructure rotation … but IOCs do not
Treat Failed Infections as Intelligence, Not as Non-Events
One of the more frustrating patterns when tracking Gamaredon is how many times infection attempts partially fail. The loader runs, the payload is blocked or the network request never completes.
From an incident-response POV it could be treated as “problem solved”.
From an intelligence perspective, i think that it’s a gift.
Those events tell you:
Which attachment types are used
Which execution paths are attempted
Which infrastructure is currently active
If you only investigate successful infections, you will always be late. The campaigns that fail today are the ones that succeed tomorrow with minor adjustments. If you understand Gamaredon properly, you can always be a step ahead.
Accept That Something Will Slip Through – Just Plan Around That
Perfect prevention is a nice idea, but ideas are just ideas. It is not how real environments work.
Gamaredon does not need persistence for months. It needs minutes of execution. If those minutes go unnoticed, the damage is already done, regardless of whether the payload later gets removed.
Your defensive strategy needs to assume:
Some scripts will execute
Some attachments will be opened
Some rules will be bypassed
The question here is whether anyone notices in time to react.
Visibility does not replace prevention at all. But without visibility, prevention failures become silent compromises. And silent compromises are exactly what this actor benefits from. You could say that visibility complement your prevention efforts.
Network controls that matter
From a network POV, Gamaredon is not noisy. It does not deploy custom backdoors that beacon every few seconds and it does not rely on exotic protocols. Most of the traffic is simple http(s) generated directly from scripts using tools like MSXML2.XMLHTTP.
That has two important consequences for defenders.
First, there is no separate downloader process to catch. The same process that executed the script is now making web requests. Just mshta.exe or wscript.exe talking to the internet like a perfectly normal Windows application.
Second, many network controls are designed around detecting known bad destinations, not suspicious clients. If you only look at where traffic goes, but not who is sending it and under which circumstances, you miss the entire initial delivery phase.
For Gamaredon style campaigns network defense has to focus on context, NOT just destination.
Correlate Network Traffic With Process Activity
If a script host executes and immediately initiates outbound connections, that is not normal workstation behavior.
At minimum, be able to answer:
Which process opened the connection?
What launched that process?
What file triggered the execution?
MSXMLHTTP-based traffic will look perfectly legitimate on the wire unless you know it came from a script that just executed from a mail attachment.
Normalize Outbound HTTP Behavior
One of the more uncomfortable lessons when tracking Gamaredon is that attackers actively use network behavior itself as a detection mechanism.
In several waves, delivery depended on whether certain headers, (in the latest Gamaload Samples) especially Content-Length, matched what the script originally set. Many commercial proxy setups modify requests by:
re-encoding bodies
switching between chunked and fixed-length transfers
inspecting and rewriting traffic
From the attackers side, that becomes a cheap and reliable way to identify analysis environments and block payload delivery.
Defensively, this means:
Outbound traffic needs to be as predictable and uniform as possible
Proxy behavior should be consistent across user and analysis environments
Sudden header manipulation should be considered a detection signal, not just a networking detail!!!
Otherwise, you end up with the worst possible situation: real users get infected, while analysis systems receive fake or destructive payloads
DNS as a detection surface
Treat DynDNS and Low-Rep Domains as High-Risk by Default
Gamaredon infrastructure heavily relies on:
dynamic DNS providers
rapidly changing subdomains
short-lived hosting setups
Blocking individual domains is pointless. They rotate too fast. What does not change is the type of infrastructure being used.
From a defensive standpoint, this means:
DynDNS traffic has to be restricted, monitored or at least flagged
Newly registered domains should not be treated the same as established ones
DNS telemetry is worth as part of detection logic, not just resolution
If your network policy implicitly trusts any domain that resolves, you are trusting exactly the layer Gamaredon is built on
What to Monitor Instead of Chasing Domains
DNS telemetry provides several signals that remain useful even when infrastructure rotates:
Domain age Newly registered domains should be treated different from domains that have existed for years. Many Gamaredon delivery endpoints fall into the “new/very new” category.
Provider patterns Certain DynDNS and free subdomain services appear repeatedly across campaigns.
Subdomain churn Rapidly changing subdomains under the same parent domain are a common pattern. This is not normal behavior for most legitimate services used by end users.
NXDOMAIN spikes Failed dns lookups shortly before successful connections can indicate scripted discovery or fallback logic inside loaders. Since this is very common, you can use this as a strong pattern for finding Gamaredon related activity. You can detect it, even if timeouts and sleeps are enabled.
None of these signals alone prove malicious intent itself, but together they describe infrastructure behavior that is/could be highly consistent with how Gamaredon operates. Once this dynamic is understood, the operational flexibility that makes Gamaredon effective becomes a liability that defenders can exploit 🙂
Restriction Beats Blacklisting
If possible, access to high-risk DNS categories have to be restricted by policy, not just monitored.
This can include:
blocking or limiting known DynDNS providers
forcing additional inspection or logging for low-reputation domains
isolating traffic to newly registered domains
The goal is not to eliminate all risk (that is unrealistic) but to reduce the attackers ability to operate entirely in disposable infrastructure without triggering any response.
Gamaredon depends on infrastructure that can be replaced quickly and cheaply. Defensive strategies have to make that approach operationally expensive instead of operationally invisible.
DNS Is Not Just Plumbing
In many environments, DNS is treated as a purely technical service: something that resolves names and moves on. From a threat detection perspective, that is a wasted opportunity.
DNS shows:
where systems are trying to go
how often endpoints change
whether communication targets look stable or disposable
Especially in script-driven infection chains, DNS can be the first external signal that something has moved from local execution to external communication.
If DNS data is not included in your detection logic, then a large portion of Gamaredon activity will look like harmless background traffic until much later in the attack chain.
In my opinion, proper DNS logging should always be included a defensive strategy, regardless of which threat actor you are dealing with.
Prepare for anti-analysis
One thing that becomes obvious to me when tracking Gamaredon over time is that they do not just try to avoid detection, they actively react to analysis.
Payload delivery and script behavior can change depending on the environment. Analysis systems may receive different payloads, broken samples or nothing at all, while real victims get fully functional stages. What you see in a sandbox is not always what happens in the wild.
This means relying on a single analysis setup is risky. If all samples run through the same sandbox, the same proxy and the same network profile, that environment becomes easy to fingerprint and easy to avoid.
Analysis systems should look as boring and realistic as possible.
The takeaway from my analysis is simple: when the attacker adapts to being observed, your analysis pipeline becomes part the attack surface. If you do not account for that, you may be analyzing exactly what the attacker wants you to see
More information
If you want to know more about Gamaredn, check out my latest articles:
In malware analysis, it is tempting to describe change as innovation. New tricks, new tooling, new malware families. What is far more revealing, however, is how little actually changes and what changes anyway.
Between late November and the end of December 2025, several Gamaredon-related VBScript loaders surfaced that are, functionally, almost identical. They all execute the same mechanism, rely on the same execution primitive, and ultimately aim for the same outcome.
And yet, something does change, quietly, incrementally, and very deliberately.
This article focuses strictly on observable, concrete shifts in obfuscation, not assumptions, not intent inferred from tooling, and not architectural leaps that are not supported by the samples themselves.
Hundreds of variables that are written to once and never read again
Repeated arithmetic mutations (x = x + 14) without semantic relevance
Long linear execution flow
No variable declarations (Dim entirely absent)
The obfuscation here serves one purpose only: syntactic noise.
There is no attempt to:
Hide control flow
Delay string resolution
Reconstruct logic conditionally
Everything is present in the source, just buried under irrelevant assignments.
From an analyst’s perspective, this sample is noisy but predictable. Once dead code is ignored, execution logic collapses into a short, linear sequence.
19 December 2025 – Indicator overload
The mid-December sample introduces a clear and measurable change: indicator density.
New observations:
A significant increase in hard-coded URLs
URLs pointing to unrelated, legitimate, and state-adjacent domains
No execution dependency on most of these URLs
Crucially, these URLs are not obfuscated. They are placed in plain sight.
This is not string hiding it is indicator flooding.
The obfuscation shift here is not technical complexity, but analytical friction:
Automated extraction produces dozens of false leads
IOC-based clustering becomes unreliable
Manual triage cost increases without changing execution logic
The loader still behaves linearly. What changes is the signal-to-noise ratio.
22 December 2025 – Defensive Reaction at the Payload Layer
The December 22 sample is not an obfuscation milestone, but it is a defensive one.
From a loader perspective, almost nothing changes:
The download URL is fully present and statically recoverable
No additional string hiding or control-flow manipulation is introduced
Execution remains linear and transparent
However, focusing solely on loader complexity misses the actual shift.
The real change happens at the payload layer
For the first time in this series, the loader delivers GamaWiper instead of Pterodo for Analysis environments.
This is not a neutral substitution.
As outlined in my earlier analysis of GamaWipers behavior, this payload is explicitly designed to:
Notably, this change occurs almost exactly four weeks after my article outlining practical approaches to tracking Gamaredon infrastructure went public. Whether coincidence or feedback loop, the timing aligns remarkably well with the first observed deployment of GamaWiper as an anti-analysis response.
25 December 2025 – Control-Flow Noise Appears
The Christmas sample does not introduce new primitives, but it does introduce execution ambiguity.
Concrete changes:
Multiple .Run invocations exist
Not all of them result in meaningful execution
Several objects and variables are constructed but never used
Execution order is less visually obvious
This is not branching logic, but control-flow camouflage.
The analyst can still reconstruct execution, but:
Dead paths look plausible
Execution sinks are no longer unique
Automated heuristics struggle to identify the real one
The obfuscation no longer targets strings, it targets execution clarity.
30 December 2025 – Fragmented Runtime Assembly
The final sample introduces the most tangible structural changes.
Observed differences:
Systematic use of Dim declarations
Extensive use of short, non-semantic string fragments
Assembly of execution-relevant strings via repeated concatenation across distant code sections
No complete execution string exists statically
Domains are just random invalid Domains
At no point does the full execution command exist as a contiguous value in the source.
Instead:
Fragments are combined
Recombined
Passed through intermediate variables
Finalized immediately before execution
This directly degrades:
Static string extraction
Signature-based detection
Regex-driven tooling
No encryption is added. The shift is purely architectural.
05 January 2026 – Added Datetime Parameter to URL
EDIT 07.01.2026: I added this part as new findings appeared
Since early January, another small but relevant change appeared in the loader logic.
The scripts now generate a date value at runtime:
This value is then embedded directly into the download path, resulting in URLs like:
From a detection standpoint, this is subtle but effective
This means:
payload paths change daily
static URL signatures age out immediately
and IOC reuse across campaigns becomes unreliable
Relation to Prior Observations
This behavior aligns closely with patterns discussed in my earlier article on GamaWiper and Gamaredon’s anti-analysis strategies, where delivery behavior adapts based on perceived execution context.
After my recent blog posts covering Gamaredon’s ongoing PterodoGraph campaign targeting Ukraine, and following almost a full month of silence in terms of newly observed malware samples, fresh activity has finally resurfaced.
New samples have appeared, along with reports pointing to a component now referred to as GamaWiper.
It is important to note that GamaWiper, or at least very similar scripts has already been observed in Gamaredon operations in previous months. From a purely technical standpoint, this functionality is therefore not entirely new.
What is new, however, is the context in which it is now being deployed.
In this article, I aim to shed some light on what GamaWiper actually is, why Gamaredon is actively delivering it at this stage of the infection chain, and what this shift tells us about the group’s current operational mindset. What initially appears to be just another destructive payload instead turns out to be a deliberate control mechanism, one that decides who receives the real malware and who gets wiped instead
I’ll keep this post a bit shorter and focus only on what’s new, so it doesnt get boring. If you’re looking for deeper technical details, please refer to my previous posts from 22.11.2025 and 13.11.2025, where I covered the core mechanics in depth.
For this analysis, I’m using my deobfuscated version of the sample, next time i’ll maybe show you how to deobfuscate Gamaredon Scripts manually in less then 10 minutes.
After downloading the latest Gamaredon malware sample, it immediately became obvious that the current variants differ noticeably from what we’ve seen before.
Note: I started writing YARA Rules for Gamaredons current samples, you can find them here.
Key Changes at a Glance
Junk URLs now closely resemble real payload delivery URLs
No full Pterodo payload is delivered anymore 🙁
Gamaredon has hardened the delivery of Pterodo samples
Infection Flow – What Changed?
After the user opens the RAR archive and infects their system, the behavior initially looks familiar. On reboot, the Pterodo sample is fetched again, but only if the client is geolocated in Ukraine, as already mentioned in my previous blog posts.
Previously, non-UA clients would simply receive:
an empty page, or
an empty file
Today, however, things look a bit different.
Instead, the client receives GamaWiper.
GamaWiper – Sandbox? Gone.
GamaWiper is essentially a sandbox / VM killer whose sole purpose is to prevent analysis environments from seeing anything useful.
In earlier campaigns, this wasn’t always handled very well. For example, when I used Hybrid-Analysis, it was trivial to extract:
Telegram channels
Graph URLs
infrastructure relationships
This was a classic infrastructure design flaw and a great example of what budget cuts can do to an APT operation 😄
Today, however, the approach is much simpler:
If a sandbox is detected -> wipe it
No telemetry, no infrastructure leaks, no fun.
If you are a doing legit malware research interested in (deobfuscated) Samples from Gamaredon, you can write me an email.
Initial Loader: “GamaLoad”
The initial loader, which I’ll refer to as GamaLoad, implements a multi-stage payload fetch mechanism with dynamically constructed URLs and headers. The goal is resilience: fetch stage two no matter what.
Note: All malicious domains have been removed.
Request Characteristics
Request Type
Method: GET
Client:msxml2.xmlhttp
Execution: synchronous
URL Structure
Each request fetches a randomly generated resource:
/<random>.<ext>
Random filename: 7-10 characters (a-z, 0-9)
Camouflage extensions, e.g.:
wmv
yuv
lgc
rm
jpeg
C2 Fallback Order
The script iterates through multiple sources until a valid payload is received:
Argument URL (if passed at execution)
Hardcoded fallback
Cloudflare Workers domain
Domain fetch using @ notation
Abuse of the URL userinfo field
Dynamic host via check-host.net
HTML parsing
live host extraction
Alternative domain (again using @ notation)
Registry-based URL
Once a working C2 is found, it is stored as a persistent C2 entry.
HTTP Headers
The request uses very explicit and intentionally crafted headers.
User-Agent
A browser-like string combined with a host fingerprint, including:
Computer name
Drive serial number (hex-encoded)
Timestamp
UTC+2
Ukrainian local time expected
Cookie
Static campaign identifier
Rotates regularly (more on that below)
Content-Length
Explicitly set
Even for GET requests
Enables victim identification & tracking Also plays a role in proxy evasion (see below)
Success Condition
A request is considered successful when:
HTTP status is 200
Response size is greater than 91 bytes
Once this condition is met, all remaining fallbacks are skipped.
Payload Processing
Payload received as binary
UTF-8 conversion
Cleanup (CR/LF, delimiters)
Base64 decoding
In-memory execution
No disk writes – classic fileless execution
Evasion Techniques
Multi-stage fallback logic
Dynamic hosts
Delays between requests
Victim-specific User-Agent
Below is an example of a fully constructed request header sent to the payload delivery host.
Payload Rotation
Gamaredon currently rotates payloads every 1-3 hours.
With each rotation, the following variables may change:
Domains for Payload Delivery
User-Agent
Cookie
Content-Length
Why Is Content-Length Set?
The Content-Length HTTP header specifies the size of the request or response body in bytes. Its typical purpose is:
Defining message boundaries
Preventing truncated reads
Enabling correct stream handling
In this case, however, I strongly believe the header is set intentionally for tracking and proxy evasion.
Why?
The loader uses msxml2.xmlhttp. When calling .send() via this client, the Content-Length header is not overwritten.
For a normal residential client, this is usually not an issue. However, many HTTP/HTTPS proxies, especially residential and chained proxies fail to handle this properly and may:
break the connection
modify the request
normalize headers
This behavior is highly detectable.
My conclusion: Gamaredon likely uses this mechanism to filter out proxy-based analysis setups. The choice of client and header behavior is far too specific to be accidental.
So, if you end up receiving GamaWiper instead of a payload, now you know why.
Conclusion
Gamaredon has clearly tightened its operational security.
The infrastructure flaws that previously allowed easy extraction of internal details have been addressed, and sandbox detection has shifted from “leaky but useful” to “wipe and move on”.
While these changes will certainly disrupt some tracking and automated analysis systems, the overall approach feels… let’s say pragmatic, but somewhat heavy-handed.
UPDATE 22.12.2025: Gamaredon updated it’s payload delivery infrastructure. You can find more information here. UPDATE 08.01.2026: If you want to know how to defend against Gamaredon and similar Actors, check out this article. I also started writing YARA Rules for Gamaredons current samples, if you are a valid security researcher and you need them, send ma an email. If you are a doing legit malware research interested in (deobfuscated) Samples from Gamaredon, you can write me an email aswell.
Campaign Summary
Timeframe: February – November 2025
37 analyzed samples
New zero-click infection vector -> CVE-2025-6218
New C2 architecture: DynDNS + Fast-Flux + Telegram + graph.org
Two-stage geo-fencing + header firewall
Pteranodon as the central Stage-2 loader
Server-side registration required for deeper payload access
As the year slowly crawls toward its inevitable end (like certain Russian infrastructure), it’s a good moment to take another detailed look at Gamaredon’s ongoing phishing campaign targeting Ukraine.
I’ve previously published a high-level overview of this campaign, you can check that article out if you want the “lite” version. Today, however, we’re digging deeper: how to untangle the FSB’s infrastructure for this operation and how we managed to extract additional payloads directly from their servers with varying degrees of cooperation from Microsoft’s RAR parser.
A quick thank-you goes out to my brother Ramon, who assisted especially in retrieving additional payloads from Gamaredon’s backend. Family bonding through state-sponsored malware analysis, truly heartwarming.
Dataset Overview
For this analysis, I organized all samples into a structured table divided into Stage-1 and Stage-2 to Stage-X artifacts.
Stage-1 samples are the actual phishing attachments delivered to victims (HTA, LNK, RAR archives).
Stage-2 to Stage-X samples represent everything the Gamaredon infrastructure subsequently downloads once the initial loader executes or the vulnerability is triggered.
Each entry contains:
Filename: original name taken from the email attachment or payload
Hash: SHA-256 fingerprint for verification
Dropped Files: anything extracted or written by the sample (HTA/PS1 loaders, Pteranodon modules, persistence scripts, etc.)
This allows us to map the infection chain fully, from the very first email to the deeper payload ecosystem sitting behind Gamaredon’s firewall-like C2 logic.
In total, we analyzed 37 samples for this write-up.
Передати засобами АСУ Дніпро_6_3_4_4265_17.11.2025.pdf Передати засобами АСУ Дніпро6_3_4_4265_17.11.2025.pdf:............_AppData_Roaming_Microsoft_Windows_Start Menu_Programs_Startup_6_3_4_4265_17.11.2025.HTA
Передати засобами АСУ Дніпро_9_5_5_433_17.11.2025.pdf Передати засобами АСУ Дніпро9_5_5_433_17.11.2025.pdf:............_AppData_Roaming_Microsoft_Windows_Start Menu_Programs_Startup_9_5_5_433_17.11.2025.HTA
Передати засобами АСУ Дніпро_2_7_4_62_13.11.2025.pdf Передати засобами АСУ Дніпро2_7_4_62_13.11.2025.pdf:............_AppData_Roaming_Microsoft_Windows_Start Menu_Programs_Startup_2_7_4_62_13.11.2025.HTA
Передати засобами АСУ Дніпро_3_8_2_7442_13.11.2025.pdf Передати засобами АСУ Дніпро3_8_2_7442_13.11.2025.pdf:............_AppData_Roaming_Microsoft_Windows_Start Menu_Programs_Startup_3_8_2_7442_13.11.2025.HTA
Передати засобами АСУ Дніпро_2_1_1_7755_12.11.2025.pdf Передати засобами АСУ Дніпро2_1_1_7755_12.11.2025.pdf:............_AppData_Roaming_Microsoft_Windows_Start Menu_Programs_Startup_2_1_1_7755_12.11.2025.HTA
Передати засобами АСУ Дніпро_2_1_1_7755_11.11.2025.pdf Передати засобами АСУ Дніпро2_1_1_7755_11.11.2025.pdf:............_AppData_Roaming_Microsoft_Windows_Start Menu_Programs_Startup_2_1_1_7755_11.11.2025.HTA
Щодо надання інформації (військова частина А0135_11-967_11.11.2025).pdf Щодо надання інформації (військова частина А0135_11-967_11.11.2025).pdf:.........._.._AppData_Roaming_Microsoft_Windows_Start Menu_Programs_Startup_11-967_11.11.2025.HTA
Запит на отримання інформації командира військової частини А0135_11-967_10.11.2025.pdf Запит на отримання інформації командира військової частини А0135_11-967_10.11.2025.pdf:.........._.._AppData_Roaming_Microsoft_Windows_Start Menu_Programs_Startup_11-967_10.11.2025.HTA
Перегляд підходів до призову під час мобілізації_2-3716-25_07.11.2025.pdf Перегляд підходів до призову під час мобілізації2-3716-25_07.11.2025.pdf:............_AppData_Roaming_Microsoft_Windows_Start Menu_Programs_Startup_2-3716-25_07.11.2025.HTA
The analyzed artifacts make the intention behind this operation painfully clear: the campaign is aimed squarely at Ukrainian military, governmental, political, and administrative entities.
Based on filenames, document themes, and sender infrastructure, Gamaredon’s operational goals can be summarized as follows:
Military intelligence collection (documents, internal communication, location data, organization charts)
Rapid exfiltration (Pteranodon immediately sends host-, user-, and system-metadata to the C2)
Long-term espionage (stealers, wipers, tasking modules, USB spreaders)
This is not an opportunistic campaign. It is a structured, military-oriented espionage and sabotage operation consistent with, and likely coordinated by Russian state intelligence.
Campaign Timeline
Campaign Description
Gamaredon continues to bombard Ukrainian organizations with phishing emails, using a rotating set of attachments and themes. The filenames of the analyzed samples strongly indicate military and political targeting, and the underlying infrastructure is built on large DynDNS farms and Fast-Flux C2 nodes an architecture that screams “FSB budget optimization,” if you will.
Until early November 2025, the group primarily distributed HTA and LNK attachments. Then they shifted strategy, adopting a new Windows vulnerability CVE-2025-6218, allowing infections without the victim consciously executing anything.
Their new favorite delivery vector? RAR archives containing seemingly harmless documents.
What happens?
When a victim opens the RAR archive:
the vulnerability triggers immediately
a hidden HTA is extracted straight into the Windows Startup folder
reboot -> automatic execution -> connection to Gamaredon’s C2
further payloads are downloaded and initial reconnaissance begins
A classic example of Microsoft doing Microsoft things.
Infection Chain (CVE-2025-6218 & CVE-2025-8088)
The multi-stage infection chain used in this campaign is simple, elegant, and annoyingly effective. A key component is the server-side access control logic, which tightly restricts who is allowed to receive further payloads, ensuring that analysts outside the target region receive nothing but empty responses and existential frustration.
1. Initial Access: Web-based Loaders
Entry points include:
HTA attachments
LNK droppers
RAR archives containing HTA or LNK files
And increasingly:
RAR archives exploiting CVE-2025-6218 and CVE-2025-8088
CVE-2025-6218
Vulnerability allowing automatic file extraction into privileged directories
HTA placed into Startup without user execution
CVE-2025-8088
MSHTML execution bypass, circumventing Windows 11 hardening
All these delivery formats share one purpose: download and launch Pteranodon, the central stage-2 loader.
2. Pteranodon Loader
Once the initial dropper executes, it fetches Pteranodon via HTTP(S).
This is where Gamaredon’s C2 firewall kicks in.
Persistence Mechanisms
Pteranodon uses multiple persistence vectors depending on available permissions:
Registry Run keys (HKCU and occasionally HKLM)
Scheduled tasks (5 – 30 minute intervals)
HTA files in the Startup folder
Hidden script copies inside %APPDATA%, %LOCALAPPDATA%, and %PROGRAMDATA%
These ensure the loader survives multiple reboots and can continuously request new tasks and modules.
Communication Structure
Gamaredon’s C2 traffic is distinctive:
XOR + Base64 layering
Pseudo-JSON structures (loose key/value pairs)
Regular tasking requests (download payload, run wiper, USB spread, resend systeminfo)
Operator fingerprints (recurring variable names and patterns)
Pteranodon is intentionally simple, lightweight, and extremely flexible, the malware equivalent of a Russian Lada: It may look primitive, but you’ll be surprised how long it keeps going.
3. Access Control Logic (C2 Firewall)
Gamaredon uses a multi-layered filtering system that serves as both OPSEC and anti-analysis defense.
Purpose of the Access Control Logic
The C2:
only responds fully to Ukrainian IP ranges
verifies browser headers
requires system registration before delivering deeper payloads
This effectively locks out researchers, sandboxes, cloud instances, and… pretty much everyone except the intended victims.
Stages
Stage 1: IP Validation
Non-Ukrainian IP -> HTTP 200 with empty body
Ukrainian IP -> proceed
Stage 2: Header Validation
Must supply correct:
Identifier/Token
User-Agent
Accept-Language
Invalid -> serve a 0-byte file Valid -> proceed
Stage 3: Registration & Tasking
Full payload access only after system registration:
hostname
username
local IP
environment
token
Then the C2 provides:
USB/network spread modules
Wipers
Persistence modules
Stealers
Additional droppers
The basic access control logic looks like this:
4. Campaign Characteristics
Strict Ukraine-only geo-fencing
Strong anti-analysis (empty responses instead of errors)
High variation of initial access files
Consistent use of Pteranodon
Increased abuse of RAR + CVE-2025-6218
Multiple drops per day
Analysis
This article focuses more on mapping the infrastructure than on deep reverse-engineering. If you want in-depth Stage-1 payload analysis, check my previous article.
Once the malicious attachment is executed, it contacts a remote Gamaredon domain and retrieves Pteranodon.
Key observations from sandboxing
Most sandbox environments receive empty responses, expected due to the C2 filtering
Simulating headers alone is insufficient
Regular Ukrainian proxies also fail
Rotating Ukrainian residential proxiesdo work
However, deeper stages require successful registration, which makes automated extraction time-consuming
After bypassing the filters, we obtained obfuscated HTAs containing Base64-encoded VBS Code.
These loaders then fetch:
Pteranodon
wiper modules
auxiliary droppers
etc.
All files are provided in the sample table for further analysis.
Telegram & graph.org C2 Distribution
Gamaredon uses:
Telegram channels for rotating C2 IPs and cryptographic material
graph.org pages for rotating payload URLs
Both platforms are:
ideal for operations requiring frequent updates
highly resilient
hard to take down
https://graph.org/vryivzphxwc-11-11
If you are a doing legit malware research interested in tracking, feel free to write me an email.
Fast-Flux Infrastructure (194.67.71.0/24)
One IP stood out: 194.67.71.75, belonging to REG.RU, a well-known high-abuse Russian hosting provider.
Findings:
200+ IPs in the subnet engaged in coordinated port-scanning against Ukrainian targets (April 2025)
44,157 PassiveDNS entries for the 256 hosts
39,903 unique domains
Typical Fast-Flux characteristics:
extremely short TTL
rapid IP rotation
each IP hosting dozens of unrelated domains
low-quality disposable domain patterns
consistent abusive behavior
This subnet is:
clearly Russian-controlled
used for offensive operations
structurally similar to GRU-affiliated infrastructure
highly likely to be connected directly or indirectly to the FSB
I built a graph on VirusTotal to visualize the malware distribution by the subnet:
NOTE: By clicking ‘Load content’, you consent to data being transmitted to a third-party provider in the United States. Please note that US data protection standards differ from those in the EU.
Changes in the 2025 Gamaredon Campaign
Compared to 2021 – 2024, the 2025 operation shows significant evolution:
1. Zero-Click via CVE-2025-6218
RAR-based exploit allows silent execution with no user interaction.
2. RAR-First Delivery
RAR replaced HTA/LNK as the primary attachment format.
3. More complex access control
Geo-fencing, header checks, registration tokens, and multi-stage filtering.
Better registry/task persistence and more aggressive lateral movement.
Summary
The 2025 Gamaredon campaign is no longer just “phishing with extra steps” It has evolved into a modular, highly dynamic, multi-infrastructure malware ecosystem, powered by:
Zero-click exploits
Geo-fenced C2 delivery
Fast-Flux DNS
Telegram distribution
graph.org rotation
Persistent Pteranodon loaders
…all wrapped in a design philosophy best described as: “If it works, ship it, if it breaks, wrap it in Base64 and ship it anyway.”
MITRE ATT&CK Mapping
The current Gamaredon campaign maps to a wide range of relevant MITRE ATT&CK techniques. Below is a consolidated overview of the most important tactics and techniques observed during the various stages of the operation: (Click To Open)
TA0001 – Initial Access
T1566.001 – Phishing: Spearphishing Attachment Distribution of HTA, LNK, and RAR attachments using thematically relevant document names.
T1204.002 – User Execution: Malicious File Execution of HTA/LNK loaders, or automatic execution via CVE-2025-6218.
TA0002 – Execution
T1059.005 – Command and Scripting Interpreter: Visual Basic Extensive use of HTA and VBScript for initial loader execution.
T1059.001 – Command and Scripting Interpreter: PowerShell Used to download and run Pteranodon modules.
T1203 – Exploitation for Client Execution CVE-2025-6218 enabling automatic HTA placement and execution (zero-click).
TA0003 – Persistence
T1547.001 – Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder Persistence achieved via HTA scripts placed in the Startup folder and registry autostarts.
T1053.005 – Scheduled Task/Job Creation of scheduled tasks that periodically re-execute Pteranodon or supplemental scripts.
TA0004 – Privilege Escalation
(No explicit privilege escalation techniques observed; Gamaredon typically operates under user-level permissions.)
TA0005 – Defense Evasion
T1027 – Obfuscated/Encrypted Files and Information Heavy use of BASE64 and XOR layers to obfuscate code and communications.
T1497 – Virtualization/Sandbox Evasion C2 access-control (IP/header validation) to prevent payload delivery to researchers or sandboxes.
T1070 – Indicator Removal on Host Wiper/cleanup scripts remove MRUs, registry traces, and startup entries.
TA0006 – Credential Access
(Seen in earlier Gamaredon campaigns; less prominent in 2025.) T1552.001 – Unsecured Credentials: Credentials in Files Some modules harvest document contents and autocomplete data.
TA0010 – Exfiltration
T1041 – Exfiltration Over C2 Channel Hostnames, usernames, system metadata, and environment details sent directly to C2.
TA0011 – Command and Control
T1071.001 – Application Layer Protocol: Web Protocols C2 communication over HTTP/HTTPS.
T1102.002 – Web Service: Telegram Use of Telegram channels for dynamic IP rotation and distribution of secrets/tokens.
T1102 – Web Service (graph.org) Use of graph.org pages for periodically rotating payload URLs.
T1568.002 – Dynamic DNS Frequent use of DynDNS for rotating C2 domains.
T1090 – Proxy Fast-Flux infrastructure in subnet 194.67.71.0/24 used to proxy malicious infrastructure.
TA0009 – Collection
T1119 – Automated Collection Immediate collection of system information after Pteranodon’s initial registration.
TA0008 – Lateral Movement / Propagation
T1091 – Replication Through Removable Media USB-based propagation (a long-standing Gamaredon tactic).
T1021 – Remote Services(limited) Some modules show capability for internal network spread.
High-Level Indicators for Threat Hunters
This section summarizes the most important behavioral indicators that SOCs, threat hunters, and CERT teams can use to detect Gamaredon activity early. These are high-level detection patterns rather than sample-specific IOCs
1. Network Indicators
HTTP requests from mshta.exe or powershell.exe to DynDNS domains, graph.org pages, or Ukrainian/Russian subnets
Repeated GET requests resulting in 0-byte responses
Outbound traffic to 194.67.71.0/24 (REG.RU Fast-Flux cluster)
Unexpected connections to Telegram API/channels without active user sessions
Very low DNS TTL values for domains rotating across many IPs
2. File System Indicators
Presence of suspicious script files:
HTA/VBS in the Startup folder: %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\*.hta
Dropped PowerShell/VBS files in:
%APPDATA%
%LOCALAPPDATA%
%PROGRAMDATA%
Files with pseudo-legitimate names such as Update.hta, Sync.hta, etc.
How a Russian Threat Actor Uses a Recent WinRAR Vulnerability in Their Ukraine Operations
Today we’re taking a look at several malware samples from the advanced persistent threat group “Primitive Bear” aka “Gamaredon”.
Primitive Bear is a Russian state-sponsored Advanced Persistent Threat (APT) group that has been active since at least 2013. With high confidence, the group is attributed to the Federal Security Service of the Russian Federation (FSB), Russia’s domestic intelligence service.
The most recently circulating malware samples caught my attention because they all follow the same pattern and exploit a newly disclosed vulnerability CVE-2025-6218 to load additional malware in later stages.
In this post, I want to walk you through the methodology and the infrastructure used by the attacker.
Below is an overview of the samples I analyzed that make use of CVE-2025-6218, along with their origin. I will continue analyzing additional samples in order to map the attacker’s infrastructure as comprehensively as possible.
Повістка про виклик_357-16230-25_24.10.2025.pdf:.._.._.._.._.._.._AppData_Roaming_Microsoft_Windows_Start Menu_Programs_Startup_357-16230-25_24.10.2025.HTA
Щодо надання інформації (військова частина А0135_11-967_11.11.2025).pdf:.._.._.._.._.._.._AppData_Roaming_Microsoft_Windows_Start Menu_Programs_Startup_11-967_11.11.2025.HTA
Перегляд підходів до призову під час мобілізації_2-3716-25_07.11.2025.pdf:.._.._.._.._.._.._AppData_Roaming_Microsoft_Windows_Start Menu_Programs_Startup_2-3716-25_07.11.2025.HTA
Запит на отримання інформації командира військової частини А0135_11-967_10.11.2025.pdf:.._.._.._.._.._.._AppData_Roaming_Microsoft_Windows_Start Menu_Programs_Startup_11-967_10.11.2025.HTA
Передати засобами АСУ Дніпро_2_1_1_7755_11.11.2025.pdf:.._.._.._.._.._.._AppData_Roaming_Microsoft_Windows_Start Menu_Programs_Startup_2_1_1_7755_11.11.2025.HTA
Передати засобами АСУ Дніпро_2_1_1_7755_12.11.2025.pdf:.._.._.._.._.._.._AppData_Roaming_Microsoft_Windows_Start Menu_Programs_Startup_2_1_1_7755_12.11.2025.HTA
Передати засобами АСУ Дніпро_3_8_2_7442_13.11.2025.pdf:.._.._.._.._.._.._AppData_Roaming_Microsoft_Windows_Start Menu_Programs_Startup_3_8_2_7442_13.11.2025.HTA
Передати засобами АСУ Дніпро_2_7_4_62_13.11.2025.pdf:.._.._.._.._.._.._AppData_Roaming_Microsoft_Windows_Start Menu_Programs_Startup_2_7_4_62_13.11.2025.HTA
The campaign I observed clearly targets Ukrainian entities, something we can identify mainly by the filenames used:
Original Filename
English Translation
Повістка про виклик_357-16230-25_24.10.2025.pdf
Subpoena_357-16230-25_24.10.2025.pdf
Щодо надання інформації (військова частина А0135_11-967_11.11.2025).pdf
Regarding the provision of information (military unit A0135_11-967_11.11.2025).pdf
Перегляд підходів до призову під час мобілізації_2-3716-25_07.11.2025.pdf
Review of approaches to conscription during mobilisation_2-3716-25_07.11.2025.pdf
Запит на отримання інформації командира військової частини А0135_11-967_10.11.2025.pdf
Request for information from the commander of military unit A0135_11-967_10.11.2025.pdf
Передати засобами АСУ Дніпро_2_1_1_7755_11.11.2025.pdf
Transfer via automated control system Dnipro_2_1_1_7755_11.11.2025.pdf
Передати засобами АСУ Дніпро_2_1_1_7755_12.11.2025.pdf
Transfer via automated control system Dnipro_2_1_1_7755_12.11.2025.pdf
Передати засобами АСУ Дніпро_3_8_2_7442_13.11.2025.pdf
Transfer via automated control system Dnipro_3_8_2_7442_13.11.2025.pdf
Передати засобами АСУ Дніпро_2_7_4_62_13.11.2025.pdf
Transfer via automated control system Dnipro_2_7_4_62_13.11.2025.pdf
Primitive Bear is well-known for its spear-phishing operations, so none of this is surprising. What is new, however, is the use of RAR archives to load additional malware. Unfortunately, we cannot definitively identify all recipients of these samples, but the filenames give us a pretty good idea of who they were intended for:
File
Probable recipient / Context
Derived from the name
Повістка про виклик_357-16230-25_24.10.2025.pdf
Authorities/judiciary or territorial recruitment centers (ТЦК та СП) for mobilization
“Повістка” can mean court/investigative authority or military summons.
Щодо надання інформації (військова частина А0135_11-967_11.11.2025).pdf
Military Unit A0135 (Військова частина А0135)
explicit mention of the unit
Перегляд підходів до призову під час мобілізації_2-3716-25_07.11.2025.pdf
Mobilization/personnel offices: ТЦК та СП, Mobilization Department in the MoD/General Staff
Thematic focus: “Approaches to convening”
Запит на отримання інформації командира військової частини А0135_11-967_10.11.2025.pdf
Commander of military unit A0135
explicitly addressed
Передати засобами АСУ Дніпро_2_1_1_7755_11.11.2025.pdf
Positions with access to “АСУ Днепр” (АСУ = Automated Management/Information Systems) This is typically MoD/ТЦК/Human Resources
“Transmit via ASU Dnipro” -> internal administration/data channel
Передати засобами АСУ Дніпро_2_1_1_7755_12.11.2025.pdf
as above
Series/sequel document (different date)
Передати засобами АСУ Дніпро_3_8_2_7442_13.11.2025.pdf
as above
other internal classification/filing codes
Передати засобами АСУ Дніпро_2_7_4_62_13.11.2025.pdf
as above
Now that we better understand the context of the samples, we can dive into the actual analysis. Since all samples share a nearly identical structure, we’ll look at the most recent one found, with the hash 237696ecc370688a8d1894eb2f95af53a3c0f8d42eb540b7f529b4d4f4492bc0
The victim receives a RAR archive containing two files: a fake PDF and a HTML Application (HTA). The HTA file always has the same bizarre naming scheme:
This immediately reveals the exploitation of CVE-2025-6218.
The vulnerability is a critical directory traversal -> remote code execution (RCE)flaw in WinRAR (up to version 7.11) on Windows. The bug lies in how RAR archives process file paths: an attacker can craft an archive entry that writes files outside the intended extraction folder e.g., directly into the user’s Startup directory.
Once a file lands in an auto-executed location, it runs on next login or reboot, resulting in RCE with the current user’s privileges. It still requires user interaction, such as opening a malicious archive. The issue is fixed in WinRAR 7.12 (Beta 1) and later.
If you want to get a feeling for the vulnerability, a PoC is definitely worth looking at.
So what actually happens when the victim opens the RAR file?
The user opens the archive.
The archive extracts a .pdf into the current directory.
The archive silently extracts an .hta containing obfuscated VBScript into the Startup folder.
After reboot, the VBScript fetches additional malware.
It’s worth noting that the exploitation of CVE-2025-6218 requires only minimal user interaction. In most cases, the victim merely has to open the malicious RAR archive. No special system configuration is required, no sandbox needs to be disabled, and no “advanced mode” must be enabled. WinRAR’s default extraction behavior is sufficient for the path traversal to write an HTA file directly into the user’s Startup folder.
long story short: the attacker relies only on the victim doing what victims do best, double-clicking whatever lands in their inbox.
Now let’s take a look at what such an HTA file actually looks like:
We see an obfuscation attempt that is, let’s put it politely, more bad than good. Between the actual payload there’s a lot of junk lines:
These can be filtered out easily by looking at each assigned variable. If a variable never gets used or only references itself, it can be safely removed. I did the cleanup manually, because the scripts are tiny and the obfuscation is by no means a masterpiece.
After removing the junk lines and renaming the important variables, I ended up with the following result:
The entire deobfuscation process took about five minutes. The script isn’t complex, so let’s walk through it.
The string pretends to be a legitimate Windows component.
Using mshta.exe is classic: this Windows binary can directly execute remotely hosted HTA/HTML scripts, a typical Living-off-the-Land Binary (LOLBIN) abuse.
president.gov.ua@ looks like an official Ukrainian domain
the real host is readers.serveirc.com, a free DynDNS subdomain acting as C2 or malware hosting server.
3. It executes the payload silently
wshell.Run payload
4. Error suppression
On Error Resume Next
Runtime errors are ignored to avoid crashes or prompts.
5. It closes itself
Close
The script exists purely as a loader/downloader. No real payload is inside, instead it fetches the actual malware (another HTA, VBS, or EXE) from readers.serveirc.com.
This aligns perfectly with Primitive Bear’s usual TTPs:
multi-stage payload chains ending in backdoors for surveillance and exfiltration (e.g., Pteranodon, GammaLoad)
abuse of Windows-native binaries (mshta.exe, wscript.exe)
phishing documents themed around Ukrainian government topics (e.g., “повістка.pdf”)
fast-changing C2 infrastructure on free DNS services (serveirc.com, myftp.biz, ddns.net)
Primitive Bear’s operations often end in the deployment of modular backdoors such as Pteranodon or GammaLoad, both of which are staples of the group’s espionage toolkit:
Pteranodon: A long-running backdoor family used by Primitive Bear since at least 2016. It supports classic cyber-espionage features such as screenshot capture, file exfiltration, keystroke logging, command execution, and staged payload delivery. Modular, noisy, but effective enough for long-term access.
GammaLoad: A lightweight downloader/backdoor frequently used as the “next stage” after initial compromise. Typically retrieves secondary modules, maintains C2 connectivity, and prepares the system for more persistent implants. Often deployed through simple LOLBIN-based loaders (like the one used here).
Nothing revolutionary, just FSB’s usual grab-bag of surveillance toys 😉
Infrastructure used in the 2025 Ukraine Campaign (so far)
Throughout my analysis, I reviewed a large number of recent samples (October – November) from this threat actor. Below is a summary and visualization of the infrastructure I identified.
The actor makes heavy use of DynDNS subdomains, such as:
readers.serveirc.com
dears.serveirc.com …and many others
All of these can be attributed to No-IP, which gives us a pool of recurring IP addresses (including IPs not associated with a Dyn-DNS domain name):
IP-Address
Provider
Country
194.58.66.5
BAXET-GROUP-INC – interlir.com
India
194.58.66.132
BAXET-GROUP-INC – interlir.com
India
194.58.66.192
BAXET-GROUP-INC – interlir.com
India
194.87.240.141
relcom.com
Czech Republic
194.87.230.166
BAXET-GROUP-INC – interlir.com
Greece
194.87.240.215
relcom.com
Czech Republic
185.39.204.82
globconnex.com
Turkey
45.141.234.234
globconnex.com
Ireland
5.8.18.46
Putin
Russia
Some of these IP addresses are provided by InterLIR, including the realcom addresses. InterLIR is essentially an IP address marketplace: companies in need of IPv4 or IPv6 space can buy, rent, or sub-lease unused ranges. The platform advertises fast provisioning, legally vetted transfers, and a European business focus.
Since IPv4 addresses are scarce (and expensive), entire micro-economies have formed around services like this, which attackers happily exploit for disposable infrastructure.
I also rechecked which of the domains still resolve to an active host. During that process, I identified fourteen domains that are currently still active and are likely still being used by the threat actor.
acess-pdf.webhop.me
backup.9fvzesn.us
creates.webhop.me
dears.serveirc.com
digitall.webhop.me
dilopendos.serveirc.com
fixer.serveirc.com
google-pdf.redirectme.net
hosting-redirect.sytes.net
political-news.serveirc.com
freedynamicdns.net
readers.serveirc.com
serversftp.serveirc.com
yeard.serveirc.com
Based on the information available so far, we can also compile a final overview of the files that have been distributed through this infrastructure:
This is not the full list of distributed files in this campaign, but i’ll keep track of further samples and update the list accordingly.
Recommendations for Defenders and Blue Teams
To mitigate and detect this campaign (and similar WinRAR-based exploitation attempts), i recommend the following defensive measures:
Update WinRAR immediately Ensure that WinRAR is updated to version 7.12 (Beta 1) or later, where CVE-2025-6218 has been patched.
Block execution of HTA files In most enterprise environments, .hta files should not be executed at all. Enforce this via AppLocker, WDAC, or enterprise GPO restrictions.
Monitor for LOLBIN misuse Flag suspicious executions of:
mshta.exe
wscript.exe
powershell.exe (especially with remote URLs)
Monitor the Startup folder Creation of .hta, .vbs, .js, or unknown executables inside: %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup …should always be treated as high-severity alerts, alway have an eye on this lol.
Inspect email attachments Particularly RAR/ZIP archives containing unusual path structures or files with “hidden extensions” (file.pdf:.hta, etc.).
Network defense Block known C2 domains and sinkhole DynDNS-based infrastructure where possible.
Endpoint logging Ensure Sysmon or a comparable EDR solution logs:
Process creation
File modification in Startup paths
Network connections from LOLBINs
Suspicious command-line parameters
Basically: watch for anything that behaves like Windows, but shouldn’t ^-^
