Chinese-sponsored groups are using the popular Brickstorm backdoor to access and gain persistence in government and tech firm networks, part of the ongoing effort by the PRC to establish long-term footholds in agency and critical infrastructure IT environments, according to a report by U.S. and Canadian security offices.
ShadyPanda spent seven years uploading trusted Chrome and Edge extensions, later weaponizing them for tracking, hijacking, and remote code execution. Learn how the campaign unfolded.
In this episode, we discuss the first reported AI-driven cyber espionage campaign, as disclosed by Anthropic. In September 2025, a state-sponsored Chinese actor manipulated the Claude Code tool to target 30 global organizations. We explain how the attack was executed, why it matters, and its implications for cybersecurity. Join the conversation as we examine the […]
In March 2025, Kaspersky detected a wave of infections that occurred when users clicked on personalized phishing links sent via email. No further action was required to initiate the infection; simply visiting the malicious website using Google Chrome or another Chromium-based web browser was enough.
The malicious links were personalized and extremely short-lived to avoid detection. However, Kaspersky’s technologies successfully identified a sophisticated zero-day exploit that was used to escape Google Chrome’s sandbox. After conducting a quick analysis, we reported the vulnerability to the Google security team, who fixed it as CVE-2025-2783.
Acknowledgement for finding CVE-2025-2783 (excerpt from the security fixes included into Chrome 134.0.6998.177/.178)
We dubbed this campaign Operation ForumTroll because the attackers sent personalized phishing emails inviting recipients to the Primakov Readings forum. The lures targeted media outlets, universities, research centers, government organizations, financial institutions, and other organizations in Russia. The functionality of the malware suggests that the operation’s primary purpose was espionage.
We traced the malware used in this attack back to 2022 and discovered more attacks by this threat actor on organizations and individuals in Russia and Belarus. While analyzing the malware used in these attacks, we discovered an unknown piece of malware that we identified as commercial spyware called “Dante” and developed by the Italian company Memento Labs (formerly Hacking Team).
Similarities in the code suggest that the Operation ForumTroll campaign was also carried out using tools developed by Memento Labs.
In this blog post, we’ll take a detailed look at the Operation ForumTroll attack chain and reveal how we discovered and identified the Dante spyware, which remained hidden for years after the Hacking Team rebrand.
Attack chain
Operation ForumTroll attack chain
In all known cases, infection occurred after the victim clicked a link in a spear phishing email that directed them to a malicious website. The website verified the victim and executed the exploit.
When we first discovered and began analyzing this campaign, the malicious website no longer contained the code responsible for carrying out the infection; it simply redirected visitors to the official Primakov Readings website.
Therefore, we could only work with the attack artifacts discovered during the first wave of infections. Fortunately, Kaspersky technologies detected nearly all of the main stages of the attack, enabling us to reconstruct and analyze the Operation ForumTroll attack chain.
Phishing email
Example of a malicious email used in this campaign (translated from Russian)
The malicious emails sent by the attackers were disguised as invitations from the organizers of the Primakov Readings scientific and expert forum. These emails contained personalized links to track infections. The emails appeared authentic, contained no language errors, and were written in the style one would expect for an invitation to such an event. Proficiency in Russian and familiarity with local peculiarities are distinctive features of the ForumTroll APT group, traits that we have also observed in its other campaigns. However, mistakes in some of those other cases suggest that the attackers were not native Russian speakers.
Validator
The validator is a relatively small script executed by the browser. It validates the victim and securely downloads and executes the next stage of the attack.
The first action the validator performs is to calculate the SHA-256 of the random data received from the server using the WebGPU API. It then verifies the resulting hash. This is done using the open-source code of Marco Ciaramella’s sha256-gpu project. The main purpose of this check is likely to verify that the site is being visited by a real user with a real web browser, and not by a mail server that might follow a link, emulate a script, and download an exploit. Another possible reason for this check could be that the exploit triggers a vulnerability in the WebGPU API or relies on it for exploitation.
The validator sends the infection identifier, the result of the WebGPU API check and the newly generated public key to the C2 server for key exchange using the Elliptic-curve Diffie–Hellman (ECDH) algorithm. If the check is passed, the server responds with an AES-GCM key. This key is used to decrypt the next stage, which is hidden in requests to bootstrap.bundle.min.js and .woff2 font files. Following the timeline of events and the infection logic, this next stage should have been a remote code execution (RCE) exploit for Google Chrome, but it was not obtained during the attack.
Sandbox escape exploit
List of in-the-wild 0-days caught and reported by Kaspersky
Over the years, we have discovered and reported on dozens of zero-day exploits that were actively used in attacks. However, CVE-2025-2783 is one of the most intriguing sandbox escape exploits we’ve encountered. This exploit genuinely puzzled us because it allowed attackers to bypass Google Chrome’s sandbox protection without performing any obviously malicious or prohibited actions. This was due to a powerful logical vulnerability caused by an obscure quirk in the Windows OS.
To protect against bugs and crashes, and enable sandboxing, Chrome uses a multi-process architecture. The main process, known as the browser process, handles the user interface and manages and supervises other processes. Sandboxed renderer processes handle web content and have limited access to system resources. Chrome uses Mojo and the underlying ipcz library, introduced to replace legacy IPC mechanisms, for interprocess communication between the browser and renderer processes.
The exploit we discovered came with its own Mojo and ipcz libraries that were statically compiled from official sources. This enabled attackers to communicate with the IPC broker within the browser process without having to manually craft and parse ipcz messages. However, this created a problem for us because, to analyze the exploit, we had to identify all the Chrome library functions it used. This involved a fair amount of work, but once completed, we knew all the actions performed by the exploit.
In short, the exploit does the following:
Resolves the addresses of the necessary functions and code gadgets from dll using a pattern search.
Hooks the v8_inspector::V8Console::Debug function. This allows attackers to escape the sandbox and execute the desired payload via a JavaScript call.
Starts executing a sandbox escape when attackers call console.debug(0x42, shellcode); from their script.
Hooks the ipcz::NodeLink::OnAcceptRelayedMessage function.
Creates and sends an ipcz message of the type RelayMessage. This message type is used to pass Windows OS handles between two processes that do not have the necessary permissions (e.g., renderer processes). The exploit retrieves the handle returned by the GetCurrentThread API function and uses this ipcz message to relay it to itself. The broker transfers handles between processes using the DuplicateHandle API function.
Receives the relayed message back using the ipcz::NodeLink::OnAcceptRelayedMessage function hook, but instead of the handle that was previously returned by the GetCurrentThread API function, it now contains a handle to the thread in the browser process!
Uses this handle to execute a series of code gadgets in the target process by suspending the thread, setting register values using SetThreadContext, and resuming the thread. This results in shellcode execution in the browser process and subsequent installation of a malware loader.
So, what went wrong, and how was this possible? The answer can be found in the descriptions of the GetCurrentThread and GetCurrentProcess API functions. When these functions are called, they don’t return actual handles; rather, they return pseudo handles, special constants that are interpreted by the kernel as a handle to the current thread or process. For the current process, this constant is -1 (also equal to INVALID_HANDLE_VALUE, which brings its own set of quirks), and the constant for the current thread is -2. Chrome’s IPC code already checked for handles equal to -1, but there were no checks for -2 or other undocumented pseudo handles. This oversight led to the vulnerability. As a result, when the broker passed the -2 pseudo handle received from the renderer to the DuplicateHandle API function while processing the RelayMessage, it converted -2 into a real handle to its own thread and passed it to the renderer.
Shortly after the patch was released, it became clear that Chrome was not the only browser affected by the issue. Firefox developers quickly identified a similar pattern in their IPC code and released an update under CVE-2025-2857.
When pseudo handles were first introduced, they simplified development and helped squeeze out extra performance – something that was crucial on older PCs. Now, decades later, that outdated optimization has come back to bite us.
Could we see more bugs like this? Absolutely. In fact, this represents a whole class of vulnerabilities worth hunting for – similar issues may still be lurking in other applications and Windows system services.
To learn about the hardening introduced in Google Chrome following the discovery of CVE-2025-2783, we recommend checking out Alex Gough’s upcoming presentation, “Responding to an ITW Chrome Sandbox Escape (Twice!),” at Kawaiicon.
Persistent loader
Persistence is achieved using the Component Object Model (COM) hijacking technique. This method exploits a system’s search order for COM objects. In Windows, each COM class has a registry entry that associates the CLSID (128-bit GUID) of the COM with the location of its DLL or EXE file. These entries are stored in the system registry hive HKEY_LOCAL_MACHINE (HKLM), but can be overridden by entries in the user registry hive HKEY_CURRENT_USER (HKCU). This enables attackers to override the CLSID entry and run malware when the system attempts to locate and run the correct COM component.
COM hijacking in a nutshell
The attackers used this technique to override the CLSID of twinapi.dll {AA509086-5Ca9-4C25-8F95-589D3C07B48A} and cause the system processes and web browsers to load the malicious DLL.
This malicious DLL is a loader that decrypts and executes the main malware. The payload responsible for loading the malware is encoded using a simple binary encoder similar to those found in the Metasploit framework. It is also obfuscated with OLLVM. Since the hijacked COM object can be loaded into many processes, the payload checks the name of the current process and only loads the malware when it is executed by certain processes (e.g., rdpclip.exe). The main malware is decrypted using a modified ChaCha20 algorithm. The loader also has the functionality to re-encrypt the malware using the BIOS UUID to bind it to the infected machine. The decrypted data contains the main malware and a shellcode generated by Donut that launches it.
LeetAgent
LeetAgent is the spyware used in the Operation ForumTroll campaign. We named it LeetAgent because all of its commands are written in leetspeak. You might not believe it, but this is rare in APT malware. The malware connects to one of its C2 servers specified in the configuration and uses HTTPS to receive and execute commands identified by unique numeric values:
0xC033A4D (COMMAND) – Run command with cmd.exe
0xECEC (EXEC) – Execute process
0x6E17A585 (GETTASKS) – Get list of tasks that agent is currently executing
0x6177 (KILL) – Stop task
0xF17E09 (FILE \x09) – Write file
0xF17ED0 (FILE \xD0) – Read file
0x1213C7 (INJECT) – Inject shellcode
0xC04F (CONF) – Set communication parameters
0xD1E (DIE) – Quit
0xCD (CD) – Change current directory
0x108 (JOB) – Set parameters for keylogger or file stealer
In addition to executing commands received from its C2, it runs keylogging and file-stealing tasks in the background. By default, the file-stealer task searches for documents with the following extensions: *.doc, *.xls, *.ppt, *.rtf, *.pdf, *.docx, *.xlsx, *.pptx.
The configuration data is encoded using the TLV (tag-length-value) scheme and encrypted with a simple single-byte XOR cipher. The data contains settings for communicating with the C2, including many settings for traffic obfuscation.
In most of the observed cases, the attackers used the Fastly.net cloud infrastructure to host their C2. Attackers frequently use it to download and run additional tools such as 7z, Rclone, SharpChrome, etc., as well as additional malware (more on that below).
The number of traffic obfuscation settings may indicate that LeetAgent is a commercial tool, though we have only seen ForumTroll APT use it.
Finding Dante
In our opinion, attributing unknown malware is the most challenging aspect of security research. Why? Because it’s not just about analyzing the malware or exploits used in a single attack; it’s also about finding and analyzing all the malware and exploits used in past attacks that might be related to the one you’re currently investigating. This involves searching for and investigating similar attacks using indicators of compromise (IOCs) and tactics, techniques, and procedures (TTPs), as well as identifying overlaps in infrastructure, code, etc. In short, it’s about finding and piecing together every scrap of evidence until a picture of the attacker starts to emerge.
We traced the first use of LeetAgent back to 2022 and discovered more ForumTroll APT attacks on organizations and individuals in Russia and Belarus. In many cases, the infection began with a phishing email containing malicious attachments with the following names:
Baltic_Vector_2023.iso (translated from Russian)
DRIVE.GOOGLE.COM (executable file)
Invitation_Russia-Belarus_strong_partnership_2024.lnk (translated from Russian)
Various other file names mentioning individuals and companies
In addition, we discovered another cluster of similar attacks that used more sophisticated spyware instead of LeetAgent. We were also able to track the first use of this spyware back to 2022. In this cluster, the infections began with phishing emails containing malicious attachments with the following names:
SCAN_XXXX_<DATE>.pdf.lnk
<DATE>_winscan_to_pdf.pdf.lnk
Rostelecom.pdf.lnk (translated from Russian)
Various others
The attackers behind this activity used similar file system paths and the same persistence method as the LeetAgent cluster. This led us to suspect that the two clusters might be related, and we confirmed a direct link when we discovered attacks in which this much more sophisticated spyware was launched by LeetAgent.
Connection between LeetAgent and commercial spyware called Dante
After analyzing this previously unknown, sophisticated spyware, we were able to identify it as commercial spyware called Dante, developed by the Italian company Memento Labs.
The Atlantic Council’s Cyber Statecraft Initiative recently published an interesting report titled “Mythical Beasts and where to find them: Mapping the global spyware market and its threats to national security and human rights.” We think that comparing commercial spyware to mythical beasts is a fitting analogy. While everyone in the industry knows that spyware vendors exist, their “products” are rarely discovered or identified. Meanwhile, the list of companies developing commercial spyware is huge. Some of the most famous are NSO Group, Intellexa, Paragon Solutions, Saito Tech (formerly Candiru), Vilicius Holding (formerly FinFisher), Quadream, Memento Labs (formerly Hacking Team), negg Group, and RCS Labs. Some are always in the headlines, some we have reported on before, and a few have almost completely faded from view. One company in the latter category is Memento Labs, formerly known as Hacking Team.
Hacking Team (also stylized as HackingTeam) is one of the oldest and most famous spyware vendors. Founded in 2003, Hacking Team became known for its Remote Control Systems (RCS) spyware, used by government clients worldwide, and for the many controversies surrounding it. The company’s trajectory changed dramatically in 2015 when more than 400 GB of internal data was leaked online following a hack. In 2019, the company was acquired by InTheCyber Group and renamed Memento Labs. “We want to change absolutely everything,” the Memento Labs owner told Motherboard in 2019. “We’re starting from scratch.” Four years later, at the ISS World MEA 2023 conference for law enforcement and government intelligence agencies, Memento Labs revealed the name of its new surveillance tool – DANTE. Until now, little was known about this malware’s capabilities, and its use in attacks had not been discovered.
Excerpt from the agenda of the ISS World MEA 2023 conference (the typo was introduced on the conference website)
The problem with detecting and attributing commercial spyware is that vendors typically don’t include their copyright information or product names in their exploits and malware. In the case of the Dante spyware, however, attribution was simple once we got rid of VMProtect’s obfuscation and found the malware name in the code.
Dante spyware name in the code
Dante
Of course, our attribution isn’t based solely on the string “Dante” found in the code, but it was an important clue that pointed us in the right direction. After some additional analysis, we found a reference to a “2.0” version of the malware, which matches the title of the aforementioned conference talk. We then searched for and identified the most recent samples of Hacking Team’s Remote Control Systems (RCS) spyware. Memento Labs kept improving its codebase until 2022, when it was replaced by Dante. Even with the introduction of the new malware, however, not everything was built from scratch; the later RCS samples share quite a few similarities with Dante. All these findings make us very confident in our attribution.
Why did the authors name it Dante? This may be a nod to tradition, as RCS spyware was also known as “Da Vinci”. But it could also be a reference to Dante’s poem Divine Comedy, alluding to the many “circles of hell” that malware analysts must pass through when detecting and analyzing the spyware given its numerous anti-analysis techniques.
First of all, the spyware is packed with VMProtect. It obfuscates control flow, hides imported functions, and adds anti-debugging checks. On top of that, almost every string is encrypted.
VMProtect anti-debugging technique
To protect against dynamic analysis, Dante uses the following anti-hooking technique: when code needs to execute an API function, its address is resolved using a hash, its body is parsed to extract the system call number, and then a new system call stub is created and used.
Dante anti-hooking technique (simplified)
In addition to VMProtect’s anti-debugging techniques, Dante uses some common methods to detect debuggers. Specifically, it checks the debug registers (Dr0–Dr7) using NtGetContextThread, inspects the KdDebuggerEnabled field in the KUSER_SHARED_DATA structure, and uses NtQueryInformationProcess to detect debugging by querying the ProcessDebugFlags, ProcessDebugPort, ProcessDebugObjectHandle, and ProcessTlsInformation classes.
To protect itself from being discovered, Dante employs an interesting method of checking the environment to determine if it is safe to continue working. It queries the Windows Event Log for events that may indicate the use of malware analysis tools or virtual machines (as a guest or host).
The strings Dante searches for in the event logs
It also performs several anti-sandbox checks. It searches for “bad” libraries, measures the execution times of the sleep() function and the cpuid instruction, and checks the file system.
Some of these anti-analysis techniques may be a bit annoying, but none of them really work or can stop a professional malware analyst. We deal with these techniques on an almost daily basis.
After performing all the checks, Dante does the following: decrypts the configuration and the orchestrator, finds the string “DANTEMARKER” in the orchestrator, overwrites it with the configuration, and then loads the orchestrator.
The configuration is decrypted from the data section of the malware using a simple XOR cipher. The orchestrator is decrypted from the resource section and poses as a font file. Dante can also load and decrypt the orchestrator from the file system if a newer, updated version is available.
The orchestrator displays the code quality of a commercial product, but isn’t particularly interesting. It is responsible for communication with C2 via HTTPs protocol, handling modules and configuration, self-protection, and self-removal.
Modules can be saved and loaded from the file system or loaded from memory. The infection identifier (GUID) is encoded in Base64. Parts of the resulting string are used to derive the path to a folder containing modules and the path to additional settings stored in the registry.
An example of Dante’s paths derivation
The folder containing modules includes a binary file that stores information about all downloaded modules, including their versions and filenames. This metadata file is encrypted with a simple XOR cipher, while the modules are encrypted with AES-256-CBC, using the first 0x10 bytes of the module file as the IV and the key bound to the machine. The key is equal to the SHA-256 hash of a buffer containing the CPU identifier and the Windows Product ID.
To protect itself, the orchestrator uses many of the same anti-analysis techniques, along with additional checks for specific process names and drivers.
If Dante doesn’t receive commands within the number of days specified in the configuration, it deletes itself and all traces of its activity.
At the time of writing this report, we were unable to analyze additional modules because there are currently no active Dante infections among our users. However, we would gladly analyze them if they become available. Now that information about this spyware has been made public and its developer has been identified, we hope it won’t be long before additional modules are discovered and examined. To support this effort, we are sharing a method that can be used to identify active Dante spyware infections (see the Indicators of compromise section).
Although we didn’t see the ForumTroll APT group using Dante in the Operation ForumTroll campaign, we have observed its use in other attacks linked to this group. Notably, we saw several minor similarities between this attack and others involving Dante, such as similar file system paths, the same persistence mechanism, data hidden in font files, and other minor details. Most importantly, we found similar code shared by the exploit, loader, and Dante. Taken together, these findings allow us to conclude that the Operation ForumTroll campaign was also carried out using the same toolset that comes with the Dante spyware.
Conclusion
This time, we have not one, but three conclusions.
1) DuplicateHandle is a dangerous API function. If the process is privileged and the user can provide a handle to it, the code should return an error when a pseudo-handle is supplied.
2) Attribution is the most challenging part of malware analysis and threat intelligence, but also the most rewarding when all the pieces of the puzzle fit together perfectly. If you ever dreamed of being a detective as a child and solving mysteries like Sherlock Holmes, Miss Marple, Columbo, or Scooby-Doo and the Mystery Inc. gang, then threat intelligence might be the right job for you!
3) Back in 2019, Hacking Team’s new owner stated in an interview that they wanted to change everything and start from scratch. It took some time, but by 2022, almost everything from Hacking Team had been redone. Now that Dante has been discovered, perhaps it’s time to start over again.
Full details of this research, as well as future updates on ForumTroll APT and Dante, are available to customers of the APT reporting service through our Threat Intelligence Portal.
TTP detection rules in Kaspersky NEXT EDR Expert suspicious_drop_dll_via_chrome
This rule detects a DLL load within a Chrome process, initiated via Outlook. This behavior is consistent with exploiting a vulnerability that enables browser sandbox bypass through the manipulation of Windows pseudo-handles and IPC.
possible_com_hijacking_by_memento_labs_via_registry
This rule detects an attempt at system persistence via the COM object hijacking technique, which exploits peculiarities in the Windows COM component resolution process. This feature allows malicious actors to create custom CLSID entries in the user-specific registry branch, thereby overriding legitimate system components. When the system attempts to instantiate the corresponding COM object, the malicious payload executes instead of the original code.
cve_exploit_detected
This generic rule is designed to detect attempts by malicious actors to exploit various vulnerabilities. Its logic is based on analyzing a broad set of characteristic patterns that reflect typical exploitation behavior.
Folder with modules
The folder containing the modules is located in %LocalAppData%, and is named with an eight-byte Base64 string. It contains files without extensions whose names are also Base64 strings that are eight bytes long. One of the files has the same name as the folder. This information can be used to identify an active infection.
Hacktivism and geopolitically motivated APT groups have become a significant threat to many regions of the world in recent years, damaging infrastructure and important functions of government, business, and society. In late 2022 we predicted that the involvement of hacktivist groups in all major geopolitical conflicts from now on will only increase and this is what we’ve been observing throughout the years. With regard to the Ukrainian-Russian conflict, this has led to a sharp increase of activities carried out by groups that identify themselves as either pro-Ukrainian or pro-Russian.
The rise in cybercrime amid geopolitical tensions is alarming. Our Kaspersky Cyber Threat Intelligence team has been observing several geopolitically motivated threat actors and hacktivist groups operating in various conflict zones. Through collecting and analyzing extensive data on these groups’ tactics, techniques, and procedures (TTPs), we’ve discovered a concerning trend: hacktivists are increasingly interconnected with financially motivated groups. They share tools, infrastructure, and resources.
This collaboration has serious implications. Their campaigns may disrupt not only business operations but also ordinary citizens’ lives, affecting everything from banking services to personal data security or the functioning of the healthcare system. Moreover, monetized techniques can spread exponentially as profit-seeking actors worldwide replicate and refine them. We consider these technical findings a valuable resource for global cybersecurity efforts. In this report, we share observations on threat actors who identify themselves as pro-Ukrainian.
About this report
The main goal of this report is to provide technical evidence supporting the theory we’ve proposed based on our previous research: that most of the groups we describe here actively collaborate, effectively forming three major threat clusters.
This report includes:
A library of threat groups, current as of 2025, with details on their main TTPs and tools.
A technical description of signature tactics, techniques, procedures, and toolsets used by these groups. This information is intended for practical use by SOC, DFIR, CTI, and threat hunting professionals.
What this report covers
This report contains information on the current TTPs of hacktivists and APT groups targeting Russian organizations particularly in 2025, however they are not limited to Russia as a target. Further research showed that among some of the groups’ targets, such as CloudAtlas and XDSpy, were assets in European, Asian, and Middle Eastern countries. In particular, traces of infections were discovered in 2024 in Slovakia and Serbia. The report doesn’t include groups that emerged in 2025, as we didn’t have sufficient time to research their activity. We’ve divided all groups into three clusters based on their TTPs:
Cluster I combines hacktivist and dual-purpose groups that use similar tactics, techniques, and tools. This cluster is characterized by:
Shared infrastructure
A unique software suite
Identical processes, command lines, directories, and so on
Distinctive TTPs
Cluster II comprises APT groups that have different TTPs from the hacktivists. Among these, we can distinguish simple APTs (characterized by their use of third-party utilities, scripts that carry out all the malicious logic, shared domain registrars, and concealing their real infrastructure behind reverse proxy systems – for example, using Cloudflare services), and more sophisticated ones (distinguished by their unique TTPs).
Cluster III includes hacktivist groups for which we’ve observed no signs of collaboration with other groups described here.
Example: Cyberthreat landscape in Russia in 2025
Hacktivism remains the key threat to Russian businesses and businesses in other conflict areas today, and the scale and complexity of these attacks keep growing. Traditionally, the term “hacktivism” refers to a blend of hacking and activism, where attackers use their skills to achieve social or political goals. Over the past few years, these threat actors have become more experienced and organized, collaborating with one another and sharing knowledge and tools to achieve common objectives.
Additionally, a new phenomenon known as “dual-purpose groups” has appeared in the Russian threat landscape in recent years. We’ve detected links between hacktivists and financially motivated groups. They use the same tools, techniques, and tactics, and even share common infrastructure and resources. Depending on the victim, they may pursue a variety of goals: demanding a ransom to decrypt data, causing irreparable damage, or leaking stolen data to the media. This suggests that these attackers belong to a single complex cluster.
Beyond this, “traditional” categories of attackers continue to operate in Russia and other regions: groups engaged in cyberespionage and purely financially motivated threat actors also remain a significant problem. Like other groups, geopolitically motivated groups are cybercriminals who undermine the secure and trustworthy use of digitalization opportunities and they can change and adapt their target regions depending on political developments.
That is why it is important to also be aware of the TTPs used by threat actors who appear to be attacking other targets. We will continue to monitor geopolitically motivated threat actors and publish technical reports about their TTPs.
Recommendations
To defend against the threats described in this report, Kaspersky experts recommend the following:
Provide your SOC teams with access to up-to-date information on the latest attacker tactics, techniques, and procedures (TTPs). Threat intelligence feeds from reliable providers, like Kaspersky Threat Intelligence, can help with this.
Use a comprehensive security solution that combines centralized monitoring and analysis, advanced threat detection and response, and security incident investigation tools. The Kaspersky NEXT XDR platform provides this functionality and is suitable for medium and large businesses in any industry.
Protect every component of modern and legacy industrial automation systems with specialized OT security solutions. Kaspersky Industrial CyberSecurity (KICS) — an XDR-class platform — ensures reliable protection for critical infrastructure in energy, manufacturing, mining, and transportation.
Conduct regular security awareness training for employees to reduce the likelihood of successful phishing and other social engineering attacks. Kaspersky Automated Security Awareness Platform is a good option for this.
The report is available for our partners and customers. If you are interested, please contact report@kaspersky.com
In September 2024, we detected malicious activity targeting financial (trading and brokerage) firms through the distribution of malicious .scr (screen saver) files disguised as financial documents via Skype messenger. The threat actor deployed a newly identified Remote Access Trojan (RAT) named GodRAT, which is based on the Gh0st RAT codebase. To evade detection, the attackers used steganography to embed shellcode within image files. This shellcode downloads GodRAT from a Command-and-Control (C2) server.
GodRAT supports additional plugins. Once installed, attackers utilized the FileManager plugin to explore the victim’s systems and deployed browser password stealers to extract credentials. In addition to GodRAT, they also used AsyncRAT as a secondary implant to maintain extended access.
GodRAT is very similar to the AwesomePuppet, another Gh0st RAT-based backdoor, which we reported in 2023, both in its code and distribution method. This suggests that it is probably an evolution of AwesomePuppet, which is in turn likely connected to the Winnti APT.
As of this blog’s publication, the attack remains active, with the most recent detection observed on August 12, 2025. Below is a timeline of attacks based on detections of GodRAT shellcode injector executables. In addition to malicious .scr (screen saver) files, attackers also used .pif (Program Information File) files masquerading as financial documents.
GodRAT shellcode injector executable MD5
File name
Detection date
Country/territory
Distribution
cf7100bbb5ceb587f04a1f42939e24ab
2023-2024ClientList&.scr
2024.09.09
Hong Kong
via Skype
e723258b75fee6fbd8095f0a2ae7e53c
2024-11-15_23.45.45 .scr
2024.11.28
Hong Kong
via Skype
d09fd377d8566b9d7a5880649a0192b4
2024-08-01_2024-12-31Data.scr
2025.01.09
United Arab Emirates
via Skype
a6352b2c4a3e00de9e84295c8d505dad
2025TopDataTransaction&.scr
2025.02.28
United Arab Emirates
NA
6c12ec3795b082ec8d5e294e6a5d6d01
2024-2025Top&Data.scr
2025-03-17
United Arab Emirates
via Skype
bb23d0e061a8535f4cb8c6d724839883
Corporate customer transaction &volume.pif
corporate customer transaction &volume.zip
company self-media account application qualifications&.zip
2025-05-26
United Arab Emirates
Lebanon
Malaysia
NA
160a80a754fd14679e5a7b5fc4aed672
个人信息资料&.pdf.pif
informasi pribadi &pelanggan global.pdf.pif
global customers preferential deposit steps&.pif
2025-07-17
Hong Kong
NA
2750d4d40902d123a80d24f0d0acc454
2025TopClineData&1.scr
2025-08-12
United Arab Emirates
NA
441b35ee7c366d4644dca741f51eb729
2025TopClineData&.scr
2025-08-12
Jordan
NA
Technical details
Malware implants
Shellcode loaders
We identified the use of two types of shellcode loaders, both of which execute the shellcode by injecting it into their own process. The first embeds the shellcode bytes directly into the loader binary, and the second reads the shellcode from an image file.
A GodRAT shellcode injector file named “2024-08-01_2024-12-31Data.scr” (MD5 d09fd377d8566b9d7a5880649a0192b4) is an executable that XOR-decodes embedded shellcode using the following hardcoded key: “OSEDBIU#IUSBDGKJS@SIHUDVNSO*SKJBKSDS#SFDBNXFCB”. A new section is then created in the memory of an executable process, where the decoded shellcode is copied. Then the new section is mapped into the process memory and a thread is spawned to execute the shellcode.
Another file, “2024-11-15_23.45.45 .scr” (MD5 e723258b75fee6fbd8095f0a2ae7e53c), serves as a self-extracting executable containing several embedded files as shown in the image below.
Content of self-extracting executable
Among these is “SDL2.dll” (MD5 512778f0de31fcce281d87f00affa4a8), which is a loader. The loader “SDL2.dll” is loaded by the legitimate executable Valve.exe (MD5 d6d6ddf71c2a46b4735c20ec16270ab6). Both the loader and Valve.exe are signed with an expired digital certificate. The certificate details are as follows:
Serial Number: 084caf4df499141d404b7199aa2c2131
Issuer Common Name: DigiCert SHA2 Assured ID Code Signing CA
Validity: Not Before: Friday, September 25, 2015 at 5:30:00 AM; Not After: Wednesday, October 3, 2018 at 5:30:00 PM
Subject: Valve
The loader “SDL2.dll” extracts shellcode bytes hidden within an image file “2024-11-15_23.45.45.jpg”. The image file represents some sort of financial details as shown below.
The loader allocates memory, copies the extracted shellcode bytes, and spawns a thread to execute it. We’ve also identified similar loaders that extracted shellcode from an image file named “2024-12-10_05.59.18.18.jpg”. One such loader (MD5 58f54b88f2009864db7e7a5d1610d27d) creates a registry load point entry at “HKCU\Software\Microsoft\Windows\CurrentVersion\Run\MyStartupApp” that points to the legitimate executable Valve.exe.
Shellcode functionality
The shellcode begins by searching for the string “godinfo,” which is immediately followed by configuration data that is decoded using the single-byte XOR key 0x63. The decoded configuration contains the following details: C2 IP address, port, and module command line string. The shellcode connects to the C2 server and transmits the string “GETGOD.” The C2 server responds with data representing the next (second) stage of the shellcode. This second-stage shellcode includes bootstrap code, a UPX-packed GodRAT DLL and configuration data. However, after downloading the second-stage shellcode, the first stage shellcode overwrites the configuration data in the second stage with its own configuration data. A new thread is then created to execute the second-stage shellcode. The bootstrap code injects the GodRAT DLL into memory and subsequently invokes the DLL’s entry point and its exported function “run.” The entire next-stage shellcode is passed as an argument to the “run” function.
GodRAT
The GodRAT DLL has the internal name ONLINE.dll and exports only one method: “run”. It checks the command line parameters and performs the following operations:
If the number of command line arguments is one, it copies the command line from the configuration data, which was “C:\Windows\System32\curl.exe” in the analyzed sample. Then it appends the argument “-Puppet” to the command line and creates a new process with the command line “C:\Windows\System32\curl.exe -Puppet”. The parameter “-Puppet” was used in AwesomePuppet RAT in a similar way. If this fails, GodRAT tries to create a process with the hardcoded command “%systemroot%\system2\cmd.exe -Puppet”. If successful, it suspends the process, allocates memory, and writes the shellcode buffer (passed as a parameter to the exported function “run”) to the allocated memory. A thread is then created to execute the shellcode, and the current process exits. This is done to execute GodRAT inside the curl.exe or cmd.exe process.
If the number of command line arguments is greater than one, it checks if the second argument is “-Puppet.” If true, it proceeds with the RAT’s functionality; otherwise, it acts as if the number of command line arguments is one, as described in the previous case.
The RAT establishes a TCP connection to the C2 server on the port from the configuration blob. It collects the following victim information: OS information, local hostname, malware process name and process ID, user account name associated with malware process, installed antivirus software and whether a capture driver is present. A capture driver is probably needed for capturing pictures, but we haven’t observed such behavior in the analyzed sample.
The collected data is zlib (deflate) compressed and then appended with a 15-byte header. Afterward, it is XOR-encoded three times per byte. The final data sent to the C2 server includes a 15-byte header followed by the compressed data blob. The header consists of the following fields: magic bytes
(\x74\x78\x20) , total size (compressed data size + header size), decompressed data size, and a fixed DWORD (1 for incoming data and 2 for outgoing data). The data received from the C2 is only XOR-decoded, again three times per byte. This received data includes a 15-byte header followed by the command data. The RAT can perform the following operations based on the received command data:
Inject a received plugin DLL into memory and call its exported method “PluginMe”, passing the C2 hostname and port as arguments. It supports different plugins, but we only saw deployment of the FileManager plugin
Close the socket and terminate the RAT process
Download a file from a provided URL and launch it using the CreateProcessA API, using the default desktop (WinSta0\Default)
Open a given URL using the shell command for opening Internet Explorer (e.g. “C:\Program Files\Internet Explorer\iexplore.exe” %1)
Same as above but specify the default desktop (WinSta0\Default)
Create the file “%AppData%\config.ini”, create a section named “config” inside this file, and, create in that section a key called “NoteName” with the string provided from the C2 as its value
GodRAT FileManager plugin
The FileManager plugin DLL has the internal name FILE.dll and exports a single method called PluginMe. This plugin gathers the following victim information: details about logical drives (including drive letter, drive type, total bytes, available free bytes, file system name, and volume name), the desktop path of the currently logged-on user, and whether the user is operating under the SYSTEM account. The plugin can perform the following operations based on the commands it receives:
List files and folders at a specified location, collecting details like type (file or folder), name, size, and last write time
Write data to an existing file at a specified offset
Read data from a file at a specified offset
Delete a file at a specified path
Recursively delete files at a specified path
Check for the existence of a specified file. If the file exists, send its size; otherwise, create a file for writing.
Create a directory at a specified path
Move an existing file or directory, including its children
Open a specified application with its window visible using the ShellExecuteA API
Open a specified application with its window hidden using the ShellExecuteA API
Execute a specified command line with a hidden window using cmd.exe
Search for files at a specified location, collecting absolute file paths, sizes, and last write times
Stop a file search operation
Execute 7zip by writing hard-coded 7zip executable bytes to “%AppData%\7z.exe” (MD5 eb8d53f9276d67afafb393a5b16e7c61) and “%AppData%\7z.dll” (MD5 e055aa2b77890647bdf5878b534fba2c), and then runs “%AppData%\7z.exe” with parameters provided by the C2. The utility is used to unzip dropped files.
Second-stage payload
The attackers deployed the following second-stage implants using GodRAT’s FileManager plugin:
Chrome password stealer
The stealer is placed at “%ALLUSERSPROFILE%\google\chrome.exe” (MD5 31385291c01bb25d635d098f91708905). It looks for Chrome database files with login data for accessed websites, including URLs and usernames used for authentication, as well as user passwords. The collected data is saved in the file “google.txt” within the module’s directory. The stealer searches for the following files:
%LOCALAPPDATA%\Google\Chrome\User Data\Default\Login Data – an SQLite database with login and stats tables. This can be used to extract URLs and usernames used for authentication. Passwords are encrypted and not visible.
%LOCALAPPDATA%\Google\Chrome\User Data\Local State – a file that contains the encryption key needed to decrypt stored passwords.
MS Edge password stealer
The stealer is placed at “%ALLUSERSPROFILE%\google\msedge.exe” (MD5 cdd5c08b43238c47087a5d914d61c943). The collected data is stored in the file “edge.txt” in the module’s directory. The module attempts to extract passwords using the following database and file:
%LOCALAPPDATA%\Microsoft\Edge\User Data\Default\Login Data – the “Login Data” SQLite database stores Edge logins in the “logins” table.
%LOCALAPPDATA%\Microsoft\Edge\User Data\Local State – this file contains the encryption key used to decrypt saved passwords.
AsyncRAT
The DLL file (MD5 605f25606bb925d61ccc47f0150db674) is an injector and is placed at “%LOCALAPPDATA%\bugreport\LoggerCollector.dll” or “%ALLUSERSPROFILE%\bugreport\LoggerCollector.dll”. It verifies that the module name matches “bugreport_.exe”. The loader then XOR-decodes embedded shellcode using the key “EG9RUOFIBVODSLFJBXLSVWKJENQWBIVUKDSZADVXBWEADSXZCXBVADZXVZXZXCBWES”. After decoding, it subtracts the second key “IUDSY86BVUIQNOEWSUFHGV87QCI3WEVBRSFUKIHVJQW7E8RBUYCBQO3WEIQWEXCSSA” from each shellcode byte.
A new memory section is created, the XOR-decoded shellcode is copied into it, and then the section is mapped into the current process memory. A thread is started to execute the code in this section. The shellcode is used to reflectively inject the C# AsyncRAT binary. Before injection, it patches the AMSI scanning functions (AmsiScanBuffer, AmsiScanString) and the EtwEventWrite function to bypass security checks.
AsyncRAT includes an embedded certificate with the following properties:
Serial Number: df:2d:51:bf:e8:ec:0c:dc:d9:9a:3e:e8:57:1b:d9
Issuer: CN = marke
Validity: Not Before: Sep 4 18:59:09 2024 GMT; Not After: Dec 31 23:59:59 9999 GMT
Subject: CN = marke
GodRAT client source and builder
We discovered the source code for the GodRAT client on a popular online malware scanner. It had been uploaded in July 2024. The file is named “GodRAT V3.5_______dll.rar” (MD5 04bf56c6491c5a455efea7dbf94145f1). This archive also includes the GodRAT builder (MD5 5f7087039cb42090003cc9dbb493215e), which allows users to generate either an executable file or a DLL. If an executable is chosen, users can pick a legitimate executable name from a list (svchost.exe, cmd.exe, cscript.exe, curl.exe, wscript.exe, QQMusic.exe and QQScLauncher.exe) to inject the code into. When saving the final payload, the user can choose the file type (.exe, .com, .bat, .scr and .pif). The source code is based on Gh0st RAT, as indicated by the fact that the auto-generated UID in “GodRAT.h” file matches that of “gh0st.h”, which suggests that GodRAT was originally just a renamed version of Gh0st RAT.
GodRAT.h
gh0st.h
Conclusions
The rare command line parameter “puppet,” along with code similarities to Gh0st RAT and shared artifacts such as the fingerprint header, indicate that GodRAT shares a common origin with AwesomePuppet RAT, which we described in a private report in 2023. This RAT is also based on the Gh0st RAT source code and is likely connected with Winnty APT activities. Based on these findings, we are highly confident that GodRAT is an evolution of AwesomePuppet. There are some differences, however. For example, the C2 packet of GodRAT uses the “direction” field, which was not utilized in AwesomePuppet.
Old implant codebases, such as Gh0st RAT, which are nearly two decades old, continue to be used today. These are often customized and rebuilt to target a wide range of victims. These old implants are known to have been used by various threat actors for a long time, and the GodRAT discovery demonstrates that legacy codebases like Gh0st RAT can still maintain a long lifespan in the cybersecurity landscape.
In the latter half of 2024, the Russian IT industry, alongside a number of entities in other countries, experienced a notable cyberattack. The attackers employed a range of malicious techniques to trick security systems and remain undetected. To bypass detection, they delivered information about their payload via profiles on both Russian and international social media platforms, as well as other popular sites supporting user-generated content. The samples we analyzed communicated with GitHub, Microsoft Learn Challenge, Quora, and Russian-language social networks. The attackers thus aimed to conceal their activities and establish a complex execution chain for the long-known and widely used Cobalt Strike Beacon.
Although the campaign was most active during November and December 2024, it continued until April 2025. After a two-month silence, our security solutions began detecting attacks again. The adversary employed new malicious samples, which were only slightly modified versions of those described in the article.
Kaspersky solutions detect this threat and assign the following verdicts:
HEUR:Trojan.Win64.Agent.gen
HEUR:Trojan.Win64.Kryptik.gen
HEUR:Trojan.WinLNK.Starter.gen
MEM:Trojan.Multi.Cobalt.gen
HEUR:Trojan.Win32.CobaltStrike.gen
Initial attack vector
The initial attack vector involved spear phishing emails with malicious attachments. The emails were disguised as legitimate communications from major state-owned companies, particularly within the oil and gas sector. The attackers feigned interest in the victims’ products and services to create a convincing illusion of legitimacy and increase the likelihood of the recipient opening the malicious attachment.
Sample spear phishing email
All attachments we observed were RAR archives with the following structure:
Требования.lnk
Требования
Company Profile.pdf
List of requirements.pdf
Требования
pdf
pdf
Company profile.pdf and List of requirements.pdf were decoy files designed to complement the information in the email. The directory Требования\Требования contained executables named Company.pdf and Requirements.pdf, designed to mimic secure PDF documents. The directory itself was hidden, invisible to the user by default.
When Требования.lnk was opened, the files in Требования\Требования were copied to %public%\Downloads\ and renamed: Company.pdf became nau.exe, and Requirements.pdf became BugSplatRc64.dll. Immediately afterward, nau.exe was executed.
In this attack, the adversary leveraged a common technique: DLL Hijacking (T1574.001). To deploy their malicious payload, they exploited the legitimate Crash reporting Send Utility (original filename: BsSndRpt.exe). The tool is part of BugSplat, which helps developers get detailed, real-time crash reports for their applications. This was the utility that the attackers renamed from Company.pdf to nau.exe.
For BsSndRpt.exe to function correctly, it requires BugSplatRc64.dll. The attackers saved their malicious file with that name, forcing the utility to load it instead of the legitimate file.
To further evade detection, the malicious BugSplatRc64.dll library employs Dynamic API Resolution (T1027.007). This technique involves obscuring API functions within the code, resolving them dynamically only during execution. In this specific case, the functions were obfuscated via a custom hashing algorithm, which shares similarities with CRC (Cyclic Redundancy Check).
Hashing algorithm
A significant portion of the hashes within the malicious sample are XOR-encrypted. Additionally, after each call, the address is removed from memory, and API functions are reloaded if a subsequent call is needed.
MessageBoxW function hook
The primary purpose of BugSplatRc64.dll is to intercept API calls within the legitimate utility’s process address space to execute its malicious code (DLL Substitution, T1574.001). Instead of one of the API functions required by the process, a call is made to a function (which we’ll refer to as NewMessageBox) located within the malicious library’s address space. This technique makes it difficult to detect the malware in a sandbox environment, as the library won’t launch without a specific executable file. In most of the samples we’ve found, the MessageBoxW function call is modified, though we’ve also discovered samples that altered other API calls.
Hooking MessageBoxW
After modifying the intercepted function, the library returns control to the legitimate nau.exe process.
NewMessageBox function
Once the hook is in place, whenever MessageBoxW (or another modified function) is called within the legitimate process, NewMessageBox executes. Its primary role is to run a shellcode, which is loaded in two stages.
First, the executable retrieves HTML content from a webpage located at one of the addresses encrypted within the malicious library. In the sample we analyzed, these addresses were https://techcommunity.microsoft[.]com/t5/user/viewprofilepage/user-id/2631 and https://www.quora[.]com/profile/Marieformach. The information found at both locations is identical. The second address serves as a backup if the first one becomes inactive.
NewMessageBox searches the HTML code retrieved from these addresses for a string whose beginning and end match patterns that are defined in the code and consist of mixed-case alphanumeric characters. This technique allows attackers to leverage various popular websites for storing these strings. We’ve found malicious information hidden inside profiles on GitHub, Microsoft Learn Challenge, Q&A websites, and even Russian social media platforms.
Malicious profiles on popular online platforms
While we didn’t find any evidence of the attackers using real people’s social media profiles, as all the accounts were created specifically for this attack, aligning with MITRE ATT&CK technique T1585.001, there’s nothing stopping the threat actor from abusing various mechanisms these platforms provide. For instance, malicious content strings could be posted in comments on legitimate users’ posts.
The extracted payload is a base64-encoded string with XOR-encrypted data. Decrypted, this data reveals the URL https://raw.githubusercontent[.]com/Mariew14/kong/master/spec/fixtures/verify-prs, which then downloads another XOR-encrypted shellcode.
We initially expected NewMessageBox to execute the shellcode immediately after decryption. Instead, nau.exe launches a child process with the same name and the qstt parameter, in which all of the above actions are repeated once again, ultimately resulting in the execution of the shellcode.
Shellcode
An analysis of the shellcode (793453624aba82c8e980ca168c60837d) reveals a reflective loader that injects Cobalt Strike Beacon into the process memory and then hands over control to it (T1620).
The observed Cobalt sample communicates with the C2 server at moeodincovo[.]com/divide/mail/SUVVJRQO8QRC.
Attribution and victims
The method used to retrieve the shellcode download address is similar to the C2 acquisition pattern that our fellow security analysts observed in the EastWind campaign. In both cases, the URL is stored in a specially crafted profile on a legitimate online platform like Quora or GitHub. In both instances, it’s also encrypted using an XOR algorithm. Furthermore, the targets of the two campaigns partially overlap: both groups of attackers show interest in Russian IT companies.
It’s worth mentioning that while most of the attacks targeted Russian companies, we also found evidence of the malicious activity in China, Japan, Malaysia, and Peru. The majority of the victims were large and medium-sized businesses.
Takeaways
Threat actors are using increasingly complex and clever methods to conceal long-known tools. The campaign described here used techniques like DLL hijacking, which is gaining popularity among attackers, as well as obfuscating API calls within the malicious library and using legitimate resources like Quora, GitHub, and Microsoft Learn Challenge to host C2 addresses. We recommend that organizations adhere to the following guidelines to stay safe:
Track the status of their infrastructure and continuously monitor their perimeter.
Use powerful security solutions to detect and block malware embedded within bulk email.
Train their staff to increase cybersecurity awareness.
Secure corporate devices with a comprehensive system that detects and blocks attacks in the early stages.
You can detect the malware described here by searching for the unsigned file BugSplatRc64.dll in the file system. Another indirect sign of an attack could be the presence of Crash reporting Send Utility with any filename other than the original BsSndRpt.exe.