Old Gremlins, new methods

Until recently, Russian-speaking cyber threat actors shared an unspoken rule: do not attack Russian companies. Groups that violated the rule were few and far between, and OldGremlin was one of them. Since spring 2020, when the “gremlins” were first uncovered by Group-IB Threat Intelligence analysts, the hackers have been attacking Russian businesses, including banks, industrial enterprises, medical organizations, and software developers.

According to a Singapore-based cybersecurity company Group-IB, over the past two years OldGremlin has conducted 13 malicious email campaigns. The year 2020 was the most fruitful: ten campaigns, with emails purporting to be from a Russian metallurgical holding, the Belarusian plant MTZ, a dental clinic, and the media holding RBC, nine of which were described in Group-IB’s 2020 report. One more campaign was discovered later in the year.

After the first attacks, it became clear that OldGremlin prepares their phishing emails with great care and monitors the news agenda closely. Their choices for email subjects included remote work during the pandemic, protests in Belarus, and an interview request from a known financial journalist working for a Russian media outlet, called RBC.

Another OldGremlin hallmark is that the group conducts multi-stage targeted attacks using sophisticated tactics and techniques. For example, they did not send their TinyCryptor ransomware directly by email; instead they first obtained remote access to the victim’s machine. The latter was used as a springboard to conduct reconnaissance, collect data, and then move laterally across the organization’s network.

OldGremlin history

OldGremlin launched only one mass phishing email campaign in 2021 (in February), but it was so successful that, apparently, it fueled the gang for the entire year. A few months later, Group-IB team discovered that the February email campaign was the initial entry point and source of a number of attacks. Moreover, last year OldGremlin became the greediest cybergang targeting Russia: they demanded as much as $3 million from one of their victims.

In late March 2022, OldGremlin put themselves on the radar with two malicious email campaigns. As in past attacks, the group bombarded Russian companies with another batch of emails exploiting trending news topics. This time they played the sanctions card, masquerading as representatives of a Russian financial organization.

Given the fact that many international providers of email security products suspended operations on the Russian market, the campaigns of OldGremlin and other threat actors that use email at the initial stage are likely to become more successful and frequent.

Having identified one potential victim (a mining company), Group-IB Computer Emergency Response team (CERT-GIB) warned the company in question about the threat.

In this blog post, Group-IB experts share technical descriptions of OldGremlin’s new attacks and tools and map the group’s main tactics, techniques and procedures (TTPs) to the MITRE ATT&CK™ framework.

March 22 Campaign

A new OldGremlin‘s attack was detected on March 22, 2022. Before the campaign, on March 2, the attackers registered the domain mirfinance[.]org with namecheap, set it up with the public email service Yandex.Mail and sent malicious emails to Russian companies. The use of public legitimate email service sometimes allows the attackers to bypass traditional security systems.

DNS records for mirfinance[.]org. Source: Group-IB Threat Intelligence

“All cards issued in our country [Russia] will no longer work,” the phishing email said and prompted the recipients to urgently issue a new banking card and link it to the bank payroll.

OldGremlin’s phishing email from the March 22 campaign

To have a new payment card “issued”, the client was supposed to read the guidelines and fill out a questionnaire. In reality, the emails contained links to a malicious document stored in Dropbox: hxxps://dl[.]dropboxusercontent[.]com/s/1956cypkkihawuu/Anketa.docx?dl=0. The document looked as follows:

Malicious document stored in Dropbox

It is noteworthy that in February 2021, the threat actor sent emails leveraging a malicious document containing a similar Office 365 image. The campaign affected multiple companies, and OldGremlin is still reaping the benefits, as they are known for dwelling in the victims’ infrastructure for a long time before proceeding to the next stage.

To return to the recent attack, the infection scheme is presented below for clarity:

OldGremlin’s March 22 attack

Once opened, the document loads a template located at hxxps://dl[.]dropboxusercontent[.]com/s/gjyjs0rbtihy7ue/Doc1.dotm. The template contains a macro that performs the following actions:

1. Copies the original file (Anketa.docx) to the path %TEMP%\docx1.zip.
2. Extracts an executable file from the archive embedded in the original document to the path %TEMP%\word\media\image2.jpg, renames the file to image2.exe and launches it.
3. Displays an error and closes the document.

The archive contained the group’s new tool, which — judging by the PDB string — the developer named TinyFluff. TinyFluff is a successor to the gang’s custom backdoor called TinyNode, which OldGremlin used as the primary downloader for receiving and running malicious scripts. The purpose of TinyFluff was to launch the interpreter Node.js on the infected device and grant remote access to it (a detailed description of the interpreter can be found in the “Tools” section).

The key features of this version of TinyFluff are:

1. The application downloads Node.js from the official website.
2. JavaScript is embedded in the file body.
3. It does not contain a hardcoded command and control (C2) address; instead the application uses DGA.
4. All communication with C2 servers is performed through a DNS tunnel.

Among the generated domains, two definitely belonged to the attackers. The rest were either not registered at the time of analysis or Group-IB experts could not find evidence that they were involved in the attack:

We will return to the table above, but for now we will continue to describe the cyber kill chain. Group-IB’s Managed XDR extracted some of the JavaScripts used in this campaign. In particular, Group-IB detected an interesting — though still “raw” — script with a wide functionality:

• Communication with the C2 server through a DNS tunnel
• Gathering information about infected devices
• Stealing files from infected devices
• Downloading arbitrary files from servers
• Deploying a SOCKS server to proxy traffic
• Executing arbitrary JS code

OldGremlin’s March 25 attack

Three days later, on March 25, the group launched a new campaign, but using a more simplified toolkit. The likely reason for this is that the final script used in the previous attack was not yet ready for full-fledged use in the wild. It required additional testing and additional features. The bad news is that OldGremlin will most likely perfect their script and use it in future attacks.

Unfortunately, Group-IB has not yet uncovered any email samples (if you have received one, please let us know), but our specialists did reconstruct the second attack.

OldGremlin’s March 25 attack

The attack was identified following the analysis of OldGremlin’s infrastructure. Group-IB discovered two LNK files that were associated with the IP address 46.101.113[.]161 (used to resolve NS records for subdomains from the previous malicious email campaign). Both files were located in archives available for downloading from Dropbox:

Group-IB experts believe that the above links were embedded in the emails sent by the group. When launched, the LNK files executed the following commands:

Here is what happened: using WebDAV protocol the threat actors mapped the network drive hxxp://192.248.176[.]138, displayed the decoy document (DopSog_Consultant.docx or Akt_sverki_Consultant.docx), and launched the malicious executable file tf.exe. The decoy documents looked as follows:

Decoy document Akt_sverki_Consultant.docx (Translation: Reconciliation certificate)

Decoy document DopSog_Consultant.docx (Translation: Supplementary Agreement). Obviously, the legitimate company Consultant Plus has nothing to do with documents used in the campaign.

The payload, as you may have guessed, is TinyFluff. Unlike the file used in the March 22 campaign, however, this version does not have a built-in script and does not download the Node.js interpreter from the official website. Instead, the application copies both the script and the interpreter from its own current location, i.e., from the network drive 192.248.176[.]138.

The final-stage script is much simpler than the above version. It lacks both DGA (the IP address 46.101.113[.]161 is specified as C2) and data encryption. In fact, all communication between the Trojan and C2 could be viewed using an ordinary traffic sniffer.

Group-IB experts retrieved several JS commands that were executed on the infected device. They were all designed to obtain information about an infected device. They even included CMD commands (as described in the corresponding section).

Tools used by OldGremlin group

TinyFluff

As mentioned above, Group-IB experts detected two versions of TinyFluff:

Let’s begin with the tf.exe file (SHA1: c82e12e563d5d5f4a8dd67703b5df7373b457abc) as the tool is much simpler than its predecessor. Once launched, the application creates the directory %APPDATA%\%MachineGuid%, where %MachineGuid% is the registry value for HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MachineGuid. If the directory already exists, the application terminates itself. The application copies the interpreter Node.js (node.exe) and the malicious script s.txt to the created directory. The script is heavily obfuscated, but if it can be run then there is no need to waste time on de-obfuscation because the obfuscated layer restarts Node.js and passes a “clean” script to it as an argument.

How Group-IB Managed XDR’s module called Malware Detonation Platform lays the attack

As seen in the screenshot, the argument of the second node.exe process is a script without obfuscation. Its functionality is simple: it connects to the address 46.101.113[.]161:80, passes the format identifier /{0.[0-9]*/}, receives the command in a loop, and executes it (using the function eval). The commands are described in detail in the relevant section.

Although the second version of TinyFluff (SHA1: bd0a6a3628f268a37ac9d708d03f57feef5ed55e) was discovered earlier (and the compilation date is more recent), it is more sophisticated. Just like the previous version, it places the script and the interpreter in the directory %APPDATA%\%MachineGuid%. However, the interpreter is downloaded from the official website: http://nodejs.org/dist/latest-erbium/win-x86/node.exe, and the malicious script is located in a resource of the executable file named TXT. As in the above case, the de-obfuscated script can be obtained from an argument of the node.exe child process:

Source: Group-IB Managed XDR

This time the script is more complicated. For example, it doesn’t have a built-in C2 list. Instead, the script uses DGA:

For each domain, the script generates a subdomain in the format [0-9a-f]{4}.[0-9a-f]{8}.%dga_domain%, creates a DNS query, and receives a TXT record. The tool carries out all communication through a DNS tunnel, which means that all the data transmitted by the Trojan is in a subdomain and the server’s response is in a TXT record. We will not dwell on this any further as we believe that all interaction with the server occurs in this way.

The script verifies the digital signature of the received data using the function crypto.verify with the base64-encoded key MCowBQYDK2VwAyEAgp0p9o6lg/ZZ3WUJtx7UBBb1qYMZEDNC19Hbb84wt88= (in DER format). If the signature is valid, the script generates a bot identifier (a number from 0 to 1), after which it requests a command from the C2 server in a loop. The response is obfuscated. De-obfuscation is performed as follows:

1. Data is Base64-decoded.
2. Data is decrypted using the RC4 algorithm (in such requests, the key is %id%.%dga_domain%, which is the domain to which a connection was made).
3. The decrypted data is decompressed using the gzip algorithm.

The above described algorithm is used to de-obfuscate all traffic between the malware and the C2 server, with only the key changing (going forward we will therefore only say that the data is de-obfuscated using a given key). After de-obfuscation, a JS script is immediately executed by the interpreter. The textual description is complicated, so let’s illustrate it using a sample analyzed by the Malware Detonation Platform. Registration looked as follows:

The example above shows that the domain eccbc8[.]com was generated using DGA and that 0.058106102444631436 is the bot’s unique identifier. The screenshot shows two TXT responses, but at this stage we are only interested in the first one:

We will return to the second response later. If you use the following script:

and the key 0.058106102444631436.eccbc8[.]com, you will receive the first command:

As can be seen, the first command is designed to download and run the next-stage tool. To do so, it performs 23 DNS queries (such as 0x%chank_number%.lin9gtmn.eccbc8[.]com), concatenates the responses into a string, de-obfuscates it using the key lin9gtmn, and launches it. An example of such requests:

The resulting script has many functions, including:

• Sending multiple DNS queries at the same time
• Gathering information about infected devices
• Stealing files from infected devices
• Downloading arbitrary files from servers
• Deploying a SOCKS server to proxy traffic

It is noteworthy that at the time of analysis, the resulting script was unfinished: Group-IB researchers came across errors in the script code and the persistence function was commented out. Moreover, from all the above functions, the script only performs one, namely collecting information about the infected device in a JSON object in the following format:

The data is once again obfuscated using the lin9gtmn key, split into chunks of 60 bytes, and sent as several requests in the following format:

Polygon example:

In response, the server sends an obfuscated JavaScript to be executed. In our case, Group-IB experts did not receive any additional commands. However, do you remember that we planned to return to the second response? Here it is:

The second command from the server after de-obfuscation looks as follows:

And this script runs the second large piece of code from the final-stage script. First, the code makes a request to the server in order to obtain connection parameters. The request is as follows:

Polygon example:

The response is data in the format %threads%:%width%:%expire%, obfuscated with the %id% key. To avoid overloading the article with in-depth technical details, we will not describe what these fields mean. We will only note that these variables are responsible for the number of simultaneous DNS requests, the number of simultaneously processed commands from the server, and the run time of the command handler script.

Having obtained the connection parameters, the script launches the function used to handle commands from the server. The function makes a request to the server in order to receive commands:

Polygon example:

The script processes the following commands:

It is worth noting that this section of the code logs the progress of its work, but in order to transfer data to the server the code uses the function this.send (not defined in the code). The function accepts this.proc.stdout as the first argument. Moreover, the result of the .download: command is processed in the same way. This evidence may indicate that this piece of code is still being developed.

The code also contains two functions whose names speak for themselves: _socks and _eval. Group-IB experts have not seen them being used in the code, which means that they can probably be called on the server’s command. Moreover, the threat actors commented out a part of the script code that ensures persistence in the system by creating the file OneDrive.cmd in the Microsoft\Windows\Start Menu\Programs\Startup directory and adding to it a command to start the Node.js interpreter with the s.txt argument.

Commands

As mentioned above, on March 25, Group-IB experts obtained and analyzed several commands. The commands were being used for reconnaissance, after which the attackers (or their script) realized that the application was launched in a test environment and sent a command to terminate the interpreter. All commands were sent in clear text, which made it possible to examine them using a traffic sniffer:

An example of traffic between an infected device and a server

Commands can be divided by functionality into six scripts that perform the following actions:

1. Collecting information about the infected system/device:
   • CPU
   • Computer name, memory capacity
   • Network information (IP and MAC addresses)
   • OS information
   • Path to the %Temp% directory
   • System run time
2. Obtaining information about connected drives
3. Launching the cmd.exe shell, executing a command, and sending the output to C2. During our research, the following commands were executed:
   • ipconfig /all
   • kill
4. Obtaining information about the plugins installed in the system. At the time of research no plugins had been loaded, so we have only their names:
   • TSFR
   • SHLL
   • NESC
   • PRSE/PRST
   • FWSE
   • SPPU/SPPR
   • SRPU/SRPR
   • ATSE
5. Obtaining information about files in the following directories:
   • The directory in which the malicious script and the Node.js interpreter are located
   • C:\
   • C:\Users
   • C:\Users\<%username%>
   • C:\Users\<%username%>\Downloads
6. Terminating the Node.js interpreter

Group-IB researchers did not manage to obtain more commands during the analysis, but even based on this short list, we can conclude that OldGremlin prepared a sufficient number of scripts to ensure full-fledged post-exploitation.

Conclusion

After a long break of more than a year, in March 2022 the ransomware gang OldGremlin resumed their malicious email campaigns targeting Russian companies. They remain one of the very few Russian-speaking ransomware gangs operating in Russia. As in their past attacks, the gremlins used carefully crafted fake emails, an up-to-date news agenda, and new custom tools. The latter included TinyFluff, which we analyzed in detail. We have reason to believe that the new campaigns may have infected a large number of companies and that in the coming months the attackers will slowly and carefully move through their infrastructure, bypassing existing security systems.

To prevent ransomware attacks, Group-IB recommends that companies use Group-IB Managed XDR to protect their infrastructure against targeted attacks and proactively hunt for threats using Threat Intelligence data. We also advise cybersecurity analysts to explore the list of OldGremlin’s tactics, techniques and procedures shared below, which is mapped to the MITRE ATT&CK matrix. Group-IB’s Threat Intelligence team will continue to monitor the group’s activities and promptly notify customers about any new attacks.

MITRE

IOCs

Network

Domains

Files

2022-03-22

2022-03-25