by Robin Dost

---

There’s yet another update in Gamaredons GamaLoad scripts, which pushed me to write this article and to slightly revisit my previous post “Defending Against Gamaredon: Practical Controls That Actually Work“.

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:

3538618e0ae0f7e73d96843d90323178b1d434262a074fc24be8e36283e7dd92

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)
• trivial to detect via signatures and behavior
• operationally noisy (suspicious child processes, script artifacts, obvious telemetry)

BITS lives in a much more comfortable gray zone:

• it supports persistent and robust downloads
• 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.

Is This a Problem?

Not really.

In my article “Defending Against Gamaredon: Practical Controls That Actually Work”, I now show how you can effectively mitigate BITS abuse without breaking normal business operations.

So yes: Gamaredon adapted.
And yes we’ll adapt again. That’s kind of the point. 🙂