Our previous blog post was a short brief of new Agent.BTZ variants that we found. This second part in the series will demonstrate in greater detail exactly how we discovered these new variants.
To begin, we used our hunting methodology, which consist of four main parts:
- Collection: Collect multiple samples from different versions.
- Analysis: Mark functions that have stayed consistent across all versions that are likely to be a part of the next version.
- Creating a signature: Create a robust yet flexible YARA rule for these functions.
- Hunting: Search a large repository of files with that YARA rule (VirusTotal, for example).
2. Why focus on Agent.BTZ?
We chose to focus on Agent.BTZ for several reasons: First, This is one of the oldest state-sponsored threat, developed and operated by the Turla group since (at least) 2007 for dozens of targeted attacks.
Second, there is also a lot of public knowledge regarding Agent.BTZ specifically and Turla group in general available online, including intel reports, technical analyses and malware samples, which we used for our research.
Third is the fact that this specific malware has remained out of public view for the last two to three years; however, we recognized that it wasn’t likely to disappear–it has just continued to fly under the radar.
3. Do the math
We based our research on an earlier publication from three years ago: “Evolution of sophisticated spyware: from Agent.BTZ to ComRAT” by Paul Rascagnères of GDATA (at the time). In this excellent blog post, Paul described the evolution of Agent.BTZ to ComRAT between 2007-2014 by manually diffing (BinDiff) two different candidates from each major internal hard-coded version (referred by the authors as “Ch” or “PVer”).
The following table shows the code’s similarity between each version to its direct neighbors. By summing up the data in this table we can conclude that, in general, about ~30% of the original code has been used in every version up to the latest known version as of 2014 (marked in red).
Obviously this 30% isn’t comprised of totally unique code made by Agent.BTZ’s developers; rather, it is a mixture made of mostly common code that can be found in many more software products (both legit and malware). For example, these could include C Runtime Library or any other 3rd party library such as zlib. Using Intezer’s technology, we were able to do a ‘deep dive’ into this code, automatically mapping all of the common, library and (most importantly) unique pieces of code created by the malware’s authors.
4. Mysterious magic number
After filtering out all of the common and library code, we were left with several unique functions that can be found in every version of the malware since 2007. The most prominent is the following function:
In the picture you can see the two, almost identical functions from the first version (Ch 1.0) on the right and the latest version (Ch 3.26) of Agent.BTZ on the left. This function is initially reading first four bytes of a given file, and then comparing them for the magic number 0xAAFF1290 (marked in red). If it matches, the function will return true; otherwise, it is false.
So, what is this magic number? Which file is it? We were actually unable to find the function that creates this file within the same binary (ver 3.26). The function shown above is the only reference to that magic number. Luckily, while re-reading old ThreatExpert’s Agent.BTZ analysis from 2008 we happened to notice the following paragraph:
So now we know that this function is used to verify thumb.dd files, which are log/config files leaked over newly-connected USB drives (to overcome air-gapped networks, like those of the Pentagon). But wait… why didn’t we found the function which creates these files? Because the USB-infection vector was removed few years earlier! And yet the adversary is still looking for these valuable thumb.dd files…
5. Hunting for new variants
So far, we know that this function exists, and it has stayed consistent across all versions of the malware; we know what it does (verify certain magic number) and why (detect thumb.dd files leaked from internal network by older versions of the malware). By that information, we can tell that it’s likely to be used in future versions as well.
The next step involves writing a dedicated YARA rule(see appendix) for that specific function and searching for new samples. The rule has to be tolerant to minor changes between versions (mainly due to different compilation flags). Using the VirusTotal Intelligence service, we were able to scan about 2-3 months’ worth of file uploads. As soon as the scan finished, we dug into the results and discovered this first new variant of Agent.BTZ that wasn’t yet mentioned in any public report:
**A screenshot from the Intezer Analyze™ product displaying partial code connections between new sample to old samples of Agent.BTZ(Turla group).
This specific file was supposedly compiled at 2016-07-13 (the timestamp was modified in some of the earlier samples) and uploaded to VT 2017-05-11, which means that this sample is at least two years newer than any previous sample.
6. Main differences between old(3.26) & new samples
- New file names
- activeds.dll – proxy dll
- stdole2.tlb – main payload
- New file names
- AddAtomS removed
- Legacy stub function
- AddAtomT removed
- Legacy installation function
- UnInstallW added
- Force delete file. Used by new dropper for self delete.
- AddAtomS removed
- PVer(internal version tracking)
- random version id(see following picture) instead of incremental,
might be due to GDATA’s 2014 publications.
- For example:
- For example:
- Persistence(COM Hijacking)
- New CLSID
- New CLSID
- C2 Infrastructure
- Both using “Satellite Turla” infrastructure
- Config & Log Files
- Same 512 bytes encryption key as 3.26
- Different file paths:
- config: %appdata%\Microsoft\Windows\PrivacIE\High\desktop.ini
- log: %appdata%\Microsoft\Windows\PrivacIE\High\index.dat
7. Indicators of Compromise