Normal view

Supply chain attack on eScan antivirus: detecting and remediating malicious updates

29 January 2026 at 16:07

UPD 30.01.2026: Added technical details about the attack chain and more IoCs.

On January 20, a supply chain attack has occurred, with the infected software being the eScan antivirus developed by the Indian company MicroWorld Technologies. The previously unknown malware was distributed through the eScan update server. The same day, our security solutions detected and prevented cyberattacks involving this malware. On January 21, having been informed by Morphisec, the developers of eScan contained the security incident related to the attack.

Malicious software used in the attack

Users of the eScan security product received a malicious Reload.exe file, which initiated a multi-stage infection chain. According to colleagues at Morphisec who were the first to investigate the attack, Reload.exe prevented further antivirus product updates by modifying the HOSTS file, thereby blocking the ability of security solution developers to automatically fix the problem, which, among other things, led to the update service error.

The malware also ensured its persistence in the system, communicated with command-and-control servers, and downloaded additional malicious payloads. Persistence was achieved by creating scheduled tasks; one example of such a malicious task is named “CorelDefrag”. Additionally, the consctlx.exe malicious file was written to the disk during the infection.

How the attackers managed to pull off this attack

At the request of the BleepingComputer information portal, eScan developers explained that the attackers managed to gain access to one of the regional update servers and deploy a malicious file, which was automatically delivered to customers. They emphasize that this is not a vulnerability — the incident is classified as unauthorized access to infrastructure. The malicious file was distributed with a fake, invalid digital signature.

According to the developers, the infrastructure affected by the incident was quickly isolated, and all access credentials were reset.

Having checked our telemetry, we identified hundreds of machines belonging to both individuals and organizations, which encountered infection attempts with payloads related to the eScan supply chain attack. These machines were mostly located in South Asia, primarily in India, Bangladesh, Sri Lanka, and the Philippines. Having examined them, we identified that to orchestrate the infection, attackers were able to replace a legitimate component of the eScan antivirus, located under the path C:\Program Files (x86)\escan\reload.exe, with a malicious executable. This reload.exe file is launched at runtime by components of the eScan antivirus. It has a fake, invalid digital signature (certificate serial number: 68525dadf70c773d41609ff7ca499fb5). We found this implant to be heavily obfuscated with constant unfolding and indirect branching, which made its analysis quite tedious.

Obfuscated code snippet

Obfuscated code snippet

When started, this reload.exe file checks whether it is launched from the Program Files folder, and exits if not. It further initializes the CLR (Common Language Runtime) environment inside its process, which it uses to load a small .NET executable into memory (SHA1: eec1a5e3bb415d12302e087a24c3f4051fca040e). This executable is based on the UnmanagedPowerShell tool, which allows executing PowerShell code in any process. Attackers modified the source code of this project by adding an AMSI bypass capability to it, and used it to execute a malicious PowerShell script inside the reload.exe process. This script has three lines, and looks as follows:

Lines of the launched script

Lines of the launched script

Each of these lines is responsible for decoding and launching a Base64-encoded PowerShell payload. These three payloads, which we will further analyze, are used for the infection on the target machine.

eScan antivirus tampering payload

The first executed payload is deployed to tamper with the installed eScan solution, in an attempt to prevent it from receiving updates and detecting the installed malicious components. To do that, it performs several actions, including the following ones:

  • Deletes multiple files of the eScan antivirus, including the Remote Support Utility located at C:\Program Files (x86)\Common Files\MicroWorld\WGWIN\tvqsapp.exe. Notably, before deletion, the payload creates ZIP-archived backups of removed files inside the C:\ProgramData\esfsbk directory.
  • Modifies the HKLM\SOFTWARE\WOW6432Node\MicroWorld\eScan for Windows\MwMonitor registry key to add the C:\Windows, C:\Program Files and C:\Program Files (x86) folders to antivirus exceptions.
  • Adds update servers of the eScan antivirus (such as update1.mwti.net) to the hosts file, associating them with the IP address 2.3.4.0.
  • Modifies registry keys related to antivirus databases, for example by assigning 999 to the WTBases_new value of the HKLM\SOFTWARE\WOW6432Node\MicroWorld\eScan for Windows\ODS registry key.

While tampering with eScan, this payload writes a debug log to the C:\ProgramData\euapp.log file, which can be used as an indicator of compromise.

It is worth noting that while running this payload, we did not observe all these actions to succeed on our test machine with eScan installed. For example, the self-defense component of eScan was able to prevent malicious entries from being written into the hosts file. Nevertheless, after the payload had finished execution, we were unable to further update eScan, as we were getting this error message:

Error message displayed to us when we launched the update process after tampering with eScan

Error message displayed to us when we launched the update process after tampering with eScan. While the message says, “The operation completed successfully”, its appearance is abnormal, and no updates are actually downloaded or installed

Finally, the first payload replaces the C:\Program Files (x86)\eScan\CONSCTLX.exe component of eScan with a next-stage persistent payload, which we will describe in further sections of this article.

AMSI bypass payload

The second payload launched is designed to bypass AMSI. The payload implements typical code for doing that – it determines the address of the AmsiScanBuffer function and then patches it to always return an error.

Snippet of the AMSI bypass payload (deobfuscated version)

Snippet of the AMSI bypass payload (deobfuscated version)

Victim validation payload

The goal of the third payload, which is the last to be executed, is to validate whether the victim machine should be further infected, and if yes, to deliver a further payload to it. When started, it examines the list of installed software, running processes and services against a blocklist. Entries in this blocklist are related to analysis tools and security solutions. Notably, Kaspersky security solutions are included into this blocklist. This means that this stage will refuse to deliver the embedded payload if Kaspersky products are installed on the victim machine.

If validation is successful, the payload proceeds with deploying a PowerShell-based persistent payload on the infected machine. To do that, it:

  • Writes the persistent payload to the Corel value of the HKLM\Software\E9F9EEC3-86CA-4EBE-9AA4-1B55EE8D114E registry key.
  • Creates a scheduled task named Microsoft\Windows\Defrag\CorelDefrag, designed to execute the following PowerShell script every day at a random time:
    PowerShell script executed by the CorelDefrag scheduled task (beautified version)

    PowerShell script executed by the CorelDefrag scheduled task (beautified version)

    This script retrieves the persistent payload from the HKLM\Software\E9F9EEC3-86CA-4EBE-9AA4-1B55EE8D114E registry key, Base64-decodes and then executes it.

When the payload execution finishes, either because validation failed or the persistent component was deployed successfully, it sends a heartbeat to the C2 infrastructure. This is done by sending a GET request, which contains a status code and optionally an error message, to the following URLs:

  • https://vhs.delrosal[.]net/i
  • https://tumama.hns[.]to
  • https://blackice.sol-domain[.]org
  • https://codegiant.io/dd/dd/dd.git/download/main/middleware[.]ts

The response to the GET request is not processed.

As such, during installation, the infected machine receives two persistent payloads:

  • The CONSCTLX.exe payload, designed to be launched by the eScan antivirus
  • The PowerShell-based payload, designed to be launched via a scheduled task

The CONSCTLX.exe persistent payload

This payload is obfuscated in the same way as the Reload.exe malicious executable. In the same way as this executable, CONSCTLX.exe initializes the CLR environment to execute a PowerShell script inside its own process. The goal of this script is to retrieve the other (PowerShell-based) persistent payload from the HKLM\Software\E9F9EEC3-86CA-4EBE-9AA4-1B55EE8D114E registry key, and execute it. However, this script contains another interesting feature: it changes the last update time of the eScan product to the current time, by writing the current date to the C:\Program Files (x86)\eScan\Eupdate.ini file. This is needed to make the eScan solution GUI display a recent update date, so that the user does not notice that antivirus updates are actually blocked.

Screenshot of the eScan product GUI, with the highlighted date that is changed by the payload

Screenshot of the eScan product GUI, with the highlighted date that is changed by the payload

Apart from launching the PowerShell script, the payload also attempts to retrieve a fallback payload from the C2 infrastructure, by sending GET requests to the following URLs:

  • https://csc.biologii[.]net/sooc
  • https://airanks.hns[.]to

If there is a need to deliver this payload, the server responds with an RC4-encrypted blob, which is decrypted by the component and launched as shellcode.

The PowerShell-based persistent payload

The second deployed payload is entirely PowerShell-based. When started, it performs an AMSI bypass and conducts the same validation procedures as the victim validation payload. It further sends a GET request to the C2 infrastructure, using the same URLs as the validation payload. In this request, the cookie value named “s” contains RC4-encrypted and Base64-encoded system information, such as the victim ID, user name and current process name. In response to this request, the C2 server may optionally send the victim a PowerShell script, to be launched by the victim machine.

A rarely observed attack vector

Notably, it is quite unique to see malware being deployed through a security solution update. Supply chain attacks are a rare occurrence in general, let alone ones orchestrated through antivirus products. Based on the analysis of the identified implants, we can conclude that this attack was prepared thoroughly, as to orchestrate it, attackers had to:

  • Get access to the security solution update server.
  • Study the internals of the eScan product to learn how its update mechanism works, as well as how to potentially tamper with this product.
  • Develop unique implants, tailored to the supply chain attack.

An interesting fact about the implants deployed is that they implement fallback methods of performing malicious operations. For example, if the scheduled task that launches the PowerShell payload is deleted, it will still be launched by the CONSCTLX.exe file. In addition, if the C2 servers used by the PowerShell payload are identified and blocked, attackers will be still able to deploy shellcodes to the infected machine through CONSCTLX.exe.

One lucky thing about this attack is that it was contained in a quite a short period of time. As security solutions have a high level of trust within the operating system, attackers can use a variety of creative ways to orchestrate the infection, for example by using kernel-mode implants. However, in the attack we saw, they relied on user-mode components and commonly observed infection techniques, such as using scheduled tasks for persistence. This factor, in our opinion, made this supply chain attack easy to detect.

How to stay safe?

To detect infection, it is recommended to review scheduled tasks for traces of malware, check the %WinDir%\System32\drivers\etc\hosts file for blocked eScan domains, and review the eScan update logs for January 20.

The developers of eScan have created a utility for their users that removes the malware, rolls back the modifications it has made, and restores the normal functionality of the antivirus. The utility is sent to customers upon request to technical support.

Users of the solution are also advised to block known malware command-and-control server addresses.

Kaspersky’s security solutions, such as Kaspersky Next, successfully detect all malware used by the attackers with its Behavior Detection component.

Indicators of compromise

Network indicators
https://vhs.delrosal[.]net/i
https://tumama.hns[.]to
https://blackice.sol-domain[.]org
https://codegiant.io/dd/dd/dd.git/download/main/middleware[.]ts
https://csc.biologii[.]net/sooc
https://airanks.hns[.]to

Malicious Reload.exe component hashes
1617949c0c9daa2d2a5a80f1028aeb95ce1c0dee
a928bddfaa536c11c28c8d2c5d16e27cbeaf6357
ebaf9715d7f34a77a6e1fd455fe0702274958e20
96cdd8476faa7c6a7d2ad285658d3559855b168d

Malicious CONSCTLX.exe component hash
2d2d58700a40642e189f3f1ccea41337486947f5

Files and folders
C:\ProgramData\esfsbk
C:\ProgramData\euapp.log

Scheduled task name
Microsoft\Windows\Defrag\CorelDefrag

Registry keys
HKLM\Software\E9F9EEC3-86CA-4EBE-9AA4-1B55EE8D114E
HKLM\SOFTWARE\WOW6432Node\MicroWorld\eScan for Windows\ODS – value WTBases_new set to 999

Operation ForumTroll continues: Russian political scientists targeted using plagiarism reports

17 December 2025 at 11:00

Introduction

In March 2025, we discovered Operation ForumTroll, a series of sophisticated cyberattacks exploiting the CVE-2025-2783 vulnerability in Google Chrome. We previously detailed the malicious implants used in the operation: the LeetAgent backdoor and the complex spyware Dante, developed by Memento Labs (formerly Hacking Team). However, the attackers behind this operation didn’t stop at their spring campaign and have continued to infect targets within the Russian Federation.

More reports about this threat are available to customers of the Kaspersky Intelligence Reporting Service. Contact: intelreports@kaspersky.com.

Emails posing as a scientific library

In October 2025, just days before we presented our report detailing the ForumTroll APT group’s attack at the Security Analyst Summit, we detected a new targeted phishing campaign by the same group. However, while the spring cyberattacks focused on organizations, the fall campaign honed in on specific individuals: scholars in the field of political science, international relations, and global economics, working at major Russian universities and research institutions.

The emails received by the victims were sent from the address support@e-library[.]wiki. The campaign purported to be from the scientific electronic library, eLibrary, whose legitimate website is elibrary.ru. The phishing emails contained a malicious link in the format: https://e-library[.]wiki/elib/wiki.php?id=<8 pseudorandom letters and digits>. Recipients were prompted to click the link to download a plagiarism report. Clicking that link triggered the download of an archive file. The filename was personalized, using the victim’s own name in the format: <LastName>_<FirstName>_<Patronymic>.zip.

A well-prepared attack

The attackers did their homework before sending out the phishing emails. The malicious domain, e-library[.]wiki, was registered back in March 2025, over six months before the email campaign started. This was likely done to build the domain’s reputation, as sending emails from a suspicious, newly registered domain is a major red flag for spam filters.

Furthermore, the attackers placed a copy of the legitimate eLibrary homepage on https://e-library[.]wiki. According to the information on the page, they accessed the legitimate website from the IP address 193.65.18[.]14 back in December 2024.

A screenshot of the malicious site elements showing the IP address and initial session date

A screenshot of the malicious site elements showing the IP address and initial session date

The attackers also carefully personalized the phishing emails for their targets, specific professionals in the field. As mentioned above, the downloaded archive was named with the victim’s last name, first name, and patronymic.

Another noteworthy technique was the attacker’s effort to hinder security analysis by restricting repeat downloads. When we attempted to download the archive from the malicious site, we received a message in Russian, indicating the download link was likely for one-time use only:

The message that was displayed when we attempted to download the archive

The message that was displayed when we attempted to download the archive

Our investigation found that the malicious site displayed a different message if the download was attempted from a non-Windows device. In that case, it prompted the user to try again from a Windows computer.

The message that was displayed when we attempted to download the archive from a non-Windows OS

The message that was displayed when we attempted to download the archive from a non-Windows OS

The malicious archive

The malicious archives downloaded via the email links contained the following:

  • A malicious shortcut file named after the victim: <LastName>_<FirstName>_<Patronymic>.lnk;
  • A .Thumbs directory containing approximately 100 image files with names in Russian. These images were not used during the infection process and were likely added to make the archives appear less suspicious to security solutions.
A portion of the .Thumbs directory contents

A portion of the .Thumbs directory contents

When the user clicked the shortcut, it ran a PowerShell script. The script’s primary purpose was to download and execute a PowerShell-based payload from a malicious server.

The script that was launched by opening the shortcut

The script that was launched by opening the shortcut

The downloaded payload then performed the following actions:

  • Contacted a URL in the format: https://e-library[.]wiki/elib/query.php?id=<8 pseudorandom letters and digits>&key=<32 hexadecimal characters> to retrieve the final payload, a DLL file.
  • Saved the downloaded file to %localappdata%\Microsoft\Windows\Explorer\iconcache_<4 pseudorandom digits>.dll.
  • Established persistence for the payload using COM Hijacking. This involved writing the path to the DLL file into the registry key HKCR\CLSID\{1f486a52-3cb1-48fd-8f50-b8dc300d9f9d}\InProcServer32. Notably, the attackers had used that same technique in their spring attacks.
  • Downloaded a decoy PDF from a URL in the format: https://e-library[.]wiki/pdf/<8 pseudorandom letters and digits>.pdf. This PDF was saved to the user’s Downloads folder with a filename in the format: <LastName>_<FirstName>_<Patronymic>.pdf and then opened automatically.

The decoy PDF contained no valuable information. It was merely a blurred report generated by a Russian plagiarism-checking system.

A screenshot of a page from the downloaded report

A screenshot of a page from the downloaded report

At the time of our investigation, the links for downloading the final payloads didn’t work. Attempting to access them returned error messages in English: “You are already blocked…” or “You have been bad ended” (sic). This likely indicates the use of a protective mechanism to prevent payloads from being downloaded more than once. Despite this, we managed to obtain and analyze the final payload.

The final payload: the Tuoni framework

The DLL file deployed to infected devices proved to be an OLLVM-obfuscated loader, which we described in our previous report on Operation ForumTroll. However, while this loader previously delivered rare implants like LeetAgent and Dante, this time the attackers opted for a better-known commercial red teaming framework: Tuoni. Portions of the Tuoni code are publicly available on GitHub. By deploying this tool, the attackers gained remote access to the victim’s device along with other capabilities for further system compromise.

As in the previous campaign, the attackers used fastly.net as C2 servers.

Conclusion

The cyberattacks carried out by the ForumTroll APT group in the spring and fall of 2025 share significant similarities. In both campaigns, infection began with targeted phishing emails, and persistence for the malicious implants was achieved with the COM Hijacking technique. The same loader was used to deploy the implants both in the spring and the fall.

Despite these similarities, the fall series of attacks cannot be considered as technically sophisticated as the spring campaign. In the spring, the ForumTroll APT group exploited zero-day vulnerabilities to infect systems. By contrast, the autumn attacks relied entirely on social engineering, counting on victims not only clicking the malicious link but also downloading the archive and launching the shortcut file. Furthermore, the malware used in the fall campaign, the Tuoni framework, is less rare.

ForumTroll has been targeting organizations and individuals in Russia and Belarus since at least 2022. Given this lengthy timeline, it is likely this APT group will continue to target entities and individuals of interest within these two countries. We believe that investigating ForumTroll’s potential future campaigns will allow us to shed light on shadowy malicious implants created by commercial developers – much as we did with the discovery of the Dante spyware.

Indicators of compromise

e-library[.]wiki
perf-service-clients2.global.ssl.fastly[.]net
bus-pod-tenant.global.ssl.fastly[.]net
status-portal-api.global.ssl.fastly[.]net

❌