Donot Team Leverages New Modular Malware Framework in South Asia
Authors: Dennis Schwarz and Jill Sopko
Special thanks to Richard Hummel and Hardik Modi for their contributions on this post.
- ASERT discovered a new modular malware framework, we call yty, that focuses on file collection, screenshots, and keylogging.
- We believe the threat actors, Donot Team, who created EHDevel, also created the yty framework.
- With medium confidence, ASERT believes this new malware framework will pick up where EHDevel left off and continue to focus on targets in South Asia.
In late January 2018, ASERT discovered a new modular malware framework we call “yty”. The framework shares a striking resemblance to the EHDevel framework. We believe with medium confidence that a team we call internally as “Donot Team” is responsible for the new malware and will resume targeting of South Asia.
In a likely effort to disguise the malware and its operations, the authors coded several references into the malware for football—it is unclear whether they mean American football or soccer. The theme may allow the network traffic to fly under the radar.
While we believe this framework and its components are new, it shares many Tactics, Techniques, and Procedures (TTPs) and Indicators of Compromise (IOCs) with the EHDevel malware framework. In September 2017, Bitdefender released a white paper describing EHDevel and some of the campaigns that used it. Some of the highlights of it included the following:
- Labeled as an APT (advanced persistent threat) and active since at least 2016.
- Modular architecture with malware functionality spread over multiple components.
- Components used a variety of programming languages (C++, .NET, Python, VBS, and AutoIt).
- Functionality included: file collection, screenshots, key logging, and gathering system information.
- Command and control (C2) hosts stored in a document hosted on Google Docs.
- Decoy documents, timestamp analysis, and C2 server log analysis showed a focus on Pakistan.
We assess with medium confidence that the yty framework is a replacement for the EHDevel framework and that the Donot Team may start using it in campaigns in a similar manner as EHDevel.
The evolution from EHDevel to yty shows the threat actors are continually improving and modifying their malware framework, adding to their sophistication.
Donot Team campaigns use multiple methods to mimic legitimate applications, organizations, and services like Adobe, Gmail or news outlets. They also including seemingly benign domains that likely raise minimal suspicion to a human observer. The following domains are a few examples:
- Adobe update services
- Gmail webmail service
- Generic services domains
- Mimics weekly English-language newspaper in Sri Lanka
- English version of the national daily newspaper in Bangladesh
The actors use false personas to register their domains instead of opting for privacy protection services. Depending on the registrar service chosen, this could be seen as another cost control measure. The actors often used typo-squatting to slightly alter a legitimate domain name. In contrast, the registration information used accurate spelling, possibly indicating the domain naming was intentional, typos included. Each unique registrant usually registered only a few domains, but mistakenly reused phone numbers or the registration data portrayed a similar pattern across domains. Looking at shared IP infrastructure, it was easy to see the registration patterns and expand the network used by the attackers.
The Donot Team relies heavily on subdomains. Nearly every domain discovered through the course of this investigation had multiple, unique subdomains and every malware sample analyzed communicated to subdomains. In at least two instances, the domain never resolved to an IP address. Instead, the malware used subdomains, which lead to active infrastructure.
Many of the sub-domains only navigated to the third level, but other samples used overly complex subdomain structures down to the sixth or seventh level.
Looking at registration patterns and passive DNS, many of these domains resolve for as little as three days before going offline. It is possible the attackers use these small windows to test their malware operations.
Although we did not observe the original distribution of the core binary, we believe the group specifically targeted Pakistani individuals based on the decoy documents observed. They appeared to be official Government of Pakistan memos, see Figure 1, above.
Donot Team’s TTPs, infrastructure, and the malware code are strikingly similar to the EHDevel malware reported by BitDefender and is likely the same group of operators. Bitdefender noted that the EHDevel malware appeared similar to malware analyzed by Blue Coat Labs in their report “Snake in the Grass”. The “Snake in the Grass” report also showed malware similarities and infrastructure overlap with Operation Hangover (also known as the Patchwork Group). While Arbor agrees that there are suspicious similarities between the Donot Team and Patchwork, we did not uncover definitive evidence to link the two groups. Additionally, a malicious document associated with yty was tagged by Hybrid Analysis as “Viceroy Tiger”, but there hasn’t been much recent public information on this group that we could find to corroborate.
yty Malware Framework Analysis
One of the TTPs associated with the Donot Team is the use of modular/plugin-based malware frameworks. We call the new malware framework “yty” (based on debugging strings in its components). The components of the framework are shown in Figure 2:
The first piece of the framework is a malicious Excel document named “Cirular.xls” (9ce56e1403469fc74c8ff61dde4e83ad72597c66ce07bbae12fa70183687b32d). The content of the spreadsheet is an executable that is extracted and executed by macros, Figure 3.
The delivery mechanism for the XLS file is unknown, but evidence suggests it could be a test document as seen in Figure 4:
.exe (Downloader 1) Analysis
Compilation Date: 2018-02-05 09:06:13
PDB Path: C:\Users\donot\Documents\Visual Studio 2010\Projects\downloader\Debug\downloader.pdb
Due to a bug in the macro code, the extracted executable is saved as “.exe”. This is a stripped down C++ program that, as its PDB path string indicates, downloads and executes another executable, then removes itself. The downloader attempts to retrieve and execute the following file (not active at the time of research):
- This host is a direct overlap with the EHDevel malware framework as it was also seen distributing payloads in Bitdefender’s analysis.
Setup.exe (Downloader 2) Analysis
Compilation Date: 2018-01-04 09:43:28
PDB Path: C:\Users\803\Desktop\ytyboth\yty 2.0\Release\Setup.pdb
Setup.exe is another downloader written in C++ but contains more functionality than the “.exe” downloader. First, it checks/creates a mutex named “toptwo” so that only one copy of itself is running on the victim.
To confuse malware analysts, it mixes in junk code as seen in Figure 5.
It also has some basic anti-sandbox detection that tries to detect Virtual PC, Sandboxie, and VMware (example in Figure 6):
Similar to some components in the EHDevel framework, it creates logs for debugging purposes, though the messages are not as verbose as in EHDevel’s samples, Figure 7.
Command & Control
Much like EHDevel, in order to get its C2 host, it downloads a file from Google Docs. The document in this case was located at:
At the time of research, the name of the document was “ip2.txt” and it contained the following IP address:
Per its metadata, the owner of the document is:
- Alfred Vilfi
An example C2 beacon is show in Figure 8:
Based on the “/football/goal”, “score”, “ball”, and “loose” strings they are using a football theme to help disguise its traffic. The POST data contains:
- CPU information
- Windows version
- Is a virtual machine?
- Computer name
- User name
- Serial number of main disk volume
At the time of analysis, we only elicited a “loose” response from the C2 server. Continued execution is reliant on eliciting a “win” response. If a “win” response does not occur, the malware continues beaconing until it receives the appropriate response. Once the correct response is seen, the malware downloads the next component from the same C2 using the following URL path:
A secondary macro in circular.xls establishes persistence for the setup.exe download as seen in Figure 9.
Setup.exe introduces three common names seen in the rest of the malware framework:
- “yty”, the name we use for the framework, from the PDB path string.
- “bigdata” from the schtasks /tn (taskname) parameter used in the persistence mechanism.
- A “bot id” consisting of computer name, user name, and volume serial number separated by dashes.
boothelp.exe – Plugin Downloader
Compilation Date: 2018-01-03 09:42:00
PDB Path: C:\Users\803\Desktop\ytyboth\yty 2.0\Release\boothelp.pdb
Another TTP used by the Donot Team is the transition from one programming language to another. We see this with boothelp.exe, which is written in .NET–instead of C++ like the other components. boothelp.exe is a downloader responsible for retrieving modules/plugins that contain added functionality.
The plugin downloader uses the same C2 channels as setup.exe by downloading a Google Doc file which contains the C2 IP address. It then continues the football theme by beaconing to the “/football/flag” folder on the C2 server, Figure 10.
Using an HTML <div> element labeled “pcinfo”—possibly displayed verbatim in the C2 panel—the malware beacon message contains various pieces of system information outlined below:
- User name
- Computer name
- Windows version
- Number of processors
- System directory
- Domain name
- .NET version
- Information on drives
- CPU information
The response from the C2 is an odd string containing multiple pieces, delimited by various characters, but boils down to what plugins to download/run and their file sizes. The plugins for this framework were downloaded from the same URI path (“/football/download/2/”) where boothelp.exe was located. As of February 2018, we observed the following plugins:
- vstservice.exe – document listing plugin
- abode.exe – file exfiltration plugin
- mdriver.exe – key logger plugin
- dspcheck.exe – screenshot plugin
- mboard.exe – system information plugin
These modules share functionality with components of the EHDevel framework, creating further overlap between the two malware frameworks. boothelp.exe has an interesting but unused function that takes a list of benign URLs and opens connections to them. As noted previously, we believe the actors are still testing the malware framework and it’s possible these URLs will become an anti-analysis feature to hide C2 communication among benign traffic. Some of the interesting benign URLs listed below:
vstservice.exe – File Listing Plugin
Compilation Date: 2018-01-03 08:14:32
PDB Path: C:\Users\803\Desktop\ytyboth\yty 2.0\Release\vstservice.pdb
The vstservice.exe plugin is .NET file responsible for sending a list of the file system to the C2. The malware retrieves the C2 from a Google Docs file like the previous binaries. The file was located at the following location:
At the time of research, the Google Doc was named “domain.txt” and contained the following C2 host:
Per its metadata, it is owned by the same owner as the document above.
The plugin sends two file listings. The first one focuses on files with the following extensions:
The second one contains all other files. An example is shown in Figure 11.
The URL path for this C2 references the “bigdata” string observed in the macro persistence mechanism. Some of the POST parameters are unclear, but contain the following items:
- status – hardcoded to “Found”
- path – hardcoded to “Unknown”
- pc – bot ID
- type – unclear
- fname – file name
- cnumber – a number representative of large files broken into chunks
- orname – unclear
- ofid – order ID for files broken into chunks
Similar to the plugin downloader, this plugin includes an unused function that connects to benign URLs. Some of the URLs are listed below:
abode.exe – File Exfiltration Plugin
Compilation Date: 2018-01-03 08:14:46
PDB Path: C:\Users\803\Desktop\ytyboth\yty 2.0\Release\abode.pdb
abode.exe is a .NET file capable of file exfiltration. It uses the same Google Doc document and C2 as the vstservice.exe plugin. Two sets of files can be exfiltrated. The first set is a periodic sending of files generated by other plugins that do not include a C2 mechanism themselves. The second set of files is specified by the C2 as seen in Figure 12.
The “id” parameter is hardcoded and the “pc” parameter is the bot ID. The file is then sent to the C2 as seen in Figure 13.
This plugin also includes unused, benign URLs as seen below:
mdriver.exe – Keylogger Plugin
Compilation Date: 2018-01-03 08:14:19
PDB Path: C:\Users\803\Desktop\ytyboth\yty 2.0\Release\mdriver.pdb
This plugin is written in C++ and is a key logger. It checks/creates a mutex named “twotwo“, uses the Windows SetWindowsHookEx and SetWinEventHook APIs to perform its key logging, and then relies on abobe.exe to exfiltrate the captured key strokes. Figure 14 shows an example of exfiltrated key log data.
dspcheck.exe – Screenshot Plugin
Compilation Date: 2018-01-09 08:33:36
PDB Path: D:\Soft\DevelopedCode\yty 2.0\Release\dspcheck.pdb
dspcheck.exe is a screenshot plugin written in .NET. This plugin also shows evidence that the actors are continuing their testing efforts as seen in Figure 15.
It has the beginnings of C2 functionality, but this sample still relies on abobe.exe to send screenshots back to the C2, see Figure 16.
mboard.exe – System Information Plugin
Packed SHA256: 50281cdd1b22f2b85de5809bf69ebd10e399410f519e357c1cb941c5dc7c95e1
The last plugin seen in this framework was mboard.exe. It is written in Golang and is packed with UPX. The purpose of this plugin is to gather various system information such as the following:
- Drive information
- Output of systeminfo command
- Installed software
- Output of ipconfig /all command
- Output of net view command
- Output of tasklist command
The collected is saved into multiple files with a “qr” extension appended. They are then sent to the C2 via abobe.exe. An example showing the running process list being sent to the C2 is shown in Figure 17.
Appendix A (IOCs):
C2 IP Addresses