Kaspersky

Subscribe to Kaspersky hírcsatorna Kaspersky
Frissítve: 2 óra 59 perc
2022. június 23.

The hateful eight: Kaspersky’s guide to modern ransomware groups’ TTPs

These days ransomware analysis gets a lot of coverage in commercial and public reports, with vendors issuing dozens of ransomware-related publications each year. These reports provide analysis on specific malware families or new samples, describe the activities of a particular ransomware group, give general tips on how to prevent ransomware from working, and so on. Malware analysts and security professionals can learn a lot from these reports, but not much of the content has an immediate or practical use. With the release of the report Common TTPs of modern ransomware, Kaspersky experts have taken a different approach. We want to familiarize the reader with the different stages of ransomware deployment, how cybercriminals use RATs and other tools across the various stages and what they aim to achieve. The report also provides a visual guide to defending against targeted ransomware attacks, using the most prolific groups as examples, and introduces the reader to the SIGMA detection rules that we created.

What are the ransomware groups?

For the report we selected the eight most common ransomware groups:

  1. Conti/Ryuk
  2. Pysa
  3. Clop (TA505)
  4. Hive
  5. Lockbit2.0
  6. RagnarLocker
  7. BlackByte
  8. BlackCat

We analyzed in detail the attacks these groups perpetrated and employed techniques and tactics described in MITRE ATT&CK to identify a large number of shared TTPs. By tracking all the groups and detecting their attacks, we saw that the core techniques remain the same throughout the cyber kill chain. The attack patterns revealed are not accidental because this class of attack requires the hackers to go through certain stages, such as penetrating the corporate network or victim’s computer, delivering malware, further discovery, account hijacking, deleting shadow copies, removing backups and, finally, achieving their objectives.

To highlight the common components and TTPs shared by the ransomware groups across different attack patterns, we’ve created a common cyber kill chain diagram. It provides a visual representation of the techniques and tactics used by different ransomware operators.

Once the incident data relating to the ransomware groups has been collected, we can identify the TTPs characteristic of each of them and then superimpose these onto the shared cyber kill chain. The arrows indicate the sequence of specific techniques and the colours mark the individual groups that have been known to deploy these techniques.

Whom is the report for?

This report is written for SOC analysts, threat hunting teams, cyberthreat intelligence analysts, digital forensics specialists and cybersecurity specialists that are involved in the incident response process and/or want to protect the environment they are responsible for from targeted ransomware attacks. Our main goal is to help with understanding how ransomware groups generally operate and how to defend against their attacks.

You can use this report as a book of knowledge on the main techniques used by ransomware groups, for writing hunting rules and for auditing your security solutions.

The report contains
  • Tactics, techniques and procedures (TTPs) of eight modern ransomware groups: Conti/Ryuk, Pysa, Clop (TA505), Hive, Lockbit2.0, RagnarLocker, BlackByte, and BlackCat
  • A description of how different groups share more than half of the common components and TTPs, with the core attack stages being executed identically across groups
  • A cyber kill chain diagram that combines the visible intersections and common elements of the selected ransomware groups and makes it possible to predict the threat actors’ next steps
  • A detailed analysis of each technique with examples of how they are being used by various groups and a comprehensive list of mitigations
  • SIGMA rules based on described TTPs that can be applied to SIEM solutions

 Common TTPs of modern ransomware (PDF)

2022. június 21.

APT ToddyCat

ToddyCat is a relatively new APT actor that we have not been able to relate to other known actors, responsible for multiple sets of attacks detected since December 2020 against high-profile entities in Europe and Asia. We still have little information about this actor, but we know that its main distinctive signs are two formerly unknown tools that we call ‘Samurai backdoor’ and ‘Ninja Trojan’.

The group started its activities in December 2020, compromising selected Exchange servers in Taiwan and Vietnam using an unknown exploit that led to the creation of a well-known China Chopper web shell, which was in turn used to initiate a multi-stage infection chain. In that chain we observed a number of components that include custom loaders used to stage the final execution of the passive backdoor Samurai.

During the first period, between December 2020 and February 2021, the group targeted a very limited number of servers in Taiwan and Vietnam, related to three organizations.

From February 26 until early March, we observed a quick escalation and the attacker abusing the ProxyLogon vulnerability to compromise multiple organizations across Europe and Asia.

We suspect that this group started exploiting the Microsoft Exchange vulnerability in December 2020, but unfortunately, we don’t have sufficient information to confirm the hypothesis. In any case, it’s worth noting that all the targeted machines infected between December and February were Microsoft Windows Exchange servers; the attackers compromised the servers with an unknown exploit, with the rest of the attack chain the same as that used in March.

Other vendors observed the attacks launched in March. Our colleagues at ESET dubbed the cluster of activities ‘Websiic’, while the Vietnamese company GTSC released a report about the infection vector and the technique used to deploy the first dropper. That said, as far as we know, none of the public accounts described sightings of the full infection chain or later stages of the malware deployed as part of this group’s operation.

The first wave of attacks exclusively targeted Microsoft Exchange Servers, which were compromised with Samurai, a sophisticated passive backdoor that usually works on ports 80 and 443. The malware allows arbitrary C# code execution and is used with multiple modules that allow the attacker to administrate the remote system and move laterally inside the targeted network.

In some specific cases, the Samurai backdoor was also used to launch another sophisticated malicious program that we dubbed Ninja. This tool is probably a component of an unknown post-exploitation toolkit exclusively used by ToddyCat.

Based on the code logic, it appears that Ninja is a collaborative tool allowing multiple operators to work on the same machine simultaneously. It provides a large set of commands, which allow the attackers to control remote systems, avoid detection and penetrate deep inside a targeted network. Some capabilities are similar to those provided in other notorious post-exploitation toolkits. For example, Ninja has a feature like Cobalt Strike pivot listeners, which can limit the number of direct connections from the targeted network to the remote C2 and control systems without internet access. It also provides the ability to control the HTTP indicators and camouflage malicious traffic in HTTP requests that appear legitimate by modifying HTTP header and URL paths. This feature provides functionality that reminds us of the Cobalt Strike Malleable C2 profile.

Since it first appeared in December 2020, ToddyCat has continued its intense activity, especially in Asia where we detect many other variants of loaders and installers similar to those abused to load Samurai and Ninja malware. We also observed other waves of attacks against desktop machines that were infected by sending the malicious loaders via Telegram.

First Campaign Infection vector

Based on our telemetry, ToddyCat started to compromise servers on December 22, 2020, using an unknown exploit against the Microsoft Exchange component. The exploit was used to deploy the China Chopper web shell, which was used in turn to download and execute another dropper, debug.exe.

Starting from February 26, we observed the same infection chain and samples observed in December and January, deployed using ProxyLogon.

Stage 1 – Dropper

The dropper installs all the other components and creates multiple registry keys to force the legitimate svchost.exe process to load the final Samurai backdoor.


Infection workflow

The program debug.exe makes use of a special resolution function that is used every time it calls a Windows API. The code checks if the pointer is already resolved and placed into a global variable. If the value was not found, it goes on to retrieve the address using the resolution function, which receives a handle to the library that contains the API and an encrypted string of the requested API name, following which it decrypts the string using an XOR-based algorithm.


Code snippet used to resolve and call CryptDestroyKey and CryptReleaseKey functions

The dropper was configured to load an encrypted payload stored in another file, debug.xml. The data are decrypted using the standard Wincrypt functions with the CALG_3DES_112 algorithm and a static key embedded in the code. Once decrypted, the file shows a structure that contains multiple payloads and values used to install the next stages.

Field Value magic 0x12345678 DotNet_Loader_v2_Payload websvc.dll payload compatible with .Net Framework v2.0 DotNet_Loader_v4_Payload websvc.dll payload compatible with .Net Framework v4.0 Loader_Dll_Payload iiswmi.dll dll loader ServiceName WebUpdate Path_DotNet_Loader %COMMONPROGRAMFILES%\System\websvc.dll Path_Loader_Dll %COMMONPROGRAMFILES%\microsoft shared\WMI\iiswmi.dll RegKey_Path_Service_SvcHost SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost RegKey_Path_Interface SOFTWARE\Classes\Interface\{6FD0637B-85C6-D3A9-CCE9-65A3F73ADED9} Reg_Interface_Payload_v4 Samurai backdoor for .Net Framework v4.0 Reg_Interface_Payload_v2 Samurai backdoor for .Net Framework v2.0

Once the values are retrieved from the file, the malware conducts a sequence of actions in order to stage the next component in the infection chain:

  1. Attempts to create the directory %COMMONPROGRAMFILES%\Microsoft Shared\wmi\ that will contain the DLL used for the next stage.
  2. Checks if a service corresponding to the subsequent stage already exists, and if so attempts to stop it.
  3. Checks if the .NET framework of version 2.0 is installed by attempting to open the registry key SOFTWARE\Microsoft\.NETFramework\policy\v2.0
  4. If the key exists, the malware drops the element we refer to as DotNet_Loader_v2_Payload to %COMMONPROGRAMFILES%\System\websvc.dll; otherwise, it drops the contents of DotNet_Loader_v4_Payload in the same path.
  5. Drops a DLL loader used to start the second stage under the path %COMMONPROGRAMFILES%\microsoft shared\WMI\iiswmi.dll
  6. Once the aforementioned files are available on the system, the malware tries to create the registry key specified below to maintain persistence on the system. The value in that key indicates the name of the service that is created to execute the binary. Following the example below, once executed the service-related process is associated with the command line %SystemRoot%\System32\svchost.exe -k httpsvc.
    Registry Key: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost Value name: httpsvc Value: WebUpdate
  7. After the service is created, the malware attempts to configure the second stage DLL and entry point within it to be executed when the service is started. This is done by setting the corresponding registry keys with the following values:
    Registry Key: $HKLM\System\ControlSet\Services\WebUpdate\Parameters Value name: ServiceDll Value: %ProgramFiles%\Common Files\microsoft shared\WMI\iiswmi.dll Registry Key: $HKLM\System\ControlSet\Services\WebUpdate\Parameters Value name: ServiceMain Value: INIT
  8. The malware drops the final payload in the infection chain as a compressed, encrypted and base64 encoded blob under the following registry key:
    Registry Key: $HKLM\SOFTWARE\Classes\Interface\{6FD0637B-85C6-D3A9-CCE9-65A3F73ADED9} Value name: Value: ILQ3Pz8/Pz87P9IFVEskWKpIeTB0jZx5SVXYXhh1fG...%encoded data%
Stage 2 – DLL Loader

The registry keys created during the previous step forced the svchost.exe process to load a malicious library developed in C++, iiswmi.dll. The code used inside the library is quite similar to the dropper and it calls the Windows API using the same special resolution function observed in the dropper.

This component is merely a loader that attempts to get an encrypted payload from the registry and pass it as an argument to another DLL manually loaded during runtime.

The malware attempts to read the contents of the previously written registry key SOFTWARE\Classes\Interface\{6FD0637B-85C6-D3A9-CCE9-65A3F73ADED9}, and if it succeeds, loads the previously dropped DLL in the path %COMMONPROGRAMFILES%\System\websvc.dll.

To invoke the next stage, the malware calls the Init export in the loaded DLL (websvc.dll) while passing the contents of the former registry key as an argument.


Code snippet used to load and execute websvc.dll

Stage 3 – .NET Loader

The websvc.dll library was developed in C# and it is another loader that expects an encrypted payload as input argument. That input is comprised of two base64-encoded strings separated by the pipe character (“|”). The first string contains the final stage and the second an encrypted configuration that is used during the execution of the next stage.

The library decodes the first string and the resulting data are decrypted with a simple single XOR with the key 0x3F and decompressed using Gzip. The resulting payload is another library written in C#, which is loaded in memory and executed by invoking a method named “Equal” from the class “X” defined in the loaded code. The second base64-encoded string loaded from the registry is passed as argument to the new C# library.


Code snippet used to load and execute final stage

Samurai backdoor

The final stage is a formerly unknown modular backdoor that we dubbed Samurai, due to a constant keyword used inside an important dictionary used by the malware to share data between its modules.

The library was developed in C# and uses the .NET HTTPListener class to receive and handle HTTP POST requests, looking for specially crafted requests that carry encrypted C# source code issued by the attackers. These programs will be in turn compiled and executed during runtime.

The malware is obfuscated with an algorithm developed to increase the difficulty of reverse engineering by making the code complicated to read. Multiple functions in the code are assigned random names, while some perform very simple actions, like getting a property of an object passed as input.

Moreover, the malware uses multiple while loops and switch cases to jump between instructions, thus flattening the control flow and making it hard to track the order of actions in the code. The flow is controlled by modifying the switch case expression value and using break and goto statements to restart the loop, re-evaluate the switch expression and jump to the correct instruction.


Code snippet with while loop and switch case

The malware’s logic starts by decrypting configuration data provided as an input argument. Those data are encoded with base64 and encrypted with the DES algorithm using the hardcoded key 90 EE 0C E1 6C 0D C9 0C. The resulting payload is a configuration file, which is customized per victim, containing multiple lines with several parameters consumed by the backdoor.

Below is an example of the configuration block’s structure:

keywordxyz C:\Windows\Temp\ http://*:80/owa/auth/sslauth/ https://*:443/owa/auth/sslauth/

The first line contains a keyword that needs to be included as a variable in the received POST request, marking it as designated for processing by the backdoor and also used to specify important session parameters like the AES session key and the list of variable names that contain the data that should be processed.

In some variants, the second line is used as a directory path, whose value is used to override the TEMP environment variable. All the other lines are URI prefixes that are used to configure the HTTPListener component, whereby each is a string composed of a scheme (HTTP or HTTPS), a host, an optional port, and an optional path defining which request will be processed by the HTTPListener object.

In several cases, the URL prefixes contained in the configuration included the victim’s domain, as in the following example: https://mail.%redacted%.gov.%redacted%/owa/auth/sslauth.

Once the configuration is successfully decrypted, the backdoor starts the listeners according to the provided configuration and waits for incoming requests. The request must to be structured as in the following example:

POST /owa/auth/sslauth/ HTTP/1.0 Host: example.xyz Headers... keywordxyz={session_AES_key,variable2,variable3}&variable2=[C# source code]&variable3=[argument_for_the_compiled_program\r\nassembly_reference1;assemb ly_reference2]

Where:

{} = encrypted with default AES key + base64 encoded [] = encrypted with session AES key + base64 encoded ### Input config ### keywordxyz C:\Windows\Temp\ http://*:80/owa/auth/sslauth/

The request body should contain three values, one of which is equal to the keyword specified in the configuration received as input. The related value should be encoded with base64 and encrypted with AES, using a predefined key. The resulting string will contain three values delimited by the comma character: the first value is another AES key that is used to decrypt the other POST values, the second is the name of the variable that contains the C# source code, and the third contains the name of the variable that contains the arguments and the list of assembly references that should be added to the compiled project.

Once compiled, the backdoor tries to invoke a method named “run” from a class named “core” that should be included in the received program. The invoked method receives two arguments as input:

  • The first one is a dictionary containing a key named “samurai” holding the current working directory path as a value.
  • The second is a value provided by the attacker in the third element of the POST request.

If the request is valid and the code is successfully executed, the backdoor replies with an HTTP 200 code, including the result generated by the invoked .NET assembly in the response body. The message will be encrypted with AES using the session key and it will be encoded with Base64.

Uploaded modules

During our investigation, we were able to discover some modules uploaded by the attackers and compiled by the Samurai backdoor:

Module Description Remote Command Execute arbitrary commands using the Windows command line, cmd.exe. File enumerator Get a list of files and directories in a specific path provided by the attacker as an argument. File exfiltration Download arbitrary files from the compromised machines. Proxy Connect Start a connection to a remote IP address and TCP port specified in the code. Proxy Handler Forward the payload received with HTTP request to the remote IP address and vice versa.

It is worth mentioning the arguments passed to the modules, which in some cases are structures with specific formats. All modules must contain a “run” method, which expects two arguments, a dictionary that contains the “samurai” keyword with the current working directory, and a string provided by the attacker. The string should include values separated by the semi-colon character (“;”).

For example, the following is a valid string for the Remote Command module:

Y21kLmV4ZQ==;ZGlyICVNQUxESVIlXCoubXdy;TUFMRElSPUM6XE1hbGRpcg==

The string contains three different fields, and each of them is encoded with base64. The decoded value for this example is the following:

cmd.exe;dir %MALDIR%\*.mwr;MALDIR=C:\Maldir

The first value is the program that will be executed, the second one is the argument that will be passed to the new process and the last one is an environment variable.

The cumbersome administration of the Samurai backdoor using arguments in this structure suggests that the Samurai backdoor is the server-side component of a bigger solution that includes at least another client component providing an interface for the operators that can be used to automatically upload some predefined modules.

Further evidence that enhances this hypothesis is related to the proxy modules, two different C# programs developed to forward TCP packets to arbitrary hosts. The attacker uses these modules to start a connection between a running instance of a Samurai backdoor and a remote host and forward the packets using the backdoor as a proxy. It is probably used to move laterally inside the compromised network. Most of the detected modules were configured to communicate with internal IPs on standard ports, such as: 135, 445, 389, 80 and 443.

The first program is used to initialize the connection and it embeds the remote IP and the remote port inside the code.


Code snippet with the socket object creation

When the connection is established, the socket object is added to the first argument received by the “run” method. This argument is usually a dictionary that contains the keyword “samurai”.

So, the socket object is stored in the dictionary as the value of a unique key, whose name is composed by the word “ninja” followed by an alphanumeric unique code. The same value is then embedded in the second program, which is used to handle the packets.


Code snippet of socket object handling

It suggests that the C# source code is probably dynamically generated by a client-side program that keeps track of proxy sessions.

Ninja Trojan

In specific cases the Samurai backdoor was used to deploy another sophisticated malware that we dubbed Ninja, a tool developed in C++, likely a part of an unknown post-exploitation toolkit developed by ToddyCat.

This tool was designed to take full control of a remote system and provide the attacker with the ability to operate deeply within the targeted network. The attacker can use a number of different commands that provide the following capabilities:

  • Enumerate and manage running processes;
  • Manage the file system;
  • Start multiple reverse shell sessions;
  • Inject code in arbitrary processes;
  • Load additional modules (probably plugins) at runtime;
  • Provide proxy functionalities to forward TCP packets between the C2 and a remote host.

Moreover, the tool can be configured to communicate using multiple protocols and it includes features to evade detection, camouflaging its malicious traffic inside HTTP and HTTPS requests that try to appear legitimate by using popular hostname and URL path combinations. The configuration is fully customizable and is similar to other features provided by famous post-exploitation tools such as Cobalt Strike and its Malleable C2 profiles.

The attacker can configure the agent to work only in specific time frames, which can be dynamically configured using a specific command.

Last, but not least, each agent can also work as a server component that receives packets from other agents, parses the requests and forwards them to another predefined C2. This feature allows the attackers to create chains of servers and communicate with agents without a direct internet connection. It can also be used to avoid network detections, by forwarding all malicious traffic generated inside a targeted intranet through a unique node instead of generating activities from all compromised machines.

Loader

We have never observed Ninja stored on the file system; it is usually loaded in memory by another component. The loader is usually an executable file, which shares many similarities with the iiswmi.dll library and Samurai installers such as the previously mentioned debug.exe.

The loader uses the same “special resolution function” to call the Windows API and decrypts the file payload using 3DES (112-bit) and uncompress the decrypted data with the LZSS algorithm.

The resulting payload is a library that will be mapped in memory by the loader without the DOS header and it will be invoked calling an exported function “Debug”.

We observed multiple variants, and the tool evolved during the year. The first samples lacked some features, such as the ability to handle multiple sessions on the client side and the ability to communicate with HTTP and HTTPS protocols. The embedded configuration structure was also a little different.

In this article we are going to describe the last detected version.

Config

The malware starts operations by retrieving configuration parameters from an encrypted payload embedded in the binary, which is XORed with the constant value “0xAA” and compressed with the LZSS algorithm.

The analyzed configuration contains a list of 15 elements with the following values:

Parameter Description 2B847033-C95F-92E3-D847-29C6AE934CDC Mutex name used to guarantee atomic execution. C2_INFO A structure that contains the information to communicate with the C2 servers. /Collector/3.0/ URL path used with HTTP and HTTPS protocols. Content-Type: application/x-www-form-urlencoded HTTP header used with HTTP and HTTPS protocols. Host: mobile.pipe.microsoft.com:8080 HTTP header used with HTTP and HTTPS protocols. Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv 11.0) like Gecko User-Agent used with HTTP and HTTPS protocols. 0 Working hour Start. 0 Working minute Start. 0 Working second Start. 0 Working hour Stop. 0 Working minute Stop. 0 Working second Stop. 0 TCP C2 communication interval. 300 HTTP C2 communication interval. 0 Local Server port.

The first element is the mutex name, which could be any string, but usually looks like a GUID value. C2_INFO is a string that contains multiple values organized with a specific structure.

HTTP config

The attacker can also customize the HTTP URL path and headers to mimic legitimate services and hide malicious traffic. The specific values in the example will generate requests like the following.

POST /Collector/3.0/ HTTP/1.1 Content-Type: application/x-www-form-urlencoded Host: mobile.pipe.microsoft.com:8080 User-Agent: Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv 11.0) like Gecko Content-Length: 430 Cache-Control: no-cache

We may infer that the attacker was trying to emulate Microsoft Teams behavior, although the “User-Agent” and the “Host” headers are incorrect.

C2 Info

The C2_INFO contains multiple information items specified with the following format:

%Protocol% \r %C2_Hostname% \r %C2_Port% \r %Proxy_Type% \r Proxy_Info

The protocol is a numeric value that identify the communication protocol:

  1. HTTP
  2. HTTPS
  3. TCP

The C2 hostname and port are self-explanatory.

The “Proxy_Type” is another integer that can have three different values:

  1. No Proxy. Connect to the C2 directly
  2. System Proxy
  3. Manual Proxy

When the value is equal to “3”, the agent will try to decode a base64 string embedded in “Proxy_Info” that contains different information, according to the specified protocol. When the protocol is HTTP or HTTPS, the following information must be specified:

%Proxy_Address% : %Proxy_Port% \t %Proxy Username% \t %Proxy_Password%

If the protocol is TCP, the decoded strings could specify a proxy chain with up to 255 hops.

%Proxy_Address% \t %Proxy_Port% \t %Remote_Host% \t %Remote_Port% \r %Proxy_Address% \t %Proxy_Port% \t %Remote_Host% \t %Remote_Port% \r %Proxy_Address% \t %Proxy_Port% \t %Remote_Host% \t %Remote_Port% \r %Proxy_Address% \t %Proxy_Port% \t %Remote_Host% \t %Remote_Port% \r ... up to 255

The information will be used by the agent to initialize the connection with the C2.

Working time config

The Ninja agent includes an interesting ‘working time’ feature that can be used to force the malware to work only within a specific time frame. For example, it could configure the malware to work only from 9am to 6pm, during typical working hours. This feature is useful to avoid being detected by specific security solutions such as behavior-based intrusion detection systems. When the values are equal to zero, the feature is disabled and the agent works at any time. The attacker can remotely configure these options with a specific command.

Local server

The last value is the local server port. When the local server feature is enabled, the agent acts as the C2. It waits for agent connections, decodes the received requests and forwards them to the remote C2. This feature is probably used for ‘pivoting’ and accessing other internal systems from the compromised machine. Also, this value can be modified by the attacker with a specific command.

Communication protocol

Malware communications are protected with a sequence of encryption and encoding algorithms, with small differences between the HTTP and TCP protocols.

Both protocols use a message format as follows:

Message_ID@Message_payload

The “Message_ID” changes according to the command type and the “Message_payload” contains the real payload compressed, XORed with the static value 0x3F and encoded with base64 algorithm using a custom alphabet.

The resulting message is then encrypted with AES 256 using a session key generated by selecting two random characters from the custom base64 alphabet. The agent will use random characters to generate a SHA1 hash, which will be used for the AES encryption.

The encrypted data is then encoded again using the base64 algorithm and the resulting string is appended to the previously generated random character to allow the server to decrypt the information.

When the agent is configured to use the HTTP/S protocol, the data are included in standard POST requests.

If the C2 communicates using the TCP protocol, the agent will send a first packet with the constant value 0x6CC8DF01 and then other packets with the generated payload. The server should reply with a packet with the same constant value 0x6CC8DF01 and then with other packets encrypted with the same algorithms. The constant value is not always the same, but changes according to the variant.

The first message is sent using the “Message_ID” 10001 and it contains information about the infected system and the agent configuration.

  • System info (collected with Kernel32.GetNativeSystemInfo function)
  • OS info (collected with Ntdll.RtlGetVersion function)
  • Computer name
  • Local IP address
  • Agent file path
  • Agent PID
  • Agent Sleep Time
  • Agent C2 configuration (C2 hostname, Port, Proxy Info)
Commands

The server response usually has the following structure:

  • Magic constant 0x887766
  • Number of commands
  • List of commands

The “Magic constant” is an integer, the value of which changes according to the variants. The list of commands is an array, and for each element the attacker could specify:

  • CommandID
  • Arguments Size
  • Arguments

The argument values change according to the “CommandID”, but usually they are strings with multiple values divided by the ‘*’ character.

Command ID Description Response ID 20000 Enable Session 20001 Disable Session 20002 Update sleep time 20003 Kill Bot 20004 Execute program as user 20005 Set Local Server Port 20006 Safe Exit 20010 Shell::Start new session 30010 20011 Shell::Handle Command 30011 20012 Shell::Close Session 30012 20013 Shell::Terminate Session Tree 30013 20020 File::Get Drives list 30020 20021 File::Get Directory content 30021 20022 File::Create directory 30022 20023 File::Delete file 30023 20024 File::Remove directory 30024 20025 File::Move file 30025 20026 File::Change Create\Last access\Last write Time 30026 20030 File::Read file 30030 20031 File::Write file 30031 20040 Proxy::Start Session 30040 20041 Proxy::Set socket as writeable 30041 20042 Proxy::Send Data 30042 20043 Proxy::Receive Data 30043 20044 Proxy::Close Session 30044 20045 Proxy::Reconnect 30045 20050 Enumerate Processes (filename|pid|number of threads) 30050 20051 Kill a list of processes 20052 Process Injection 30052 20053 Plugin::Load 30053 20054 Plugin::Read Output 30054 20055 Plugin::Unload 30055 20056 Enumerate Processes (SessionID\PID\Domain\Username) 30056 20060 Injection::Start new session 30060 20061 Injection::List active sessions 30061 20062 Injection::Close session 30062 20064 Injection::Inject code in a new process 30064 20065 Injection::Read “pobject” 30065 20068 Injection::Read “create_object” 30068 21000 Configure Working Time 31000

Some commands are self-explanatory, others aren’t, and in some cases we are unable to fully understand them since we are still missing some information.

The Enable and Disable session commands are used to activate or deactivate the Agent. The attacker should enable the bot before sending any other commands, which will be dropped by deactivated bots. The Enable command is also mandatory to enable the “Local server” feature.

The Shell, Proxy and Injection commands were designed to run multiple parallel sessions, which probably means that multiple operators can work on the target machine simultaneously. The agent manages three structures, one for the Shell, one for the Proxy and the last one for the Injection commands.

For example, when the attacker wants to start a shell, they must use the command “20010” that will force the agent to create a new process and new pipes used to redirect the standard input and the standard output. The “Shell session ID” must be specified by the attacker and this value will be stored in the local array, which contains the list of active sessions. If the command succeeds, the agent will reply with a list of information like new PID and pipe handles.

The command 20011 can be used to read or write data in the pipes. The attacker has to provide a valid “Shell session id”, an event ID and the pipe handles. Before processing the command, the agent will check if the provided ID is valid, by comparing the values with those in the local structure.

The command 20012 is used to close an active session, remove the “Session_ID” from the local array, terminate the running process and close the pipe handles. A similar logic is used to manage the Proxy commands, which can be used to forward packets to other remote hosts using the TCP protocol.

The Plugin commands are used to load other unknown libraries in the agent process address space. We don’t have information about the other modules, but we presume they are additional plugins that can be used by the attacker to provide more features.

Based on static analysis we know the libraries should export at least three functions: GET, RUN and CLOSE; and then share data with the main process by using a file mapping object.

The “Process Injection” (20052) command and the “Injection” set of commands could cause some confusion, but they are quite different. The first one is used to inject arbitrary shellcode in a running process. The second is used to inject another agent module in a new process specified by the attack. The injected code is not an arbitrary shellcode, but something that should communicate with the main agent by using specific file mapping objects.

The attacker uses command 20060 to start a new injection session, where the attacker basically provides the shellcode that will be injected in a new program, and whose path will be specified with command 20064.

The “Injection::Inject code in a new process” command will force the agent to start a program specified by the attacker. The specified program will be created as suspended and the agent will write the shellcode in a new section allocated in the created process.

The agent then gets the remote thread’s context to obtain the instruction pointer address and replace the instruction in that offset with the following:

dec eax sub esp, 40h dec eax mov eax, %SHELLCODE_ADDRESS% call eax

Finally, the code will resume the remote process, which will execute the injected code.

The commands 20065 and 20068 are then used to read data from the file mapping objects, which should contain information generated by the injected code.

Other campaigns and variants Other variants

During our investigations, we discovered several loader and installer variants that evolved during 2021 and were used in different campaigns.

Installers

All the installers are quite similar in their logic: they load a payload from an external file, usually located in the same directory, with a name that differs according to the variant:

  • debug.xml
  • web.xml
  • access.log
  • cache.dat
  • reg.txt
  • logo.jpg

The files are always decrypted with the same algorithm, CALG_3DES_112, but the loaded data are usually tailored for the victim.

All installers create a new service using a name and description specified in an encrypted file. They also set a registry value (either httpsvc or w3esvc) in the following Windows registry key:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SvcHost

These values cause svchost.exe to automatically start the malicious service and load the code in its process address memory. The registry values contain the malicious service name. The main difference between the installer variants is related to the final payload. Based on initial investigations, we know that the first variants (from December 2020 to May 2021) were configured to store their payload inside a registry key, such as:

$HKLM\SOFTWARE\Classes\Interface\{6FD0637B-85C6-D3A9-CCE9-65A3F73ADED9} $HKLM\SOFTWARE\Classes\Interface\{AFDB6869-CAFA-25D2-C0E0-09B80690F21D}

Starting from March we also observed new variants configured to store the final backdoor inside other encrypted files in the file system. The most common dropped the Stage 2 loader in the following paths:

  • %System32%\Triedit.dll
  • %System32%\fveapi.dll

and the Stage 3 loader and encrypted payload in the following paths:

  • %WINDIR%\Microsoft.NET\Framework\sbs_clrhost.dll
  • %WINDIR%\Microsoft.NET\Framework\sbs_clrhost.dat
  • %WINDIR%\Microsoft.NET\Framework\Util.dll
  • %WINDIR%\Microsoft.NET\Framework\Util.dat

Starting from September 2021, we observed new samples configured to once again store the final payload in the Windows registry, but instead of relying on static registry key values, the malware was configured to create a dynamically generated key in $HKLM\SOFTWARE\Classes\Interface\, based on the disk drive’s serial number:


Code snippet to create a registry key based on the Volume Serial Number

The constants used to generate the final registry key name change for each sample.

Loaders

The loaders are basic tools used to decrypt payloads from 3DES and load them into memory. They were modified over time along with the installers to account for the changes in how the final payload is stored.

Some loaders, like those mentioned in the previous paragraph, were configured to load another payload from an encrypted file and pass the resulting data as arguments for another library, a Stage 3 loader, stored in a specific location.

Other loaders were configured to load the payload from the registry and pass it to the Stage 3 library.

Some variants included a function to directly run .NET code at runtime, without relying on another external Stage 3 library.

Finally, we observed other loaders that were mainly used on desktop systems to load the Ninja Trojan.

Other attacks against Desktop systems

The first waves of attacks exclusively targeted Microsoft Exchange servers, but starting from September 2021, we also observed a new set of loaders detected on desktop systems in Central Asia with filenames such as “01.09.2021 г..exe”, “03.09.2021 г.exe”, “нота мид кр регламент.exe” and “Тех.Инструкции.exe”.

The files were loaders configured to run the Ninja component, but they were distributed as executable files embedded in zip archives and sent through the popular messaging app Telegram.

The programs were configured to load a payload from another file, “license.txt”, which should be located in the same directory. The malware then uses the previously described “special resolution function” to call the Windows API and decrypts the file payload using 3DES (112)-bit and uncompresses the decrypted data.

The resulting payload is the Ninja library that will be mapped in memory by the loader without the DOS header and it will be invoked calling an exported function “Debug”.

How to detect the Samurai backdoor

The whole infection scheme used to deploy and guarantee Samurai persistence, was designed to avoid forensic analysis and the most common superficial checks.

As we said, the malicious code is loaded by the legitimate svchosts.exe process, which means that the backdoor cannot be detected with a simple process enumeration.

Moreover, the backdoor cannot be spotted by watching the open TCP ports, because it uses the .NET HTTPListener class, which is built on top of HTTP.sys and allows different processes to share the same ports. In the case of the Samurai backdoor, it uses ports 80 or 443, which are also used by Microsoft Exchange.

We detect this backdoor as “HEUR:Backdoor.MSIL.Samurai.gen”, but in the absurd case that you are not using our products, a simple way to check if the backdoor is running is to try to find one of the IoCs shared in this blogpost or trying to execute the following command:

#>netsh http show servicestate verbose=yes

As described by Microsoft, this command will display a snapshot of the HTTP service, and you can try to find suspicious registered URLs such as the following:

Server session ID: ED00000020000013 Version: 2.0 State: Active Properties: ... Max bandwidth: inherited Max connections: inherited Timeouts: Timeout values inherited Number of registered URLs: 2 Registered URLs: HTTP://*:80/OWA/AUTH/TOKEN/ HTTPS://*:443/OWA/AUTH/TOKEN/

Victims

Based on our visibility we know that ToddyCat focused its attention on high-profile targets; most of them were government organizations and military entities, as well as military contractors.

We know the attacks launched before February 2021 targeted a very limited number of government entities in:

  • Taiwan
  • Vietnam

After the ProxyLogon publication the number of detections rapidly increased around the world, and we also observed victims in the following countries:

  • Afghanistan
  • India
  • Iran
  • Malaysia
  • Pakistan
  • Russia
  • Slovakia
  • Thailand
  • United Kingdom

After May 2021, we observed other variants and campaigns that we attributed to the same group and affected most of the previously mentioned countries in Asia and the following:

  • Kyrgyzstan
  • Uzbekistan
  • Indonesia


Overall affected victims map

Attribution

Unfortunately, we were not able to attribute the attacks to a known APT group; and for this reason we dubbed this entity ToddyCat.

During our investigations we noticed that ToddyCat victims are related to countries and sectors usually targeted by multiple Chinese-speaking groups. In fact, we observed three different high-profile organizations compromised during a similar time frame by ToddyCat and another Chinese-speaking APT group that used the FunnyDream backdoor.

This overlap caught our attention, since the ToddyCat malware cluster is rarely seen as per our telemetry; and we observed the same targets compromised by both APTs in three different countries. Moreover, in all the cases there was a proximity in the staging locations and in one case they used the same directory.

Target 1
C:\ProgramData\Microsoft\DRM\rundll.dll – FunnyDream related
C:\ProgramData\Microsoft\mf\svchost.dll – ToddyCat

Target 2
C:\ProgramData\adobe\avps.exe – FunnyDream related
C:\ProgramData\adobe\2.dll – ToddyCat

Despite the overlap, we do not feel confident merging ToddyCat with the FunnyDream cluster at the moment. Considering the high-profile nature of all the victims we discovered, it is likely they were of interest to several APT groups. Moreover, despite the occasional proximity in staging locations, we have no concrete evidence of the two malware families directly interacting (for instance, one deploying the other), and the specific directories are frequently used by multiple attackers.

Conclusions

ToddyCat is a sophisticated APT group that uses multiple techniques to avoid detection and thereby keeps a low profile. During our investigations we discovered dozens of samples, but despite the number of files and the duration of their activities, we were unable to attribute the attacks to a known group; and there is also quite a bit of technical information about the operations that we don’t have.

The affected organizations, both governmental and military, show that this group is focused on very high-profile targets and is probably used to achieve critical goals, likely related to geopolitical interests.

Based on our telemetry, the group shows a strong interest in targets in Southeast Asia, but their activities also impact targets in the rest of Asia and Europe.

We’ll continue to monitor this group and keep you updated.

More information, IoCs and YARA rules about ToddyCat are available to customers of the Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com.

ToddyCat’s indicators of compromise

5cfdb7340316abc5586448842c52aabc Dropper google.log
93c186c33e4bbe2abdcc6dfea86fbbff Dropper
5a912beec77d465fc2a27f0ce9b4052b Dll Loader Stage 2 iiswmi.dll
f595edf293af9b5b83c5ffc2e4c0f14b Dll Loader Stage 3 websvc.dll
5a531f237b8723396bcfd7c24885177f Dll Loader Stage 2 fveapi.dll
1ad6dccb520893b3831a9cfe94786b82 Dll Loader Stage 2 fveapi.dll
f595edf293af9b5b83c5ffc2e4c0f14b Dll Loader Stage 3 sbs_clrhost.dll
8a00d23192c4441c3ee3e56acebf64b0 Samurai Backdoor
5e721804f556e20bf9ddeec41ccf915d Ninja Trojan

Other variants
33694faf25f95b4c7e81d52d82e27e7b 1.dll – Installer
832bb747262fed7bd45d88f28775bca6 Техинстр egov – ГЦП – Акрамов.exe – Loader
8fb70ba9b7e5038710b258976ea97c98 28.09.2021. Управление ИР и ИС.exe – Loader
ee881e0e8b496bb62ed0b699f63ce7a6 Loader
ae5d2cef136ac1994b63c7f8d95c9c84 Loader
5c3bf5d7c3a113ee495e967f236ab614 System.Core.dll – Loader
bde2073dea3a0f447eeb072c7e568ee7 wabext.dll – Loader
350313b5e1683429c9ffcbc0f7aebf3b rcdll.dll – Loader

Ninja C2
149.28.28[.]159
eohsdnsaaojrhnqo.windowshost[.]us

File paths
C:\inetpub\temp\debug.exe
C:\Windows\Temp\debug.exe
C:\Windows\Temp\debug.xml
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\web.exe
C:\Users\Public\Downloads\dw.exe
C:\Users\Public\Downloads\chrome.log
C:\Windows\System32\chr.exe
C:\googleup.exe
C:\Program Files\microsoft\exchange server\v15\frontend\httpproxy\owa\auth\googleup.log
C:\google.exe
C:\Users\Public\Downloads\x64.exe
C:\Users\Public\Downloads\1.dll
C:\Program Files\Common Files\microsoft shared\WMI\iiswmi.dll
C:\Program Files\Common Files\microsoft shared\Triedit\Triedit.dll
C:\Program Files\Common Files\System\websvc.dll
C:\Windows\Microsoft.NET\Framework\sbs_clrhost.dll
C:\Windows\Microsoft.NET\Framework\sbs_clrhost.dat
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\web.xml
C:\Users\Public\Downloads\debug.xml
C:\Users\Public\Downloads\cache.dat
C:\Windows\System32\config\index.dat
C:\Windows\Microsoft.NET\Framework\netfx.dat
%ProgramData%\adobe\2.dll
%ProgramData%\adobe\acrobat.exe
%ProgramData%\git\git.exe
%ProgramData%\intel\mstacx.dll
%ProgramData%\microsoft\drm\svchost.dll
%ProgramData%\microsoft\mf\svchost.dll
%ProgramData%\microsoft\mf\svhost.dll
%program files%\Common Files\services\System.Core.dll
%public%\Downloads\1.dll
%public%\Downloads\config.dll
%system%\Triedit.dll
%userprofile%\Downloads\Telegram Desktop\03.09.2021 г.zip
%userprofile%\Downloads\Telegram Desktop\Тех.Инструкции.zip
%userprofile%\libraries\1.dll
%userprofile%\libraries\chrome.exe
%userprofile%\libraries\chrome.log
%userprofile%\libraries\config.dll
C:\intel\2.dll
C:\intel\86.dll
C:\intel\x86.dll

Registry Keys
$HKLM\System\ControlSet\Services\WebUpdate
$HKLM\System\ControlSet\Services\PowerService
$HKLM\SOFTWARE\Classes\Interface\{6FD0637B-85C6-D3A9-CCE9-65A3F73ADED9}
$HKLM\SOFTWARE\Classes\Interface\{AFDB6869-CAFA-25D2-C0E0-09B80690F21D}

2022. június 20.

‘Unpacking’ technical attribution and challenges for ensuring stability in cyberspace

Introduction

When reports of a cyberattack appear in the headlines, questions abound regarding who launched it and why. Even if an attacker has what are to it perfectly rational reasons for conducting such an attack, these reasons are often known only to them. The rest of the world, including the victims of the attack, must often engage in some degree of speculation to explain the events and devise ways to protect themselves accordingly. Knowing the technical aspects of an attack may allow victims to build stronger defences, patch gaps and increase their cyber-resilience. This is why both policymakers and industry leaders are usually eager to have this knowledge as a possible ‘cure’ to mitigate or prevent such cyberattacks from happening again.

A constant challenge in such an endeavour is that the cyber context, in all its complexity and interconnectedness, remains a dark, unknown forest for many decision-makers. How then can they find out who was behind an attack and why?

Attribution of a cyberattack is not ‘magic’. It is a complex process where technical, legal and political discussions intertwine to produce as complete a narrative as possible – with as many plausible answers as possible (though not always comprehensive ones). Technical attribution relates to a technical investigation to identify who was behind a cyberattack or cyber operation. Legal attribution assesses if there has been a breach of international law. Finally, political attribution implies the political decision to publicly or privately announce those assessments and tie them to a particular state or private actor.

Security researchers and private cybersecurity companies can typically analyse cyber incidents from a technical standpoint and cluster them into groups, which they then tie to particular threat actors. However, the only actors that deliver the entire narrative of a cyberattack – discussing accountability and international law – are nation states. The decision-making of states is highly complex in nature, often involving multiple considerations – from domestic issues to foreign affairs. Publicly attributing cyberattacks, meaning announcing who is thought to be responsible, is therefore often not straightforward, and states might not always be willing to make such announcements.[1]

Within this piece, we, a collection of policy scholars and industry experts, discuss how technical attribution – identifying who is behind a cyberattack – can become more transparent and better understood by the wider public. Our key discussion points include: How is technical attribution carried out? What are the key challenges in conducting reliable technical attribution? And finally, how can this be more accessible to the multitude of stakeholders who are operating in cyberspace and/or have interests there?

Below are our reflections on these questions, divided into several parts. Firstly, we discuss technical attribution and options to make it more transparent and accessible; next we reflect on how, given existing limitations within multilateral initiatives, the international community might make incremental improvements towards ensuring that technical attribution is made more transparent and more accessible and ensure the stability and security of cyberspace.

Why would anyone want to know details of technical attribution?

Cyber attribution is a necessary step to accountability in cyberspace.[2] It serves as a basis for a response: for states in accordance with international law, and for the private sector (if it owns or manages attacked infrastructure) in accordance with national applicable laws. Cyber attribution is a necessary precursor to retaliation – technical, legal or political. And if a state has advanced attribution capabilities, it is in a better position to understand what has happened and appropriately react to a cyberattack. Attribution capabilities are therefore a crucial element in building a deterrence strategy against malicious behaviour.

Besides states and security researchers, why would anyone else be interested in conducting technical attribution and finding out all possible details?

Given the multistakeholder nature of cyberspace, a state’s sovereign decision on cyber attribution – whether public or private – may have far-reaching consequences for other stakeholders. The increasingly relevant discussions, from scholars, academia and civil society,[3] further signal interest in greater transparency of and accessibility to, at least, technical attribution.

These decisions impact geopolitical realities, and in this regard the more information other decision-makers (e.g., owners of ICT infrastructure that procure tools and services for critical functions and sectors) have, the better they are informed about these geopolitical realities to make decisions that would, in turn, impact users of such ICT infrastructure.

In addition, accessibility to information about technical attribution provides third parties with the ability to assess the results of technical analysis and investigation. Third parties may spot gaps and inconsistencies in the evidence presented and thus help increase the credibility and quality of technical attribution.

In practice, some States have clearly communicated that there is no obligation under international law to disclose underlying evidence of attribution. Scholars also highlight the significant security risks that public (technical) attribution brings and thus argue that “public attribution is not always better.” Nonetheless, the idea of an international attribution mechanism has been floated by several experts and organizations, proposing an independent mechanism for impartial analysis and decision-making in cyber attribution to complement and assist in states’ sovereign decisions.[4] [5] While states’ reservations regarding calls for greater transparency in cyber attribution and the risks it may carry for strategic competition are valid and do have merit,[6] the benefits of making technical attribution more accessible and better understood by the wider international community should also be explored.

Following on from the previously discussed key thought that cyber attribution as states’ sovereign prerogative has wider impacts on non-state actors, we hope that more transparent and accessible technical attribution would be important for states to develop better and fact-based assessments, and thus contribute to greater stability and predictability in cyberspace. After discussing how technical attribution is conducted and current difficulties and limitations with it, we reflect on suggestions for the continuing negotiations in the United Nations Open-Ended Working Group on Developments in Information and Telecommunications in the Context of International Security (UN OEWG) and for the international community broadly.

How the pie gets made: steps in conducting technical attribution

While the idea of cyber attribution – i.e., determining who is responsible for an attack – is generally understandable by anyone, its technical underpinnings usually rely on domain-specific knowledge. In almost all cases, with the exception of attribution provided through human intelligence (or HUMINT), it is based on careful analysis of available technical information. The end result of this process is technical attribution: intelligence that informs readers about the identity of the attackers. But in this specific context, ‘identity’ should not be understood in the traditional sense: this type of attribution is not aimed at pointing to a door that law enforcement can then kick down. This would in fact require leaps that are usually impossible based on the information available. Instead, the objects crucial to the process of technical attribution are threat actors and attack campaigns. Such ‘objects’, as referred to here, point to things such as malware and hijacked servers, which, when put together and ‘manipulated’, inform the technical attribution process. The process produces clusters that represent malicious cyber activity, which can be grouped together based on identifiable characteristics of the attack and previous attacks.

Technical attribution may lead the conclusion that, e.g., “APT 41 is responsible for this attack”, where APT 41 is a term used to consistently designate a specific attacker in the context of different incidents. Figuring out who the people behind APT 41 are would be the prerogative of political, rather than technical, attribution. Technical attribution is only concerned with understanding what characterizes APT 41 as an attacker, and which cyberattacks they are responsible for. But how does this process take place?

To understand this, one must first understand what information is used in the technical attribution process and where such information comes from. Taking control of an IT system implies a lot of interaction with it: using vulnerabilities to acquire privileges on the machine, deploying programs to exert control over it, and so on. All these operations affect the target computer or device in very specific ways: files are created, log entries are written, network traffic is generated, and so on. Despite the best efforts of the attackers to leave the smallest possible footprint, it is almost impossible to erase all traces of an attack. The main reason for this is that some of the technical information generated during the interaction is not stored in the compromised machine, or even in the target network (i.e., within network activity logs collected by the Internet Service Provider (ISP), etc.). Below are some examples of the type of data collected and strategies of collection and analysis during the technical attribution process.

Tooling

Most readers will be familiar with ‘backdoors’, ‘Trojans’ and the like – computer programs used to send arbitrary commands to a compromised device, but where do these tools come from? Some of them can be purchased as commercial products, others are open-source and freely available. Some of these tools have even been created by threat actors themselves.

In the latter case, discovering the same unique malware family in two separate cyber-incidents is a strong indication that they share the same perpetrator. A significant part of the work that cyberthreat intelligence teams perform is meticulously indexing known and unknown attack software, and keeping track of which entities use it.

Infrastructure

The tools described in the previous paragraph and deployed in victims’ networks do not function in a vacuum. The stolen data needs to be exfiltrated somewhere, and the backdoor needs a place (like a dead-drop) where it obtains the commands to execute. Servers and domain names purchased online serve this function and are collectively seen as the ‘infrastructure’.

When the same server is used simultaneously in the context of two apparently uncorrelated attacks, conventional wisdom suggests that whoever owns it must therefore be responsible for them both. Technical attribution can take the investigation process further, often by noting attacker habits – such as which resellers they favour, the specific way they configure their machines, and so on. All of this makes it possible to tie together incidents that do not involve the exact same servers (i.e., servers with different IP addresses), or sometimes even discover the infrastructure of a given threat actor before it is used in an operation.

Attacker procedures

Finally, it is sometimes possible to obtain a clear picture of what the attackers do once they are inside a network: this encompasses the deployment of additional offensive tools and utilities, but also the commands they type. Due to the number of members of attack groups, some of them have to put strict and repeatable procedures in place – allowing for various operators to fill in for one another. Identifying such recurrent patterns, such as a sequence of information gathered in a specific order from a new machine, can allow defenders to recognise a threat actor across multiple incidents.

Beyond this, other aspects that can hint at the identity of attacks include more trivial elements – such as which encryption algorithm, network protocol or attack vector an attacker favours.

The above strategies form a key aspect of the technical attribution process: they transcend individual incidents and aim at building knowledge that can be useful within a larger context. However, no vendor or intelligence service has full visibility over all cyber incidents taking place: defenders only know about what is going on inside their network; incident responders are only aware of the incidents they are asked to remediate; security vendors only obtain limited telemetry from their customer base.

It follows that no single entity can be successful at attribution alone: it is only by sharing information about threat actors (i.e., through whitepapers, conferences and blog posts) that the industry’s knowledge has allowed us to keep track of the hundreds of threat actors identified over the years.

What are the difficulties, uncertainties and limitations of technical attribution?

Even assuming that it is fully available to those performing cyber attribution, technical information is limited, and does not always allow for robust answers. The obvious blind spot is that private cybersecurity vendors often have no investigative powers. This precludes everyone in the industry from ‘following the money’. In the case of attacker infrastructure, servers and domain names are not obtained for free: one way or another, threat actors must find a way to pay for them. Traces generated at this stage are simply unavailable at the technical level.

Tool-based attribution (i.e., grouping together attacks that leverage the same unique malware families) has also been getting more difficult over the years – for two reasons. Firstly, a number of attackers have eschewed homemade backdoors to solely rely on open-source software. These publicly available backdoors can be used by anyone and cannot characterize a single threat actor unless some significant and unique modifications have been made to them. Secondly, Kaspersky has also observed the tendency to share tools and procedures between close yet distinct threat actors, e.g., instance hacker groups from the same region, working for the same sponsor, but going after different target verticals (e.g., the education, energy, or fintech sectors).

Adding to the uncertainty of technical attribution are two important issues that need mentioning. The first is that a number of attackers are acutely aware of the technical attribution process and will therefore attempt to impede it by misleading analysts. The issue is further compounded by the fact that attackers interact with each other and may steal tools from one another – how would defenders then be able to distinguish between the original owner and the copycat? Threat actors may also try to purposefully leave behind ‘false flags’ – indicators that incriminate other groups. Such false flags may only be discovered through very careful analysis and are likely happening more frequently than the industry is aware of.

The second issue is that the technical information analysts work with is very ambiguous. High-profile victims may be compromised by several attackers at once: each of them deploying their tools and generating a muddled footprint. This means that those performing technical attribution are unable to clarify whether it is one, two, or even more distinct groups that are responsible for the activity they are investigating. The risk that a tool would be attributed to the wrong group always exists, with the implication of poisoning the global knowledge-well for years.

What are the obstacles to a transparent technical attribution process?

The lack of a global database and the inherent ambiguity of the attribution process imply that cooperation and verifiable procedures are necessary to bolster existing technical attribution efforts. But arguments against global information sharing and transparency in this sphere suggest that a call for such procedures is not a straightforward solution.

One key objection in this regard stems from the possibility of attackers gaining access to such a global knowledge pool of information. Attribution reports contain precise indicators (e.g., file hashes, IP addresses, domain names, and so on), which would allow attackers to see which incidents led to their discovery and how defenders tied the activity to them. The immediate consequence of transparent attribution is that it provides resources for attackers to tap into to further hone their methodologies and cover up the most characteristic aspects of their operations. There is therefore arguably value in protecting methods used to track threat actors from interception, even at the expense of wider cooperation.

A further argument against global information sharing and transparency in technical attribution processes is that disclosing how an attack is attributed also provides information about the capabilities of the defender. Such information might involve trade/industry secrets or even sensitive and/or classified information. Government actors use their signals intelligence (SIGINT) capabilities to provide invaluable data for the cyber attribution process (including political and legal) and would rather not attribute an attack publicly at all than have to disclose their SIGINT capabilities and the extent of their visibility. In a limited number of instances, covertly discovering who the attacker is allows analysts to engage in a post-discovery reconstruction of an alternate trail of technical data. By covert means, we refer to signals intelligence, illegal wiretapping and sometimes even plain hacking. But this process – called ‘parallel construction’ – cannot always be performed, sometimes leaving only a choice between unsubstantiated attribution or no attribution at all.

Paths forward?

There is clearly a cat-and-mouse aspect to technical attribution. As attackers update their methodologies in order to avoid blame, defenders look for new sources of information to help them produce intelligence. The first observation is that tool-based attribution is on the decline. The global availability of sophisticated and free cyber offensive programmes means that attackers will not need to create their own anymore. On the other hand, new capabilities are offered to defenders in response. For instance, there are now offerings for private SIGINT capabilities, where defenders can purchase raw network data collected from the whole world, allowing them to see operators connecting to their attack servers.

Given all the limits discussed above, what could be a way forward for technical attribution that is both more transparent and more accessible?

Building upon existing discussions already taking place at various multilateral fora, such as the first iteration of the UN OEWG or the UN Group of Governmental Experts on advancing responsible State behaviour in cyberspace in the context of international security (UN GGE), this paper suggests some areas through which technical attribution can be made more transparent and accessible. These generally focus on issues pertaining to norm implementation (i.e., norm 13(b) of the UN GGE report concerning cyber attribution) and creating more clarification and guidance for policymakers. Both areas are outlined below:

Building consensus amongst states regarding (technical) attribution

The lack of consensus amongst states regarding the necessity of technical attribution and its associated processes remains to be addressed. For example, regarding Norm 13(b), the UN GGE report has noted that “attribution is a complex undertaking” and that “a broad range of factors should be considered before establishing the source of an ICT incident”.[7] While this acknowledges the complexity of attribution (including technical) that practitioners have raised, it leaves various questions unanswered. Given that attribution is complex and involves many factors, what is the “agreed-upon baseline” for such technical attribution to occur?

Based on documents submitted by states (to both the UN OEWG and UN GGE), it appears that the international community is divided along the lines of whether providing the technical details of ICT incidents (i.e., part of technical attribution) ought to be made compulsory. Some states, such as Russia, have called for legally formalising the need for technical attribution. Others, such as China, while highlighting that states should “demonstrate genuine, reliable and adequate proof” when attributing ICT incidents, hold back from making the provision of evidence a mandatory requirement – note the distinction between use of the term “states should…” and “states must…”.

Additionally, paragraph 24 of the GGE report highlighted the need for states who have suffered cyberattacks to “include the incident’s technical attributes…including the incident’s bearing on international peace and security; and the results of consultations between the States concerned”. However, there remains much potential for future discussions on the topic (such as at the second iteration of the UN OEWG) to take the discussion further to specify or outline what such technical data collection actually entails, as well as the processes for sharing information and consulting with other concerned states.

Fostering mechanisms for multistakeholder cooperation at the regional and international levels

While the UN GGE (July 2021) aimed to promote “cooperative measures to address existing and potential threats” in the ICT sphere, support for mechanisms that promote such cooperation remains lacking. Although states recognise the importance of information-sharing and the value that exchanging best practices could bring,[8] it concedes that considerations on how cooperation regarding attribution can actually occur will have to be addressed in future discussions.

Additionally, the call for increased regional and international cooperation is limited to national-level representatives such as Computer Emergency Response Teams (CERTs) or Computer Security Incident Response Teams (CSIRTs) and national ICT authorities. Considering that private sector partners (e.g., cybersecurity vendors) have a significant amount of cybersecurity expertise, the involvement of such private sector partners in international cooperation efforts could significantly assist the international community in gaining more insight into cyberattacks, and aid in attribution processes. It must be noted that expanding the ‘playing field’ to bring in private sector entities would entail significant national security considerations. Successfully addressing this issue would allow private sector expertise to be utilised and further elevate the technical attribution capabilities that states currently possess. Identifying the channels and mechanisms for private sector involvement seems therefore critical for future discussions on building trusted and verifiable technical attribution.

As demonstrated, there is a clear need for greater communication, transparency, and accessibility to information amongst states, while paying some degree of consideration to national security concerns. However, this is not the first time the international community has faced such transnational problems, which require capacity and expertise-building, as well as cooperation among actors from both the public sector and private industry, in order to solve them. As outlined in the Annex, examples from such disparate areas as piracy, nuclear non-proliferation, and space offer us lessons as to how technical cooperation can operate globally. Information-sharing, a key barrier to international cooperation due to national security concerns, can be effectively implemented once the necessary supporting structures (i.e., agreed-upon definitions and norms) are in place. Potential cooperation can also initially take the form of ‘minilaterals’ or technical ad-hoc groups, where good practices are first shared across a small number of states before being scaled up. Private sector expertise can also be shared with national-level agencies via an array of carefully crafted private-public partnerships (PPP).

Lastly, capacity building to help the multitude of stakeholders as well as states (with less cyber capacities) to learn complexities of technical attribution should be another critical element in ongoing international efforts. Examples of this could be security training sessions, roundtable discussions (e.g., such as those organized by UNIDIR), gamified virtual exercises (e.g., the Cyber Stability Games developed by Kaspersky with the support of DiploFoundation), amongst others.

Conclusion

It is hoped this piece has shed more light on the nuances and caveats of technical attribution, which could be used for further research and analysis by other actors. As no one cybersecurity vendor or any other actor in cyberspace has comprehensive visibility into the threat landscape, closer cooperation among security researchers and cybersecurity companies is necessary for building fact and evidence-based technical attribution as well as public research. Greater dialogue between security researchers, diplomats, and academia is necessary to avoid their ‘worlds’ existing in silos. Furthermore, technical attribution and its nuances need to be better understood and more accessible for both diplomatic negotiations within the bodies like the UN First Committee (which is responsible for dealing with disarmament and international security matters) and evidence-based academic research (which may also inform the former).

An international attribution mechanism could be a solution to greater transparency in, and accessibility of technical attribution in an ideal world. However, the likelihood of this being set up in the near future remains relatively low. The lack of political will of states to tie themselves to formal legal obligations in cyberspace means that an effective information-sharing mechanism resembling that which exists in the Somali piracy context is highly unlikely, at least for the near-term. The UN and International Atomic Energy Agency’s nuclear information-sharing mechanisms further point to the institutional limits of any such international body. A more feasible alternative would be the building of technical ad-hoc groups, or various mini-lateral groupings, following the examples of from the nuclear and space policy realm. Such groups, represented by a diverse security research community and academics, could serve as a technical consultative tool for intergovernmental negotiations taking place within various international fora, such as the UN First Committee. Leadership efforts of a few states, coupled with a global recognition of the danger the lack of information sharing mechanisms creates, is therefore urgently required for any such group to be effectively set up.

Annex: Lessons from past global information-sharing initiatives Information-sharing on Piracy in Somalia

Although it exists in a totally different domain, the case of piracy off the coast of Somalia can give us insights into how information-sharing to tackle a common threat might actually occur.[9] A series of UN Security Council (UNSC) Resolutions have bolstered several informal information-sharing mechanisms, aiming to aid in the direct enforcement of international law and the prosecution of piracy crime. The Contact Group on Piracy off the Coast of Somalia (CGPCS) is one such mechanism. An international forum bringing together more than 60 States and international organisations, the CGPCS meets in plenary sessions and various issue-based working groups to share data and enforce coordination strategies. Piracy-related information-sharing mechanisms have been praised as instrumental in lowering rates of Somali piracy over the past two decades. Why then has this area proven so fertile for functional and effective information-sharing regimes and how might this measure up in the case of technically attributing cyberattacks?

First and foremost, the piracy context enjoys a well-established customary legal practice in international law. The nature of the crime means it is carried out in ‘international waters’, removing jurisdictional conflicts, giving any State the right to seize and penalise pirate ships in high seas. Secondly, the information that is shared among States and organisations for prosecution purposes rarely relies on data protected under the umbrella of ‘national security’. This is not to say that counter-piracy information-sharing mechanisms do not face obstacles. Investigators and prosecutors use similar techniques to cyber attributors of ‘following the money’ and mapping data on group activities and group characteristics. However, unlike in cyber attribution cases, piracy prosecutions centre on relatively unambiguous sets of perpetrators (i.e., Somali pirates), a shared public venue for apprehension activities (i.e., international waters), and less sensitive data required to prosecute piracy (e.g., GPS-based location data, photographs of attacks on vessels). Drawing upon such criteria, technical attribution would therefore require a mechanism to unambiguously identify the sets of perpetrators (i.e., cyberattackers/attack groups), a shared venue that is clearly outlined (i.e., public vs private cyberspace), and data that is both valuable yet falling short of the ‘classified’ threshold. All the above need to be established within the international ‘cyber environment’ via clear and widely-accepted cyber norms. Their relative absence is therefore indicative of the fact that the success of CGPCS and other piracy-related information sharing mechanisms may be difficult to replicate in the cyber context.

Nuclear non-proliferation and space cooperation as possible PPP models

Nuclear non-proliferation, or nuclear weapons disarmament, is another issue of international concern where, like in cyber attribution cases, information sharing is recognisably important yet swarmed with political and security apprehension. The widely ratified Treaty on the Non-Proliferation of Nuclear Weapons (‘NPT’) governs the international efforts to prevent the spread of nuclear weapons and to promote cooperation in the peaceful uses of nuclear energy. Article IV of the Treaty specifically states that parties undertake to facilitate and have the right to participate in the fullest possible exchange of information, with the International Atomic Energy Agency (‘IAEA’) being entrusted with key verification responsibilities under the NPT. Additional Protocols to the IAEA’s Statute have, over the years, improved the Agency’s ability to verify the integrity of information provided by states regarding their nuclear activities. Replicating this system in the cyber context would be difficult primarily because of the lack of a treaty that comprehensively regulates state behaviour in cyberspace.

Indeed, there is little unified political will for any such international agreement in the foreseeable future. Despite the limited powers that the IAEA has over sovereign states, it nonetheless has the authority to conduct inspections, gather data and share information because signatory state parties (to the NPT and IAEA Statue) have willingly given up some of their sovereign rights for these purposes. The existence of the NPT, as a formal source for state obligations, establishes expectations that states can be held to, and provides any mechanisms stemming from it with a degree of authority and political weight. Furthermore, this makes ad-hoc and informal mechanisms in the nuclear context easier to establish and find global support for. The International Partnership for Nuclear Disarmament Verification (IPNDV) is one example of a public-private partnership that brings global actors together to identify and solve technical challenges in monitoring and verifying nuclear disarmament that formal state agreements are not equipped to solve. The fact that states have legal obligations to participate in information sharing means that research opportunities, funding and solutions to information protection issues are also more likely.

The realm of nuclear non-proliferation, where a comprehensive treaty and a slew of associated organisations and bodies support it, is unlike the cyber domain where the quantity of agreements is lower and less comprehensive in terms of issue-area coverage. Yet it is also worth pointing out that the lack of an international treaty does not preclude actors from working together. Initiatives undertaken by just a few states (termed ‘minilaterals’) can lead to the development of good practices, which can be scaled up and tweaked to accommodate additional members. An example of such an initiative is the Space Situational Awareness (‘SSA)’ Sharing Program set up by the US Air Force Space Command in recognition that space situational awareness is critical to avoiding unintentional collisions and detecting and attributing attacks to space assets. Initially, the Program suffered from severe asymmetries of information among the interested parties, with the US Air Force having access to an internal catalogue with detailed information on all tracked objects, while the publicly accessible catalogue contained only basic information on a subset of space assets. Such an approach, justified through national security concerns, showed its limitations in 2009, when a commercial communication satellite and a defunct Russian Cosmos satellite collided without advanced warning to the commercial operators. Through series of multistakeholder agreements in 2019 between the US Strategic Command, 19 states, two international organisations, and more than 77 commercial satellite owners, operators and launchers, data that is of a significantly higher-quality has begun to be shared in a more systematic manner between all parties. Such an outcome can perhaps offer us some insight, not just to the benefits of private-public partnerships (PPP), but how such PPPs can benefit all actors that operate within the realm of both space and/or cybersecurity. The increased frequency and impact of cyberattacks targeted at governmental infrastructure over the past years has to some extent pushed the international community to explore such coordinated responses. Whether or not these events will have a sufficient impact for a coordinated effort like with the SSA remains to be seen.

 

[1] E.g., Estonia has expressed that “attribution remains a national political decision based on technical and legal considerations regarding a certain cyber incident or operation. Attribution will be conducted on a case-by-case basis, and various sources as well as the wider political, security and economic context can be considered”. https://front.un-arm.org/wp-content/uploads/2021/08/A-76-136-EN.pdf

[2] E.g., Germany has expressed that “Attributing a cyber incident is of critical importance as a part of holding States responsible for wrongful behavior and for documenting norm violations in cyberspace.” https://front.un-arm.org/wp-content/uploads/2021/08/A-76-136-EN.pdf

[3] E.g., submissions from some multistakeholders to the 2019-2021 UN OEWG highlight the need for a “multistakeholder approach which engages all relevant stakeholders to build strong, impartial and verifiable verification mechanisms that build trust and confidence” (https://front.un-arm.org/wp-content/uploads/2020/04/cs-coordination-perspectives-on-oewg-pre-draft.pdf) and support to “support multistakeholder, independent and coordinated attribution efforts” (https://front.un-arm.org/wp-content/uploads/2020/04/oewg-pre-draft-gpd-response-final.pdf).

[4] Mueller, M. et al, (2019) ‘Cyber Attribution: Can a New Institution Achieve Transnational Credibility?’, The Cyber Defense Review, 4(1): 107-122; https://css.ethz.ch/content/dam/ethz/special-interest/gess/cis/center-for-securities-studies/pdfs/CSSAnalyse244-EN.pdf.

[5] https://ict4peace.org/wp-content/uploads/2019/08/ICT4Peace-2019-Submission-UN-Open-Ended-Working-Group.pdf; https://front.un-arm.org/wp-content/uploads/2021/02/WILPF_zero-draft_23Feb2021.pdf.

[6] E.g., through signaling their own capabilities and technical advances to adversaries who could use this as an additional advantage.

[7] Ibid, paragraph 22.

[8] UN GGE Report 2021 (n 17), paragraph 27 and 28.

[9] McLaughlin, R. and Paige, T. (2015) ‘The Role of Information sharing in Counter Piracy in the Horn of Africa Region: A Model for Transnational Enforcement Operations’, Journal of International Law and International Relations, 12(1).

2022. június 15.

How much does access to corporate infrastructure cost?

Division of labor

Money has been and remains the main motivator for cybercriminals. The most widespread techniques of monetizing cyberattacks include selling stolen databases, extortion (using ransomware) and carding. However, there is demand on the dark web not only for data obtained through an attack, but also for the data and services necessary to organize one (e.g., to perform specific steps of a multiphase attack). Complex attacks almost invariably feature several phases, such as reconnaissance, initial access to the infrastructure, gaining access to target systems and/or privileges, and the actual malicious acts (data theft, destruction or encryption, etc.). This is just one example of a phased attack where each step can be accomplished by a new contractor – if only because the different steps require different expertise.

Experienced cybercriminals seek to ensure the continuity of their business and constantly need new data for initial access to corporate systems. It’s advantageous for them to pay for prearranged access rather than spend time digging for primary vulnerabilities and penetrating the perimeter.

Screenshot translation

Post
I will buy accounts for access to corporate VPNs or firewalls (FortiGate, SonicWall, PulseSecure, etc.) or take them for further attack development.
I have a small team.
Revenue from 150kk and higher.
Countries: US, CA, AU, GB
Suggest your price in pm, everything is negotiable
Price: 1000 USD
Send offers to private messages

Request for access to corporate VPN. Source: Kaspersky Digital Footprint Intelligence service portal

In contrast, less experienced cybercriminals are not always able to see an attack through to the end (malware execution, data theft, etc.), but are proficient enough to make money by selling initial access. This article deals specifically with this initial access market.

Types of initial access

These are the most common actions used by cybercriminals to obtain initial access to corporate infrastructure in order to develop an attack:

  • Exploitation of software vulnerabilities. For example, attacks on a corporate web resource (exploitation of first-day vulnerabilities across website components, SQL injections, gaining access to vulnerable web app control panels, etc.).
  • Obtaining legitimate corporate credentials. For example, use of data from stealer logs or password mining.
  • Phishing attacks on employees. For example, an email with a malicious payload.

You can learn more about these types of attacks and the specifics of gaining initial access from our analysis report based on data from hundreds of incident investigations.

A special mention should be made of the method for capturing legitimate accounts based on stealers. These malicious programs residing in infected devices collect various account and payment data, cookie files, authorization tokens, etc. that they save to their logs. Cybercriminals scan these logs in search of data they can exploit and monetize: some are looking for credit card data, others for domain accounts, social network accounts, etc. They refer to this stage as processing. After sorting the logs, they either exchange their finds on forums by making them public or sell them to individual buyers.

Screenshot translation

[2TB of logs] I will retrieve data from my databases on your requests
Message
I have my own databases. I can retrieve data you need from my databases.
Suggest your price.
2TB of 2020-2021 data: credentials related to banking accounts and the most popular services. Profit will only be obtained from private service accounts.

Malware log offers on a dark web forum. Source: Digital Footprint Intelligence service

Screenshot translation

Malware logs (different). General topic.
Post
I publish log data of Azor ransomware for free, it could be useful for someone.
Logs contain mixed data from infected devices worldwide.

Free malware log offers on a dark web forum. Source: Digital Footprint Intelligence service

The cybercriminals are literally dealing in gigabytes of logs generated by stealers.

Large volume of logs uploaded to a file exchange service

Screenshot translation

Verified! I will buy information retrieved from your log data (USA) based on my request [MAIL:PASS only required]
Good day!
I will buy information retrieved from your log data (with USA-related data extracted) based on my request.
I buy at least 150 lines, thus, I will not pay if you will send me less lines.
Warning! I buy only user credentials (MAIL:PASS) data from your logs, which match my requirements, I do not need the whole logs
If you do not know how to extract mail:pass data from logs, you can use StealerLogSearcher v1.3
My request:

  • I have Brute/Checker [it does not work fast]
  • I pay only for valid credentials + credit cards data (no matter if credit card is active or not)
  • Your own log data is the priority, I already have 95% of public logs
  • Price is 0.5 USD for valid user account with linked card
  • NO payment for already used accounts (I can see it by log data) | If more than 80% of accounts in the database have already been used, I will NOT PAY FOR PROVIDED LINES AT ALL.
  • I normalize the provided database, remove duplicates and compare with my anti-public database before processing your data via brute/checker
  • I work with everybody on a first-come, first-served basis, if my software is already processing someone’s database – wait
  • I only work with a guarantee or first logs, then payment. Doesn’t matter who you are.
  • I won’t work with you if you act crazy, hurry me, talk rude, cadge, etc.

Screenshot translation

Hi everybody! I am looking for checked (verified) mixed Facebook logs.
The catalog with log data should contain Facebook EAAB (access) token and cookie file, an example is attached.
I need valid logs.
Initially, required value of data is 100-200 samples per week.
Contact me via private messages or Telegram. Thank you for your attention!

Topic on dark web forum with a request for specific malware logs

Main criteria for initial access valuation

Cybercriminals use a set of criteria when describing which company they sell access to on dark web forums: company size, revenue, business area, region and so forth. Yet, from analyzing a lot of posts you could conclude that corporate revenue is the main criterion: almost all posts mention revenue, whereas the region and business area of the target company are advertised much less. Some posts also refer to the level of complexity as a reason for high prices, i.e., how much time and effort the seller spent to gain access. But this is quite a subjective criterion that depends, among other things, on the cybercriminal’s expertise.

Screenshot translation

I sell VPN accounts of USA companies, revenue is 1kkk$
Post
Company is a global organization that provides technologies and services for customers and specializes in design and implementation
Employees: more than 50 000
Revenue: $1 billion
USA
Price: 7 000$
Access type: VPN
Company is a leading provider of web presence solutions for small and mid-sized businesses worldwide.
Employees: 2k+
Revenue: 700kk$
USA
Price: 5 000$
Access type: VPN
We work with guarantees; otherwise, you pay a deposit and I will provide you with access information in advance.
First contact in private messages.

Screenshot translation

[Sale] VPN-RDP accounts for network access
Post
Company is a law firm providing legal support services to clients, assistance in business projects start-up and pre-trial proceedings.
Country: France
Access type: VPN-RDP
Revenue: 8kk+$ (information is current as of 2019)
Access level: Admin
Price: 300$
Company is a private healthcare organization with its own laboratory. It provides wide-ranging medical services.
Country: USA
Access type: VPN-RDP
Revenue: 3kk+$
Access level: Admin
Price: 300$
Company provides a wide range of construction services, including door/window installation. It also has its own production facility.
Country: United Kingdom
Access type: VPN-RDP
Revenue: 2kk+$
Access level: Admin
Price: 200$
Company produces branded clothes.
Country: USA
Access type: VPN-RDP
Revenue: 6kk+$]

Announcements on a dark web forum offering VPN/RDP network access to different organizations

In addition to the target company’s features, the price can also depend on the type of access offered. Information about a vulnerability (e.g., SQL injection) and legitimate credentials (e.g., RDP/SSH) will be priced very differently for companies with comparable revenues, because they offer a different probability of a successful attack. Selling an account to access remote management interfaces (RDP, SSH) means that access to a system in the corporate network infrastructure has already been gained, whereas a vulnerability merely offers the chance to achieve a similar level of access. Even when it comes to the same issue, such as an SQL injection, there are many factors affecting the potential development of the attack (vulnerable host location (e.g., corporate network or cloud server), what DBMS is used, the intended vulnerability exploitation technique, database volume, etc.) and, therefore, its cost.

Cost of initial access

To find out how these criteria influence the cost of access, we analyzed about 200 posts published on two popular dark web forums. We identified a set of relevant parameters for each one:

  • Corporate revenue
  • Type of access
  • Price of data
  • Company info (region, business area, etc.)

That done, we screened out from our selection the irrelevant posts – those not stating revenue or the price of network access data. This reduced the total number to 117 posts.

The following diagram shows the correlation between lot price and revenue without considering the technical factors:

The correlation between the price of network access data and a company’s revenue (download)

As you can see:

  • Most offers fall within the $0–$5,000 price range
  • Most offers refer to moderately sized companies
  • Average price of access data (depicted as a trend line) is between several hundred and five thousand dollars, and grows as revenue increases

Some of the major deviations from the price range can be explained by lot characteristics, such as business area specifics. For instance, network access data for a company specializing in POS terminals and providing internet acquiring services is valued much higher ($20,000) than other similar offers. The price may also be increased by “bonuses” attached to the lot, such as an already compromised database containing email addresses or other sensitive or confidential data sold in the same package along with the access. The buyer can either process these later or use and resell them separately.

If we take a closer look at the price distribution across the whole body of offers, almost half of them (42.74%) are under $1,000.

Offers grouped by price category (download)

If analyzed in terms of access type, most posts offer RDP access or a VPN + RDP bundle (75.21% of lots). In the diagram below both of these options belong to the categories “RDP access (without details)”, “RDP access (local admin)”, “RDP access (domain admin)” and “RDP access (user)”.

Offers grouped by access type (download)

To get a clearer picture of the connection between lot price and corporate revenue, we analyzed the posts offering data for RDP access – the most common access category and most uniform pricewise – for large businesses with revenue of over $500 million. The following diagram shows how revenue affects the cost of data for RDP access.

The correlation between RDP access cost and large company revenue (download)

This diagram doesn’t demonstrate a direct correlation between access cost and corporate income. However, the selection is quite small, meaning the disproportionate influence of variable access properties (user privileges, a company’s country/region/industry) could skew any remotely objective conclusions based on quantitative analysis.

One way or another, access to large business infrastructure usually costs between $2,000 and $4,000, which are relatively modest prices. But there is no upper limit to the cost either. For example, in the topic below the original lot price was $50,000 (the lot also covered a number of sub-companies). And even though the price was later halved by the seller, one of the thread members called the offer overpriced.

Screenshot translation

Hi, I offer VPN-RDP access
There is access data to 2-3 domains of that network, the total number is 3-4, I don’t know exactly, see the screenshot below for DNS servers!
Country: Australia
The company sells goods, not foodstuffs etc., but garments etc.! more in pm!
Revenues differ, 465 million for the main company only, and there is access to their networks, there is also an account with their domain, I could not get access to the domain itself so far! but if you try you can gain access to all domains in their different networks!
Respond only if ready to buy, preferably with a big deposit
Price: $50k not much for several companies with resources on one network. There are lots of RDP interfaces, RDP is closed on some servers, but it can still be opened easily using PSexec or using your own method!
not in a hurry to sell. every network has its own network access servers, I think some of them were accessible, there is lots of data for processing with a good chance of a successful outcome! The country is not poor, so if an attack is conducted well, the payoff will be substantial!
Updating my post, I have taken 4 Domain Admins, let me make it clear for the dumb ones out there, 4 Domain Admins means different accounts for different ADs. for example, there is a network XXXX with several AD services each with user accounts of its own, there is also another XXXX network also with several ADs and accounts of its own, well, I have access to each AD from the different networks, you will be able to compromise networks of 4-5 different companies in one go, all these companies belong to 1 head company, and four subsidiaries are on the same VPN network, and they are all interconnected, each network has an internet adapter of its own, as I said before, respond only if ready to buy, preferably with a big deposit!

Sale of data for remote access to five companies in one network for $50,000

Screenshot translation

If you buy today I will cut the price down to $25K
Warning from moderator: work strictly through guarantee

Price reduced from $50,000 to $25,000

Screenshot translation

You seem to have no clue what access is and what its price is, nobody will buy it even for 3K, 95% probability

Comment about the offer being overpriced

Screenshot translation

Your message is funny, I saw people selling access for $100K, I saw people getting many times more than they had paid, this is what buying access is all about, if you buy access for ransomware and process it properly, and if you get paid around $200K which is nothing for companies like that, you get huge profit, I’m not mentioning people charging $1mn and more, if you are not happy about something keep your comments to yourself, do not litter the thread!

Response to comment about the offer being overpriced

Screenshot translation

2 minutes ago Eastfarmer said:
I can’t stop laughing, don’t you mind the disgrace, what is it I don’t know about ransomware? are you the person who enters, checks nothing and encrypts the first random machines? $1k? go ahead and tell me why it should cost $1k. is it just one company with 20 computers and revenue of 10 mn? don’t be stupid man. I am telling you again there are 5 companies, they are all subsidiaries of a head company, a subsidiary has $465mn revenue, others a bit less. Australians?)))))) you mean Australians are poor? do they have a poor economy? man, people pay huge money even for African companies. What are you trying to tell me, a friend of mine pocketed $200k from a company with $15mn revenue. It was Estonia, or maybe you are a friend and supporter of the first two dudes or just a windbag? I really don’t get it what are you trying to make of it, if they don’t buy it so be it, why this pointless flood? can’t you just pass it by? mind your own business
I didn’t say a word about you being a poor pentester. I said you are poor ransomwarer at least because you have not conducted the attack yourself)) do you understand the difference, nobody insulted you as a specialist, if you took offence I am sorry. I will not write to your thread any more

Discussion continuation. Source: Digital Footprint Intelligence service

Here is another example of a high price being asked for data belonging to a company with a revenue of $500 million. The asking price is 12 BTC.

Screenshot translation

Australia
Revenue: > $500 million+
There is access to a network, admin-level access, direct connection to SSH servers, access to backups.
Price: 12 BTC
All questions in pm

Lot price 12 BTC

Interestingly, gaining access to corporate networks is in high demand, with some lots selling the same day they are published.

Access data sold on the day of publication

Access data sold a few days after publication

Ransomware auctions: stolen data pricing

Undoubtedly, one of the most important components of the initial access price is the amount of money the buyer can potentially earn from an attack conducted using that access. Cybercriminals are ready to pay thousands or even tens of thousands of dollars for the opportunity to infiltrate a corporate network for a reason. Successful attacks pay off very nicely. Ransomware attacks are a prime example. In attacks like that malware usually encrypts a significant amount of data on workstations or servers, virtually paralyzing the company’s operations or causing material risks to its business processes. Once encryption is accomplished, the attackers contact the victim with an offer to buy decryption keys. These often cost millions of dollars. For example, according to media reports, a European travel agency dished out $4.5 million, and a large American insurer a whopping $40 million in ransom money.

Of late, cybercriminals have tended not only to encrypt but also steal corporate data. They may later post some of the stolen data in their blogs – primarily as proof but also as extra leverage –threatening to publish more unless the company pays them the money they demand within the stipulated timeframe.

Different ransomware groups follow different approaches to publishing stolen data.

  • Some of them publish information about the incident (along with the data) only if no agreement is reached with the victim.
  • Some publicize the incident immediately after the attack and state exactly when they plan to begin disclosing critical data.
  • Some set up an auction in which the stolen data will go to whoever is willing to pay the highest price (presumably a single buyer). In this latter case, the auction price of a lot – though smaller than the ransom charged for data decryption – can still be several times more than the price of access to the corporate system.

If we take a look at posts offering stolen data to a single buyer, the lot price normally starts in the tens of thousands of dollars, often reaching sums of around a million.

Blackmailer blog: auction price of stolen data

Blackmailer blog: auction price of stolen data along with published data

Blackmailer blog: auction closed (stolen data sold to a single buyer)

Blackmailer blog: active auction

Blackmailer blog: stolen data published in parts (one part at a time)

Blackmailer blog: data on Charlie Hebdo terrorist attack stolen from a legal firm are available for $1 million

Blackmailer blog: attackers announce the publication of stolen data after they failed to negotiate with the victim company

Blackmailer blog: attackers announce they are waiting for the ransom (1 day and 11 hours left before the publication of stolen data)

Blackmailer blog: the attackers published the stolen data because the ransom was not paid

Conclusion

Demand for corporate data on the black market is high, and it doesn’t always involve targeted attacks. Attackers may gain access to the infrastructure of a random company to sell it to blackmailers or other advanced cybercriminals later. An attack like that can affect a company of any size, big or small, because corporate system access is often priced moderately on underground forums, especially compared to the potential damage to a business.

Sellers on the dark web most often offer remote access via RDP. To protect corporate infrastructure from attacks through remote access and control services, make sure the connection via this protocol is secure by:

 

[1] For details of the service and test access, please contact us at intelligence@kaspersky.com

2022. június 8.

Router security in 2021

A router is a gateway from the internet to a home or office —  despite being conceived quite the opposite. Routers are forever being hacked and infected, and used to infiltrate local networks. Keeping this gate locked so that no one can stroll right through is no easy task. It is not always clear just how this locking works, especially when it comes to home routers, whose users are by no means all security pros. What’s more, it’s not uncommon for routers to be full of holes.

Since the start of the pandemic, however, router security has received more attention. Many companies introduced remote working for employees, some of whom never returned to the office. If before the pandemic few people worked from home, now their number is significant. As a result, cybercriminals now see home routers as gateways to corporate networks, and companies as potential attack vectors. Proof of the heightened attention in network devices comes from the sharp rise in the number of vulnerabilities found in them in recent years.

Router vulnerabilities

According to cve.mitre.org, the number of vulnerabilities discovered in various routers, from mobile to industrial, has grown over the past decade. However, with the mass shift to remote working, it went off the scale. During 2020 and 2021, more than 500 router vulnerabilities were found.

Number of router vulnerabilities according to cve.mitre.org, 2010–2022 (download)

The nvd.nist.gov website presents different figures, but they too show a significant increase in the number of router vulnerabilities found in 2020 and 2021.

Number of router vulnerabilities according to nvd.nist.gov, 2010–2022 (download)

Analyzing the nvd.nist.gov data on router vulnerabilities, we calculated that 18% were critical, and more than half (53.5%) were high-priority.

Distribution of router vulnerabilities by priority, 2021 (download)

Critical vulnerabilities are the very holes in the gateway through which an intruder can penetrate a home or corporate network. They make the router much easier to hack, which gives the opportunity to get round password protection features (such as CAPTCHA or a limited number of login attempts), run third-party code, bypass authentication, send remote commands to the router or even disable it. In early 2022, for instance, a security researcher effectively cut off the whole North Korea from the internet by exploiting unpatched vulnerabilities in critical routers and other network equipment.

Unfortunately, not all vendors are rushing to fix even critical vulnerabilities. At the time of writing, of the 87 critical vulnerabilities published in 2021, more than a quarter (29.9%) remain unpatched and unreported by the vendor:

Router manufacturers’ response to vulnerabilities found in their products in 2021 (download)

Note the third column in the diagram: 26% of all critical router vulnerabilities published in 2021 received a vendor advisory. These advisories do not always come with a full-fledged patch. In some cases, they only recommend owners of vulnerable devices to contact support.

Moreover, whereas employees have more or less got to grips with protecting laptops, desktop computers and even mobile devices, they may not know what to do, if anything, with routers. According to a survey by UK company Broadband Genie, 48% of users had not changed any of their router’s settings at all, even the control panel and Wi-Fi network passwords. 73% of them just see no reason to go into the settings, and 20% do not know how to do it.  That said, the situation with router security is gradually improving: if a Shodan.io search for smart devices with the default password in the summer of last year revealed more than 27,000 hits, a similar search in April 2022 returned only 851. Moreover, most of these routers had the name HACKED-ROUTER-HELP-SOS-DEFAULT-PASSWORD, indicating they had already been compromised.

Shodan.io search results for “default password” in June 2021

Shodan.io search results for “default password” in April 2022

These results are most likely due to the fact that many vendors started creating unique, random passwords for each individual device, instead of a standard default password for all of them, available to anyone.

Router-targeting malware

To find out why cybercriminals attack routers, it is first worth looking at the Top 10 malware detected by our IoT traps in 2021.

Verdict %* 1 Backdoor.Linux.Mirai.b 48.25 2 Trojan-Downloader.Linux.NyaDrop.b 13.57 3 Backdoor.Linux.Mirai.ba 6.54 4 Backdoor.Linux.Gafgyt.a 5.51 5 Backdoor.Linux.Agent.bc 4.48 6 Trojan-Downloader.Shell.Agent.p 2.54 7 Backdoor.Linux.Gafgyt.bj 1.85 8 Backdoor.Linux.Mirai.a 1.81 9 Backdoor.Linux.Mirai.cw 1.51 10 Trojan-Downloader.Shell.Agent.bc 1.36

* Attacks by this malware as a percentage of all attacks on Kaspersky IoT honeypots in 2021

As the table shows, around a half of all verdicts belong to the Mirai family. Discovered back in 2016, it remains the most common malware infecting IoT devices. This botnet of routers, smart cameras and other connected devices is the most persistent there is, since infected devices cannot be cured by any protective technologies, and users often do not notice that something is wrong.

The Mirai botnet was originally designed for large-scale DDoS attacks on Minecraft servers, and was later employed to attack other resources. After its source code was published, all and sundry began to distribute it and conduct DDoS attacks using Mirai-infected devices.

Mirai is not the only DDoS malware to target routers. In September 2021, the Russian companies Yandex, Sber and others were subjected to the largest DDoS attack ever observed using a new botnet of MikroTik routers. Researchers named the botnet Meris. It is believed to consist of 200–250 thousand devices infected with the new malware.

Thus, one of the main goals of attacking routers is to recruit them into botnets to carry out large-scale DDoS attacks.

But we should not forget the main function of a router: to act as a gateway to the internet from a local network. Cybercriminals can hack into routers to get into a user’s or company’s network.

But we should not forget the main function of a router: to act as a gateway to the internet from a local network. Cybercriminals can hack into routers to get into a user’s or company’s network. Such attacks can be smaller in scale than creating DDoS botnets, for which reason they are not listed in the most common threats to routers. That said, they are far more dangerous for companies than Mirai.

For example, there have been reports about attacks by the Sandworm APT group on small office/home office (SOHO) network devices. The cybercriminals infected WatchGuard and Asus devices with the Cyclops Blink malware. Although we cannot say for sure what they intended to do next, this malware persists in the firmware even after a factory reset and gives attackers remote access to compromised networks.

Conclusion

The growing interest in router security in recent years stems largely from the belief that protecting a router is a task beyond the grasp of ordinary users. At the same time, remote working allows intruders to penetrate a company’s infrastructure by exploiting a security hole in an employee’s home network. It’s a mouth-watering prospect for attackers, but companies are not blind to the threat.

If you want to secure your home router or develop security guidelines for remote employees, we advise the following:

  • Change the default password to one that is strong (i.e. long and complex). There is no shame in writing down the password for your home router — it is rarely used and physical access to the router is restricted to a small circle of individuals.
  • Use proper encryption. As of today, that means WPA2.
  • Disable remote access. To do so, simply find this setting in the interface and uncheck Remote Access. If remote access is needed after all, disable it when not in use.
  • Make sure to update the firmware. Before purchasing a router, make sure that the vendor issues firmware updates on the regular basis and install them promptly on the device.
  • For extra security, use a static IP address and turn off DHCP, as well as protect Wi-Fi with MAC filtering. All this will make the process longer and more complicated, as you will need to set up any additional device connections manually. But it will be far harder for an intruder to get into the local network.
2022. június 6.

CVE-2022-30190 (Follina) vulnerability in MSDT: description and counteraction

At the end of May, researchers from the nao_sec team reported a new zero-day vulnerability in Microsoft Support Diagnostic Tool (MSDT) that can be exploited using Microsoft Office documents. It allowed attackers to remotely execute code on Windows systems, while the victim could not even open the document containing the exploit, or open it in Protected Mode. The vulnerability, which the researchers dubbed Follina, later received the identifier CVE-2022-30190.

CVE-2022-30190 technical details

Briefly, the exploitation of the CVE-2022-30190 vulnerability can be described as follows. The attacker creates an MS Office document with a link to an external malicious OLE object (word/_rels/document.xml.rels), such as an HTML file located on a remote server. The data used to describe the link is placed in the tag with attributes Type=”http://schemas.openxmlformats.org/officeDocument/2006/relationships/oleObject”, Target=”http_malicious_link!”. The link in the Target attribute points to the above-mentioned HTML file, inside which a malicious script is written using a special URI scheme.
When opened, the attacker-created document runs MSDT. The attacker can then pass, through a set of parameters, any command to this tool for execution on the victim’s system with the privileges of the user who opened the document. What is more, the command can be passed even if the document is opened in Protected Mode and macros are disabled.
At the time of posting, two document formats were known to allow CVE-2022-30190 exploitation: Microsoft Word (.docx) and Rich Text Format (.rtf). The latter is more dangerous for the potential victim because it allows execution of a malicious command even without opening the document — just previewing it in Windows Explorer is enough.

Protecting against Follina

Kaspersky is aware of attempts to exploit the CVE-2022-30190 vulnerability through Microsoft Office documents. Our solutions protect against this using the Behavior Detection and Exploit Prevention tools.
The following verdict names are possible:

  • PDM:Exploit.Win32.Generic
  • HEUR:Exploit.MSOffice.Agent.n
  • HEUR:Exploit.MSOffice.Agent.gen
  • HEUR:Exploit.MSOffice.CVE-2017-0199.a
  • HEUR:Exploit.MSOffice.CVE-2021-40444.a
  • HEUR:Exploit.MSOffice.Generic

Geography of Follina exploitation attempts with Exploit.MSOffice.CVE-2021-40444.a verdict, May 1 – June 3, 2022 (download)

We expect to see more Follina exploitation attempts to gain access to corporate resources, including for ransomware attacks and data breaches. Therefore, we continue to closely monitor the situation and improve overall vulnerability detection. In addition, as part of the Managed Detection and Response service, our SOC experts can detect vulnerability exploitation, investigate attacks and provide clients with all necessary threat-related information.
To protect against Follina exploitation, we strongly advise that you follow Microsoft’s own guidelines: Guidance for CVE-2022-30190 Microsoft Support Diagnostic Tool Vulnerability. In particular, to prevent exploitation of this vulnerability, you can disable support for the MSDT URL protocol by taking these steps:

  1. Run Command Prompt as Administrator.
  2. To back up the registry key, execute the command “reg export HKEY_CLASSES_ROOT\ms-msdt filename”
  3. Execute the command “reg delete HKEY_CLASSES_ROOT\ms-msdt /f”.
2022. június 2.

WinDealer dealing on the side

Introduction

LuoYu is a lesser-known threat actor that has been active since 2008. It primarily goes after targets located in China, such as foreign diplomatic organizations established in the country, members of the academic community, or companies from the defense, logistics and telecommunications sectors. In their initial disclosures on this threat actor, TeamT5 identified three malware families: SpyDealer, Demsty and WinDealer. The actor behind these families is capable of targeting Windows, Linux and macOS machines, as well as Android devices.

In previous years, Kaspersky investigated LuoYu’s activities and was able to confirm the connection between Demsty and WinDealer. On January 27, we delivered a joint presentation with TeamT5 and ITOCHU Corporation at Japan Security Analyst Conference (JSAC) to provide an update on the actor’s latest activities. In this article, we will focus on one of the most groundbreaking developments: the fact that LuoYu has the ability to perform man-on-the-side attacks.

Delivery method

In the past, LuoYu used watering-hole attacks (for instance, on local news websites) to infect their targets. Seeing that some variants of their Android malware impersonate a popular messaging app in Asia, it is also likely that malicious APKs are distributed in a variety of ways, including social engineering to convince users to install fake updates for their applications.

In 2020, we discovered a whole new distribution method for the WinDealer malware that leverages the automatic update mechanism of select legitimate applications. In one case we investigated, we noticed that a signed executable qgametool.exe (MD5 f756083b62ba45dcc6a4d2d2727780e4), compiled in 2012, deployed WinDealer on a target machine. This program contains a hardcoded URL that it uses to check for updates, as shown in the following screenshot:

Update URL hardcoded in qgametool.exe

The executable located at this URL (hxxp://download.pplive[.]com/PPTV(pplive)_forap_1084_9993.exe, MD5 270902c6bb6844dc25ffaec801393245) is benign, but our telemetry shows that on rare occasions, a WinDealer sample (MD5 ce65092fe9959cc0ee5a8408987e3cd4) is delivered instead.

Observed WinDealer infection flow

We also identified online message board posts where Chinese-speaking users reported the discovery of malware under the same name – PPTV(pplive)_forap_1084_9993.exe – on their machine. The posted information was complete enough for us to confirm that they had indeed received a sample of WinDealer.
Leaving the mystery of the delivery method aside for now, let’s look at the capabilities of the malware itself.

WinDealer’s technical description

WinDealer is a modular malware platform. It starts execution by locating an embedded DLL file placed in its resources by looking for a hardcoded pattern, and proceeds to decode it using a 10-byte XOR key.

Layout of the encrypted data

WinDealer’s logic is spread over the initial EXE and its companion DLL: the former contains the setup of the program as well as network communications, while the orders sent by the C2 are implemented in the latter. The malware possesses the following capabilities:

  • File and file system manipulation: reading, writing and deleting files, listing directories, obtaining disk information;
  • Information gathering: collecting hardware details, network configuration and/or keyboard layout, listing running processes, installed applications and configuration files of popular messaging applications (Skype, QQ, WeChat and Wangwang);
  • Download and upload of arbitrary files;
  • Arbitrary command execution;
  • System-wide search across text files and Microsoft Word documents;
  • Screenshot capture;
  • Network discovery via ping scan;
  • Backdoor maintenance: set up or remove persistence (via the registry’s RUN key), configuration updates.

A variant we discovered (MD5 26064e65a7e6ce620b0ff7b4951cf340) also featured the ability to list available Wi-Fi networks. Overall, WinDealer is able to collect an impressive amount of information, even when compared to other malware families. And yet, the most extraordinary aspect of WinDealer lies elsewhere.

The impossible infrastructure

The latest WinDealer sample we discovered in 2020 doesn’t contain a hardcoded C2 server but instead relies on a complex IP generation algorithm to determine which machine to contact. The details of this algorithm are left as an exercise to the reader, but the end result is that the IP address is selected at random from one of these two ranges:

  • 113.62.0.0/15 (AS4134, CHINANET XIZANG PROVINCE NETWORK)
  • 111.120.0.0/14 (AS4134, CHINANET GUIZHOU PROVINCE NETWORK)

Once the IP address has been selected, communications take place either over UDP port 6999 or TCP port 55556. In an even weirder twist, a research partner shared with us an additional WinDealer sample (MD5 d9a6725b6a2b38f96974518ec9e361ab) that communicates with the hardcoded URL “http://www[.]microsoftcom/status/getsign.asp”. This domain is obviously invalid and cannot resolve to anything in normal circumstances – yet the malware expects a response in a predetermined format (“\x11\x22\x??\x33\x44”).

Packets exchanged with the C2 server contain a header (described in the next table) followed by AES-encrypted data. They leverage a homemade binary protocol containing magic numbers and flags, making it easy to recognize and filter packets on a large scale.

Offset

Description

Sample value (in hex)

0x00 Magic number 06 81 DA 91 CE C7 9F 43 0x08 Target identifier 57 5B 73 B2 0x0C Flag set by the attacker. Its exact meaning remains unclear 00 or 0B or 16 0x0D Connection type or backdoor command identifier
0 = initial connection
1 = subsequent connection
Others = backdoor command identifiers 00 0x0E Unknown static value 14 0x0F Unknown value 00 0x10 Payload
Initial connection: the generated AES key and its CRC32, encrypted using RSA-2048 with a hardcoded public key.
All other packets: payload size followed by encrypted payload using AES-128 in ECB mode with the generated AES key. 03 4D 5D 44 C3 1E 0A DA
A3 4A 86 A3 CC ED 67 38
… The man-on-the-side attack

Putting all the pieces together, WinDealer’s infrastructure is nothing short of extraordinary:

  • It appears to be distributed via plain HTTP requests that normally return legitimate executables.
  • It communicates with IP addresses selected randomly inside a specific AS.
  • It can interact with non-existent domain names.

It is very hard to believe that an attacker would be able to control the 48,000 IP addresses of the aforementioned IP ranges, or even a significant portion of them. The only way to explain these seemingly impossible network behaviors is by assuming the existence of a man-on-the-side attacker who is able to intercept all network traffic and even modify it if needed.

Such capabilities are not unheard of: the QUANTUM program revealed in 2014 was the first known instance. The general idea is that when the attacker sees a request for a specific resource on the network, it tries to reply to the target faster than the legitimate server. If the attacker wins the “race”, the target machine will use the attacker-supplied data instead of the normal data. This is consistent with the scenario described earlier in this article, where the target receives an infected executable instead of the normal one. Automatic updaters are prime targets for such attacks as they perform frequent requests – it doesn’t matter if the attackers don’t win most races, as they can try again until they succeed, guaranteeing that they will infect their targets eventually. This class of attack is particularly devastating because there is nothing users can do to protect themselves, apart from routing traffic through another network. This can be done with the use of a VPN, but these may be illegal depending on the jurisdiction and would typically not be available to Chinese-speaking targets.

Confirming our assessment, we later discovered a downloader utility (MD5 4e07a477039b37790f7a8e976024eb66) that uses the same unique user-agent as WinDealer samples we analyzed (“BBB”), tying it weakly to LuoYu.

A downloader utility and WinDealer of 2021 use the unique user-agent “BBB”

The downloader periodically retrieves and runs an executable from hxxp://www.baidu[.]com/status/windowsupdatedmq.exe. This URL normally returns a 404 error and we consider it extremely unlikely that the attackers have control over this domain.

Based on all the evidence laid out above, we speculate that the attackers may have the following capabilities over AS4134:

  • Intercepting all network traffic, which allows them to receive backdoor responses to random IP addresses without having to deploy actual C2 servers.
  • Injecting arbitrary TCP and UDP packets on the network, a capability through which they can send orders to WinDealer.
  • Full control over the DNS, meaning they can provide responses for non-existent domains.
  • Either QUANTUMINSERT capabilities or the ability to modify the contents of HTTP packets on the fly, thanks to which they can achieve remote, zero-click malware installation by abusing auto-update mechanisms. One noteworthy observation is that the attackers specifically target plain HTTP sessions, indicating that they may not have the ability to break or downgrade HTTPS.
WinDealer’s targets

Our analysis of WinDealer reveals that it specifically looks for popular applications in Asia, such as QQ, WeChat and WangWang. It also contains references to registry keys created by Sogou programs. This indicates to us that the LuoYu APT is predominantly focused on Chinese-speaking targets and organizations related to China. Our telemetry confirms that the vast majority of LuoYu targets are located in China, with occasional infections in other countries such as Germany, Austria, the United States, Czech Republic, Russia and India.

In recent months, LuoYu has started to widen its scope to companies and users in East Asia and their branches located in China.

Geographic distribution of WinDealer targets

Conclusion

With this report, we recognize LuoYu as an extremely sophisticated threat actor able to leverage capabilities available only to the most mature attackers. We can only speculate as to how they were able to obtain such capabilities. They could have compromised routers on the route to (or inside) AS4134. Alternatively, they may use signals intelligence methods unknown to the general public. They may even have access (legitimate or fraudulent) to law enforcement tools set up at the ISP level and are abusing them to perform offensive operations. Overall, a threat actor is leveraging capabilities that could be compared (but are distinct) from the QUANTUMINSERT program in order to infect targets located in China.

Man-on-the-side attacks are devastating because they do not require any interaction with the target to lead to a successful infection: simply having a machine connected to the internet is enough. They can only be detected through careful network monitoring, which is outside of the realm of everyday users, or if an endpoint security program catches the payload when it is deployed on the attacked computer.

Whatever the case, the only way for potential targets to defend against such intrusions is to remain extremely vigilant and have robust security procedures involving regular antivirus scans, analysis of outbound network traffic and extensive logging to detect anomalies.

Indicators of Compromise

WinDealer samples

MD5: ce65092fe9959cc0ee5a8408987e3cd4
SHA-1: 87635d7632568c98c0091d4a53680fd920096327
SHA-256: 27c51026b89c124a002589c24cd99a0c116afd73c4dc37f013791f757ced7b7e

MD5: 0c8663bf912ef4d69a1473597925feeb
SHA-1: 78294dfc4874b54c870b8daf7c43cfb5d8c211d0
SHA-256: db034aeb3c72b75d955c02458ba2991c99033ada444ebed4e2a1ed4c9326c400

MD5: 1bd4911ea9eba86f7745f2c1a45bc01b
SHA-1: f64c63f6e17f082ea254f0e56a69b389e35857fd
SHA-256: 25cbfb26265889754ccc5598bf5f21885e50792ca0686e3ff3029b7dc4452f4d

MD5: 5a7a90ceb6e7137c753d8de226fc7947
SHA-1: 204a603c409e559b65c35208200a169a232da94c
SHA-256: 1e9fc7f32bd5522dd0222932eb9f1d8bd0a2e132c7b46cfcc622ad97831e6128

MD5: 73695fc3868f541995b3d1cc4dfc1350
SHA-1: 158c7382c88e10ab0208c9a3c72d5f579b614947
SHA-256: ea4561607c00687ea82b3365de26959f1adb98b6a9ba64fa6d47a6c19f22daa4

MD5: 76ba5272a17fdab7521ea21a57d23591
SHA-1: 6b831413932a394bd9fb25e2bbdc06533821378c
SHA-256: ecd001aeb6bcbafb3e2fda74d76eea3c0ddad4e6e7ff1f43cd7709d4b4580261

MD5: 8410893f1f88c5d9ab327bc139ff295d
SHA-1: 64a1785683858d8b6f4e7e2b2fac213fb752bae0
SHA-256: 318c431c56252f9421c755c281db7bd99dc1efa28c44a8d6db4708289725c318

MD5: cc7207f09a6fe41c71626ad4d3f127ce
SHA-1: 84e749c37978f9387e16fab29c7b1b291be93a63
SHA-256: 28df5c75a2f78120ff96d4a72a3c23cee97c9b46c96410cf591af38cb4aed0fa

MD5: e01b393e8897ed116ba9e0e87a4b1da1
SHA-1: 313b231491408bd107cecf0207868336f26d79ba
SHA-256: 4a9b37ca2f90bfa90b0b8db8cc80fe01d154ba88e3bc25b00a7f8ff6c509a76f

MD5: ef25d934d12684b371a17c76daf3662c
SHA-1: b062773bdd9f8433cbd6e7642226221972ecd4e1
SHA-256: 08530e8280a93b8a1d51c20647e6be73795ef161e3b16e22e5e23d88ead4e226

MD5: faa8eaed63c4e9f212ef81e2365dd9e8
SHA-1: 0d3a5725b6f740929b51f9a8611b4f843e2e07b1
SHA-256: b9f526eea625eec1ddab25a0fc9bd847f37c9189750499c446471b7a52204d5a

2022. május 27.

IT threat evolution in Q1 2022. Mobile 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 Q1 2022:

  • 6,463,414 mobile malware, adware and riskware attacks were blocked.
  • The largest share of all detected mobile threats accrued to RiskTool programs — 48.75%.
  • 516,617 malicious installation packages were detected, of which:
    • 53,947 packages were related to mobile banking trojans,
    • and 1,942 packages were mobile ransomware trojans.
Quarterly highlights

In Q1 2022, the level of activity among cybercriminals remained roughly the same as it was at the end of 2021 when comparing the number of attacks on mobile devices. But in general, the number of attacks is still on a downward trend.

Number of attacks targeting users of Kaspersky mobile solutions, Q1 2020 — Q1 2022 (download)

What makes this quarter interesting is that many different fraudulent apps are distributed via official app stores. It’s not uncommon for apps published in the store to be accompanied by inflated ratings with fake reviews posted on the page for the app which are of course all positive. These types of apps occupy seven out of the twenty places in our malware ranking for Q1.

One of the schemes used by scammers which has been becoming more popular since last year are scam apps for receiving social benefits. The mobile apps redirect to a webpage where users are prompted to enter personal data and shown a large sum of money they’re supposedly entitled to. In order to claim their benefits however, users are told they need to pay a commission to cover the transfer cost or legal assistance. Once the money has been transferred, the app’s objective is considered achieved, and the user receives nothing in return.

Scam apps targeting Russian-speaking users

Another common scheme deployed by scammers are fraudulent trading apps which grant access to an investment platform for certain gas stocks. The app brings the user to a fake website where you can “raise your investment capital”. Needless to say, all the money invested is sent straight to the cybercriminals.

 

Other types of fraudulent apps begin charging a hefty weekly subscription fee a few days after the app is installed or even sign the user up for premium SMS subscriptions.

Keto diet app for meal planning which deducts money from the user’s bankcard without receiving prior consent

Other finds which stood out this quarter were various apps for taking out payday loans targeting users in Mexico and India. In our system of classification, these apps belong to a family of potentially unwanted software called RiskTool.AndroidOS.SpyLoan, which request access to user’s text messages, contacts list and photos. If a payment is late, debt collectors can begin calling people from the user’s contacts list or blackmail the user by threatening to disclose their personal information.

We observed a similar case in Brazil, where people were encouraged to install an app to take out payday loans which locks users out of their phones if they miss a payment.

Mobile threat statistics

In Q1 2022, Kaspersky detected 516,617 malicious installation packages, which is 79,448 fewer than the previous quarter and down 935,043 against Q1 2021.

Number of detected malicious installation packages, Q1 2021 — Q1 2022 (download)

Distribution of detected mobile malware by type

Distribution of newly detected mobile malware by type, Q4 2021 and Q1 2022 (download)

Almost half of all threats detected in Q1 2022 were potentially unwanted RiskTool apps (48.75%), which is a reduction of 3.21 p.p. compared to the previous quarter. Most apps detected in this category belonged to the traditionally dominant SMSreg family (61.37%).

Adware apps came second (16.92%), which also saw a decrease of 10.01 p.p. The worst offenders belonged to the Ewind family (28.89%), which were encountered more frequently than any other adware we detected. It’s followed by Adlo (19.84%) and HiddenAd (12.46%) families.

Third place was taken by various trojans whose share increased by 10.32 p.p. to 14.68%. The trojan families that had the greatest impact were Mobtes (44.35%), Piom (32.61%) and Boogr (14.32%).

Top 20 mobile malware programs

Note that the malware rankings below exclude riskware or PUAs, such as RiskTool or adware.

Verdict %* 1 DangerousObject.Multi.Generic 20.45 2 Trojan.AndroidOS.Fakemoney.d 10.73 3 Trojan-SMS.AndroidOS.Fakeapp.d 7.82 4 Trojan-SMS.AndroidOS.Fakeapp.c 5.36 5 Trojan-Spy.AndroidOS.Agent.aas 4.93 6 Trojan.AndroidOS.Fakeapp.ed 4.45 7 Trojan.AndroidOS.Fakemoney.g 3.28 8 Trojan-Dropper.AndroidOS.Agent.sl 2.94 9 DangerousObject.AndroidOS.GenericML 2.55 10 Trojan.AndroidOS.Fakeapp.dw 2.40 11 Trojan-Ransom.AndroidOS.Pigetrl.a 2.14 12 Trojan.AndroidOS.Soceng.f 2.14 13 Trojan.AndroidOS.Fakemoney.i 2.13 14 Trojan-Downloader.AndroidOS.Agent.kx 1.63 15 Trojan-SMS.AndroidOS.Agent.ado 1.62 16 Trojan.AndroidOS.Fakeapp.ea 1.55 17 Trojan-Downloader.AndroidOS.Necro.d 1.47 18 Trojan-Dropper.AndroidOS.Hqwar.gen 1.36 19 Trojan.AndroidOS.GriftHorse.l 1.26 20 SMS-Flooder.AndroidOS.Dabom.c 1.19

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

The malware rating for Q1 2022 featured many new arrivals, which we discussed in the quarterly-highlights section. But let’s go back to the top of the ranking. First place was defended by the traditional title-holder DangerousObject.Multi.Generic (20.45%), which is a verdict we use to describe malware detected using cloud technology. The trojan identified as Trojan.AndroidOS.Fakemoney.d (10.73%) moved up from third to second place. Other members of this family have also occupied seventh and thirteenth place in the rating. These are fraudulent apps that invite users to fill out a fake application for social benefits. The majority of users targeted in these attacks live in Russia, Kazakhstan and Ukraine.

The trojans in third and fourth place (7.82% and 5.36%) are members of the Trojan-SMS.AndroidOS.Fakeapp family. This type of malware is able to send text messages and call specified numbers, display ads and hide its icon on the device. Fifth place is taken by a trojan referred to as Trojan-Spy.AndroidOS.Agent.aas (4.93%), which is a modification of the popular WhatsApp Messenger containing a spy tool.

Trojan.AndroidOS.Fakeapp.ed (4.45%) took sixth place. This verdict refers to a category of fraudulent apps which target users in Russia by posing as a stock-trading platform for investing in gas.

Eighth place is occupied by Trojan-Dropper.AndroidOS.Agent.sl (2.94%), a dropper that installs and runs banking trojans on devices. The majority of users attacked by it were located in Russia, Germany and Turkey.

Ninth place was taken by the verdict DangerousObject.AndroidOS.GenericML (2.55%). These verdicts are assigned to files recognized as malicious by our machine-learning systems. The verdict in tenth place is Trojan.AndroidOS.Fakeapp.dw (2.40%), which is used to describe various scam apps, such as apps claiming to offer an additional source of income.

The trojan in eleventh place is Trojan-Ransom.AndroidOS.Pigetrl.a (2.14%), which locks the device’s screen and asks for a code to unlock it. The trojan doesn’t provide any instructions on how to obtain this code, and the code itself is embedded in the body of the malware.

The trojan which came twelfth was Trojan.AndroidOS.Soceng.f (2.14%), which sends text messages to people in your contacts list, deletes files on the SD card, and overlays the interfaces of popular apps with its own window. The trojan in fourteenth place is Trojan-Downloader.AndroidOS.Agent.kx (1.63%), which downloads adware.

A trojan known as Trojan-SMS.AndroidOS.Agent.ado (1.62%), which sends text messages to short premium-rate numbers is in fifteenth place. The next row down is occupied by Trojan.AndroidOS.Fakeapp.ea (1.55%), another fraudulent trading app for investing in gas.

The trojan in seventeenth place is Trojan-Downloader.AndroidOS.Necro.d (1.47%), which is used to download and run other forms of malware on an infected device. It is followed by Trojan-Dropper.AndroidOS.Hqwar.gen (1.36%), which is used to unpack and run various banking trojans on a device.

The trojan in nineteenth place is Trojan.AndroidOS.GriftHorse.l (1.26%) — another fraudulent app mentioned in the quarterly-highlight section. It subscribes users to premium text-messaging services. The next line is occupied by SMS-Flooder.AndroidOS.Dabom.c (1.19%), which has the main aim of bombarding people with spam text messages.

Geography of mobile threats

Map of attempts to infect mobiles with malware, Q1 2022 (download)

TOP 10 countries by share of users attacked by mobile malware

Countries* %** 1 Iran 35.25 2 China 26.85 3 Yemen 21.23 4 Oman 19.01 5 Saudi Arabia 15.81 6 Algeria 13.89 7 Argentina 13.59 8 Brazil 10.80 9 Ecuador 10.64 10 Morocco 10.56

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

In the rating for Q1 2022, Iran (35.25%) is still the country with the most infected devices. The most frequently encountered threat in this country was annoying adware from the Notifyer and Fyben families. China came second (26.85%), where the most frequently encountered threats were Trojan.AndroidOS.Boogr.gsh and Trojan.AndroidOS.Najin.a. Third place was taken by Yemen (21.23%), where the most widespread mobile threat was Trojan-Spy.AndroidOS.Agent.aas spyware.

Mobile banking trojans

The number of installation packages for mobile banking trojans, which dipped in the first three quarters of 2021, continued to grow: we detected 53,947 of these packages in the reporting period, which is 15,594 up on Q4 2021 and a year-on-year increase of 28,633 against Q1 2021. The increase in the number of packages is largely due to the Trojan-Banker.AndroidOS.Bray family — its share accounted for 80.89% of all mobile banking trojans detected. The second most frequently detected package was Trojan-Banker.AndroidOS.Fakecalls (8.75%), followed by Trojan-Banker.AndroidOS.Cebruser (2.52%) in third place.

Number of installation packages for mobile banking trojans detected by Kaspersky, Q1 2021 — Q1 2022 (download)

TOP 10 most common mobile bankers

Verdict %* 1 Trojan-Banker.AndroidOS.Bian.h 18.68 2 Trojan-Banker.AndroidOS.Anubis.t 12.52 3 Trojan-Banker.AndroidOS.Svpeng.q 8.63 4 Trojan-Banker.AndroidOS.Agent.ep 8.24 5 Trojan-Banker.AndroidOS.Asacub.ce 4.98 6 Trojan-Banker.AndroidOS.Agent.eq 4.56 7 Trojan-Banker.AndroidOS.Sova.g 2.75 8 Trojan-Banker.AndroidOS.Gustuff.d 2.62 9 Trojan-Banker.AndroidOS.Agent.cf 2.39 10 Trojan-Banker.AndroidOS.Hqwar.t 2.32

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

Geography of mobile banking threats, Q1 2022 (download)

TOP 10 countries by shares of users attacked by mobile banking trojans

Countries* %** 1 Spain 1.80 2 Turkey 1.07 3 Australia 0.54 4 China 0.35 5 Italy 0.17 6 Japan 0.15 7 Colombia 0.13 8 Yemen 0.09 9 South Korea 0.08 10 Malaysia 0.07

* Countries with relatively few users of Kaspersky mobile security solutions (under 10,000) have been excluded from the ranking.
** Unique users attacked by mobile banking trojans as a percentage of all Kaspersky mobile security solution users in the country.

Spain (1.80%) was where the most unique users were attacked by mobile financial threats in Q1 2022. The trojan behind almost three quarters of attacks (74,58%) in this country was the TOP 10 leader Trojan-Banker.AndroidOS.Bian.h. Turkey (1.07%) came second, where Trojan-Banker.AndroidOS.Bian.h (42.69%) was also encountered more frequently than any other threat. Australia (0.54%) took third place, where one trojan was more active than all the rest: Trojan-Banker.AndroidOS.Gustuff.d (95.14%).

Mobile ransomware trojans

In Q1 2022, we detected 1,942 installation packages for mobile ransomware trojans, which is 2,371 fewer than the figure recorded in the previous quarter and a year-on-year decrease of 1,654 against Q1 2021.

Number of installation packages for mobile ransomware trojans detected by Kaspersky, Q1 2021 and Q1 2022 (download)

TOP 10 most common mobile ransomware

Verdict %* 1 Trojan-Ransom.AndroidOS.Pigetrl.a 78.77 2 Trojan-Ransom.AndroidOS.Rkor.br 5.68 3 Trojan-Ransom.AndroidOS.Rkor.bs 1.99 4 Trojan-Ransom.AndroidOS.Small.as 1.89 5 Trojan-Ransom.AndroidOS.Rkor.bi 1.59 6 Trojan-Ransom.AndroidOS.Rkor.bt 1.58 7 Trojan-Ransom.AndroidOS.Rkor.bp 1.41 8 Trojan-Ransom.AndroidOS.Rkor.bh 0.93 9 Trojan-Ransom.AndroidOS.Rkor.bn 0.88 10 Trojan-Ransom.AndroidOS.Rkor.bl 0.76

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

The top ransomware trojan held onto its title in the ranking for Q1 2022: Trojan-Ransom.AndroidOS.Pigetrl.a (78.77%). It’s worth noting that 94% of all attacks involving this trojan targeted Russia. The next runners-up trailing far behind the leader are two members of the Trojan-Ransom.AndroidOS.Rkor family: Rkor.br (5.68%) and Rkor.bs (1.99%).

Geography of mobile ransomware trojans, Q1 2022 (download)

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

Countries* %** 1 Yemen 0.43 2 Kazakhstan 0.34 3 China 0.28 4 Kyrgyzstan 0.08 5 Moldova 0.03 6 Saudi Arabia 0.02 7 Russian Federation 0.02 8 Egypt 0.02 9 Ukraine 0.02 10 Lithuania 0.02

* Countries with relatively few users of Kaspersky mobile security solutions (under 10,000) have been excluded from the ranking.
** Unique users attacked by ransomware trojans as a percentage of all Kaspersky mobile security solution users in the country.

Yemen (0.43%) tops the list of countries where the greatest number of users were attacked by mobile ransomware trojans. It’s followed by Kazakhstan (0.34%) with China (0.28%) rounding out the top three. The trojan which users in Yemen encountered most frequently was Trojan-Ransom.AndroidOS.Pigetrl.a, while users in Kazakhstan and China encountered members of the Trojan-Ransom.AndroidOS.Rkor family.

2022. május 27.

IT threat evolution Q1 2022

Targeted attacks MoonBounce: the dark side of UEFI firmware

Late last year, we became aware of a UEFI firmware-level compromise through logs from our firmware scanner (integrated into Kaspersky products at the start of 2019). Further analysis revealed that the attackers had modified a single component in the firmware in a way that allowed them to intercept the original execution flow of the machine’s boot sequence and introduce a sophisticated infection chain.

Our analysis of the rogue firmware, and other malicious artefacts from the target’s network, revealed that the threat actor behind it had tampered with the firmware to embed malware that we call MoonBounce. Since the implant is located in SPI flash on the motherboard, rather than on the hard disk, it can persist even if someone formats or replaces the hard disk.

Moreover, the infection chain does not leave any traces on the hard drive, as its components operate in memory only – facilitating a fileless attack with a small footprint. We detected other non-UEFI implants in the targeted network that communicated with the same infrastructure.

We attribute this intrusion set to APT41, a threat actor widely believed to be Chinese speaking, because of the combination of the above findings with network infrastructure fingerprints and other TTPs.

Our report describes in detail how the MoonBounce implant works 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 APT41.

BlueNoroff continues its search for crypto-currency

In January, we reported a malicious campaign targeting companies that work with cryptocurrencies, smart contracts, decentralized finance and blockchain technology: the attackers are interested in fintech in general. We attribute the campaign, named SnatchCrypto, to the BlueNoroff APT group, the threat actor behind the 2016 attack on Bangladesh’s central bank.

The campaign has two goals: gathering information and stealing cryptocurrency. The attackers are mainly interested in collecting data on user accounts, IP addresses and session information; and they steal configuration files from programs that work directly with cryptocurrency and may contain account credentials. The attackers carefully study potential victims, sometimes monitoring them for months.

One approach they take is to manipulate popular browser extensions for managing crypto wallets. They change an extension’s source in the browser settings so that they can install a modified version from local storage instead of the legitimate version loading from the official web store. They also use the modified Metamask extension for Chrome to replace the transaction logic, enabling them to steal funds even from those who use hardware devices to sign cryptocurrency transfers.

The attackers study their victims carefully and use the information they find to frame social engineering attacks. Typically, they construct emails that masquerade as communications from legitimate venture companies, but with an attached, macro-enabled document. When opened, this document eventually downloads a backdoor.

Our telemetry shows that there were victims in 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 that there were more victims of this financially motivated attack campaign.

Roaming Mantis reaches Europe

Since 2018, we have been tracking Roaming Mantis – a threat actor that targets Android devices. The group uses various malware families, including Wroba, and attack methods that include phishing, mining, smishing and DNS poisoning.

Typically, the smishing messages contain a very short description and a URL to a landing page. If someone clicks on the link and opens the landing page, there are two scenarios: the attackers redirect people using iOS to a phishing page imitating the official Apple website; on Android devices, they install the Wroba malware.

Our latest research indicates that Roaming Mantis has extended its geographic reach to include Europe. In the second half of 2021, the most affected countries were France, Japan, India, China, Germany and South Korea.

Territories affected by Roaming Mantis activity (download)

Cyberattacks related to the crisis in Ukraine

On January 14, attackers defaced 70 Ukrainian websites and posted the message “be afraid and expect the worst”. The defacement message on the Ministry of Foreign Affairs website, written in Ukrainian, Russian and Polish, suggested that personal data uploaded to the site had been destroyed. Subsequently, DDoS attacks hit some government websites. The following day, Microsoft reported that it had found destructive malware, dubbed WhisperGate, on the systems of government bodies and agencies that work closely with the Ukrainian government. It was not clear who was behind the attack, although the deputy secretary of Ukraine’s National Security and Defence Council stated that it was the work of UNC1151, a threat actor thought to be linked to Belarus.

WhisperKill, the wiper used during the WhisperGate campaign, wasn’t the only wiper to target organizations in Ukraine. On February 23, ESET published a tweet announcing new wiper malware targeting Ukraine. This wiper, named HermeticWiper by the research community, abuses legitimate drivers from the EaseUS Partition Master to corrupt the drivers of the compromised system. The compilation date of one of the identified samples was December 28 last year, suggesting that this destructive campaign had been planned for months.

The following day, Avast Threat Research announced the discovery of new Golang ransomware in Ukraine, which they dubbed HermeticRansom and which we call ElectionsGoRansom. This malware was discovered at around the same time as HermeticWiper; and publicly available information from the security community indicated that it was used in recent cyberattacks in Ukraine. The unsophisticated style and poor implementation suggest that attackers probably used this new ransomware as a smokescreen for the HermeticWiper attack.

On March 1, ESET published a blog post related to wipers used in Ukraine and to the ongoing conflict: in addition to HermeticWiper, this post introduced IsaacWiper, used to target specific computers previously compromised with another remote administration tool named RemCom, commonly used by attackers for lateral movement within compromised networks.

On March 22, the Ukraine CERT published a new alert about the DoubleZero wiper targeting the country. This is a new wiper, written in .NET, with no similarity to previously discovered wipers targeting Ukrainian entities. According to the CERT public statement, the campaign took place on March 17, when several targets in Ukraine received a ZIP archive with the filename “Вирус… крайне опасно!!!.zip” (translation: “Virus… extremely dangerous!!!.zip”).

On March 10, researchers from the Global Research and Analysis Team shared their insights into past and present cyberattacks in Ukraine. You can find the recording of the webinar here and a summary/Q&A here.

Lazarus uses Trojanized DeFi app to deliver malware

Earlier this year, we discovered a Trojanized DeFi app, compiled in November last year. The app contains a legitimate program, called DeFi Wallet, which saves and manages a cryptocurrency wallet, but it also implants a malicious file when executed. The malware is a fully featured backdoor designed to control compromised computers.

While it’s not clear how the threat actor tricked the victims into executing the Trojanized app, we suspect they sent a spear-phishing email or contacted them via social media.

We attribute the attacks, with high confidence, to the Lazarus group. We discovered numerous overlaps with other tools used by the same threat actor. The malware operator exclusively used compromised web servers located in South Korea for this attack. To take over the servers, we worked closely with a local CERT; as a result of this effort, we had the opportunity to investigate a Lazarus group C2 server.

The threat actor configured this infrastructure with servers set up as multiple stages. The first stage is the source for the backdoor, while the purpose of the second stage servers is to communicate with the implants. This represents a common scheme for Lazarus infrastructure.

We weren’t able to confirm the exact victims of this campaign, but the attack targets entities and/or individuals at a global level.

Other malware Noreboot: faking an iPhone restart

One of the things you can do to protect yourself from advanced mobile spyware is to reboot your device on a daily basis. Typically, such programs do not have a permanent foothold in the system and will survive only until the device is next restarted – the vulnerabilities that allow an attacker to obtain such persistence are rare and very expensive.

However, researchers have recently found a way to fake a restart.  Their technique, which they call Noreboot, is only a proof-of-concept, but if implemented by an attacker, it would allow them to achieve persistence on a target device.

For their lab demonstration, the researchers use an iPhone they had already infected (although they did not share the details of how they did this). When they shut down the device, using the power and volume buttons, the spyware displays an image of the iOS shutdown screen, faking the shutdown. After the user drags the power-off slider, the screen goes dark and the phone no longer responds to any of the user’s actions. When they press the power button again, the malware displays a perfect replica of the iOS boot animation.

Most people, of course, are not in the firing line of advanced threat actors; and a few simple precautions can help to keep you safe.

  • Don’t jailbreak or root your device.
  • Use a unique, complex passcode; and don’t leave your device unlocked when it’s unattended.
  • Only download apps from the App Store or Google Play.
  • Review app permissions and remove apps you no longer use.
  • If you use Android, protect your device with a robust security solution.

For those who think they could be a potential target for advanced threat actors, Costin Raiu, director of the Global Research and Analysis Team at Kaspersky, has outlined some steps you can take to reduce and mitigate the risks.

Hunting for corporate credentials on ICS networks

In 2021, Kaspersky ICS CERT experts noticed a growing number of anomalous spyware attacks infecting ICS computers across the globe. Although the malware used in these attacks belongs to well-known commodity spyware families, the attacks stand out from the mainstream due to the very limited number of targets in each attack and the very short lifetime of each malicious sample.

By the time we detected this anomaly, it had become a trend: around 21.2 percent of all spyware samples blocked on ICS computers worldwide in the second half of 2021 were part of this new limited-scope, short-lifetime attack series. At the same time, depending on the region, up to one-sixth of all computers attacked with spyware had been attacked using this tactic.

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

Overall, we identified more than 2,000 corporate email accounts belonging to industrial companies that the attackers abused as next-attack C2 servers because of successful malicious operations of this type. They stole, or abused in other ways, many more (over 7,000 according to our estimates).

Lapsus$ group hacks Okta

In March, the Lapsus$ cybercrime group claimed that it had obtained “superuser/admin” access to internal systems at Okta. The dates of the screenshots posted by the group suggest that it had had access to Okta’s systems since January. Lapsus$ was previously responsible for a number of high-profile hacks, including the Brazil Ministry of Health, Impresa, Nvidia, Samsung and Ubisoft.

Okta develops and maintains identity and access management systems; in particular, it provides a single sign-on solution that is used by a large number of companies. Okta confirmed the breach and stated that 2.5 percent of its customers (amounting to 366 customers) were potentially affected; and said that it had contacted the affected customers.

A few days later, Lapsus$ mocked Okta’s response to the breach.

The phishing kit market

Phishing remains one of the key methods used by attackers to compromise their targets – both individuals and organizations. One of the most common tricks the phishers use is to create a fake page that mimics the legitimate site of a famous brand. They copy design elements from the real website, making it hard for people to distinguish fake pages from the real ones.

Such websites can be easily blocked or added to anti-phishing databases, so cybercriminals need to generate these pages quickly and in large numbers. Since it is time-consuming to create them from scratch each time, and not all cybercriminals have the necessary skills, they tend to use phishing kits. These are like model aircraft or vehicle assembly kits – ready-made templates and scripts that others can use to create phishing pages quickly and at scale. They are quite easy to use, so even inexperienced attackers without technical skills can make use of them.

Cybercriminals typically get phishing kits from dark web forums or from closed Telegram channels. Scammers working on a tight budget can find some basic open-source tools online. Those who are better off can commission Phishing-as-a-Service, which often includes various phishing kits.

Cybercriminals tend to use hacked official websites to host pages generated using the phishing kits, or rely on companies that offer free web hosting providers. The latter are constantly working to combat phishing and block fake pages, although phishing websites often only require a short period of activity to achieve their intended purpose, which is to collect the personal data of victims and send it to the criminals.

Number of unique domains using the TOP 10 phishing kits, August 2021 — January 2022 (download)

Last year alone, Kaspersky detected 469 individual phishing kits, enabling us to block around 1.2 million phishing pages. The chart shows the dynamics of the TOP 10 phishing kits we detected between August 2021 and January 2022, along with the number of unique domains where each phishing kit was encountered.

2022. május 27.

IT threat evolution in Q1 2022. Non-mobile statistics

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

Quarterly figures

According to Kaspersky Security Network, in Q1 2022:

  • Kaspersky solutions blocked 1,216,350,437 attacks from online resources across the globe.
  • Web Anti-Virus recognized 313,164,030 unique URLs as malicious.
  • Attempts to run malware for stealing money from online bank accounts were stopped on the computers of 107,848 unique users.
  • Ransomware attacks were defeated on the computers of 74,694 unique users.
  • Our File Anti-Virus detected 58,989,058 unique malicious and potentially unwanted objects.
Financial threats Financial threat statistics

In Q1 2022 Kaspersky solutions blocked the launch of at least one piece of malware designed to steal money from bank accounts on the computers of 107,848 unique users.

Number of unique users attacked by financial malware, Q1 2022 (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 and territory 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 or territory.

Geography of financial malware attacks, Q1 2022 (download)

TOP 10 countries by share of attacked users

Country* %** 1 Turkmenistan 4.5 2 Afghanistan 4.0 3 Tajikistan 3.9 4 Yemen 2.8 5 Uzbekistan 2.4 6 China 2.2 7 Azerbaijan 2.0 8 Mauritania 2.0 9 Sudan 1.8 10 Syria 1.8

* 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 Ramnit/Nimnul Trojan-Banker.Win32.Ramnit 36.5 2 Zbot/Zeus Trojan-Banker.Win32.Zbot 16.7 3 CliptoShuffler Trojan-Banker.Win32.CliptoShuffler 6.7 4 SpyEye Trojan-Spy.Win32.SpyEye 6.3 5 Gozi Trojan-Banker.Win32.Gozi 5.2 6 Cridex/Dridex Trojan-Banker.Win32.Cridex 3.5 7 Trickster/Trickbot Trojan-Banker.Win32.Trickster 3.3 8 RTM Trojan-Banker.Win32.RTM 2.7 9 BitStealer Trojan-Banker.Win32.BitStealer 2.2 10 Danabot Trojan-Banker.Win32.Danabot 1.8

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

Our TOP 10 leader changed in Q1: the familiar ZeuS/Zbot (16.7%) dropped to second place and Ramnit/Nimnul (36.5%) took the lead. The TOP 3 was rounded out by CliptoShuffler (6.7%).

Ransomware programs Quarterly trends and highlights Law enforcement successes
  • Several members of the REvil ransomware crime group were arrested by Russian law enforcement in January. The Russian Federal Security Service (FSB) says it seized the following assets from the cybercriminals: “more than 426 million rubles ($5.6 million) including denominated in cryptocurrency; $600,000; 500,000 euros; computer equipment, the crypto wallets that were used to perpetrate crimes, and 20 luxury cars that were purchased with illicitly obtained money.”
  • In February, a Canadian citizen was sentenced to 6 years and 8 months in prison for involvement in NetWalker ransomware attacks (also known as Mailto ransomware).
  • In January, Ukrainian police arrested a ransomware gang who delivered an unclarified strain of malware via e-mail. According to the statement released by the police, over fifty companies in the United States and Europe were attacked by the cybercriminals.
HermeticWiper, HermeticRansom and RUransom, etc.

In February, new malware was discovered which carried out attacks with the aim of destroying files. Two pieces of malware — a Trojan called HermeticWiper that destroys data and a cryptor called HermeticRansom — were both used in cyberattacks in Ukraine. That February, Ukrainian systems were attacked by another Trojan called IsaacWiper, followed by a third Trojan in March called CaddyWiper. The apparent aim of this malware family was to render infected computers unusable leaving no possibility of recovering files.

An intelligence team later discovered that HermeticRansom only superficially encrypts files, and ones encrypted by the ransomware can be decrypted.

RUransom malware was discovered in March, which was created to encrypt files on computers in Russia. The analysis of the malicious code revealed it was developed to wipe data, as RUransom generates keys for all the victim’s encrypted files without storing them anywhere.

Conti source-code leak

The ransomware group Conti had its source code leaked along with its chat logs which were made public. It happened shortly after the Conti group expressed support for the Russian government’s actions on its website. The true identity of the individual who leaked the data is currently unknown. According to different versions, it could have been a researcher or an insider in the group who disagrees with its position.

Whoever it may have been, the leaked ransomware source codes in the public domain will obviously be at the fingertips of other cybercriminals, which is what happened on more than one occasion with examples like Hidden Tear and Babuk.

Attacks on NAS devices

Network-attached storage (NAS) devices continue to be targeted by ransomware attacks. A new wave of Qlocker Trojan infections on QNAP NAS devices occurred in January following a brief lull which lasted a few months. A new form of ransomware infecting QNAP NAS devices also appeared in the month of January called DeadBolt, and ASUSTOR devices became its new target in February.

Maze Decryptor

Master decryption keys for Maze, Sekhmet and Egregor ransomware were made public in February. The keys turned out to be authentic and we increased our support to decrypt files encrypted by these infamous forms of ransomware in our RakhniDecryptor utility. The decryptor is available on the website of our No Ransom project and the website of the international NoMoreRansom project in the Decryption Tools section.

Number of new modifications

In Q1 2022, we detected eight new ransomware families and 3083 new modifications of this malware type.

Number of new ransomware modifications, Q1 2021 — Q1 2022 (download)

Number of users attacked by ransomware Trojans

In Q1 2022, Kaspersky products and technologies protected 74,694 users from ransomware attacks.

Number of unique users attacked by ransomware Trojans, Q1 2022 (download)

Geography of attacked users

Geography of attacks by ransomware Trojans, Q1 2022 (download)

TOP 10 countries attacked by ransomware Trojans

Country* %** 1 Bangladesh 2.08 2 Yemen 1.52 3 Mozambique 0.82 4 China 0.49 5 Pakistan 0.43 6 Angola 0.40 7 Iraq 0.40 8 Egypt 0.40 9 Algeria 0.36 10 Myanmar 0.35

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

TOP 10 most common families of ransomware Trojans Name Verdicts* Percentage of attacked users** 1 Stop/Djvu Trojan-Ransom.Win32.Stop 24.38 2 WannaCry Trojan-Ransom.Win32.Wanna 13.71 3 (generic verdict) Trojan-Ransom.Win32.Gen 9.35 4 (generic verdict) Trojan-Ransom.Win32.Phny 7.89 5 (generic verdict) Trojan-Ransom.Win32.Encoder 5.66 6 (generic verdict) Trojan-Ransom.Win32.Crypren 4.07 7 (generic verdict) Trojan-Ransom.Win32.CryFile 3.72 8 PolyRansom/VirLock Trojan-Ransom.Win32.PolyRansom / Virus.Win32.PolyRansom 3.37 9 (generic verdict) Trojan-Ransom.Win32.Crypmod 3.17 10 (generic verdict) Trojan-Ransom.Win32.Agent 1.99

* Statistics are based on detection verdicts of Kaspersky products. The information was provided by Kaspersky product users who consented to provide statistical data.
** Unique Kaspersky users attacked by specific ransomware Trojan families as a percentage of all unique users attacked by ransomware Trojans.

Miners Number of new miner modifications

In Q1 2022, Kaspersky solutions detected 21,282 new modifications of miners.

Number of new miner modifications, Q1 2022 (download)

Number of users attacked by miners

In Q1, we detected attacks using miners on the computers of 508,449 unique users of Kaspersky products and services worldwide.

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

Geography of miner attacks

Geography of miner attacks, Q1 2022 (download)

TOP 10 countries attacked by miners

Country* %** 1 Ethiopia 3.01 2 Tajikistan 2.60 3 Rwanda 2.45 4 Uzbekistan 2.15 5 Kazakhstan 1.99 6 Tanzania 1.94 7 Ukraine 1.83 8 Pakistan 1.79 9 Mozambique 1.69 10 Venezuela 1.67

* 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 criminals during cyberattacks Quarter highlights

In Q1 2022, a number of serious vulnerabilities were found in Microsoft Windows and its components. More specifically, the vulnerability CVE-2022-21882 was found to be exploited by an unknown group of cybercriminals: a “type confusion” bug in the win32k.sys driver the attacker can use to gain system privileges. Also worth noting is CVE-2022-21919, a vulnerability in the User Profile Service which makes it possible to elevate privileges, along with CVE-2022-21836, which can be used to forge digital certificates.

One of the major talking points in Q1 was an exploit that targeted the CVE-2022-0847 vulnerability in the Linux OS kernel. It was dubbed “Dirty Pipe”. Researchers discovered an “uninitialized memory” vulnerability when analyzing corrupted files, which makes it possible to rewrite a part of the OS memory, namely page memory that contains system files’ data. This in turn opens up an opportunity, such as elevating attacker’s privileges to root. It’s worth noting that this vulnerability is fairly easy to exploit, which means users of all systems should regularly install security patches and use all available means to prevent infection.

When it comes to network threats, this quarter continued to show how cybercriminals often resort to the technique of brute-forcing passwords to gain unauthorized access to various network services, the most popular of which are MSSQL, RDP and SMB. Attacks using the EternalBlue, EternalRomance and similar exploits remain as popular as ever. Due to widespread unpatched versions of Microsoft Exchange Server, networks often fall victim to exploits of ProxyToken, ProxyShell, ProxyOracle and other vulnerabilities. One example of a critical vulnerability found is remote code execution (RCE) in the Microsoft Windows HTTP protocol stack which allows an attack to be launched remotely by sending a special network packet to a vulnerable system by means of the HTTP trailer functionality. New attacks on network applications which will probably also become common are RCE attacks on the popular Spring Framework and Spring Cloud Gateway. Specific examples of vulnerabilities in these applications are CVE-2022-22965 (Spring4Shell) and CVE-2022-22947.

Vulnerability statistics

Q1 2022 saw an array of changes in the statistics on common vulnerability types. For instance, the top place in the statistics is still firmly held by exploits targeting vulnerabilities in Microsoft Office and their share has increased significantly to 78.5%. The same common vulnerabilities we’ve written about on more than one occasion are still the most widely exploited within this category of threats. These are CVE-2017-11882 and CVE-2018-0802, which cause a buffer overflow when processing objects in a specially crafted document in the Equation Editor component and ultimately allow an attacker to execute arbitrary code. There’s also CVE-2017-8570, where opening a specially crafted file with an affected version of Microsoft Office software gives attackers the opportunity to perform various actions on the vulnerable system. Another vulnerability found last year which is very popular with cybercriminals is CVE-2021-40444, which they can use to exploit through a specially prepared Microsoft Office document with an embedded malicious ActiveX control for executing arbitrary code in the system.

Distribution of exploits used by cybercriminals, by type of attacked application, Q1 2022 (download)

Exploits targeting browsers came second again in Q1, although their share dropped markedly to just 7.64%. Browser developers put a great deal of effort into patching vulnerability exploits in each new version and closing a large number of gaps in system security. Apart from that, the majority of browsers have automatic updates as opposed to the distinct example of Microsoft Office, where many of its users still use outdated versions and are in no rush to install security updates. That could be precisely the reason why we’ve seen a reduction in the share of browser exploits in our statistics. However, this does not mean they’re no longer an immediate threat. For instance, Chrome’s developers fixed a number of critical RCE vulnerabilities, including:

  • CVE-2022-1096: a “type confusion” vulnerability in the V8 script engine which gives attackers the opportunity to remotely execute code (RCE) in the context of the browser’s security sandbox.
  • CVE-2022-0609: a use-after-free vulnerability which allows to corrupt the process memory and remotely execute arbitrary codes when performing specially generated scripts that use animation.

Similar vulnerabilities were found in the browser’s other components: CVE-2022-0605which uses Web Store API, and CVE-2022-0606 which is associated with vulnerabilities in the WebGL backend (ANGLE). Another vulnerability found was CVE-2022-0604, which can be used to exploit a heap buffer overflow in Tab Groups, also potentially leading to remote code execution (RCE).

Exploits for Android came third in our statistics (4.10%), followed by exploits targeting the Adobe Flash Platform (3.49%), PDF files (3.48%) and Java apps (2.79%).

Attacks on macOS

The year began with a number of interesting multi-platform finds: the Gimmick multi-platform malware family with Windows and macOS variants that uses Google Drive to communicate with the C&C server, along with the SysJoker backdoor with versions tailored for Windows, Linux and macOS.

TOP 20 threats for macOS

Verdict %* 1 AdWare.OSX.Pirrit.ac 13.23 2 AdWare.OSX.Pirrit.j 12.05 3 Monitor.OSX.HistGrabber.b 8.83 4 AdWare.OSX.Pirrit.o 7.53 5 AdWare.OSX.Bnodlero.at 7.41 6 Trojan-Downloader.OSX.Shlayer.a 7.06 7 AdWare.OSX.Pirrit.aa 6.75 8 AdWare.OSX.Pirrit.ae 6.07 9 AdWare.OSX.Cimpli.m 5.35 10 Trojan-Downloader.OSX.Agent.h 4.96 11 AdWare.OSX.Pirrit.gen 4.76 12 AdWare.OSX.Bnodlero.bg 4.60 13 AdWare.OSX.Bnodlero.ax 4.45 14 AdWare.OSX.Agent.gen 3.74 15 AdWare.OSX.Agent.q 3.37 16 Backdoor.OSX.Twenbc.b 2.84 17 Trojan-Downloader.OSX.AdLoad.mc 2.81 18 Trojan-Downloader.OSX.Lador.a 2.81 19 AdWare.OSX.Bnodlero.ay 2.81 20 Backdoor.OSX.Agent.z 2.56

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

The TOP 20 threats to users detected by Kaspersky security solutions for macOS is usually dominated by various adware apps. The top two places in the rating were taken by adware apps from the AdWare.OSX.Pirrit family, while third place was taken by a member of the Monitor.OSX.HistGrabber.b family of potentially unwanted software which sends users’ browser history to its owners’ servers.

Geography of threats for macOS

Geography of threats for macOS, Q1 2022 (download)

TOP 10 countries by share of attacked users

Country* %** 1 France 2.36 2 Spain 2.29 3 Italy 2.16 4 Canada 2.15 5 India 1.95 6 United States 1.90 7 Russian Federation 1.83 8 United Kingdom 1.58 9 Mexico 1.49 10 Australia 1.36

* 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 Q1 2022, the country where the most users were attacked was France (2.36%), followed by Spain (2.29%) and Italy (2.16%). Adware from the Pirrit family was encountered most frequently out of all macOS threats in the listed countries.

IoT attacks IoT threat statistics

In Q1 2022, most devices that attacked Kaspersky traps did so using the Telnet protocol as before. Just one quarter of devices attempted to brute-force our SSH traps.

Telnet 75.28% SSH 24.72%

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

If we look at sessions involving Kaspersky honeypots, we see far greater Telnet dominance.

Telnet 93.16% SSH 6.84%

Distribution of cybercriminal working sessions with Kaspersky traps, Q1 2022

TOP 10 threats delivered to IoT devices via Telnet

Verdict %* 1 Backdoor.Linux.Mirai.b 38.07 2 Trojan-Downloader.Linux.NyaDrop.b 9.26 3 Backdoor.Linux.Mirai.ba 7.95 4 Backdoor.Linux.Gafgyt.a 5.55 5 Trojan-Downloader.Shell.Agent.p 4.62 6 Backdoor.Linux.Mirai.ad 3.89 7 Backdoor.Linux.Gafgyt.bj 3.02 8 Backdoor.Linux.Agent.bc 2.76 9 RiskTool.Linux.BitCoinMiner.n 2.00 10 Backdoor.Linux.Mirai.cw 1.98

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

Similar IoT-threat statistics are published in the DDoS report for Q1 2022.

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 and territories that serve as sources of web-based attacks: TOP 10

The following statistics show the distribution by country or territory 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 Q1 2022, Kaspersky solutions blocked 1,216,350,437 attacks launched from online resources across the globe. 313,164,030 unique URLs were recognized as malicious by Web Anti-Virus components.

Distribution of web-attack sources by country and territory, Q1 2022 (download)

Countries and territories where users faced the greatest risk of online infection

To assess the risk of online infection faced by users in different countries and territories, for each country or territory 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 and territories.

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 or territory* %** 1 Taiwan 22.63 2 Tunisia 21.57 3 Algeria 16.41 4 Mongolia 16.05 5 Serbia 15.96 6 Libya 15.67 7 Estonia 14.45 8 Greece 14.37 9 Nepal 14.01 10 Hong Kong 13.85 11 Yemen 13.17 12 Sudan 13.08 13 Slovenia 12.94 14 Morocco 12.82 15 Qatar 12.78 16 Croatia 12.53 17 Republic of Malawi 12.33 18 Sri Lanka 12.28 19 Bangladesh 12.26 20 Palestine 12.23

* Excluded are countries and territories 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 or territory.

On average during the quarter, 8.18% of computers of Internet users worldwide were subjected to at least one Malware-class web attack.

Geography of web-based malware attacks, Q1 2022 (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 Q1 2022, our File Anti-Virus detected 58,989,058 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 triggerings in response to potentially dangerous or unwanted programs, such as RiskTool or adware.

Country* %** 1 Yemen 48.38 2 Turkmenistan 47.53 3 Tajikistan 46.88 4 Cuba 45.29 5 Afghanistan 42.79 6 Uzbekistan 41.56 7 Bangladesh 41.34 8 South Sudan 39.91 9 Ethiopia 39.76 10 Myanmar 37.22 11 Syria 36.89 12 Algeria 36.02 13 Burundi 34.13 14 Benin 33.81 15 Rwanda 33.11 16 Sudan 32.90 17 Tanzania 32.39 18 Kyrgyzstan 32.26 19 Venezuela 32.00 20 Iraq 31.93

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

Geography of local infection attempts, Q1 2022 (download)

Overall, 15.48% of user computers globally faced at least one Malware-class local threat during Q1. Russia scored 16.88% in this rating.

2022. május 26.

Managed detection and response in 2021

Kaspersky Managed Detection and Response (MDR) helps organizations to complement existing detection capabilities or to expand limited in-house resources to protect their infrastructure from the growing number and complexity of threats in real time. We collect telemetry from clients’ networks and analyze it using machine learning and artificial intelligence, plus human threat-hunting analysts. Kaspersky SOC investigates alerts and notifies the client if there is something bad going on, providing response actions and recommendations.

MDR in 2021 in numbers

In 2021:

  • Kaspersky MDR received 414K alerts.
  • 74% of received alerts were processed by SOC analysts, 6.67% of which were related to real incidents reported to customers via the MDR portal
  • 4% of all incidents are related to only one alert
  • 14% of incidents were high-severity, 66% medium-severity, and 20% low-severity
  • The average identification time of high-severity incidents was 41.4 minutes
  • 7% of high-severity incidents were targeted attacks; 18% were ethical offensive exercises (penetration testing, red teaming etc.)
  • Most incidents were detected at the initial access (27.3%) and lateral movement (16.3%) stages
  • Most often high-severity incidents were detected in IT (39%), industrial (30.2%), and financial (29.1%) organizations
  • The LOL binaries most often used by attackers were cmd.exe, powershell.exe, and rundll.exe

To get the full Kaspersky Managed Detection and Response 2021 report, please fill out the form below.
MktoForms2.loadForm("//app-sj06.marketo.com", "802-IJN-240", 23724); MktoForms2.whenReady(function(form) { form.onSuccess(function(vals, tyURL) { document.location.href = tyURL; 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'); }); })();

2022. május 25.

The Verizon 2022 DBIR

The Verizon 2022 Data Breach Investigations Report is out. We are proud to collaborate as a supporting contributor to this year’s data efforts once again and to have contributed for the past 8 years. The report provides interesting analysis of a full amount of global incident data.

Several things stand out in the 2022 report:

  • Ransomware challenges continue to mount — “Ransomware’s heyday continues, and is present in almost 70% of malware breaches this year.”
  • Social engineering became an overwhelming problem this past year, highlighting the surge in repeated cybercrime tactics — 1. “The human element continues to be a key driver of 82% of breaches and this pattern captures a large percentage of those breaches.” 2. “Actor Motives: Financial (89%), Espionage (11%).”
  • APT activity continues to be high, was underreported in the past, and while it possibly continues to be underreported, its reporting is increasing: “Financial has been the top motive since we began to track it in 2015. However, that same year the rise of hacktivism (particularly leaks) accounted for many attacks. Espionage-related attacks were not even on the radar, but seven years later the world is a very different place. Espionage has taken the 2nd place spot for years, and hacktivism is, for the most part, simply an afterthought. Before we move on, however, it should be noted that while espionage has almost certainly increased over the last few years, the fact that it did not appear at all in 2015 was quite likely due to our contributors and general case load at the time.”
  • System intrusions were heavily weighted at the top by two vectors: “‘Partner’ and ‘Software update’ as the leading vectors for incidents. This is primarily attributed to one very large and very public security incident that happened last year. We’ll give you a hint, it rhymes with ‘PolarShins’.” These data points fall under the supply chain discussion for us, and we continue to see that trend into this year — the “supply chain” is actively targeted and abused as a deployment tactic around the world, and we expect it to continue.

Business leaders should be sure to check out Appendix C — Behavior. It maintains an interesting approach on quantifying success in training programs, “In 2021 we reported that the human element impacted 85% of breaches, which decreased slightly to 82% this year. Unfortunately, strong asset management and a stellar vulnerability scanner aren’t going to solve this one.”

Perhaps next year we will read more about IoT and industrial issues, we’ll see. In the meantime, enjoy this year’s publication!

2022. május 25.

What’s wrong with automotive mobile apps?

Introduction

The recent story about the 19-year-old hacker who took control of several dozen Tesla cars has become something of a sensation. We already know that there was an issue with a third-party app that enabled access to data from Teslas. This made it possible for the security researcher to lock and unlock the cars, turn the lights on and off, and even enable keyless driving. All the functions in the native Tesla application became available due to a misconfiguration in third-party data logging software. So, let’s try to get a better understanding of what these apps are, why they appear on the market, and the risks they pose.

First public notice about the incident involving Tesla

The majority of modern vehicles are equipped with a special telematics module. The electronic control unit with a built-in SIM card provides the manufacturer with the vehicle’s location, warns the owner about upcoming vehicle inspections, and can even contact emergency services. In addition, the car owner gets some handy functions, such as the ability to check the vehicle’s location, control the door locks, remotely turn on climate control, and even automatically park the car. And all that by just using a mobile application.

Interface of a typical companion app

But why do people need a third-party app when all these functions are available in the car manufacturer’s application?

Native apps simply can’t satisfy the demand for features among modern car owners. For example, some users want to see how the fuel/energy consumption changes depending on their route. Some want to warm up the vehicle interior while their smart coffee machine starts making coffee in the morning. And others are not happy that they need to use several mobile applications for different car brands, and want to manage them all from a single universal application.

So, what can go wrong? The same sort of things that occur in other walks of life. A key is needed to gain access to a car, but in this case instead of a key there is a login or email and a password. And the prerequisite for the automaker’s backend to send a command to the owner’s vehicle if it receives these credentials. They are intended to be transferred directly from the automaker’s native app, but third-party apps can ask a user for the original credentials and send them to the automaker’s API on their behalf.

Communication between apps and vehicle

The risk is obvious: third parties get the ability, for example, to unlock the car or track all its movements on behalf of the car owner.

What’s the scope?

How many of these solutions are out there? Kaspersky analysts checked among mobile applications, open-source software and searched web services to find out. The research scope included 155 of the most popular solutions that require the vehicle owner’s credentials (login and password pair or API key) to interact with the vehicle. A total of 69 mobile apps and 81 solutions were discovered in open repositories, such as API clients in various programming languages. The findings also included web services, as well as a few other things of interest.

Types of applications (download)

Each of these discovered application types is described below.

About mobile applications

Let’s start with mobile apps as the most accessible and most understandable for the average user. If we look closer at the descriptions of these apps, they usually talk about their great functionality, convenience, and even comparisons to the “slow” apps provided by automakers.

Description of a random application

An analysis of these descriptions showed that more than half the applications fail to mention that they use the owner’s account with the automaker’s native service.

Share of applications that don’t notify users on credential usage (download)

Yes, that’s right. The important thing to note here is that the second smaller share is made up of developers that explicitly state their apps do not store the user’s data, or store it in encrypted form or only use the credentials to obtain authorization tokens. But, to be clear, you are basically handing over your car keys to a complete stranger and taking them at their word, because there’s no way of verifying those statements.

Some of the developers also suggest using an authorization token instead of a username and password to look more credible. But the catch there is that this token makes it possible to access the car in the same way as user credentials. And, once again, the user should be aware that all this is at their own risk. Only 19% of developers feel the need to mention this fact and warn the user without hiding behind several screens of fine print.

Share of apps warning users about their liability (download)

The most common way for a user to contact the application developer is usually via feedback in the review section of the mobile app store. But what if the question is more serious and requires an immediate response? Here we can thank the application stores and their placement rules. The contact information for 86% of the app authors was found without much effort, although quite often it is just an email without any additional information. But for some applications the search can lead to a deleted social network page or a stub page with no contacts.

Share of apps with available contacts (download)

Based on this, it’s clear that most of these applications are developed by enthusiasts. Is that necessarily a bad thing? No. But there’s no onus on the enthusiast developer to care about your vehicle’s safety and data security to the same extent that state regulators demand of automakers.

Which vehicle brands are most often subject to control by third-party apps? In total, we counted 31 brands, with the top five shown below. Note, some applications enable control of more than one type of car brand, so the number of mentions is not equal to the total number of apps.

Top five affected automotive brands (download)

Tesla leads by a considerable margin, followed by Nissan. It appears that electric vehicle owners, who are usually car enthusiasts, are interested in these apps.

When it comes to the cost, 46 of the 69 apps are free of charge or at least have a demo mode. If a program can do cool tricks with a car and costs a lot of money, there may well be a free counterpart.

Free to paid allocation (download)

This, combined with the fact that such applications have been downloaded from Google Play more than 239,000 times, makes you wonder just how many people have given strangers free access to their cars.

Open-source API clients and web services

It is worth noting that slightly more advanced users tend to use software from GitHub. And indeed, it is pretty easy to check it to see if an API client is transferring sensitive information to third parties. But what if the source code is a bit more complicated? Would all the users check the code, and how thoroughly? And, of course, this won’t guarantee there are no vulnerabilities in the application itself or its components. The example in the first link of this article illustrates that rather well.

The third type of application in our selection is web services. These services are provided to users on a commercial basis. But even though they may be developed by organizations with highly skilled developers and well-established management, the authorization scheme is not that different. The user still needs to provide their credentials, but to a web form and not to a mobile application or API endpoint.

What didn’t fit our data?

One other type of application stands a little apart from the rest. That’s because unlike the regular add-ons or classic “give the username and password – get the token”, they are designed as full-fledged B2B solutions. B2B? Yes, that’s right. Take, for instance, a company that wants to sell an application or service to a user without diving deep into the specific implementations of different car manufacturers. And a B2B provider provides universal solutions that are capable of interacting with multiple automakers and facilitates their work, becoming an intermediate link.

Schematically, an example would be as follows:

  • The user registers in an online third-party service like those mentioned in the previous section. That service helps estimate the optimal time and location to charge a vehicle.
  • The system of the service has no direct access to the automaker’s API, so it passes the user’s credentials to the aforementioned B2B provider.
  • In its turn, the B2B provider sends the credentials to the automaker’s API and gets an authorization token in return, allowing direct access to the user’s vehicle and its data.

Thus, the username and the password go to both the third-party application and the B2B provider at the same time. In this case, both the owner and developer “in the middle” are at risk because the security of the user data now depends on yet another company.

There is also some risk here for the automakers because these services process the data of lots of users. Yes, all of this only works with the end user’s consent, but, as recent events show, it is the car brand that makes the headlines, rather than the app name.

Conclusion

If you decide to stop using such apps after reading this article, there are a few things to consider:

  • It’s not enough to just delete the app – some services require that you end the subscription or delete your account on their website;
  • A password change is mandatory;
  • Even after a password reset, it is better to try to revoke access via the manufacturer’s website (if there is such a feature) or customer support service.

Of course, not all these companion applications should be treated as insecure or untrusted. Some of them use specially designed solutions from automakers, which, for example, make it impossible to unlock the doors remotely for security reasons. Instead, access to the vehicle data is given via the manufacturer’s website, and there is no need to provide credentials to a particular application. Users can also revoke this access at any time. Unfortunately, there still aren’t many apps capable of this.

Hence, we urge the app developers to make user protection a priority and take precautionary measures so as not to compromise their customers or themselves. Instead of assuming their customers are prepared for potential threats, developers can proactively equip their apps with additional user-protection technologies.

Kaspersky recommends the following for application developers:

  • Since supply-chain attacks through public repositories have become more frequent of late, the development process needs enhanced protection against outside interference. Adopt solutions that can secure the software development process by application control at runtime, scanning for vulnerabilities before deployment, routine security vetting of containers and anti-malware testing of the production artifacts. Kaspersky Hybrid Cloud Security meets development needs. It secures Docker and Windows containers and provides a ‘security-as-code’ approach, with containerization host memory protection, tasks for containers, image scanning and scriptable interfaces, so you can integrate security tasks into CI/CD pipelines without impacting the development process.
  • Implement protection mechanisms into the app. Kaspersky Mobile SDK enables customer data protection, as well as malware detection, secure connectivity and more.
2022. május 23.

ISaPWN – research on the security of ISaGRAF Runtime

In early 2020, we notified the Rockwell Automation Product Security Incident Response Team (RA PSIRT) of several vulnerabilities we had identified in the ISaGRAF Runtime execution environment.

According to public sources of information, ISaGRAF Runtime is used as an automation framework in multiple products in various industries across the globe and its use is not limited to ICS. ISaGRAF Runtime are also used in transportation, power & energy, and other sectors.

This report includes an analysis of the ISaGRAF framework, its architecture, the IXL and SNCP protocols that are used to program and control ISaGRAF-based devices and to communicate with them.

Our research has uncovered multiple vulnerabilities in ISaGRAF Runtime. The following potential vectors of attacks on ISaGRAF-based devices have been identified:

  • A remote unauthenticated attacker could execute privileged commands of the IXL service on devices with ISaGRAF Runtime versions released before 2010.
  • A remote attacker could easily implement a password brute force attack in ISaGRAF Runtime.
  • An attacker that can carry out a MitM attack will be able to overwrite tag statuses, the program being downloaded to the device, or authentication data. Since authentication data is encrypted with a preset symmetric key, the attacker could decrypt an intercepted target (device) password.
  • An attacker could exploit the vulnerabilities identified to gain remote access to a device with ISaGRAF Runtime and execute arbitrary malicious code inside the ISaGRAF Runtime virtual machine.
  • An attacker could exploit the vulnerabilities to escape the ISaGRAF Runtime sandbox, ensure the malicious code’s persistence on the device, and hide it from future detection.

Detailed descriptions of the vulnerabilities identified are provided, along with an analysis of the impact that their potential abuse could have and recommendations on additional risk mitigation measures.

By the end of 2021, all of the vulnerabilities identified had been fixed by the technology vendor, or mitigations were suggested by the vendor, CISA, or Kaspersky ICS CERT.

As of March 2022, the following vendors had reported ISaGRAF Runtime vulnerabilities in their products: Rockwell Automation, Schneider Electric, Xylem, GE, and Moxa.

More information is available on the Kaspersky ICS CERT website.

2022. május 17.

Evaluation of cyber activities and the threat landscape in Ukraine

Introduction

When the war in Ukraine broke out, many analysts were surprised to discover that what was simultaneously happening in the cyber domain did not match their predictions[1]. Since the beginning of the fighting, new cyberattacks taking place in Ukraine have been identified every week, which lead to a variety of interpretations – and indeed a global feeling of confusion. In this report, we aim to provide a strategic technical assessment of our understanding of current events.

Much of the debate around the situation concerns the question of whether or not a cyberwar is taking place. However, we find this question to be entirely irrelevant. While there is no question that a high number of cyberattacks have taken place and are still taking place in the country, we recognize that the overwhelming majority of cyber events thus far have been overshadowed by the kinetic aspects of the conflict. We nevertheless do still see value in attempting to interpret the data at hand, in alignment with Kaspersky’s constant commitment to understand more about threat actors and how they are organized.

Therefore, with this article, our core aim is to share a threat landscape overview, which Kaspersky cybersecurity researchers in its Global Research and Analysis Team (GReAT) are observing in relation to the conflict, with the wider international community and thus to contribute to broader ongoing cyber-stability discussions of threat-related insights.

Overview of cyber activities

Since the beginning of the war, the international community has observed a very high number of attacks of various kinds and degrees of sophistication. These attacks include:

  • Destructive attacks such as:
    • Ransomware (IsaacRansom);
    • Fake ransomware (WhisperGate);
    • Wipers (HermeticWiper, CaddyWiper, DoubleZero, IsaacWiper); and
    • ICS/OT wipers (AcidRain, Industroyer2).
  • Advanced persistent threats (APTs) and campaigns focused on intelligence gathering, such as:
    • Gamaredon;
    • Hades (Sandworm);
    • PandoraBlade; and
    • UNC1151.

Focusing on the destructive attacks, we cannot help but notice that many of the malicious programs discovered showcase vastly disparate degrees of sophistication. At one end of the spectrum, HermeticWiper is an extremely well-designed piece of software, which must have required weeks of development (at least) before it was released. At the other end, programs such as IsaacWiper appear to be the product of rushed development – as if their operators had been tasked with destroying data at the eleventh hour.

Contrary to some declarations, we have not noticed any particular coordination efforts, neither between separate instances of these attacks, nor with military operations occurring at the same time (with the notable exception of AcidRain). We have also been unable to identify any particular trends in the targeting involved. Our best guess is that separate groups decided to take advantage and wreak havoc immediately after the conflict erupted.

The overall limited operational impact of such attacks could certainly be viewed as surprising when we consider that some threat actors active in the region have demonstrated highly-disruptive capabilities in the past (e.g., BlackEnergy). We can only speculate as to why such capabilities were not used since late February, but our best guess is that the attacks were not coordinated, and each such attack with a more disruptive impact typically requires more effort for careful planning and execution from the threat actors. This supposition may be given more weight by ESET’s discovery of Industroyer2 in a Ukrainian energy company: the research reports that destructive actions were planned for April 8, but that “the attack had been planned for at least two weeks”. It is safe to assume that such an attack requires careful planning and that preparations for it only started after it became clear that the war would last longer than widely expected.

In this regard, summing up the above-mentioned discussions, these are our three key takeaways:

  1. Attacks observed against infrastructure in Ukraine so far appear to be uncoordinated and conducted by groups of varying technical levels;
  2. While these cyber activities hint at a role cyberspace could take during a military conflict, what we have seen so far can hardly be regarded as the full extent of threat actors’ capabilities; and
  3. It is likely that as a clearer perception of the scale and duration of the war emerges, the various groups will find ways of coordinating better – possibly leading to highly disruptive impacts as outlined above.
The KA-SAT event and risks of spillover

On February 24, around 04:00 UTC – around the time of the start of the Russian invasion of Ukraine – several Viasat KA-SAT modems ceased functioning due to yet another wiper attack (AcidRain). This attack is officially reported to have affected Ukrainian military communications and is unlikely to be a coincidence considering the timing. No matter who orchestrated it, this is a rare example of a cyberattack providing operational support for a physical military operation, which in itself makes it significant in terms of understanding modern warfare. It is however unclear whether this provided any brief or lasting tactical value: as far as we are aware, other means of communication (e.g., 3G, 4G) remained available in the same timeframe.

This attack also disabled the remote control of wind turbines located in Germany, raising concerns about potential spillover of the conflict into other European countries. It is unclear why routers belonging to a German customer were affected: maybe the means of distribution used to spread the malware did not allow for granular targeting, or maybe the operators made a mistake. In any case, we have little reason to believe that there was any intent to provoke adverse effects outside Ukraine.

Whenever the spillover question comes up, it is usually associated with memories of the NotPetya incident (fake-ransomware distributed through a supply-chain attack in Ukraine in 2017). It is worth pointing out that NotPetya contained self-spreading code and its uncontrollable spread was powered by a very potent Windows exploit. No such thing has been observed in any of the malware families used in Ukraine recently. As such, we estimate the risk of witnessing another NotPetya-level event as very low.

One final point of interest is whether it is likely that similar events will take place during the remainder of the conflict. It is important to understand that ICS attacks are far from trivial to organize due to the complex nature of systems they affect and the fact that such machines are typically not connected to the internet. This means that an attacker would have to breach the victim’s network first, figure out where the target appliances are located, and finally devise an attack scenario involving specific equipment it likely does not own a copy of to conduct experiments. In other words, highly-disruptive attacks require meticulous preparation that range in the order of weeks – if not months. In conclusion such attacks would only be achievable a long time from now – unless attackers already present in strategic networks chose not to leverage this access to date.

Summing up the above-mentioned discussion, our key takeaways are the following:

  1. The Viasat attack is a very significant cyber event. It is hard to tell whether others will take place in the near future, but that probability increases significantly as time passes.
  2. The recent Industroyer2 discovery indicates that there may be a desire among threat actors to conduct highly-disruptive attacks soon.
  3. The threat campaigns observed so far have been very focused on Ukraine.
  4. Any observed spillover to date should be interpreted as accidental, and the potential for uncontrolled malware spread has so far been non-existent.
Takeaways from Kaspersky for international discussions on stability in cyberspace

As we are still transitioning from one phase of the conflict to another, we expect that some of the observations outlined in this report will become less accurate. Though the various cyberattacks observed so far have been disorganized and uncoordinated, we consider that more structured activity may surface soon amid this constant background noise.

As the conflict drags on, we predict that more sophisticated threat actors will get involved and refocus their intelligence collection activities. For this reason, we advise companies all around the world to prepare for a resurgence of ransomware attacks.

Taking a broader perspective on the threat landscape these days in the light of ongoing inter-state negotiations at the UN, the international community more than ever needs to further advance the operationalization of the agreed non-binding cyber norms and confidence-building measures (CBMs), and extend them to relevant stakeholders. In particular, it is important to advance discussions on cross-border cooperation between the CERT/CSIRT community and relevant security experts to ensure that they can do their job – protecting victims of cyber incidents – despite any political or geopolitical context. And in this regard, one of the core aspects we at Kaspersky have continuously been advocating[2] for is developing effective interaction between national points of contacts (PoCs) as well as points of contacts from relevant stakeholders (such as the private sector, owners and manufacturers of ICTs, cybersecurity experts and others), which can be utilized during significant cyber events.

One of the open questions that remains for the international community is clarification on the protection of civilian infrastructure in cyberspace. In this regard, more information and transparency from states on how they interpret the application of international law and, particularly, international humanitarian law, is urgently needed to provide effective safeguards to civilian infrastructure in cyberspace. The ongoing efforts, such as those of the International Committee of the Red Cross (ICRC), to signal legal protection through digital emblems seems an important contribution in this regard.

Finally, the public core of the internet, whose security and availability is essentially vital for digitized societies and economies, needs to be discussed further and acknowledged by UN Member States and the larger international community. The current acute geopolitical tensions pose a serious risk of further fragmenting the baseline fundamental internet infrastructure, which was initially created and designed in a multistakeholder, decentralized spirit. These factors have the potential to create greater insecurity affecting many users of ICTs, and therefore, more than ever require international dialogue among all states to preserve cyberspace.

We have also previously shared our views to the UN cyber-dialogue (i.e. UN Open-Ended Working group) which can be found at the official web-page of the UN OEWG.

 

[1] For instance, https://www.politico.com/news/2022/01/28/russia-cyber-army-ukraine-00003051 or https://www.csis.org/analysis/russias-possible-invasion-ukraine

[2] Eight practical suggestions to the UN OEWG from a cybersecurity research perspective, Kaspersky’s submission in December 2021 https://documents.unoda.org/wp-content/uploads/2021/12/Kaspersky-submission-UN-OEWG_December-2021.pdf

2022. május 16.

HTML attachments in phishing e-mails

The use of embedded HTML documents in phishing e-mails is a standard technique employed by cybercriminals. It does away with the need to put links in the e-mail body, which antispam engines and e-mail antiviruses usually detect with ease. HTML offers more possibilities than e-mail for camouflaging phishing content.

There are two main types of HTML attachments that cybercriminals use: HTML files with a link to a fake website or a full-fledged phishing page. In the first case, the attackers can not only hide a link in the file, but also automatically redirect the user to the fraudulent site when they open this file. The second type of HTML attachment makes it possible to skip creating the website altogether and save on hosting costs: the phishing form and the script that harvests the data are embedded directly in the attachment. In addition, an HTML file, like an e-mail, can be modified according to the intended victim and attack vector, allowing for more personalized phishing content.

Fig.1. Example e-mail with an HTML attachment

Structure of phishing HTML attachments

Phishing elements in HTML attachments are usually implemented using JavaScript, which handles redirecting the user to a phishing site or collecting and sending credentials to scammers.

Fig. 2. Phishing HTML page and its source code

Typically, the HTML page sends data to a malicious URL specified in the script. Some attachments consist entirely (or mostly) of a JS script.

In the e-mail source code, the HTML attachment looks like plain text, usually Base64-encoded.

Fig. 3. HTML attachment in e-mail source code

If a file contains malicious scripts or links in plaintext, the security software can quickly parse and block it. To avoid this, cybercriminals resort to various tricks.

JavaScript obfuscation

JavaScript obfuscation is one of the most common techniques used to disguise HTML attachments. To prevent the URL in the file from being quickly spotted and blocked, phishers obfuscate either the phishing link itself or the entire script, and sometimes the whole HTML file. In some cases, cybercriminals obfuscate the code manually, but often they use ready-made tools, of which many are freely available, such as JavaScript Obfuscator.

For example, opening the HTML attachment in the phishing e-mail supposedly from HSBC Bank (see Fig. 1) in a text editor, we see some pretty confusing JS code, which, it would seem, hints neither at opening a link nor at any other meaningful action.

Fig. 4. Example of obfuscation in an HTML attachment

However, it actually is an obfuscated script that redirects the user to a phishing site. To disguise the phishing link, the attackers used a ready-made tool, allowing us to easily deobfuscate the script.

Fig. 5. Deobfuscated script from an attachment in an e-mail seemingly from HSBC Bank: link for redirecting the user

If a script, link, or HTML page is obfuscated manually, it is much harder to restore the original code. To detect phishing content in such a file, dynamic analysis may be required, which involves running and debugging the code.

Encoding

Sometimes attackers use more interesting methods. In one phishing e-mail, for instance, we found an unusual HTML attachment. As in the example above, it contained JavaScript. Because the code was so compact, one might think it was doing the same as the code in the fake HSBC e-mail — that is, redirecting the user to a phishing site. But upon running it, we found a full-fledged phishing page encoded in this small script.

Fig. 6. HTML file using the unescape() method — the source code of the file contains only five lines, one of which is empty

Fig. 7. Phishing page in the HTML attachment

The cybercriminals used an interesting trick that involves the deprecated JS method unescape(). This method substitutes the “%xx” character sequences with their ASCII equivalents in the string that is passed to it. Running the script and viewing the source code of the resulting page, we see plain HTML.

Fig. 8. The resulting HTML file

Instead of unescape(), JavaScript now uses the decodeURI() and decodeURIComponent() methods, yet most modern browsers still support unescape(). We cannot say for sure why the attackers chose a deprecated method, but it could be because modern methods are more likely to be interpreted and detected by antispam engines.

Statistics

In the first four months of 2022, Kaspersky security solutions detected nearly 2 million e-mails containing malicious HTML attachments. Nearly half of them (851,328) were detected and blocked in March. January was the calmest month, with our antispam solutions detecting 299,859 e-mails with phishing HTML attachments.

Number of detected e-mails with malicious HTML attachments, January–April 2022 (download)

Conclusion

Phishers deploy a variety of tricks to bypass e-mail blocking and lure as many users as possible to their fraudulent sites. A common technique is HTML attachments with partially or fully obfuscated code. HTML files allow attackers to use scripts, obfuscate malicious content to make it harder to detect, and send phishing pages as attachments instead of links.

Kaspersky security solutions detect HTML attachments containing scripts regardless of obfuscation.

2022. május 11.

New ransomware trends in 2022

Ahead of the Anti-Ransomware Day, we summarized the tendencies that characterize ransomware landscape in 2022. This year, ransomware is no less active than before: cybercriminals continue to threaten nationwide retailers and enterprises, old variants of malware return while the new ones develop. Watching and assessing these tendencies not only provides us with threat intelligence to fight cybercrime today, but also helps us deduce what trends may see in the months to come and prepare for them better.

In the report, we analyze what happened in late 2021 and 2022 on both the technological and geopolitical levels and what caused the new ransomware trends to emerge. First, we will review the trend of cross-platform ransomware development that is becoming more and more widespread among threat actors. Next, we will concentrate on how the ransomware gangs continue to industrialize and evolve into real businesses by adopting techniques of benign software companies. Last, we will delve into how ransomware gangs put on a political hat and engaged in the conflict between Russia and Ukraine.

Trend #1: Threat actors are trying to develop cross-platform ransomware to be as adaptive as possible

As a consequence of the Big Game Hunting (BGH) scheme that has become increasingly popular over the years, cybercriminals have been penetrating more and more complex environments where a wide variety of systems are running. In order to cause as much damage as possible and to make recovery very difficult (if not impossible), they try to encrypt as many systems as possible. This means that their ransomware should be able to run on different combinations of architectures and operation systems.

One way to overcome this is to write the ransomware in a “cross-platform programming language” such as Rust or Golang. There are a few other reasons to use a cross-platform language. For example, even though the ransomware might be aimed at one platform at the moment, writing it in a cross platform makes it easier to port it to other platforms. Another reason is that analysis of cross-platform binaries is a bit harder than that of malware written in plain C.

In our crimeware reporting section on the Threat Intelligence Platform we cover some of these ransomware variants that work on different platforms. The following are the most important highlights from these reports.

Conti cross-platform functionality

Conti is a group conducting BGH, targeting a wide variety of organizations across the globe. Just like many other BGH groups, it uses the double extortion technique as well as an affiliate-based structure.

We noticed that only certain affiliates have access to a Linux variant of the Conti ransomware, targeting ESXi systems. It supports a variety of different command-line arguments that can be used by the affiliate to customize the execution. The version for Linux supports the following parameters:

Parameter Description –detach The sample is executed in the background and it is detached from the terminal –log For debugging purposes, with a filename specified, Conti will write the actions to a log file –path Conti needs this path to encrypt the system. With the selected path, the ransomware will encrypt the entire folder structure recursively –prockiller This flag allows the ransomware to kill those processes that have the selected files for encryption –size Function not implemented –vmlist Flag used to skip virtual machines during the encryption process –vmkiller It will terminate all the virtual machines for the ESXi ecosystem

Conti parameters (Linux ESXi)

BlackCat cross-platform functionality

BlackCat started offering their services in December 2021 on the dark web. Although the malware is written in Rust from scratch, we found some links to the BlackMatter group as the actor used the same custom exfiltration tool that had been observed earlier in BlackMatter activities. Due to Rust cross-compilation capabilities, it did not take long time for us to find BlackCat samples that work on Linux as well.

The Linux sample of BlackCat is very similar to the Windows one. In terms of functionality, it has slightly more, as it is capable of shutting down the machine and deleting ESXi VMs. Naturally, typical Windows functionality (e.g., executing commands through cmd.exe) was removed and replaced with the Linux equivalent so the ransomware still holds the same functionality on the different platforms it operates on.

Deadbolt cross-platform functionality

Deadbolt is an example of ransomware written in a cross-platform language, but currently aimed at only one target – QNAP NAS systems.  It is also an interesting combination of Bash, HTML and Golang. Deadbolt itself is written in Golang, the ransom note is an HTML file that replaces the standard index file used by the QNAP NAS, and the Bash script is used to start the decryption process if the provided decryption key is correct. There is another peculiar thing about the ransomware: it doesn’t need any interaction with attackers because a decryption key is provided in a Bitcoin transaction OP_RETURN field. The Bash file is shown below.

#!/bin/sh echo "Content-Type: text/html" echo "" get_value () { echo "$1" | awk -F "${2}=" '{ print $2 }' | awk -F '&' '{ print $1 }' } not_running() { echo '{"status":"not_running"}'; exit; } PID_FILENAME=/tmp/deadbolt.pid STATUS_FILENAME=/tmp/deadbolt.status FINISH_FILENAME=/tmp/deadbolt.finish TOOL=/mnt/HDA_ROOT/722 CRYPTDIR=/share if [ "$REQUEST_METHOD" = "POST" ]; then DATA=`dd count=$CONTENT_LENGTH bs=1 2> /dev/null`'&' ACTION=$(get_value "$DATA" "action") if [ "$ACTION" = "decrypt" ]; then KEY=$(get_value "$DATA" "key") if [ "${#KEY}" != 32 ]; then echo "invalid key len" exit fi K=/tmp/k-$RANDOM echo -n > $K for i in `seq 0 2 30`; do printf "\x"${KEY:$i:2} >> $K done SUM=$(sha256sum $K | awk '{ print $1 }') rm $K if [ "$SUM" = "915767a56cb58349b1e34c765b82be6b117db7e784c3efb801f327ff00355d15" ]; then echo "correct key" exec >&- exec 2>&- ${TOOL} -d "$KEY" "$CRYPTDIR" elif [ "$SUM" = "93f21756aeeb5a9547cc62dea8d58581b0da4f23286f14d10559e6f89b078052" ]; then echo "correct master key" exec >&- exec 2>&- ${TOOL} -d "$KEY" "$CRYPTDIR" else echo "wrong key." fi elif [ "$ACTION" = "status" ]; then if [ -f "$FINISH_FILENAME" ]; then echo '{"status":"finished"}' exit fi if [ -f "$PID_FILENAME" ]; then PID=$(cat "$PID_FILENAME") if [ "$PID" = "" ]; then not_running fi if [ ! -d "/proc/$PID" ]; then not_running fi fi if [ -f "$STATUS_FILENAME" ]; then COUNT=$(cat "$STATUS_FILENAME") echo '{"status":"running","count":"'${COUNT}'"}' else not_running fi else echo "invalid action" fi else echo

Trend #2: The ransomware ecosystem is evolving and becoming even more “industrialized”

Just like legitimate software companies, cybercriminal groups are continually developing their tool kit for themselves and their customers – for example, to make the process of data exfiltration quicker and easier. Another trick that threat actors sometimes pull off is rebranding their ransomware, changing bits and pieces in the process. Let’s delve into the new tools and “business” strategies ransomware gangs are employing these days.

Evolution of Lockbit, one of the most successful RaaS since 2019

Lockbit started in 2019, and then in 2020, its affiliate program was announced. Over time, the group has been developing actively, as can be seen in the figure below:

When the group started with its malicious activities, it did not have any leak portal, was not doing double extortion, and there was no data exfiltration before data encryption.

The infrastructure was also improved over time. Like other ransomware families, Lockbit’s infrastructure suffered several attacks that forced the group to implement some countermeasures to protect its assets. These attacks included hacking of the Lockbit’s administration panels and DDOS-attacks to force the group to shut down its activity.

The latest security addition made by the Lockbit developers is a “waiting page” that redirects users to one of the available mirrors.

StealBIT: custom data exfiltration tool utilized by Lockbit ransomware

Data exfiltration, which is used when groups apply double extortion, is possible in many different ways. Initially cybercriminals used publicly available tools such as Filezilla, and then later replaced them with their own custom tools such as StealBIT. There are a few reasons for this:

  • Publicly available tools are not always known for their speed. For ransomware operators speed is important, because the longer it takes to exfiltrate data, the greater the chance that ransomware operators will be caught,
  • Flexibility is another reason. Standard tools are not designed with the requirements for ransomware operators in mind. For example, with most tools it is possible to upload the data only to one host. If that host is down, another host must be specified manually. There is always the chance that criminal infrastructure will be taken down or fall into the hands of LEAs. To provide more flexibility and overcome these limitations, StealBIT has a list of hardcoded hosts the data can be exfiltrated to. If the first one is down for some reason, the second host is tried.
  • Ransomware operators have requirements that are not met with publicly available tools. One such requirement is to exfiltrate not all the data, but only the interesting data. In StealBIT this is implemented by having a hardcoded list of extensions that should be extracted. Another functionality is that the affiliate ID is sent when data is uploaded.

In the figure below, the data exfiltration is compared (by the authors) to that of other tools:

SoftShade deploys Fendr exfiltration client

Fendr, also known as Exmatter, is a malicious data exfiltration tool used by several ransomware groups such as BlackMatter, Conti and BlackCat. Fendr was not seen in all the BlackMatter and Conti incidents we observed, but we did see them in all BlackCat-related incidents. Therefore, we believe that Fendr was used by a crimeware group that participated in a few affiliate schemes.

Internally, SoftShade developers called it “file_sender” and “sender2”. The malware is written in C# .Net, and was frequently deployed alongside BlackMatter and Conti malware as a packed .Net executable, but most samples deployed alongside Conti and BlackCat ransomware were not packed (except for one Conti incident in November 2021). It is designed to efficiently manage large amounts of selective file collection and upload activity on a victim system and then remove itself from the system. Fendr is built with several open-source libraries, and its design is clearly the result of maturing, professionalised experience in the ransomware space, handling arbitrary large file volumes across various Windows systems and networks.

Also interesting is the deployment and packaging of Fendr and their chosen ransomware. Across each affiliate scheme (except for one Conti incident), the ransomware and Fendr are delivered simultaneously across a network to many systems as “v2.exe” and “v2c.exe”, or as “v2.exe” and “sender2.exe”. This simultaneous push seems to prioritize coordination and efficiency over raising risk of detection. In a Conti-related exception, it appears that a Fendr variant was pushed across the network to many systems as “\\hostname\$temp\sender2.exe”.

Trend #3 Ransomware gangs take sides in geopolitical conflicts

Cybercriminals use news headlines to achieve their malicious goals. We saw this during the initial phase of the global Covid-19 pandemic, when there was a surge of Covid-19-related spam and phishing e-mails. The same happened with the geopolitical conflict in Ukraine in 2022.

There is, however, one big difference. The usage of the pandemic wasn’t personal because it was just another topic from a long list of holidays, events, incidents, etc. In the case of the conflict, threat actors decided to choose sides, and this makes the topic much more personal.

Typically in a geopolitical conflict such as this one, one would associate the source of the cyberattacks with state-sponsored threat actors. This is not always true, as we have noted a new type of engagement in this conflict: cybercrime forums and ransomware groups reacting to the situation and taking action.

There have been consequences: for example, the disclosure of the Conti-related information. We also see this in malware variants that have been recently deployed. Specific variants that are exclusively found in Ukraine or in Russia often choose sides, either against Ukraine or against Russia. Let’s look at the most notable ransomware gang activity around the conflict.

Ransomware gangs taking sides

The most significant reaction of all is likely the Conti ransomware group. On February 25, Conti published a message on its news site with a statement that it would retaliate with full capabilities against any “enemy’s” critical infrastructure if Russia became a target of cyberattacks. This is probably a rare example of a cybercriminal group supporting a nation-state publicly. As a result, an allegedly Ukrainian member shared chats and other internal Conti-related information online.

Conti ransomware group posting a warning message on its news site

On the other side there are other communities such as Anonymous, IT Army of Ukraine and Belarusian Cyber Partisans openly supporting Ukraine.

The table below highlights the position of several groups and forums during the beginning of the conflict.

Open UA support Open RU support Neutral RaidForums Conti Lockbit Anonymous collective CoomingProject IT Army of Ukraine Stormous Belarusian Cyber Partisans Freeud: brand-new ransomware with wiper capabilities

Kaspersky recently discovered Freeud, a brand-new ransomware variant that supports Ukraine. The Freeud’s ransom note says — not very subtly — that Russian troops should leave Ukraine. The choice of words and how the note is written suggest that it is written by a native Russian speaker. Other language artifacts that we found suggest the authors are non-native English speakers. For example, the word “lending” was found several times in places where the writers should have used “landing”.

The political view of the malware authors is expressed not only through the ransom note but also through the malware features. One of them is wiping functionality. If the malware contains a list of files, instead of encrypting, the malware wipes them from the system.

Another property that stands out is the high quality of the malware, highlighted by the encryption methods applied and the way multithreading is used.

Elections GoRansom (HermeticRansom) covering up destructive activity

GoRansom was found at the end of February in Ukraine at the same time the HermeticWiper attack was carried out. We covered in a post published in March. There are a few things that GoRansom does that are different from other ransomware variants:

  • It creates hundreds of copies of itself and runs them.
  • The function naming scheme refers to the US presidential elections.
  • There is no obfuscation and it has pretty straightforward functionality.

Self-copies made by HermeticRansom

For these reasons we believe it was created to boost the effectiveness of cyberoperations in Ukraine.

Stormous ransomware joins the Ukraine crisis with a PHP malware

It is not very often that we come across malware written in PHP. Most of the time when we analyze PHP code it is either a web shell or some botnet panel code. Stormous is one of the few exceptions. Aside from being a backdoor, it also contains ransomware functionality. The threat actor hunts for web servers supporting PHP technology and weaknesses that are vulnerable to web apps.

An analysis of the malware suggests the threat actor is Arabic speaking from a North African region. Stormous sides with Russia:

The PHP script provides a web interface for remote interaction over HTTP, where several encryption options are offered: “OpenSSL”, “Mcrypt” and “Xor”. It is quite possible that these three were developed into the script because of external considerations at the target, like the version of PHP running on the server (some extensions are deprecated or unavailable from one version to the next).

DoubleZero wiper targets Ukraine

The DoubleZero wiper was initially published by the Ukrainian CERT on the March 22. It is a completely new wiper written in C#; it is not similar to any other known wipers and targets only Ukrainian entities. The binary itself is heavily obfuscated by an unknown C# obfuscator. Classes and method names are randomly generated.

Obfuscation

Control flow is organized using a function-flattening mechanism created to slow down analysis of malicious code.

Obfuscated decompiled code

When all the preparations are over, malware starts its wiping operations. First, it checks for user (nonsystem files) by comparing folder names with a hardcoded list and starts wiping them using quite an interesting implementation of NtFsControlFile API.

Hardcoded list of folders

File wiping

The NtFsControlFile routine sends a control code directly to a specified file system or file system filter driver, causing the corresponding driver to perform the specified action. As seen in the screenshot, the control code has the value of 622792 (0x980C8in hex), which corresponds to the FSCTL_SET_ZERO_DATA control code of the FCSTL structure. Data in the file will be overwritten by ZERO values that are pointed by intPtr2 variable. If the function fails, the wiper will execute the standard .Net FileStream.Write function for the same purpose. Then malware wipes the system files found.

Malware then deletes the Windows registry tree subkeys in HKU, HKLM and kills the “lsass” process to reboot the infected machine.

Conclusion

As the saying goes, forewarned is forearmed, and this also applies to cybersecurity. In recent years, ransomware groups have come a long way from being scattered gangs to businesses with distinctive traits of full-fledged industry. As a result, attacks have become more sophisticated and more targeted, exposing victims to more threats. Monitoring the activity of ransomware groups and their developments provides us with threat intelligence that enables better defences.

We witnessed cross-platform ransomware written in Rust and Golang becoming a weapon of the “new-generation” of ransomware groups. Thanks to the software’s flexibility, the attacks can be conducted on a larger scale with no regard to what operating system the victim is using. This flexibility allows ransomware gangs to quickly adapt their strategy when carrying out attacks, diversify their targets and affect more victims.

Second, we witnessed a significant development in how ransomware groups rebuild their inner processes to facilitate their activity increasingly resembling legitimate software developers. While their efforts in branding (and re-branding) aren’t entirely new, the segmentation of their ‘businesses’ as well creation of new exfiltration tools point towards maturing Ransomware-as-a-Service industry, where the ransomware owner simplifies the job for the operators as much as possible.

Finally, ransomware group’s engagement in the conflict between Russia and Ukraine have set a precedent in the way cybercriminals operate in relation to geopolitics. While it is widely seen that advanced persistent threat (APT) actors are usually the ones to take on the mission of carrying out advanced attacks in the interest of the state, we now see that ransomware actors voluntarily engage in such activities as well, often leading to quite destructive consequences.

These tendencies are already affecting the way we need to defend against ransomware today. Ahead of the Anti-Ransomware Day, Kaspersky encourages organization to follow these best practices that help them safeguard against ransomware:

  • Always keep software updated on all the devices you use, to prevent attackers from infiltrating your network by exploiting vulnerabilities.
  • Focus your defence strategy on detecting lateral movements and data exfiltration to the internet. Pay special attention to the outgoing traffic to detect cybercriminals’ connections. Set up offline backups that intruders cannot tamper with. Make sure you can quickly access them in an emergency when needed.
  • Enable ransomware protection for all endpoints. There is a free Kaspersky Anti-Ransomware Tool for Business that shields computers and servers from ransomware and other types of malware, prevent exploits and is compatible with already installed security solutions.
  • Install anti-APT and EDR solutions, enabling capabilities for advanced threat discovery and detection, investigation and timely remediation of incidents. Provide your SOC team with access to the latest threat intelligence and regularly upskill them with professional training. All of the above is available within Kaspersky Expert Security framework.
  • Provide your SOC team with access to the latest threat intelligence (TI). The Kaspersky Threat Intelligence Portal is a single point of access for the company’s TI, including crimeware, providing cyberattack data and insights gathered by Kaspersky spanning over 20 years. To help businesses enable effective defences in these turbulent times, Kaspersky announced access to independent, continuously updated and globally-sourced information on ongoing cyberattacks and threats, at no charge. Request your access to this offer here: crimewareintel[at]kaspersky.com.
2022. május 6.

Mobile subscription Trojans and their little tricks

Billing fraud is one of the most common sources of income for cybercriminals. There are currently a number of known mobile Trojans specializing in secretly subscribing users to paid services. They usually pay for legitimate services in a user’s name and scammers take a cut from the money billed. These types of subscription fees tend to be fleeced from the phone balance.

A user who is genuinely interested in subscribing to a service normally needs to visit the content provider’s website and click “subscribe.” As Trojan apps are capable of simulating a click on this icon, service providers sometimes require a confirmation code sent in a text message to complete subscription. In other cases, marketplaces try to make it harder to automate subscription by using a CAPTCHA, while others analyze traffic and block subscription scams using anti-fraud solutions. Yet there are some types of malware which can bypass at least some of these protections.

Jocker: Text message thief in Google Play

Trojans from the Trojan.AndroidOS.Jocker family can intercept codes sent in text messages and bypass anti-fraud solutions. They’re usually spread on Google Play, where scammers download legitimate apps from the store, add malicious code to them and re-upload them to the store under a different name. The trojanized apps fulfill their original purposes in most cases, and the user won’t suspect they are a source of threats.

To bypass vetting on Google Play, the Trojan monitors whether it’s gone live. The malicious payload will remain dormant while the app is stalled at the vetting stage.

Checking availability on Google Play

While trojanized apps are removed from the store on a daily basis, it’s constantly flooded by new ones to take their place. The screenshots below show examples of apps for messaging, monitoring blood pressure, and document scanning using your phone’s camera, all of which were still available on Google Play at the end of February.

From left to right: messaging app (d3d8dbb9a4dffc1e7007b771e09b5b38), blood pressure app (ab168c7fbfa2f436d7deb90eb5649273), and document scanning app (77a6c1c2f782c699d1e73a940f36a527)

Jocker functions

Once the infected app is installed on your device, it requests access to text messages if its legitimate functionality requires it — for example, if it poses itself as a messaging app. Otherwise, it requests access to notifications. Pop-up notifications about messages received also contain the text of these messages, so access to notifications allows the malware to intercept the confirmation codes to complete subscription.

Once launched, the malware downloads and launches a new file which inherits permissions from the infected app. The earliest versions of the Trojan downloaded the subscription app straight away. But presently Jocker is a staged downloader.

Downloading of Jocker’s stage 1 payload. The scammers call their software SDK

Launch of the first stage

The scammers avoid detection by using different options for the initial payload download and launch. The entire process can involve a staged download of four files to deliver the final payload to the infected device, where only the last file is responsible for the main aim of subscribing the user.

Launch of stage 2 payload (SDK)

Launch of the main payload (SDK) for subscription

The main payload basically follows a standard scheme: it receives a URL of the subscription page from the C&C server and opens it in an invisible window. Once the page is loaded, the Trojan injects it with scripts which request a subscription and confirm it using an intercepted code from the text message.

Code of Jocker’s main payload

Main “SDK” also has code for bypassing anti-fraud systems. For example, the malware can modify the X-Requested-With header in an HTTP request, which can be used to identify the particular app requesting a subscription. Jocker can also block or substitute anti-fraud scripts.

Substitution of anti-fraud script

Geography of Jocker attacks

From January 2021 to March 2022, Jocker most frequently attacked users in Saudi Arabia (21.20%). Poland came second (8.98%) with Germany in third place (6.01%).

Geographical distribution of Kaspersky users attacked by the Jocker family, January 2021 — March 2022 (download)

The other countries in the TOP 10 where most users encountering Jocker were located were Malaysia (5.71%), the United Arab Emirates (5.50%), Switzerland (5.10%), South Africa (4.12%), Austria (3.96%), Russia (3.53%), and China (2.91%).

MobOk skirts CAPTCHA

Another subscription Trojan identified as Trojan.AndroidOS.MobOk was also first detected in an infected app on Google Play. However, this malware is now mainly spread as the payload of another Trojan called Triada, which is present in preinstalled apps (usually system apps) on certain smartphone models. It’s also built into popular apps, such as the APKPure app store and a widely used modification of WhatsApp Messenger.

Trojan.AndroidOS.MobOk works on a principle similar to the malware described in the previous section. A subscription page is opened in an invisible window and a confirmation code stolen from a text message is stealthily entered there. If the malware is downloaded by Triada, it inherits Triada’s access to text messages, but if MobOk is spread by itself, it will request access to notifications, similarly to Jocker.

MobOk differs from Jocker in its additional capability of bypassing CAPTCHA. The Trojan deciphers the code shown on the image by sending it to a special service.

Sending an image to a recognition service and receiving the recognized code

Geography of MobOk attacks

The country where users encountered MobOk Trojans most frequently from January 2021 to March 2022 was Russia (31.01%). Second place is occupied by India (11.17%), closely followed by Indonesia (11.02%).

Geographical distribution of users attacked by MobOk family, January 2021 — March 2022 (download)

Fourth and fifth place were taken by Ukraine (8.31%) and Algeria (5.28%). The other countries in the TOP 10 where the Trojan was most active were Mexico (2.62%), Brazil (1.98%), Germany (1.63%), Turkey (1.43%), and Malaysia (1.27%).

Vesub — beware of fake apps

A malware called Trojan.AndroidOS.Vesub is spread through unofficial sources and imitates popular games and apps like GameBeyond, Tubemate, Minecraft, GTA5 and Vidmate.

Examples of fake apps

Most of the apps completely lack any legitimate functionality. They begin subscribing straight after they’re launched, while the user sees a loading window. However, there are some examples such as a fake GameBeyond app where the detected malware was accompanied by a random set of working games.

The subscription process used by Vesub is similar to the previous examples: the malware opens an invisible window, requests a subscription, and enters a code received in a text message.

Geography of Vesub attacks

Two out of every five users who encountered Vesub were in Egypt (40.27%). The family was also active in Thailand (25.88%) and Malaysia (15.85%).

Geographical distribution of users attacked by the Vesub family, January 2021 — March 2022 (download)

GriftHorse.l: read the small text

All of the apps described above subscribe users to legitimate third-party services, even if the user doesn’t need them. However, there are other forms of malware which subscribe users to the app authors’ own “service.”

You can end up subscribing to one of these services by simply not reading the user agreement carefully enough. For example, apps which have recently been spread intensively on Google Play offer to tailor personal weight-loss plans for a token fee.

Once launched, the app asks you to fill out a questionnaire.

A page then opens to inform the user that a personal plan is being generated.

Then all you need to do is pay for the service and receive your weight-loss plan, which the scammers promise to send to your email address.

If you scroll down to the bottom of the page, you’ll see that the “service” charges a subscription fee with automatic billing. This means money will be deducted from the user’s bank account on a regular basis, needing no repeat confirmation from the user.

The fact that the app subscribes users to automatic billing is confirmed in the reviews section on Google Play. Moreover, many users complain they were unable to cancel the subscription directly through the actual app, while others mention they never received a weight-loss plan after paying the subscription fee.

Kaspersky solutions detect these apps as Trojan.AndroidOS.GriftHorse.l. Our researchers also detected websites that deploy a similar subscription scheme (article in Russian). These websites offered access to a wider pool of materials, such as training courses on office suites or online marketplace trading.

Geography of GriftHorse.l attacks

We observed the activity of Trojan GriftHorse.l from 25 January 2022. Kaspersky solutions detected most instances of the Trojan on devices owned by users in Russia (81.37%). The country which came in second for the most users affected was Saudi Arabia (6.07%), with Egypt (1.91%) in third place.

Geographical distribution of users attacked by GriftHorse.l Trojan, 25 January 2022 — 31 March 2022 (download)

GriftHorse.ae: don’t give out your number!

The Trojan detected as Trojan.AndroidOS.GriftHorse.ae may belong to the same family as GriftHorse.l, but it behaves in a completely different way. The malware poses as apps for recovering deleted files, editing photos and videos, blinking the flash for incoming calls, navigation, document scanning, translation, and so on. Yet all these apps can do in practice is request a phone number under the pretense of a login, although clicking “login” will actually subscribe the user. This is the simplest form of subscription — it bills the cell phone account and all it needs to complete the process is the victim’s phone number. It remains unclear what exactly does the GriftHorse.ae Trojan subscribe the user to.

Fake login screen in an app

Like its relative, GriftHorse.ae is also spread through Google Play. Scammers upload a great number of similar apps to the marketplace in the hope that at least some of them will be available to users for a certain amount of time.

Geography of GriftHorse.ae attacks

Our radars picked up the GriftHorse.ae Trojan for the first time on 10 March 2022. Among the users who fell victim to attacks in less than a month, 43.57% were located in Russia, 22.95% in Saudi Arabia, and 6.14% in Oman.

Geographical distribution of users attacked by GriftHorse.ae Trojan, 10 March 2022 — 31 March 2022 (download)

Forth and fifth place were taken by users in Poland (4.39%) and Belarus (3.22%).

General statistics on Trojan subscribers

From January 2021 to March 2022, the most active of the subscription Trojans covered in this article was MobOk. It was encountered by 74.09% of the Kaspersky mobile solution users who were attacked by the malware mentioned in this piece. Joker Trojans were blocked on 17.16% of user devices, while the least active Trojans were from the families Vesub (3.57%) and GriftHorse (3.53% of users encountered GriftHorse.l and 2.09% encountered GriftHorse.ae). It’s still worth noting that GriftHorse is a new family and it’s only beginning to pick up momentum.

Share of users who encountered Trojans from specific families out of all users attacked by the subscription Trojans described in this article, January 2021— March 2022 (download)

Geography of subscription Trojan attacks

The majority of users who encountered subscription Trojans were located in Russia (27.32%), India (8.43%), Indonesia (8.18%), Ukraine (6.25%), and Saudi Arabia (5.01%).

Geographical distribution of users attacked by subscription Trojans, January 2021 — March 2022 (download)

Conclusion

Subscription Trojans can bypass bot detection on websites for paid services, and sometimes they subscribe users to scammers’ own non-existent services.

To avoid unwanted subscriptions, avoid installing apps from unofficial sources, which is the most frequent source of malware. You shouldn’t let your guard down when installing apps from Google Play either: read the reviews, read up on the developer, the terms of use and payment. For messaging choose a well-known app with positive reviews.

Even if you trust an app, you should avoid granting it too many permissions. Only allow access to notifications for apps that need it to perform their intended purposes — for example, to transfer notifications to wearable devices. Apps for something like themed wallpapers or photo editing don’t need access to your notifications.

Indicators of compromise (MD5)

Trojan.AndroidOS.Joker

d3d8dbb9a4dffc1e7007b771e09b5b38
ab168c7fbfa2f436d7deb90eb5649273
77a6c1c2f782c699d1e73a940f36a527
34c60a3034635cc19c110a14dcfd2436
8cccfb60aeeb726916f4937c0a702e6a

Trojan.AndroidOS.MobOk

b73d2205a2062a51727e22e25a168cef

Trojan.AndroidOS.Vesub

1b833cc7880d5f1986d53692b8a05e3c
2cfbbc61a71d38fc83c50dc18d569b77
6e07381626d69f4710d7979dff7bff2a
3395101b243993f4969c347e5feb8f65
aebe1da0134b40fdcfc3adea18a50b8a

Trojan.AndroidOS.GriftHorse.l

07d6d7a15b94a6697db66364f1e79a85
11a1446bd6265b66e13f097ecfd195d8

Trojan.AndroidOS.GriftHorse.ae

1b987b970d1274e44a66769c4a453462
1cefe439d7c533cf8ed689dd41ab35c4
1d264d1eff33cff04dd04680db13a7d0
1eb9c7af96fcefb9e6070ee8c1720aa3
1f3baf400abaafd99fd3c0d630ad75ea
3a9829a5a62dda630f6b1e2d3371f9ae
3cece1bcf65ec7befd5eef8aa2fc70cb
3ed41d81c15f6479ec0e0bca69c5c55f
4bd04b372cf9eb00230d761eafb02218
5a6b67fa0d911f4858b0f00dc46c58fd
5a7ab3c12c01e7c9c0a58ef7be536ca9
5b5427b6310480a23e64cebfb757fffe
5d9c9d7725ea4e47fc319384b2f88dad
5ddd4d0321a29a5e8699b703b4165df8
6b336d8e9b459d937046475945d0c976
06d5eea04cfaa637e6b78f2ff22b7e7a
6dba0f2972d412f768f1c332777753f9
6e76a7b223754a27197c73cb815505d6
6ede369b56d7f405849e0e2263fc5d95
6f6391157fe40d78be21a145cb8fdc0a
7ad06772f92688d331e994febe77d56f
7d068d99bab6873750fc81444980d084
7def5fccad7d3f9ef0c6f54140f63cf9
7eccd4b190bac4f9470afa975cdab5e2

2022. május 4.

A new secret stash for “fileless” malware

In February 2022 we observed the technique of putting the shellcode into Windows event logs for the first time “in the wild” during the malicious campaign. It allows the “fileless” last stage Trojan to be hidden from plain sight in the file system. Such attention to the event logs in the campaign isn’t limited to storing shellcodes. Dropper modules also patch Windows native API functions, related to event tracing (ETW) and anti-malware scan interface (AMSI), to make the infection process stealthier.

Besides event logs there are numerous other techniques in the actor’s toolset. Among them let us distinguish how the actor takes initial recon into consideration while developing the next malicious stages: the C2 web domain name mimicking the legitimate one and the name in use belonging to the existing and software used by the victim. For hosting the attacker uses virtual private servers on Linode, Namecheap, DreamVPS.

One more visible common approach is the use of a lot of anti-detection decryptors. Actor uses different compilers, from Microsoft’s cl.exe or GCC under MinGW to a recent version of Go. Also, to avoid detection, some modules are signed with a digital certificate. We believe it is issued by the actor, because our telemetry doesn’t show any legitimate software signed with it, only malicious code used in this campaign.

Regarding last stage Trojans: the actor decided not to stick to just one – there are HTTP and named pipe based ones. Obviously besides the event logs the actor is obsessed with memory injection – lots of RAT commands are related to it and are used heavily. Along with the aforementioned custom modules and techniques, several commercial pentesting tools like Cobalt Strike and NetSPI (ex-SilentBreak) are used.

Actually, as we don’t have commercial versions of the latter it’s hard to say which enumerated techniques came from the product and which are home-brewed. For sure, third-party code from GitHub is also in use: we registered at least BlackBone for legitimate processes in memory patching.

The infection chain

We started the research from the in-memory last stager and then, using our telemetry, were able to reconstruct several infection chains. What piqued our attention was the very targeted nature of the campaign and the vast set of tools in use, including commercial ones.

The variety of the campaign’s techniques and modules looks impressive. Let us divide it into classes to technically describe this campaign. Actually, we need to cover the following sets of modules: commercial pentesting suites, custom anti-detection wrappers around them and last stage Trojans.

Commercial tool sets SilentBreak Cobalt Strike Anti-detection wrappers Go decryptor with heavy usage of the syscall library. Keeps Cobalt Strike module encoded several times, and AES256 CBC encrypted blob. We haven’t previously observed Go usage with Cobalt Strike A library launcher, compiled with GCC under MinGW environment. The only possible reason for this stage is anti-detection AES decryptor, compiled with Visual Studio compiler Last stage RAT HTTP-based Trojan. Possible original names are ThrowbackDLL.dll and drxDLL.dll, but code is more complex than old publicly available version of SilentBreak’s Throwback Named pipes-based Trojan. Possible original names are monolithDLL.dll and SlingshotDLL.dll. Based on file names there is a possibility that last stage modules are parts of a commercial Slingshot version

Once again, some modules which we consider custom, such as wrappers and last stagers, could possibly be parts of commercial products. So now after some classification we are ready to analyze modules one by one.

Initial infection

The earliest phase of attack we observed took place in September 2021. The spreading of the Cobalt Strike module was achieved by persuading the target to download the link to the .rar on the legitimate site file.io, and run it themselves. The digital certificate for the Cobalt Strike module inside is below (during the campaign with the same one, 15 different stagers from wrappers to last stagers were signed):

Organization: Fast Invest ApS E-mail: sencan.a@yahoo.com Thumbprint 99 77 16 6f 0a 94 b6 55 ef df 21 05 2c 2b 27 9a 0b 33 52 c4 Serial 34 d8 cd 9d 55 9e 81 b5 f3 8d 21 d6 58 c4 7d 72

Due to the different infection scenarios for all the targeted hosts we will describe just one of the observed ones. Having an ability to inject code into any process using Trojans, the attackers are free to use this feature widely to inject the next modules into Windows system processes or trusted applications such as DLP.

Keeping in mind truncated process injections, and even mimicking web domain registration, we could describe the attack process as quite iterative: initial recon with some modules and then preparation of additional attacks.

Commercial tool sets

Regarding the commercial tools, traces of SilentBreak and Cobalt Strike toolset usage in this campaign are quite visible. Trojans named ThrowbackDLL.dll and SlingshotDLL.dll remind us of Throwback and Slingshot, which are both tools in SilentBreak’s framework, while the “sb” associated with the dropper (sb.dll) could be an abbreviation of the vendor’s name.

Here we want to mention that several .pdb paths inside binaries contain the project’s directory C:\Users\admin\source\repos\drx\ and other modules not named after SilentBreak, such as drxDLL.dll. However, encryption functions are the same as in the publicly available Throwback code.

Anti-detection wrappers

For the anti-detection wrappers, different compilers are in use. Besides MSVC, Go compiler 1.17.2 and GCC under MinGW have been used. Decryptors differ a lot; the features they contain are listed in the table below:

Anti-detection technique Usage Several compilers The same AES256 CBC decryption could be done with Go and C++ modules Whitelisted launchers Autorunned copy of WerFault.exe maps the launcher into process address space Digital certificate 15 files are signed with “Fast Invest” certificate. We didn’t observe any legitimate files signed with it Patch logging exports of ntdll.dll To be more stealthy, Go droppers patch logging-related API functions like EtwEventWriteFull in self-address space with empty functionality Keep shellcode in event logs This is the main innovation we observed in this campaign. Encrypted shellcode with the next stager is divided into 8 KB blocks and saved in the binary part of event logs C2 web domain mimicking Actor registered a web domain name with ERP in use title

This layer of infection chain decrypts, maps into memory and launches the code. Not all of them are worth describing in detail, but we will cover the Go decryptor launcher for Cobalt Strike. All corresponding hashes are listed in the appendix.

Function names in the main package are obfuscated. Main.init decodes Windows API function names from kernel32.dll and ntdll.dll libraries (WriteProcessMemory and other functions) related to event log creation. Each of these names in the binary are base64-encoded four times in a row. Using WriteProcessMemory, the dropper patches with “xor rax, rax; ret” code the following functions in memory: EtwNotificationRegister, EtwEventRegister, EtwEventWriteFull, EtwEventWriteFull, EtwEventWrite.

In Main.start the malware checks if the host is in the domain and only works if it’s true. Then it dynamically resolves the addresses of the aforementioned functions. The next stager is encrypted with AES256 (CBC mode), the key and IV are encoded with base64.

With such an approach, it requires the researcher to code some script to gather the encrypted parts of the next module. After decryption, to get the final portable executable, data has to be converted further.

Last stager types

Last stagers have two communication mechanisms – over HTTP with RC4 encryption and unencrypted with named pipes. The latter way is technically able to communicate with any network visible external host, but under Windows named pipes are built upon the SMB protocol, which would barely open for external networks. So these modules most probably serve for lateral movement.

Feature HTTP-based trojan Named pipes-based trojan C2 communication Active connection to a randomly chosen C2 from a hardcoded list Passive mode Encryption XOR-based, RC4 Plaintext Self version in beacon 1.1 No Natural language artifacts Unused argument “dave” No Command set Quite basic, 7 of them More profound, 20 of them Injection functionality Yes and much in use Yes and much in use Quite unusual among the commands Sleep time randomization: (random between 0,9 – 1,1) * sleep time Get minutes since last user input

After this introduction into the set of malware, we will now describe the infection chain: dropper injection with Cobalt Strike pentesting suite.

Dropper in DLL, search order hijacking

We start custom module analysis from the wrapper-dropper dynamic library. This code is injected into Windows processes such as explorer.exe. At its single entry point after being loaded into the virtual address space of the launcher process, the dropper removes files created by previous stages or executions.

Firstly, the module copies the original legitimate OS error handler WerFault.exe to C:\Windows\Tasks. Then it drops one of the encrypted binary resources to the wer.dll file in the same directory for typical DLL search order hijacking. For the sake of persistence, the module sets the newly created WerFault.exe to autorun, creating a Windows Problem Reporting value in the Software\Microsoft\Windows\CurrentVersion\Run Windows system registry branch.

The dropper not only puts the launcher on disk for side-loading, but also writes information messages with shellcode into existing Windows KMS event log

The dropped wer.dll is a loader and wouldn’t do any harm without the shellcode hidden in Windows event logs. The dropper searches the event logs for records with category 0x4142 (“AB” in ASCII) and having the Key Management Service as a source. If none is found, the 8KB chunks of shellcode are written into the information logging messages via the ReportEvent() Windows API function (lpRawData parameter). Created event IDs are automatically incremented, starting from 1423.

Launcher in wer.dll

This launcher, dropped into the Tasks directory by the first stager, proxies all calls to wer.dll and its exports to the original legitimate library. At the entry point, a separate thread combines all the aforementioned 8KB pieces into a complete shellcode and runs it. The same virtual address space, created by a copy of the legitimate WerFault.exe, is used for all this code.

To prevent WerFault continuing its error handling process, the DLL patches the launcher’s entry point with typical Blackbone trampolines

The way to stop the legitimate launcher’s execution isn’t traditional. In the main thread, wer.dll finds its entry point and patches it with a simple function. WaitAndExit() on the screenshot above would just call WaitForSingleObject() with the log gathering thread id and then exit, meaning no real WerFault.exe error handling code could ever be executed: the spoofed DLL mapped into its address space would block it.

Shellcode into Windows event logs

The launcher transmits control to the very first byte of the gathered shellcode. Here, three arguments for the next function are prepared:

  • Address of next stage Trojan. It is also contained within the data extracted from the event logs
  • The standard ROR13 hash of exported function name Load inside this Trojan (0xE124D840)
  • Addresses of the string “dave” and constant “4”, which become the arguments of the exported function, found by hash

The parsing of the next Windows portable executable to locate its entry point is quite typical. To make the next stage Trojan less visible, the actor wiped the “MZ” magic in its header. After calling the code at the Trojan’s entry point, the shellcode also searches for the requested export and invokes it.

Besides searching for the entry point and calling it, the shellcode also searches for a Trojan export by hardcoded hash and runs the found function with arguments “dave” and “4”

HTTP Trojan

For last stagers we will be a bit more detailed than for auxiliary modules before. The C++ module obviously used the code from SilentBreak’s (now NetSPI’s) Throwback public repository: XOR-based encryption function, original file name for some samples, e.g., ThrowbackDLL.dll, etc. Let us start here with the aforementioned Load() exported function. It’s just like the patching of WerFault above (the function waits on the main Trojan thread) but it ignores any parameters, so “dave” and “4” are unused. It is possible this launcher supports more modules than just this one, which would require parameters.

Target fingerprinting

The module decrypts C2 domains with a one- byte XOR key. In the case of this sample there is only one domain, eleed[.]online. The Trojan is able to handle many of them, separated by the “|” character and encrypted. For further communications over plain HTTP, the Trojan chooses a random C2 from this set with user agent “Mozilla 5.0”.

The malware generates a fingerprinting string by gathering the following information, also separated by “|’:

  • Values of MachineGUID from the SOFTWARE\Microsoft\Cryptography
  • Computer name
  • Local IP addresses obtained with GetAdaptersInfo
  • Architecture (x86 or x64)
  • OS version
  • Whether the current process has SeDebugPrivilege

The fingerprinter also appends “1.1” to the string (which could be the malware version) and the sleep time from the current config.

Encrypted HTTP communication with C2

Before HTTP communications, the module sends empty (but still encrypted) data in an ICMP packet to check connection, using a hardcoded 32-byte long RC4 key. Like any other strings, this key is encrypted with the Throwback XOR-based algorithm.

If the ping of a control server with port 80 available is successful, the aforementioned fingerprint data is sent to it. In reply, the C2 shares the encrypted command for the Trojan’s main loop.

Trojan commands Code Command features 0 Fingerprint the target again. 1 Execute command. The Trojan executes the received command in the new process and sends the result back to the C2. 2 Download from a URL and save to the given path. 3 Set a new sleep time. This time in minutes is used as a timeout if the C2 hasn’t replied with a command to execute yet. Formula for randomization is (random number between 0,9 – 1,1) * sleep time. 4 Sleep the given number of minutes without changing the configuration. 5 List processes with PID, path, owner, name and parent data. 6 Inject and run shellcode into the target process’ address space. To inject into the same process, the command argument should be “local”. Like the shellcode in the event logs, this one would run the provided PE’s entry point and as well as a specific export found by hash. 99 Terminates the session between trojan and C2.

Another Trojan in use during this campaign is named pipe-based and has a more profound command system, including privilege escalation, screenshotting, inactivity time measurement, etc. Here, we come to the infection chain end. We continue with another last stage Trojan type, which we observed injected into processes like edge.exe.

Named pipes-based Trojan

The Trojan location is C:\Windows\apds.dll. The original legitimate Microsoft Help Data Services Module library with the same name is in C:\Windows\System32. The main Trojan working cycle is in a separate thread. The malware also exports a Load() function, whose only purpose is to wait for a working thread, which is typical for this campaign’s modules.

First, the main trojan thread gets the original apds.dll and exports and saves it into an allocated new heap buffer right after the Trojan’s image in memory. Then the Trojan edits the self-exported functions data in a way that allows it to call the original apds.dll exports through the crafted stubs like the following, where the address is the one parsed from the real apds.dll:

48B8<addr> MOV RAX,<addr> FFE0 JMP RAX

This trampoline code is taken from the Blackbone Windows memory hacking library (RemoteMemory::BuildTrampoline function). DLL hijacking isn’t something new, we have seen such a technique used to proxy legitimate functions many times, but recreating self-exports with just short stubs to call the original legitimate functions is unusual.  The module then creates a duplex-named pipe, “MonolithPipe”, and enters its main loop.

Work cycle

After the aforementioned manipulations with exported functions, the module lightly fingerprints the host with architecture and Windows version information. The Trojan also initializes a random 11-byte ASCII string using the rare constant mentioned, e.g., here in the init_keys function. The result serves as a unique session id.

The malware connects to the hardcoded domain on port 443 (in this case https://opswat[.]info:443) and sends POST requests to submit.php on the C2 side. HTTPS connection options are set to accept self-signed certificates on the server side. The C2 communication in this case is encrypted with an RC4 algorithm with the Dhga(81K1!392-!(43<KakjaiPA8$#ja key. In the case of the named pipes- based Trojan, the common commands are:

Code Command features 0 Set the “continue” flag to False and stop working. 1 N/A, reserved so far. 2 Get time since the last user input in minutes. 3 Get current process information: PID, architecture, user, path, etc. 4 Get host domain and user account. 5 Impersonate user with credentials provided. 6 Get current process’s available privileges. 7 Execute command with the cmd.exe interpreter. 8 Test connection with a given host (address and port) using a raw TCP socket. 9 Get running processes information: path, owner, name, parent, PID, etc. 10 Impersonate user with the token of the process with a provided ID. 11 List files in directory. 12 Take a screenshot. 13 Drop content to file. 14 Read content from file 15 Delete file. 16 Inject provided code into process with the given name. 17 Run shellcode from the C2. 18 N/A, reserved so far. 19 Run PowerShell script. During this campaign we observed Invoke-ReflectivePEInjection to reflectively load Mimikatz in memory and harvest credentials.

We have now covered the three layers of the campaign. Interestingly, we observed a Trojan with a complete command set as in the table above, but still using RC4-encrypted HTTP communications with the C2 instead of named pipes. The last stage samples look like a modular platform, whose capabilities the actor is able to combine according to their current needs.

Infrastructure Domain IP First seen ASN eleed[.]online 178.79.176[.]136 Jan 15, 2022 63949 – Linode eleed[.]cloud 178.79.176[.]136 – 63949 – Linode timestechnologies[.]org 93.95.228[.]97 Jan 17, 2022 44925 – The 1984 avstats[.]net 93.95.228[.]97 Jan 17, 2022 44925 – The 1984 mannlib[.]com 162.0.224[.]144 Aug 20, 2021 22612  – Namecheap nagios.dreamvps[.]com 185.145.253[.]62 Jan 17, 2022 213038 – DreamVPS opswat[.]info 194.195.241[.]46 Jan 11, 2022 63949 – Linode – 178.79.176[.]1 – 63949 – Linode Attribution

The code, which we consider custom (Trojans, wrappers), has no similarities with previously known campaigns or previously registered SilentBreak toolset modules. Right now we prefer not to name the activity and instead stick to just “SilentBreak” given it is the most used among the tools here. If new modules appear and allow us to connect the activity to some actor we will update the name accordingly.

Conclusions

We consider the event logs technique, which we haven’t seen before, the most innovative part of this campaign. With at least two commercial products in use, plus several types of last-stage RAT and anti-detection wrappers, the actor behind this campaign is quite capable. There is the possibility that some of the modules we described here as custom ones are part of a commercial toolset as well. The code is quite unique, with no similarities to known malware. We will continue to monitor similar activity.

Indicators of Compromise File Hashes (malicious documents, trojans, emails, decoys)

Dropper
822680649CDEABC781903870B34FB7A7
345A8745E1E3AE576FBCC69D3C8A310B
EF825FECD4E67D5EC5B9666A21FBBA2A
FA5943C673398D834FB328CE9B62AAAD

Logs code launcher
2080A099BDC7AA86DB55BADFFBC71566
0D415973F958AC30CB25BD845319D960
209A4D190DC1F6EC0968578905920641
E81187E1F2E6A2D4D3AD291120A42CE7

HTTP Trojan
ACE22457C868DF82028DB95E5A3B7984
1CEDF339A13B1F7987D485CD80D141B6
24866291D5DEEE783624AB51516A078F
13B5E1654869985F2207D846E4C0DBFD

Named pipes trojan and similar
59A46DB173EA074EC345D4D8734CB89A
0B40033FB7C799536C921B1A1A02129F
603413FC026E4713E7D3EEDAB0DF5D8D

Anti-detection wrappers/decryptors/launchers, not malicious by themselves
42A4913773BBDA4BC9D01D48B4A7642F
9619E13B034F64835F0476D68220A86B
0C0ACC057644B21F6E76DD676D4F2389
16EB7B5060E543237ECA689BDC772148
54271C17684CA60C6CE37EE47B5493FB
77E06B01787B24343F62CF5D5A8F9995
86737F0AE8CF01B395997CD5512B8FC8
964CB389EBF39F240E8C474E200CAAC3
59A46DB173EA074EC345D4D8734CB89A
A5C236982B0F1D26FB741DF9E9925018
D408FF4FDE7870E30804A1D1147EFE7C
DFF3C0D4F6E2C26936B9BD82DB5A1735
E13D963784C544B94D3DB5616E50B8AE
E9766C71159FC2051BBFC48A4639243F
F3DA1E157E3E344788886B3CA29E02BD

Host-based IoCs

C:\Windows\Tasks\wer.dll
C:\Windows\Tasks\WerFault.exe copy of the legit one to sideload the malicious .dll
Named pipe MonolithPipe
Event logs with category 0x4142 in Key Management Service source. Events ID auto increments starting from 1423.

PDB paths

C:\Users\admin\source\repos\drx\x64\Release\sb.pdb
C:\Users\admin\source\repos\drx\x64\Release\zOS.pdb
C:\Users\admin\source\repos\drx\x64\Release\ThrowbackDLL.pdb
C:\Users\admin\source\repos\drx\x64\Release\drxDLL.pdb
C:\Users\admin\source\repos\drx\x64\Release\monolithDLL.pdb

2022. április 27.

APT trends report Q1 2022

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

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

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

Disclaimer: when referring to APT groups as Russian-speaking, Chinese-speaking or other-“speaking” languages, we refer to various artefacts used by the groups (such as malware debugging strings, comments found in scripts, etc.) containing words in these languages, based on the information we obtained directly or which is otherwise publicly known and reported widely. The use of certain languages does not necessarily indicate a specific geographic relation but rather points to the languages that the developers behind these APT artefacts use.

The most remarkable findings

On January 14, 70 Ukrainian websites were defaced: the attackers posted the message “be afraid and expect the worst”. The defacement message on the Ministry of Foreign Affairs website, written in Ukrainian, Russian and Polish, suggested that personal data uploaded to the site had been destroyed. Subsequently, DDoS attacks hit several government websites. The following day, Microsoft reported that it had found destructive malware, dubbed WhisperGate, on the systems of government bodies and agencies that work closely with the Ukrainian government. We analyzed the associated samples and concluded that the deployed malware was not comparable in complexity or code similarity to malware leveraged in previous destruction campaigns such as NotPetya or BadRabbit; but was much more reminiscent of that typically used by cybercriminals. We also identified two samples developed in December 2021 containing test strings and preceding revisions of the ransom note observed in Microsoft’s shared samples. It remains unclear who is behind the attack, although Serhiy Demedyuk, deputy secretary of Ukraine’s National Security and Defense Council, stated that it was the work of UNC1151, a threat actor believed to be linked to Belarus. Throughout our investigation, we identified two samples developed in December 2021 containing test strings and earlier revisions of the ransom note observed in Microsoft’s shared samples. We concluded with high confidence that these samples were earlier iterations of the wiper reportedly used in Ukraine. Additionally, we suspect that the MBR wiper was initially developed at that time and repurposed more recently for the above campaign. This could have been done either by an advanced actor with the intention of conveying the false notion that the operation was being conducted by criminals; or in cooperation with lower-tier threat actors who contributed their own resources.

On January 26, CERT-UA published a report showing code similarity between WhisperKill (the file wiper used during the WhisperGate campaign) and WhiteBlackCrypt, a wiper used in the first quarter of 2021. While we were unable to obtain the same results by analyzing the CERT-UA samples, we subsequently identified a different WhiteBlackCrypt sample matching the WhisperKill architecture and sharing similar code. We also investigated the Bitcoin wallets used by both WhisperGate and WhiteBlackCrypt, but were unable to uncover any link between the two.

On February 23, ESET published a tweet announcing new wiper malware targeting Ukraine. The malware was more advanced than the samples identified earlier in the year that we documented in two of our private reports. This wiper, named HermeticWiper by the research community, abuses legitimate drivers from EaseUS Partition Master to corrupt the drivers of the compromised system. One of the identified samples was compiled on December 28, 2021, suggesting that this destructive campaign had been planned for months. At the time of publication, we had not identified any similarities between HermeticWiper and other known malware.

The following day, Avast Threat Research announced the discovery of new Golang ransomware in Ukraine, which they dubbed HermeticRansom. This malware was found around the same time as HermeticWiper; and publicly available information from the security community indicated that it was used in recent cyberattacks in Ukraine. Due to its unsophisticated style and poor implementation, this new ransomware was probably only a smokescreen for the HermeticWiper attack, due to its non-sophisticated style and poor implementation. We named this malware Elections GoRansom.

In late February 2022, we identified two archives submitted from network addresses in Ukraine to an online multi-scanner service. Both archives leveraged the name of the Security Service of Ukraine (SBU or СБУ) to trick targets into executing a Remote Access Tool (RAT). We were unable to determine the ultimate goal of deploying such RATs, or associate the campaigns with any known threat actor, but the two archives appear linked together and may have been deployed by the same operators. Such threats pose a risk to Ukrainian organizations and their partners, as well as foreign organizations with premises in Ukraine. The RAT deployment campaigns look like they are targeted at developing access at scale in Ukraine, which could match activities from criminal groups that pledged allegiance to Russia, and may enable further destructive activities.

On March 1, ESET published a blog post related to wipers used in Ukraine and to the ongoing conflict: in addition to HermeticWiper, this post introduced IsaacWiper, used to target specific machines previously compromised with another remote administration tool named RemCom, commonly used by attackers for lateral movement within compromised networks. Contrary to reporting from other vendors, this wiper does not leverage the Isaac PRNG.

On March 10, researchers from the Global Research and Analysis Team shared their insights into past and present cyberattacks in Ukraine. You can find the recording of the webinar here and a summary/Q&A here.

On March 22, the Ukraine CERT published a new alert about the DoubleZero wiper targeting the country. This is a new wiper, written in .NET, with no similarities to previously discovered wipers targeting Ukrainian entities. According to the CERT public statement, the campaign took place on March 17, when several targets in Ukraine received a ZIP archive with the filename “Вирус… крайне опасно!!!.zip” (translation: “Virus… extremely dangerous!!!.zip”).

Russian-speaking activity

In December 2021, as a result of our continued monitoring of the activities of the DustSquad threat actor, we observed new infrastructure and tools being used alongside the already known Octopus Trojan. We had initially analyzed this Delphi malware in April 2018. Since then, the actor has continued to target diplomatic entities of several Central Asian countries; and, according to our telemetry, their consulates in APAC and the Middle East are also affected by recent campaigns. Octopus is only one of DustSquad’s tools, along with other Windows and Android malware such as Zaka, Akinak and Harpoon. For Windows development, Delphi has been the group’s traditional programming language of choice. The actor maintains a two-layered communication scheme, with relays and real C2s, utilizing a JSON-formatted base64-encoded network communication protocol, via the use of a third-party IndyProject library. We have previously seen DustSquad use third-party post-exploitation tools, such as the password dumping utility fgdump; but we have now observed new custom C modules, a first for DustSquad, and Delphi downloaders acting as post-exploitation facilitators, able to gather documents of interest for the actor. Malicious Windows executables have also been compiled with GCC under the MinGW environment.

Chinese-speaking activity

While hunting for malicious IIS modules, following our earlier reports about the mass exploitation of ProxyLogon and the Owowa module, we identified another backdoor module that has been widely deployed since at least June 2021. We named it BlackMoule, as we believe it is an update of BlackMould, a malicious tool that was briefly mentioned by Microsoft in late 2019 as part of GALLIUM activities against telecoms companies (aka Operation SoftCell).

In May 2021, we reported on Websiic, a cluster of activities that formed a set of attacks against high-profile targets in Europe and Asia. The attackers used the infamous ProxyLogon exploit to compromise Exchange servers and deploy a China Chopper web shell, which was in turn used to start a sophisticated infection scheme leading to the execution of a new backdoor that we dubbed Samurai. The toolset includes several unique loaders and installers that had not previously been observed and can be used to load malicious payloads directly into memory, usually in the context of a legitimate process such as svchost.exe. We discovered continued activity involving multiple new loaders and installers, which were supposedly used to deploy different malicious payloads. We also observed that the malware was exclusively used against servers until August 2021; but starting from September, similar samples were also observed targeting desktop environments via messaging applications such as Telegram. Despite the discovery of weak ties to the FunnyDream cluster, we were unable to confidently attribute this new campaign to an existing group, so we dubbed the threat actor behind these attack clusters ToddyCat. Our private report on the matter takes a closer look at the available  evidence: we concluded that the overlaps are weak but unlikely to be coincidental, leading us to believe that the actor behind Websiic might be part of the Chinese-speaking nebulae.

At the end of January, the BfV (Federal Office for the Protection of the Constitution of Germany) issued a report detailing activity by the APT27 group (aka LuckyMouse) targeting German commercial companies. Their analysis outlines the usage of a common infection triad leveraged by the group, whereby a legitimate executable (mempeng.exe or vfhost.exe) side-loads a malicious DLL (vftrace.dll), which in turn invokes the execution of the HyperBro malware from position-independent code found within a third file (thumb.dat). By investigating this threat through the lens of Kaspersky’s telemetry, we found an identical intrusion set targeting an enterprise in Taiwan that deals with the manufacture of smart city technology, which may suggest an intent to steal intellectual property, possibly as a means of leveraging the same technology as an instrument of surveillance. Another victim in which the same chain was exhibited is a computer game manufacturer in Cambodia, where the attack could have been used for a different purpose, possibly to infiltrate the company’s supply chain. We determined that the attackers were able to spread across the network and remain active within it for months, while making use of various tools. In addition to the infection chain outlined above, we found post-exploitation tools that were not mentioned by the BfV, including a custom-written keylogger and a publicly available SSH and SFTP credential stealer. Interestingly, we were able to observe the presence of a second malware loader on several hosts in the network that coincided with the deployment of the HyperBro implant. This loader leverages a fake Flash installer implanted with shellcode that is used to fetch a Cobalt Strike payload from a remote C2 server. At the time of writing, we can only assess with medium confidence that this tool is indeed associated with the group’s activity, indicating a possible sharing of initial access to the network with an external entity, or usage of Cobalt Strike as an alternative to HyperBro in the case of unsuccessful deployment.

Middle East

While hunting for malicious modules for Microsoft IIS servers, we identified a poorly detected and widely deployed module that we call XTest. XTest is based on the publicly available IIS-Raid open source, and was identified on hundreds of servers in late February, with 95 percent of them still being compromised at the time of our report. We were not able to determine the exact purpose XTest serves the threat actors, but we believe, with low confidence, that the module may have been deployed as part of malicious activities from the APT35 actor (aka Charming Kitten and Phosphorus).

Southeast Asia and Korean Peninsula

We reported recent, ongoing malicious activity that we attribute to the threat actor Sidecopy, targeting government staff in India. In addition to the known malware types deployed in past campaigns by this actor, such as MargulasRAT, we identified a cluster of activity targeting Linux and macOS platforms, including an unknown Golang-based Linux RAT that we attribute exclusively to this group. The supporting infrastructure for this operation overlaps with an operation described in a report published by Cisco Talos in September 2021, which discusses a campaign targeting government personnel in India using Netwire and Warzone (aka AveMaria RAT) dating back to the end of 2020. According to the authors, the decoys, used in malicious documents and spread in the early stages of these operations, resemble the one used by TransparentTribe (aka APT36 and Mythic Leopard) and Sidecopy. Our private report provides additional and updated indicators of compromise (IoCs) in the context of the same campaign and a description of some Linux and macOS malware that the group behind it has recently adopted.

We identified three campaigns linked to the Konni threat actor, active since mid-2021, targeting Russian diplomatic entities. While the attackers used the same Konni RAT implant throughout the different campaigns, the infection vectors were different in each campaign: documents containing embedded macros, an installer masquerading as a COVID-19 registration application and, finally, a downloader with a new year screensaver decoy. We also identified post-exploitation tools exclusively used by Konni following a successful infection. These are capable of taking screenshots of the active window, deploying a keylogger or listing the connected USB devices and their content. The tools align with the threat actor’s goal of stealing sensitive information from infected systems. We found overlaps in the infrastructure used by a tunneling tool used by the actor and several possible phishing websites set up within the above time frame. One of the registered domains shared similarities with another domain attributed to TA406 that, according to ProofPoint, incorporates the Konni APT.

Monitoring APT10 activities, we discovered new variants of its tools being used against the same targets as in previous campaigns – Japanese government agencies and diplomatic entities. We have seen versions of the LODEINFO backdoor through v0.4.7, v0.4.8, v0.4.9, v0.5.6, and v0.5.8 from January to December 2021, while Lilim RAT received an update to v1.4.1 in June 2021. In 2020, we published private reports featuring LODEINFO, a sophisticated fileless malware first mentioned in a blogpost from JPCERT/CC3. In these reports, we mentioned new families of fileless malware known as DOWNJPIT and Lilim RAT, which replaced the existing tools of the trade. Further, we disclosed, with high confidence, that LODEINFO and its related activities were attributed to APT10, the infamous Chinese-speaking actor. Our latest report on this subject includes technical analysis of the new versions of LODEINFO and Lilim RAT and reviews updates to the malware. In particular, LODEINFO v0.5.6 and v0.5.8 introduced obfuscated backdoor command identifiers to slow down the reversing process. They also implemented the Vigenere cipher to evade detection by certain security products.

We recently discovered a Trojanized DeFi application, compiled in November 2021. This application contains a legitimate program called DeFi Wallet, that saves and manages a cryptocurrency wallet, but also implants a malicious file when executed. This malware is a fully featured backdoor containing sufficient capabilities to control the compromised victim. After looking into the functionalities of this backdoor, we discovered numerous overlaps with other tools used by the Lazarus group. The malware operator exclusively used compromised web servers located in South Korea for this attack. To take over the servers, we worked closely with a local CERT and, as a result of this effort, we had the opportunity to investigate a Lazarus group C2 server. The threat actor configured this infrastructure with servers set up as multiple stages. The first stage is the source for the backdoor, while the purpose of the second stage server is to communicate with the implants. This represents a common scheme for Lazarus infrastructure. From the log files originating from the C2 servers, a number of infected hosts are visible. By only using IP addresses we weren’t able to confirm the exact victims of this campaign, given that some may belong to researchers, but they did reveal that this attack targeted entities and/or individuals at a global level.

Since October 2021, the Sidewinder threat actor has been using new malicious JS code with recently created C2 server domains. The attack targets victims with spear-phishing emails containing malicious OOXML files. The OOXML files have an external reference to the attacker’s server and download an RTF document exploiting the CVE-2017-11882 vulnerability. The RTF documents have an embedded JS script in an OLE object that is dropped onto the victim’s machine. Sidewinder has been using this infection chain for over a year; we provided details of these modules and described further payloads in our previous report. Our last report, in November, showed that Sidewinder’s use of the obfuscated JS script has decreased in recent months. Closer investigation of the attacks performed in that period revealed dozens of detections of a new obfuscation technique used in their JS script, while the rest of the infection chain remained fairly consistent. The new attacks use the same infection chain, targeting other victims from their traditional victim profile as well as a number of victims in countries that were not traditionally of interest to SideWinder, such as Singapore. The timestamp of the detections and the registration of the servers used by Sidewinder in these attacks suggest that they started preparing the infrastructure and registering domains for their new wave of attacks in late September. In early October they updated their toolset with new JS obfuscation techniques, and while they continued the use of their old obfuscation routine for a while, they have slowly switched completely to the new one. We described the attacks using the new obfuscated JS scripts in our most recent private report. The attackers also used a new technique to reduce the suspicion raised by some of their spear-phishing documents that had no text content. They followed their first attempt to attack the victim – a spear-phishing email containing a malicious RTF exploit file – with another similar email, but in this case the title of the malicious document was “_Apology Letter.docx”, and it contained some text explaining that the previous email was sent in error and that they are reaching out to apologize for that mistake.

In January, a trusted source forwarded a suspicious email to us. This email is disguised as an invitation from the renowned PyeongChang Peace forum and contains a DropBox link in the email body. The fetched file from the DropBox link contains a malicious Windows shortcut file capable of downloading the next stage payload from the attacker’s server. Fortunately, we were able to acquire the samples from the remote server. We dubbed this malware Phontena; and our analysis revealed the entire infection chain of this attack, made up of multiple stages. From our telemetry, we discovered a full-featured backdoor that is probably the final payload of this infection. After analyzing the samples from the remote server, we recognized that the actor behind this attack was associated with information published by another vendor about a threat actor named APT-C-601 or APT-Q-122. Based on the malware sample we discovered, we assess that this group has many overlaps with the DarkHotel group. Malware used in previous DarkHotel activity, as well as the samples discovered as part of this research, has very similar C2 communication and internal mechanisms. Moreover, the malware author left Korean comments in one of the stager payloads.

Two years after we first reported the activities of a threat actor we named FishingElephant, the group continues to target victims in Bangladesh and Pakistan. While we identified the use of a new keylogger by FishingElephant, it appears that the group still mainly relies on the same TTPs (such as payload and communication patterns) that were covered in our initial reports.

ToddyCat, a relatively new APT actor, is responsible for multiple attacks detected since December 2020. In the first wave of attacks, dubbed Websiic, the attackers exploited a ProxyLogon vulnerability to compromise Exchange Servers of high-profile organizations in Europe and Asia. More recently, we detected a new set of attacks against desktop machines starting in September 2021, named Ninja by the attacker. This Trojan provides a large set of commands allowing the attackers to control target computers. Some capabilities we analyzed are similar to those provided in other notorious post-exploitation toolkits.

Other interesting discoveries

In December we were made aware of a UEFI firmware-level compromise through logs from our firmware scanning technology. Further analysis showed that the attackers modified a single component within the firmware to append a payload to one of its sections and incorporate inline hooks within particular functions. These changes allowed the attackers to intercept the original flow of the firmware code and have it executed alongside a sophisticated infection chain. The introduced malicious flow, in turn, is in charge of persistently executing a malware stager from a Windows service once the operating system is running. By examining other IoCs from the same network, we gathered a trove of evidence that led us to assess, with medium-to-high confidence, that the threat actor involved is closely tied to the APT41 group. More specifically, we inspected communication of other nodes in the same network to infrastructure related to the server from which the payload is retrieved by the malicious stager. This traffic originated from an in-memory modular implant dubbed ScrambleCross, known to be in use by APT41 or a closely affiliated actor. Although we have covered several UEFI-based infections in APT reports in the last few months, those were cases operating through modifications introduced to the Windows boot loader image, which resides on the ESP partition on disk and can be remediated through a reinstallation of the operating system. In this case, however, the malware was found in an image typically based in the SPI flash, which is outside the hard disk and therefore withstands formatting or disk replacement. To the best of our knowledge, this is only the third known case found in the wild of a comparable UEFI implant, following LowJax and MosaicRegressor.

While hunting for recent Deathstalker intrusions, we identified a new Janicab variant used in targeting legal entities in the Middle East during 2020, possibly active into early 2021 and potentially extending an extensive campaign that can be traced back to early 2015 targeting legal, financial and travel organizations in the Middle East and Europe. Janicab was first introduced in 2013 as malware able to run on macOS and Windows operating systems. The Windows version has a VBS script-based implant as the final stage, instead of the C#/PowerShell combination observed previously in Powersing samples. The VBS-based implant samples we have identified to date have a range of version numbers, meaning it was, and still is, in development. Overall, Janicab shows the same functionalities as its counterpart malware families, but instead of downloading several tools later in the intrusion lifecycle, as the group used to do with EVILNUM and Powersing intrusions, the analyzed samples have most of the tools embedded and obfuscated within the dropper. Interestingly, the threat actor continues to use YouTube, Google+, and WordPress web services as Dead Drop Resolvers (DDRs). However, some of the YouTube links observed are unlisted and go back to 2015, indicating possible re-use of infrastructure. Law firms and financial institutions remain the sectors most affected by DeathStalker. However, in the intrusions we analyzed recently, we suspect that travel agencies are a new vertical that we haven’t previously seen this threat actor targeting.

We recently identified additional malicious activities, conducted by Tomiris operators since at least October 2021, against government, telecoms and engineering organizations in Kyrgyzstan, Afghanistan and Russia. In July 2021, we reported the previously unknown Tomiris Golang backdoor, deployed against government organizations within a CIS country through DNS hijacking. We exposed similarities between DarkHalo’s SunShuttle backdoor and the Tomiris implant. Later in 2021, we uncovered associated malicious activities that also used the open-source RATel implant to target several government organizations within Russia and Central Asia, while drawing an additional possible link between Tomiris operators and UNC1514.

Final thoughts

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

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

  • Geopolitics has always been a key driver of APT developments; never more so than during a period of open warfare, as illustrated by the various cyberattacks related to the conflict in Ukraine. We have, of course, seen other activity centered around geopolitics, including the Konni and APT10 campaigns.
  • One of the trends we discussed in our 2021 APT review and predictions for 2022 was the further development of low-level implants. Moonbounce provides a striking example of this trend.

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