Subscribe to Kaspersky hírcsatorna Kaspersky
Frissítve: 1 perc 32 másodperc
2021. május 10.

DDoS attacks in Q1 2021

News overview

Q1 2021 saw the appearance of two new botnets. News broke in January of the FreakOut malware, which attacks Linux devices. Cybercriminals exploited several critical vulnerabilities in programs installed on victim devices, including the newly discovered CVE-2021-3007. Botnet operators use infected devices to carry out DDoS attacks or mine cryptocurrency.

Another active bot focused on Android devices with the ADB (Android Debug Bridge) debug interface. The botnet was dubbed Matryosh (from the Russian word matryoshka — nesting doll) due to the multi-step process for obtaining the C&C address. It is not the first bot to attack mobile devices through a debug interface. This loophole was previously exploited by ADB.Miner, Ares, IPStorm, Fbot, Trinity, and other malware.

Q1 was not without yet another iteration of Mirai. Cybercriminals infected network devices, exploiting relatively recently discovered vulnerabilities, plus several unknown bugs. According to the researchers who identified the attack, it might have affected several thousand devices.

In Q1 2021, cybercriminals also found a host of new tools for amplifying DDoS attacks. One of them was Plex Media Server for setting up a media server on Windows, macOS, or Linux computers, network-attached storages (NAS), digital media players, and the like. Around 37,000 devices with Plex Media Server installed, accessible online directly or receiving packets redirected from specific UDP ports, turned out to be vulnerable. Junk traffic generated by Plex Media Server is made up of Plex Media Service Discovery Protocol (PMSSDP) requests and amplifies the attack by a factor of approximately 4.68.

A major amplification vector was the RDP service for remote connection to Windows devices. RDP servers listening on UDP port 3389 were used to amplify DDoS attacks. At the time of publishing the information about the misuse of the remote access service, 33,000 vulnerable devices had been found. The amplification factor was significantly higher than in the case of Plex Media Server: 85.9. To prevent attacks via RDP, it is recommended to hide RDP servers behind a VPN or disable UDP port 3389.

That said, a VPN is no panacea if it too is vulnerable to amplification attacks. In Q1 2021, for instance, attackers went after Powerhouse VPN servers. The culprit turned out to be the Chameleon protocol, which guards against VPN blocking and listens on UDP port 20811. The server response to requests on this port was 40 times larger than the original request. The vendor released a patch when they learned about the problem.

Alas, not all users of vulnerable programs and devices install updates promptly. For instance, as of mid-March, there were around 4,300 web-based servers for DDoS amplification through the DTLS protocol — this method was covered in our previous report. Vulnerable devices were either misconfigured or missing the latest firmware version with the required settings. Cybercriminals have wasted no time in adding this amplification method (as well as most others discovered just this past quarter) to their arsenal of DDoS-for-hire platforms.

Non-standard protocols are of interest to cybercriminals not only as a means of amplification, but as a tool for carrying out DDoS attacks. In Q1, a new attack vector appeared in the form of DCCP (Datagram Congestion Control Protocol), a transport protocol for regulating the network load when transmitting data in real time, for example, video streaming. The built-in mechanisms to protect against channel congestion did not prevent attackers using this protocol to flood victims with multiple connection requests. What’s more, on the side of the junk packet recipients, there were no online-accessible DCCP applications. Most likely, the attackers were randomly looking for a way to bypass standard DDoS protection.

Another unusual DDoS vector was the subject of an FBI warning about the rise in attacks on emergency dispatch centers. TDoS (telephony denial-of-service) attacks aim to keep the victim’s phone number permanently busy, flooding it with junk calls. There are two main TDoS methods: via flash mobs on social networks or forums, and automated attacks using VoIP software. Neither is new, but TDoS against critical first-responder facilities poses a very serious threat. “The public can protect themselves in the event that 911 [the emergency number across North America] is unavailable by identifying in advance non-emergency phone numbers and alternate ways to request emergency services in their area,” the FBI advised.

On the whole, the quarter was rich in media-reported DDoS attacks. In particular, DDoS ransomware continued to attack organizations worldwide at the start of the year. In some cases, they demonstrated impressive capabilities. For example, a European gambling company was bombarded with junk traffic, peaking at 800 GB per second. Maltese Internet service provider Melita was also hit by ransomware: a showcase DDoS attack disrupted services. At the same time, ransomware operators, having already started to steal victims’ data before encryption, also turned their eyes on DDoS as an extortion tool. The first attack on the website of a victim unwilling to negotiate occurred late last year. In January, Avaddon’s operators jumped on the bandwagon, followed in March by the group behind the Sodinokibi (REvil) ransomware.

Ransomwarers were likely spurred on by the upward movement of cryptocurrency prices, which continued in Q1 2021. In early February, Tesla announced a massive investment in Bitcoin, which led to even more hype around digital money. Several cryptocurrency exchanges could not cope with the resulting influx of sign-ups and suffered downtime. There was no avoiding DDoS either: British exchange EXMO reported an attack on its systems. Company representatives admitted that not only the site was affected, but the entire network infrastructure.

As many users were still working (and playing) from home in Q1 2021, cybercriminals made sure to target the most in-demand resources. In addition to the aforementioned Melita, Austrian provider A1 Telekom (article in German), as well as Belgian telecommunications firm Scarlet, suffered DDoS attacks (albeit without the ransomware component). In both instances, customers faced communication disruptions, and in the case of A1 Telekom, users all across the country experienced problems.

Online entertainment was likewise targeted by cybercriminals throughout the quarter. For example, Blizzard reported a DDoS attack in early January. The barrage of junk traffic caused players, especially those trying to connect to World of Warcraft servers, to experience delays. There were also cases of players getting kicked off the server. Towards the end of the month, cybercriminals attacked League of Legends. Players attempting to enter tournaments in Clash mode experienced login issues and intermittent connection failures. In February, a DDoS attack temporarily disabled the television service of Icelandic provider Siminn. And in March, LittleBigPlanet servers were unavailable for several days. Players blamed a disgruntled fan for the attack.

By early 2021, many schools had switched to on-campus or hybrid mode, but that did not stop the DDoS attacks. Only now, instead of flooding online platforms with junk traffic, cybercriminals sought to deprive educational institutions of internet access. For instance, in February, US schools in Winthrop, Massachusetts, and Manchester Township, New Jersey, were hit by DDoSers. In the second case, the attack forced the institutions to temporarily return to remote schooling. In March, CSG Comenius Mariënburg, a school in Leeuwarden, Netherlands, also fell victim to a DDoS attack. The attack was organized by students themselves. Two of them were quickly identified, but school officials suspect that there were other accomplices.

The most significant event in Q1 was COVID-19 vaccination. As new segments of the population became eligible for vaccination programs, related websites suffered interruptions. At the end of January, for example, a vaccine registration website in the US state of Minnesota crashed under the load.The incident coincided with the opening of appointments to seniors, teachers and childcare workers.In February, a similar glitch occurred on a vaccine appointment portal in Massachusetts as retirees, people with chronic illnesses and staff of affordable senior housing tried to sign up for a shot. In both cases, it is not known for certain whether it was a DDoS attack or an influx of legitimate traffic; all the same, cybersecurity company Imperva recorded a spike in bot activity on healthcare resources.

Nor was Q1 without political DDoS attacks. In February, cybercriminals flooded the websites of Dutch politician Kati Piri and the Labor Party, of which she is a member, with junk traffic. The Turkish group Anka Nefeler Tim claimed responsibility. In late March, a DDoS hit the website of the Inter-Parliamentary Alliance on China (IPAC). Representatives of the organization note that this is not the first such attack in living memory. On top of that, several government agencies in Russia and Ukraine reported DDoS attacks in early 2021. The victims included the websites of the Russian Federal Penitentiary Service and the National Guard, the Kiev City State Administration, the Security Service of Ukraine, the National Security and Defense Council, as well as other Ukrainian security and defense institutions.

Since the start of 2021, a number of media outlets in Russia and abroad have been targeted by DDoS attacks. In January, attackers downed the websites of Kazakh newspaper Vlast and Brazilian nonprofit media organization Repórter Brasil. In the second case, the attacks continued for six days. The Ulpressa portal, based in the Russian city of Ulyanovsk, came under a much longer attack lasting several weeks. The website was attacked daily during peak hours. The KazanFirst news portal initially managed to repel the stream of junk traffic, but the attackers changed tactics and ultimately took the site offline. A similar scenario played out in the case of Mexican magazine Espejo: the administrators deflected the first attempts to down the site, but these were followed by a more powerful DDoS wave.

But it was not only legitimate organizations that suffered from DDoS in Q1 2021. In January, many resources on the anonymous Tor network, which is popular with cybercriminals, were disrupted. The Tor network may have been overloaded due to DDoS attacks against specific sites on the dark web. A February target was the major underground forum Dread, used, among other things, to discuss deals on the black market. The forum administration was forced to connect additional servers to defend against the attack.

But this quarter was not all doom and gloom: some DDoS organizers did get exposed. For example, a pair of high-ranked Apex Legends players who DDoSed anyone who beat them finally got banned. A slightly more severe punishment was dished out to a teenager who late last year tried to disrupt Miami-Dade County Public Schools’ online learning system. He escaped jail, but was sentenced to 30 hours’ community service and placed on probation.

Quarter trends

In Q1 2021, DDoS market growth against the previous reporting period outstripped our prediction of around 30%, nudging over the 40% mark. Unusually, and hence interestingly, 43% of attacks occurred in the normally relatively calm month of January.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Comparative number of DDoS attacks, Q1 2021, Q1 2020, and Q4 2020. Data for Q1 2020 is taken as 100% (download)

The unexpected surge in DDoS activity can be attributed to the price of cryptocurrencies in general, and Bitcoin in particular, which began to fall in January 2021. The practice of previous years shows that rapid cryptocurrency growth is followed by a similarly rapid decline. It seems that the nimblest botnet owners expected similar behavior this year, and reverted back to DDoS at the first hint of a price drop. However, the Bitcoin price sometimes has a mind of its own: it rose again in February, plateaued in March and remains high at the time of posting. Accordingly, the DDoS market sagged in February and March.

Note that these two months were entirely in line with our forecast: the DDoS market showed slight growth relative to Q4, but no more than 30%. Another curiosity is that this year’s February and March indicators are very similar (within a few percent) to those of January 2020, which was a typically calm January. The same picture (abnormal January followed by standard February and March) was seen in 2019.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Comparative number of DDoS attacks, 2019–2021. Data for 2019 is taken as 100% (download)

Q1 2019 was fairly stable, almost benchmark standard, so it can be used to demonstrate deviations. Last year saw an explosive increase in DDoS activity in February and March, which we attributed, and continue to attribute, to the coronavirus outbreak, the switch to remote working, and the emergence of many new DDoS-vulnerable targets. This year’s January outlier is equally stark when compared with the 2019 data.

Note the significant lag in the Q1 figures overall against the same period of last year. This gap can be explained by the above-mentioned abnormally high numbers in 2020. Over the past year, the situation has changed: organizations have strengthened and learned how to protect remote infrastructure, so Q1 this year was simply ordinary, with no distortions. The slump in the numbers was caused specifically by the abnormal previous year, not the decline in the current one.
At the same time, the share of smart attacks in Q1 increased relative to both the end of 2020 (from 44.29% to 44.60%) and its start. This also indirectly confirms the theory that capacities are being redirected away from DDoS, which comes at the expense of attacks that are easy to organize and defend, since they have become unprofitable for botnet operators.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Share of smart attacks, Q1 2021, Q1 2020, and Q4 2020 (download)

In our Q4 2020 report, we noted a downward trend in the duration of short attacks and an upward one in the duration of long attacks. This trend continued this quarter as well, which is clearly seen from the duration data compared to Q4 of the previous year. We cautiously assume that this trend will continue in the future.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

DDoS attack duration, Q1 2021, Q1 2020, and Q4 2020. Data for Q1 2020 is taken as 100% (download)

Statistics Methodology

Kaspersky has a long history of combating cyberthreats, including DDoS attacks of all types and complexity. Company experts monitor botnets using the Kaspersky DDoS Intelligence system.

The DDoS Intelligence system is part of the Kaspersky DDoS Protection solution, and intercepts and analyzes commands sent to bots from C&C servers. The system is proactive, not reactive, meaning that it does not wait for a user device to get infected or a command to be executed.

This report contains DDoS Intelligence statistics for Q1 2021.

In the context of this report, it is assumed that an incident is a separate (single) DDoS-attack if the interval between botnet activity periods does not exceed 24 hours. For example, if the same web resource was attacked by the same botnet with an interval of 24 hours or more, then this incident is considered as two attacks. Bot requests originating from different botnets but directed at one resource also count as separate attacks.

The geographical locations of DDoS-attack victims and C&C servers used to send commands are determined by their respective IP addresses. The number of unique targets of DDoS attacks in this report is counted by the number of unique IP addresses in the quarterly statistics.

DDoS Intelligence statistics are limited to botnets detected and analyzed by Kaspersky. Note that botnets are just one of the tools used for DDoS attacks, and that this section does not cover every single DDoS attack that occurred during the review period.

Note that, starting Q4 2020, the number of botnets whose activity is included in the DDoS Intelligence statistics has increased. This may be reflected in the data presented in this report.

Quarter summary

In Q1 2021:

  • The US displaced China from top spot by both number of DDoS attacks and number of unique targets.
  • We saw a spike in DDoS activity in January, peaking at over 1,800 attacks per day: 1,833 on the 10th and 1,820 on the 11th. On several other days in January, the daily number of attacks exceeded 1,500.
  • The distribution of attacks by day of the week was fairly even: just 2.32 p.p. separated the most and the least active days.
  • The number of short (less than 4 hours) DDoS attacks increased significantly.
  • The most widespread this time was UDP flooding (41.87%), while SYN flooding dropped to third place (26.36%).
  • Linux botnets continued to account for almost all DDoS traffic (99.90%).
Attack geography

In Q1 2021, the perennial leaders by number of DDoS attacks swapped places: the US (37.82%) added 16.84 p.p. to top the leaderboard, nudging aside China (16.64%), which lost 42.31 p.p. against the previous reporting period. The Hong Kong Special Administrative Region (2.67%), which had long occupied third position, this time dropped to ninth, with Canada (4.94%) moving into the Top 3.

The UK (4.12%) also lost ground, falling from fourth to sixth place, despite its share increasing by 2.13 p.p., behind the Netherlands (4.48%) and France (4.43%). South Africa, which finished fifth last quarter, dropped out of the Top 10 altogether.
Germany (3.78%) moved up to seventh place, displacing Australia (2.31%), which rounds out the ranking this quarter. Eighth place was taken by Brazil (3.36%), having rarely climbed higher than eleventh before.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Distribution of DDoS attacks by country, Q4 2020 and Q1 2021 (download)

The Top 10 countries by number of DDoS targets traditionally corresponds closely to the ranking by number of attacks. The Q1 leader was the US (41.98%), whose share increased by 18.41 p.p. By contrast, China’s share fell by more than four times — from 44.49% to 10.77%, pushing it into second place. However, there are some minor differences in the two rankings. Hong Kong, for instance, dropped out of the Top 10 countries by number of targets, and the Netherlands moved up to third place (4.90%). The UK (4.62%) consolidated its position in fourth spot, while Canada (4.05%) dropped from sixth to seventh, just a fraction of a percentage point behind Germany (4.10%) and France (4.08%).

Brazil (3.31%), as in the ranking by number of DDoS attacks, moved up to eighth place, while Australia (2.83%) climbed tenth to ninth place, allowing Poland (2.50%) to sneak in at the foot of the table. Like Brazil, Poland is an infrequent guest in the Top 10.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Distribution of unique DDoS-attack targets by country, Q4 2020 and Q1 2021 (download)

DDoS attack dynamics

Q1 2021 got off to a dynamic start. DDoS activity peaked on January 10 and 11, when the number of attacks exceeded 1,800 per day. January posted several more days on which our systems recorded more than 1,500 attacks. As mentioned above, this surge in activity is most likely due to the brief drop in the Bitcoin price.
After a stormy start, there followed a relatively calm February, when for several days in a row — from the 13th to the 17th — the daily rate of DDoS attacks remained under 500. The quietest day was February 13, when we recorded just 346 attacks. Early March saw another peak, more modest than the January one: 1,311 attacks on the 3rd and 1,290 on the 4th. Note that, as before, this was preceded by a fall in the Bitcoin price.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Dynamics of the number of DDoS attacks, Q1 2021 (download)

In Q1 2021, DDoS attacks by day of the week were far more evenly spread than in the previous reporting period. The difference between the stormiest and the quietest days was 2.32 p.p. (versus 6.48 p.p. in Q4 2020). Saturday (15.44%) took the lion’s share of DDoS attacks, while Thursday (13.12%), last quarter’s leader, was this time the most inactive day. Overall, the share of days from Friday to Monday increased in the first three months of 2021, while midweek dipped slightly.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Distribution of DDoS attacks by day of the week, Q4 2020 and Q1 2021 (download)

Duration and types of DDoS attacks

The average DDoS attack duration in Q1 more than halved compared to Q4 2020. The proportion of very short attacks lasting less than four hours rose markedly (91.37% against 71.63% in the previous reporting period). In contrast, the share of longer attacks declined. Attacks lasting 5–9 hours lost 7.64 p.p., accounting for 4.14% of all attacks; only 2.07% of incidents lasted 10–19 hours, and 1.63% 20–49 hours. Attacks lasting 50–99 hours in Q1 made up less than 1% of the total. The shares of long (0.07%) and ultra-long (0.13%) attacks also fell slightly.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Distribution of DDoS attacks by duration, Q4 2020 and Q1 2021 (download)

The distribution of attacks by type continued to change. In Q1 2021, the seemingly unassailable leader, SYN flooding (26.36%), lost its grip on the ranking. This DDoS type shed 51.92 p.p. and finished third. Meanwhile, UDP (41.87%) and TCP flooding (29.23%) gained in popularity among attackers. GRE (1.43%) and HTTP flooding (1.10%), which round out the ranking, also posted modest growth.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Distribution of DDoS attacks by type, Q1 2021 (download)

In terms of botnet types, Linux-based bots were again responsible for the vast majority of attacks this quarter. Moreover, their share even rose slightly against the previous reporting period: from 99.80% to 99.90%.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Ratio of Windows/Linux botnet attacks, Q4 2020 and Q1 2021 (download)

Botnet distribution geography

The traditional leader in terms of C&C server hosting is the US (41.31%), and Q1 was no exception. Its share increased by 5.01 p.p. against Q4 2020. Silver and bronze again went to Germany (15.32%) and the Netherlands (14.91%), only this time they changed places: the share of the Netherlands fell, while Germany’s almost doubled.
Romania dropped from fourth to seventh place (2.46%), behind France (3.97%), the UK (3.01%), and Russia (2.60%). Canada held on to eighth position (1.92%), while Singapore and the Seychelles closed out the ranking, both posting 1.37% in Q1.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Distribution of botnet C&C servers by country, Q1 2021 (download)


The first quarter began with a surge in DDoS activity amid falling cryptocurrency prices, but on the whole it was relatively calm. At the same time, we observed several unexpected reshuffles. In particular, the US knocked China out of first place by both number of DDoS attacks and number of targets. SYN flooding, long the most common type of attack, gave way to UDP and TCP this time around.

As for Q2 forecasts, no significant shifts in the DDoS market are in sight at present. As is customary, much will depend on cryptocurrency prices, which are currently rising an all-time high. Besides, the experience of previous years shows that the second quarter is usually rather calmer than the first; so, barring any shocks, we can expect little change, perhaps a slight decline, in the DDoS market. That said, if the cryptocurrency market falls sharply, we forecast a rise in DDoS activity, driven largely by simple, short-lasting attacks.

2021. május 6.

Operation TunnelSnake: formerly unknown rootkit used to secretly control networks of regional organizations

Windows rootkits, especially those operating in kernel space, are pieces of malware infamous for their near absolute power in the operating system. Usually deployed as drivers, such implants have high privileges in the system, allowing them to intercept and potentially tamper with core I/O operations conducted by the underlying OS, like reading or writing to files or processing incoming and outgoing network packets. The capability to blend into the fabric of the operating system itself, much like security products do, is the quality that earns rootkits their notoriety for stealth and evasion.

Having said that, the successful deployment and execution of a rootkit component in Windows has become a difficult task over the years. With Microsoft’s introduction of Driver Signature Enforcement, it has become harder (though not impossible) to load and run new code in kernel space. Even then, other mechanisms such as Kernel Patch Protection (also known as PatchGuard) make it hard to tamper with the system, with every change in a core system structure potentially invoking the infamous Blue Screen of Death.

Consequently, the number of Windows rootkits in the wild has decreased dramatically, with the bulk of those still active often being leveraged in high profile APT attacks. One such example came to our attention during an investigation last year, in which we uncovered a formerly unknown Windows rootkit and its underlying cluster of activity. We observed this rootkit and other tools by the threat actor behind it being used as part of a campaign we dubbed ‘TunnelSnake’, conducted against several prominent organizations in Asia and Africa.

In this blog post we will focus on the following key findings that came up in our investigation:

  • A newly discovered rootkit that we dub ‘Moriya’ is used by an unknown actor to deploy passive backdoors on public facing servers, facilitating the creation of a covert C&C communication channel through which they can be silently controlled;
  • The rootkit was found on networks of regional diplomatic organizations in Asia and Africa, detected on several instances dating back to October 2019 and May 2020, where the infection persisted in the targeted networks for several months after each deployment of the malware;
  • We observed an additional victim in South Asia, where the threat actor deployed a broad toolset for lateral movement along with the rootkit, including a tool that was formerly used by APT1. Based on the detection timestamps of that toolset, we assess that the attacker had a foothold in the network from as early as 2018;
  • A couple of other tools that have significant code overlaps with Moriya were found as well. These contain a user mode version of the malware and another driver-based utility used to defeat AV software.

We provided information about this operation in our threat intelligence portal in August 2020. More details and analysis are available to customers of our private APT reporting service. For more details contact: intelreports@kaspersky.com.

What is the Moriya rootkit and how does it work?

Our investigation into the TunnelSnake campaign started from a set of alerts from our product on a detection of a unique rootkit within the targeted networks. Based on string artefacts within the malware’s binaries, we named this rootkit Moriya. This tool is a passive backdoor which allows attackers to inspect all incoming traffic to the infected machine, filter out packets that are marked as designated for the malware and respond to them. This forms a covert channel over which attackers are able to issue shell commands and receive back their outputs.

The rootkit has two traits that make it particularly evasive. The packet inspection happens in kernel mode with the use of a Windows driver, allowing attackers to drop the packets of interest before they are processed by the network stack, thus ensuring they are not detected by security solutions. Secondly, the fact that the rootkit waits for incoming traffic rather than initiating a connection to a server itself, avoids the need to incorporate a C&C address in the malware’s binary or to maintain a steady C&C infrastructure. This hinders analysis and makes it difficult to trace the attacker’s footprints.

The figure below illustrates the structure of the rootkit’s components. They consist of a kernel mode driver and a user mode agent that deploys and controls it. In the following sections we will break down each of these components and describe how they operate to achieve the goal of tapping into the target’s network communication and blending in its traffic.

Fig. 1. The architecture of the Moriya rootkit

User mode agent analysis

The user mode component of the Moriya rootkit has two purposes. One is to deploy the kernel mode component of the malware on the machine and the other is to leverage the covert communication channel created by it to read shell commands sent from the C&C server to the compromised machine and to respond to them. Since Moriya is a passive backdoor intended to be deployed on a server accessible from the internet, it contains no hardcoded C&C address and relies solely on the driver to provide it with packets filtered from the machine’s overall incoming traffic.

The first order of business for the attacker when using Moriya is to gain persistence on the targeted computer. For this purpose, the user mode agent’s DLL contains an export function named Install, which is intended to create a service named ZzNetSvc with the description ‘Network Services Manager’ and start it. In turn, the path to the user mode agent’s image is set to the registry key HKLM\System\CurrentControlSet\Services\ZzNetSvc\Parameters\ServiceDll so that it will be invoked from its ServiceMain export each time the service is initiated.

Next, after the service is started, the agent will attempt to load the rootkit’s driver into the system. Its binary is bundled as two driver images within the DLL’s resource section, corresponding to 32- and 64-bit architectures, while in reality only one of them is written to disk. In the cases we analyzed, the agent DLLs were compiled for 64-bit systems, dropping a 64-bit driver to the drivers directory in the system path, under the name MoriyaStreamWatchmen.sys, hence the rootkit’s name.

Fig. 2. Code that writes the Moriya driver to disk

The agent uses a known technique whereby the VirtualBox driver (VBoxDrv.sys) is leveraged to bypass the Driver Signature Enforcement mechanism in Windows and load Moriya’s unsigned driver. DSE is an integrity mechanism mandating that drivers are properly signed with digital signatures in order for them to be loaded, which was introduced for all versions of Windows starting from Vista 64-bit. The technique used to bypass it was seen in use by other threat actors like Turla, Lamberts and Equation.

Moriya’s user mode agent bypasses this protection with the use of an open-source code[1] named DSEFIX v1.0. The user agent dumps an embedded VBoxDrv.sys image of version 1.6.2 to disk and loads it, which is then used by the aforementioned code to map Moriya’s unsigned driver to kernel memory space and execute it from its entry point. These actions are made possible through IOCTLs implemented in VBoxDrv.sys that allow writing to kernel address space and executing code from it. Throughout this process, the bypass code is used to locate and modify a flag in kernel space named g_CiOptions, which controls the mode of enforcement.

After the unsigned driver is loaded, the agent registers a special keyword that is used as a magic value, which will be sought in the first bytes of every incoming packet passed on the covert channel. This allows the rootkit to filter marked packets and block them for any application on the system other than the user mode agent. The registration of the value is done through a special IOCTL with the code 0x222004 sent to the driver, where a typical magic string is pass12.

Fig. 3. Registration of the packet magic value using a designated IOCTL

Except for its covert channel communication feature, Moriya is capable of establishing a reverse shell session using an overt channel. For this purpose, it waits for a special packet that consists of a message with the structure connect <c2_address> <c2_port>. The address and port are parsed and used by the agent to start a new connection to the given server, while creating a new cmd.exe process and redirecting its I/O to the connection’s socket. The handles for the newly created process and its main thread are destroyed to avoid detection.

In any other case, the agent attempts to read the incoming TCP payload from the driver, which will be retrieved as soon as a designated packet with a magic number and shell command is received. An attempt is made to read the data with a plain ReadFile API function as a blocking operation, i.e., reading is accomplished only once the buffer in kernel mode is populated with data from a Moriya-related packet.

Upon an incoming packet event, the agent creates a new cmd.exe process and redirects its I/O using named pipes. One pipe is used to read the retrieved shell command from the covert channel and the other is used to write the shell’s output (obtained from the stdout and stderr streams) back to it after execution. To write any data back, the agent uses the WriteFile API function with the driver’s handle.

All traffic passed on the channel is encoded with a simple encryption scheme. Every sent byte has its payload, following the magic string, XORed with the value 0x05 and then negated. Following the same logic, to decode the incoming traffic’s payload, every byte of it should be first negated and then XORed with 0x05.

Fig. 4. Code used for packet encoding

Kernel mode driver analysis

The Moriya rootkit’s driver component makes use of the Windows Filtering Platform (WFP) to facilitate the covert channel between the compromised host and the C&C server. WFP provides a kernel space API that allows driver code to intercept packets in transit and intervene in their processing by the Windows TCP/IP network stack. This makes it possible to write a driver that can filter out distinct packet streams, based on developer-chosen criteria, and designate them for consumption by a specific user mode application, as is the case in Moriya.

The driver fetches the distinct Moriya-related traffic using a filtering engine. This is the kernel mode mechanism used to inspect traffic according to rules that can be applied on various fields across several layers of a packet (namely data link, IP and transport), making it possible to handle matching packets with unique handlers. Such handlers are referred to as callout functions.

In the case of Moriya, the filtering engine is configured to intercept TCP packets, sent over IPv4 from a remote address. Each packet with these criteria will be inspected by a callout function that checks if its first six bytes correspond to the previously registered magic value, and if so, copies the packet contents into a special buffer that can be later read by the user mode agent. The matching packet will then be blocked in order to hide its presence from the system, while any other packet is permitted to be processed as intended by the network stack.

To allow the crafting of a response back to the server, the callout function saves a special value in a global variable that identifies the received TCP stream. This value is called a flowHandle, and is taken from the packet’s corresponding FWPS_INCOMING_METADATA_VALUES0 struct. When the user issues a response to the server via the driver, the latter would craft a new packet using the FwpsAllocateNetBufferAndNetBufferList0 function and insert the response data and target server based on the saved flowHandle to it, using the function FwpsStreamInjectAsync0.

Fig. 5. Code that creates a new packet, designates it for the flow of the corresponding incoming TCP packet and injects data written from user space into it

As formerly mentioned, the driver registers several functions that are exposed to the user mode agent in order to interact with it:

  • IRP_MJ_READ: used to allow the user mode agent to read the body of a Moriya TCP packet from a special buffer to which it is copied upon receipt. The function itself waits on an event that gets signaled once such a packet is obtained, thus turning the ReadFile function called by the user mode agent into a blocking operation that will wait until the packet is picked up by the driver.
  • IRP_MJ_WRITE: injects user-crafted data into a newly created TCP packet that is sent as a response to an incoming Moriya packet from the server.
  • IRP_MJ_DEVICE_CONTROL: used to register the keyword to check the beginning of every incoming TCP packet in order to identify Moriya-related traffic. The passed magic is anticipated to be six characters long.

Fig. 6. Code used for registering the packet magic value from the driver side

How were targeted servers initially infected?

Inspecting the systems targeted by the rootkit, we tried to understand how they got infected in the first place. As previously mentioned, Moriya was seen deployed mostly on public-facing servers within the victim organizations. In one case, we saw the attacker infect an organizational mail server with the China Chopper webshell, using it to map the victim’s

network and then deploy other tools in it. Moriya’s user mode agent was explicitly installed using a command line executed on the targeted server this way. This command and examples of others run on the victim machine via the webshell can be seen below.

"cmd" /c cd /d C:\inetpub\wwwroot\&ipconfig -all "cmd" /c cd /d C:\inetpub\wwwroot\&reg query HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest "cmd" /c cd /d C:\inetpub\wwwroot\&$public\acmsetup.exe "cmd" /c cd /d C:\inetpub\wwwroot\&query user "cmd" /c cd /d C:\inetpub\wwwroot\&ipconfig/all "cmd" /c cd /d C:\inetpub\wwwroot\&ping google.com "cmd" /c cd /d C:\inetpub\wwwroot\&netstat -anp tcp "cmd" /c cd /d C:\inetpub\wwwroot\&tasklist /v "cmd" /c cd /d C:\inetpub\wwwroot\&whoami "cmd" /c cd /d C:\inetpub\wwwroot\&cd $windir\web\ "cmd" /c cd /d $windir\Web\&rundll32 MoriyaServiceX64.dll, Install "cmd" /c cd /d C:\inetpub\wwwroot\&ipconfig/all "cmd" /c cd /d C:\inetpub\wwwroot\&time /t ...

In general, we assess that the group’s modus-operandi involves infiltrating organizations

through vulnerable web servers in their networks. For example, an older variant of Moriya named IISSpy (described below) targets IIS web servers. Our telemetry shows that it was likely deployed by exploiting CVE-2017-7269 to let the attackers gain an initial foothold on a server prior to running the malware.

Post exploitation toolset

During our investigation we found a target in South Asia that enabled us to get a glimpse into some of the other tools that we assess were in use by the same attacker. The toolset includes programs used to scan hosts in the local network, find new targets, perform lateral movement to spread to them and exfiltrate files. While most of the tools seem custom made and tailored for the attackers’ activities, we could also observe some open-source malware frequently leveraged by Chinese-speaking actors. Following is an outline of these tools based on their purpose in the infection chain.

  • Network Discovery: custom built programs used to scan the internal network and detect vulnerable services.
    • HTTP scanner: command-line tool, found under the name ‘8.tmp’, which discovers web servers through banner grabbing. This is done by issuing a malformed HTTP packet to a given address, where no headers are included and the request is succeeded with multiple null bytes.

      Fig. 7. Malformed packet generated by HTTP scanner

      If the server responds, the output will be displayed in the console, as shown below.

      Fig. 8. Console output with a server response displayed upon discovery of a new server in the network

    • DCOM Scanner: another command-line utility that attempts to connect to a remote host on TCP port 135 (RPC), and use the DCOM IOxidResolver interface to resolve addresses assigned to all network interfaces available on the remote system.

      Fig. 9. Output of the DCOM scanner utility

  • Lateral Movement: tools used to spread to other hosts in the targeted networks.
    • BOUNCER: malware that was first described by Mandiant in their 2013[2] report on APT1. This tool is another passive backdoor that waits for incoming connections on a specific port and provides different features, as outlined below, that can be used to control a remote host and facilitate lateral movement from it.
      0x01: Proxy Init Connection 0x02: Proxy Send Packet 0x03: Proxy Close Connection 0x07: Execute Shellcode 0x0A: Kill Bot 0x0C: Reverse Shell CMD 0x0D: Delete File 0x0E: Execute local program 0x0F: Enumerate Servers In Domain and save output in gw.dat 0x10: Enumerate SQL Servers and save output in sql.dat 0x12: Reverse Shell CreateProcess 0x16: Upload File - Write Data 0x17: Download File - Finish 0x1E: Download File - Start 0x1F: Upload File - Start 0x2D: Enumerate Servers 0x2E: Enumerate SQL Server 0x2F: Enumerate Servers Verbose 0x30: Enumerate Users 0x32: Do nothing The BOUNCER sample that we observed contained a string that indicates which command-line arguments it anticipates:
      usage:%s IP port [proxip] [port] [key] However, the backdoor is configured to accept only the port number on which it will listen.

      We saw two versions of this backdoor, initiated by two different launchers. The first one is an executable file named nw.tmp that decrypts an embedded payload using the RC4 algorithm and injects it into a newly spawned svchost.exe process. The injected payload is similar to one described by Mandiant in 2013, which is yet another intermediate loader that decrypts and loads an embedded BOUNCER DLL. The last stage is started by invoking the DLL’s dump export with the arguments passed via the command line.

      The other version was stored with the name rasauto.dll in the system directory, impersonating the Windows Remote Access Auto Connection Manager library. Like the other version, it decrypts an embedded DLL using RC4, but this time uses no intermediate stage, instead directly calling the DLL’s dump export without arguments. The decrypted library is a slightly modified BOUNCER variant that always listens on the hardcoded port 1437.

      Fig. 10. Code from the second BOUNCER variant that uses the hardcoded port 1437 to listen for new packets

      Based on compilation timestamps of all BOUNCER-related executables, as shown below, we assess that the attacker reused old samples of the malware rather than compiled new versions of it:

      nw.tmp – stage 0 - launcher - 08-03-2017 03:56:24 nw.tmp – stage 1 - embedded loader - 26-08-2014 04:49:58 nw.tmp – stage 2 - embedded BOUNCER backdoor - 28-05-2012 13:44:37 rasauto.dll - stage 0 – loader 26-08-2013 09:37:08 rasauto.dll - stage 1 - embedded BOUNCER backdoor - 26-08-2013 09:36:27

    • Custom PSExec: the attacker deployed a tool to execute commands remotely on compromised machines. Like the original PSExec tool, this one consists of two components – a client named tmp and a service named pv.tmp. In order to use the tool, the attacker has to execute it via a command line with the parameters specified below.Usage: psexec <hostname >   psserve_path  exefilename  ServerName[option]\n

      The service component is a tiny program that uses the CreateProcessA API to start a program specified as an argument. The client component uses the Service Control Manager (SCM) API to create a service on the target machine. If the ServerName argument is not specified, the service will be named Server%c%c where %c is a random lower case character. The exefilename argument is then passed to the StartServiceA function in order to initiate the command execution.

      Fig. 11. Code used to create and start the service on targeted host

      It is worth noting that the program has some limitations. Compared with the original PSExec, it is not able to copy the service binary (i.e., pv.tmp, which has its path specified in the psserve_path argument) to a remote machine, but rather assumes it is already present on it. Besides, it cannot handle network credentials, limiting the ability to execute commands as other users, nor does it support pipes, which means it does not receive the output of the commands it issues.

  • Exfiltration: multi-platform utilities commonly used to establish connections with remote hosts and conduct file system operations on them, including file upload and download.
    • Earthworm and Termite: well-known command-line utilities developed to facilitate intrusion into intranet networks. These programs are multiplatform and can be deployed on various architectures. Earthworm is used to create tunnels between compromised hosts and transfer data.

      Fig. 12. Earthworm help message

      Termite provides additional features to download and upload files between the compromised hosts, as well as a way to spawn a remote shell to control the targeted machine.

      Fig. 13. Termite help message

    • TRAN: another tool that we detected under the filename tmp that was used to transfer data between compromised hosts. The binary we saw operated as a loader that embodies a tiny web server encrypted with the RC4 algorithm within it. This server is later injected into a newly created legitimate schtask.exe process and usually listens on port 49158. It is used for managing files uploaded by the attacker into an in-memory virtual file system maintained by the malware.By default the file system includes a tiny program named client.exe, which can be downloaded by any host using a standard HTTP GET request to the path /client.exe. This file is a command-line utility that can be used to control the virtual file system managed by the server, through one of several available commands outlined below.

      Fig. 14. Client.exe help message

IISSpy: tracing Moriya back to a user-mode rootkit

IISSpy is an older user-mode version of the Moriya rootkit that we were able to pinpoint in our telemetry. It is used to target IIS servers for establishing a backdoor in their underlying websites. It was detected on a machine in 2018, unrelated to any of the attacks in the current operation. This suggests the threat actor has been active since at least that year.

The malware, which comes as a DLL, achieves its goals by enumerating running IIS processes on the server (i.e., those that are executed from the image w3wp.exe), and injecting the malware’s DLL into them to alter their behavior. The executed code in the IIS processes will then set inline hooks for several functions, most notably CreateFileW.

The corresponding CreateFileW hook function checks if the filename argument contains the directory ‘\MORIYA\’ or ‘\moriya\’ in its path, and if so, infers that the attacker has sent a specially crafted HTTP request to the web server. In this request, the Moriya path in the URL is followed by an encoded command. After the command is decoded and processed, it is passed via a mailslot (\\.\mailslot\slot) to a separate thread, while signaling an event called Global\CommandEvent.

Fig. 15. Code of the CreateFileW hook function that looks for the ‘MORIYA’ \ ‘moriya’ directory in a request path

Should the currently handled file contain the Moriya path, the very same hook function will generate a special file on the web server to which command execution output will be written. This file’s path is created by finding the position of the ‘\MORIYA\’ or ‘\moriya\’ strings in the inspected filename argument, and replacing it with the string ‘\IISINFO.HTM’. This will then be appended to the command data passed on the mailslot, following a ‘ > ‘ character.

The other thread waiting on the command event mentioned above is in charge of processing attacker data fetched from the mailslot. Any such command will be read and parsed to find the ‘ > ‘ character and the file path that follows it, in this case the one corresponding to ‘IISINFO.HTML’. After executing the command via cmd.exe, the output will be written to the file in this path, allowing the attacker to read it by issuing a corresponding HTTP request where the URL path leads to this file on the server.

Other functions that are hooked in the IIS process are CreateProcessAsUserW and CreateProcessW. These are used to detect if the current process spawns a new server instance, which will in turn be injected with the malware’s DLL. Apart from this, IISSpy will also create a monitoring thread that will periodically look for newly created httpd.exe processes, corresponding to the Apache server. If detected, the malware will be injected to them as well.

Although it is evident from both the functionality and use of the Moriya keyword by the malware that IISSpy and the Moriya rootkit are related, further evidence in the code substantiates the connection:

  • The older variant is capable of creating a reverse shell transmitted through an overt channel in exactly the same way as the more recent version of the malware, i.e., it identifies a connect request followed by a C&C server address and port, connects to it and redirects the IO of a new exe process to the underlying socket.
  • Both variants use the same packet encoding and decoding algorithm, whereby each clear-text byte is XORed with 0x5 and negated, and vice-versa.

Fig. 16. Packet decoding loop that follows the same logic as that used in Moriya

  • In both cases the developers left a trail of unique debug messages, issued to the OutputDebugString API function. An example of such a string used in identical code in the two variants is shown below.

Fig. 17. Code used in both variants to spawn a new shell, while printing unique debug messages

  • Both implants are deployed by invoking an export function named Install that creates a service that allows persistent execution, with the malware’s logic residing in the ServiceMain Moreover, the Install functions are highly similar to one another.

Fig. 18. Comparison of Install export function CFGs between IISSpy and Moriya

The ProcessKiller rootkit vs. security products

Another interesting artefact found in our telemetry that could be tied to the developers of Moriya is a malware named ProcessKiller. As its name suggests, it is intended to eliminate execution of processes, with the use of a kernel mode driver. Ultimately, this tool is used to shut down and block initiation of AV processes from kernel space, thus allowing other attack tools to run without being detected.

This malware operates through the following stages:

  • An attacker calls the malware’s DLL from an export named Kill, passing it a list of process names it would like to shut down and block as a command-line argument.
  • The malware writes a driver that is embedded as a resource within it, impersonating a Kaspersky driver under the path %SYSTEM%\drivers\kavp.sys.
  • There is an attempt to load the driver using the Service Control Manager. However, since it is not signed and loading is prone to fail on Windows versions above Vista 64-bit, the malware uses the same DSEFix code to bypass Digital Signature Enforcement as witnessed in Moriya’s user mode agent.
  • The malware parses the process names passed as arguments and creates a vector of ‘blacklisted processes’ out of them.
  • For each process in the list, the malware detects its PID and issues it through an IOCTL with code 0x22200C to the driver which is in charge of shutting it down from kernel space. The shutdown is carried out by locating the process object with the function PsLookupProcessByProcessId and then terminating it with ZwTerminateProcess.
  • The list of processes is then passed via another IOCTL with the code 0x222004 to the driver, which inserts each member of it to a linked list in kernel space. When the driver is bootstrapped, it registers a callback for newly created processes through the PsSetCreateProcessNotifyRoutineEx function, which inspects the image name of the created process and compares it against those found in the linked list. If a match is found, the process creation status in the PPS_CREATE_NOTIFY_INFO structure will be set to STATUS_UNSUCCESSFUL, signaling the user space API function that process creation failed.
  • At this point any other malware can theoretically operate without being detected.
  • If the attacker wishes to disable blacklisting, it can be done by issuing an IOCTL with the code 0x222008, which would destroy the linked list of blacklisted processes.

Once again, the connection to Moriya is based on several observations:

  • Distinct debug error messages, as the one presented below.

Fig. 19. Unique debug message that appears in ProcessKiller and Moriya

  • Filename of the same structure, i.e., Moriya’s agent is internally named ‘MoriyaServiceX64.dll’, and ProcessKiller’s DLL is named ‘ProcessKillerX64.dll’
  • Usage of the exact same DSEFix code to load an unsigned driver.
What do we know about the threat actor?

Unfortunately, we are not able to attribute the attack to any particular known actor, but based on the TTPs used throughout the campaign, we suppose it is a Chinese-speaking one. We base this on the fact that the targeted entities were attacked in the past by Chinese-speaking actors, and are generally located in countries that are usually targeted by such an actor profile. Moreover, the tools leveraged by the attackers, such as China Chopper, BOUNCER, Termite and Earthworm, are an additional indicator supporting our hypothesis as they have previously been used in campaigns attributed to well-known Chinese-speaking groups.

Who were the targets?

Based on our telemetry the attacks were highly targeted and delivered to less than 10 victims around the world. The most prominent victims are two large regional diplomatic organizations in South-East Asia and Africa, while all the others were victims in South Asia.


The TunnelSnake campaign demonstrates the activity of a sophisticated actor that invests significant resources in designing an evasive toolset and infiltrating networks of high-profile organizations. By leveraging Windows drivers, covert communications channels and proprietary malware, the group behind it maintains a considerable level of stealth. That said, some of its TTPs, like the usage of a commodity webshell and open-source legacy code for loading unsigned drivers, may get detected and in fact were flagged by our product, giving us visibility into the group’s operation.

Still, with activity dating back to at least 2018, the threat actor behind this campaign has shown that it is able to evolve and tailor its toolset to target environments. This indicates the group conducting these attacks may well still be active and retooling for additional operations in the area of interest outlined in this publication, as well as other regions. With that in mind, we continue to track this attacker and look for signs of its reappearance in the wild. Any findings and updates will be made available to customers of our Threat Intelligence Portal.

For more information about operation TunnelSnake and the underlying threat actor, contact us at: intelreports@kaspersky.com.
To learn more on reverse engineering and malware analysis from Kaspersky GReAT experts, check out the website http://xtraining.kaspersky.com.

IOCs 48307C22A930A2215F7601C78240A5EE Moriya Agent A2C4EE84E3A95C8731CA795F53F900D5 Moriya 64-bit Driver 5F0F1B0A033587DBCD955EDB1CDC24A4 IISSpy C1159FE3193E8B5206006B4C9AFBFE62 ProcessKiller DA627AFEE096CDE0B680D39BD5081C41 ProcessKiller Driver – 32-bit 07CF58ABD6CE92D96CFC5ABC5F6CBC9A ProcessKiller Driver – 64-bit 9A8F39EBCC580AA56D6DDAF5804EAE61 pv.tmp (Custom PSExec Server) 39C361ABB74F9A338EA42A083E6C7DF8 pc.tmp (Custom PsExec Client) DE3FB65461EE8A68A3C7D490CDAC296D tran.tmp (Exfiltration tool) EAC0E57A22936D4C777AA121F799FEE6 client.exe (Utility embedded in tran.tmp) D745174F5B0EB41D9F764B22A5ECD357 rasauto.dll (Bouncer Loader) 595E43CDF0EDCAA31525D7AAD87B7BE4 8.tmp (HTTP )Scanner 9D75B50727A8E732DB0ADE7E270A7395 ep.tmp DCOM Scanner 3A4E1F3F7E1BAAB8B02F3A8EE20F98C9 nw.tmp Bouncer Loader 47F2D06713DAD556F535E523B777C682 Termite 45A5D9053BC90ED657FA90DE0B775E8F Earthworm

[1] Today a copy of the original code can be found here: http://www.m5home.com/bbs/thread-8043-1-1.html

[2] https://www.fireeye.com/content/dam/fireeye-www/services/pdfs/mandiant-apt1-report.pdf

2021. május 3.

Spam and phishing in Q1 2021

Quarterly highlights Banking phishing: new version of an old scheme

In Q1 2021, new banking scams appeared alongside ones that are more traditional. Clients of several Dutch banks faced a phishing attack using QR codes. The fraudsters invited the victim to scan a QR code in an email, ostensibly to unblock mobile banking. In actual fact, scanning the code resulted in a data leak, money theft or device infection, if it contained a link to a web page with malware.

To lure users to their sites, phishers exploited the COVID-19 topic. In particular, in a newsletter purporting to be from the MKB bank, recipients were asked to catch up on the latest news about the pandemic and measures taken by the bank. The link pointed to a fake Outlook authorization page.

This past year, cybercriminals have actively exploited the topic of government payouts, most often in relation to damage caused by the pandemic. In Q1 2021, scammers imitating bank emails began to focus on compensation. The links in their messages took the victim to a well-designed phishing pages with official emblems, business language and references to relevant laws. The attacks were mostly aimed at stealing any card details and personal data.

However, users of specific banks were also targeted. In this case, the focus was on copying the external attributes of the bank’s website to create a near-indistinguishable phishing version.

Vaccine with cyberthreat

COVID-19 vaccination was one of the hottest global topics, and hence highly attractive to scammers. Cybercriminals took advantage of people’s desire to get vaccinated as quickly as possible. For instance, some UK residents received an email that appeared to come from the country’s National Health Service. In it, the recipient was invited to be vaccinated, having first confirmed their participation in the program by clicking on the link.

In another mailing, the attackers focused on age — people over 65 were asked to contact a clinic to receive a vaccine.

In both cases, to make a vaccination appointment, a form had to be filled out with personal data; and in the first case, the phishers also wanted bank card details. If the victim followed all the instructions on the fake website, they handed their money and personal data to the attackers.

Another way to gain access to users’ personal data and purse strings was through fake vaccination surveys. Scammers sent out emails in the name of large pharmaceutical companies producing COVID-19 vaccines, or of certain individuals. The message invited the recipient to take part in a short survey.

Participants were promised a gift or cash reward for their help. After answering the questions, the victim was redirected to a page with the “gift.”

Having consented to receive the prize, the user was asked to fill out a detailed form with personal information. In some cases, the attackers also asked for payment of a token amount for delivery. However, if the victim went ahead and entered their bank card details, the amount charged was several times higher. Needless to say, no gift materialized.

The vaccination topic could hardly be ignored by spammers offering services on behalf of Chinese manufacturers. The emails mentioned lots of products related to diagnosis and treatment of the virus, but the emphasis was on the sale of vaccination syringes.

Such offers may look very favorable, but the likelihood of a successful deal is zero. Most if not all of the time, the “business partners” simply vanish into thin air after receiving the agreed prepayment.

Corporate segment: on-the-job fraud

Corporate usernames and passwords remain a coveted prize for scammers. To counter people’s increasingly wary attitude to emails from outside, attackers try to give their mailings a respectable look, disguising them as messages from business tools and services. By blending into the workflow, the scammers calculate that the user will be persuaded to follow the link and enter data on a fake page. For example, a “notification” from Microsoft Planner invited the user to review their tasks for the coming month. The link redirected them to a phishing page requesting their Microsoft account credentials.

In the Runet (Russian internet), we found an email seemingly from the support department of an analytics portal. The messages talked about recent updates and suggested checking the availability of the resource. The link also required entering corporate account credentials.

Old techniques, such as creating a unique fake page using JavaScript, were combined in Q1 with overtly business-themed phishing emails. If previously scammers used common, but not always business-oriented services as bait, the new batch of emails cited an urgent document awaiting approval or contract in need of review.

Every little bit helps

Since the end of last year, we have observed fraudulent emails and fake pages urging users to pay a small sum for certain services. The payment indicated in the fake email was often so tiny that the potential victim could ignore the risks. For example, in one of the emails below, the cybercriminals ask for just 1.99 rubles (US$0.027). The calculation was simple: users would be less averse to paying a small amount than a larger one, which means more potential victims willing to enter card details on the bogus site. To make the emails more convincing, they imitated commonly used services. For example, delivery services — messages from which are often faked — led the field. The potential victim was asked to pay for customs clearance or package delivery. However, the scammers did not fake the courier service emails very well: they were readily given away by the address in the From field or by the invalid tracking number indicated in the email.

Besides delivery, scammers found other reasons for mailing out “invoices.” In particular, fake notifications about payment for domain usage or even an expired WhatsApp subscription did the rounds. In the latter case, the very mention of a paid subscription should sound an alarm, since even the business version of WhatsApp is free.

Although the scammers asked for a token payment in the email, in reality, if successful, they siphoned off far more than that from the victims’ account, and swiped their bank card details. This danger is ever-present when entering data on dubious websites.

Intrigue: emails from strangers

In March, we identified a targeted mailing to the addresses of an educational institution. The email reported a hack of the database of the school’s partner company, which resulted in the intruders getting their hands on the personal data of students and employees. The company refused to pay the ransom, so now the school administration must prepare for the worst: the data might find its way onto darknet, and from there to even worse criminals, who could use it to enter the school building under the guise of an employee. To convince the school leaders of the reality of the looming threat, the email authors advised clicking the provided link and viewing a portion of the stolen database. The link led to a site in the .onion domain, which can only be opened using the Tor browser. Behind the link was a C&C server that was accessed by malware (various ransomware, including Trojan-Banker.Win32.Danabot). A link to this resource was also contained in ransom messages from the attackers, and in some cases malware was downloaded from it. If a curious employee visited this resource, they risked launching the ransomware in the school’s network or facing a demand to pay the ransom on behalf of the partner company.

Cybercriminals adopted an interesting tactic to attack Facebook users. The potential victim received an email saying that their account had violated the social network’s terms of use. To avoid the account being deleted, the scammers advised the recipient to follow the link and lodge an appeal. At the same time, the window for doing so was very short so as to hurry the victim into acting quickly without scrutinizing the message. The email would have been no different from any other aimed at stealing Facebook credentials, but for one nuance: the link in the message pointed to an actual Facebook page.

Resembling an official notice, the page stated that an erroneous decision to block an account could be disputed by following the link provided. In reality, it was a note in a Facebook user’s profile, which the sharp-eyed user could have discerned from the word “notes” in the address. Clicking the link in the note took the victim straight to a phishing site. The attackers’ calculation was simple: first lull the victim’s vigilance with a legitimate link, then get them to enter their credentials on a fake page.

Statistics: spam Proportion of spam in mail traffic

In Q1 2021, the share of spam in global mail traffic continued to decline and averaged 45.67%, down 2.11 p.p. against Q4 2020 (47.78%).

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Proportion of spam in global email traffic, Q4 2020 and Q1 2021 (download)

The highest percentage of junk mail was recorded in January (46.12%). This is 0.71 p.p. less than the lowest figure in 2020 (46.83%). The calmest month was March, in which spam accounted for only 45.10% of all emails.

In the Runet, the average share of spam was also lower than in Q4 48.56% versus 50.25%. As was generally the case worldwide, the most turbulent month of the reporting period was January (49.76%), and the quietest was March (47.17%). In contrast to the global picture, January’s share of spam in the Runet was 1.30 p.p. higher than December’s (49.76% versus 48.46%).

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Proportion of spam in Runet mail traffic, Q4 2020 and Q1 2021 (download)

Sources of spam by country

In 2020, Russia and Germany led the pack by volume of outgoing spam. In Q1 2021, they remained out in front: Russia accounted for 22.47% of spam, and Germany’s share was 14.89%. Third place went to the US (12.98%), and fourth to China (7.38%).

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Sources of spam by country, Q1 2021 (download)

The Netherlands (4.18%) ranked fifth, followed by France (3.69%) and Spain (3.39%). Poland (2.39%), Brazil (2.37%) and Japan (2.23%) round out the Top 10.

Malicious mail attachments

In Q1 2021, Kaspersky solutions detected 38,195,315 malicious mail attachments. This is almost 3 million fewer than in the last three months of 2020. That said, the number of attachments blocked by Mail Anti-Virus grew during the quarter.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Number of Mail Anti-Virus triggerings, Q4 2020 and Q1 2021 (download)

Malware families

The most common Trojans detected by our solutions in mail attachments came from the Agensla family (8.91%). These malicious programs specialize in stealing credentials from browsers, as well as from mail and FTP clients. In second place came exploits for the CVE-2017-11882 vulnerability in the Microsoft Equation Editor component, which were detected in 6.38% of cases. Third position this time was taken by Trojans from the Badun family (5.79%). Malicious programs disguised as e-documents are detected with this verdict. Malware from the Badun family most often spreads through archives.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Top 10 malware families in mail traffic, Q1 2021 (download)

Fourth place went to SAgent (4.98%) — documents containing a VBA script that runs PowerShell to covertly download other malware. The fifth- and sixth-placed families are Taskun (3.79%) — programs that create malicious tasks in Windows Task Scheduler, and ISO (3.69%) — malicious disk images distributed by email. In seventh place is the Noon spyware (2.41%), which steals passwords from browsers and reads keystrokes. In eighth is the Crypt family (2.16%), which consists of highly obfuscated or encrypted software. The Top 10 is rounded out by Androm backdoors (2.05%) and worms coded in Visual Basic (1.66%).

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Top 10 malicious attachments, Q1 2021 (download)

The Top 10 most common malicious attachments in Q4 corresponds exactly to the ranking of families. This suggests that each of the above-described families was widespread largely due to one member.

Countries targeted by malicious mailings

Our solutions registered the largest number of attempts to open malicious attachments in Spain (8.74%). This country was the top malicious mailing target throughout 2020, and held on to first place in this reporting quarter. Italy (7.59%) moved up to second place, and third place went to Germany (5.84%).

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Countries targeted by malicious mailings, Q1 2021 (download)

In fourth position in Q1 was the UAE (5.25%), with Russia (4.88%) closing out the Top 5.

Statistics: phishing

In Q1 2021, our Anti-Phishing system prevented 79,608,185 attempted redirects to fraudulent websites. 5.87% of Kaspersky users encountered phishing, and 695,167 new masks were added to the anti-phishing databases.

Geography of phishing attacks

This quarter, phishing attacks affected a relatively small proportion of our users, both overall and in specific countries. The leader was France, where 9.89% of all users of Kaspersky solutions tried to follow a fraudulent link at least once during the reporting period.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Distribution of phishing attacks by country, Q1 2021 (download)

Israel placed second and Hungary third, where 8.45% and 8.27% of users, respectively, encountered phishing pages. Meanwhile, Brazil (7.94%), which topped the rating in 2020, only managed ninth position in Q1.

Top-level domains

As usual, the largest share of phishing sites that users attempted to visit in the period January–March 2021 were located in the .com domain zone (32.80%). The second most popular domain among scammers this time around was .xyz (11.38%). Bronze goes to the .tk domain zone (3.24%), belonging to the Tokelau Islands, a dependent territory of New Zealand, in the Pacific Ocean. Tokelau domains are cheap to rent, and so popular with phishers.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Top-level domain zones most commonly used for phishing, Q1 2021 (download)

Also prevalent this quarter were phishing sites that were not assigned domain names (2.78%). Such resources were the fourth most popular. In fifth spot, just 0.01 p.p. behind, was the Russian domain .ru (2.77%).

Organizations under attack

The rating of organizations targeted by phishers is based on the triggering of the deterministic component in the Anti-Phishing system on user computers. The component detects all pages with phishing content that the user has tried to open by following a link in an email message or on the web, as long as links to these pages are present in the Kaspersky database.

The Top 10 organizations used by phishers as bait remained practically unchanged in Q1 relative to 2020. Online stores (15.77%) still lead the way, followed by global internet portals (15.50%) and banks (10.04%). Fraudsters’ continued targeting of users of electronic trading platforms is explained by the pandemic-related restrictions that remained in force in many countries this quarter.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Distribution of organizations targeted by phishers, by category in Q1 2021 (download)


In Q1 2021, we largely saw a continuation of the 2020 trends. Cybercriminals are still actively using the COVID-19 theme to entice potential victims. And as coronavirus vaccination programs have been rolled out, spammers have adopted it as bait. Corporate account hunters continue to hone their techniques to make their emails as convincing as possible. Meanwhile, phishers who prey on personal accounts are still actively spoofing the websites of online stores, which have risen in popularity due to the pandemic.

Attackers will likely carry on exploiting the COVID-19 vaccination topic in Q2. Moreover, we can expect new fraudulent schemes to emerge. Scams related to compensation for damages caused to individuals and companies worldwide will not go away any time soon, too. Moreover, Q2 may see an associated rise in the number of fraudulent schemes offering payments from governments or other structures. And as the summer season approaches, an increase in the number of emails related to tourism is possible; however, due to the pandemic, it is likely to be small. On the other hand, cybercriminals will almost certainly continue to actively hunt corporate account credentials, exploiting the fact that many companies are still in remote working mode and communication among employees is predominantly online.

2021. április 27.

APT trends report Q1 2021

For four years, the Global Research and Analysis Team (GReAT) at Kaspersky has been publishing quarterly summaries of advanced persistent threat (APT) activity. The summaries are based on our threat intelligence research and provide a representative snapshot of what we have published and discussed in greater detail in our private APT reports. They are designed to highlight the significant events and findings that we feel people should be aware of.

This is our latest installment, focusing on activities that we observed during Q1 2021.

Readers who would like to learn more about our intelligence reports or request more information on a specific report are encouraged to contact intelreports@kaspersky.com.

The most remarkable findings

In December, SolarWinds, a well-known IT managed services provider, fell victim to a sophisticated supply-chain attack. The company’s Orion IT, a solution for monitoring and managing customers’ IT infrastructure, was compromised. This resulted in the deployment of a custom backdoor, named Sunburst, on the networks of more than 18,000 SolarWinds customers, including many large corporations and government bodies, in North America, Europe, the Middle East and Asia. In our initial report on Sunburst, we examined the method used by the malware to communicate with its C2 (command-and-control) server and the protocol used to upgrade victims for further exploitation. Further investigation of the Sunburst backdoor revealed several features that overlap with a previously identified backdoor known as Kazuar, a .NET backdoor first reported in 2017 and tentatively linked to the Turla APT group. The shared features between Sunburst and Kazuar include the victim UID generation algorithm, code similarities in the initial sleep algorithm and the extensive usage of the FNV1a hash to obfuscate string comparisons. There are several possibilities: Sunburst may have been developed by the same group as Kazuar; the developers of Sunburst may have adopted some ideas or code from Kazuar; both groups obtained their malware from the same source; some Kazuar developers moved to another team, taking knowledge and tools with them; or the developers of Sunburst introduced these links as a form of false flag. Hopefully, further analysis will make things clearer.

On March 2, Microsoft reported a new APT actor named HAFNIUM, exploiting four zero-days in Exchange Server in what they called “limited and targeted attacks”. At the time, Microsoft claimed that, in addition to HAFNIUM, several other actors were exploiting them as well. In parallel, Volexity also reported the same Exchange zero-days being in use in early 2021. According to Volexity’s telemetry, some of the exploits in use are shared across several actors, besides the one Microsoft designates as HAFNIUM. Kaspersky telemetry revealed a spike in exploitation attempts for these vulnerabilities following the public disclosure and patch from Microsoft. During the first week of March, we identified approximately 1,400 unique servers that had been targeted, in which one or more of these vulnerabilities were used to obtain initial access. Prior to the posts, on February 28, we identified related exploitation on less than a dozen Exchange systems; we also found more than a dozen Exchange artefacts indicating exploitation uploaded to multi-scanner services. According to our telemetry, most exploitation attempts were observed for servers in Europe and the United States. Some of the servers were targeted multiple times by what appear to be different threat actors (based on the command execution patterns), suggesting the exploits are now available to multiple groups.

We have also discovered a campaign active since mid-March targeting governmental entities in the Russian Federation, using the aforementioned Exchange zero-day exploits. This campaign made use of a previously unknown malware family we dubbed FourteenHi. Further investigation revealed traces of activity involving variants of this malware dating back a year. We also found some overlaps in these sets of activities with HAFNIUM in terms of infrastructure and TTPs as well as the use of ShadowPad malware during the same timeframe.


During routine monitoring of detections for FinFisher spyware tools, we discovered traces that point to recent FinFly Web deployments. In particular, we discovered two servers with web applications that we suspect, with high confidence, were generated using FinFly Web. FinFly Web is, in essence, a suite of tools and packages that implement a web-based exploitation server. It was first publicly documented in 2014, in the aftermath of the Gamma Group hacking incident. One of the suspected FinFly Web servers was active for more than a year between October 2019 and December 2020. This server was disabled a day after our discovery last December. Nevertheless, we were able to capture a copy of its landing page, which included JavaScript used to profile victims using what appears to be previously unknown code. In the second case, the server hosting FinFly Web was already offline at the moment of discovery, so we drew our conclusions using available historical data. As it turned out, it was active for a very short time around September 2020 on a host that appears to have been impersonating the popular Mail.ru service. Surprisingly, this server began answering queries again on January 12. So far, we haven’t seen any related payloads being dropped by these web pages.

Russian-speaking activity

Kazuar is a .NET backdoor usually associated with the Turla threat actor (aka Snake and Uroboros). Recently, Kazuar received renewed interest due to its similarities with the Sunburst backdoor. Although the capabilities of Kazuar have already been exposed in public research, many interesting facts about this backdoor were not made public. Our latest reports focus on the changes the threat actor made to the September and November versions of its backdoor.

On February 24, the National Security Defense Council of Ukraine (NSDC) publicly warned that a threat actor had exploited a national documents circulation system (SEI EB) to distribute malicious documents to Ukrainian public authorities. The alert contained a few related network IoCs, and specified that the documents used malicious macros in order to drop an implant onto targeted systems. Thanks to the shared IoCs, we were able to attribute this attack, with high confidence, to the Gamaredon threat actor. The malicious server IP mentioned by the NSDC has been known to Kaspersky since February as Gamaredon infrastructure.

On January 27, the French national cybersecurity agency (ANSSI) published a report describing an attack campaign that targeted publicly exposed and obsolete Centreon systems between 2017 and 2020, in order to deploy Fobushell (aka P.A.S.) webshells and Exaramel implants. ANSSI associated the campaign with the Sandworm intrusion-set, which we refer to as Hades. Although we specifically looked for additional compromised Centreon systems, Exaramel implant samples or associated infrastructure, we were unable to retrieve any useful artifacts from which we could initiate a comprehensive investigation. However, we did identify three Centreon servers where a Fobushell webshell had been deployed. One of those Fobushell samples was identical to another we previously identified on a Zebrocy C2 server.

Chinese-speaking activity

We discovered a set of malicious activities, which we named EdwardsPheasant, targeting mainly government organizations in Vietnam since June 2020. The attackers leverage previously unknown and obfuscated backdoors and loaders. The activities peaked in November 2020, but are still ongoing. The associated threat actor continues to leverage its tools and tactics (described in our private report) to compromise targets or maintain access in their networks. While we could identify similarities with the tools and tactics associated with Cycldek (aka Goblin Panda) and Lucky Mouse (aka Emissary Panda), we have been unable to attribute this set of activities to either of them conclusively.

We investigated a long-running espionage campaign, dubbed A41APT, targeting multiple industries, including the Japanese manufacturing industry and its overseas bases, which has been active since March 2019. The attackers used vulnerabilities in an SSL-VPN product to deploy a multi-layered loader we dubbed Ecipekac (aka DESLoader, SigLoader and HEAVYHAND). We attribute this activity to APT10 with high confidence. Most of the discovered payloads deployed by this loader are fileless and have not been seen before. We observed SodaMaster (aka DelfsCake, dfls and DARKTOWN), P8RAT (aka GreetCake and HEAVYPOT), and FYAnti (aka DILLJUICE Stage 2) which in turn loads QuasarRAT. In November and December 2020, two public blog posts were published about this campaign. One month later, we observed new activities from the actor with an updated version of some of their implants designed to evade security products and make analysis harder for researchers. You can read more in our public report.

Middle East

We recently came across previously unknown malicious artifacts that we attributed to the Lyceum/Hexane threat group, showing that the attackers behind it are still active and have been developing their toolset during the last year. Although Lyceum still prefers taking advantage of DNS tunneling, it appears to have replaced the previously documented .NET payload with a new C++ backdoor and a PowerShell script that serve the same purpose. Our telemetry revealed that the threat group’s latest endeavors are focused on going after entities within one country – Tunisia. The victims we observed were all high-profile Tunisian organizations, such as telecommunications or aviation companies. Based on the targeted industries, we assume that the attackers may have been interested in compromising these entities to track the movements and communications of individuals that are of interest to them. This could mean that the latest Lyceum cluster has an operational focus on targeting Tunisia, or that it is a subset of broader activity that is yet to be discovered.

On November 19, 2020, Shadow Chaser Group tweeted about a suspected MuddyWater APT malicious document potentially targeting a university in the United Arab Emirates. Based on our analysis since then, we suspect this intrusion is part of a campaign that started at least in early October 2020 and was last seen active in late December 2020. The threat actor relied on VBS-based malware to infect organizations from government, NGO and education sectors. Our telemetry, however, indicates that no further tools were deployed and we do not believe that data theft took place either. This indicates to us that the attackers are currently in the reconnaissance phase of their operation, and we expect subsequent waves of attacks to follow in the near future. In our private report, we provide an in-depth analysis of the malicious documents used by this threat actor and study their similarities to known MuddyWater tooling. The infrastructure setup and communications scheme are also similar to past incidents attributed to this group. The actor maintains a small set of first-stage C2 servers to connect back from the VBS implant for initial communications. Initial reconnaissance is performed by the actor and communication with the implant is handed off to a second-stage C2 for additional downloads. Finally, we present similarities with known TTPs of the MuddyWater group and attribute this campaign to them with medium confidence.

Domestic Kitten is a threat group mainly known for its mobile backdoors. The group’s operations were exposed in 2018, showing that it was conducting surveillance attacks against individuals in the Middle East. The threat group targeted Android users by sending them popular and well-known applications that were backdoored and contained malicious code. Many of the applications had religious or political themes and were intended for Farsi, Arabic and Kurdish speakers, possibly alluding to this attack’s main targets. We have discovered new evidence showing that Domestic Kitten has been using PE executables to target victims using Windows since at least 2013, with some evidence that it goes back to 2011. The Windows version, which, to the best of our knowledge, has not been described in the past, was delivered in several versions, with the more recent one used for at least three and a half years to target individuals in parallel to the group’s mobile campaigns. The implant functionality and infrastructure in that version have remained the same all along, and have been used in the group’s activity witnessed this year.

Ferocious Kitten is an APT group that has been active against Persian-speaking individuals since 2015 and appears to be based in Iran. Although it has been active over a large timespan, the group has mostly operated under the radar and, to the best of our knowledge, has not been covered by security researchers. It only recently attracted attention when a lure document was uploaded to VirusTotal and was brought to public knowledge by researchers on Twitter. Subsequently, one of its implants was analyzed by a Chinese intelligence firm. We have been able to expand some of the findings on the group and provide insights on additional variants. The malware dropped from the aforementioned document is dubbed MarkiRAT and is used to record keystrokes and clipboard content, provide file download and upload capabilities as well as the ability to execute arbitrary commands on the victim’s machine. We were able to trace the implant back to at least 2015, along with variants intended to hijack the execution of the Telegram and Chrome applications as a persistence method. Interestingly, some of the TTPs used by this threat actor are reminiscent of other groups operating in the domain of dissident surveillance. For example, it used the same C2 domains across its implants for years, which was witnessed in the activity of Domestic Kitten. In the same vein, the Telegram execution hijacking technique observed in this campaign by Ferocious Kitten was also observed being used by Rampant Kitten, as covered by Check Point. In our private report, we expand the details on these findings as well as provide analysis and mechanics of the MarkiRAT malware.

Karkadann is a threat actor that has been targeting government bodies and news outlets in the Middle East since at least October 2020. The threat actor leverages tailor-made malicious documents with embedded macros that trigger an infection chain, opening a URL in Internet Explorer. The minimal functionality present in the macros and the browser specification suggest that the threat actor might be exploiting a privilege-escalation vulnerability in Internet Explorer. Despite the small amount of evidence available for analysis in the Karkadann case, we were able to find several similarities to the Piwiks case, a watering-hole attack we discovered that targeted multiple prominent websites in the Middle East. Our private report presents the recent Karkadann campaigns and the similarities between this campaign and the Piwiks case. The report concludes with some infrastructure overlaps with unattributed clusters that we have seen since last year that are potentially linked to the same threat actor.

Southeast Asia and Korean Peninsula

We discovered that the Kimsuky group adopted a new method to deliver its malware in its latest campaign on a South Korean stock trading application. In this campaign, beginning in December 2020, the group compromised a website belonging to the vendor of stock trading software, replacing the hosted installation package with a malicious one. Kimsuky also delivered its malware by utilizing a malicious Hangul (HWP) document containing COVID-19-related bait that discusses a government relief fund. Both infection vectors ultimately deliver the Quasar RAT. Compared to Kimsuky’s last reported infection chain, composed of various scripts, the new scheme adds complications and introduces less popular file types, involving VBS scripts, XML and Extensible Stylesheet Language (XSL) files with embedded C# code in order to fetch and execute stagers and payloads. Based on the lure document and characteristics of the compromised installation package, we conclude that this attack is financially motivated, which, as we have previously reported, is one of Kimsuky’s main focus areas.

On January 25, the Google Threat Analysis Group (TAG) announced that a North Korean-related threat actor had targeted security researchers. According to Google TAG’s blog, this actor used highly sophisticated social engineering, approached security researchers through social media, and delivered a compromised Visual Studio project file or lured them to their blog and installed a Chrome exploit. On March 31, Google TAG released an update on this activity showing another wave of fake social media profiles and a company the actor set up mid-March. We can confirm that several infrastructures on the blog overlap with our previously published reporting about Lazarus group’s ThreatNeedle cluster. Moreover, the malware mentioned by Google matched ThreatNeedle – malware that we have been tracking since 2018. While investigating associated information, a fellow external researcher confirmed that he was also compromised by this attack, sharing information for us to investigate. We discovered additional C2 servers after decrypting configuration data from the compromised host. The servers were still in use during our investigation, and we were able to get additional data, analyzing logs and files present on the servers. We assess that the published infrastructure was used not only to target security researchers but also in other Lazarus attacks. We found a relatively large number of hosts communicating with the C2s at the time of our research. You can read our public report here.

Following up our previous investigation into Lazarus attacks on the defense industry using ThreatNeedle, we discovered another malware cluster named CookieTime used in a campaign mainly focused on the defense industry. We detected activity in September and November 2020, with samples dating back to April 2020. Compared to the already known malware clusters of the Lazarus group, CookieTime shows a different structure and functionality. This malware communicates with the C2 server using the HTTP protocol. In order to deliver the request type to the C2 server, it uses encoded cookie values and fetches command files from the C2 server. The C2 communication takes advantage of steganography techniques, delivered in files exchanged between infected clients and the C2 server. The contents are disguised as GIF image files, but contain encrypted commands from the C2 server and command execution results. We had a chance to look into the command and control script as a result of working closely with a local CERT to take down the threat actor’s infrastructure. The malware control servers are configured in a multi-stage fashion and only deliver the command file to valuable hosts.

While investigating the artifacts of a supply-chain attack on the Vietnam Government Certification Authority’s (VGCA) website, we discovered that the first Trojanized package dates to June 2020. Unravelling that thread, we identified a number of post-compromise tools in the form of plugins deployed using PhantomNet malware, which was delivered using Trojanized packages. Our analysis of these plugins revealed similarities with the previously analyzed CoughingDown malware. In our private report, we offer a detailed description for each post-compromise tool used in the attack, as well as other tools belonging to the actor’s arsenal. Finally, we also explore CoughingDown attribution in the light of recent discoveries.

On February 10, DBAPPSecurity published details about a zero-day exploit they discovered last December. Aside from the details of the exploit itself, researchers also mentioned it being used in the wild by BitterAPT. While no such subsequent information was given in the initial report to explain the attribution claims, our investigation into this activity confirms the exploit was in fact being used exclusively by this actor. We assigned the name TurtlePower to the campaign that makes use of this exploit, along with the other tools used to target governmental and telecom entities in Pakistan and China. We have also confidently linked the origin of this exploit to a broker we refer to as Moses. Moses has been responsible for the development of at least five exploits patched in the last two years. We have also been able to tie the usage of some of these exploits to at least two different actors thus far – BitterAPT and DarkHotel. At this time, it is unclear how these threat actors are obtaining exploits from Moses, whether it is through direct purchase or another third-party provider. During the TurtlePower campaign, BitterAPT used a wide array of tools on its victims to include a stage one payload named ArtraDownloader, a stage two payload named Splinter, a keylogger named SourLogger, an infostealer named SourFilling, as well as variations of Mimikatz to gather specific files and maintain its access. This particular campaign also appears to be narrowly focused on targets within Pakistan and China (based on the initial report referenced). While we can verify specific targeting within Pakistan using our own data, we have not been able to do the same regarding China. Use of CVE-2021-1732 peaked between June and July 2020, but the overall campaign is still ongoing.

In 2020, we observed new waves of attacks related to Dropping Elephant (aka Patchwork, Chinastrats), focusing on targets in China and Pakistan. We also noted a few targets outside of the group’s traditional area of operations, namely in the Middle East, and a growing interest in the African continent. The attacks followed the group’s well-established TTPs, which include the use of malicious documents crafted to exploit a remote code execution vulnerability in Microsoft Office, and the signature JakyllHyde (aka BadNews) Trojan in the later infection stages. Dropping Elephant introduced a new loader for JakyllHyde, a tool we named Crypta. It contains mechanisms to hinder detection and appears to be a core component of this APT actor’s recent toolset. Crypta and its variants have been observed in multiple scenarios loading a wide range of subsequent payloads, such as Bozok RAT, Quasar RAT and LokiBot. An additional Trojan discovered during our research was PubFantacy. To our knowledge, this tool has never been publicly described and has been used to target Windows servers since at least 2018.

We recently discovered a previously publicly unknown Android implant used in 2018-2019 by the SideWinder threat group, which we dubbed BroStealer. The main purpose of the BroStealer implant is to collect sensitive information from a victim’s device, such as photos, SMS messages, call recordings and files from various messaging applications. Although SideWinder has numerous campaigns against victims using the Windows platform, recent reports have shown that this threat group also goes after its targets via the mobile platform.

Other interesting discoveries

In February 2019, multiple antivirus companies received a collection of malware samples, most of them associated with various known APT groups. Some of the samples cannot be associated with any known activity. Some, in particular, attracted our attention due to their sophistication. The samples were compiled in 2014 and, accordingly, were likely deployed in 2014 and possibly as late as 2015. Although we have not found any shared code with any other known malware, the samples have intersections of coding patterns, style and techniques that have been seen in various Lambert families. We therefore named this malware Purple Lambert. Purple Lambert is composed of several modules, with its network module passively listening for a magic packet. It is capable of providing an attacker with basic information about the infected system and executing a received payload. Its functionality reminds us of Gray Lambert, another user-mode passive listener. Gray Lambert turned out to be a replacement of the kernel-mode passive-listener White Lambert implant in multiple incidents. In addition, Purple Lambert implements functionality similar to, but in different ways, both Gray Lambert and White Lambert. Our report, available to subscribers of our APT threat reports, includes discussion of both the passive-listener payload and the loader functionality included in the main module.

Final thoughts

While the TTPs of some threat actors remain consistent over time, relying heavily on social engineering as a means of gaining a foothold in a target organization or compromising an individual’s device, others refresh their toolsets and extend the scope of their activities. Our regular quarterly reviews are intended to highlight the key developments of APT groups.

Here are the main trends that we’ve seen in Q1 2021:

  • Perhaps the most predominant attack we researched in this quarter was the SolarWinds attack. SolarWinds showed once again how successful a supply-chain attack can be, especially where attackers go the extra mile to remain hidden and maintain persistence in a target network. The scope of this attack is still being investigated as more zero-day flaws are discovered in SolarWinds products.
  • Another critical wave of attacks was the exploitation of Microsoft Exchange zero-day vulnerabilities by multiple threat actors. We recently discovered another campaign using these exploits with different targeting, possibly related to the same cluster of activities already reported.
  • Lazarus group’s bold campaign targeting security researchers worldwide also utilized zero-day vulnerabilities in browsers to compromise their targets. Their campaigns used themes centered on the use of zero-days to lure relevant researchers, possibly in an attempt to steal vulnerability research.

As always, we would note that our reports are the product of our visibility into the threat landscape. However, it should be borne in mind that, while we strive to continually improve, there is always the possibility that other sophisticated attacks may fly under our radar.


2021. április 23.

Ransomware by the numbers: Reassessing the threat’s global impact

Kaspersky has been following the ransomware landscape for years. In the past, we’ve published yearly reports on the subject: PC ransomware in 2014-2016, Ransomware in 2016-2017, and Ransomware and malicious crypto miners in 2016-2018. In fact, in 2019, we chose ransomware as the story of the year, upon noticing the well-known threat was shifting its attention to municipalities. In the 2010s, with campaigns like WannaCry and NotPetya, ransomware became mainstream news. However, starting in 2018, we began noticing something else: the statistics for the overall number of ransomware detections were on a steep decline. What was happening? Was ransomware, in fact, a dying species of malware?

For anyone following the news in the infosecurity community, this seemed unlikely. In 2019 and 2020, stories of ransomware attacks made front-page headlines, from Maze attacking LG to the infamous APT group Lazarus adding ransomware to its arsenal. In the United States alone in 2020, ransomware hit more than 2,300 government entities, healthcare facilities and schools, according to the security company Emsisoft.

So, what’s the story?

Ransomware hasn’t disappeared; the threat has just undergone a fundamental shift. Widespread ransomware campaigns have been replaced with highly targeted, destructive attacks, often aimed at large organizations. In addition, attackers appear to be more focused on exfiltrating data as well as encrypting it, i.e., siphoning off confidential information and threatening to make it public if the victims refuse to pay. All of this is done with the aim of launching fewer attacks, each with a far larger payout, rather than collecting smaller amounts from a massive number of victims.

In this report, we’ll take a look at the numbers behind the ransomware threat from 2019 to 2020, what they mean — and what they foretell about ransomware’s future.

Key findings
  • In 2020, the number of unique users that encountered ransomware on their devices was 1,091,454, a decline from 1,537,465 in 2019.
  • In 2019, the share of users targeted with ransomware among the overall number of users that encountered malware was 3.31%; this declined slightly in 2020 to 2.67%.
  • The share of ransomware detections among the overall number of malware detections was 1.49% in 2019 and 1.08% in 2020.
  • In both 2019 and 2020, WannaCry was the most frequently encountered crypto-ransomware family on Windows systems.
  • In 2019, the number of unique users that encountered ransomware on their mobile devices was 72,258. This number declined to 33,502 in 2020.
  • However, the share of unique users that encountered ransomware on their mobile devices among the overall number of users that encountered malware held steady between 2019 and 2020 at 0.56%.
  • From 2019 to 2020, the number of unique users affected by targeted ransomware families increased by 767%.
  • By far, the industry that contained the greatest share of targeted ransomware attacks was engineering and manufacturing, at 25.63%.

This report has been prepared using depersonalized data processed by Kaspersky Security Network (KSN).

There are two main metrics used. The first, unique users, refers to the number of distinct users of Kaspersky products with the KSN feature enabled who encountered ransomware at least once in a given period. The second is detections, which is the number of ransomware attacks blocked by Kaspersky products over a given period.

The report also includes research into the threat landscape by Kaspersky experts.

Kaspersky products detect various types of ransomware. These include crypto-ransomware (malware that encrypts your files), screen lockers, browser lockers, and boot lockers. Unless otherwise stated, statistics refer to any type of ransomware.

Ransomware across all platforms

As Kaspersky has previously noted, the total number of ransomware detections has been steadily declining since 2017. This is a trend that has continued through 2019 and 2020.

In 2019, the total number of unique users that encountered ransomware across all platforms was 1,537,465. In 2020, that number fell to 1,091,454 — a decrease of 29%.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Side-by-side comparison of the number of unique KSN users that encountered ransomware on their devices, 2019 – 2020 (download)

In fact, for each month in 2020, the number of unique users that encountered ransomware across all devices was lower than the number observed during the same month in the previous year. In both years, the number of users that encountered ransomware was relatively stable — hovering between 100,000 and 170,000 in 2020 and between 150,000 and 190,000 in 2019 — with the exception of July 2019, when there was a noticeable spike. This was driven by an increase in two ransomware families. The first, Bluff, is a browser locker, meaning victims are confronted with a fake tab — one they are unable to exit out of — that threatens dire consequences if a certain amount of money is not paid. The other was Rakhni, a crypto-ransomware that first appeared in 2013 and was distributed primarily through spam with malicious attachments.

The share of unique users that encountered ransomware out of the total number that encountered any type of malware across their devices also declined, from 3.31% in 2019 to 2.67% in 2020. However, the share of ransomware detections out of the total number of malware detections held relatively steady, declining only slightly from 2019 to 2020, from 1.49% to 1.08%.

The most active crypto-ransomware families

Three years after it first made headlines everywhere, WannaCry is still the most active crypto-ransomware family. To date, WannaCry is the largest ransomware infection in history, with damage totaling at least $4 billion across 150 countries. In 2019, 21.85% of users that encountered crypto-ransomware encountered WannaCry.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Top five crypto-ransomware families, 2019 (download)

Among other active families were GandCrab, a ransomware family that was active in 2019 and followed the RaaS model, STOP/DJVU, and PolyRansom/VirLock. Shade, a widespread cryptor that first appeared in 2014, was still one of the most active ransomware families in 2019, but its activity has been on the decline for years. In fact, in 2020, Kaspersky released a decryptor for all strains of Shade — and it was no longer one of the five most active ransomware families detected by Kaspersky products.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Top five crypto-ransomware families, 2020 (download)

In 2020, WannaCry was still the most frequently encountered family, with 16% of users (80,207) that encountered crypto-ransomware encountering this malware. In addition, a new strain entered the top five most active families: Crysis/Dharma. Crysis is able to use multiple attack vectors, although recently it has primarily exploited unsecured RDP access. First discovered in 2016, the malware has continued to evolve and is now following ransomware-as-a-service model.

In general, 2019 and 2020 continued a trend first noticed in early 2018: the consolidation of ransomware groups. Only a few notable families continue to maintain a significant presence across the threat landscape, with the rest of attacks conducted by ransomware Trojans that do not belong to any specific family. Of course, new families do continue to appear, with STOP and GandCrab serving as excellent examples.

Geography of ransomware attacks

When analyzing the geography of attacked users, we take into consideration the distribution of Kaspersky’s customers. That’s why, when examining the geography of attacks, we use the percentage of users attacked with ransomware as a proportion of users attacked with any kind of malware in those regions where there are more than 10,000 unique users of Kaspersky products.

All percentages reflect the percent of unique users that encountered ransomware at least once on any device out of the total number of unique users that encountered any type of malware over the stated period.

Middle East

In 2019, the countries with the greatest share of users that encountered ransomware on any device in the Middle East were as follows:

Country %* Pakistan 19.03% Palestine 6.74% Yemen 6.55% Egypt 6.41% Iraq 6.28%

*Share of users attacked with ransomware out of all users encountering malware in the country

Pakistan had, by far, the greatest share of users encountering ransomware: 19.03%. The other countries in the top five all had a share of roughly 6% of users that encountered ransomware.

In 2020, the five countries with the greatest share of users encountering ransomware remained the same with a few small adjustments.

Country %* Pakistan 14.88% Yemen 7.49% Egypt 6.45% Palestine 5.48% Iraq 5.37%

*Share of users attacked with ransomware out of all users encountering malware in the country

Pakistan still had the greatest share of users, but the overall percentage declined to 14.88%. The percent of users encountering ransomware in Yemen actually increased to 7.49%, while the percentage of users in Palestine and Iraq lowered, and the share of affected Egyptians remained pretty much the same.

North and South America

In 2019, the countries in North and South America with the greatest percentage of users that encountered ransomware were the following:

Country %* United States 5.49% Paraguay 4.87% Venezuela 3.34% Canada 3.25% Guatemala 2.81%

*Share of users attacked with ransomware out of all users encountering malware in the country

The United States had the greatest share at 5.49% percent, followed by Paraguay at 4.87%. Rounding out the countries with the greatest share of users encountering ransomware were Venezuela, Canada, and Guatemala.

In 2020, the countries with the greatest share in North and South America were mostly the same — although with a smaller percentage of users encountering ransomware.

Country %* United States 2.97% Venezuela 2.49% Canada 2.46% Paraguay 2.44% Uruguay 2.37%

*Share of users attacked with ransomware out of all users encountering malware in the country

year, Venezuela had the second greatest share of users encountering ransomware, with Paraguay falling to fourth. In addition, Guatemala was replaced by Uruguay.


In 2019, the countries in Africa with the greatest percentage of users encountering ransomware were the following:

Country %* Mozambique 12.02% Ethiopia 8.57% Ghana 5.75% Angola 3.32% Libya 3.28%

*Share of users attacked with ransomware out of all users encountering malware in the country

Mozambique had the greatest share of users by far at 12.02%, followed by Ethiopia at 8.57%. The remaining countries with the greatest percentage of users that encountered ransomware were Ghana, Angola, and Libya.

In 2020, the landscape shifted a bit:

Country %* Cameroon 6.83% Mali 5.85% Mozambique 5.62% Ethiopia 5.39% Ghana 3.85%

*Share of users attacked with ransomware out of all users encountering malware in the country

The country with the greatest share of users encountering ransomware was Cameroon, followed by Mali. Mozambique, Ethiopia, and Ghana remained in the top five, but the share of users facing ransomware declined for all three.


In Asia in 2019, the five countries with the greatest percentage of users encountering ransomware were the following:

Country %* Afghanistan 26.44% Bangladesh 23.14% Turkmenistan 11.28% Uzbekistan 10.53% Tajikistan 8.08%

*Share of users attacked with ransomware out of all users encountering malware in the country

Afghanistan had the greatest share of users at 26.44%, followed by Bangladesh at 23.14%. The next three countries with the greatest share of users were concentrated in Central Asia: Turkmenistan, Uzbekistan, and Tajikistan.

In 2020, the landscape slightly changed:

Country %* Afghanistan 17.67% Bangladesh 11.31% Turkmenistan 9.52% Tajikistan 5.26% Kyrgyzstan 4.05%

*Share of users attacked with ransomware out of all users encountering malware in the country

Uzbekistan left the rating of countries with the greatest share of users encountering ransomware, giving way to Kyrgyzstan (4.05%), and the percentages of all the rest were significantly lower than in 2019. Afghanistan’s share of users declined to 17.67% and Bangladesh’s to 11.31%.


In Europe, the countries with the greatest percentage of users encountering ransomware were the following:

Country %* Azerbaijan 5.03% Turkey 3.03% Cyprus 2.82% France 2.74% Armenia 2.54% Bulgaria 2.54%

*Share of users attacked with ransomware out of all users encountering malware in the country

Azerbaijan had the greatest share at 5.03%, followed by Turkey and Cyprus. Rounding out the six countries with the greatest percentage of users encountering ransomware were France, Armenia, and Bulgaria, the last two having the same share of affected users.

In 2020, the landscape looked a bit different:

Country %* France 5.18% Montenegro 4.36% Monaco 4.22% Azerbaijan 4.21% Macedonia 4.06%

*Share of users attacked with ransomware out of all users encountering malware in the country

France had the greatest share of users encountering ransomware, followed by Montenegro and Monaco, which replaced Turkey and Cyprus. Azerbaijan had the fourth greatest share at 4.21%, and Macedonia took Armenia’s place as the country with the fifth greatest share.

Mobile ransomware

As is the case with ransomware across all devices, mobile ransomware continues to decline. In 2019, the total number of unique Kaspersky users that encountered ransomware was 72,258. In 2020, it was 33,502 — a decrease of 54%.

However, the share of mobile users that encountered ransomware out of the total number that encountered any type of malware remained steady at 0.56%. This coincided with a decline in the overall number of mobile ransomware detections — from 333,878 in 2019 to 290,372 in 2020.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Number of mobile ransomware detections from 2019 to 2020 (download)

Interestingly enough, while the number of mobile ransomware detections declined relatively steadily after July 2019 with just a few small spikes in July 2019 and February 2020, it again started to rise significantly in the second half of 2020, reaching 35,000 detections in September of last year. This was due to, oddly enough, the ransomware Encoder, which is actually designed for Windows workstations and is not dangerous for mobile devices. However, in September 2020, Encoder spread via Telegram, which has both a mobile and desktop application. The attackers were most likely targeting Windows users, and mobile users accidentally ended up with Encoder on their phones when the mobile version of Telegram synced downloads with the desktop client.

Most active mobile ransomware families


!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Distribution of the most active mobile ransomware families, 2019 (download)

In 2019, nearly 45% of users that encountered mobile ransomware encountered Svpeng, the family that started as SMS Trojans, then switched to stealing banking credentials and credit card data, and finally evolved into ransomware. Slightly less than 19% of users encountered Rkor and Small. Rkor is a classic locker for ransom. Distributed via porn, it uses accessibility services to gain the necessary control over a device and then locks it until a fee is paid. Small is very similar: it locks the screen and demands a fee to continue watching porn.

The fourth most common family is Congur, which is distributed via a modified application, such as WhatsApp. Another well-known active family is Fusob, which claims to be from some kind of authority and says that the intended victim is obligated to pay a fine.


!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Distribution of the most active mobile ransomware families, 2020 (download)

In 2020, Small was the most frequently encountered mobile ransomware family at 26% followed by Rkor and Congur. Svpeng was the fourth most common family, with 14% of users encountering it.

Geography of attacked users

In 2019, the countries with the greatest percentage of users that encountered ransomware on their mobile devices were the following:

Country %*  United States 33.19% Kazakhstan 13.24% Canada 2.71% Germany 2.27% Italy 2.19% United Kingdom 1.53% Iran 1.41% Poland 1.22% Mexico 1.09% Spain 1.00%

*Share of users attacked with ransomware out of all users encountering malware

The countries with the greatest number of users encountering mobile ransomware were relatively dispersed globally, with the United States having the highest percentage. Kazakhstan followed at 13.24%. The rest of the top ten had significantly smaller percentages of users encountering mobile ransomware, with Canada — the country with the third largest share — having only 2.71%.

In 2020, the countries with the greatest percentage of users that encountered mobile ransomware were the following:

Country %* Kazakhstan 23.80% United States 10.32% Germany 2.54% Egypt 1.46% Mexico 1.43% Italy 1.41% United Kingdom 1.14% Iran 1.07% Malaysia 1.02% Indonesia 1.01%

*Share of users attacked with ransomware out of all users encountering malware

In 2020, Kazakhstan had the greatest percentage of users encountering mobile ransomware at 23.80%, followed by the United States at 10.32%. Poland, Spain, and Canada were replaced by Malaysia, Indonesia, and Egypt. In general, the percentage of affected users declined — this is to be expected given that the overall number of users affected by mobile ransomware declined by more than 50%.

The rise of targeted ransomware

While the raw total of ransomware detections has been on the decline, those numbers only tell part of the story. When ransomware first made front-page headlines, it was because of campaigns like WannaCry, Petya, and CryptoLocker: massive campaigns interested in hitting as many users as possible and extorting relatively small amounts per user. In WannaCry, for example, the attackers only requested $300 and later raised this amount to $600.

However, these types of campaigns are becoming less profitable, for potentially several reasons.      Given the increasing amount of attention paid to ransomware, security software may have become better at blocking ransomware threats and people are repeatedly encouraged not to pay. In addition, in a lot of countries, people simply can’t afford that high of a ransom. As a result, attackers have shifted their focus to those who can pay — companies. In 2019, nearly one-third of victims targeted by ransomware were corporate users.

Of course, infecting companies requires a far more sophisticated, targeted approach, and there are specific ransomware families designed to do just that.

Targeted ransomware (also known as “big game hunting”) consists of families of ransomware used to extort money from a particular victim. These victims tend to be high profile, such as large corporations, government and municipal agencies, and healthcare organizations, and the ransom demanded is far larger than that demanded from separate users. Often, their attacks involve one or more of the following stages:

  • Network compromise
  • Reconnaissance & persistence
  • Lateral movement
  • Data exfiltration
  • Data encryption
  • Extortion

Initial infection often occurs via exploitation of server-side software (VPNs, Citrix, WebLogic, Tomcat, Exchange, etc), RDP brute-force attacks/credential stuffing, supply-chain attacks, or botnets.

Kaspersky classifies a particular ransomware group as “targeted” based on the victims chosen, and if sophisticated methods are used to conduct the attack, such as breaching the network or lateral movement. So far, Kaspersky has identified 28 of these targeted families, which includes the infamous Hades ransomware that targets companies worth at least $1 billion.

From 2019 to 2020, the number of unique users affected by targeted ransomware — ransomware that is designed to affect specific users — increased from 985 to 8,538, a 767% jump.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

The number of unique Kaspersky users affected by targeted ransomware, 2019 – 2020 (download)

A major spike occurred in July 2020, which was driven by the REvil ransomware family, which successfully exploited the foreign exchange company Travelex for $2.3 million. Grubman Shire Meiselas & Sacks, a New York-based law firm with a host of celebrity clients, also fell victim to REvil in May. Other highly targeted ransomware families also appeared in 2019 and 2020, the most notable of which was Maze. First appearing in 2019, Maze used various mechanisms for initial compromise. In certain cases, they used spear-phishing campaigns to install Cobalt Strike RAT, while other attacks involved exploiting a vulnerable internet-facing service (e.g., Citrix ADC/NetScaler or Pulse Secure VPN) or weak RDP credentials to breach the network. Maze primarily targeted businesses and large organizations. Some of their most notable attacks were against LG and the city of Pensacola, Florida.

Alongside this rise in targeted ransomware there has been an increased focus not just on data encryption but on data exfiltration: searching for highly confidential information and threatening to make it public if the ransom isn’t met as a means of coercing organizations to pay. Maze was one of the first ransomware groups to actually publish this stolen data if the ransom wasn’t paid. In addition, this information can later be sold online at auctions, which is what happened with databases from various agricultural companies that had fallen victim to REvil in the summer of 2020.

Eventually, Maze teamed up with another well-known, highly targeted ransomware family, RagnarLocker, which first appeared in 2020. Like Maze, RagnarLocker targets primarily large organizations and publishes the confidential information of those who refuse to pay on the “Wall of Shame.” This family is so targeted that each individual malware sample is specifically tailored to the organization it is attacking.

WastedLocker also appeared in 2020 and made global headlines when it knocked most popular services by Garmin, the well-known fitness and GPS technology company, offline for three days as it held the company’s data for a $10 million ransom. The malware used in the attack was specifically designed for Garmin.

Targeted ransomware is not confined to one specific industry. It has affected everything from healthcare organizations to sports and fitness companies.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Distribution of targeted ransomware attacks by industry, 2019–2020 (download)

Engineering and manufacturing was the most represented industry by far, with 25.63% of targeted ransomware attacks from 2019 to 2020 affecting this industry. This is not surprising given the highly sensitive nature of their data and the often high value of such companies. It is also incredibly disruptive to businesses in this sector if their systems go offline. 7.60% of targeted ransomware attacks affected professional and consumer services companies, and 7.09% targeted financial firms. Other popular targets are construction & real estate, commerce & retail, and IT & telecommunications.


The world is entering a new era of ransomware, and it’s likely that any kind of large-scale campaign — the kind that targets average, everyday users — will be few and far between. Of course, that’s not to say ransomware is only a threat if you’re a large company. Just in December of last year, there was a group looking to capitalize on the launch of Cyberpunk 2077 by distributing a fake, mobile version of the game that encrypts users’ files once downloaded.

That said, there has been an unmistakable shift in the landscape — one aimed at extorting confidential information and recovering large sums of money by targeting just one or maybe a dozen organizations. That means ransomware attackers will continue to deploy more advanced techniques for infiltrating networks and encrypting data. APT groups like Lazarus have already begun adding ransomware to their toolset. It wouldn’t be surprising if additional advanced threat actors followed suit.

The biggest takeaway from this is that companies — large and small — need to think about more than just backing up their data. They need to take a comprehensive approach to their security — one that includes regular patching, software updates, and cybersecurity awareness training. Some of these attacks against companies involve gaining an initial foothold in the system, laterally moving throughout the network until full control has been achieved, and then conducting reconnaissance for months before striking at a moment that causes optimal damage. In the attack against Travelex with the REvil ransomware, the cybercriminals had infiltrated the company’s network six months before they actually encrypted the data and demanded the ransom.

Ransomware attackers are sharpening their toolsets, and companies need to respond in kind. Fortunately, doing so is completely within their power.

Here are just a few suggestions from Kaspersky experts on the ways you can safeguard your organization against ransomware:

  1. Always keep software updated on all the devices you use to prevent ransomware from exploiting vulnerabilities.
  2. Focus your defense strategy on detecting lateral movements and data exfiltration to the internet. Pay special attention to the outgoing traffic to detect cybercriminals’ connections. Back up data regularly. Make sure you can quickly access it in an emergency when needed.
  3. Use solutions like Kaspersky Endpoint Detection and Responseand Kaspersky Managed Detection and Response, which help identify and stop an attack at an early stage, before attackers reach their final goals.
  4. To protect the corporate environment, educate your employees. Dedicated training courses can help, such as the ones provided in the Kaspersky Automated Security Awareness Platform. A free lesson on how to protect your business from ransomware attacks is available here.
  5. Use a reliable endpoint security solution, such as Kaspersky Endpoint Security for Business, which is powered by exploit prevention, behavior detection, and a remediation engine that is able to roll back malicious actions. KESB also has self-defense mechanisms that can prevent its removal by cybercriminals.
2021. április 21.

Targeted Malware Reverse Engineering Workshop follow-up. Part 2

If you have read our previous blogpost “Targeted Malware Reverse Engineering Workshop follow-up. Part 1“, you probably know about the webinar we conducted on April 8, 2021, with Kaspersky GReAT’s Ivan Kwiatkowski and Denis Legezo, to share best practices in reverse engineering and demonstrate real-time analysis of recent targeted malware samples. The experts also had a fireside chat with Igor Skochinsky of Hex-Rays and introduced the Targeted Malware Reverse Engineering online self-study course.

The webinar audience having been so active – it was a very pleasant surprise, thanks again! – not only were we unable to address all the incoming questions online, we didn’t even manage to pack the rest of them in one blogpost. So here comes the second part of the webinar follow-up.

Questions related to malware analysis
  1. How common are opaque predicates in legitimate software? Can these predicates be leveraged as detection signatures?
    Ivan: It is difficult to provide an answer encompassing all legitimate software. As a general rule, obfuscation or evasion techniques can provide a relevant weak signal  potentially indicating malicious behavior, but should not be used for detection.
    Denis: We mostly deal with malicious, not legit code, but I would not expect such tricks there. What for — protection? I would not expect opaque predicates even from third-party protectors.
  2. Do you often come across binary obfuscation methods like nanomites, control flow flattening or VM in malwares?
    Ivan: Such techniques are extremely rare, possibly because attackers know that the presence of such protections will raise suspicion.
    Denis: We met several flattening cases lately. I could also name a couple of cases of custom internal VM usage in malware. So, not often, but they do exist.
  3. When it comes to packed executables, are automated unpackers usually good enough (like using dynamic instrumentation to detect tail jump and so forth) or is it more about manual work?
    Ivan: It turns out that packed executables are not as widespread as you would think. They turn up so rarely that I always default to manual work.
    Denis: We mostly deal with targeted malware, and packing executables are not common in this world, I agree.
  4. Do we also see any “exotic” commercial packers like vmprotect?
    Ivan: We don’t, however, if this is of interest to you, I strongly recommend you to watch Vitaly Kamluk’s presentation on the subject.
    Denis: Not in this training, but again, I would not say such tools are too popular in the world of targeted malware. Mostly due to being detected by security products, I suppose.
  5. What are the most creative anti-reversing tricks from malware creators you have seen so far?
    Ivan: I would name the LuckyMouse APT which deploys stripped down malware samples containing none of its configuration anymore, once saved somewhere on the victim’s machine. Generally speaking, they’re very good at making sure that files obtained by defenders are incomplete.
    Denis: The best anti-reversing trick I have seen is a seasoned software design pro with brain-damaging multi-module development style and 30 years of experience on the other side of the court. The only thing you want to do after the encounter is to yell at him/her, your disassembler, your PC, and yourself. But when you are done at last — well, this is the reason why we do it.
Questions on the Targeted Malware Reverse Engineering course syllabus

You can find the full syllabus here.

  1. Is the training focused on static reverse engineering or do you use dynamic analysis (e.g. debug/emulation) as well? Is the virtual lab analysis limited to static one?
    Ivan: We occasionally use debugging, and debuggers are available in the VM. Most of the work, however, takes place in IDA Pro.
    Denis: Ah, our deep belief in static analysis has affected the training for sure. But we do debugging as well, it is true. For example, in the LuckyMouse track.
  2. Will the analysis exercises deal only with the “final” malicious payloads/files or with analyzing the entire infection chains (e.g. downloader -> dropper/injector -> shellcode)?
    Ivan: It is closer to the other way around. When we have no time to show everything, we focus on the most complex parts of the infection chain (the beginning), tackle all the problems, and leave the easy part (looking at the unobfuscated final stage) as an exercise for the audience.
  3. You have mentioned that a lot of course time will be spent discussing deobfuscation mechanisms. Will there also be a chapter/section dealing on bypassing anti-reversing mechanisms?
    Ivan: The course is organized around the specific real malware cases. There is no theory segment on obfuscation. However, we show many samples that use different techniques and demonstrate how to approach each one of them.
  4. Does the course cover the C2 protocol traffic analysis?
    Ivan: To some extent, yes. One of the tracks is entirely dedicated to analyzing a network utility, understanding and re-implementing its custom protocol.
    Denis: For example, in the Topinambour track, you deal with simple C2 communication protocol analysis from the reversing point of view: it means means by analyzing the code you come to understand what to expect from the traffic.
  5. Do you cover both IDA Python and IDC during the course?
    Ivan: We only cover IDA Python, but the participants are free to use IDC if they choose to.
  6. Will you teach any countermeasures against this kind of anti-reversing techniques?
    Ivan: It’s our intentional choice to focus on real-life cases; and it is a fact that the vast majority of samples I have worked on involved no such protections. One of the malware specimens shown in the course has Anti-VM detection, which doesn’t bother us as we are just reading the code.
  7. What malicious document formats will be analyzed in the training?
    Ivan: The malicious document studied in the course is the InPage exploit.
    Denis: The InPage file format is based upon Compound Document Format, and we will analyze how the Biodata campaign operators had embedded the shellcode into it.
  8. If you detect such antimalware techniques, will there be a link to your previous Yara training: how to write a good detection rule to find such complex anti obfuscation techniques?
    Ivan: As you will probably see, the course is quite packed as it is! We may make a comment here and there about what could be a good Yara rule, but only in passing. I am, however, certain that the training will help you write better Yara rules.
  9. Shall we also learn to write or automate these anti obfuscation tasks at scale?
    Ivan: Yes, a large part of the course focuses on defeating the various protections that prevent us from seeing the actual payload!
Topics not addressed in the Targeted Malware Reverse Engineering training
  1. The course seems to include various topics on RE. Anything that has been left out? Probably saved for a future update to the course.
    Ivan: There are many things we could not get into. Rust/Go malware, CPU architectures beyond x86 and x64, ARM arch and Mac OS, etc. But we believe we were able to provide a varied yet realistic sample of what we usually encounter.
    Denis: In the third-level reverse engineering course from Kaspersky, you may expect the use of a decryption framework to facilitate such typical reversing tasks.
  2. Does the course address any malware employing unique file formats, thus requiring one to create an IDA loader module? How often do you deal with malware that uses unique file formats? It is something I am looking to learn.
    Ivan: This is a use case not covered by the course, and in fact one that I have yet to encounter.
    Denis: One quite unique _document_ format with the shellcode in it is featured in the course, but it needs no loader module, as you understand. Pity, but your topic seems to be out of the scope of this training. We are planning to create additional reversing screencasts from time to time — let’s think about covering this, too.
Virtual lab
  1. Will it be possible to do the exercises in a personal lab at home to analyze the samples of the course?
    Ivan: Due to legal restrictions in some countries, participants are required to work in the dedicated virtual lab that we provide and the VM cannot be downloaded. The good news is that it contains all the necessary tools, including a full version of IDA Pro.
  2. Can the lab hours be extended if required?
    Ivan: Virtual machines will indeed be suspended after 100 hours of runtime. We can extend the hours on a case-by-case basis, but we expect this should be enough to complete all the tracks of the training.
  3. Do we need to RDP from a VM?
    Ivan: The virtual environment is accessed directly from the web browser.
  4. Are the VM’s stealthy for the malware, or can they be detected through redpill/no-pill techniques?
    Ivan: The VMs provided in the training make no attempt at concealing what they are. Most of the malware provided does not particularly try to prevent execution in virtualized environments, and in any case the training is focused on static analysis with IDA Pro.
  5. If we write IDA scripts, can we extract them to our home environment at the end?
    Ivan: Sadly, this will not be possible. But the scripts you write should remain relatively modest in size, and will probably not be generic enough to allow future use anyway.

You can check information on prerequisites here.

  • Do you have any good recommendations on how to prepare for the training? Any prerequisites for this course?
    Ivan: I would advise to check out the demo version of the training. It should give you an idea of whether you meet the prerequisites, and we also provide a number of third-party resources in the introduction in case you need a bit of preparation.
  • Is knowledge of cryptographic algorithms also required? Or shall we learn how to detect them in the binaries?
    Ivan: We touch on that subject lightly. In most cases, figuring out which cryptographic algorithm is used is straightforward. If not, some help will be provided during the solution segments.
  • Knowledge of which languages is required?
    Ivan: Python scripting is required at some point. Other than that, familiarity with compiled languages, such as C or C++, is recommended.
Support & feedback
  • How much support or guidance will be available if I get stuck on an exercise?
    Ivan: We will collect your requests through helpdesk. Also a monthly call with the trainers is scheduled to answer your questions about the course. Otherwise, we are generally available on Twitter: @JusticeRage and @legezo.
  • Does the Targeted Malware Reverse Engineering training provide for some kind of exam/cert at the end?
    Ivan: There is no exam as such, although each track contains challenging knowledge checks and quizzes to check your progress. Certification will be awarded to all participants who complete all the tracks of the course.
  • How much will this course cost?
    Ivan: $1,400 VAT included.
  • Future plans/Future courses
    • What is the difference between the Targeted Malware Reverse Engineering training and the upcoming third-level Advanced Malware Analysis training?
      Ivan: This is an intermediate-level course, while the upcoming one will be an advanced expert-level course.
2021. április 19.

Targeted Malware Reverse Engineering Workshop follow-up. Part 1

On April 8, 2021, we conducted a webinar with Ivan Kwiatkowski and Denis Legezo, Senior Security Researchers from our Global Research & Analysis Team (GReAT), who gave live workshops on practical disassembling, decrypting and deobfuscating authentic malware cases, moderated by GReAT’s own Dan Demeter.

Ivan demonstrated how to strip the obfuscation from the recently discovered Cycldek-related tool, while Denis presented an exercise on reversing the MontysThree’s malware  steganography algorithm. The experts also had a fireside chat with our guest Igor Skochinsky of Hex-Rays.

On top of that, Ivan and Denis introduced the new Targeted Malware Reverse Engineering online self-study course, into which they have squeezed 10 years of their cybersecurity experience. This intermediate-level training is designed for those seeking confidence and practical experience in malware analysis. It includes in-depth analysis of ten fresh real-life targeted malware cases, like MontysThree, LuckyMouse and Lazarus, hands-on learning with an array of reverse engineering tools, including IDA Pro, Hex-Rays decompiler, Hiew, 010 Editor, and 100 hours of virtual lab practice.

In case you missed the webinar – or if you attended but want to watch it again – you can find the video here: Targeted Malware Reverse Engineering Workshop (brighttalk.com).

With so many questions collected during the webinar – thank you all for your active participation! – we lacked the time to answer them all online, we promised we would come up with this blogpost.

Questions on the Cycldek-related tool analysis
  1. How do you decide whether the Cycldek-actors have adopted the DLL side-loading triad technique, or the actors normally using the DLL side-loading triad have adopted the design considerations from Cycldek?
    Ivan: It is precisely because we cannot really differentiate between the two that we have been very careful with the attribution of this specific campaign. The best we can say at the moment is that the threat actor behind it is related to Cycldek.
    Denis: Even in our training there is another track with .dll search order hijacking – LuckyMouse. I really would not recommend anyone to build attribution based on such a technique, because it’s super wide-spread among the Chinese-speaking actors.
  2. Does the script work automatically, or do you have to add information about the specific code you are working with?
    Ivan: The script shown in the webinar was written solely for the specific sample used in the demonstration. I prefer to write small programs addressing very specific issues at first, and only move on to developing generic frameworks when I have to, which is not the case for opaque predicates.
  3. Is the deobfuscation script for the shellcode publicly available?
    Ivan: It is derived from a publicly available script. However, my modifications were not made public; if they were, it would make the training a little too easy, wouldn’t it?
  4. Decryption/deobfuscation seems to be very labor-intensive. Have you guys experimented with symbolic execution in order to automate the process? Have you built a framework that you use against multiple families and (data&code) obfuscation or you build tools on ‘as needed’ basis?
    Ivan: I have always found it quicker to just write quick scripts to solve the problem instead of spending time on diving into symbolic execution. Same goes for generic frameworks, but who knows? Maybe one day I will need one.
    Denis: Decryption/deobfuscation is mostly case-based, I agree, but we also have disassembler plugins to facilitate such tasks. By the way, such a code base and the habits are the reasons that create the threshold to change the disassembler. We have internal framework for asm layer decryption, you will meet him in advanced course, but it’s up to researcher to use it or not.
  5. Any insight into the success rate of this campaign?
    Ivan: We were able to identify about a dozen organizations attacked during this campaign. If you want to know more about our findings, please have a look at our blogpost.
  6. Any hint on the code pattern that helped you connect with the Cycledek campaign?
    Ivan: You can find more about this in our blogpost. Even more details are available through our private reporting service. Generally speaking, we have a tool called KTAE that performs this task, and of course the memory of samples we have worked on in the past.
  7. About the jump instructions that lead to the same spot – how were they injected there? Manually using a binary editor?
    Ivan: The opaque predicates added in the Cycldek shellcode were almost certainly inserted using an automated tool.
  8. I am one of the people using the assembly view. After the noping stage usually I have to suffer the long scrolling. You mentioned there is a way to fix this?”
    Ivan: Check out this script I published on GitHub a couple of months ago.
  9. Can xmm* registers and Pxor be used as code patterns Yara signatures?
    Ivan: This is in fact one of the signatures I wrote for this piece of malware.
Questions on analysis of the MontysThree’s malware steganography algorithm
  1. Do you think there was a practical reason to use steganography as obfuscation, or the malware developer did it just for fun?
    Denis: In my experience, most steps the malefactors take are on purpose, not for fun. With steganography they are trying to fool the network security systems like IDS/IPS: bitmaps are not too suspicious for them. Let me also add that the campaign operators are human, too, so now and again there will be Easter eggs in their products — for example, take a look at the Topinambour track and the phrases used as decryption keys and beaconing.
  2. What image steganography algorithm have you seen hiding in the wild recently, other than LSB?
    Denis: As far as I know, it is LSB alright — Microcin, MontysThree. I would expect some tools to be creating such images for the operators. But take a look at the function we ended during the short workshop: depending on the decrypted steganography parameters, it could be not just LSB, but the “less significant half a byte” as well.
  3. Are there any recent malware samples incorporating network steganography in their C&C-channels, the way the DoublePulsar backdoor did using SMB back in 2017?
    Denis: I suppose you mean the broken SMB packages. Yes, the last trick of the kind I saw was the rare use of HTTP statuses as C2 commands. You might be surprised to learn how many of them there are in RFCs and how strange some of them are, like “I’m the kettle”.
Reverse Engineering: how to start a career, working routines, the future of the profession
  1. How does one get into malware reverse engineering? What are the good resources to study? How can one find interesting malware samples?
    Ivan: You can find a solid introduction at https://beginners.re/. Next, check out https://crackmes.one/ which contains many programs designed to be reverse-engineered, so one can finally move on to malware samples. Worry not about finding the “interesting” ones early on; just try to get good at it, document what you do, and you will find yourself in no time being able to access all the data you could wish for.
    Denis: Do you like meditating on the code and trying to understand it? Then I suppose you already have everything you need. I think you should not bother looking for interesting ones in the beginning (if I get your question right) – everything will do. In my experience, the fun ones are written by professional programmers, not malware writers, because they just cannot do away with their habit of structuring the data and code, making it multi-thread safe, etc.
  2. Now an experienced malware reverse engineer, where did you start from? Do you have any solid math/programming background from where you moved on to malware reverse engineering? Or what would be the typical path?
    Ivan: I have a software engineering background, and my math expertise is shaky at best. After having met so many people in this field, I can say confidently that there is no typical path beyond being passionate about the subject.
    Denis: Personally I have a math/programming background, but I couldn’t agree more: it’s more about passion than any scientific education.
  3. If you are reverse engineering malware, do you work as a team?
    Ivan: While several researchers can investigate a campaign together, I usually work on samples alone. The time it takes to wrap up a case may vary between a week and several months, depending on the complexity of the investigation!
    Denis: Reversing itself is not the task that is easy to distribute/parallel. In my experience, you would spend more time organizing the process than benefit from the work of several reversers. Typically, I do this part alone, but research is not limited to binary analysis: the quest, the sharing of previous experiences with the same malware/tools, and so forth — it is a team game.
  4. What do you think about AI? Would it help to automate the reverse engineering work?
    Ivan: I think at the moment it is still a lot more A than I. I keep hearing sales pitches about how it will revolutionize the infosec industry and I do not want to dismiss them outright. I am sure there are a number of tasks, such as malware classification, where AI could be helpful. Let’s see what the future brings!
    Denis: OK, do you use any AI-based code similarity, for example? I do, and you know — my impression so far is we still need meat-based engineers who understand how it works to use it right.
  5. How helpful is static analysis, considering the multiple advanced sandboxing solutions available today?
    Ivan: Sandboxing and static analysis will always serve complementary purposes. Static analysis is fast and does not require running the sample. It is great to quickly gather information about what a program might do or for triage. Dynamic analysis takes longer, yields more details, but gives malware an opportunity to detect the sandboxed environment. Then, at the very end, you do static analysis again, which involves reverse-engineering the program with a disassembler and takes the longest. All have their uses.
    Denis: Sometimes you need static analysis because of the multiple advanced anti-sandboxing tricks out there. You also reveal far more details through static analysis if you want to create better Yara rules or distinguish a specific part of custom code to attribute samples to specific developers. So it is up to you how deep the rabbit hole should be.
Tips on tools, IDA and other things
  1. Do you contribute to Lumina server? Does Kaspersky have any similar public servers to help us during our analysis?
    Ivan: My understanding is that Lumina is most helpful when used by a critical mass of users. As such, I do not think it would make sense to fragment the community across multiple servers. If you are willing to share metadata about the programs you are working on with third-parties, I would recommend to simply go with an Hex-Rays’ instance.
    Denis: No, I have never contributed to Lumina so far. I don’t think it is going to be too popular for threat intelligence, but let us wait and see — public Yara repositories are there, so maybe code snippets might also meet the community’s needs.
  2. What tools and techniques do you recommend for calculating the code similarity of samples? Is this possible with IDA Pro?
    Ivan: For this, we have developed a commercial solution called KTAE. That’s what we regularly use internally.
    Denis: Personally, I am using our KTAE. As far as I know, the creating of custom FLIRT signatures right in IDA could partially cover this need.
  3. Is there any specific reason why you are using IDA under wine? Does it have anything to do with the type of samples you are analyzing?
    Denis: I used to have Windows IDA licenses and Linux OS historically, so wine is my way of using disassembler. It does not affect your analysis anyway — choose any samples you want under any OS.
  4. What is your favorite IDA Pro plugin and why?
    Ivan: One of the internal plugins developed by Kaspersky. Other than that, I use x64dbgida regularly and have heard great things about Labeless.
    Denis: For sure our internal plugins. And it’s not because of the authorship, they just perfectly meet our needs.
  5. Do you have a plan to create/open an API so we can create our own processor modules for decompilers (like SLEIGH in Ghidra)? The goal being to analyze VM-based obfuscation.
    Igor: Unlikely to happen in the near future but that’s something we’re definitely keeping in our minds.

If you have any more questions about Ivan’s workshop on the Cycldek-related tool or about the Targeted Malware Reverse Engineering online course, please feel free to drop us a line in the comments box below or contact us on Twitter: @JusticeRage, @legezo and @IgorSkochinsky. We will answer the rest of the questions in our next blogpost – stay tuned!

2021. április 13.

Zero-day vulnerability in Desktop Window Manager (CVE-2021-28310) used in the wild

While analyzing the CVE-2021-1732 exploit originally discovered by the DBAPPSecurity Threat Intelligence Center and used by the BITTER APT group, we discovered another zero-day exploit we believe is linked to the same actor. We reported this new exploit to Microsoft in February and after confirmation that it is indeed a zero-day, it received the designation CVE-2021-28310. Microsoft released a patch to this vulnerability as a part of its April security updates.

We believe this exploit is used in the wild, potentially by several threat actors. It is an escalation of privilege (EoP) exploit that is likely used together with other browser exploits to escape sandboxes or get system privileges for further access. Unfortunately, we weren’t able to capture a full chain, so we don’t know if the exploit is used with another browser zero-day, or coupled with known, patched vulnerabilities.

The exploit was initially identified by our advanced exploit prevention technology and related detection records. In fact, over the past few years, we have built a multitude of exploit protection technologies into our products that have detected several zero-days, proving their effectiveness time and again. We will continue to improve defenses for our users by enhancing technologies and working with third-party vendors to patch vulnerabilities, making the internet more secure for everyone. In this blog we provide a technical analysis of the vulnerability and how the bad guys exploited it. More information about BITTER APT and IOCs are available to customers of the Kaspersky Intelligence Reporting service. Contact: intelreports@kaspersky.com.

Technical details

CVE-2021-28310 is an out-of-bounds (OOB) write vulnerability in dwmcore.dll, which is part of Desktop Window Manager (dwm.exe). Due to the lack of bounds checking, attackers are able to create a situation that allows them to write controlled data at a controlled offset using DirectComposition API. DirectComposition is a Windows component that was introduced in Windows 8 to enable bitmap composition with transforms, effects and animations, with support for bitmaps of different sources (GDI, DirectX, etc.). We’ve already published a blogpost about in-the-wild zero-days abusing DirectComposition API. DirectComposition API is implemented by the win32kbase.sys driver and the names of all related syscalls start with the string “NtDComposition”.

DirectComposition syscalls in the win32kbase.sys driver

For exploitation only three syscalls are required: NtDCompositionCreateChannel, NtDCompositionProcessChannelBatchBuffer and NtDCompositionCommitChannel. The NtDCompositionCreateChannel syscall initiates a channel that can be used together with the NtDCompositionProcessChannelBatchBuffer syscall to send multiple DirectComposition commands in one go for processing by the kernel in a batch mode. For this to work, commands need to be written sequentially in a special buffer mapped by NtDCompositionCreateChannel syscall. Each command has its own format with a variable length and list of parameters.

enum DCOMPOSITION_COMMAND_ID { ProcessCommandBufferIterator, CreateResource, OpenSharedResource, ReleaseResource, GetAnimationTime, CapturePointer, OpenSharedResourceHandle, SetResourceCallbackId, SetResourceIntegerProperty, SetResourceFloatProperty, SetResourceHandleProperty, SetResourceHandleArrayProperty, SetResourceBufferProperty, SetResourceReferenceProperty, SetResourceReferenceArrayProperty, SetResourceAnimationProperty, SetResourceDeletedNotificationTag, AddVisualChild, RedirectMouseToHwnd, SetVisualInputSink, RemoveVisualChild };

List of command IDs supported by the function DirectComposition::CApplicationChannel::ProcessCommandBufferIterator

While these commands are processed by the kernel, they are also serialized into another format and passed by the Local Procedure Call (LPC) protocol to the Desktop Window Manager (dwm.exe) process for rendering to the screen. This procedure could be initiated by the third syscall – NtDCompositionCommitChannel.

To trigger the vulnerability the discovered exploit uses three types of commands: CreateResource, ReleaseResource and SetResourceBufferProperty.

void CreateResourceCmd(int resourceId) { DWORD *buf = (DWORD *)((PUCHAR)pMappedAddress + BatchLength); *buf = CreateResource; buf[1] = resourceId; buf[2] = PropertySet; // MIL_RESOURCE_TYPE buf[3] = FALSE; BatchLength += 16; } void ReleaseResourceCmd(int resourceId) { DWORD *buf = (DWORD *)((PUCHAR)pMappedAddress + BatchLength); *buf = ReleaseResource; buf[1] = resourceId; BatchLength += 8; } void SetPropertyCmd(int resourceId, bool update, int propertyId, int storageOffset, int hidword, int lodword) { DWORD *buf = (DWORD *)((PUCHAR)pMappedAddress + BatchLength); *buf = SetResourceBufferProperty; buf[1] = resourceId; buf[2] = update; buf[3] = 20; buf[4] = propertyId; buf[5] = storageOffset; buf[6] = _D2DVector2; // DCOMPOSITION_EXPRESSION_TYPE buf[7] = hidword; buf[8] = lodword; BatchLength += 36; }

Format of commands used in exploitation

Let’s take a look at the function CPropertySet::ProcessSetPropertyValue in dwmcore.dll. This function is responsible for processing the SetResourceBufferProperty command. We are most interested in the code responsible for handling DCOMPOSITION_EXPRESSION_TYPE = D2DVector2.

int CPropertySet::ProcessSetPropertyValue(CPropertySet *this, ...) { ... if (expression_type == _D2DVector2) { if (!update) { CPropertySet::AddProperty<D2DVector2>(this, propertyId, storageOffset, _D2DVector2, value); } else { if ( storageOffset != this->properties[propertyId]->offset & 0x1FFFFFFF ) { goto fail; } CPropertySet::UpdateProperty<D2DVector2>(this, propertyId, _D2DVector2, value); } } ... } int CPropertySet::AddProperty<D2DVector2>(CResource *this, unsigned int propertyId, int storageOffset, int type, _QWORD *value) { int propertyIdAdded; int result = PropertySetStorage<DynArrayNoZero,PropertySetUserModeAllocator>::AddProperty<D2DVector2>( this->propertiesData, type, value, &propertyIdAdded); if ( result < 0 ) { return result; } if ( propertyId != propertyIdAdded || storageOffset != this->properties[propertyId]->offset & 0x1FFFFFFF ) { return 0x88980403; } result = CPropertySet::PropertyUpdated<D2DMatrix>(this, propertyId); if ( result < 0 ) { return result; } return 0; } int CPropertySet::UpdateProperty<D2DVector2>(CResource *this, unsigned int propertyId, int type, _QWORD *value) { if ( this->properties[propertyId]->type == type ) { *(_QWORD *)(this->propertiesData + (this->properties[propertyId]->offset & 0x1FFFFFFF)) = *value; int result = CPropertySet::PropertyUpdated<D2DMatrix>(this, propertyId); if ( result < 0 ) { return result; } return 0; } else { return 0x80070057; } }

Processing of the SetResourceBufferProperty (D2DVector2) command in dwmcore.dll

For the SetResourceBufferProperty command with the expression type set to D2DVector2, the function CPropertySet::ProcessSetPropertyValue(…) would either call CPropertySet::AddProperty<D2DVector2>(…) or CPropertySet::UpdateProperty<D2DVector2>(…) depending on whether the update flag is set in the command. The first thing that catches the eye is the way the new property is added in the CPropertySet::AddProperty<D2DVector2>(…) function. You can see that it adds a new property to the resource, but it only checks if the propertyId and storageOffset of a new property are equal to the provided values after the new property is added, and returns an error if that’s not the case. Checking something after a job is done is bad coding practice and can result in vulnerabilities. However, a real issue can be found in the CPropertySet::UpdateProperty<D2DVector2>(…) function. No check takes place that will ensure if the provided propertyId is less than the count of properties added to the resource. As a result, an attacker can use this function to perform an OOB write past the propertiesData buffer if it manages to bypass two additional checks for data inside the properties array.

(1) storageOffset == this->properties[propertyId]->offset & 0x1FFFFFFF (2) this->properties[propertyId]->type == type

Conditions which need to be met for exploitation in dwmcore.dll

These checks could be bypassed if an attacker is able to allocate and release objects in the dwm.exe process to groom heap into the desired state and spray memory at specific locations with fake properties. The discovered exploit manages to do this using the CreateResource, ReleaseResource and SetResourceBufferProperty commands.

At the time of writing, we still hadn’t analyzed the updated binaries that are fixing this vulnerability, but to exclude the possibility of other variants for this vulnerability Microsoft would need to check the count of properties for other expression types as well.

Even with the above issues in dwmcore.dll, if the desired memory state is achieved to bypass the previously mentioned checks and a batch of commands are issued to trigger the vulnerability, it still won’t be triggered because there is one more thing preventing it from happening.

As mentioned above, commands are first processed by the kernel and only after that are they sent to Desktop Window Manager (dwm.exe). This means that if you try to send a command with an invalid propertyId, NtDCompositionProcessChannelBatchBuffer syscall will return an error and the command will not be passed to the dwm.exe process. SetResourceBufferProperty commands with expression type set to D2DVector2 are processed in the win32kbase.sys driver with the functions DirectComposition::CPropertySetMarshaler::AddProperty<D2DVector2>(…) and DirectComposition::CPropertySetMarshaler::UpdateProperty<D2DVector2>(…), which are very similar to those present in dwmcore.dll (it’s quite likely they were copy-pasted). However, the kernel version of the UpdateProperty<D2DVector2> function has one notable difference – it actually checks the count of properties added to the resource.

int DirectComposition::CPropertySetMarshaler::UpdateProperty<D2DVector2>(DirectComposition::CPropertySetMarshaler *this, unsigned int *commandParams, _QWORD *value) { unsigned int propertyId = commandParams[0]; unsigned int storageOffset = commandParams[1]; unsigned int type = commandParams[2]; if ( propertyId >= this->propertiesCount || storageOffset != this->properties[propertyId]->offset & 0x1FFFFFFF) || type != this->properties[propertyId]->type ) { return 0xC000000D; } else { *(_QWORD *)(this->propertiesData + (this->properties[propertyId]->offset & 0x1FFFFFFF)) = *value; ... } return 0; }

DirectComposition::CPropertySetMarshaler::UpdateProperty<D2DVector2>(…) in win32kbase.sys

The check for propertiesCount in the kernel mode version of the UpdateProperty<D2DVector2> function prevents further processing of a malicious command by its user mode twin and mitigates the vulnerability, but this is where DirectComposition::CPropertySetMarshaler::AddProperty<D2DVector2>(…) comes in to play. The kernel version of the AddProperty<D2DVector2> function works exactly like its user mode variant and it also applies the same behavior of checking property after it has already been added and returns an error if propertyId and storageOffset of the created property do not match the provided values. Because of this, it’s possible to use the AddProperty<D2DVector2> function to add a new property and force the function to return an error and cause inconsistency between the number of properties assigned to the same resource in kernel mode/user mode. The propertiesCount check in the kernel could be bypassed this way and malicious commands would be passed to Desktop Window Manager (dwm.exe).

Inconsistency between the number of properties assigned to the same resource in kernel mode/user mode could be a source of other vulnerabilities, so we recommend Microsoft to change the behavior of the AddProperty function and check properties before they are added.

The whole exploitation process for the discovered exploit is as follows:

  1. Create a large number of resources with properties of specific size to get heap into predictable state.
  2. Create additional resources with properties of specific size and content to spray memory at specific locations with fake properties.
  3. Release resources created at stage 2.
  4. Create additional resources with properties. These resources will be used to perform OOB writes.
  5. Make holes among resources created at stage 1.
  6. Create additional properties for resources created at stage 4. Their buffers are expected to be allocated at specific locations.
  7. Create “special” properties to cause inconsistency between the number of properties assigned to the same resource in kernel mode/user mode for resources created at stage 4.
  8. Use OOB write vulnerability to write shellcode, create an object and get code execution.
  9. Inject additional shellcode into another system process.

Kaspersky products detect this exploit with the verdicts:

  • HEUR:Exploit.Win32.Generic
  • HEUR:Trojan.Win32.Generic
  • PDM:Exploit.Win32.Generic


2021. április 9.

Malicious code in APKPure app

Recently, we’ve found malicious code in version 3.17.18 of the official client of the APKPure app store. The app is not on Google Play, but it is itself a quite a popular app store around the world. Most likely, its infection is a repeat of the CamScanner incident, when the developer implemented a new adware SDK from an unverified source.

We notified the developers about the infection on April 8. APKPure confirmed the issue and promptly fixed it with the release of version 3.17.19.

In terms of functionality, the malicious code embedded in APKPure is standard for this type of threat. When the app starts, the payload is decrypted and launched. In this case, it is located in a long string in the app code.

The payload collects information about the user device and sends it to the C&C server.

Next, depending on the response received, the malware can:

    • Show ads when the device is unlocked.

    • Open browser pages with ads repeatedly.

    • Load additional executable modules.

In our case, a Trojan was loaded that has much in common with the notorious Triada malware and can perform a range of actions: from displaying and clicking ads to signing up for paid subscriptions and downloading other malware.

Depending on the OS version, the Trojan can inflict various forms of damage on the victim. APKPure users with current Android versions mostly risk having paid subscriptions and intrusive ads appear from nowhere. Users of smartphones who do not receive security updates are less fortunate: in outdated versions of the OS, the malware is capable of not only loading additional apps, but installing them on the system partition. This can result in an unremovable Trojan like xHelper getting onto the device.

Kaspersky solutions detect the malicious implant as HEUR:Trojan-Dropper.AndroidOS.Triada.ap.

If you use APKPure, we recommend immediately deleting the infected app and installing the “clean” 3.17.19 version. In addition, scan the system for other Trojans using a reliable security solution, such as Kaspersky Internet Security for Android.


APKpure app


Downloaded malware


2021. április 5.

The leap of a Cycldek-related threat actor


In the nebula of Chinese-speaking threat actors, it is quite common to see tools and methodologies being shared. One such example of this is the infamous “DLL side-loading triad”: a legitimate executable, a malicious DLL to be sideloaded by it, and an encoded payload, generally dropped from a self-extracting archive. Initially considered to be the signature of LuckyMouse, we observed other groups starting to use similar “triads” such as HoneyMyte. While it implies that it is not possible to attribute attacks based on this technique alone, it also follows that efficient detection of such triads reveals more and more malicious activity.

The investigation described in this article started with one such file which caught our attention due to the various improvements it brought to this well-known infection vector.

FoundCore Loader

This malware sample was discovered in the context of an attack against a high-profile organization located in Vietnam. From a high-level perspective, the infection chain follows the expected execution flow:

After being loaded by a legitimate component from Microsoft Outlook (FINDER.exe, MD5 9F1D6B2D45F1173215439BCC4B00B6E3), outlib.dll (MD5 F267B1D3B3E16BE366025B11176D2ECB) hijacks the intended execution flow of the program to decode and run a shellcode placed in a binary file, rdmin.src (MD5 DF46DA80909A6A641116CB90FA7B8258). Such shellcodes that we had seen so far, however, did not involve any form of obfuscation. So, it was a rather unpleasant surprise for us when we discovered the first instructions:

Experienced reverse-engineers will immediately recognize disassembler-desynchronizing constructs in the screenshot above. The conditional jumps placed at offsets 7 and 9 appear to land in the middle of an address (as evidenced by the label loc_B+1), which is highly atypical for well-behaved assembly code. Immediately after, we note the presence of a call instruction whose destination (highlighted in red) is identified as bogus by IDA Pro, and the code that follows doesn’t make any sense.

Explaining what is going on requires taking a step back and providing a bit of background about how disassemblers work. At the risk of oversimplifying, flow-oriented disassemblers make a number of assumptions when processing files. One of them is that, when they encounter a conditional jump, they start disassembling the “false” branch first, and come back to the “true” branch later on. This process is better evidenced by looking at the opcodes corresponding to the code displayed above, again starting from offset 7:

It is now more obvious that there are two ways to interpret the code above: the disassembler can either start from “E8”, or from “81” – by default, IDA will choose the latter: E8 is in fact the opcode for the call instruction. But astute readers will notice that “JLE” (jump if lower or equal) and “JG” (jump if greater) are opposite conditions: no matter what, one of those will always be true and as such the actual code, as seen by the CPU during the execution, will start with the byte “81”. Such constructs are called opaque predicates, and this E8 byte in the middle was only added there in order to trick the disassembler.

Defeating this trick is but a trivial matter for IDA Pro, as it is possible to manually correct the disassembling mistake. However, it was immediately obvious that the shellcode had been processed by an automated obfuscation tool. Opaque predicates, sometimes in multiples, and dead code were inserted between every single instruction of the program. In the end, cleaning up the program automatically was the only practical approach, and we did so by modifying an existing script for the FinSpy malware family created by the respected reverse-engineer Rolf Rolles.

This step allowed us to discover the shellcode’s purpose: to decrypt and decompress the final payload, using a combination of RC4 and LZNT1. Even then, it turned out that the attackers had more tricks up their sleeve. Normally, at this stage, one would have expected to find a PE file that the shellcode would load into memory. But instead, this is what we got:

The recovered file was indeed a PE, but it turned out that most of its headers had been scrubbed. In fact, even the scarce ones remaining contained incoherent values – for instance, here, a number of declared sections equal to 0xAD4D. Since it is the shellcode (and not the Windows loader) that prepares this file for execution, it doesn’t matter that some information, such as the magic numbers, is missing. As for the erroneous values, it turned out that the shellcode was fixing them on the fly using hardcoded operations:

for ( i = 0; ; ++i ) // Iterate on the sections { // [...] // Stop when all sections have been read if ( i >= pe->pe_header_addr->FileHeader.NumberOfSections - 44361 ) break; // [...] }

For instance, in the decompiled code above (as for all references to the file’s number of sections) the value read in the headers is subtracted by 44361. For the attackers, the advantage is two-fold. First, it makes acquiring the final payload statically a lot more difficult for potential reverse-engineers. Second, it also ensures that the various components of the toolchain remain tightly coupled to each other. If only a single one of them finds itself uploaded to a multi-scanner website, it will be unexploitable for defenders. This is a design philosophy that we had observed from the LuckyMouse APT in the past, and is manifest in other parts of this toolchain too, as we will see later on. Eventually, we were able to reconstruct the file’s headers and move on with our analysis – but we found this loader so interesting from an educational standpoint that we decided to base one track of our online reverse-engineering course on it. For more detailed steps on how we approached this sample, please have a look at Targeted Malware Reverse Engineering.

FoundCore payload

The final payload is a remote administration tool that provides full control over the victim machine to its operators. Upon execution, this malware starts 4 threads:

  • The first one establishes persistence by creating a service.
  • The second one sets inconspicuous information for the service by changing its “Description”, “ImagePath”, “DisplayName” fields (among others).
  • The third sets an empty DACL (corresponding to the SDDL string “D:P”) to the image associated to the current process in order to prevent access to the underlying malicious file.
  • Finally, a worker thread bootstraps execution and establishes connection with the C2 server. Depending on its configuration, it may also inject a copy of itself to another process.

Communications with the server can take place either over raw TCP sockets encrypted with RC4, or via HTTPS. Commands supported by FoundCore include filesystem manipulation, process manipulation, screenshot captures and arbitrary command execution.

RoyalRoad documents, DropPhone and CoreLoader

Taking a step back from the FoundCore malware family, we looked into the various victims we were able to identify to try to gather information about the infection process. In the vast majority of the incidents we discovered, it turned out that FoundCore executions were preceded by the opening of a malicious RTF documents downloaded from static.phongay[.]com. They all were generated using RoyalRoad and attempt to exploit CVE-2018-0802.

Interestingly, while we would have expected them to contain decoy content, all of them were blank. We, therefore, hypothesize the existence of precursor documents, possibly delivered through spear-phishing, or precursor infections, which would trigger the download of one of these RTF files.

Successful exploitation leads to the deployment of yet another malware that we named DropPhone:

MD5 6E36369BF89916ABA49ECA3AF59D38C6 SHA1 C477B50AE66E7228164930117A7D36C53713A5F2 SHA256 F50AE4B25B891E95B57BD4391AEB629437A43664034630D593EB9846CADC9266 Creation time 2020-11-04 09:14:22 File type PE32 executable (DLL) (GUI) Intel 80386, for MS Windows File size 56 KB

This C++ implant also comes in the form of a legitimate executable (DeElevate.exe, from the publisher StarDock) and a side-loaded DLL (DeElevator.dll). At this stage, we are left with more questions than answers when it comes to it. DropPhone fetches a file saved as data.dat from hxxps://cloud.cutepaty[.]com, but we were unable to obtain a copy of this file so far. Next, it expects to find a companion program in %AppData%\Microsoft\Installers\sdclt.exe, and will eventually terminate execution if it cannot find it.

Our hypothesis is that this last file could be an instance or variant of CoreLoader (which we will describe in a minute), but the only piece of data supporting this theory that we have at our disposal is that we found CoreLoader in this folder in a single occurrence.

DropPhone launches sdclt.exe, then collects environment information from the victim machine and sends it to DropBox. The last thing this implant does is delete data.dat without ever accessing its contents. We speculate that they are consumed by sdclt.exe, and that this is another way to lock together the execution of two components, frustrating the efforts of the reverse-engineers who are missing pieces of the puzzle – as is our case here.

MD5 1234A7AACAE14BDD94EEE6F44F7F4356 SHA1 34977E351C9D0E9155C6E016669A4F085B462762 SHA256 492D3B5BEB89C1ABF88FF866D200568E9CAD7BB299700AA29AB9004C32C7C805 Creation time 2020-11-21 03:47:14 File type PE32 executable (DLL) (GUI) Intel 80386, for MS Windows File size 66 KB

Finally, CoreLoader, the last malware we found associated to this set of activity, is a simple shellcode loader which performs anti-analysis and loads additional code from a file named WsmRes.xsl. Again, this specific file eluded our attempts to catch it but we suspect it to be, one way or another, related to FoundCore (described in the previous section).

Overall, our current understanding of this complex toolchain is as follows. Dashed lines represent the components and links we are inferring, striped boxes represent the files we could not acquire.

Victimology and attribution

We observed this campaign between June 2020 and January 2021. According to our telemetry, dozens of organizations were affected. 80% of them are based in Vietnam and belong to the government or military sector, or are otherwise related to the health, diplomacy, education or political verticals. We also identified occasional targets in Central Asia and in Thailand.

For the reasons laid-out in the introduction, attribution based on tooling alone is risky when it comes to this nebula. At first glance, the use of a “triad”, the general design philosophy and the obvious effort spent to make reverse-engineering as complex as possible are reminiscent of LuckyMouse. However, we also observed code similarities between CoreLoader or FoundCore and programs associated with the Cycldek threat actor – namely, RedCore Loader (MD5: 1B6BCBB38921CAF347DF0A21955771A6).

While Cycldek was, so far, considered to be one of the lesser sophisticated threat actors from the Chinese-speaking nexus, its targeting is known to be consistent with what we observed in this campaign. Therefore, we are linking the activities described in this post with Cycldek with low confidence.


No matter which group orchestrated this campaign, it constitutes a significant step up in terms of sophistication. The toolchain presented here was willfully split into a series of interdependent components that function together as a whole. Single pieces are difficult – sometimes impossible – to analyze in isolation, because they rely on code or data provided at other stages of the infection chain. We regretfully admit that this strategy was partly successful in preventing us from obtaining a complete picture of this campaign. As such, this report is as much about the things we know as it is about figuring out what we don’t. We hereby extend our hand to fellow researchers who might be seeing other pieces of this vast puzzle, because we strongly believe that the challenges ahead of us can only be overcome through information sharing among trusted industry partners.

Some readers from other regions of the world might dismiss this local activity as irrelevant to their interests. We would advise them to take heed. Experience shows that regional threat actors sometimes widen their area of activity as their operational capabilities increase, and that tactics or tools are vastly shared across distinct actors or intrusion-sets that target different regions. Today, we see a group focused on South-East Asia taking a major leap forward. Tomorrow, they may decide they’re ready to take on the whole world.

Indicators of Compromise

File Hashes

F267B1D3B3E16BE366025B11176D2ECB FoundCore malicious DLL (outllib.dll) DF46DA80909A6A641116CB90FA7B8258 FoundCore companion file (rdmin.src) 6E36369BF89916ABA49ECA3AF59D38C6 DropPhone 60095B281E32DAD2B58A10005128B1C3 Malicious RTF document 1234A7AACAE14BDD94EEE6F44F7F4356 CoreLoader


phong.giaitrinuoc[.]com FoundCore C2 cloud.cutepaty[.]com DropPhone C2 static.phongay[.]com RTF document stager
2021. április 2.

Browser lockers: extortion disguised as a fine

Browser lockers (aka browlocks) are a class of online threats that prevent the victim from using the browser and demand a ransom. A locker is a fake page that dupes the user, under a fictitious pretext (loss of data, legal liability, etc.), into making a call or a money transfer, or giving out payment details. The “locking” consists of preventing the user from leaving the current tab, which displays intimidating messages, often with sound and visual effects.

This type of fraud is not new and has long been on the radar of researchers. The past decade has seen numerous browser locking campaigns targeting users worldwide. Despite its mature age, the threat has lost none of its popularity; on the contrary, the number of tricks used by scammers is only growing. They include imitating the “blue screen of death” (BSOD) in the browser, false warnings about system errors or detected viruses, threats to encrypt files, legal liability notices, and many others. In this post, we examine two families of lockers that mimic government websites.

Propagation methods

Both families spread mainly via advertising networks, primarily aimed at selling “adult” content and movies in an intrusive manner; for example, through tabs or windows that open on top of the visited site when loading a page with an embedded ad module (pop-ups) or after clicking anywhere on the page (click-unders). Presumably cybercriminals pay for ads to show browser lockers in pop-ups.

Family #1. Fake websites of the Russian Ministry of Internal Affairs: “Give us your money”

Members of the first family under consideration mimic the website of the Russian Ministry of Internal Affairs (MVD), and are thus aimed at users from Russia. In Q4 2020, more than 55,000 users encountered them.

Example of a fake MVD website

What the victim sees (and hears)

On landing on a fake browlock site, the user typically sees a warning, supposedly from the browser, saying that if they leave the page some changes might not be saved.

If the user simply closes the tab, nothing happens; but if they click anywhere on the page, the main content of the locker expands to full screen. As a result, an imitation of a computer screen with an open browser appears in front of the user: at the bottom is a taskbar with the Google Chrome icon, and at the top is an address bar displaying the real URL of the MVD. The notification on the page states that the device has been locked due to a violation of the law. Under the pretext of a fine, the victim is instructed to transfer a certain amount to a mobile account, ranging in size from 3,000 to 10,000 rubles (US$40–130). In case of refusal, the ransomwarers threaten file encryption, as well as criminal liability under Article 242 of the Russian Criminal Code. The page is accompanied by an audio recording with threats and a demand to pay the fine.

Technical details

The scammers use full-screen mode to make it difficult for the user to access the browser window controls and taskbar, and to create a locking effect. In addition, to convince the victim that the mouse is unresponsive, the attackers hide the cursor by manipulating the CSS property cursor.

The page also uses the following code to handle keystrokes:

After deobfuscation, we obtain a very small script:

It was probably assumed that running this code would result in the Escape (keycode=27), Ctrl (keycode=17), Alt (keycode=18) and Tab (keycode=9) keystrokes being ignored, as well as F1, F3, F4, F5 and F12. This could prevent the user from leaving the page using various keyboard shortcuts, but the trick does not work in modern browsers.

Another interesting detail is the animation of the supposed file encryption process, which is shown in the screenshots below. It consists of an endless succession of random numbers and letters, simulating enumeration of allegedly encrypted files in the system directory.

Page addresses

Cybercriminals often use alphanumeric domain names, where the number sequence corresponds to a date close to the domain registration date and the letter sequence is an abbreviation, for example, “mpa” (the Russian abbreviation for “municipal legal act”) or “kad” (“cadastral office”). Example of a fraudulent domain: 0402mpa21[.]ru.

We also saw domain names composed of topic-based words, such as “police” or “mvd”. Cybercriminals use them to mimic the addresses of the legitimate sites of law enforcement agencies. An example of such a domain is mvd-ru[.]tech.

Mobile version of fake MVD websites

The threat also exists on mobile devices. To determine the type of device during propagation, the User-Agent field in the header of the HTTP request is checked. As in the case of the “full” version, the victim is accused of breaking the law and ordered to pay a fine; the amount, however, is smaller than in the desktop version.

Family #2. Fake law enforcement websites in the Middle East: “Give us your card details”

The second family differs in the way that money is transferred to the ransomwarers. As before, the user is accused of violating the law, informed that their computer has been locked, and instructed to pay a fine. However, instead of leaving their account or telephone number for payment, the cybercriminals insert a data entry form on the page asking for card details.

This family of lockers is targeted mostly at users in the Middle East (UAE, Oman, Kuwait, Qatar, and Saudi Arabia). In addition, we have seen fraudulent pages disguised as Indian and Singaporean law enforcement websites. European equivalents are slightly less common.

In Q4 2020, this family threatened more than 130,000 users.

Examples of ransomware pages

Technical details

From a technical viewpoint, browser lockers of the second type are in many ways similar to the fake MVD websites. As in the first case, the content expands to full screen to make it difficult for the user to access the browser window controls and taskbar. At the top of the page is an address bar with the URL of the official government resource, and at the bottom is a fake taskbar with the Google Chrome icon. The mouse pointer is not displayed, and a script similar to the one above is used to handle keystrokes. Besides entering payment data, no actions on the page are available to the user.

The screenshot below shows an obfuscated script that implements the “locking,” as well as collects and sends the user-input data.

The victim’s payment details are transferred via an HTTP POST request to the same malicious resource that hosts the page. In the screenshot below is an example of a request to send payment details to the malicious site sslwebtraffic[.]cf.


The threats investigated are not technically complex. Their functionality is rather primitive and aims to create the illusion of locking the computer and intimidate the victim. Landing on such a page by mistake will not harm the user’s device or data, as long as they do not fall for the cybercriminals’ smoke-and-mirror tactics. What’s more, to get rid of the locker requires no special knowledge or technical means.

But if the user panics, they could lose money. Kaspersky solutions block malicious web resources and threat-related files (scripts, content elements) with the verdict HEUR:Trojan.Script.Generic.

Indicators of compromise

Fake MVD websites


Fake law enforcement websites in other countries


2021. március 31.

Financial Cyberthreats in 2020

2020 was challenging for everyone: companies, regulators, individuals. Due to the limitations imposed by the epidemiological situation, particular categories of users and businesses were increasingly targeted by cybercriminals. While we were adjusting to remote work and the rest of the new conditions, so were scammers. As a result, 2020 was extremely eventful in terms of digital threats, in particular those faced by financial institutions.

At the same time, some of the known APT (Advanced persistent threats) groups that are not generally targeting financial institutions have tried their hand at it. Existing at a special crossroads between APT and financial crime, the Lazarus group has already been among the most active ones in the financial sphere. In 2020, the group tried its hand at the big extortion game with the VHD ransomware family. Later on other groups, such as MuddyWater, followed suit.

Moreover, in 2020, we saw regional actors go global. A few Brazilian malware families expanded their operations to other continents, targeting victims in Europe and Asia. We have dubbed the first four families to have done this (Guildma, Javali, Melcoz, Grandoreiro) “the Tétrade”. Later on the authors of Guildma also created the new banking malware Ghimob targeting users located in Brazil, Paraguay, Peru, Portugal, Germany, Angola, and Mozambique.

Of course, the known financial threats have remained, too. Thus, the year 2020 saw a surge in the use of Emotet, described by Interpol as “the world’s most dangerous malware”. In the beginning of 2021, law enforcement agencies all over the world joined their forces to disrupt the botnet’s infrastructure. According to Kaspersky experts, the operation will frustrate Emotet’s activities for at least several months. In the meantime, at least some of Emotet customers have switched to Trickbot.

Even though, in 2020, we have seen ever more sophisticated cyberattacks, the overall statistics look encouraging: the number of users hit by computer and mobile malware declines, so does financial phishing. Still, that does not mean that the cyber world has become a safer place – it means that the cybercriminals’ goals and tactics have undergone a number of changes. Despite the decreasing general statistics, we see that attacks have become more targeted and business-oriented. At the same time, we observe cybercriminals to skillfully adapt themselves to the global changes and benefit from the teleworking vulnerabilities and the rising popularity of online shopping. This report aims to shed a light on more details of financial cyberthreats in 2020.

This research is a continuation of our annual financial threat reports (2019, 2018 and 2017) providing an overview of the latest trends and key events across the financial threat landscape. Traditionally, the study covers the common phishing threats encountered by users, along with Windows and Android-based financial malware.


In this research, by financial malware we mean several types of malevolent software. Firstly, we identify as financial the malware targeting users of financial services such as online banking, payment systems, e-money services, e-shops, and cryptocurrency services. Secondly, we use the term to define the malware attempting to gain access to financial organizations and their infrastructure. In most cases, financial malware attacks rely on spamming and phishing activities, such as creating and distributing fake finance themed web pages and emails to steal the victims’ payment info.

To examine the financial sector threat landscape, Kaspersky researchers have analyzed the malicious activities on devices owned by individuals using the Kaspersky security products, which they volunteered to make available to us through the Kaspersky Security Network. The corporate user statistics were collected from the enterprise security solutions, after our customers agreed to share their data with Kaspersky.

The data for 2020 was mostly compared against 2019 to monitor the malware development trends. However, in some parts, for better insight into the financial malware evolution, the study also refers to earlier times.

Key findings


  • In 2020, the percentage of users hit by phishing declined slightly from 15.7% to 13.21%.
  • This time around, e-shops became the target of choice for phishing attacks. Almost every fifth attempted visit to a phishing page blocked by Kaspersky products has been related to online store phishing.
  • Phishing attacks against PayPal users soared from 26.8% in 2019 to 38.7% in 2020. The longtime leader of the category, Visa, dropped to the fourth place with 10.2% of phishing attacks against users of payment systems successfully prevented by Kaspersky in 2020.


  • In 2020, 625,364 users were attacked by banking Trojans – 148,579 less from 773,943 in 2019.
  • This year, users in Russia, Germany and Kazakhstan were the most frequent targets of financial malware.
  • Zbot is still the most widespread banking malware (22.2 % of attacked users), the second place is now held by CliptoShuffler (15.3%), with Emotet (14.5%) in the third place as before.
  • 36% of users hit by banking malware are corporate ones – an increase of one percentage point from the previous year.


  • This year, the number of users attacked by Android banking malware rapidly dropped by more than 55%: from 675,772 in 2019 to 294,158 in 2020.
  • Japan, Taiwan and Spain ended up with the highest percentage of users hit by Android banking malware.
Financial phishing

Financial phishing is one of the most popular tools used by cybercriminals to make money. Its prevalence is explained by the fact that it does not require much investment or technical expertise. In most cases, successful scammers win access either to the victim’s money or data that can be sold or otherwise monetized.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Percentage of financial phishing attacks (of the overall phishing attacks) detected by Kaspersky, 2016 – 2020 (download)

In 2020, Kaspersky anti-phishing technologies detected 434,898,635 attempted visits to various types of phishing pages. As can be seen from the graph above, 37.2% of those were related to financial phishing – 14.2 p.p. less than the figure registered in 2019 (51.4%). The lowest financial phishing percentage in the past five years.

By “financial phishing” we mean not banking phishing alone but several other types as well. For one, there are the ‘payment systems’, which include pages mimicking the well-known payment brands like PayPal, Visa, MasterCard, American Express and others. There are also the ‘e-shops’ which include online stores and auction sites like Amazon, Apple store, Steam, E-bay and others.

In 2019, the financial phishing cases detected by Kaspersky products were distributed as follows:

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Distribution of financial phishing cases by type in 2019 (download)

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Distribution of financial phishing cases by type in 2020 (download)

The year 2020 was definitely a unique one when it comes to financial phishing. One year back, we reported an increase in bank-related phishing from less than 22% to almost 30%. In 2020, banking phishing reached only 10.72 percent of the total. The e-shops, with 7.57% in 2019, on the contrary, almost tripled reaching 18.12%. Kaspersky experts connect these changes with the lockdown measures due to the pandemic – at home most of the time, people turned to online shopping and digital entertainment. Thus, growing demand from the users has led to increased “supply” from the cybercriminals. It should be noted that, while online shopping proved the most appealing field for scammers, payment systems were not that much of a lure – their share barely reaching 8.41%.

2019 statistics on payment systems:

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

The most frequently used brands in ‘payment systems’ financial phishing schemes in 2019 (download)

As can be observed from the graph above, the users of Visa Inc. (37.6%) were targeted the most in 2019. PayPal came in second with 26.8%, while MasterCard closed the top 3.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

The most frequently used brands in ‘payment systems’ financial phishing schemes in 2020 (download)

In 2020, the PayPal brand name (38.7%) was used for scam more than those of any other popular payment system. Its share grew by 12 p.p.

Example of a phishing page targeting PayPal users

Mastercard made it to the second place slightly increasing its share from 16.3% to 17.5%. The third and the fourth places, with a tiny difference between them, were taken by American Express (10.6%) and Visa (10.2%). As was observed, in 2020, scammers mimicked Visa Inc. 3.5 times less than in 2019 (37.6%).

Example of a phishing page targeting Visa users

In 2019, we analyzed the ‘e- shop’ brands most frequently used by cybercriminals in financial phishing schemes. The results showed Apple (42.8%) to be the number one choice for scam. The online stores Amazon (23.6%) and eBay (14.2%) took the second and the third place respectively.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Brands most frequently used in ‘e-shop’ financial phishing schemes, 2019 (download)

Examples of phishing pages based on the online store brands most used by cybercriminals

In 2020, as the e-shop phishing continued to grow, Amazon made it to the first place with 27.8% of total. Challenged by the popular online store, Apple (27.1%) stepped down to the second place, its share reduced by 15 p.p. Steam and eBay swapped their positions – Steam (14.9%) finished third, and eBay (12.8%) fourth.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Brands most frequently used in ‘e-shop’ financial phishing schemes, 2020 (download)

Banking malware for PC

In this study, we analyze the banking malware that steals the credentials used to access online banking or payment system accounts and to intercept one-time passwords.

After an upsurge of malware activity in October 2016, when as many as 1,494,236 users were hit, we observed a gradual decline in the number of users attacked with banking malware. 2020 was no exception. The number of attacked users has declined from 773,943 in 2019 to 625,364 – almost a 20% drop.

The reduction can be explained by the fact that attacks are becoming more targeted – cybercriminals now prefer to attack large businesses. Yet common users and small entities continue to fall victim to cybercriminal groups such as Zbot, CliptoShuffler, Emotet, RTM and others.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Dynamic change in the number of unique users attacked with banking malware 2018 – 2020 (download)

The main actors

Every year we detect multiple families of banking malware: some of them become outdated, some, on the contrary, gain popularity among cybercriminals. Below is a list of top 10 most active banking malware families detected in 2019. The leading ones were Zbot (21.6%), RTM (19.8%), Emotet (12.6%), CliptoShuffler (5.6%) and Trickster (5.5%).

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

TOP 10 most widespread banking malware families in 2019 (download)

This year we continued tracking the most active banking malware families. It is quite noteworthy that only four of them (Zbot, CliptoShuffler, Emotet and RTM) account for more than one half of the attacked users. Below is a list of top 10 banking malware families we detected in 2020.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

TOP 10 most widespread banking malware families in 2020 (download)

While Zbot (22.2%) still enjoys the status of the most used malware in the financial sphere, there were some changes in the list. RTM, with 10.5%, dropped from the second to the fourth place, while two other families, CliptoShuffler (15.3%) and Emotet (14.5%), both climbed higher in 2020. Notably, Gozi (3.3%), the second most active family just two years ago, was pushed out to the ninth place.

What is more, year 2020 has also been special for expansion of regional threat actors into the outside world. Thus, the four large Brazilian families we have called the Tétrade went global targeting not only Latin America but Asian and European countries as well.

Geography of attacked users

To assess and compare the degree of computer infection risk faced by users in different countries of the world, we have calculated for each country the proportion of Kaspersky product users faced by the threat during the period of report versus the total number of users attacked by financial malware.

Traditionally, more than half of all users hit with banking malware in 2019 and 2020 came from 10 countries. In 2019, the top 10 was as follows:

Russian Federation 33.6% Germany 7.4% China 3.3% Brazil 3% India 3% Mexico 3% Vietnam 2.70% Italy 2.60% Kazakhstan 2% United States 2%

In 2019, Russia’s share reached 33.6% of the total, Germany finishing second with 7.4%, and China closing the top three with 3.3%.

In 2020, the situation was as follows:

Russian Federation 26.6 Germany 4.5 Kazakhstan 4.1 Brazil 3.4 China 3.4 Italy 3.3 India 3.1 Mexico 2.8 Vietnam 2.8 Uzbekistan 2.3

As can be seen from the chart, despite the decline Russia (26.6%) and Germany (4.5%) still hold the first and second places in the top 10. Notably, Russia’s figures always tend to be the highest due to the fact that most Kaspersky users are located in Russia. Kazakhstan, which used to be 9th with 2%, this year broke into the top three having added 2 more percentage points.

Types of users attacked

It can be noticed that financial malware becomes more corporate-oriented. This year we observed that 36% of users attacked by banking malware are corporate ones – one percentage point up from the previous year. This partly confirms our hypothesis about cybercriminals shifting their attention to the corporate sector. Still, the increase is relatively small, and we expect the redistribution of attacks between corporate and private users to clear up in the near future.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Corporate vs consumer product users, 2019–2020 (download)

All in all, in 2020, companies became more vulnerable due to the restrictions for onsite work and staff, coupled with increased number of employees using the corporate network remotely. The hasty transition to teleworking has affected the corporate security – most businesses were not ready to go online. Some of them lacked the devices, so employees had to use their home computers for work. Lack of online security training, default laptop configurations left as is, vulnerable remote access connections – together these factors have paved way to all sorts of attacks, including banking malware scams.

Сryptocurrency related cyberthreats in 2020

Three years ago, in 2018, cryptocurrencies made the hottest topic and turned the eyes of the whole cybersecurity community to the new danger. We have analyzed the hidden mining software cybercriminals spread to coin money at the users’ cost, and found that today the malicious activity is not that widespread.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Number of users attacked by mining malware in 2019 (download)

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Number of users attacked by mining malware in 2020 (download)

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Geography of mining attacks, 2020 (download)

Thus, in 2020, we continued to observe a downward trend for this type of threat. Yet by the end of the year the numbers reached a certain plateau, and we even saw local trend reversals. It is likely that the sharp increase in cryptocurrency prices at the end of 2020 may boost the threat in early 2021. Moreover, due to the COVID crisis, we may yet see some economies collapsing and local currencies plummeting in 2021, which would turn cryptomining a lot more attractive.

Mobile banking malware

Android banking malware is a well-known threat Kaspersky experts have been analyzing for years. Last year was a dramatic one in terms of mobile banking malware. As stated in our previous annual report, in 2019, the number of users hit by it dropped to just over 675 thousand from around 1.8 million in 2018.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Number of users attacked with Android banking malware, 2018 – 2019 (download)

In 2020, we observed a continuation of this trend as the number of attacked users decreased by slightly less than 60% to 294,158.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Number of users attacked with Android banking malware, 2019 – 2020 (download)

To get a better view of the reasons behind these dramatic changes, Kaspersky experts took a closer look at the landscape and reviewed the most widespread families over the year. In 2019, the situation was as follows:

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Most widespread Android banking malware in 2019 (download)

In 2020, Asacub’s (25.6%) share is still the weightiest. Yet it shrank by 18.8 percentage points since 2019. Agent (18.0%) is still in the second position, although a bit lighter from the year before. Svpeng (12.8%), which mostly hunts for the administrator rights on the infected device, this year was challenged by Rotexy (17.9%), in which the banking Trojan’s features are combined with those of a ransomware blocker.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Most widespread Android banking malware in 2020 (download)

All in all, 2020 was rich in new mobile banking malware. Let us give a brief overview of this year’s major findings:

  • Trojan-Banker.AndroidOS.Ghimob.a
    New banking malware from the Tétrade group that went global this year and attacked banks, exchanges, cryptocurrency exchangers and fintech organizations in Brazil, Paraguay, Peru, Portugal, Germany, Angola, and Mozambique. Ghimob was able to spy on a total of 153 mobile apps, which is impressive for a banking Trojan.
  • Trojan-Banker.AndroidOS.Gorgona.a
    The malware mimics Google Play and uses the notification panel to attract the user’s attention. It can make and redirect calls, execute USSD commands, install additional apps and block the device, if needed. If granted the permission to use Accessibility, it can get even more rights, for example, to receive and process text messages. Thus, it can gain control of the two-factor authentication. Uses TCP for C2 communication. Tends to target banks in Turkey.
  • Trojan-Banker.AndroidOS.Knobot.a
    The new financial threat market player. Alongside phishing windows and interception of the two-factor authentication messages, the Trojan offers several features not typical of financial threats. For example, a mechanism for interception of device PIN code through Accessibility services.
    Ironically, it asks its victim to delegate the rights and even provides a small instruction on how to do it.

    A screenshot of Trojan-Banker.AndroidOS.Knobot.a on user’s phone

Geography of attacked users

Top 10 countries by percentage of users hit by Android banking malware in 2019:

Russian Federation 0.72% South Africa 0.66% Australia 0.59% Spain 0.29% Tajikistan 0.21% Turkey 0.20% United States 0.18% Italy 0.17% Ukraine 0.17% Armenia 0.16%

Top 10 countries by percentage of users hit by Android banking malware in 2020:

Japan 2.83% Taiwan (province of China) 0.87% Spain 0.77% Italy 0.71% Turkey 0.60% Korea 0.34% Russian Federation 0.25% Tajikistan 0.21% Poland 0.17% Australia 0.15%

As can be seen from the statistics, all the countries were completely reshuffled year on year. Russia from it top position in 2019 moved to the 7th place in 2020. Armenia, which used to close the 2019 chart, left it altogether. On the other hand, Japan (2.83%) and Taiwan (0.87%), not even mentioned in 2019, rapidly gained more users hit by Android banking malware and made it to the top. Meanwhile Spain (0.77%) ousted Australia from the third place with almost 3 thousand of affected users.


The year 2020 has shown that cybercriminals can easily adapt to new realities of the changing world. They keep updating their malware with new features and improving the detection avoidance techniques. The general statistics in all the areas we have analyzed (PC and mobile malware, phishing) is on the downward trend, which is a good sign.

We have observed that, in 2020, the phishing scammers have switched their attention from banks to e-shops. This trend is closely related to the pandemic, which has greatly changed the public’s attitude towards online shopping: criminals have marked its growing popularity and turned focus on it. We have registered a slight increase of the share of malware attacks against corporate users. The emerging trend of banking Trojans targeting corporate users is also of concern, as such attacks are likely to bring more problems than attacks on individuals. At the same time, the regional scam factories targeting financial organizations are increasingly reaching the global level, potentially resulting in more growth in 2021. Thus, even though the general statistics look positive, we have to consider the massive threat landscape still faced by financial organizations.

For protection against financial threats, Kaspersky recommends users to:

  • Install only applications obtained from reliable sources, such as the official websites;
  • Check the access rights and permissions requested by the application – do not grant them if they fail to match the app’s feature set;
  • Never follow links from spam messages and never open documents attached to them;
  • Install a trusted security solution, such as Kaspersky Security Cloud – it will protect you from a broad range of financial cyberthreats.

To protect your business from financial malware, Kaspersky security experts recommend:

  • Introduce cybersecurity awareness training for your employees, particularly those responsible for accounting, to teach them to detect phishing pages and improve the digital literacy of staff in general;
  • For critical user profiles, such as those in financial departments, enable the default deny mode for web resources to ensure that only legitimate ones can be accessed;
  • Install the latest updates and patches for all the software you use;
  • For protection from complex threat and targeted attacks, install the anti-APT and EDR solutions for network threat detection, incident investigation and timely recovery action. Provide your SOC team with access to the latest threat intelligence and regular upskill training. All these are available within the Kaspersky Expert Security framework.
2021. március 30.

APT10: sophisticated multi-layered loader Ecipekac discovered in A41APT campaign

Why is the campaign called A41APT?

In 2019, we observed an APT campaign targeting multiple industries, including the Japanese manufacturing industry and its overseas operations, that was designed to steal information. We named the campaign A41APT (not APT41) which is derived from the host name “DESKTOP-A41UVJV” from the attacker’s system used in the initial infection. The actor leveraged vulnerabilities in Pulse Connect Secure in order to hijack VPN sessions, or took advantage of system credentials that were stolen in previous operations.

Log of the hijacking VPN session from DESKTOP-A41UVJV

A41APT is a long-running campaign with activities detected from March 2019 to the end of December 2020. Most of the discovered malware families are fileless malware and they have not been seen before. One particular piece of malware from this campaign is called Ecipekac (a.k.a DESLoader, SigLoader, and HEAVYHAND). It is a very sophisticated multi-layer loader module used to deliver payloads such as SodaMaster (a.k.a DelfsCake, dfls, and DARKTOWN), P8RAT (a.k.a GreetCake, and HEAVYPOT) and FYAnti (a.k.a DILLJUICE stage2) which loads QuasarRAT.

In November and December 2020, Symantec and LAC both published blogposts about this campaign. A month later, we discovered new activities from A41APT that utilized modified and updated payloads, and that’s what we cover in this blog.

In February 2021, a GReAT security expert and his friends gave a presentation on the A41APT campaign at the GReAT Ideas event. You can download the slides here. Further information about A41APT is available to customers of the Kaspersky Intelligence Reporting service. Contact intelreports@kaspersky.com

Technical analysis: Ecipekac

We observed a multi-layer x64 loader used exclusively by this actor and dubbed Ecipekac after a unique string found in the second layer of the Ecipekac loader. The string is “Cake piece” in reverse (with a typo).

The hardcoded unique string “ecipekac”

Ecipekac uses a new, complicated loading schema: it uses the four files listed below to load and decrypt four fileless loader modules one after the other to eventually load the final payload in memory.

Ecipekac infection flow

The files are:

Filename MD5 Hash Description policytool.exe 7e2b9e1f651fa5454d45b974d00512fb Legitimate exe for DLL side-loading jli.dll be53764063bb1d054d78f2bf08fb90f3 Ecipekac Layer I loader vac.dll f60f7a1736840a6149d478b23611d561 Encrypted Ecipekac Layer II loader (shellcode) pcasvc.dll 59747955a8874ff74ce415e56d8beb9c Encrypted Ecipekac Layer IV loader (shellcode)

Please note that the Ecipekac Layer III loader module is embedded in the encrypted Layer II loader.

Ecipekac: Layer I loader

Layer I of Ecipekac infection flow

The Ecipekac Layer I loader abuses policytool.exe, a legitimate application that is normally packaged in the IBM Development Package for Eclipse, to load a malicious DLL named ‘jli.dll’ in the current directory via the DLL side-loading technique. The ‘jli.dll’ file acts as the first layer of the Ecipekac loader. This DLL file has a number of export functions; however, all of them refer to a similar function that carries the main loading feature. The loader reads 0x40408 bytes of data from the end of another DLL – ‘vac.dll’ (where the data section starts at the offset of 0x66240). The data size of 0x40408 is derived from a hardcoded value, 0x40405, incremented until it’s divisible by eight.

MD5 f60f7a1736840a6149d478b23611d561 SHA1 5eb69114b2405a6ea0780b627cd68b86954a596b SHA256 3b8ce709fc2cee5e7c037a242ac8c84e2e00bd597711093d7c0e85ec68e14a4c Link time 2033-11-13 08:50:03 File type PE32+ executable (DLL) (GUI) x86-64, for MS Windows Compiler Linker Version: 14.13, OS Version: 10.0 File size 681544 (666KB) File name vac.dll Embedded data at 0x66240
00066240: febe d990 66de 1bc9 75b7 dc2c 3e1f 3ef2
00066250: 78d0 0005 5c27 a511 c122 bdf4 15e7 052c
00066260: af72 7e08 064c f7b9 70f0 57bf 250a 3b4d
000a6630: ee4b b1f2 294d eea1 290e aba2 6954 130f
000a6640: 1267 9ab3 f800 0000

The ‘vac.dll’ DLL file is signed with a valid, legitimate digital signature, although the file has been tampered with. At first glance, the fact that its digital signature is valid would suggest the file has not been manipulated after being digitally signed.

The signed digital certificate of vac.dll

However, what happened was that the actor resized the Certificate Table in the digitally signed ‘vac.dll’ and inserted their own data in the Certificate Table so it doesn’t affect the digital signature. This technique was published at BlackHat 2016 as MS13-098.

The layer I loader decrypts the layer II loader shellcode from the embedded data in ‘vac.dll’. Several crypto algorithms are used, such as XOR, AES and DES. The order and combination of algorithms, as well as the decryption keys, are different from one sample to another.

Decryption flow in first loader

For example, in the sample shown above, the order of crypto algorithms was a one-byte XOR using the hardcoded key of ‘0x9F’, followed by an AES CBC mode decryption with the AES key ’83H4uREKfFClDH8ziYTH8xsBYa32p3wl’ and the IV key ’83H4uREKfFClDH8z’.

One interesting characteristic of Ecipekac is that the attackers implemented these cryptographic algorithms in their own code instead of using the Windows API. The attackers have also made slight modifications compared to the original implementation. For instance, in the function related to the AES algorithm, they intentionally referenced the third byte of the AES key as shown in the following code.

A small modification in the AES function

Apart from the AES algorithm mentioned, the attackers have also modified the DES algorithm.

Ecipekac: Layer II loader shellcode

Layer II of infection flow using Ecipekac

The Ecipekac Layer II loader is a simple shellcode which contains the data of the next layer DLL in disordered parts. At first, this shellcode checks for the magic string “ecipekac” in this data set. Then it reconstructs and loads each part of the embedded data into allocated memory in the correct order to create the original code of the DLL as shown below.

Reconstruction for the divided PE BLOB in memory

Then it calls the entry point of the loaded DLL which is the third layer of Ecipekac. Based on our investigation, the magic string used in this module is not exclusively “ecipekac” in all instances. We also observed “9F 8F 7F 6F” and “BF AF BF AF” being used in several samples instead.

Ecipekac Layer III loader DLL

Layer III of infection flow using Ecipekac

The third layer’s method of loading the next layer resembles the first layer. It reads encrypted data from the end of ‘pcasvc.dll’, which is signed using a digital certificate as is the case with ‘vac.dll’.

MD5 59747955a8874ff74ce415e56d8beb9c SHA1 0543bfebff937039e304146c23bbde7693a67f4e SHA256 a04849da674bc8153348301d2ff1103a7537ed2ee55a1588350ededa43ff09f6 Link time 2017-02-24 15:47:04 File type PE32+ executable (DLL) (console) x86-64, for MS Windows Compiler Linker Version: 14.13, OS Version: 10.0 File size 733232 (717KB) File name pcasvc.dll Embedded data at 0x87408 (size:0x2BC28) 00087408: 98e4 1def 8519 d194 3c70 4e84 458a e34c
00087418: b145 74da c353 8cf8 1d70 d024 8a54 8bde
000b3010: 2c1b 6736 8935 d55d 8090 0829 5dfc 7352
000b3020: 44bd c35b 9b23 1cb6 0000 0000 0000 0000

The crypto algorithms are again one-byte XOR and AES CBC mode, this time to decrypt the fourth loader shellcode from the embedded data of ‘pcasvc.dll’. However, the sequence of algorithms is in reverse order compared to the first layer. The hardcoded keys are also different: “0x5E” is used as the XOR key, while the AES key and IV are “K4jcj02QSLWp8lK9gMK9h7W0L9iB2eEW” and “K4jcj02QSLWp8lK9” respectively.

Ecipekac: Layer IV loader shellcode

Layer IV of infection flow using Ecipekac

During our research, we found three different types of shellcode used as the fourth layer of Ecipekac.

Layer IV loader shellcode – first type

The first shellcode type’s procedure acts the same way as the Ecipekac Layer II shellcode, with the only difference being the embedded PE, which is the final payload of Ecipekac in this case. The payload of the first type shellcode is either “P8RAT” or “FYAnti loader”. An analysis of these payloads is provided in the later sections of this report.

Layer IV loader shellcode – second type

The second type of shellcode is totally different from the other loader types. This shellcode has a unique data structure shown in the table below.

Offset Example Data Description 0x000 90 90 90 90 90 90 90 90 magic number to check before proceeding to data processing. 0x008 0x11600 size of encrypted data 0x00C A9 5B 7B 84 9C CB CF E8 B6 79 F1 9F 05 B6 2B FE 16 bytes RC4 key 0x01C C7 36 7E 93 D3 07 1E 86 23 75 10 49 C8 AD 01 9F 6E D0 9F 06 85 97 B2
[skipped] Encrypted payload (SodaMaster) by RC4

This shellcode confirms the presence of the magic number “90 90 90 90 90 90 90 90” at the beginning of this data structure, before proceeding to decrypt a payload at offset 0x01C using RC4 with a 16-byte key of “A9 5B 7B 84 9C CB CF E8 B6 79 F1 9F 05 B6 2B FE”. The decrypted payload is “SodaMaster”, and is described later in this report.

Layer IV loader shellcode – third type

The last type of shellcode is a Cobalt Strike stager. We have confirmed the use of several different Cobalt Strike stager shellcodes since October 2019. In addition, some of the observed Cobalt Strike stager samples included a setting in the HTTP header of their malicious communications to disguise them as common jQuery request in order to evade detection by security products.

Hardcoded HTTP header to impersonate jQuery request

The actual hardcoded C2 used in the HTTP header for the C2 communication impersonating JQuery requests was “51.89.88[.]126” with the respective port 443.

Payloads of Ecipekac

Payload of Infection flow using Ecipekac

As mentioned previously, apart from the Cobalt Strike stager, we observed three types of final payload implanted by the Ecipekac loader during this long-running campaign.

  • P8RAT
  • SodaMaster
  • FYAnti loader for QuasarRAT

The following timeline shows samples of the Ecipekac loader together with their respective filename and payload type based on a compilation timestamp of the first layer DLL:

Timeline of the Ecipekac loader files and payloads

Cobalt Strike’s stager has been used throughout the research period. FYAntiLoader for QuasarRAT was monitored in October 2019, and has not been observed since then. Instead of this, SodaMaster and P8RAT were monitored from May 2020.


One of Ecipekac’s payloads is a new fileless malware which we call P8RAT (a.k.a GreetCake). P8RAT has the following unique data structure used to store the C2 communication configuration. We collected several samples of P8RAT during our research and found no C2 address of P8RAT that was used more than once. In total we found 10 backdoor commands in all the collected P8RAT samples. The most recent P8RAT sample, with the compilation timestamp of December 14, 2020, shows a new backdoor command with the code number of “309” implemented. The command “304”, which was present in earlier samples and carries similar functionality, was removed.

Command Description Compilation time of P8RAT 2020-03-30 2020-08-26 2020-12-14 300 Closing socket Enabled Enabled Enabled 301 Creating a thread for executing/loading a downloaded PE file Enabled Enabled Enabled 302 No functionality Enabled Removed Removed 303 Sending randomly generated data Enabled Enabled Enabled 304 Executing/loading downloaded PE/shellcode Enabled Removed Removed 305 Setting value of “Set Online Time” (the string was hardcoded in the P8RAT version compiled on 2020-03-30 and removed from the P8RAT version compiled on 2020-08-26). Enabled Enabled Enabled 306 Setting value of “Set Reconnect TimeOut” (the string was hardcoded in the P8RAT version compiled on 2020-03-30 and removed from the P8RAT version compiled on 2020-08-26). Enabled Enabled Enabled 307 Setting value of “Set Reconnect times” (the string was hardcoded in the P8RAT version compiled on 2020-03-30 and removed from the P8RAT version compiled on 2020-08-26). Enabled Enabled Enabled 308 Setting value of “Set Sleep time” (the string was hardcoded in the P8RAT version compiled on 2020-03-30 and removed from the P8RAT version compiled on 2020-08-26). Enabled Enabled Enabled 309 Creating thread for executing downloaded shellcode was implemented from the P8RAT version compiled on 2020-12-14. Not implemented Not implemented Enabled

The main purpose of P8RAT is downloading and executing payloads (consisting of PE and shellcode) from its C2 server. However, we were unable to obtain any sample of the subsequent payloads for this malware.

In the P8RAT sample from March 2020, hardcoded strings such as “Set Online Time”, “Set Reconnect TimeOut”, “Set Reconnect Times” and “Set Sleep Time” were used in regard to backdoor commands “305” to “308”, which point to the possible purpose of these commands. Based on these strings, which were removed from the P8RAT samples in August 2020, we speculate that these commands are possibly used to control the intervals of the C2 communication by defining sleep time, reconnect time and reconnect timeout in order to blend C2 communication with normal network traffic of the system.

In another update, the P8RAT sample from August 2020 looks for two process names (“VBoxService.exe” and “vmtoolsd.exe”) on the victim’s system, to detect VMware or VirtualBox environments at the beginning of its main malicious function.

Hardcoded file names to detect VMware and VirtualBox

Interestingly the attacker made some modifications to P8RAT in December 2020, shortly after the publication of the two blogposts from Symantec on November 17, 2020, and LAC on December 1, 2020 (in Japanese). We strongly believe that this actor had examined these security vendors’ publications carefully and then modified P8RAT accordingly.


Another payload of the Ecipekac loader, which we call SodaMaster (a.k.a DelfsCake), is also a new fileless malware. In our research we found more than 10 samples of SodaMaster. All the collected samples of this module were almost identical, with the offsets and hex patterns of all functions perfectly matching. The only differences were in the configuration data, including a hardcoded C2, an encoded RSA key and additional data for calculating a mutex value.

Configuration of SodaMaster

When execution of this malware begins, it creates a mutex with a name in the reverse order of the CRC32 checksum calculated from the encoded RSA key and its following additional data. Then the malware randomly generates a value as an RC4 key for C2 communication. The first data block sent to the C2 server includes the user_name, the host_name, PID of the malware module, OS_version, socket_name, the generated RC4 key and the malware’s elapsed running time.

C2 communication of SodaMaster

We confirmed four backdoor commands, coded as “d”, “f”, “l” and “s”, in the recent SodaMaster sample. In addition, we also discovered an old SodaMaster sample which has only two commands. A description of each command is shown in the following table.

Command Description Compilation time of P8RAT 2019-01-07 2019-06-10 d Create thread for launching downloaded DLL and call export function of the DLL. Enabled Enabled f Set value as RC4 key for the encrypted C2 communication Not implemented Enabled l Set value as sleep time Not implemented Enabled s Create thread for executing downloaded shellcode Enabled Enabled

Based on the analysis of the backdoor features of the SodaMaster module, the purpose of this malware is also to download and execute payloads (DLL or shellcode), like P8RAT. Unfortunately, we have not been able to obtain these payloads yet.

The SodaMaster module also shows an anti-VM feature. The malware looks for the presence of the registry key “HKEY_CLASSES_ROOT\\Applications\\VMwareHostOpen.exe” on the victim’s system before proceeding to its main functionality. This registry key is specific to the VMware environment.

SodaMaster anti-VM check

Another characteristic of SodaMaster is the use of a common obfuscation technique known as “stackstrings” to create the registry key in double-byte characters. We observed the same obfuscation technique used for a process name and DLL name in other SodaMaster samples.

FYAnti loader for QuasarRAT

The last observed type of payload deployed by Ecipekac is a loader module named FYAnti loader. In the Ecipekac loader malware of the fourth layer, the DLL is loaded into memory and an export carrying the name “F**kY**Anti” is called. We named this loader “FYAnti” because of this distinct string. The execution flow of the FYAnti has two additional layers to implement the final stage, which is a QuasarRAT (a.k.a xRAT).

Infection flow of FYAnti loader

The first layer of the FYAnti loader decrypts an embedded .NET module and executes it using the CppHostCLR technique. The .NET module is packed using “ConfuserEx v1.0.0” and acts as yet another loader that searches for a file in the “C:\Windows\Microsoft.NET\” directory with file sizes between 100,000 and 500,000. The unpacked code is shown in the screenshot below.

Unpacked code of the second layer loader of FYAnti to search a file

In this instance, an encrypted file named “web_lowtrust.config.uninnstall” is found and used as the next stage module. The .NET module loads and decrypts this file using AES CBC mode. The decrypted payload is another .NET module named Client.exe which is QuasarRAT, a popular open-source remote administration tool. The configuration data is stored in the binary with most of this data being encrypted by AES CFB mode and base64. The AES key is generated using the hardcoded string “KCYcz6PCYZ2VSiFyu2GU”in the configuration data.

Malware configuration of QuasarRAT

All loader modules and payloads are decrypted and executed in memory only.


Based on our investigations, we assess with high confidence that the APT10 threat actor is behind the A41APT campaign. This attribution is based on the following points:

First, the hardcoded URL “www.rare-coisns[.]com” from an x86 SodaMaster sample was mentioned in the report from ADEO regarding APT10’s activity targeting the finance and telecommunication sectors of Turkey, also fitting the geolocation of the VirusTotal submitter.

Second, the similarity of the A41APT campaign with APT10 activities described in a Cylance blogpost. These include the Ecipekac Loader, FYAnti loader’s unique export name “F**kY**Anti”, using the CppHostCLR technique and QuasarRAT used as the FYAnti’s final payload. Moreover, as stated in the Symantec blogpost, the FYAnti loader, the export name “F**kY**Anti”, CppHostCLR technique for injection of .NET loader and the QuasarRAT were similar to the activities of the APT10 group discovered by the BlackBerry Cylance threat research team.

Last but not least, there are some similarities and common TTPs to those outlined in our previous TIP report on APT10 activities:

  • Implementation of the hashing or crypto algorithms done manually by the malware developers instead of using Windows APIs, with some modifications;
  • Use of calculated hash values (fully or partially) for some features like crypto keys, part of the crypto keys, key generation, mutex names and so on;
  • Using the DLL side-loading technique to run a payload in memory;
  • Using PowerShell scripts for persistence and also for lateral movement;
  • Using exe for removing logs in order to hide their activities;
  • Sending victim machine data such as username, hostname, PID, current time and other specifics – though this point is not unique to APT10 backdoors and is quite common in most backdoor families;
  • Modifying implants shortly after security researchers publish their analysis of the actor’s activities and TTPs;
  • Targeting mainly Japan, alongside associated overseas branches or organizations related to Japan.

However, we observed some interesting differences in the A41APT campaign and previous activities:

  • P8RAT and SodaMaster did not contain a malware version number as opposed to the previous malware instances used by APT10 such as LilimRAT, Lodeinfo and ANEL;
  • As for the infection vector, we could not identify any spear-phishing email in this A41APT campaign, which is quite common in APT10 attacks.

Overall, APT10 is considered a large APT group running multiple simultaneous campaigns and, understandably, TTPs differ from one campaign to another. We believe the differences mentioned here for the A41APT campaign represent a normal variation of TTPs that can be expected in the case of such a large APT group.


We consider the A41APT campaign to be one of APT10’s long-running activities. This campaign introduced a very sophisticated multi-layer malware named Ecipekac and its payloads, which include different unique fileless malware such as P8RAT and SodaMaster.

In our opinion, the most significant aspect of the Ecipekac malware is that, apart from the large number of layers, the encrypted shellcodes were being inserted into digitally signed DLLs without affecting the validity of the digital signature. When this technique is used, some security solutions cannot detect these implants. Judging from main features of the P8RAT and SodaMaster backdoors, we believe that these modules are downloaders responsible for downloading further malware that, unfortunately, we have not been able to obtain so far in our investigation.

We see the activity outlined in this report as a continuation of the activity we previously reported in our Threat Intelligence Portal, where, in 2019, this threat actor began targeting overseas offices of Japanese associations or organizations using the ANEL malware. The operations and implants of the campaign described in this report are remarkably stealthy, making it difficult to track the threat actor’s activities. The main stealth features are the fileless implants, obfuscation, anti-VM and removal of activity tracks.

We will continue to investigate and track the activities of the APT10 actor, which are expected to keep improving its covertness with each year.

Appendix I – Indicators of Compromise

Note: The indicators in this section are valid at the time of publication. Any future changes will be directly updated in the corresponding .ioc file.

File Hashes (malicious documents, trojans, emails, decoys)

Ecipekac loader
be53764063bb1d054d78f2bf08fb90f3   jli.dll     P8RAT
cca46fc64425364774e5d5db782ddf54   vmtools.dll SodaMaster
dd672da5d367fd291d936c8cc03b6467   CCFIPC64.DLL      FYAnti loader

Encrypted Ecipekac Layer II, IV loader (shellcode)
md5   filename    payloads
f60f7a1736840a6149d478b23611d561   vac.dll     P8RAT
59747955a8874ff74ce415e56d8beb9c   pcasvc.dll  P8RAT
4638220ec2c6bc1406b5725c2d35edc3    wiaky002_CNC1755D.dll   SodaMaster
d37964a9f7f56aad9433676a6df9bd19    c_apo_ipoib6x.dll SodaMaster
335ce825da93ed3fdd4470634845dfea   msftedit.prf.cco  FYAnti loader
f4c4644e6d248399a12e2c75cf9e4bdf   msdtcuiu.adi.wdb  FYAnti loader

Encrypted QuasarRAT
md5   filename    payloads
019619318e1e3a77f3071fb297b85cf3   web_lowtrust.config.uninstall QuasarRAT

Domains and IPs


Appendix II – MITRE ATT&CK Mapping This table contains all the TTPs identified in the analysis of the activity described in this report. Tactic Technique Technique Name Initial Access T1133 External Remote Services

Uses vulnerabilities in Pulse Connect Secure to hijack a VPN session. T1078 Valid Accounts

Uses stolen credentials to connect to the enterprise network as initial infection. Execution T1059.001 Command and Scripting Interpreter: PowerShell

Uses PowerShell to download implants and remove logs. T1053.005 Scheduled Task/Job: Scheduled Task

Creates a task for running a legitimate EXE with Ecipekac (malicious DLL) using DLL side-loading technique. Persistence T1574.001 Hijack Execution Flow: DLL Search Order Hijacking

Uses a legitimate EXE file which loads Ecipekac (malicious DLL) in the current directory. T1574.002 Hijack Execution Flow: DLL Side-Loading

Uses a legitimate EXE file which loads Ecipekac (malicious DLL) in the current directory. T1053.005 Scheduled Task/Job: Scheduled Task

Creates a task for running a legitimate EXE with Ecipekac (malicious DLL) using DLL side-loading technique. T1078 Scheduled Task/Job: Scheduled Task

Uses stolen credentials to connect to the enterprise network as initial infection. Privilege Escalation T1574.001 Hijack Execution Flow: DLL Search Order Hijacking

Uses a legitimate EXE file which loads Ecipekac (malicious DLL) in the current directory. T1574.002 Hijack Execution Flow: DLL Side-Loading

Uses a legitimate EXE file which loads Ecipekac (malicious DLL) in the current directory. T1053.005 Scheduled Task/Job: Scheduled Task

Creates a task for running a legitimate EXE with Ecipekac (malicious DLL) using DLL side-loading technique. T1078 Scheduled Task/Job: Scheduled Task

Uses stolen credentials to connect to the enterprise network as initial infection. Defense Evasion T1574.001 Hijack Execution Flow: DLL Search Order Hijacking

Uses a legitimate EXE file which loads Ecipekac (malicious DLL) in the current directory. T1574.002 Hijack Execution Flow: DLL Side-Loading

Uses a legitimate EXE file which loads Ecipekac (malicious DLL) in the current directory. T1053.005 Scheduled Task/Job: Scheduled Task

Creates a task for running a legitimate EXE with Ecipekac (malicious DLL) using DLL side-loading technique. T1078 Scheduled Task/Job: Scheduled Task

Uses stolen credentials to connect to the enterprise network as initial infection. T1070.003 Indicator Removal on Host: Clear Command History

Removes Powershell execution logs using Wevtutil.exe. T1036 Masquerading

Encrypted shellcode of Ecipekac was embedded in the legitimate DLL. T1497.001 Virtualization/Sandbox Evasion: System Checks

Payloads of Ecipekac check a registry key and process names to identify VM environment. Discovery T1057 Process Discovery

Checks the process of VMware and VirtualBox to identify the VM environment. T1082 System Information Discovery

SodaMaster sends system information such as user_name, the host_name, PID of the malware module, OS_version, etc. T1012 Query Registry

Checks a registry key of VMware to identify the VM environment. Lateral Movement T1210 Exploitation of Remote Services

Uses vulnerabilities in Pulse Connect Secure to hijack a VPN session. Command and Control T1071.001 Application Layer Protocol: Web Protocols

Cobalt Strike’s stager uses HTTP protocol for communication with C2 server to disguise as a common jQuery. T1132.002 Data Encoding: Non-Standard Encoding

SodaMaster uses an original data structure and RSA for the first communication, then uses RC4 for encryption.

2021. március 29.

Doxing in the corporate sector


Doxing refers to the collection of confidential information about a person without their consent for the purpose of inflicting harm on that person or to otherwise gain some benefit from gathering or disclosing such information. Normally, doxing involves a threat to specific people, such as media personalities or participants of online discussions. However, any organization can also become a victim of doxing. Confidential corporate information is no less sensitive than the personal data of an individual, and the sheer scale of financial and reputational risks from potential blackmail or disclosure of such information can have a colossal impact.

In the article titled “Dox, steal, reveal. Where does your personal data end up?”, we mentioned that a cybercriminal could attack their victim by using targeted phishing e-mails to obtain access to the victim’s data. But this probably would be an expensive undertaking. However, when doxing is aimed at the corporate sector, cybercriminals are less hindered by the cost of an attack because the potential monetary rewards are much larger. To gather as much confidential corporate information as possible, cybercriminals are employing much more diverse methods than they normally would in their attacks against individual users. We will discuss those methods in this article.

Collecting information about a company from public sources

The first and simplest step that can be taken by cybercriminals is to gather data from publicly accessible sources. The Internet can provide doxers with all kinds of helpful information, such as the names and positions of employees, including those who occupy key positions in the company. Such key positions include the CEO, HR department director, and chief accountant.

For example, if LinkedIn shows that the CEO of a company is “friends” with the chief accountant or head of the HR department, and these persons are also friends with their direct subordinates, a cybercriminal only needs to know their individual names to easily figure out the company’s hierarchy and use this information for subsequent attacks.

In less professionally-oriented social networks such as Facebook, many users indicate their workplace and also publish a large amount of personal information, including recreational photos and the specific restaurants and gyms that they visit. You might think that this kind of information would be useless for an attack on a company because this personal info is not actually related to the company and contains no data that could actually compromise the company or the account owner. However, you would be surprised at how useful this information really could be to a cybercriminal.

Attacks using publicly accessible data: BEC

Information from personal profiles of employees can actually be used to set up BEC attacks. A BEC (Business E-mail Compromise) is a targeted attack on the corporate sector in which a cybercriminal initiates e-mail correspondence with an employee of an organization by posing as a different employee (including their superior) or as a representative of a partner company. The attacker does this to gain the trust of the victim before ultimately persuading the victim to perform certain actions, such as sending confidential data or transferring funds to an account controlled by the attacker. We registered 1,646 unique BEC attacks during February of 2021 alone. Let’s examine a scenario in which information from personal profiles of employees can help cybercriminals achieve their ultimate goals.

On his own page on a social network, an employee of a large company publishes an innocent photo with an ocean view and a comment stating that he still has three more weeks of vacation. A few days later, the company account department’s mailbox receives an e-mail from the vacationing employee requesting his pay to be deposited to a card in a different bank. The e-mail sender requests that they take care of this as quickly as possible, and explains that he can’t take any calls because he got sick and is not able to speak over the phone.

Example BEC attack with switched bank details

The unsuspecting accountant asks the employee to send his new bank details. After receiving this new banking information, the accountant changes the employee’s data in the system, and payment is sent to the new bank account some time later. However, a few weeks later, the clueless employee returns from vacation without a penny to his name and is dying to know why the accountant never sent his money.

After a little investigation, they determine that the e-mail regarding payment had been sent by cybercriminals who found out from the employee’s social network post that he was on vacation and temporarily unreachable. Although they used the real first and last name of the employee, the fraudulent message had been sent from a spoofed domain that was very similar to the domain of the organization (more details about this technique can be found in this article).

BEC attacks as a means to collect data

In the example above, the goal of the cybercriminals was a one-time financial profit. However, as we mentioned earlier, BEC attacks can also be aimed at obtaining confidential information. Depending on the position of the employee or the importance of the partner being impersonated by the cybercriminals, they could obtain access to fairly sensitive documents such as contracts or customer databases. In addition, cybercriminals may not limit themselves to just one attack, but could use any acquired information to pursue a larger goal.

Leaked data

Confidential documents that end up in the public domain either by carelessness or from malicious intent can also help cybercriminals to complete a dossier on a company. Over the past few years, there has been a notable increase in data breaches related to data stored in the cloud. Most of these breaches occur with Amazon AWS Simple Cloud Storage (AWS S3) due to the widespread popularity of this system as well as the apparent simplicity of its configuration, which does not require any special knowledge of information security. This simplicity is what ultimately poses a danger to the owners of file repositories in AWS known as “buckets”, which are most often breached due to an incorrect system configuration. For example, in July of 2017, the data of 14 million Verizon users was breached due to incorrectly configured buckets.

Tracking pixel

Cybercriminals may resort to various technical tricks to obtain information relevant to their particular goals. One of these tricks is to distribute e-mail messages containing tracking pixel that are often disguised as some type of “test” messages. This technique enables attackers to obtain data such as the time the e-mail was opened, the specific version of the recipient’s mail client, and the IP address, which could help find out the approximate location of the recipient. Using this information, cybercriminals can build a profile on a specific person whom they can then impersonate in subsequent attacks. Specifically, if scammers know the daily schedule and time zone of an employee, they can choose the most ideal time to conduct an attack.

Here’s one example of doxing through the use of a tracking pixel, in which the CEO of a large company receives so-called “test messages” whose contents may slightly vary.

Example test message containing a tracking pixel

Messages arrive from different domains and at different times. Some come at the peak of the workday, and some come late at night. The latter are opened by the company CEO almost immediately after they arrive to work. Those “test messages” continue to arrive for approximately a week, and then abruptly stop. The CEO thinks the incident is some kind of joke and quickly forgets about it. However, it soon turns out that the company has transferred a few million dollars to the address of an outside company. An investigation reveals that someone claiming to be the CEO had sent several e-mails demanding that the company accountants immediately pay for services rendered by the outside company. This scenario matches one variant of a BEC attack known as a CEO fraud attack, in which cybercriminals pose as top managers of organizations.

Example e-mail used to initiate a CEO fraud attack

In this scenario, cybercriminals found out the work schedule of their targets by using “test messages” containing a tracking pixel that they sent not only to the CEO but also to specific accounting employees. They were then able to request the transfer of a large sum of money supposedly on behalf of the CEO at an ideal time when the CEO was unreachable, but the accounting department was already online.


Despite their seemingly primitive simplicity, e-mail phishing and other malicious attacks still serve as some of the main tools used by cybercriminals to gather corporate data. These attacks usually follow a standard scenario.

Corporate e-mail addresses of employees receive messages that imitate typical notifications coming from business platforms such as SharePoint. These messages urgently ask the employees to follow a link to either read an important document or perform some other important action. If employees actually follow the recommendations of this e-mail, they will end up on a spoofed website containing a fraudulent form for entering their corporate account credentials. If an employee attempts to log in to this fake resource, this login information will end up in the hands of the phishing scammers. If a business platform is accessible not only from within the corporate network but also from outside of it, the cybercriminals could then log in to the resource using the employee’s account and collect the information they need.

Example phishing e-mail. An employee is asked to follow a link to read a fax message

The first wave of an attack launched against an organization may also be a phishing ploy aimed at hijacking the personal accounts of employees. Many users are “friends” with their colleagues on social networks and correspond with them in popular messengers, which may include discussions about work-related issues. By gaining access to an employee’s account, cybercriminals can skillfully coax the employee’s contacts into disclosing corporate information.

Luckily, simple mass e-mail phishing is promptly detected by most security products, and more and more users are becoming aware of these types of attacks. However, cybercriminals are resorting to more advanced types of attacks, such as phishing for data over the phone.

Phone phishing

The main difference between phone phishing and typical phishing attacks is that cybercriminals persuade their victim to give them confidential information over the phone instead of via a phishing web page. They also may use various methods to establish contact with their victim. For example, they can directly call specific employees or call around the entire company — if the database of employee contacts ended up in their hands, or they can distribute e-mail messages requesting that the employees call a specific number. The latter example is more interesting, so we will discuss this method in detail.

Let’s examine a potential scenario for such an attack. A company employee receives a phishing e-mail that is specially stylized as an official message from a large service provider such as Microsoft. The message contains information that requires the victim to make a quick decision. Cybercriminals may also try to intimidate the recipient. The example below states that child pornography was accessed from the victim’s computer. To resolve the issue, the cybercriminals request that the employee contact technical support at a specific number. If the victim actually calls the specific number, the cybercriminals could pose as Microsoft technical support personnel and dupe the victim into revealing their username and password for accessing the company’s internal systems.

Example e-mail message initiating a phone phishing attack

Cybercriminals often pose as technical support personnel or as representatives of the company’s IT department to gain the trust of its employees. This was exactly the technique used for the Twitter hack in the summer of 2020.

By obtaining employee credentials, they were able to target specific employees who had access to our account support tools. They then targeted 130 Twitter accounts – Tweeting from 45, accessing the DM inbox of 36, and downloading the Twitter Data of 7.

— Twitter Support (@TwitterSupport) July 31, 2020

Message from Twitter Support regarding the incident

Twitter employees with access to internal systems of the company received phone calls supposedly from the IT department. During these conversations, cybercriminals employed social engineering techniques to gain access not only to the internal network of the company, but also to tools that enabled them to manage Twitter user accounts. As a result, the pages of many famous people showed fraudulent messages promising their readers that they would receive double any amount that they transferred to a specific bitcoin wallet. More details about this incident can be found in the Twitter company blog.

Examples of scam messages on Twitter

The victims of this incident included the company itself, which incurred reputational losses, and many Twitter users who were duped by the messages from the spoofed posts and actually transferred more than $110,000 in bitcoin. This perfectly illustrates the fact that the initially attacked company is not always the ultimate victim of corporate doxing, but it could be just an unknowing intermediary within a much larger cybercriminal campaign aimed at the company’s customers or partners. Ultimately, the reputation of all involved parties will be damaged.

Doxing of individual employees

Traditional doxing involving the collection of data on specific people could also be used in a larger attack against an organization. As we mentioned earlier, cybercriminals can employ BEC attacks based on specific information acquired from publicly accessible posts on social networks. However, this is not the only potential consequence of doxing, especially for cases of targeted data collection in which the attackers do not limit themselves to publicly available data sources but actually hack the accounts of a victim for the purpose of obtaining access to private content.

Identity theft

One result of doxing aimed at an individual employee may also be theft of their identity. Under a stolen identity, cybercriminals may circulate false information that results in a damaged reputation and sometimes financial losses of a company, especially if this information is attributed to a high-ranking employee whose statements are capable of provoking a serious scandal.

Let’s examine one of the potential attack scenarios involving identity theft. In this scenario, cybercriminals create a fake account for a high-ranking manager of their target company on a social network where the manager has not yet registered, such as Clubhouse. This account participates in discussions with a large number of users, and constantly makes provocative statements that are eventually reported in the media. As a result, company shares may lose value, and potential customers start trending toward the company’s competitors. Interestingly, cases of identity theft have already been observed in Clubhouse (albeit relatively minor cases so far).

Cybercriminals may also pose as a company employee for fraudulent purposes. For example, if a cybercriminal has obtained audio and video content involving the victim, such as from presentations at conferences, broadcasts, or their Instagram stories, the cybercriminal may employ “deepfake” technology. There have already been cases when scammers very convincingly imitated the voice of the CEO of an international company and persuaded the management team of one of their branches to transfer a large sum of money to the scammers.


Corporate doxing poses a serious threat to the confidential data of a company. This article provided examples showing how information that is publicly accessible and generally non-threatening to a company could actually lead to an attack that results in significant financial and reputational losses if such information falls into the hands of professional cybercriminals. The more sensitive the data accessed by cybercriminals, the more damage they are capable of inflicting. They could demand ransom for the confidential information, sell it on the dark web, or use it for subsequent attacks on customers, partners, and company departments responsible for financial transactions.

How to protect yourself

To prevent or minimize the risk of a successful attack on your company, you must first understand that skimping on your security tools is never a good idea. This is especially true in today’s environment, which is continually dealing with new technologies that could be exploited by cybercriminals. To lower the likelihood of confidential data theft:

  • Establish a rigid rule to never discuss work-related issues in external messengers outside of the official corporate messengers, and train your employees to strictly adhere to this rule.
  • Help your employees become more knowledgeable and aware of cybersecurity issues. This is the only way to effectively counteract the social engineering techniques that are aggressively used by cybercriminals. To do so, you could use an online training platform such as Kaspersky Automated Security Awareness Platform.
  • An employee who is well versed in cybersecurity issues will be able to thwart an attack. For instance, if they receive an e-mail from a colleague requesting information, they will know to first call the colleague to confirm that they actually sent the message.
  • Utilize anti-spam and anti-phishing technologies. Kaspersky provides several of these types of solutions, which are included in the following business-oriented products: Kaspersky Security for Microsoft Exchange Servers, Kaspersky Security for Linux Mail Server, Kaspersky Secure Mail Gateway, and the standalone product Kaspersky Security for Microsoft Office 365.
2021. március 25.

Threat landscape for industrial automation systems. Statistics for H2 2020



H1 2020

H2 2020


Global percentage of attacked ICS computers 32.6% 33.42% 38.55%

Percentage of attacked ICS computers by region

Northern Europe 10.1% 11.5% 12.3% Western Europe 15.1% 14.8% 17.6% Australia 16.3% 17.0% 18.9% United States and Canada 17.2% 16.5% 19.6% Eastern Europe 26.4% 28.0% 30.5% Southern Europe 27.6% 29.6% 33.1% Latin America 33.6% 34.3% 38.8% Russia 32.2% 34.6% 39.5% Middle East 34.0% 34.6% 40.2% South Asia 38.8% 41.3% 47.0% East Asia 42.9% 41.8% 46.3% Central Asia 43.7% 43.9% 48.8% Africa 45.6% 46.4% 51.2% Southeast Asia 49.8% 47.5% 53.9%

Main threat sources globally

Internet 16.7% 16.7% 20.5% Removable media 5.8% 5.4% 7.0% Email clients 3.4% 4.1% 4.4% Traits
  1. There is no longer a downward trend in the percentage of ICS computers on which malicious objects were blocked.
    Starting with the second half (H2) of 2019, we observed a decline in the percentages of ICS computers on which malicious objects were blocked. This was observed in industrial control systems (ICS) as well as in corporate and personal computing environments. This downward trend was not observed in the second half of 2020.
    • Globally, the percentage of attacked ICS computers in the second half of the year was 33.4%, which was 0.85 percentage points (p.p.) higher than the first half (H1) of the year.

      !function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

      Percentage of ICS computers on which malicious objects were blocked, by half-year, 2017 – 2020 (download)

    • The percentage of attacked ICS computers increased in 62% of countries.
      In H2 2020, the percentage of ICS computers on which malicious objects were blocked increased in relation to H1 in 62% of countries. In comparison, this trend was observed in 7% of countries in 2019, and the same was seen in H1 2020 compared to H2 2019.

      !function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

      !function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

      Change in the percentage of attacked computers in countries of the world (p.p.) in H2 compared to H1, 2019 vs 2020 (download 1, 2)

      The maximum growth of this indicator in a country was 8.2 p.p. (in Saudi Arabia), while most countries observed no more than a 4 p.p. increase. Therefore, the global average change over the half-year was insignificant.

  2. The seasonal fluctuations typical of past years were not observed this year
    In previous years, the percentage of ICS computers on which malicious objects were blocked was at its maximum in March/April and October, while this indicator sagged between those months.In 2020, this indicator behaved differently. It reached its maximum in February and dropped almost to its minimum in May. In the first two months of summer, it grew to its near-maximum in July. In October, the percentage of attacked ICS computers was one of the lowest.

    !function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

    Percentage of ICS computers on which malicious objects were blocked, by month, 2018 – 2020 (download)

  3. The percentage of ICS computers on which malicious email attachments were blocked increased
    • Globally, in H2 2020, the percentage of ICS computers on which malicious email attachments were blocked increased by 0.7 p.p. compared to H1.

      !function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

      Percentage of ICS computers on which malicious email attachments were blocked (download)

    • This indicator increased in all regions except East Asia, the US and Canada, Western Europe, and Russia.
    • In 73.4% of all countries in H2 2020, the percentage of ICS computers on which malicious email attachments were blocked increased compared to H1 2020.This is three times larger than the equivalent indicator for 2019 (23.6%).

      !function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

      !function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

      Change in the percentage of ICS computers (p.p.) on which malicious email attachments were blocked in H2 compared to H1, countries and territories, 2019 vs 2020 (download 1, 2)

  4. There was a rise in the percentage of ICS computers on which threats distributed over the internet and email, and spyware and miners were blocked
    • Malicious objects from the internet – web resources involved in the distribution or management of malware (+2.5 p.p.), and malicious scripts and redirects on web resources (JS and HTML) (+1.6 p.p.).
    • Typical threats distributed by email (+1.2 p.p.). – malicious MS Office and PDF documents (+1.2 p.p.).
    • Spyware (+1.4 p.p.) – Trojans, backdoors, and keyloggers.
    • Miners (+0.7 p.p.) – executable files for Windows.

    For all these threats, the indicators of H2 2020 exceeded the equivalent results of not only H1 2020 but also H2 2019.

    !function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

    Percentage of ICS computers on which various types of malicious objects were blocked, H2 2019 – H2 2020 (download)

  5. In developed countries, the percentage of ICS computers attacked by ransomware increased
    Globally, the percentage of ICS computers on which ransomware was blocked decreased from 0.63% in H1 to 0.49% in H2.At the same time, this indicator increased in regions with developed countries:
    • +0.25 p.p. in the US and Canada
    • +0.23 p.p. in Australia
    • +0.13 p.p. in Western Europe

    !function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

    Change in the percentage of ICS computers (p.p.) on which ransomware was blocked in H2 2020 compared to H1 (download)

Impact of the COVID-19 pandemic

In our H1 2020 report, we wrote about the impact of the COVID-19 pandemic on the changes that we observed in the attack surface and threat landscape for industrial enterprises and industrial automation systems. In H2 2020, we continued our observations and identified a number of trends that could, in our opinion, be due to circumstances connected with the pandemic in one way or another, as well as the reaction of governments, organizations and people to these circumstances.

Changes in seasonal fluctuations in the percentage of attacked computers

It can be seen in the ‘Percentage of ICS computers on which malicious objects were blocked’ diagram that in the past years the percentage of attacked ICS computers significantly decreased in summer months and in December. It is likely that this decrease was associated with traditional vacation periods: an infected USB drive cannot transfer malware from one computer to another all by itself, nor can an engineering workstation click on a link leading to a phishing website when the engineer is not there.

However, there was a noticeable change in the situation in 2020: we saw no significant seasonal fluctuations in the percentage of attacked computers. It is likely that this was due to changes in employee vacation schedules, since many people decided to go without vacations in the time of lockdown, travel restrictions, and closed borders.

Attacks on RDP remote connection services

Another effect of the pandemic was a noticeable increase in the percentage of ICS computers that could be accessed remotely via the RDP protocol.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Percentage of ICS computers accessible via RDP, by months of 2020 (download)

It can be seen in the diagram above that the percentage grew continuously from January to April – the time when many organizations were dealing with the challenges of organizing work under an impending and actual lockdown. Then, after some fluctuations, the percentage decreased somewhat and stabilized at a slightly higher level than before the pandemic.

We do not have sufficient data to make conclusions as to what proportion of these computers could only be accessed from the industrial network of the enterprise, what part could be accessed from the corporate segment of the network and what percentage was available even outside the organization’s perimeter. However, we can state with confidence that the increase in the availability of ICS computers certainly affected the attack surface. Threat actors clearly took advantage of that – this is obvious from the following diagram, which shows the percentages of ICS computers on which brute force attacks on credentials used to access the RDP service were detected and blocked:

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Percentage of ICS computers on which attempts to brute force RDP passwords were detected, by months of 2020 (download)

It is easy to notice a certain synchronism in the changes occurring in these two parameters: the percentage of attacked RDP connections follows the percentage of UCS computers available via RDP almost all through the year (from January to October) with a delay of approximately one month, catching up (i.e., the changes are synchronized) in October and November.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Percentage of ICS computers on which brute force attacks on RDP passwords were detected and percentage of ICS computers available via RDP (download)

We can only guess whether the one-month ‘delay’ in changes occurring in the percentage of attacked computers had to do with the speed with which attacks propagated on the enterprise network or the speed with which threat actors responded to changes in the opportunity landscape (attack surface).

Changes in ransomware priorities

One more potential consequence of the pandemic can be identified by analyzing the dynamics of ransomware attacks on industrial enterprises in different regions, which can be indirectly assessed based on the percentage of ICS computers attacked by ransomware. It can be seen in the ‘Change in the percentage of ICS computers (p.p.) on which ransomware was blocked’ diagram, as well as the diagram below that this percentage decreased in H2 2020 in all regions of the world except North America, Western Europe and Australia, where it did not just fail to decrease but increased several times over!

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Percentage of ICS computers on which ransomware was blocked, H2 2019 – H2 2020 (download)

We believe that these curious dynamics could indicate the response of threat actors to the economic consequences of the pandemic. In those countries where the ‘creditworthiness’ of organizations decreased as a result of the pandemic, the number of attacks on industrial enterprises also fell (and so did the percentage of attacked ICS computers). At the same time, in countries where industrial organizations were generally more financially stable and were still able to pay ransom, the activity of attackers increased (and the percentage of attacked ICS computers surged). It can be hypothesized that the changes that we observed were due, among other things, to a shift in some groups’ focus when choosing victims towards organizations in more economically stable countries.

The full report is available on Kaspersky ICS CERT.

2021. március 18.

Convuster: macOS adware now in Rust


Traditionally, most malicious objects detected on the macOS platform are adware: besides the already familiar Shlayer family, the TOP 10 includes Bnodlero, Cimpli, Adload and Pirrit adware. As a rule, most tend to be written in C, Objective-C or Swift. Recently, however, cybercriminals have been paying increased attention to new programming languages, seemingly in the hope that such code will be more opaque to virus analysts who have little or no experience with the newer languages. We have already seen quite a few samples written in Go, and recently cybercriminals turned their attention to Rust as well.

The first to write about suspicious files in this programming language was a Twitter user, @gorelics:

Suspicious agent (rust compiler)#macos #malwarehttps://t.co/9PZ6v9u0Yshttps://t.co/uylt2w6TUJ pic.twitter.com/OgZIzlgVmA

— gorelics (@gorelics) August 16, 2020

In the screenshot the tweet shows, one can see that several samples of suspicious code are run by configuration PLIST files through the LaunchAgents/LaunchDaemons mechanism. Alongside the suspicious names of the PLIST files, this is the first wakeup call that the program is dangerous, given the low popularity of Rust-based executables.

We examined these samples for malicious behavior. The analysis showed these executables to be a new adware program, that has subsequently been called Convuster.

Technical details Sample in Rust

It can be deduced that the analyzed sample was written in Rust from the frequent use of the language’s standard library, as well as several code lines containing paths to files with the .rs extension, which is the standard Rust source file extension.

Rust artifacts in the sample

At startup, the executable checks the configuration PLIST files ~/Library/LaunchAgents/com.ist.up.plist and /Library/LaunchDaemons/com.ist.up.plist for keys needed to run the sample, such as RunAtLoad, StartInterval and Version. We were not able to retrieve these files, but presumably they are used to run the sample under investigation when the user logs in to the system.

After these checks, the program obtains the device ID, as well as the system version and bitness, and forwards the gathered data to the following server: hxxps://post.convstats[.]com/hb/. In response, Convuster receives a JSON file and sends a request to the host specified in this file. The response to this request is a Bash script that gets executed by the Bash shell and then removed from the system.

Request generation

At the time of analysis, the server was not responding to requests. However, after examining information about the suspicious convstats[.]com domain, we detected the update.convstats[.]com and trk.convstats[.]com subdomains (in addition to the already known post.convstats[.]com).

Sample in Swift

In the update.convstats[.]com subdomain, at the address hxxps://update.convstats[.]com/Player.dmg, we found a DMG disk image containing another Convuster executable, this time in the Swift programming language.

The payload of the executable was encrypted:

XOR encryption

Having decrypted the data, Convuster runs the code obtained, first of all checking that the DMG image was downloaded specifically from the address hxxps://update.convstats[.]com/Player.dmg with either the ?_=1390081 or &_=1390081 parameter. It does so by accessing the quarantine database of the macOS Gatekeeper security feature using the following query:

select LSQuarantineAgentBundleIdentifier, LSQuarantineDataURLString from LSQuarantineEvent order by LSQuarantineTimeStamp desc limit 3

Typical Gatekeeper database content

Usually, this macOS database serves as a log for all files downloaded from untrusted sources. However, Convuster’s creators use it to protect their handiwork from being analyzed. If it was not downloaded from an “official” server, but rather got into the system some other way, it may mean that the program is in a test or virtual environment, that is, under investigation by virus analysts.

If the file source check is successful, the user is shown a window prompting to install Flash Player. Otherwise, the program prompts to continue the installation later, and then exits.

The installer mimics a Flash Player update

Regardless of whether the user agrees to the installation or attempts to close the window, Convuster sends a request to hxxps://post.convstats[.]com/dis/ to download the installation script, and then runs it in the Bash shell.

Running the script in the Bash shell


Convuster is run through LaunchAgents, but the program does not try to add itself to startup independently. This means that the file in question was most likely neither downloaded nor installed directly by the user. In our view, Convuster could have been installed by some other adware.

At the time of the study, we were aware of the following domain names performing redirects to the update.convstats[.]com subdomain:

  • storeoverlyadvancedapplication[.]best
  • streamgreatlyadvancedprogram[.]best
  • streamstrongcompletelyprogram[.]best
  • syncextremelysophisticatedsoftware[.]icu
  • streamquickcompletelyprogram[.]best
  • getnewestextremelyapp[.]best
  • launchfreeextremelyfreeware[.]best
  • loadsophisticated-thecompletelyfile[.]best

Besides, forum users complain about other domains prompting to install a fake Flash Player update:

User complaints about advertising redirects


Based on the behavior of the Convuster samples in Rust and Swift, we classify this program as adware. Despite their supposed exoticism, these languages lack nothing in terms of functionality from an adware developer’s point of view: Rust, for instance, has the tools not only for authoring adware, but for carrying out more sophisticated attacks.

Besides the choice of programming language, it is noteworthy that cybercriminals have learned to use built-in macOS tools and technologies, such as Gatekeeper, for their own purposes (for example, to verify the source of a file). Although this family is no longer active, it is a clear illustration of how attackers are constantly honing their threats to evade analysis and deliver adware to as many devices as possible.

Kaspersky security solutions detect this adware with the following verdict: not-a-virus:HEUR:AdWare.OSX.Convuster.a.

IoCs SHA-256

Swift samples

Mach-O executables:

Disk Images:


Rust samples

Mach-O executables:



2021. március 15.

COVID-19: Examining the threat landscape a year later

A year ago — everything changed. In an effort to stem the tide of a rapidly spreading pandemic, the world shut down. Shops were forced to shut their doors, and whole countries were placed on stringent lockdowns. Schools were closed around the world, with more than one billion children affected, and the vast majority of companies had to switch to remote work, sometimes with only a week’s notice. As life for large swaths of the population moved entirely online, the cybercriminals were ready.

In fact, not only did the way people lived and worked changed, but so did the methods and tactics used by criminals on the Internet looking to exploit the massive increase in online traffic.

With the approval of several vaccines against the coronavirus, a post-pandemic future is finally in sight. However, there is still a long way to go before life returns to normal, and some changes, such as remote work, look like they are here to stay — as do the new cyber threats that emerged alongside these shifts.

On the anniversary of the global shutdown, Kaspersky experts decided to take a look back at how the threat landscape has evolved since the beginning of the pandemic — and what that means for users in the years to come.

From targeted attacks to exploiting all things COVID-related, the biggest trends in spam and phishing

Phishing is still one of the most effective types of attacks because it exploits users’ emotions, particularly their fear and anxiety. With both of the former heightened thanks to the pandemic, phishing attacks proved to be a highly lucrative attack vector for cybercriminals.

In 2020, criminals launched a variety of scams that exploited the pandemic topic from just about every angle, from advertisements to masks when they were in short supply to special refunds from the government.

A fake landing page for a mask advertised in a phishing email. Users are prompted to put in their payment details for a mask that will most likely never arrive

Scammers often imitated leading authority figures on the pandemic, like the CDC and the World Health Organization, to give their emails additional authority — and increase the chances that users would click a malicious link. Once clicked, users could end up inadvertently downloading a range of threats on their computer, from various Trojans (malicious files that allow cybercriminals to do everything, from deleting and blocking data to interrupting the performance of the computer) and worms (files that are capable of destroying, blocking, modifying or copying data). Of course, in other instances, such as those involving advertisements for masks, the primary goal is stealing money and/or payment information.

An email supposedly from the CDC claiming that there is an urgent update regarding the pandemic

Surprisingly, one of the most common themes exploited revolved around delivery disruptions. A standard part of business operations is making various business orders, and criminals used the uncertainty surrounding mail services during the pandemic to trick users into downloading malware. They would send emails claiming that, due to COVID, an important delivery had been delayed and that the target must verify the new delivery information (a situation easy to believe in the middle of a pandemic) in order to receive it. However, upon clicking the attachment, the users would download Trojans ranging from spyware to backdoors.

A phishing email claiming that a delivery has been delayed and containing a malicious attachment

In fact, in 2020, delivery services became one of the top ten organization types targeted by phishers.

Remote work — and the rise of brute-force attacks

With many companies forced to close their doors with little notice, few had time to put the proper security measures in place. The result was that many became vulnerable to a host of new attacks as their employees began logging in to corporate resources from personal devices and on unsecured networks. Chief among them? Brute-force attacks against the RDP protocol, Microsoft’s proprietary protocol that enables users to access Windows workstations or servers. RDP is one of the most popular remote access protocols used by companies, making it a favorite target for attackers. In a brute-force attack, attackers attempt to randomly guess a username and password for the RDP connection by trying different combinations until they guess the correct one — and gain access to the confidential corporate resources.

In spring of 2020, the number of brute-force attacks against the RDP protocol skyrocketed across almost the entire planet.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

The number of brute-force attacks against the RDP protocol (download)

As shown in the graph, as soon as lockdowns were announced, the number of brute-force RDP attacks radically increased — from 93.1 mln worldwide in February  to 277.4 mln in March — a 197 percent increase. While the number of attacks has ebbed and flowed as the pandemic continued, the number of attacks has not returned to pre-pandemic levels. In fact, after new lockdowns were announced in the winter, RDP attacks once again displayed an upward trend. In February 2021, there were 377.5 mln brute-force attacks — a far cry from the 93.1 mln witnessed at the beginning of 2020.

Virtual communication platforms under attack

With the world on lockdown, Internet demand reached unprecedented levels. Large companies from Facebook to Netflix to YouTube, were forced to reduce their video quality in order to keep up with demand. And all those extra users meant a host of new targets for criminals. By the May of 2020, the average daily number of attacks blocked by Kaspersky Web Anti-Virus had increased by 25%. In fact, the number of web attacks, after displaying a decline in the summer of 2020, reached a new peak in the December as much of the world was facing a second wave of the pandemic.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Number of web-based attacked blocked by Kaspersky Web Anti-Virus from March 2020 through February 2021 (download)

A large portion of users’ time spent online was dedicated to meeting and collaborating virtually. That is why meeting and messenger apps, like Zoom and Teams, became a popular lure for distributing cyberthreats.

Upon examining popular meeting and videoconferencing apps, including Zoom, Webex, and MS Teams, Kaspersky researchers noticed a growing number of malicious files spread under the guise of these apps’ names.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

The number of malicious files spread under the guise of popular meeting apps (Webex, Zoom, MS Teams, HighFive, Lifesize, Join.me, Slack, Flock, Gotomeeting) (download)

In the January of this year, there were 1.15 mln such files detected — the highest number since the lockdown began. These files are often bundled as part of seemingly legitimate application installers, which can be encountered in several ways: through phishing emails claiming to have notifications or special offers from their platforms or through phishing web pages.

Lessons learned

Peoples’ lives have become increasingly digital for years, and this is a trend that is likely to continue. It is still unclear when travel will get back to normal and with remote work staying in the picture, videoconferencing and meeting apps will continue to be in high demand. Of course, the more time users spend online, the more vulnerable they are to security risks.

While the pandemic may be heading into its final phases, there are still new topics for phishers and scammers to exploit, like health passports for travel or vaccine distribution, and chances are they will exploit them. It is important that users view any email or website referencing the pandemic with a skeptical eye. What is more, recent events have shown how willing criminals are to take advantage of crisis, and, while this pandemic will subside, it certainly will not be the last crisis.

With many organizations already stating that they will continue to make remote work an option and/or adopt a hybrid model, RDP is not going anywhere — and neither are attacks against the protocol. That means businesses need to reevaluate their usage of RDP and learn how to secure remote access.

If there is has ever been a time for companies to reevaluate and bolster their security strategy, that time is now.

2021. március 12.

Good old malware for the new Apple Silicon platform


A short while ago, Apple released Mac computers with the new chip called Apple M1. The unexpected release was a milestone in the Apple hardware industry. However, as technology evolves, we also observe a growing interest in the newly released platform from malware adversaries. This inevitably leads us to new malware samples compiled for the Apple Silicon platform. In this article, we are going to take a look at threats for Macs with the Apple M1 chip on board. Also, we prepared a short F.A.Q. section at the end of the article for those who want to understand better the security risks of M1 malware. Let’s dive in.

XCSSET malware

Last year, a threat called XCSSET was discovered for the first time. It targets mainly Mac developers using a unique way of distribution: injecting a malicious payload into Xcode IDE projects on the victim’s Mac. This payload will be executed at the time of building project files in Xcode. XCSSET modules have numerous capabilities, such as:

  • Reading and dumping Safari cookies,
  • Injecting malicious JavaScript code into various websites,
  • Stealing user files and information from applications, such as Notes, WeChat, Skype, Telegram, etc.,
  • Encrypting user files.

All these various features, in combination with high stealth and an unusual way of distribution, make XCSSET a dangerous threat for Mac computers.

While exploring the various executable modules of XCSSET, we found out that some of them also contained samples compiled specially for new Apple Silicon chips. For example, a sample with the MD5 hash sum 914e49921c19fffd7443deee6ee161a4 contains two architectures: x86_64 and ARM64.

The first one corresponds to previous-generation, Intel-based Mac computers, but the second one is compiled for ARM64 architecture, which means that it can run on computers with the new Apple M1 chip. According to VirusTotal, this sample was first uploaded on 2021-02-24 21:06:05 and the original research report did not contain this hash or a module named “metald”, the name of the executable file. With this information on hand, we can assume that the XCSSET campaign is probably still ongoing. This leads us to the thought that more and more malware writers are actively recompiling their samples to have an opportunity to run on new Apple Silicon Macs natively.

Silver Sparrow threat

XCSSET is not the only family which has adapted to run natively on Apple Silicon. According to a RedCanary report, a new threat called Silver Sparrow has been identified. This threat introduces a new way for malware writers to abuse the default packaging functionality: instead of placing a malicious payload in preinstall or postinstall scripts, malware writers hid one in the Distribution XML file.

This payload uses JavaScript API to run bash commands in order to download a JSON configuration file.

Downloading of JSON config

And after successfully downloading that configuration file, the sample extracts a URL from the downloadURL field for the next download.

Downloading and executing a payload

Also, an appropriate Launch Agent is created for persistent execution of the malicious sample.

Malware persistence

This JavaScript payload can be executed regardless of chip architecture, but in the package file with the MD5 hash sum fdd6fb2b1dfe07b0e57d4cbfef9c8149, there is a “fat” Mach-O containing two supported architectures (ARM64 and x86_64), as compared to the old package with the MD5 hash sum 30c9bc7d40454e501c358f77449071aa. This means that the malware actors are trying to expand their attack coverage by supporting a wider range of platforms.

Adware threats for the new platform

However, there are not just malware samples that can be launched on Apple Silicon. A known Mac malware researcher Patrick Wardle recently published a post covering Pirrit adware. Though it is an old and well-known adware family, it is still actively updated by their authors and new samples are encountered in the wild quite often.

These updates include:

  • Anti-debug techniques such as using ptrace syscall with a PT_DENY_ATTACH flag,
  • Control flow obfuscation techniques,
  • Dynamic imports with dlsym calls to avoid static analysis,
  • Virtual machine detection anti-analysis.

Control flow obfuscation; dynamic symbols resolving with dlsym

Besides these improvements in regular Intel x86_64 samples, new ARM64 samples were introduced. These are crafted specifically for the Apple Silicon M1 chip, but the consequences of running these are roughly the same: launching Pirrit adware results in pop-ups, banners and various annoying advertisements displayed on the victim’s Mac.

Pirrit is not the only adware family to have begun supporting the Apple Silicon platform recently. For example, we also observed an ARM64 Bnodlero adware sample (MD5 82e02c1ca8dfb4c60ee98dc877ce77c5), which runs a bash downloader script using the system() function.

Bash downloader executed by Bnodlero sample

Frequently Asked Questions

What is so special about M1 threats?

Well, there is not much special about them, frankly speaking. The only thing that distinguishes the new Apple M1 threats from previous ones targeting Intel-based Mac computers is the architecture of the Mac processor for which the executable is compiled. In order to get their applications to run on Apple Silicon, software developers should recompile their code into executables which can run on the M1 chip. The same is true for malware adversaries.

Is Apple M1 chip less secure than Intel ones?

No, it is just a matter of platform support in malware executables.

Are Intel-based Macs affected by M1 threats?

Yes and no. On the one hand, code that is compiled exclusively for the Apple Silicon platform cannot be natively executed on the Intel x86_64 architecture. On the other hand, malicious samples are often delivered in so-called “fat” Mach-O, which usually contains the same code but is compiled for several architectures. This means that running this “fat” executable will result in launching the right malicious code depending on your platform architecture. Pirrit and Bnodlero samples are great examples of this approach.

Can threats for Intel-based Macs run on Apple M1?

Yes, they can. Due to the Rosetta 2 feature, newly released Mac computers with Apple M1 can also run malicious code written exclusively for Intel x86_64 architecture. This backward compatibility will certainly be abused by malware operators until Apple completes the transition to their proprietary chips.

Is there an upward trend in M1 malware?

Yes, there certainly is, and it is absolutely to be expected. As soon as a platform becomes more popular or highly anticipated, developers try to ensure that their software is available for it. Malware developers are no exception.


With the new M1 chip, Apple has certainly pushed its performance and energy saving limits on Mac computers, but malware developers kept an eye on those innovations and quickly adapted their executables to Apple Silicon by porting the code to the ARM64 architecture.

We have observed various attempts to port executables not just among typical adware such as Pirrit or Bnodlero samples, but also among malicious packages, such as the Silver Sparrow threat and XCSSET downloadable malicious modules. This certainly will give a kickstart to other malware adversaries to begin adapting their code for running on Apple M1 chips.

2021. március 10.

Ad blocker with miner included

Some time ago, we discovered a number of fake apps delivering a Monero cryptocurrency miner to user computers. They are distributed through malicious websites that may turn up in the victim’s search results. By the look of it, it appears to be a continuation of the summer campaign covered by our colleagues from Avast. Back then, cybercriminals distributed malware under the guise of the Malwarebytes antivirus installer.

In the latest campaign, we have seen several apps impersonated by the malware: the ad blockers AdShield and Netshield, as well as the OpenDNS service. This article analyzes only fake AdShield app, but all the other cases follow the same scenario.

Technical details

Distributed under the name adshield[.]pro, the malware impersonates the Windows version of the AdShield mobile ad blocker. After the user starts the program, it changes the DNS settings on the device so that all domains are resolved through the attackers’ servers, which, in turn, prevent users from accessing certain antivirus sites, such as Malwarebytes.com.

After substituting the DNS servers, the malware starts updating itself by running update.exe with the argument self-upgrade (“C:\Program Files (x86)\AdShield\updater.exe” -self-upgrade). Updater.exe contacts C&C and sends data about the infected machine and information about the start of the installation. Some of the lines in the executable file, including the line with the C&C server address, are encrypted to make static detection more difficult.

Updater.exe code snippet containing the encrypted address

Updater.exe downloads from the site transmissionbt[.]org and runs a modified version of the Transmission torrent client (the original distribution can be found at transmissionbt.com). The modified program sends installation information together with the ID of the infected machine to C&C, and downloads a mining module from it.

Notifying C&C about the successful installation

The mining module is made up of legitimate auxiliary libraries, an encrypted miner file named data.pak, the executable file flock.exe and the “license” file lic.data. The latter contains a SHA-256 hexadecimal hash of some parameters of the machine for which the module is intended and the data from the data.pak file. The modified Transmission client runs flock.exe, which first of all calculates the hash of the parameters of the infected computer and the data from the data.pak file, and then compares it with the hash from the lic.data file. This is necessary because C&C generates a unique set of files for each machine so as to hinder static detection and prevent the miner from running and being analyzed in various virtual environments.

If the hashes do not match, the execution stops. Otherwise, flock.exe decrypts the data from the data.pak file using the AES-128-CTR algorithm, whereby the decryption key and initialization vector are assembled from several parts stored in the sample code. The decryption results in a Qt binary resource file that contains two executable files: the open-source XMRig miner (the same one used in the summer attack) and the bxsdk64.dll library.

Decrypted data.pak file

The bxsdk64.dll file is part of the BoxedApp SDK for creating a virtual environment, but in this case it is used to run the miner under the guise of the legitimate app find.exe. The point is that to implement its functionality, bxsdk intercepts calls to system functions and can manipulate their execution. In this case, the BoxedAppSDK_CreateVirtualFileA function creates the find.exe file (which is a copy of the C:\Windows\System32\find.exe file) in the C:\ProgramData\Flock directory. All further manipulations with find.exe occur in RAM and do not affect the file on the disk. When the find.exe process starts, bxsdk intercepts the event and runs the file from the C:\ProgramData\Flock directory; then, using the WriteProcessMemory and CreateRemoteThread functions, it injects the decrypted miner body into the process memory.

To ensure the continuous operation of the miner, a servicecheck_XX task is created in Windows Task Scheduler, where XX are random numbers. The task runs flock.exe with the argument minimize.


According to data from Kaspersky Security Network, at the time of preparing this article, since the beginning of February 2021, there have been attempts to install fake apps on the devices of more than 7 thousand users. At the peak of the current campaign, more than 2,500 unique users per day were attacked, with most of the victims located in Russia and CIS countries.

!function(e,i,n,s){var t="InfogramEmbeds",d=e.getElementsByTagName("script")[0];if(window[t]&&window[t].initialized)window[t].process&&window[t].process();else if(!e.getElementById(n)){var o=e.createElement("script");o.async=1,o.id=n,o.src="https://e.infogram.com/js/dist/embed-loader-min.js",d.parentNode.insertBefore(o,d)}}(document,0,"infogram-async");

Number of users attacked, August 2020 – February 2021 (download)

Kaspersky’s security solutions detect the above-described threats with the following verdicts:

  • Win64.Patched.netyyk
  • Win32.DNSChanger.aaox
  • Win64.Miner.gen
  • HEUR:Trojan.Multi.Miner.gen
How to remove the miner

If the QtWinExtras.dll file is detected on your device, reinstall Malwarebytes. If Malwarebytes is not in the list of apps, you need to delete all the following folders that are on the disk:

  • %program files%\malwarebytes
  • program files (x86)\malwarebytes
  • %windir%\.old\program files\malwarebytes
  • %windir%\.old\program files (x86)\malwarebytes

If flock.exe is detected on your device:

  • Uninstall NetshieldKit, AdShield, uninstall or reinstall OpenDNS (whichever is installed on your device).
  • Reinstall the Transmission torrent client or uninstall it if you don’t need it.
  • Delete the folders (if present on the disk)
    • C:\ProgramData\Flock
    • %allusersprofile%\start menu\programs\startup\flock
    • %allusersprofile%\start menu\programs\startup\flock2
  • Delete the servicecheck_XX task (where XX are random numbers) in Windows Task Scheduler.






5aa0cda743e5fbd1d0315b686e5e6024 (AdShield installer)
81BC965E07A0D6C9E3EB0124CDF97AA2 (updater.exe)
ac9e74ef5ccab1d5c2bdd9c74bb798cc (modified Transmission installer)
9E989EF2A8D4BC5BA1421143AAD59A47 (NetShield installer)
2156F6E4DF941600FE3F44D07109354E (OpenDNS installer)

2021. március 4.

Zero-day vulnerabilities in Microsoft Exchange Server

What happened?

On March 2, 2021 several companies released reports about in-the-wild exploitation of zero-day vulnerabilities inside Microsoft Exchange Server. The following vulnerabilities allow an attacker to compromise a vulnerable Microsoft Exchange Server. As a result, an attacker will gain access to all registered email accounts, or be able to execute arbitrary code (remote code execution or RCE) within the Exchange Server context. In the latter case, the attacker will also be able to achieve persistence on the infected server.

A total of four vulnerabilities were uncovered:

  1. CVE-2021-26855. Server-side request forgery (SSRF) allows an attacker without authorization to query the server with a specially constructed request that will cause remote code execution. The exploited server will then forward the query to another destination.
  2. CVE-2021-26857 caused by unsafe data deserialization inside the Unified Messaging service. Potentially allows an attacker to execute arbitrary code (RCE). As a result of insufficient control over user files, an attacker is able to forge a body of data query, and trick the high-privilege service into executing the code.
  3. CVE-2021-26858. This vulnerability allows an authorized Exchange user to overwrite any existing file inside the system with their own data. To do so, the attacker has to compromise administrative credentials or exploit another vulnerability such as SSRF CVE-2021-26855.
  4. CVE-2021-27065 is similar to CVE-2021-26858 and allows an authorized attacker to overwrite any system file on the Exchange server.

Kaspersky Threat Intelligence shows that these vulnerabilities are already used by cybercriminals around the world.

Geography of attacks with mentioned MS Exchange vulnerabilities (based on KSN statistics)

We predict with a high degree of confidence that this is just the beginning, and we anticipate numerous exploitation attempts with the purpose of gaining access to resources inside corporate perimeters. Furthermore, we should note that there is typically a high risk of ransomware infection and/or data theft connected to such attacks.

How to protect against this threat?

Our products protect against this threat with Behavior Detection and Exploit Prevention components and detect exploitation with the following verdict: PDM:Exploit.Win32.Generic
We detect the relevant exploits with the following detection names:

  • Exploit.Win32.CVE-2021-26857.gen
  • HEUR:Exploit.Win32.CVE-2021-26857.a

We also detect and block the payloads (backdoors) being used in the exploitation of these vulnerabilities, according to our Threat Intelligence. Possible detection names are (but not limited to):

  • HEUR:Trojan.ASP.Webshell.gen
  • HEUR:Backdoor.ASP.WebShell.gen
  • UDS:DangerousObject.Multi.Generic

We are actively monitoring the situation and additional detection logic will be released with updatable databases when required.
Our Managed Detection and Response service is also able to identify and stop this attack by using threat hunting rules to spot the exploitation itself, as well as possible payload activity.

And the thorough research of the attack will soon be available within APT Intelligence Reporting service, please contact intelreports@kaspersky.com for details.

  • As Microsoft has already released an update to fix all these vulnerabilities, we strongly recommend updating Exchange Server as soon as possible.
  • Focus your defense strategy on detecting lateral movements and data exfiltration to the internet. Pay special attention to outgoing traffic to detect cybercriminal connections. Back up data regularly. Make sure you can quickly access it in an emergency.
  • Use solutions like Kaspersky Endpoint Detection and Response and the Kaspersky Managed Detection and Response service which help to identify and stop the attack in the early stages, before the attackers achieve their goals.
  • Use a reliable endpoint security solution such as Kaspersky Endpoint Security for Business that is powered by exploit prevention, behavior detection and a remediation engine that is able to roll back malicious actions. KESB also has self-defense mechanisms that can prevent its removal by cybercriminals.