by Robin Dost
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.
SHA256: 6de9f436ba393744a3966b35ea2254dde2f84f5b796c6f7bee4b67ccf96ccf0a
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.:
wmvyuvlgcrmjpeg
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
GETrequests
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.
Effective?
Yes.
Elegant?
Debatable 😄
2 Responses to “GamaWiper Explained: Gamaredon’s “New” Anti-Analysis Weapon”